[PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[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.

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,
-- 
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

[PATCH v2 1/2] drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to (e)DP

[Tomi Valkeinen]

From: Aradhya Bhatia <a-bhatia1@ti.com>

With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
rely on format negotiation to setup the encoder format.

Add the missing bus format negotiation hooks in the
drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.

Output format, for DPI/DSI to DP, is selected to
MEDIA_BUS_FMT_RGB888_1X24 as default, keeping in mind what the older
model used to support.

Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Closes: https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8205@siemens.com/
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c
index ef2e373606ba..89a0d804270a 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1726,6 +1726,7 @@ static void tc_edp_bridge_detach(struct drm_bridge *bridge)
 }
 
 #define MAX_INPUT_SEL_FORMATS	1
+#define MAX_OUTPUT_SEL_FORMATS	1
 
 static u32 *
 tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
@@ -1751,6 +1752,28 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
 	return input_fmts;
 }
 
+static u32 *
+tc_edp_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
+				  struct drm_bridge_state *bridge_state,
+				  struct drm_crtc_state *crtc_state,
+				  struct drm_connector_state *conn_state,
+				  unsigned int *num_output_fmts)
+{
+	u32 *output_fmts;
+
+	*num_output_fmts = 0;
+
+	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
+			      GFP_KERNEL);
+	if (!output_fmts)
+		return NULL;
+
+	output_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+	*num_output_fmts = 1;
+
+	return output_fmts;
+}
+
 static const struct drm_bridge_funcs tc_dpi_bridge_funcs = {
 	.attach = tc_dpi_bridge_attach,
 	.mode_valid = tc_dpi_mode_valid,
@@ -1777,6 +1800,8 @@ static const struct drm_bridge_funcs tc_edp_bridge_funcs = {
 	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset = drm_atomic_helper_bridge_reset,
+	.atomic_get_input_bus_fmts = drm_atomic_helper_bridge_propagate_bus_fmt,
+	.atomic_get_output_bus_fmts = tc_edp_atomic_get_output_bus_fmts,
 };
 
 static bool tc_readable_reg(struct device *dev, unsigned int reg)

-- 
2.34.1

[PATCH v2 2/2] drm/bridge: tc358767: Fix link properties discovery

[Tomi Valkeinen]

When a display controller driver uses DRM_BRIDGE_ATTACH_NO_CONNECTOR,
tc358767 will behave properly and skip the creation of the connector.

However, tc_get_display_props(), which is used to find out about the DP
monitor and link, is only called from two places: .atomic_enable() and
tc_connector_get_modes(). The latter is only used when tc358767 creates
its own connector, i.e. when DRM_BRIDGE_ATTACH_NO_CONNECTOR is _not_
set.

Thus, the driver never finds out the link properties before get_edid()
is called. With num_lanes of 0 and link_rate of 0 there are not many
valid modes...

Fix this by adding tc_get_display_props() call at the beginning of
get_edid(), so that we have up to date information before looking at the
modes.

Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Closes: https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8205@siemens.com/
Fixes: de5e6c027ae6 ("drm/bridge: tc358767: add drm_panel_bridge support")
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/bridge/tc358767.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c
index 89a0d804270a..5aafbdf423c6 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1579,6 +1579,13 @@ static struct edid *tc_get_edid(struct drm_bridge *bridge,
 				struct drm_connector *connector)
 {
 	struct tc_data *tc = bridge_to_tc(bridge);
+	int ret;
+
+	ret = tc_get_display_props(tc);
+	if (ret < 0) {
+		dev_err(tc->dev, "failed to read display props: %d\n", ret);
+		return 0;
+	}
 
 	return drm_get_edid(connector, &tc->aux.ddc);
 }

-- 
2.34.1

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Alexander Stein]

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,


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Tomi Valkeinen]

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,
> 
> 

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[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?

  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,
> 
> 

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Aradhya Bhatia]

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,
>>
>>
> 

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Alexander Stein]

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,


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[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?

Is this the last blocker to move forward with these fixes? I'd really
like to see them finally merged.

Thanks,
Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Alexander Stein]

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


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Tomi Valkeinen]

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

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Marek Vasut]

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 .

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Jan Kiszka]

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

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v2 1/2] drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to (e)DP

[Dmitry Baryshkov]

On Wed, Nov 08, 2023 at 01:27:22PM GMT, Tomi Valkeinen wrote:
> From: Aradhya Bhatia <a-bhatia1@ti.com>
> 
> With new connector model, tc358767 will not create the connector, when
> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
> rely on format negotiation to setup the encoder format.
> 
> Add the missing bus format negotiation hooks in the
> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.
> 
> Output format, for DPI/DSI to DP, is selected to
> MEDIA_BUS_FMT_RGB888_1X24 as default, keeping in mind what the older
> model used to support.
> 
> Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
> Closes: https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8205@siemens.com/
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 

If this is a fix, where is the Fixes tag?

-- 
With best wishes
Dmitry

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Aradhya Bhatia]

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).


-- 
Regards
Aradhya

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

Re: [PATCH v2 1/2] drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to (e)DP

[Dmitry Baryshkov]

On Wed, Nov 08, 2023 at 01:27:22PM GMT, Tomi Valkeinen wrote:
> From: Aradhya Bhatia <a-bhatia1@ti.com>
> 
> With new connector model, tc358767 will not create the connector, when
> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
> rely on format negotiation to setup the encoder format.
> 
> Add the missing bus format negotiation hooks in the
> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.
> 
> Output format, for DPI/DSI to DP, is selected to
> MEDIA_BUS_FMT_RGB888_1X24 as default, keeping in mind what the older
> model used to support.
> 
> Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
> Closes: https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8205@siemens.com/
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>


-- 
With best wishes
Dmitry

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Aradhya Bhatia]

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

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[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.

-- 
With best wishes
Dmitry

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Alexander Stein]

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
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Dmitry Baryshkov]

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


-- 
With best wishes
Dmitry

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Jan Kiszka]

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/

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Tomi Valkeinen]

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

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Jan Kiszka]

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

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Tomi Valkeinen]

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

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Dmitry Baryshkov]

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

-- 
With best wishes
Dmitry