| Message ID | 20231205105341.4100896-3-dario.binacchi@amarulasolutions.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add displays support for bsh-smm-s2/pro boards | expand |
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? 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 > >
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
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.
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
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; }
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(-)