The patch fixes the code for finding the next bridge with the
"pre_enable_prev_first" flag set to false. In case this condition is
not verified, i. e. there is no subsequent bridge with the flag set to
false, the whole bridge list is traversed, invalidating the "next"
variable.
The use of a new iteration variable (i. e. "iter") ensures that the value
of the "next" variable is not invalidated.
Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order")
Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---
(no changes since v1)
drivers/gpu/drm/drm_bridge.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index f66bf4925dd8..2e5781bf192e 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -662,7 +662,7 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
struct drm_atomic_state *old_state)
{
struct drm_encoder *encoder;
- struct drm_bridge *next, *limit;
+ struct drm_bridge *iter, *next, *limit;
if (!bridge)
return;
@@ -680,14 +680,15 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
* was enabled first, so disabled last
*/
limit = next;
+ iter = next;
/* Find the next bridge that has NOT requested
* prev to be enabled first / disabled last
*/
- list_for_each_entry_from(next, &encoder->bridge_chain,
+ list_for_each_entry_from(iter, &encoder->bridge_chain,
chain_node) {
- if (!next->pre_enable_prev_first) {
- next = list_prev_entry(next, chain_node);
+ if (!iter->pre_enable_prev_first) {
+ next = list_prev_entry(iter, chain_node);
limit = next;
break;
}
--
2.43.0Hi Dario
On Tue, 5 Dec 2023 at 10:54, Dario Binacchi
<dario.binacchi@amarulasolutions.com> wrote:
>
> The patch fixes the code for finding the next bridge with the
> "pre_enable_prev_first" flag set to false. In case this condition is
> not verified, i. e. there is no subsequent bridge with the flag set to
> false, the whole bridge list is traversed, invalidating the "next"
> variable.
>
> The use of a new iteration variable (i. e. "iter") ensures that the value
> of the "next" variable is not invalidated.
We already have https://patchwork.freedesktop.org/patch/529288/ that
has been reviewed (but not applied) to resolve this. What does this
version do differently and why?
Dave
> Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order")
> Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_bridge.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index f66bf4925dd8..2e5781bf192e 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -662,7 +662,7 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
> struct drm_atomic_state *old_state)
> {
> struct drm_encoder *encoder;
> - struct drm_bridge *next, *limit;
> + struct drm_bridge *iter, *next, *limit;
>
> if (!bridge)
> return;
> @@ -680,14 +680,15 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
> * was enabled first, so disabled last
> */
> limit = next;
> + iter = next;
>
> /* Find the next bridge that has NOT requested
> * prev to be enabled first / disabled last
> */
> - list_for_each_entry_from(next, &encoder->bridge_chain,
> + list_for_each_entry_from(iter, &encoder->bridge_chain,
> chain_node) {
> - if (!next->pre_enable_prev_first) {
> - next = list_prev_entry(next, chain_node);
> + if (!iter->pre_enable_prev_first) {
> + next = list_prev_entry(iter, chain_node);
> limit = next;
> break;
> }
> --
> 2.43.0
>
Hi Dave and Jagan,
On Tue, Dec 5, 2023 at 4:39 PM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> Hi Dario
>
> On Tue, 5 Dec 2023 at 10:54, Dario Binacchi
> <dario.binacchi@amarulasolutions.com> wrote:
> >
> > The patch fixes the code for finding the next bridge with the
> > "pre_enable_prev_first" flag set to false. In case this condition is
> > not verified, i. e. there is no subsequent bridge with the flag set to
> > false, the whole bridge list is traversed, invalidating the "next"
> > variable.
> >
> > The use of a new iteration variable (i. e. "iter") ensures that the value
> > of the "next" variable is not invalidated.
>
> We already have https://patchwork.freedesktop.org/patch/529288/ that
> has been reviewed (but not applied) to resolve this. What does this
> version do differently and why?
My patches only affect drm_atomic_bridge_chain_post_disable(), whereas
Jagan's patch affects both
drm_atomic_bridge_chain_post_disable() and drm_atomic_bridge_chain_pre_enable().
I tested Jagan's patch on my system with success and I reviewed with
Michael Trimarchi the
drm_atomic_bridge_chain_pre_enable() fixing and we think it's okay.
We also believe that our changes to post_disable() are better, as we
set the 'next' variable only when required,
and the code is more optimized since the list_is_last() is not called
within the loop.
Would it be possible to use Jagan's patch for fixing
drm_atomic_bridge_chain_pre_enable() and mine for
fixing drm_atomic_bridge_chain_post_disable()?
Thanks and regards,
Dario
>
> Dave
>
> > Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order")
> > Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com>
> > Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> > ---
> >
> > (no changes since v1)
> >
> > drivers/gpu/drm/drm_bridge.c | 9 +++++----
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index f66bf4925dd8..2e5781bf192e 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -662,7 +662,7 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
> > struct drm_atomic_state *old_state)
> > {
> > struct drm_encoder *encoder;
> > - struct drm_bridge *next, *limit;
> > + struct drm_bridge *iter, *next, *limit;
> >
> > if (!bridge)
> > return;
> > @@ -680,14 +680,15 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
> > * was enabled first, so disabled last
> > */
> > limit = next;
> > + iter = next;
> >
> > /* Find the next bridge that has NOT requested
> > * prev to be enabled first / disabled last
> > */
> > - list_for_each_entry_from(next, &encoder->bridge_chain,
> > + list_for_each_entry_from(iter, &encoder->bridge_chain,
> > chain_node) {
> > - if (!next->pre_enable_prev_first) {
> > - next = list_prev_entry(next, chain_node);
> > + if (!iter->pre_enable_prev_first) {
> > + next = list_prev_entry(iter, chain_node);
> > limit = next;
> > break;
> > }
> > --
> > 2.43.0
> >
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binacchi@amarulasolutions.com
__________________________________
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
info@amarulasolutions.com
www.amarulasolutions.com
Hi Dario, On Wed, Dec 6, 2023 at 6:57 PM Dario Binacchi <dario.binacchi@amarulasolutions.com> wrote: > > Hi Dave and Jagan, > > On Tue, Dec 5, 2023 at 4:39 PM Dave Stevenson > <dave.stevenson@raspberrypi.com> wrote: > > > > Hi Dario > > > > On Tue, 5 Dec 2023 at 10:54, Dario Binacchi > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > The patch fixes the code for finding the next bridge with the > > > "pre_enable_prev_first" flag set to false. In case this condition is > > > not verified, i. e. there is no subsequent bridge with the flag set to > > > false, the whole bridge list is traversed, invalidating the "next" > > > variable. > > > > > > The use of a new iteration variable (i. e. "iter") ensures that the value > > > of the "next" variable is not invalidated. > > > > We already have https://patchwork.freedesktop.org/patch/529288/ that > > has been reviewed (but not applied) to resolve this. What does this > > version do differently and why? > > My patches only affect drm_atomic_bridge_chain_post_disable(), whereas > Jagan's patch affects both > drm_atomic_bridge_chain_post_disable() and drm_atomic_bridge_chain_pre_enable(). > I tested Jagan's patch on my system with success and I reviewed with > Michael Trimarchi the > drm_atomic_bridge_chain_pre_enable() fixing and we think it's okay. > We also believe that our changes to post_disable() are better, as we > set the 'next' variable only when required, > and the code is more optimized since the list_is_last() is not called > within the loop. > Would it be possible to use Jagan's patch for fixing > drm_atomic_bridge_chain_pre_enable() and mine for > fixing drm_atomic_bridge_chain_post_disable()? > Can you please share the post-disabled bridge chain list with the below example before and after your change? Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder Thanks, Jagan.
Hi Jagan On Wed, Dec 6, 2023 at 2:31 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > Hi Dario, > > On Wed, Dec 6, 2023 at 6:57 PM Dario Binacchi > <dario.binacchi@amarulasolutions.com> wrote: > > > > Hi Dave and Jagan, > > > > On Tue, Dec 5, 2023 at 4:39 PM Dave Stevenson > > <dave.stevenson@raspberrypi.com> wrote: > > > > > > Hi Dario > > > > > > On Tue, 5 Dec 2023 at 10:54, Dario Binacchi > > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > > > The patch fixes the code for finding the next bridge with the > > > > "pre_enable_prev_first" flag set to false. In case this condition is > > > > not verified, i. e. there is no subsequent bridge with the flag set to > > > > false, the whole bridge list is traversed, invalidating the "next" > > > > variable. > > > > > > > > The use of a new iteration variable (i. e. "iter") ensures that the value > > > > of the "next" variable is not invalidated. > > > > > > We already have https://patchwork.freedesktop.org/patch/529288/ that > > > has been reviewed (but not applied) to resolve this. What does this > > > version do differently and why? > > > > My patches only affect drm_atomic_bridge_chain_post_disable(), whereas > > Jagan's patch affects both > > drm_atomic_bridge_chain_post_disable() and drm_atomic_bridge_chain_pre_enable(). > > I tested Jagan's patch on my system with success and I reviewed with > > Michael Trimarchi the > > drm_atomic_bridge_chain_pre_enable() fixing and we think it's okay. > > We also believe that our changes to post_disable() are better, as we > > set the 'next' variable only when required, > > and the code is more optimized since the list_is_last() is not called > > within the loop. > > Would it be possible to use Jagan's patch for fixing > > drm_atomic_bridge_chain_pre_enable() and mine for > > fixing drm_atomic_bridge_chain_post_disable()? > > > > Can you please share the post-disabled bridge chain list with the > below example before and after your change? We have already git commit the description in how the patch affects the post_disable. As Dario reported your patch is ok even in our use case. We don't have a real use case as the one you describe. Can we know how you test it in this use case here? Can you test our patches of post_disable? Thanks Michael > > Example: > - Panel > - Bridge 1 > - Bridge 2 pre_enable_prev_first > - Bridge 3 > - Bridge 4 pre_enable_prev_first > - Bridge 5 pre_enable_prev_first > - Bridge 6 > - Encoder > > Thanks, > Jagan.
Hi Jagan and Dave, On Wed, Dec 6, 2023 at 2:57 PM Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote: > > Hi Jagan > > On Wed, Dec 6, 2023 at 2:31 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > Hi Dario, > > > > On Wed, Dec 6, 2023 at 6:57 PM Dario Binacchi > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > Hi Dave and Jagan, > > > > > > On Tue, Dec 5, 2023 at 4:39 PM Dave Stevenson > > > <dave.stevenson@raspberrypi.com> wrote: > > > > > > > > Hi Dario > > > > > > > > On Tue, 5 Dec 2023 at 10:54, Dario Binacchi > > > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > > > > > The patch fixes the code for finding the next bridge with the > > > > > "pre_enable_prev_first" flag set to false. In case this condition is > > > > > not verified, i. e. there is no subsequent bridge with the flag set to > > > > > false, the whole bridge list is traversed, invalidating the "next" > > > > > variable. > > > > > > > > > > The use of a new iteration variable (i. e. "iter") ensures that the value > > > > > of the "next" variable is not invalidated. > > > > > > > > We already have https://patchwork.freedesktop.org/patch/529288/ that > > > > has been reviewed (but not applied) to resolve this. What does this > > > > version do differently and why? > > > > > > My patches only affect drm_atomic_bridge_chain_post_disable(), whereas > > > Jagan's patch affects both > > > drm_atomic_bridge_chain_post_disable() and drm_atomic_bridge_chain_pre_enable(). > > > I tested Jagan's patch on my system with success and I reviewed with > > > Michael Trimarchi the > > > drm_atomic_bridge_chain_pre_enable() fixing and we think it's okay. > > > We also believe that our changes to post_disable() are better, as we > > > set the 'next' variable only when required, > > > and the code is more optimized since the list_is_last() is not called > > > within the loop. > > > Would it be possible to use Jagan's patch for fixing > > > drm_atomic_bridge_chain_pre_enable() and mine for > > > fixing drm_atomic_bridge_chain_post_disable()? > > > > > > > Can you please share the post-disabled bridge chain list with the > > below example before and after your change? > > We have already git commit the description in how the patch affects > the post_disable. As Dario > reported your patch is ok even in our use case. We don't have a real > use case as the one you describe. > > Can we know how you test it in this use case here? Can you test our > patches of post_disable? > > Thanks > Michael > > > > > Example: > > - Panel > > - Bridge 1 > > - Bridge 2 pre_enable_prev_first > > - Bridge 3 > > - Bridge 4 pre_enable_prev_first > > - Bridge 5 pre_enable_prev_first > > - Bridge 6 > > - Encoder > > > > Thanks, > > Jagan. Starting from my use case: # cat /sys/kernel/debug/dri/32e00000.lcdif/bridge_chains encoder[36] bridge[0] type: 16, ops: 0x0, OF: /soc@0/bus@32c00000/dsi@32e10000:fsl,imx8mn-mipi-dsim bridge[1] type: 16, ops: 0x8, OF: /soc@0/bus@32c00000/dsi@32e10000/panel@0:sharp,ls068b3sx0 I developed a pass through MIPI-DSI bridge driver to try to test your case: # cat /sys/kernel/debug/dri/32e00000.lcdif/bridge_chains encoder[36] bridge[0] type: 16, ops: 0x0, OF: /soc@0/bus@32c00000/dsi@32e10000:fsl,imx8mn-mipi-dsim bridge[1] type: 16, ops: 0x0, OF: /pt_mipi_dsi1:amarula,pt-mipi-dsi bridge[2] type: 16, ops: 0x0, OF: /pt_mipi_dsi2:amarula,pt-mipi-dsi bridge[3] type: 16, ops: 0x0, OF: /pt_mipi_dsi3:amarula,pt-mipi-dsi bridge[4] type: 16, ops: 0x0, OF: /pt_mipi_dsi4:amarula,pt-mipi-dsi bridge[5] type: 16, ops: 0x0, OF: /pt_mipi_dsi5:amarula,pt-mipi-dsi bridge[6] type: 16, ops: 0x8, OF: /pt_mipi_dsi5/panel@0:sharp,ls068b3sx02 The pre_enable_prev_first flag is set through the "amarula,pre_enable_prev_first" dts property I put in my dts. Your and my patches give the same results (result: OK) in both your use case and mine. But If I test my new "enlarged" use case: - Encoder - bridge[0] (samsung-dsim) - bridge[1] pre_enable_prev_first - bridge[2] pre_enable_prev_first - bridge[3] pre_enable_prev_first - bridge[4] pre_enable_prev_first - bridge[5] pre_enable_prev_first - bridge[6] pre_enable_prev_first (Panel) the result is: my patches: KO your patch: OK So, I will remove my patches from the series. Can the driver I implemented to test the use cases (pass through MIPI-DSI) be considered useful for testing these bridge pipelines? Does it make sense to send its patch? Thanks and regards Dario Dario Binacchi Senior Embedded Linux Developer dario.binacchi@amarulasolutions.com __________________________________ Amarula Solutions SRL Via Le Canevare 30, 31100 Treviso, Veneto, IT T. +39 042 243 5310 info@amarulasolutions.com www.amarulasolutions.com
On Wed, Dec 13, 2023 at 12:59:05PM +0100, Dario Binacchi wrote: > Hi Jagan and Dave, > > On Wed, Dec 6, 2023 at 2:57 PM Michael Nazzareno Trimarchi > <michael@amarulasolutions.com> wrote: > > > > Hi Jagan > > > > On Wed, Dec 6, 2023 at 2:31 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > > > Hi Dario, > > > > > > On Wed, Dec 6, 2023 at 6:57 PM Dario Binacchi > > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > > > Hi Dave and Jagan, > > > > > > > > On Tue, Dec 5, 2023 at 4:39 PM Dave Stevenson > > > > <dave.stevenson@raspberrypi.com> wrote: > > > > > > > > > > Hi Dario > > > > > > > > > > On Tue, 5 Dec 2023 at 10:54, Dario Binacchi > > > > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > > > > > > > The patch fixes the code for finding the next bridge with the > > > > > > "pre_enable_prev_first" flag set to false. In case this condition is > > > > > > not verified, i. e. there is no subsequent bridge with the flag set to > > > > > > false, the whole bridge list is traversed, invalidating the "next" > > > > > > variable. > > > > > > > > > > > > The use of a new iteration variable (i. e. "iter") ensures that the value > > > > > > of the "next" variable is not invalidated. > > > > > > > > > > We already have https://patchwork.freedesktop.org/patch/529288/ that > > > > > has been reviewed (but not applied) to resolve this. What does this > > > > > version do differently and why? > > > > > > > > My patches only affect drm_atomic_bridge_chain_post_disable(), whereas > > > > Jagan's patch affects both > > > > drm_atomic_bridge_chain_post_disable() and drm_atomic_bridge_chain_pre_enable(). > > > > I tested Jagan's patch on my system with success and I reviewed with > > > > Michael Trimarchi the > > > > drm_atomic_bridge_chain_pre_enable() fixing and we think it's okay. > > > > We also believe that our changes to post_disable() are better, as we > > > > set the 'next' variable only when required, > > > > and the code is more optimized since the list_is_last() is not called > > > > within the loop. > > > > Would it be possible to use Jagan's patch for fixing > > > > drm_atomic_bridge_chain_pre_enable() and mine for > > > > fixing drm_atomic_bridge_chain_post_disable()? > > > > > > > > > > Can you please share the post-disabled bridge chain list with the > > > below example before and after your change? > > > > We have already git commit the description in how the patch affects > > the post_disable. As Dario > > reported your patch is ok even in our use case. We don't have a real > > use case as the one you describe. > > > > Can we know how you test it in this use case here? Can you test our > > patches of post_disable? > > > > Thanks > > Michael > > > > > > > > Example: > > > - Panel > > > - Bridge 1 > > > - Bridge 2 pre_enable_prev_first > > > - Bridge 3 > > > - Bridge 4 pre_enable_prev_first > > > - Bridge 5 pre_enable_prev_first > > > - Bridge 6 > > > - Encoder > > > > > > Thanks, > > > Jagan. > > Starting from my use case: > > # cat /sys/kernel/debug/dri/32e00000.lcdif/bridge_chains > encoder[36] > bridge[0] type: 16, ops: 0x0, OF: > /soc@0/bus@32c00000/dsi@32e10000:fsl,imx8mn-mipi-dsim > bridge[1] type: 16, ops: 0x8, OF: > /soc@0/bus@32c00000/dsi@32e10000/panel@0:sharp,ls068b3sx0 > > I developed a pass through MIPI-DSI bridge driver to try to test your case: > # cat /sys/kernel/debug/dri/32e00000.lcdif/bridge_chains > encoder[36] > bridge[0] type: 16, ops: 0x0, OF: > /soc@0/bus@32c00000/dsi@32e10000:fsl,imx8mn-mipi-dsim > bridge[1] type: 16, ops: 0x0, OF: /pt_mipi_dsi1:amarula,pt-mipi-dsi > bridge[2] type: 16, ops: 0x0, OF: /pt_mipi_dsi2:amarula,pt-mipi-dsi > bridge[3] type: 16, ops: 0x0, OF: /pt_mipi_dsi3:amarula,pt-mipi-dsi > bridge[4] type: 16, ops: 0x0, OF: /pt_mipi_dsi4:amarula,pt-mipi-dsi > bridge[5] type: 16, ops: 0x0, OF: /pt_mipi_dsi5:amarula,pt-mipi-dsi > bridge[6] type: 16, ops: 0x8, OF: /pt_mipi_dsi5/panel@0:sharp,ls068b3sx02 > > The pre_enable_prev_first flag is set through the > "amarula,pre_enable_prev_first" dts property I put > in my dts. > Your and my patches give the same results (result: OK) in both your > use case and mine. > But If I test my new "enlarged" use case: > > - Encoder > - bridge[0] (samsung-dsim) > - bridge[1] pre_enable_prev_first > - bridge[2] pre_enable_prev_first > - bridge[3] pre_enable_prev_first > - bridge[4] pre_enable_prev_first > - bridge[5] pre_enable_prev_first > - bridge[6] pre_enable_prev_first (Panel) > > the result is: > my patches: KO > your patch: OK > > So, I will remove my patches from the series. > > Can the driver I implemented to test the use cases (pass through > MIPI-DSI) be considered useful for testing these > bridge pipelines? > Does it make sense to send its patch? As it is, not really, but kunit tests would be very welcome Maxime
On Wed, Dec 13, 2023 at 5:29 PM Dario Binacchi <dario.binacchi@amarulasolutions.com> wrote: > > Hi Jagan and Dave, > > On Wed, Dec 6, 2023 at 2:57 PM Michael Nazzareno Trimarchi > <michael@amarulasolutions.com> wrote: > > > > Hi Jagan > > > > On Wed, Dec 6, 2023 at 2:31 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > > > Hi Dario, > > > > > > On Wed, Dec 6, 2023 at 6:57 PM Dario Binacchi > > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > > > Hi Dave and Jagan, > > > > > > > > On Tue, Dec 5, 2023 at 4:39 PM Dave Stevenson > > > > <dave.stevenson@raspberrypi.com> wrote: > > > > > > > > > > Hi Dario > > > > > > > > > > On Tue, 5 Dec 2023 at 10:54, Dario Binacchi > > > > > <dario.binacchi@amarulasolutions.com> wrote: > > > > > > > > > > > > The patch fixes the code for finding the next bridge with the > > > > > > "pre_enable_prev_first" flag set to false. In case this condition is > > > > > > not verified, i. e. there is no subsequent bridge with the flag set to > > > > > > false, the whole bridge list is traversed, invalidating the "next" > > > > > > variable. > > > > > > > > > > > > The use of a new iteration variable (i. e. "iter") ensures that the value > > > > > > of the "next" variable is not invalidated. > > > > > > > > > > We already have https://patchwork.freedesktop.org/patch/529288/ that > > > > > has been reviewed (but not applied) to resolve this. What does this > > > > > version do differently and why? > > > > > > > > My patches only affect drm_atomic_bridge_chain_post_disable(), whereas > > > > Jagan's patch affects both > > > > drm_atomic_bridge_chain_post_disable() and drm_atomic_bridge_chain_pre_enable(). > > > > I tested Jagan's patch on my system with success and I reviewed with > > > > Michael Trimarchi the > > > > drm_atomic_bridge_chain_pre_enable() fixing and we think it's okay. > > > > We also believe that our changes to post_disable() are better, as we > > > > set the 'next' variable only when required, > > > > and the code is more optimized since the list_is_last() is not called > > > > within the loop. > > > > Would it be possible to use Jagan's patch for fixing > > > > drm_atomic_bridge_chain_pre_enable() and mine for > > > > fixing drm_atomic_bridge_chain_post_disable()? > > > > > > > > > > Can you please share the post-disabled bridge chain list with the > > > below example before and after your change? > > > > We have already git commit the description in how the patch affects > > the post_disable. As Dario > > reported your patch is ok even in our use case. We don't have a real > > use case as the one you describe. > > > > Can we know how you test it in this use case here? Can you test our > > patches of post_disable? > > > > Thanks > > Michael > > > > > > > > Example: > > > - Panel > > > - Bridge 1 > > > - Bridge 2 pre_enable_prev_first > > > - Bridge 3 > > > - Bridge 4 pre_enable_prev_first > > > - Bridge 5 pre_enable_prev_first > > > - Bridge 6 > > > - Encoder > > > > > > Thanks, > > > Jagan. > > Starting from my use case: > > # cat /sys/kernel/debug/dri/32e00000.lcdif/bridge_chains > encoder[36] > bridge[0] type: 16, ops: 0x0, OF: > /soc@0/bus@32c00000/dsi@32e10000:fsl,imx8mn-mipi-dsim > bridge[1] type: 16, ops: 0x8, OF: > /soc@0/bus@32c00000/dsi@32e10000/panel@0:sharp,ls068b3sx0 > > I developed a pass through MIPI-DSI bridge driver to try to test your case: > # cat /sys/kernel/debug/dri/32e00000.lcdif/bridge_chains > encoder[36] > bridge[0] type: 16, ops: 0x0, OF: > /soc@0/bus@32c00000/dsi@32e10000:fsl,imx8mn-mipi-dsim > bridge[1] type: 16, ops: 0x0, OF: /pt_mipi_dsi1:amarula,pt-mipi-dsi > bridge[2] type: 16, ops: 0x0, OF: /pt_mipi_dsi2:amarula,pt-mipi-dsi > bridge[3] type: 16, ops: 0x0, OF: /pt_mipi_dsi3:amarula,pt-mipi-dsi > bridge[4] type: 16, ops: 0x0, OF: /pt_mipi_dsi4:amarula,pt-mipi-dsi > bridge[5] type: 16, ops: 0x0, OF: /pt_mipi_dsi5:amarula,pt-mipi-dsi > bridge[6] type: 16, ops: 0x8, OF: /pt_mipi_dsi5/panel@0:sharp,ls068b3sx02 > > The pre_enable_prev_first flag is set through the > "amarula,pre_enable_prev_first" dts property I put > in my dts. > Your and my patches give the same results (result: OK) in both your > use case and mine. > But If I test my new "enlarged" use case: > > - Encoder > - bridge[0] (samsung-dsim) > - bridge[1] pre_enable_prev_first > - bridge[2] pre_enable_prev_first > - bridge[3] pre_enable_prev_first > - bridge[4] pre_enable_prev_first > - bridge[5] pre_enable_prev_first > - bridge[6] pre_enable_prev_first (Panel) > > the result is: > my patches: KO > your patch: OK > > So, I will remove my patches from the series. > > Can the driver I implemented to test the use cases (pass through > MIPI-DSI) be considered useful for testing these > bridge pipelines? > Does it make sense to send its patch? I don't think so, I have a similar test bench for chain of bridges. I will try to re-create the chain and update the result. Jagan.
© 2016 - 2025 Red Hat, Inc.