| Message ID | 20231108-tc358767-v2-0-25c5f70a2159@ideasonboard.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case | expand |
Hi Tomi, Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: > These two patches are needed to make tc358767 work in the > DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. > > I have tested this with TI AM654 EVM with a tc358767 add-on card > connected to a DP monitor. Just a question regarding the usage of this DSI-DP bridge. What is the state of the DSI lanes after the DSI host has been initialized, but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 on DSI at any time for accessing the AUX channel. Best regards, Alexander > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > --- > Changes in v2: > - Update the format negotiation patch as discussed in > https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0232@ti.com/ - > Link to v1: > https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard. > com > > --- > Aradhya Bhatia (1): > drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to > (e)DP > > Tomi Valkeinen (1): > drm/bridge: tc358767: Fix link properties discovery > > drivers/gpu/drm/bridge/tc358767.c | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > --- > base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 > change-id: 20231031-tc358767-58e3ebdf95f0 > > Best regards,
On 08/11/2023 14:45, Alexander Stein wrote: > Hi Tomi, > > Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >> These two patches are needed to make tc358767 work in the >> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. >> >> I have tested this with TI AM654 EVM with a tc358767 add-on card >> connected to a DP monitor. > > Just a question regarding the usage of this DSI-DP bridge. > What is the state of the DSI lanes after the DSI host has been initialized, > but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 on DSI > at any time for accessing the AUX channel. Good question. I don't know, as we use it in DPI mode (DPI-DP bridge). I guess the DSI state is undefined, as it might well be that the DSI host driver's (pre-)enable is the place where the DSI is powered up and initialized. So you think in DSI mode this might fail, as AUX (possibly) won't work when calling tc_get_edid()? We could add a check there, and skip the tc_get_display_props() if in DSI mode. But tc_get_edid() surely won't work then. It would be good if someone with a board where tc358767 is used in DSI mode could test this. But, of course, it'll only be testing that particular DSI host behavior... Tomi > > Best regards, > Alexander > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> --- >> Changes in v2: >> - Update the format negotiation patch as discussed in >> https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0232@ti.com/ - >> Link to v1: >> https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard. >> com >> >> --- >> Aradhya Bhatia (1): >> drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to >> (e)DP >> >> Tomi Valkeinen (1): >> drm/bridge: tc358767: Fix link properties discovery >> >> drivers/gpu/drm/bridge/tc358767.c | 32 ++++++++++++++++++++++++++++++++ >> 1 file changed, 32 insertions(+) >> --- >> base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 >> change-id: 20231031-tc358767-58e3ebdf95f0 >> >> Best regards, > >
Hi, On 08/11/2023 14:45, Alexander Stein wrote: > Hi Tomi, > > Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >> These two patches are needed to make tc358767 work in the >> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. >> >> I have tested this with TI AM654 EVM with a tc358767 add-on card >> connected to a DP monitor. > > Just a question regarding the usage of this DSI-DP bridge. > What is the state of the DSI lanes after the DSI host has been initialized, > but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 on DSI > at any time for accessing the AUX channel. We haven't received any test reports for the DSI-DP case... I was looking at the datasheet, and I wonder, why do you say the bridge requires DSI to be up for the AUX transactions? Tomi > Best regards, > Alexander > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> --- >> Changes in v2: >> - Update the format negotiation patch as discussed in >> https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0232@ti.com/ - >> Link to v1: >> https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard. >> com >> >> --- >> Aradhya Bhatia (1): >> drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to >> (e)DP >> >> Tomi Valkeinen (1): >> drm/bridge: tc358767: Fix link properties discovery >> >> drivers/gpu/drm/bridge/tc358767.c | 32 ++++++++++++++++++++++++++++++++ >> 1 file changed, 32 insertions(+) >> --- >> base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 >> change-id: 20231031-tc358767-58e3ebdf95f0 >> >> Best regards, > >
On 06/12/23 17:41, Tomi Valkeinen wrote: > Hi, > > On 08/11/2023 14:45, Alexander Stein wrote: >> Hi Tomi, >> >> Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >>> These two patches are needed to make tc358767 work in the >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. >>> >>> I have tested this with TI AM654 EVM with a tc358767 add-on card >>> connected to a DP monitor. >> >> Just a question regarding the usage of this DSI-DP bridge. >> What is the state of the DSI lanes after the DSI host has been >> initialized, >> but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 >> on DSI >> at any time for accessing the AUX channel. + Marek Marek, Alexander, A quick grep tells me that you have added devicetree for tc358767 in DSI to (e)DP mode on other platforms. Could you please test these patches and report if you find any issue? Regards Aradhya > > We haven't received any test reports for the DSI-DP case... I was > looking at the datasheet, and I wonder, why do you say the bridge > requires DSI to be up for the AUX transactions? > > Tomi > >> Best regards, >> Alexander >> >>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >>> --- >>> Changes in v2: >>> - Update the format negotiation patch as discussed in >>> https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0232@ti.com/ - >>> Link to v1: >>> https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard. >>> com >>> >>> --- >>> Aradhya Bhatia (1): >>> drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to >>> (e)DP >>> >>> Tomi Valkeinen (1): >>> drm/bridge: tc358767: Fix link properties discovery >>> >>> drivers/gpu/drm/bridge/tc358767.c | 32 >>> ++++++++++++++++++++++++++++++++ >>> 1 file changed, 32 insertions(+) >>> --- >>> base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 >>> change-id: 20231031-tc358767-58e3ebdf95f0 >>> >>> Best regards, >> >> >
Hi Tomi, Am Mittwoch, 6. Dezember 2023, 13:11:59 CET schrieb Tomi Valkeinen: > Hi, > > On 08/11/2023 14:45, Alexander Stein wrote: > > Hi Tomi, > > > > Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: > >> These two patches are needed to make tc358767 work in the > >> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. > >> > >> I have tested this with TI AM654 EVM with a tc358767 add-on card > >> connected to a DP monitor. > > > > Just a question regarding the usage of this DSI-DP bridge. > > What is the state of the DSI lanes after the DSI host has been > > initialized, > > but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 on > > DSI at any time for accessing the AUX channel. > > We haven't received any test reports for the DSI-DP case... I was > looking at the datasheet, and I wonder, why do you say the bridge > requires DSI to be up for the AUX transactions? Looking at Figure 4.20 (Power On Sequence) in the datasheet TC9595XBG (Rev 1.1 2021-06-23) you can see that RESX can be released (only) after DSI lanes went to LP-11 state. I got information, down from the support, that LP-11 must be up in order to use AUX channel. This also matches our observations, DSI hosts often enable LP-11 only in atomic_prepare. That's too late so we used some hacks to enable LP-11 right from the beginning just to get access to AUX channel. Best regards Alexander > > Tomi > > > Best regards, > > Alexander > > > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > >> --- > >> Changes in v2: > >> - Update the format negotiation patch as discussed in > >> https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0232@ti.com/ > >> - > >> Link to v1: > >> https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboar > >> d. > >> com > >> > >> --- > >> > >> Aradhya Bhatia (1): > >> drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to > >> > >> (e)DP > >> > >> Tomi Valkeinen (1): > >> drm/bridge: tc358767: Fix link properties discovery > >> > >> drivers/gpu/drm/bridge/tc358767.c | 32 ++++++++++++++++++++++++++++++++ > >> 1 file changed, 32 insertions(+) > >> > >> --- > >> base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 > >> change-id: 20231031-tc358767-58e3ebdf95f0 > >> > >> Best regards,
On 11.12.23 09:07, Aradhya Bhatia wrote: > > > On 06/12/23 17:41, Tomi Valkeinen wrote: >> Hi, >> >> On 08/11/2023 14:45, Alexander Stein wrote: >>> Hi Tomi, >>> >>> Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >>>> These two patches are needed to make tc358767 work in the >>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. >>>> >>>> I have tested this with TI AM654 EVM with a tc358767 add-on card >>>> connected to a DP monitor. >>> >>> Just a question regarding the usage of this DSI-DP bridge. >>> What is the state of the DSI lanes after the DSI host has been >>> initialized, >>> but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 >>> on DSI >>> at any time for accessing the AUX channel. > > + Marek > > Marek, Alexander, > > A quick grep tells me that you have added devicetree for tc358767 in DSI > to (e)DP mode on other platforms. Could you please test these patches > and report if you find any issue? Is this the last blocker to move forward with these fixes? I'd really like to see them finally merged. Thanks, Jan
Hi everyone, Am Donnerstag, 15. Februar 2024, 09:53:54 CET schrieb Jan Kiszka: > On 11.12.23 09:07, Aradhya Bhatia wrote: > > On 06/12/23 17:41, Tomi Valkeinen wrote: > >> Hi, > >> > >> On 08/11/2023 14:45, Alexander Stein wrote: > >>> Hi Tomi, > >>> > >>> Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: > >>>> These two patches are needed to make tc358767 work in the > >>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP > >>>> connector. > >>>> > >>>> I have tested this with TI AM654 EVM with a tc358767 add-on card > >>>> connected to a DP monitor. > >>> > >>> Just a question regarding the usage of this DSI-DP bridge. > >>> What is the state of the DSI lanes after the DSI host has been > >>> initialized, > >>> but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 > >>> on DSI > >>> at any time for accessing the AUX channel. > > > > + Marek > > > > Marek, Alexander, > > > > A quick grep tells me that you have added devicetree for tc358767 in DSI > > to (e)DP mode on other platforms. Could you please test these patches > > and report if you find any issue? Sorry, I can't provide any feedback here. I've yet to setup the DSI-DP correctly. Best regards, Alexander > Is this the last blocker to move forward with these fixes? I'd really > like to see them finally merged. > > Thanks, > Jan
On 15/02/2024 11:03, Alexander Stein wrote: > Hi everyone, > > Am Donnerstag, 15. Februar 2024, 09:53:54 CET schrieb Jan Kiszka: >> On 11.12.23 09:07, Aradhya Bhatia wrote: >>> On 06/12/23 17:41, Tomi Valkeinen wrote: >>>> Hi, >>>> >>>> On 08/11/2023 14:45, Alexander Stein wrote: >>>>> Hi Tomi, >>>>> >>>>> Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >>>>>> These two patches are needed to make tc358767 work in the >>>>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP >>>>>> connector. >>>>>> >>>>>> I have tested this with TI AM654 EVM with a tc358767 add-on card >>>>>> connected to a DP monitor. >>>>> >>>>> Just a question regarding the usage of this DSI-DP bridge. >>>>> What is the state of the DSI lanes after the DSI host has been >>>>> initialized, >>>>> but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 >>>>> on DSI >>>>> at any time for accessing the AUX channel. >>> >>> + Marek >>> >>> Marek, Alexander, >>> >>> A quick grep tells me that you have added devicetree for tc358767 in DSI >>> to (e)DP mode on other platforms. Could you please test these patches >>> and report if you find any issue? > > Sorry, I can't provide any feedback here. I've yet to setup the DSI-DP > correctly. Ok. Does anyone have a worry that these patches make the situation worse for the DSI case than it was before? Afaics, if the DSI lanes are not set up early enough by the DSI host, the driver would break with and without these patches. These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so I'd like to merge these unless these cause a regression with the DSI case. Tomi
On 2/16/24 10:10, Tomi Valkeinen wrote: > On 15/02/2024 11:03, Alexander Stein wrote: >> Hi everyone, >> >> Am Donnerstag, 15. Februar 2024, 09:53:54 CET schrieb Jan Kiszka: >>> On 11.12.23 09:07, Aradhya Bhatia wrote: >>>> On 06/12/23 17:41, Tomi Valkeinen wrote: >>>>> Hi, >>>>> >>>>> On 08/11/2023 14:45, Alexander Stein wrote: >>>>>> Hi Tomi, >>>>>> >>>>>> Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >>>>>>> These two patches are needed to make tc358767 work in the >>>>>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP >>>>>>> connector. >>>>>>> >>>>>>> I have tested this with TI AM654 EVM with a tc358767 add-on card >>>>>>> connected to a DP monitor. >>>>>> >>>>>> Just a question regarding the usage of this DSI-DP bridge. >>>>>> What is the state of the DSI lanes after the DSI host has been >>>>>> initialized, >>>>>> but before calling atomic_pre_enable? AFAIK this bridge requires >>>>>> LP-11 >>>>>> on DSI >>>>>> at any time for accessing the AUX channel. >>>> >>>> + Marek >>>> >>>> Marek, Alexander, >>>> >>>> A quick grep tells me that you have added devicetree for tc358767 in >>>> DSI >>>> to (e)DP mode on other platforms. Could you please test these patches >>>> and report if you find any issue? >> >> Sorry, I can't provide any feedback here. I've yet to setup the DSI-DP >> correctly. > > Ok. Does anyone have a worry that these patches make the situation worse > for the DSI case than it was before? Afaics, if the DSI lanes are not > set up early enough by the DSI host, the driver would break with and > without these patches. > > These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so > I'd like to merge these unless these cause a regression with the DSI case. 1/2 looks good to me, go ahead and apply .
On 16.02.24 15:57, Marek Vasut wrote: > On 2/16/24 10:10, Tomi Valkeinen wrote: >> On 15/02/2024 11:03, Alexander Stein wrote: >>> Hi everyone, >>> >>> Am Donnerstag, 15. Februar 2024, 09:53:54 CET schrieb Jan Kiszka: >>>> On 11.12.23 09:07, Aradhya Bhatia wrote: >>>>> On 06/12/23 17:41, Tomi Valkeinen wrote: >>>>>> Hi, >>>>>> >>>>>> On 08/11/2023 14:45, Alexander Stein wrote: >>>>>>> Hi Tomi, >>>>>>> >>>>>>> Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen: >>>>>>>> These two patches are needed to make tc358767 work in the >>>>>>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP >>>>>>>> connector. >>>>>>>> >>>>>>>> I have tested this with TI AM654 EVM with a tc358767 add-on card >>>>>>>> connected to a DP monitor. >>>>>>> >>>>>>> Just a question regarding the usage of this DSI-DP bridge. >>>>>>> What is the state of the DSI lanes after the DSI host has been >>>>>>> initialized, >>>>>>> but before calling atomic_pre_enable? AFAIK this bridge requires >>>>>>> LP-11 >>>>>>> on DSI >>>>>>> at any time for accessing the AUX channel. >>>>> >>>>> + Marek >>>>> >>>>> Marek, Alexander, >>>>> >>>>> A quick grep tells me that you have added devicetree for tc358767 >>>>> in DSI >>>>> to (e)DP mode on other platforms. Could you please test these patches >>>>> and report if you find any issue? >>> >>> Sorry, I can't provide any feedback here. I've yet to setup the DSI-DP >>> correctly. >> >> Ok. Does anyone have a worry that these patches make the situation >> worse for the DSI case than it was before? Afaics, if the DSI lanes >> are not set up early enough by the DSI host, the driver would break >> with and without these patches. >> >> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so >> I'd like to merge these unless these cause a regression with the DSI >> case. > > 1/2 looks good to me, go ahead and apply . My local patches still apply on top of 6.10-rc4, so I don't think this ever happened. What's still holding up this long-pending fix (at least for our devices)? Jan
On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: > On 16.02.24 15:57, Marek Vasut wrote: > > On 2/16/24 10:10, Tomi Valkeinen wrote: > >> Ok. Does anyone have a worry that these patches make the situation > >> worse for the DSI case than it was before? Afaics, if the DSI lanes > >> are not set up early enough by the DSI host, the driver would break > >> with and without these patches. > >> > >> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so > >> I'd like to merge these unless these cause a regression with the DSI > >> case. > > > > 1/2 looks good to me, go ahead and apply . > > My local patches still apply on top of 6.10-rc4, so I don't think this > ever happened. What's still holding up this long-pending fix (at least > for our devices)? Neither of the patches contains Fixes tags. If the first patch fixes an issue in previous kernels, please consider following the stable process. If we are unsure about the second patch, please send the first patch separately, adding proper tags.
On 17-Jun-24 13:41, Dmitry Baryshkov wrote: > On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: >> On 16.02.24 15:57, Marek Vasut wrote: >>> On 2/16/24 10:10, Tomi Valkeinen wrote: >>>> Ok. Does anyone have a worry that these patches make the situation >>>> worse for the DSI case than it was before? Afaics, if the DSI lanes >>>> are not set up early enough by the DSI host, the driver would break >>>> with and without these patches. >>>> >>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so >>>> I'd like to merge these unless these cause a regression with the DSI >>>> case. >>> >>> 1/2 looks good to me, go ahead and apply . Isn't there any way for the second patch to move forward as well though? The bridge device (under DPI to (e)DP mode) cannot really work without it, and the patches have been pending idle for a long time. =) >> >> My local patches still apply on top of 6.10-rc4, so I don't think this >> ever happened. What's still holding up this long-pending fix (at least >> for our devices)? > > Neither of the patches contains Fixes tags. If the first patch fixes an > issue in previous kernels, please consider following the stable process. > > If we are unsure about the second patch, please send the first patch > separately, adding proper tags. > Thanks Dmitry! I can send the patches again with the required fixes tags (or just patch-1 if we cannot do anything about patch-2).
On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: > > > On 17-Jun-24 13:41, Dmitry Baryshkov wrote: > > On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: > >> On 16.02.24 15:57, Marek Vasut wrote: > >>> On 2/16/24 10:10, Tomi Valkeinen wrote: > >>>> Ok. Does anyone have a worry that these patches make the situation > >>>> worse for the DSI case than it was before? Afaics, if the DSI lanes > >>>> are not set up early enough by the DSI host, the driver would break > >>>> with and without these patches. > >>>> > >>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so > >>>> I'd like to merge these unless these cause a regression with the DSI > >>>> case. > >>> > >>> 1/2 looks good to me, go ahead and apply . > > Isn't there any way for the second patch to move forward as well though? > The bridge device (under DPI to (e)DP mode) cannot really work without > it, and the patches have been pending idle for a long time. =) > > >> > >> My local patches still apply on top of 6.10-rc4, so I don't think this > >> ever happened. What's still holding up this long-pending fix (at least > >> for our devices)? > > > > Neither of the patches contains Fixes tags. If the first patch fixes an > > issue in previous kernels, please consider following the stable process. > > > > If we are unsure about the second patch, please send the first patch > > separately, adding proper tags. > > > > Thanks Dmitry! I can send the patches again with the required fixes > tags (or just patch-1 if we cannot do anything about patch-2). The problem with the second patch is that it get mixed reviews. I can ack the first patch, but for the second one I'd need a confirmation from somebody else. I'll go on and apply the first patch later today.
On 22/06/24 17:49, Dmitry Baryshkov wrote: > On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: >> >> >> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: >>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: >>>> On 16.02.24 15:57, Marek Vasut wrote: >>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: >>>>>> Ok. Does anyone have a worry that these patches make the situation >>>>>> worse for the DSI case than it was before? Afaics, if the DSI lanes >>>>>> are not set up early enough by the DSI host, the driver would break >>>>>> with and without these patches. >>>>>> >>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so >>>>>> I'd like to merge these unless these cause a regression with the DSI >>>>>> case. >>>>> >>>>> 1/2 looks good to me, go ahead and apply . >> >> Isn't there any way for the second patch to move forward as well though? >> The bridge device (under DPI to (e)DP mode) cannot really work without >> it, and the patches have been pending idle for a long time. =) >> >>>> >>>> My local patches still apply on top of 6.10-rc4, so I don't think this >>>> ever happened. What's still holding up this long-pending fix (at least >>>> for our devices)? >>> >>> Neither of the patches contains Fixes tags. If the first patch fixes an >>> issue in previous kernels, please consider following the stable process. >>> >>> If we are unsure about the second patch, please send the first patch >>> separately, adding proper tags. >>> >> >> Thanks Dmitry! I can send the patches again with the required fixes >> tags (or just patch-1 if we cannot do anything about patch-2). > > The problem with the second patch is that it get mixed reviews. I can > ack the first patch, but for the second one I'd need a confirmation from > somebody else. I'll go on and apply the first patch later today. > Thanks Dmitry! However, would it be okay if I instead add another patch that makes 2 versions of the "tc_edp_bridge_funcs", say "tc_dpi_edp_bridge_funcs" and "tc_dsi_edp_bridge_funcs", that have all the same function hooks except for the .edid_read()? The dsi edid_read() will remain the same, and Tomi's patch - patch 2/2 - will only fix the dpi version of the edid_read()? The bridge already has the capability to distinguish a DSI input from a DPI input. This can be leveraged to decide which set of functions need to be used without any major changes. Regards Aradhya
On Mon, Jun 24, 2024 at 03:07:10PM GMT, Aradhya Bhatia wrote: > > > On 22/06/24 17:49, Dmitry Baryshkov wrote: > > On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: > >> > >> > >> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: > >>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: > >>>> On 16.02.24 15:57, Marek Vasut wrote: > >>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: > >>>>>> Ok. Does anyone have a worry that these patches make the situation > >>>>>> worse for the DSI case than it was before? Afaics, if the DSI lanes > >>>>>> are not set up early enough by the DSI host, the driver would break > >>>>>> with and without these patches. > >>>>>> > >>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so > >>>>>> I'd like to merge these unless these cause a regression with the DSI > >>>>>> case. > >>>>> > >>>>> 1/2 looks good to me, go ahead and apply . > >> > >> Isn't there any way for the second patch to move forward as well though? > >> The bridge device (under DPI to (e)DP mode) cannot really work without > >> it, and the patches have been pending idle for a long time. =) > >> > >>>> > >>>> My local patches still apply on top of 6.10-rc4, so I don't think this > >>>> ever happened. What's still holding up this long-pending fix (at least > >>>> for our devices)? > >>> > >>> Neither of the patches contains Fixes tags. If the first patch fixes an > >>> issue in previous kernels, please consider following the stable process. > >>> > >>> If we are unsure about the second patch, please send the first patch > >>> separately, adding proper tags. > >>> > >> > >> Thanks Dmitry! I can send the patches again with the required fixes > >> tags (or just patch-1 if we cannot do anything about patch-2). > > > > The problem with the second patch is that it get mixed reviews. I can > > ack the first patch, but for the second one I'd need a confirmation from > > somebody else. I'll go on and apply the first patch later today. > > > > Thanks Dmitry! > > However, would it be okay if I instead add another patch that makes 2 > versions of the "tc_edp_bridge_funcs", say "tc_dpi_edp_bridge_funcs" and > "tc_dsi_edp_bridge_funcs", that have all the same function hooks except > for the .edid_read()? > > The dsi edid_read() will remain the same, and Tomi's patch - patch 2/2 - > will only fix the dpi version of the edid_read()? > > The bridge already has the capability to distinguish a DSI input from a > DPI input. This can be leveraged to decide which set of functions need > to be used without any major changes. I'd prefer if somebody with the DSI setup can ack / test the second patch.
Hi, Am Montag, 24. Juni 2024, 11:49:04 CEST schrieb Dmitry Baryshkov: > On Mon, Jun 24, 2024 at 03:07:10PM GMT, Aradhya Bhatia wrote: > > > > > > On 22/06/24 17:49, Dmitry Baryshkov wrote: > > > On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: > > >> > > >> > > >> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: > > >>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: > > >>>> On 16.02.24 15:57, Marek Vasut wrote: > > >>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: > > >>>>>> Ok. Does anyone have a worry that these patches make the situation > > >>>>>> worse for the DSI case than it was before? Afaics, if the DSI lanes > > >>>>>> are not set up early enough by the DSI host, the driver would break > > >>>>>> with and without these patches. > > >>>>>> > > >>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so > > >>>>>> I'd like to merge these unless these cause a regression with the DSI > > >>>>>> case. > > >>>>> > > >>>>> 1/2 looks good to me, go ahead and apply . > > >> > > >> Isn't there any way for the second patch to move forward as well though? > > >> The bridge device (under DPI to (e)DP mode) cannot really work without > > >> it, and the patches have been pending idle for a long time. =) > > >> > > >>>> > > >>>> My local patches still apply on top of 6.10-rc4, so I don't think this > > >>>> ever happened. What's still holding up this long-pending fix (at least > > >>>> for our devices)? > > >>> > > >>> Neither of the patches contains Fixes tags. If the first patch fixes an > > >>> issue in previous kernels, please consider following the stable process. > > >>> > > >>> If we are unsure about the second patch, please send the first patch > > >>> separately, adding proper tags. > > >>> > > >> > > >> Thanks Dmitry! I can send the patches again with the required fixes > > >> tags (or just patch-1 if we cannot do anything about patch-2). > > > > > > The problem with the second patch is that it get mixed reviews. I can > > > ack the first patch, but for the second one I'd need a confirmation from > > > somebody else. I'll go on and apply the first patch later today. > > > > > > > Thanks Dmitry! > > > > However, would it be okay if I instead add another patch that makes 2 > > versions of the "tc_edp_bridge_funcs", say "tc_dpi_edp_bridge_funcs" and > > "tc_dsi_edp_bridge_funcs", that have all the same function hooks except > > for the .edid_read()? > > > > The dsi edid_read() will remain the same, and Tomi's patch - patch 2/2 - > > will only fix the dpi version of the edid_read()? > > > > The bridge already has the capability to distinguish a DSI input from a > > DPI input. This can be leveraged to decide which set of functions need > > to be used without any major changes. > > I'd prefer if somebody with the DSI setup can ack / test the second > patch. > > Now that my DSI-DP setup works apparently without issue I could test patch 2. Since my setup does not use DRM_BRIDGE_ATTACH_NO_CONNECTOR (running on drivers/gpu/drm/mxsfb/lcdif_drv.c), I can only say there is no regression. Best regards, Alexander
On Mon, 24 Jun 2024 at 13:07, Alexander Stein <alexander.stein@ew.tq-group.com> wrote: > > Hi, > > Am Montag, 24. Juni 2024, 11:49:04 CEST schrieb Dmitry Baryshkov: > > On Mon, Jun 24, 2024 at 03:07:10PM GMT, Aradhya Bhatia wrote: > > > > > > > > > On 22/06/24 17:49, Dmitry Baryshkov wrote: > > > > On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: > > > >> > > > >> > > > >> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: > > > >>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: > > > >>>> On 16.02.24 15:57, Marek Vasut wrote: > > > >>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: > > > >>>>>> Ok. Does anyone have a worry that these patches make the situation > > > >>>>>> worse for the DSI case than it was before? Afaics, if the DSI lanes > > > >>>>>> are not set up early enough by the DSI host, the driver would break > > > >>>>>> with and without these patches. > > > >>>>>> > > > >>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so > > > >>>>>> I'd like to merge these unless these cause a regression with the DSI > > > >>>>>> case. > > > >>>>> > > > >>>>> 1/2 looks good to me, go ahead and apply . > > > >> > > > >> Isn't there any way for the second patch to move forward as well though? > > > >> The bridge device (under DPI to (e)DP mode) cannot really work without > > > >> it, and the patches have been pending idle for a long time. =) > > > >> > > > >>>> > > > >>>> My local patches still apply on top of 6.10-rc4, so I don't think this > > > >>>> ever happened. What's still holding up this long-pending fix (at least > > > >>>> for our devices)? > > > >>> > > > >>> Neither of the patches contains Fixes tags. If the first patch fixes an > > > >>> issue in previous kernels, please consider following the stable process. > > > >>> > > > >>> If we are unsure about the second patch, please send the first patch > > > >>> separately, adding proper tags. > > > >>> > > > >> > > > >> Thanks Dmitry! I can send the patches again with the required fixes > > > >> tags (or just patch-1 if we cannot do anything about patch-2). > > > > > > > > The problem with the second patch is that it get mixed reviews. I can > > > > ack the first patch, but for the second one I'd need a confirmation from > > > > somebody else. I'll go on and apply the first patch later today. > > > > > > > > > > Thanks Dmitry! > > > > > > However, would it be okay if I instead add another patch that makes 2 > > > versions of the "tc_edp_bridge_funcs", say "tc_dpi_edp_bridge_funcs" and > > > "tc_dsi_edp_bridge_funcs", that have all the same function hooks except > > > for the .edid_read()? > > > > > > The dsi edid_read() will remain the same, and Tomi's patch - patch 2/2 - > > > will only fix the dpi version of the edid_read()? > > > > > > The bridge already has the capability to distinguish a DSI input from a > > > DPI input. This can be leveraged to decide which set of functions need > > > to be used without any major changes. > > > > I'd prefer if somebody with the DSI setup can ack / test the second > > patch. > > > > > > Now that my DSI-DP setup works apparently without issue I could test patch 2. > Since my setup does not use DRM_BRIDGE_ATTACH_NO_CONNECTOR (running on > drivers/gpu/drm/mxsfb/lcdif_drv.c), I can only say > there is no regression. Let me send a (non-tested) patch, switching to drm_bridge_connector, then you can probably test both of them
On 24.06.24 12:17, Dmitry Baryshkov wrote: > On Mon, 24 Jun 2024 at 13:07, Alexander Stein > <alexander.stein@ew.tq-group.com> wrote: >> >> Hi, >> >> Am Montag, 24. Juni 2024, 11:49:04 CEST schrieb Dmitry Baryshkov: >>> On Mon, Jun 24, 2024 at 03:07:10PM GMT, Aradhya Bhatia wrote: >>>> >>>> >>>> On 22/06/24 17:49, Dmitry Baryshkov wrote: >>>>> On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: >>>>>> >>>>>> >>>>>> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: >>>>>>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: >>>>>>>> On 16.02.24 15:57, Marek Vasut wrote: >>>>>>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: >>>>>>>>>> Ok. Does anyone have a worry that these patches make the situation >>>>>>>>>> worse for the DSI case than it was before? Afaics, if the DSI lanes >>>>>>>>>> are not set up early enough by the DSI host, the driver would break >>>>>>>>>> with and without these patches. >>>>>>>>>> >>>>>>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so >>>>>>>>>> I'd like to merge these unless these cause a regression with the DSI >>>>>>>>>> case. >>>>>>>>> >>>>>>>>> 1/2 looks good to me, go ahead and apply . >>>>>> >>>>>> Isn't there any way for the second patch to move forward as well though? >>>>>> The bridge device (under DPI to (e)DP mode) cannot really work without >>>>>> it, and the patches have been pending idle for a long time. =) >>>>>> >>>>>>>> >>>>>>>> My local patches still apply on top of 6.10-rc4, so I don't think this >>>>>>>> ever happened. What's still holding up this long-pending fix (at least >>>>>>>> for our devices)? >>>>>>> >>>>>>> Neither of the patches contains Fixes tags. If the first patch fixes an >>>>>>> issue in previous kernels, please consider following the stable process. >>>>>>> >>>>>>> If we are unsure about the second patch, please send the first patch >>>>>>> separately, adding proper tags. >>>>>>> >>>>>> >>>>>> Thanks Dmitry! I can send the patches again with the required fixes >>>>>> tags (or just patch-1 if we cannot do anything about patch-2). >>>>> >>>>> The problem with the second patch is that it get mixed reviews. I can >>>>> ack the first patch, but for the second one I'd need a confirmation from >>>>> somebody else. I'll go on and apply the first patch later today. >>>>> >>>> >>>> Thanks Dmitry! >>>> >>>> However, would it be okay if I instead add another patch that makes 2 >>>> versions of the "tc_edp_bridge_funcs", say "tc_dpi_edp_bridge_funcs" and >>>> "tc_dsi_edp_bridge_funcs", that have all the same function hooks except >>>> for the .edid_read()? >>>> >>>> The dsi edid_read() will remain the same, and Tomi's patch - patch 2/2 - >>>> will only fix the dpi version of the edid_read()? >>>> >>>> The bridge already has the capability to distinguish a DSI input from a >>>> DPI input. This can be leveraged to decide which set of functions need >>>> to be used without any major changes. >>> >>> I'd prefer if somebody with the DSI setup can ack / test the second >>> patch. >>> >>> >> >> Now that my DSI-DP setup works apparently without issue I could test patch 2. >> Since my setup does not use DRM_BRIDGE_ATTACH_NO_CONNECTOR (running on >> drivers/gpu/drm/mxsfb/lcdif_drv.c), I can only say >> there is no regression. > > Let me send a (non-tested) patch, switching to drm_bridge_connector, > then you can probably test both of them > I suppose [1] was that follow-up, just not leading to success, right? Now, what's next? I'd love to see the regression we have for the IOT2050 devices finally fixed, even if it now only requires a short downstream patch. Jan [1] https://lore.kernel.org/dri-devel/20240624-mxc-lcdif-bridge-attach-v1-1-37e8c5d5d934@linaro.org/
On 26/08/2024 22:35, Jan Kiszka wrote: > On 24.06.24 12:17, Dmitry Baryshkov wrote: >> On Mon, 24 Jun 2024 at 13:07, Alexander Stein >> <alexander.stein@ew.tq-group.com> wrote: >>> >>> Hi, >>> >>> Am Montag, 24. Juni 2024, 11:49:04 CEST schrieb Dmitry Baryshkov: >>>> On Mon, Jun 24, 2024 at 03:07:10PM GMT, Aradhya Bhatia wrote: >>>>> >>>>> >>>>> On 22/06/24 17:49, Dmitry Baryshkov wrote: >>>>>> On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: >>>>>>> >>>>>>> >>>>>>> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: >>>>>>>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: >>>>>>>>> On 16.02.24 15:57, Marek Vasut wrote: >>>>>>>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: >>>>>>>>>>> Ok. Does anyone have a worry that these patches make the situation >>>>>>>>>>> worse for the DSI case than it was before? Afaics, if the DSI lanes >>>>>>>>>>> are not set up early enough by the DSI host, the driver would break >>>>>>>>>>> with and without these patches. >>>>>>>>>>> >>>>>>>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR and DPI, so >>>>>>>>>>> I'd like to merge these unless these cause a regression with the DSI >>>>>>>>>>> case. >>>>>>>>>> >>>>>>>>>> 1/2 looks good to me, go ahead and apply . >>>>>>> >>>>>>> Isn't there any way for the second patch to move forward as well though? >>>>>>> The bridge device (under DPI to (e)DP mode) cannot really work without >>>>>>> it, and the patches have been pending idle for a long time. =) >>>>>>> >>>>>>>>> >>>>>>>>> My local patches still apply on top of 6.10-rc4, so I don't think this >>>>>>>>> ever happened. What's still holding up this long-pending fix (at least >>>>>>>>> for our devices)? >>>>>>>> >>>>>>>> Neither of the patches contains Fixes tags. If the first patch fixes an >>>>>>>> issue in previous kernels, please consider following the stable process. >>>>>>>> >>>>>>>> If we are unsure about the second patch, please send the first patch >>>>>>>> separately, adding proper tags. >>>>>>>> >>>>>>> >>>>>>> Thanks Dmitry! I can send the patches again with the required fixes >>>>>>> tags (or just patch-1 if we cannot do anything about patch-2). >>>>>> >>>>>> The problem with the second patch is that it get mixed reviews. I can >>>>>> ack the first patch, but for the second one I'd need a confirmation from >>>>>> somebody else. I'll go on and apply the first patch later today. >>>>>> >>>>> >>>>> Thanks Dmitry! >>>>> >>>>> However, would it be okay if I instead add another patch that makes 2 >>>>> versions of the "tc_edp_bridge_funcs", say "tc_dpi_edp_bridge_funcs" and >>>>> "tc_dsi_edp_bridge_funcs", that have all the same function hooks except >>>>> for the .edid_read()? >>>>> >>>>> The dsi edid_read() will remain the same, and Tomi's patch - patch 2/2 - >>>>> will only fix the dpi version of the edid_read()? >>>>> >>>>> The bridge already has the capability to distinguish a DSI input from a >>>>> DPI input. This can be leveraged to decide which set of functions need >>>>> to be used without any major changes. >>>> >>>> I'd prefer if somebody with the DSI setup can ack / test the second >>>> patch. >>>> >>>> >>> >>> Now that my DSI-DP setup works apparently without issue I could test patch 2. >>> Since my setup does not use DRM_BRIDGE_ATTACH_NO_CONNECTOR (running on >>> drivers/gpu/drm/mxsfb/lcdif_drv.c), I can only say >>> there is no regression. >> >> Let me send a (non-tested) patch, switching to drm_bridge_connector, >> then you can probably test both of them >> > > I suppose [1] was that follow-up, just not leading to success, right? > > Now, what's next? I'd love to see the regression we have for the IOT2050 > devices finally fixed, even if it now only requires a short downstream > patch. > > Jan > > [1] https://lore.kernel.org/dri-devel/20240624-mxc-lcdif-bridge-attach-v1-1-37e8c5d5d934@linaro.org/ I have to say I don't remember the details for this anymore, but half a year ago I said: > Afaics, if the DSI lanes are not set up early enough by the DSI host, the driver would break with and without these patches. I'm not sure if that is correct or not. But if it is, then, afaiu, this (the second patch): - Fixes the issue for the DPI-DP use case - Doesn't cause issues for the DSI-DP use case without DRM_BRIDGE_ATTACH_NO_CONNECTOR (as per Alexander's test) - Shouldn't cause (new) issues for the DSI-DP use case with DRM_BRIDGE_ATTACH_NO_CONNECTOR (as per my code review and guessing...) The third point is somewhat concerning, of course, but do we have any setup with DSI-DP and DRM_BRIDGE_ATTACH_NO_CONNECTOR that works now? If not, maybe we can just ignore the possible issues, as this fixes problems on a setup we do have. Tomi
On 28.08.24 15:32, Tomi Valkeinen wrote: > On 26/08/2024 22:35, Jan Kiszka wrote: >> On 24.06.24 12:17, Dmitry Baryshkov wrote: >>> On Mon, 24 Jun 2024 at 13:07, Alexander Stein >>> <alexander.stein@ew.tq-group.com> wrote: >>>> >>>> Hi, >>>> >>>> Am Montag, 24. Juni 2024, 11:49:04 CEST schrieb Dmitry Baryshkov: >>>>> On Mon, Jun 24, 2024 at 03:07:10PM GMT, Aradhya Bhatia wrote: >>>>>> >>>>>> >>>>>> On 22/06/24 17:49, Dmitry Baryshkov wrote: >>>>>>> On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: >>>>>>>>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: >>>>>>>>>> On 16.02.24 15:57, Marek Vasut wrote: >>>>>>>>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: >>>>>>>>>>>> Ok. Does anyone have a worry that these patches make the >>>>>>>>>>>> situation >>>>>>>>>>>> worse for the DSI case than it was before? Afaics, if the >>>>>>>>>>>> DSI lanes >>>>>>>>>>>> are not set up early enough by the DSI host, the driver >>>>>>>>>>>> would break >>>>>>>>>>>> with and without these patches. >>>>>>>>>>>> >>>>>>>>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR >>>>>>>>>>>> and DPI, so >>>>>>>>>>>> I'd like to merge these unless these cause a regression with >>>>>>>>>>>> the DSI >>>>>>>>>>>> case. >>>>>>>>>>> >>>>>>>>>>> 1/2 looks good to me, go ahead and apply . >>>>>>>> >>>>>>>> Isn't there any way for the second patch to move forward as well >>>>>>>> though? >>>>>>>> The bridge device (under DPI to (e)DP mode) cannot really work >>>>>>>> without >>>>>>>> it, and the patches have been pending idle for a long time. =) >>>>>>>> >>>>>>>>>> >>>>>>>>>> My local patches still apply on top of 6.10-rc4, so I don't >>>>>>>>>> think this >>>>>>>>>> ever happened. What's still holding up this long-pending fix >>>>>>>>>> (at least >>>>>>>>>> for our devices)? >>>>>>>>> >>>>>>>>> Neither of the patches contains Fixes tags. If the first patch >>>>>>>>> fixes an >>>>>>>>> issue in previous kernels, please consider following the stable >>>>>>>>> process. >>>>>>>>> >>>>>>>>> If we are unsure about the second patch, please send the first >>>>>>>>> patch >>>>>>>>> separately, adding proper tags. >>>>>>>>> >>>>>>>> >>>>>>>> Thanks Dmitry! I can send the patches again with the required fixes >>>>>>>> tags (or just patch-1 if we cannot do anything about patch-2). >>>>>>> >>>>>>> The problem with the second patch is that it get mixed reviews. I >>>>>>> can >>>>>>> ack the first patch, but for the second one I'd need a >>>>>>> confirmation from >>>>>>> somebody else. I'll go on and apply the first patch later today. >>>>>>> >>>>>> >>>>>> Thanks Dmitry! >>>>>> >>>>>> However, would it be okay if I instead add another patch that makes 2 >>>>>> versions of the "tc_edp_bridge_funcs", say >>>>>> "tc_dpi_edp_bridge_funcs" and >>>>>> "tc_dsi_edp_bridge_funcs", that have all the same function hooks >>>>>> except >>>>>> for the .edid_read()? >>>>>> >>>>>> The dsi edid_read() will remain the same, and Tomi's patch - patch >>>>>> 2/2 - >>>>>> will only fix the dpi version of the edid_read()? >>>>>> >>>>>> The bridge already has the capability to distinguish a DSI input >>>>>> from a >>>>>> DPI input. This can be leveraged to decide which set of functions >>>>>> need >>>>>> to be used without any major changes. >>>>> >>>>> I'd prefer if somebody with the DSI setup can ack / test the second >>>>> patch. >>>>> >>>>> >>>> >>>> Now that my DSI-DP setup works apparently without issue I could test >>>> patch 2. >>>> Since my setup does not use DRM_BRIDGE_ATTACH_NO_CONNECTOR (running on >>>> drivers/gpu/drm/mxsfb/lcdif_drv.c), I can only say >>>> there is no regression. >>> >>> Let me send a (non-tested) patch, switching to drm_bridge_connector, >>> then you can probably test both of them >>> >> >> I suppose [1] was that follow-up, just not leading to success, right? >> >> Now, what's next? I'd love to see the regression we have for the IOT2050 >> devices finally fixed, even if it now only requires a short downstream >> patch. >> >> Jan >> >> [1] >> https://lore.kernel.org/dri-devel/20240624-mxc-lcdif-bridge-attach-v1-1-37e8c5d5d934@linaro.org/ > > I have to say I don't remember the details for this anymore, but half a > year ago I said: > >> Afaics, if the DSI lanes are not set up early enough by the DSI host, >> the driver would break with and without these patches. > > I'm not sure if that is correct or not. But if it is, then, afaiu, this > (the second patch): > > - Fixes the issue for the DPI-DP use case > > - Doesn't cause issues for the DSI-DP use case without > DRM_BRIDGE_ATTACH_NO_CONNECTOR (as per Alexander's test) > > - Shouldn't cause (new) issues for the DSI-DP use case with > DRM_BRIDGE_ATTACH_NO_CONNECTOR (as per my code review and guessing...) > > The third point is somewhat concerning, of course, but do we have any > setup with DSI-DP and DRM_BRIDGE_ATTACH_NO_CONNECTOR that works now? If > not, maybe we can just ignore the possible issues, as this fixes > problems on a setup we do have. > As Dmitry asked me during Plumbers to revalidate if our setup still needs patch 2, I just did that over 6.11.0-next-20240923 (where patch 1 is now included). No surprise, it is still needed for our iot2050 device series, otherwise the display remains black. Jan
On Mon, Sep 23, 2024 at 09:42:27AM GMT, Jan Kiszka wrote: > On 28.08.24 15:32, Tomi Valkeinen wrote: > > On 26/08/2024 22:35, Jan Kiszka wrote: > >> On 24.06.24 12:17, Dmitry Baryshkov wrote: > >>> On Mon, 24 Jun 2024 at 13:07, Alexander Stein > >>> <alexander.stein@ew.tq-group.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Am Montag, 24. Juni 2024, 11:49:04 CEST schrieb Dmitry Baryshkov: > >>>>> On Mon, Jun 24, 2024 at 03:07:10PM GMT, Aradhya Bhatia wrote: > >>>>>> > >>>>>> > >>>>>> On 22/06/24 17:49, Dmitry Baryshkov wrote: > >>>>>>> On Sat, Jun 22, 2024 at 05:16:58PM GMT, Aradhya Bhatia wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> On 17-Jun-24 13:41, Dmitry Baryshkov wrote: > >>>>>>>>> On Mon, Jun 17, 2024 at 07:40:32AM GMT, Jan Kiszka wrote: > >>>>>>>>>> On 16.02.24 15:57, Marek Vasut wrote: > >>>>>>>>>>> On 2/16/24 10:10, Tomi Valkeinen wrote: > >>>>>>>>>>>> Ok. Does anyone have a worry that these patches make the > >>>>>>>>>>>> situation > >>>>>>>>>>>> worse for the DSI case than it was before? Afaics, if the > >>>>>>>>>>>> DSI lanes > >>>>>>>>>>>> are not set up early enough by the DSI host, the driver > >>>>>>>>>>>> would break > >>>>>>>>>>>> with and without these patches. > >>>>>>>>>>>> > >>>>>>>>>>>> These do fix the driver for DRM_BRIDGE_ATTACH_NO_CONNECTOR > >>>>>>>>>>>> and DPI, so > >>>>>>>>>>>> I'd like to merge these unless these cause a regression with > >>>>>>>>>>>> the DSI > >>>>>>>>>>>> case. > >>>>>>>>>>> > >>>>>>>>>>> 1/2 looks good to me, go ahead and apply . > >>>>>>>> > >>>>>>>> Isn't there any way for the second patch to move forward as well > >>>>>>>> though? > >>>>>>>> The bridge device (under DPI to (e)DP mode) cannot really work > >>>>>>>> without > >>>>>>>> it, and the patches have been pending idle for a long time. =) > >>>>>>>> > >>>>>>>>>> > >>>>>>>>>> My local patches still apply on top of 6.10-rc4, so I don't > >>>>>>>>>> think this > >>>>>>>>>> ever happened. What's still holding up this long-pending fix > >>>>>>>>>> (at least > >>>>>>>>>> for our devices)? > >>>>>>>>> > >>>>>>>>> Neither of the patches contains Fixes tags. If the first patch > >>>>>>>>> fixes an > >>>>>>>>> issue in previous kernels, please consider following the stable > >>>>>>>>> process. > >>>>>>>>> > >>>>>>>>> If we are unsure about the second patch, please send the first > >>>>>>>>> patch > >>>>>>>>> separately, adding proper tags. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Thanks Dmitry! I can send the patches again with the required fixes > >>>>>>>> tags (or just patch-1 if we cannot do anything about patch-2). > >>>>>>> > >>>>>>> The problem with the second patch is that it get mixed reviews. I > >>>>>>> can > >>>>>>> ack the first patch, but for the second one I'd need a > >>>>>>> confirmation from > >>>>>>> somebody else. I'll go on and apply the first patch later today. > >>>>>>> > >>>>>> > >>>>>> Thanks Dmitry! > >>>>>> > >>>>>> However, would it be okay if I instead add another patch that makes 2 > >>>>>> versions of the "tc_edp_bridge_funcs", say > >>>>>> "tc_dpi_edp_bridge_funcs" and > >>>>>> "tc_dsi_edp_bridge_funcs", that have all the same function hooks > >>>>>> except > >>>>>> for the .edid_read()? > >>>>>> > >>>>>> The dsi edid_read() will remain the same, and Tomi's patch - patch > >>>>>> 2/2 - > >>>>>> will only fix the dpi version of the edid_read()? > >>>>>> > >>>>>> The bridge already has the capability to distinguish a DSI input > >>>>>> from a > >>>>>> DPI input. This can be leveraged to decide which set of functions > >>>>>> need > >>>>>> to be used without any major changes. > >>>>> > >>>>> I'd prefer if somebody with the DSI setup can ack / test the second > >>>>> patch. > >>>>> > >>>>> > >>>> > >>>> Now that my DSI-DP setup works apparently without issue I could test > >>>> patch 2. > >>>> Since my setup does not use DRM_BRIDGE_ATTACH_NO_CONNECTOR (running on > >>>> drivers/gpu/drm/mxsfb/lcdif_drv.c), I can only say > >>>> there is no regression. > >>> > >>> Let me send a (non-tested) patch, switching to drm_bridge_connector, > >>> then you can probably test both of them > >>> > >> > >> I suppose [1] was that follow-up, just not leading to success, right? > >> > >> Now, what's next? I'd love to see the regression we have for the IOT2050 > >> devices finally fixed, even if it now only requires a short downstream > >> patch. > >> > >> Jan > >> > >> [1] > >> https://lore.kernel.org/dri-devel/20240624-mxc-lcdif-bridge-attach-v1-1-37e8c5d5d934@linaro.org/ > > > > I have to say I don't remember the details for this anymore, but half a > > year ago I said: > > > >> Afaics, if the DSI lanes are not set up early enough by the DSI host, > >> the driver would break with and without these patches. > > > > I'm not sure if that is correct or not. But if it is, then, afaiu, this > > (the second patch): > > > > - Fixes the issue for the DPI-DP use case > > > > - Doesn't cause issues for the DSI-DP use case without > > DRM_BRIDGE_ATTACH_NO_CONNECTOR (as per Alexander's test) > > > > - Shouldn't cause (new) issues for the DSI-DP use case with > > DRM_BRIDGE_ATTACH_NO_CONNECTOR (as per my code review and guessing...) > > > > The third point is somewhat concerning, of course, but do we have any > > setup with DSI-DP and DRM_BRIDGE_ATTACH_NO_CONNECTOR that works now? If > > not, maybe we can just ignore the possible issues, as this fixes > > problems on a setup we do have. > > > > As Dmitry asked me during Plumbers to revalidate if our setup still > needs patch 2, I just did that over 6.11.0-next-20240923 (where patch 1 > is now included). No surprise, it is still needed for our iot2050 device > series, otherwise the display remains black. Granted that nobody with the DRM_BRIDGE_ATTACH_NO_CONNECTOR + DSI-DP spoke in the last several months, I think we'd better merge the patch as it is now. If noone objects (last call), I'll do that in one or two days.
Hi, On 23/09/2024 15:25, Dmitry Baryshkov wrote: >> As Dmitry asked me during Plumbers to revalidate if our setup still >> needs patch 2, I just did that over 6.11.0-next-20240923 (where patch 1 >> is now included). No surprise, it is still needed for our iot2050 device >> series, otherwise the display remains black. > > Granted that nobody with the DRM_BRIDGE_ATTACH_NO_CONNECTOR + DSI-DP > spoke in the last several months, I think we'd better merge the patch as > it is now. If noone objects (last call), I'll do that in one or two > days. No one has objected, are we ready to merge? Tomi
On Fri, Oct 11, 2024 at 03:02:56PM +0300, Tomi Valkeinen wrote: > Hi, > > On 23/09/2024 15:25, Dmitry Baryshkov wrote: > > > > As Dmitry asked me during Plumbers to revalidate if our setup still > > > needs patch 2, I just did that over 6.11.0-next-20240923 (where patch 1 > > > is now included). No surprise, it is still needed for our iot2050 device > > > series, otherwise the display remains black. > > > > Granted that nobody with the DRM_BRIDGE_ATTACH_NO_CONNECTOR + DSI-DP > > spoke in the last several months, I think we'd better merge the patch as > > it is now. If noone objects (last call), I'll do that in one or two > > days. > > No one has objected, are we ready to merge? Applied
These two patches are needed to make tc358767 work in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector. I have tested this with TI AM654 EVM with a tc358767 add-on card connected to a DP monitor. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> --- Changes in v2: - Update the format negotiation patch as discussed in https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0232@ti.com/ - Link to v1: https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard.com --- Aradhya Bhatia (1): drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to (e)DP Tomi Valkeinen (1): drm/bridge: tc358767: Fix link properties discovery drivers/gpu/drm/bridge/tc358767.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) --- base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 change-id: 20231031-tc358767-58e3ebdf95f0 Best regards,