Linux-OMAP Archive on lore.kernel.org
 help / color / Atom feed
* OMAP5: inconsistency between target-module and dsi_of_data_omap5
@ 2020-07-05  6:52 H. Nikolaus Schaller
  2020-07-05  7:40 ` H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-05  6:52 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Discussions about the Letux Kernel, kernel, Linux-OMAP,
	Tomi Valkeinen, Laurent Pinchart, Jyri Sarha

Hi Tony,
since v5.7-rc1 our Pyra (OMAP5) dsi panel doesn't initialize and we do not
get a /dev/fb0.

There is a suspicious log message:

[   15.352314] DSI: omapdss DSI error: unsupported DSI module

I could trace it down to be likely a discrepancy between

target-module@58000000 { 

...

				target-module@5000 {
					compatible = "ti,sysc-omap2", "ti,sysc";
					reg = <0x5000 0x4>,
...
					ranges = <0 0x5000 0x1000>;

					dsi1: encoder@0 {
						compatible = "ti,omap5-dsi";

				target-module@9000 {
					compatible = "ti,sysc-omap2", "ti,sysc";
					reg = <0x9000 0x4>,
					      <0x9010 0x4>,
					      <0x9014 0x4>;

...

					ranges = <0 0x9000 0x1000>;

					dsi2: encoder@0 {
						compatible = "ti,omap5-dsi";
						reg = <0 0x200>,
						      <0x200 0x40>,
						      <0x300 0x40>;



and

static const struct dsi_of_data dsi_of_data_omap5 = {
	.model = DSI_MODEL_OMAP5,
	.pll_hw = &dss_omap5_dsi_pll_hw,
	.modules = (const struct dsi_module_id_data[]) {
		{ .address = 0x58004000, .id = 0, },
		{ .address = 0x58009000, .id = 1, },
		{ },
	},

Therefore the address match logic in dsi_probe() fails and ends in
the mentioned log message.

Looking at git blame, the DTS was recently changed by 5a507162f096b54.
Commit 98e1a6a86a22d62 did do a similar change for dsi2 but did not
modify the address.

So I wonder if the 0x5000 is just a typo or if there is something
where the dsi1: encoder@0 should have a negative offset to end
up at address 0x58004000?

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-05  6:52 OMAP5: inconsistency between target-module and dsi_of_data_omap5 H. Nikolaus Schaller
@ 2020-07-05  7:40 ` H. Nikolaus Schaller
  2020-07-05 13:47   ` H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-05  7:40 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Discussions about the Letux Kernel, kernel, Linux-OMAP,
	Tomi Valkeinen, Laurent Pinchart, Jyri Sarha


> Am 05.07.2020 um 08:52 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Tony,
> since v5.7-rc1 our Pyra (OMAP5) dsi panel doesn't initialize and we do not
> get a /dev/fb0.
> 
> There is a suspicious log message:
> 
> [   15.352314] DSI: omapdss DSI error: unsupported DSI module
> 
> I could trace it down to be likely a discrepancy between
> 
> target-module@58000000 { 
> 
> ...
> 
> 				target-module@5000 {
> 					compatible = "ti,sysc-omap2", "ti,sysc";
> 					reg = <0x5000 0x4>,
> ...
> 					ranges = <0 0x5000 0x1000>;
> 
> 					dsi1: encoder@0 {
> 						compatible = "ti,omap5-dsi";
> 
> 				target-module@9000 {
> 					compatible = "ti,sysc-omap2", "ti,sysc";
> 					reg = <0x9000 0x4>,
> 					      <0x9010 0x4>,
> 					      <0x9014 0x4>;
> 
> ...
> 
> 					ranges = <0 0x9000 0x1000>;
> 
> 					dsi2: encoder@0 {
> 						compatible = "ti,omap5-dsi";
> 						reg = <0 0x200>,
> 						      <0x200 0x40>,
> 						      <0x300 0x40>;
> 
> 
> 
> and
> 
> static const struct dsi_of_data dsi_of_data_omap5 = {
> 	.model = DSI_MODEL_OMAP5,
> 	.pll_hw = &dss_omap5_dsi_pll_hw,
> 	.modules = (const struct dsi_module_id_data[]) {
> 		{ .address = 0x58004000, .id = 0, },
> 		{ .address = 0x58009000, .id = 1, },
> 		{ },
> 	},
> 
> Therefore the address match logic in dsi_probe() fails and ends in
> the mentioned log message.
> 
> Looking at git blame, the DTS was recently changed by 5a507162f096b54.
> Commit 98e1a6a86a22d62 did do a similar change for dsi2 but did not
> modify the address.
> 
> So I wonder if the 0x5000 is just a typo or if there is something
> where the dsi1: encoder@0 should have a negative offset to end
> up at address 0x58004000?
> 
> BR and thanks,
> Nikolaus
> 

This patch makes the DSI error go away and omapdrm initialized:

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e147121513e644..b9f54f62163879 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -474,7 +474,7 @@ rfbi: encoder@0  {
                                        };
                                };
 
-                               target-module@5000 {
+                               target-module@4000 {
                                        compatible = "ti,sysc-omap2", "ti,sysc";
                                        reg = <0x5000 0x4>,
                                              <0x5010 0x4>,
@@ -490,7 +490,7 @@ SYSC_OMAP2_SOFTRESET |
                                        ti,syss-mask = <1>;
                                        #address-cells = <1>;
                                        #size-cells = <1>;
-                                       ranges = <0 0x5000 0x1000>;
+                                       ranges = <0 0x4000 0x1000>;
 
                                        dsi1: encoder@0 {
                                                compatible = "ti,omap5-dsi";

But I still have no display:

[   17.537515] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 2
[   18.558950] omapdrm omapdrm.0: [drm] Cannot find any crtc or sizes

So there is more to fix.

BR,
Nikolaus



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-05  7:40 ` H. Nikolaus Schaller
@ 2020-07-05 13:47   ` H. Nikolaus Schaller
  2020-07-05 14:26     ` Tony Lindgren
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-05 13:47 UTC (permalink / raw)
  To: Tony Lindgren, Tomi Valkeinen
  Cc: Discussions about the Letux Kernel, kernel, Linux-OMAP,
	Laurent Pinchart, Jyri Sarha


> Am 05.07.2020 um 09:40 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> 
>> Am 05.07.2020 um 08:52 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>> 
>> Hi Tony,
>> since v5.7-rc1 our Pyra (OMAP5) dsi panel doesn't initialize and we do not
>> get a /dev/fb0.
>> 
>> There is a suspicious log message:
>> 
>> [   15.352314] DSI: omapdss DSI error: unsupported DSI module
>> 
>> I could trace it down to be likely a discrepancy between
>> 
>> target-module@58000000 { 
>> 
>> ...
>> 
>> 				target-module@5000 {
>> 					compatible = "ti,sysc-omap2", "ti,sysc";
>> 					reg = <0x5000 0x4>,
>> ...
>> 					ranges = <0 0x5000 0x1000>;
>> 
>> 					dsi1: encoder@0 {
>> 						compatible = "ti,omap5-dsi";
>> 
>> 				target-module@9000 {
>> 					compatible = "ti,sysc-omap2", "ti,sysc";
>> 					reg = <0x9000 0x4>,
>> 					      <0x9010 0x4>,
>> 					      <0x9014 0x4>;
>> 
>> ...
>> 
>> 					ranges = <0 0x9000 0x1000>;
>> 
>> 					dsi2: encoder@0 {
>> 						compatible = "ti,omap5-dsi";
>> 						reg = <0 0x200>,
>> 						      <0x200 0x40>,
>> 						      <0x300 0x40>;
>> 
>> 
>> 
>> and
>> 
>> static const struct dsi_of_data dsi_of_data_omap5 = {
>> 	.model = DSI_MODEL_OMAP5,
>> 	.pll_hw = &dss_omap5_dsi_pll_hw,
>> 	.modules = (const struct dsi_module_id_data[]) {
>> 		{ .address = 0x58004000, .id = 0, },
>> 		{ .address = 0x58009000, .id = 1, },
>> 		{ },
>> 	},
>> 
>> Therefore the address match logic in dsi_probe() fails and ends in
>> the mentioned log message.
>> 
>> Looking at git blame, the DTS was recently changed by 5a507162f096b54.
>> Commit 98e1a6a86a22d62 did do a similar change for dsi2 but did not
>> modify the address.
>> 
>> So I wonder if the 0x5000 is just a typo or if there is something
>> where the dsi1: encoder@0 should have a negative offset to end
>> up at address 0x58004000?
>> 
>> BR and thanks,
>> Nikolaus
>> 
> 
> This patch makes the DSI error go away and omapdrm initialized:
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index e147121513e644..b9f54f62163879 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -474,7 +474,7 @@ rfbi: encoder@0  {
>                                        };
>                                };
> 
> -                               target-module@5000 {
> +                               target-module@4000 {
>                                        compatible = "ti,sysc-omap2", "ti,sysc";
>                                        reg = <0x5000 0x4>,
>                                              <0x5010 0x4>,
> @@ -490,7 +490,7 @@ SYSC_OMAP2_SOFTRESET |
>                                        ti,syss-mask = <1>;
>                                        #address-cells = <1>;
>                                        #size-cells = <1>;
> -                                       ranges = <0 0x5000 0x1000>;
> +                                       ranges = <0 0x4000 0x1000>;
> 
>                                        dsi1: encoder@0 {
>                                                compatible = "ti,omap5-dsi";
> 
> But I still have no display:
> 
> [   17.537515] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 2
> [   18.558950] omapdrm omapdrm.0: [drm] Cannot find any crtc or sizes
> 
> So there is more to fix.

A little more info:

on v5.7 I see:

[   13.850883] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops [omapdss])
[   13.885714] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops [omapdss])

while on v5.6:

[   14.997890] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dsi_vc_flush_receive_data [omapdss])
[   15.007726] omapdss_dss 58000000.dss: bound 58004000.encoder (ops dsi_vc_flush_receive_data [omapdss])
[   15.026118] omapdss_dss 58000000.dss: bound 58040000.encoder (ops dsi_vc_flush_receive_data [omapdss])

So the dsi1 encoder isn't properly bound.

BR,
Nikolaus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-05 13:47   ` H. Nikolaus Schaller
@ 2020-07-05 14:26     ` Tony Lindgren
  2020-07-05 14:36       ` Tony Lindgren
  0 siblings, 1 reply; 23+ messages in thread
From: Tony Lindgren @ 2020-07-05 14:26 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Tomi Valkeinen, Discussions about the Letux Kernel, kernel,
	Linux-OMAP, Laurent Pinchart, Jyri Sarha

* H. Nikolaus Schaller <hns@goldelico.com> [200705 13:48]:
> > This patch makes the DSI error go away and omapdrm initialized:
> > 
> > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> > index e147121513e644..b9f54f62163879 100644
> > --- a/arch/arm/boot/dts/omap5.dtsi
> > +++ b/arch/arm/boot/dts/omap5.dtsi
> > @@ -474,7 +474,7 @@ rfbi: encoder@0  {
> >                                        };
> >                                };
> > 
> > -                               target-module@5000 {
> > +                               target-module@4000 {
> >                                        compatible = "ti,sysc-omap2", "ti,sysc";
> >                                        reg = <0x5000 0x4>,
> >                                              <0x5010 0x4>,
> > @@ -490,7 +490,7 @@ SYSC_OMAP2_SOFTRESET |
> >                                        ti,syss-mask = <1>;
> >                                        #address-cells = <1>;
> >                                        #size-cells = <1>;
> > -                                       ranges = <0 0x5000 0x1000>;
> > +                                       ranges = <0 0x4000 0x1000>;
> > 
> >                                        dsi1: encoder@0 {
> >                                                compatible = "ti,omap5-dsi";

Oops sorry about that one. The l3 entries I've had to manually add
while l4 has been generated form the hardware for most part.

This one was caused by commit 5a507162f096 ("ARM: dts: Configure
interconnect target module for omap5 dsi1").

> > But I still have no display:
> > 
> > [   17.537515] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 2
> > [   18.558950] omapdrm omapdrm.0: [drm] Cannot find any crtc or sizes
> > 
> > So there is more to fix.
> 
> A little more info:
> 
> on v5.7 I see:
> 
> [   13.850883] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops [omapdss])
> [   13.885714] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops [omapdss])
> 
> while on v5.6:
> 
> [   14.997890] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dsi_vc_flush_receive_data [omapdss])
> [   15.007726] omapdss_dss 58000000.dss: bound 58004000.encoder (ops dsi_vc_flush_receive_data [omapdss])
> [   15.026118] omapdss_dss 58000000.dss: bound 58040000.encoder (ops dsi_vc_flush_receive_data [omapdss])
> 
> So the dsi1 encoder isn't properly bound.

Yeah sounds like something is still wrong.

Do you have loaded display-connector? That is needed starting
with v5.7-rc1.

Regards,

Tony

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-05 14:26     ` Tony Lindgren
@ 2020-07-05 14:36       ` Tony Lindgren
  2020-07-05 15:40         ` H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: Tony Lindgren @ 2020-07-05 14:36 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Tomi Valkeinen, Discussions about the Letux Kernel, kernel,
	Linux-OMAP, Laurent Pinchart, Jyri Sarha

* Tony Lindgren <tony@atomide.com> [200705 14:27]:
> * H. Nikolaus Schaller <hns@goldelico.com> [200705 13:48]:
> > > This patch makes the DSI error go away and omapdrm initialized:
> > > 
> > > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> > > index e147121513e644..b9f54f62163879 100644
> > > --- a/arch/arm/boot/dts/omap5.dtsi
> > > +++ b/arch/arm/boot/dts/omap5.dtsi
> > > @@ -474,7 +474,7 @@ rfbi: encoder@0  {
> > >                                        };
> > >                                };
> > > 
> > > -                               target-module@5000 {
> > > +                               target-module@4000 {
> > >                                        compatible = "ti,sysc-omap2", "ti,sysc";
> > >                                        reg = <0x5000 0x4>,
> > >                                              <0x5010 0x4>,

Looks like you need to also change the reg offsets above
from 0x5000 something to 0x4000 something.

> Do you have loaded display-connector? That is needed starting
> with v5.7-rc1.

Where the display-connector is a new kernel module to load.

Regards,

Tony

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-05 14:36       ` Tony Lindgren
@ 2020-07-05 15:40         ` H. Nikolaus Schaller
  2020-07-06 14:36           ` Tony Lindgren
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-05 15:40 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Tomi Valkeinen, Discussions about the Letux Kernel, kernel,
	Linux-OMAP, Laurent Pinchart, Jyri Sarha

Hi Tony,

> Am 05.07.2020 um 16:36 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * Tony Lindgren <tony@atomide.com> [200705 14:27]:
>> * H. Nikolaus Schaller <hns@goldelico.com> [200705 13:48]:
>>>> This patch makes the DSI error go away and omapdrm initialized:
>>>> 
>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>>>> index e147121513e644..b9f54f62163879 100644
>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>> @@ -474,7 +474,7 @@ rfbi: encoder@0  {
>>>>                                       };
>>>>                               };
>>>> 
>>>> -                               target-module@5000 {
>>>> +                               target-module@4000 {
>>>>                                       compatible = "ti,sysc-omap2", "ti,sysc";
>>>>                                       reg = <0x5000 0x4>,
>>>>                                             <0x5010 0x4>,
> 
> Looks like you need to also change the reg offsets above
> from 0x5000 something to 0x4000 something.

I think I had tried that as well, but then it seems to hang
in drm_setup_crtcs_fb (or shortly after).

> 
>> Do you have loaded display-connector? That is needed starting
>> with v5.7-rc1.
> 
> Where the display-connector is a new kernel module to load.

Ah, ok. Never heard of but it seems to be selected automatically:

CONFIG_CONNECTOR=y
CONFIG_DRM_DISPLAY_CONNECTOR=m

and

root@letux:~# lsmod | fgrep dss
omapdss               163840  3
omapdss_base           16384  2 omapdrm,omapdss
drm_kms_helper        143360  3 omapdss_base,omapdrm,omapdss
drm                   380928  10 ti_tpd12s015,omapdss_base,pvrsrvkm_omap5_sgx544_116,display_connector,etnaviv,omapdrm,gpu_sched,omapdss,drm_kms_helper
cec                    45056  1 omapdss
root@letux:~# 

Does the panel driver also need some modification? It is no longer loaded.

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-05 15:40         ` H. Nikolaus Schaller
@ 2020-07-06 14:36           ` Tony Lindgren
  2020-07-06 16:10             ` H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: Tony Lindgren @ 2020-07-06 14:36 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Tomi Valkeinen, Discussions about the Letux Kernel, kernel,
	Linux-OMAP, Laurent Pinchart, Jyri Sarha

* H. Nikolaus Schaller <hns@goldelico.com> [200705 15:41]:
> Does the panel driver also need some modification? It is no longer loaded.

Hmm so what's the panel driver in this case?

I think you should now be using just the generic panel with
drivers/gpu/drm/panel/panel-simple or some panel specific
driver for dsi.

I think dsi command mode is now the only omapdrm output not
yet using generic panel. And Sebastian has a branch pending
for updating dsi command mode to use generic panel.

Regards,

Tony




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-06 14:36           ` Tony Lindgren
@ 2020-07-06 16:10             ` H. Nikolaus Schaller
  2020-07-07 18:01               ` Tony Lindgren
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-06 16:10 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Tomi Valkeinen, Discussions about the Letux Kernel, kernel,
	Linux-OMAP, Laurent Pinchart, Jyri Sarha

Hi Tony,

> Am 06.07.2020 um 16:36 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [200705 15:41]:
>> Does the panel driver also need some modification? It is no longer loaded.
> 
> Hmm so what's the panel driver in this case?

boe,btl507212-w677l

> 
> I think you should now be using just the generic panel with
> drivers/gpu/drm/panel/panel-simple or some panel specific
> driver for dsi.

None of them supports the vendor specific MIPI commands of
this panel.

Therefore we have our own panel driver for years and try to
keep pace with upstream changes.

> 
> I think dsi command mode is now the only omapdrm output not
> yet using generic panel. And Sebastian has a branch pending
> for updating dsi command mode to use generic panel.

I know and had made an attempt to make a modified panel driver
compatible to his code.

But his code is no longer compatible to v5.7 or v5.8 and I failed
to get the panel working on earlier releases.

We also use it in video mode and not command mode.

It seems to be the third or fourth time that we have to rework
the panel driver for an -rc1 because dss panel api has changed
(for good reasons)...

The best thing would be that the panel driver can be upstreamed.
Ideally as a DRM panel and no an OMAPDSS display.

But there are some blocking points:

a) driver is now no longer working, so that it is no longer ready
   for submission
b) there is no DTS upstream that makes use of it
c) it is still an omapdss display driver sitting in
   drivers/gpu/drm/omapdrm/displays where it works up to v5.6.y
d) AFAIR omapdrm does not support random MIPI-DSI panels from
   drivers/gpu/drm/panel (or does it now and we have not yet
   recognised?)

Sort of hen&egg problem :)

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-06 16:10             ` H. Nikolaus Schaller
@ 2020-07-07 18:01               ` Tony Lindgren
  2020-07-07 19:04                 ` H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: Tony Lindgren @ 2020-07-07 18:01 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Tomi Valkeinen, Discussions about the Letux Kernel, kernel,
	Linux-OMAP, Laurent Pinchart, Jyri Sarha

* H. Nikolaus Schaller <hns@goldelico.com> [200706 16:11]:
> > Am 06.07.2020 um 16:36 schrieb Tony Lindgren <tony@atomide.com>:
> > I think you should now be using just the generic panel with
> > drivers/gpu/drm/panel/panel-simple or some panel specific
> > driver for dsi.
> 
> None of them supports the vendor specific MIPI commands of
> this panel.
> 
> Therefore we have our own panel driver for years and try to
> keep pace with upstream changes.

OK yeah would be good to have it upstream. It might see use
on some other platforms while waiting for the pyra dts files.

Regards,

Tony

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5
  2020-07-07 18:01               ` Tony Lindgren
@ 2020-07-07 19:04                 ` H. Nikolaus Schaller
  2020-07-08  7:52                   ` OMAP5: inconsistency between target-module and dsi_of_data_omap5 / module_mipi_dsi_driver panel with omapdrm H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-07 19:04 UTC (permalink / raw)
  To: Tony Lindgren, Tomi Valkeinen
  Cc: Discussions about the Letux Kernel, kernel, Linux-OMAP,
	Laurent Pinchart, Jyri Sarha

Hi Tony and Tomi,

> Am 07.07.2020 um 20:01 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [200706 16:11]:
>>> Am 06.07.2020 um 16:36 schrieb Tony Lindgren <tony@atomide.com>:
>>> I think you should now be using just the generic panel with
>>> drivers/gpu/drm/panel/panel-simple or some panel specific
>>> driver for dsi.
>> 
>> None of them supports the vendor specific MIPI commands of
>> this panel.
>> 
>> Therefore we have our own panel driver for years and try to
>> keep pace with upstream changes.
> 
> OK yeah would be good to have it upstream. It might see use
> on some other platforms while waiting for the pyra dts files.

So if you think we can get the panel driver upstream without the
pyra dts files I am happy to submit something for review.

But I have to fix it first.

Maybe Tomi can comment about ideas what structural changes have
been done so that it got broken since v5.7-rc1. Then it becomes
easier to fix for me. Maybe there was some rework in omapdrm/dss
which needs some change in the driver.

And what I would need to know before I start to write new code is
if is possible to operate a video mipi dsi panel with driver from
gpu/drm/panel together with omapdrm (v5.7 and later).

If this is possible it should be quite easy to mix the
old omapdrm/display driver code with e.g.:

drivers/gpu/drm/panel/panel-orisetech-otm8009a.c

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5 / module_mipi_dsi_driver panel with omapdrm
  2020-07-07 19:04                 ` H. Nikolaus Schaller
@ 2020-07-08  7:52                   ` H. Nikolaus Schaller
  2020-07-23  7:03                     ` Re:module_mipi_dsi_driver panel with omapdrm? H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-08  7:52 UTC (permalink / raw)
  To: Tony Lindgren, Tomi Valkeinen
  Cc: Linux-OMAP, Discussions about the Letux Kernel, Laurent Pinchart,
	Jyri Sarha, kernel

Hi again,

> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Tony and Tomi,
> 
>> Am 07.07.2020 um 20:01 schrieb Tony Lindgren <tony@atomide.com>:
>> 
>> * H. Nikolaus Schaller <hns@goldelico.com> [200706 16:11]:
>>>> Am 06.07.2020 um 16:36 schrieb Tony Lindgren <tony@atomide.com>:
>>>> I think you should now be using just the generic panel with
>>>> drivers/gpu/drm/panel/panel-simple or some panel specific
>>>> driver for dsi.
>>> 
>>> None of them supports the vendor specific MIPI commands of
>>> this panel.
>>> 
>>> Therefore we have our own panel driver for years and try to
>>> keep pace with upstream changes.
>> 
>> OK yeah would be good to have it upstream. It might see use
>> on some other platforms while waiting for the pyra dts files.
> 
> So if you think we can get the panel driver upstream without the
> pyra dts files I am happy to submit something for review.
> 
> But I have to fix it first.
> 
> Maybe Tomi can comment about ideas what structural changes have
> been done so that it got broken since v5.7-rc1. Then it becomes
> easier to fix for me. Maybe there was some rework in omapdrm/dss
> which needs some change in the driver.
> 
> And what I would need to know before I start to write new code is
> if is possible to operate a video mipi dsi panel with driver from
> gpu/drm/panel together with omapdrm (v5.7 and later).
> 
> If this is possible it should be quite easy to mix the
> old omapdrm/display driver code with e.g.:
> 
> drivers/gpu/drm/panel/panel-orisetech-otm8009a.c

I did a quick test on a 5.7.6 kernel with the sysc fixes as
suggested by Tony.

Then I overwrote the compatible entry of our display to be
orisetech,otm8009a and configured to build the otm8009a panel driver.

The panel driver is loaded, but not probed (no call to otm8009a_probe).
It is shown in /sys/bus/mipi-dsi/drivers (and lsmod) but not /sys/bus/mipi-dsi/devices.

So what should I try next?

BR and thanks,
Nikolaus

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re:module_mipi_dsi_driver panel with omapdrm?
  2020-07-08  7:52                   ` OMAP5: inconsistency between target-module and dsi_of_data_omap5 / module_mipi_dsi_driver panel with omapdrm H. Nikolaus Schaller
@ 2020-07-23  7:03                     ` H. Nikolaus Schaller
  2020-07-24  1:24                       ` module_mipi_dsi_driver " Laurent Pinchart
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-23  7:03 UTC (permalink / raw)
  To: Tony Lindgren, Tomi Valkeinen, Laurent Pinchart
  Cc: Linux-OMAP, Jyri Sarha, kernel, Discussions about the Letux Kernel

Hi all,

> Am 08.07.2020 um 09:52 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi again,
> 
>> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>> 
>> And what I would need to know before I start to write new code is
>> if is possible to operate a video mipi dsi panel with driver from
>> gpu/drm/panel together with omapdrm (v5.7 and later).
> 

> I did a quick test on a 5.7.6 kernel with the sysc fixes as
> suggested by Tony.
> 
> Then I overwrote the compatible entry of our display to be
> orisetech,otm8009a and configured to build the otm8009a panel driver.
> 
> The panel driver is loaded, but not probed (no call to otm8009a_probe).
> It is shown in /sys/bus/mipi-dsi/drivers (and lsmod) but not /sys/bus/mipi-dsi/devices.
> 
> So what should I try next?

Any suggestions if and how it is possible to use a gpu/drm/panel MIPI DSI
video mode panel with omapdrm (on OMAP5)?

The problem is that our old omapdrm/display driver is broken since v5.7 and
an experimental gpu/drm/panel driver does not probe. And I assume that
omapdrm/display will disappear completely soon.

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-07-23  7:03                     ` Re:module_mipi_dsi_driver panel with omapdrm? H. Nikolaus Schaller
@ 2020-07-24  1:24                       ` Laurent Pinchart
  2020-07-24  5:50                         ` H. Nikolaus Schaller
  2020-08-01 13:43                         ` H. Nikolaus Schaller
  0 siblings, 2 replies; 23+ messages in thread
From: Laurent Pinchart @ 2020-07-24  1:24 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Tony Lindgren, Tomi Valkeinen, Linux-OMAP, Jyri Sarha, kernel,
	Discussions about the Letux Kernel

Hi Nikolaus,

On Thu, Jul 23, 2020 at 09:03:49AM +0200, H. Nikolaus Schaller wrote:
> > Am 08.07.2020 um 09:52 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >> 
> >> And what I would need to know before I start to write new code is
> >> if is possible to operate a video mipi dsi panel with driver from
> >> gpu/drm/panel together with omapdrm (v5.7 and later).
> > 
> > I did a quick test on a 5.7.6 kernel with the sysc fixes as
> > suggested by Tony.
> > 
> > Then I overwrote the compatible entry of our display to be
> > orisetech,otm8009a and configured to build the otm8009a panel driver.
> > 
> > The panel driver is loaded, but not probed (no call to otm8009a_probe).
> > It is shown in /sys/bus/mipi-dsi/drivers (and lsmod) but not /sys/bus/mipi-dsi/devices.
> > 
> > So what should I try next?
> 
> Any suggestions if and how it is possible to use a gpu/drm/panel MIPI DSI
> video mode panel with omapdrm (on OMAP5)?

For the DSI panel to probe, the display driver needs to register a DSI
host with mipi_dsi_host_register(). omapdrm doesn't do so yet, we need
to integrate Sebastian's "[PATCHv2 00/56] drm/omap: Convert DSI code to
use drm_mipi_dsi and drm_panel" series first. I'll try to review it in
the near future.

> The problem is that our old omapdrm/display driver is broken since v5.7 and
> an experimental gpu/drm/panel driver does not probe. And I assume that
> omapdrm/display will disappear completely soon.

Not before Sebastian's series gets integrated.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-07-24  1:24                       ` module_mipi_dsi_driver " Laurent Pinchart
@ 2020-07-24  5:50                         ` H. Nikolaus Schaller
  2020-08-01 13:43                         ` H. Nikolaus Schaller
  1 sibling, 0 replies; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-07-24  5:50 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Tony Lindgren, Tomi Valkeinen, Linux-OMAP, Jyri Sarha, kernel,
	Discussions about the Letux Kernel

Hi Laurent,

> Am 24.07.2020 um 03:24 schrieb Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> 
> Hi Nikolaus,
> 
> On Thu, Jul 23, 2020 at 09:03:49AM +0200, H. Nikolaus Schaller wrote:
>>> Am 08.07.2020 um 09:52 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> 
>>>> And what I would need to know before I start to write new code is
>>>> if is possible to operate a video mipi dsi panel with driver from
>>>> gpu/drm/panel together with omapdrm (v5.7 and later).
>>> 
>>> I did a quick test on a 5.7.6 kernel with the sysc fixes as
>>> suggested by Tony.
>>> 
>>> Then I overwrote the compatible entry of our display to be
>>> orisetech,otm8009a and configured to build the otm8009a panel driver.
>>> 
>>> The panel driver is loaded, but not probed (no call to otm8009a_probe).
>>> It is shown in /sys/bus/mipi-dsi/drivers (and lsmod) but not /sys/bus/mipi-dsi/devices.
>>> 
>>> So what should I try next?
>> 
>> Any suggestions if and how it is possible to use a gpu/drm/panel MIPI DSI
>> video mode panel with omapdrm (on OMAP5)?
> 
> For the DSI panel to probe, the display driver needs to register a DSI
> host with mipi_dsi_host_register().

I see.

> omapdrm doesn't do so yet, we need
> to integrate Sebastian's "[PATCHv2 00/56] drm/omap: Convert DSI code to
> use drm_mipi_dsi and drm_panel" series first. I'll try to review it in
> the near future.
> 
>> The problem is that our old omapdrm/display driver is broken since v5.7 and
>> an experimental gpu/drm/panel driver does not probe. And I assume that
>> omapdrm/display will disappear completely soon.
> 
> Not before Sebastian's series gets integrated.

Yes, it is be very important for us since I do not want to find out why the
old omapdrm/display driver isn't working any more just to have it rewritten
again and moved to gpu/drm/panel within a very short time frame.

I would be happy to start the new panel driver and test it with Sebastian's
series. AFAIR Sebastian's series doesn't currently apply well to v5.8-rc so
it would be nice if there were a work-in-progress repo that is rebased every
now and then.

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-07-24  1:24                       ` module_mipi_dsi_driver " Laurent Pinchart
  2020-07-24  5:50                         ` H. Nikolaus Schaller
@ 2020-08-01 13:43                         ` H. Nikolaus Schaller
  2020-08-01 23:22                           ` Sebastian Reichel
  2020-08-04 12:43                           ` Tomi Valkeinen
  1 sibling, 2 replies; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-01 13:43 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Tony Lindgren, Tomi Valkeinen, Linux-OMAP, Jyri Sarha, kernel,
	Discussions about the Letux Kernel, David Shah,
	Sebastian Reichel

Hi Laurent,

> Am 24.07.2020 um 03:24 schrieb Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> 
> Hi Nikolaus,
> 
> On Thu, Jul 23, 2020 at 09:03:49AM +0200, H. Nikolaus Schaller wrote:
>>> Am 08.07.2020 um 09:52 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>> 
>>>> And what I would need to know before I start to write new code is
>>>> if is possible to operate a video mipi dsi panel with driver from
>>>> gpu/drm/panel together with omapdrm (v5.7 and later).
>>> 
>>> I did a quick test on a 5.7.6 kernel with the sysc fixes as
>>> suggested by Tony.
>>> 
>>> Then I overwrote the compatible entry of our display to be
>>> orisetech,otm8009a and configured to build the otm8009a panel driver.
>>> 
>>> The panel driver is loaded, but not probed (no call to otm8009a_probe).
>>> It is shown in /sys/bus/mipi-dsi/drivers (and lsmod) but not /sys/bus/mipi-dsi/devices.
>>> 
>>> So what should I try next?
>> 
>> Any suggestions if and how it is possible to use a gpu/drm/panel MIPI DSI
>> video mode panel with omapdrm (on OMAP5)?
> 
> For the DSI panel to probe, the display driver needs to register a DSI
> host with mipi_dsi_host_register(). omapdrm doesn't do so yet, we need
> to integrate Sebastian's "[PATCHv2 00/56] drm/omap: Convert DSI code to
> use drm_mipi_dsi and drm_panel" series first. I'll try to review it in
> the near future.
> 
>> The problem is that our old omapdrm/display driver is broken since v5.7 and

Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
Now I could run an unattended bisect session for the MIPI DSI panel driver
to find as the first bad commit:

commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Wed Feb 26 13:24:59 2020 +0200

   drm/omap: Switch the HDMI and VENC outputs to drm_bridge

This was merged through v5.7-rc1. The problem persists since then up
to v5.8-rc7 and likely also to v5.9.

What I guess from the change hunks is that this is the critical one:

diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
index 9ba7cc8539a1..ce21c798cca6 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
 	}
 
 	if (local_bridge) {
+		if (!out->bridge) {
+			ret = -EPROBE_DEFER;
+			goto error;
+		}
+
 		out->next_bridge = out->bridge;
 		out->bridge = local_bridge;
 	}

Since I have not seen a reference to an omap DSI bridge driver in upstream kernels
I would assume that out->bridge is NULL and therefore probing is deferred forever
and the old MIPI DSI driver (which is still there) is no longer operational.

This is consistent with that our (old omapdrm) panel driver is no longer probed.

>> an experimental gpu/drm/panel driver does not probe. And I assume that
>> omapdrm/display will disappear completely soon.
> 
> Not before Sebastian's series gets integrated.

Is there a simple patch (either from Sebastian's series or other source)
that fixes this regression until Sebastian's series is fully merged and we
can move to a module_mipi_dsi_driver based driver?

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-01 13:43                         ` H. Nikolaus Schaller
@ 2020-08-01 23:22                           ` Sebastian Reichel
  2020-08-05  9:19                             ` H. Nikolaus Schaller
  2020-08-04 12:43                           ` Tomi Valkeinen
  1 sibling, 1 reply; 23+ messages in thread
From: Sebastian Reichel @ 2020-08-01 23:22 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Laurent Pinchart, Tony Lindgren, Tomi Valkeinen, Linux-OMAP,
	Jyri Sarha, kernel, Discussions about the Letux Kernel,
	David Shah


[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]

Hi,

On Sat, Aug 01, 2020 at 03:43:22PM +0200, H. Nikolaus Schaller wrote:
> > Am 24.07.2020 um 03:24 schrieb Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> > On Thu, Jul 23, 2020 at 09:03:49AM +0200, H. Nikolaus Schaller wrote:
> >>> Am 08.07.2020 um 09:52 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >>>> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >>>> 
> >>>> And what I would need to know before I start to write new code is
> >>>> if is possible to operate a video mipi dsi panel with driver from
> >>>> gpu/drm/panel together with omapdrm (v5.7 and later).
> >>> 
> >>> I did a quick test on a 5.7.6 kernel with the sysc fixes as
> >>> suggested by Tony.
> >>> 
> >>> Then I overwrote the compatible entry of our display to be
> >>> orisetech,otm8009a and configured to build the otm8009a panel driver.
> >>> 
> >>> The panel driver is loaded, but not probed (no call to otm8009a_probe).
> >>> It is shown in /sys/bus/mipi-dsi/drivers (and lsmod) but not /sys/bus/mipi-dsi/devices.
> >>> 
> >>> So what should I try next?
> >> 
> >> Any suggestions if and how it is possible to use a gpu/drm/panel MIPI DSI
> >> video mode panel with omapdrm (on OMAP5)?
> > 
> > For the DSI panel to probe, the display driver needs to register a DSI
> > host with mipi_dsi_host_register(). omapdrm doesn't do so yet, we need
> > to integrate Sebastian's "[PATCHv2 00/56] drm/omap: Convert DSI code to
> > use drm_mipi_dsi and drm_panel" series first. I'll try to review it in
> > the near future.
> > 
> >> The problem is that our old omapdrm/display driver is broken since v5.7 and
> 
> Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
> Now I could run an unattended bisect session for the MIPI DSI panel driver
> to find as the first bad commit:
> 
> commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
> Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Date:   Wed Feb 26 13:24:59 2020 +0200
> 
>    drm/omap: Switch the HDMI and VENC outputs to drm_bridge
> 
> This was merged through v5.7-rc1. The problem persists since then up
> to v5.8-rc7 and likely also to v5.9.
> 
> What I guess from the change hunks is that this is the critical one:
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
> index 9ba7cc8539a1..ce21c798cca6 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
>  	}
>  
>  	if (local_bridge) {
> +		if (!out->bridge) {
> +			ret = -EPROBE_DEFER;
> +			goto error;
> +		}
> +

The DSI code calls omapdss_device_init_output with
local_bridge=NULL, so this is no called.

>  		out->next_bridge = out->bridge;
>  		out->bridge = local_bridge;
>  	}
> 
> Since I have not seen a reference to an omap DSI bridge driver in upstream kernels
> I would assume that out->bridge is NULL and therefore probing is deferred forever
> and the old MIPI DSI driver (which is still there) is no longer operational.
> 
> This is consistent with that our (old omapdrm) panel driver is no longer probed.
> 
> >> an experimental gpu/drm/panel driver does not probe. And I assume that
> >> omapdrm/display will disappear completely soon.
> > 
> > Not before Sebastian's series gets integrated.
> 
> Is there a simple patch (either from Sebastian's series or other source)
> that fixes this regression until Sebastian's series is fully merged and we
> can move to a module_mipi_dsi_driver based driver?

The purpose of the whole patchset is to move to drm_panel instead of
the omapdrm specific panel code. Some of the review feedback, that I
received implies that my patchset breaks your usecase (video model
DSI panel). The plan is to send it in smaller parts, which makes the
review process a bit simpler and also the rebasing work of the
series itself. The *.txt -> *.yaml binding patch has been queued
for 5.9 and the DT patches are currently waiting to be queued by
Tony. Next step is preparing for mipi_dsi. I will do this in two
steps:

1. patches up to the point creating problems for video mode
2. all the way to mipi_dsi (but not yet drm_panel)

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-01 13:43                         ` H. Nikolaus Schaller
  2020-08-01 23:22                           ` Sebastian Reichel
@ 2020-08-04 12:43                           ` Tomi Valkeinen
  2020-08-05  9:25                             ` H. Nikolaus Schaller
  1 sibling, 1 reply; 23+ messages in thread
From: Tomi Valkeinen @ 2020-08-04 12:43 UTC (permalink / raw)
  To: H. Nikolaus Schaller, Laurent Pinchart
  Cc: Tony Lindgren, Linux-OMAP, Jyri Sarha, kernel,
	Discussions about the Letux Kernel, David Shah,
	Sebastian Reichel

On 01/08/2020 16:43, H. Nikolaus Schaller wrote:

> Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
> Now I could run an unattended bisect session for the MIPI DSI panel driver
> to find as the first bad commit:
> 
> commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
> Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Date:   Wed Feb 26 13:24:59 2020 +0200
> 
>    drm/omap: Switch the HDMI and VENC outputs to drm_bridge
> 
> This was merged through v5.7-rc1. The problem persists since then up
> to v5.8-rc7 and likely also to v5.9.
> 
> What I guess from the change hunks is that this is the critical one:
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
> index 9ba7cc8539a1..ce21c798cca6 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
>  	}
>  
>  	if (local_bridge) {
> +		if (!out->bridge) {
> +			ret = -EPROBE_DEFER;
> +			goto error;
> +		}
> +
>  		out->next_bridge = out->bridge;
>  		out->bridge = local_bridge;
>  	}
> 
> Since I have not seen a reference to an omap DSI bridge driver in upstream kernels
> I would assume that out->bridge is NULL and therefore probing is deferred forever
> and the old MIPI DSI driver (which is still there) is no longer operational.
> 
> This is consistent with that our (old omapdrm) panel driver is no longer probed.

What happens? Do you get any displays? Or no displays at all? Do you get an error print?

As Sebastian said, this shouldn't prevent DSI from probing. I don't see anything in the commit that
might affect DSI.

Does the board have other display outputs? HDMI? If yes, could you try with HDMI disabled, e.g. set
its status to "disabled" in the .dts.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-01 23:22                           ` Sebastian Reichel
@ 2020-08-05  9:19                             ` H. Nikolaus Schaller
  2020-08-05 11:28                               ` Sebastian Reichel
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-05  9:19 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Laurent Pinchart, Tony Lindgren, Tomi Valkeinen, Linux-OMAP,
	Jyri Sarha, kernel, Discussions about the Letux Kernel,
	David Shah

Hi Sebastian,

> Am 02.08.2020 um 01:22 schrieb Sebastian Reichel <sebastian.reichel@collabora.com>:
> 
>> 
>> Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
>> Now I could run an unattended bisect session for the MIPI DSI panel driver
>> to find as the first bad commit:
>> 
>> commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
>> Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Date:   Wed Feb 26 13:24:59 2020 +0200
>> 
>>   drm/omap: Switch the HDMI and VENC outputs to drm_bridge
>> 
>> This was merged through v5.7-rc1. The problem persists since then up
>> to v5.8-rc7 and likely also to v5.9.
>> 
>> What I guess from the change hunks is that this is the critical one:
>> 
>> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
>> index 9ba7cc8539a1..ce21c798cca6 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/output.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
>> @@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
>> 	}
>> 
>> 	if (local_bridge) {
>> +		if (!out->bridge) {
>> +			ret = -EPROBE_DEFER;
>> +			goto error;
>> +		}
>> +
> 
> The DSI code calls omapdss_device_init_output with
> local_bridge=NULL, so this is no called.

Ok. That is very likely.

Unfortuantely I currently can't do printk tests on real hardware.

>> 
>> This is consistent with that our (old omapdrm) panel driver is no longer probed.
>> 
>>>> an experimental gpu/drm/panel driver does not probe. And I assume that
>>>> omapdrm/display will disappear completely soon.
>>> 
>>> Not before Sebastian's series gets integrated.
>> 
>> Is there a simple patch (either from Sebastian's series or other source)
>> that fixes this regression until Sebastian's series is fully merged and we
>> can move to a module_mipi_dsi_driver based driver?
> 
> The purpose of the whole patchset is to move to drm_panel instead of
> the omapdrm specific panel code.

Indeed. But it should not break the omapdrm/dss/dsi.c driver which is not moved.

> Some of the review feedback, that I
> received implies that my patchset breaks your usecase (video model
> DSI panel). The plan is to send it in smaller parts, which makes the
> review process a bit simpler and also the rebasing work of the
> series itself. The *.txt -> *.yaml binding patch has been queued
> for 5.9 and the DT patches are currently waiting to be queued by
> Tony. Next step is preparing for mipi_dsi. I will do this in two
> steps:
> 
> 1. patches up to the point creating problems for video mode

The problem is that our dsi video mode panel is already broken since
v5.7-rc1. Before any of your patches is merged.

What I do not yet understand is how Laurent's patch should be able to break it.

> 2. all the way to mipi_dsi (but not yet drm_panel)

Yes, that will be the next step. Before I can help there with testing
we need to fix dsi with v5.7ff

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-04 12:43                           ` Tomi Valkeinen
@ 2020-08-05  9:25                             ` H. Nikolaus Schaller
  2020-08-05 11:07                               ` Sebastian Reichel
  0 siblings, 1 reply; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-05  9:25 UTC (permalink / raw)
  To: Tomi Valkeinen
  Cc: Laurent Pinchart, Tony Lindgren, Linux-OMAP, Jyri Sarha, kernel,
	Discussions about the Letux Kernel, David Shah,
	Sebastian Reichel

Hi Tomi,

> Am 04.08.2020 um 14:43 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
> 
> On 01/08/2020 16:43, H. Nikolaus Schaller wrote:
> 
>> Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
>> Now I could run an unattended bisect session for the MIPI DSI panel driver
>> to find as the first bad commit:
>> 
>> commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
>> Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Date:   Wed Feb 26 13:24:59 2020 +0200
>> 
>>   drm/omap: Switch the HDMI and VENC outputs to drm_bridge
>> 
>> This was merged through v5.7-rc1. The problem persists since then up
>> to v5.8-rc7 and likely also to v5.9.
>> 
>> What I guess from the change hunks is that this is the critical one:
>> 
>> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
>> index 9ba7cc8539a1..ce21c798cca6 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/output.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
>> @@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
>> 	}
>> 
>> 	if (local_bridge) {
>> +		if (!out->bridge) {
>> +			ret = -EPROBE_DEFER;
>> +			goto error;
>> +		}
>> +
>> 		out->next_bridge = out->bridge;
>> 		out->bridge = local_bridge;
>> 	}
>> 
>> Since I have not seen a reference to an omap DSI bridge driver in upstream kernels
>> I would assume that out->bridge is NULL and therefore probing is deferred forever
>> and the old MIPI DSI driver (which is still there) is no longer operational.
>> 
>> This is consistent with that our (old omapdrm) panel driver is no longer probed.
> 
> What happens? Do you get any displays? Or no displays at all? Do you get an error print?
> 
> As Sebastian said, this shouldn't prevent DSI from probing. I don't see anything in the commit that
> might affect DSI.

Yes, that is indeed strange. The only potential direct reason I could imagine is the
additional test for out-bridge, but with Sebastian's explanation it is not
even called for DSI.

Maybe it is a false report by git bisect because this patch enables a change somewhere
else for the first time, which affects the DSI setup indirectly.

I have seen that there now is a similar, but not identical report for the N900 panel.

> 
> Does the board have other display outputs? HDMI? If yes, could you try with HDMI disabled, e.g. set
> its status to "disabled" in the .dts.

My good/bad indicator is that there is no /dev/fb0 created any more. I have not
checked for HDMI but it is likely also missing then. Basically it stopped working
with v5.7-rc1 (as the basis where we add our private panel driver, some PMU/charger
driver, DTS on top) and bisect did report this commit.

Unfortunately I currently can't do tests on real hardware and play around with printk
in the code for the next weeks. Or partially reverting the patch step by step to see
which change has an influence.

BR,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-05  9:25                             ` H. Nikolaus Schaller
@ 2020-08-05 11:07                               ` Sebastian Reichel
  2020-08-05 11:14                                 ` H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: Sebastian Reichel @ 2020-08-05 11:07 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Tomi Valkeinen, Laurent Pinchart, Tony Lindgren, Linux-OMAP,
	Jyri Sarha, kernel, Discussions about the Letux Kernel,
	David Shah


[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]

Hi,

On Wed, Aug 05, 2020 at 11:25:58AM +0200, H. Nikolaus Schaller wrote:
> > Am 04.08.2020 um 14:43 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
> > On 01/08/2020 16:43, H. Nikolaus Schaller wrote:
> >> Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
> >> Now I could run an unattended bisect session for the MIPI DSI panel driver
> >> to find as the first bad commit:
> >> 
> >> commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
> >> Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> Date:   Wed Feb 26 13:24:59 2020 +0200
> >> 
> >>   drm/omap: Switch the HDMI and VENC outputs to drm_bridge
> >> 
> >> This was merged through v5.7-rc1. The problem persists since then up
> >> to v5.8-rc7 and likely also to v5.9.
> >> 
> >> What I guess from the change hunks is that this is the critical one:
> >> 
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
> >> index 9ba7cc8539a1..ce21c798cca6 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> >> @@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
> >> 	}
> >> 
> >> 	if (local_bridge) {
> >> +		if (!out->bridge) {
> >> +			ret = -EPROBE_DEFER;
> >> +			goto error;
> >> +		}
> >> +
> >> 		out->next_bridge = out->bridge;
> >> 		out->bridge = local_bridge;
> >> 	}
> >> 
> >> Since I have not seen a reference to an omap DSI bridge driver in upstream kernels
> >> I would assume that out->bridge is NULL and therefore probing is deferred forever
> >> and the old MIPI DSI driver (which is still there) is no longer operational.
> >> 
> >> This is consistent with that our (old omapdrm) panel driver is no longer probed.
> > 
> > What happens? Do you get any displays? Or no displays at all? Do
> > you get an error print?
> > 
> > As Sebastian said, this shouldn't prevent DSI from probing. I
> > don't see anything in the commit that might affect DSI.
> 
> Yes, that is indeed strange. The only potential direct reason I could imagine is the
> additional test for out-bridge, but with Sebastian's explanation it is not
> even called for DSI.
> 
> Maybe it is a false report by git bisect because this patch enables a change somewhere
> else for the first time, which affects the DSI setup indirectly.
> 
> I have seen that there now is a similar, but not identical report for the N900 panel.

Note, that the N900 has an SDI panel, which is different from DSI.

> > Does the board have other display outputs? HDMI? If yes, could
> > you try with HDMI disabled, e.g. set its status to "disabled" in
> > the .dts.
> 
> My good/bad indicator is that there is no /dev/fb0 created any more. I have not
> checked for HDMI but it is likely also missing then. Basically it stopped working
> with v5.7-rc1 (as the basis where we add our private panel driver, some PMU/charger
> driver, DTS on top) and bisect did report this commit.
> 
> Unfortunately I currently can't do tests on real hardware and play around with printk
> in the code for the next weeks. Or partially reverting the patch step by step to see
> which change has an influence.

So it might be HDMI (or VENC) not probing successfully and
then resulting in -EPROBE_DEFER for omapdrm with no connection to
DSI at all. I suggest to disable all non-DSI video devices in
devicetree and check if this results in DSI panel coming up.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-05 11:07                               ` Sebastian Reichel
@ 2020-08-05 11:14                                 ` H. Nikolaus Schaller
  0 siblings, 0 replies; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-05 11:14 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Tomi Valkeinen, Laurent Pinchart, Tony Lindgren, Linux-OMAP,
	Jyri Sarha, kernel, Discussions about the Letux Kernel,
	David Shah


> Am 05.08.2020 um 13:07 schrieb Sebastian Reichel <sebastian.reichel@collabora.com>:
> 
> Hi,
> 
> On Wed, Aug 05, 2020 at 11:25:58AM +0200, H. Nikolaus Schaller wrote:
>>> Am 04.08.2020 um 14:43 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>> On 01/08/2020 16:43, H. Nikolaus Schaller wrote:
>>>> Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
>>>> Now I could run an unattended bisect session for the MIPI DSI panel driver
>>>> to find as the first bad commit:
>>>> 
>>>> commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
>>>> Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>>> Date:   Wed Feb 26 13:24:59 2020 +0200
>>>> 
>>>>  drm/omap: Switch the HDMI and VENC outputs to drm_bridge
>>>> 
>>>> This was merged through v5.7-rc1. The problem persists since then up
>>>> to v5.8-rc7 and likely also to v5.9.
>>>> 
>>>> What I guess from the change hunks is that this is the critical one:
>>>> 
>>>> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
>>>> index 9ba7cc8539a1..ce21c798cca6 100644
>>>> --- a/drivers/gpu/drm/omapdrm/dss/output.c
>>>> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
>>>> @@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
>>>> 	}
>>>> 
>>>> 	if (local_bridge) {
>>>> +		if (!out->bridge) {
>>>> +			ret = -EPROBE_DEFER;
>>>> +			goto error;
>>>> +		}
>>>> +
>>>> 		out->next_bridge = out->bridge;
>>>> 		out->bridge = local_bridge;
>>>> 	}
>>>> 
>>>> Since I have not seen a reference to an omap DSI bridge driver in upstream kernels
>>>> I would assume that out->bridge is NULL and therefore probing is deferred forever
>>>> and the old MIPI DSI driver (which is still there) is no longer operational.
>>>> 
>>>> This is consistent with that our (old omapdrm) panel driver is no longer probed.
>>> 
>>> What happens? Do you get any displays? Or no displays at all? Do
>>> you get an error print?
>>> 
>>> As Sebastian said, this shouldn't prevent DSI from probing. I
>>> don't see anything in the commit that might affect DSI.
>> 
>> Yes, that is indeed strange. The only potential direct reason I could imagine is the
>> additional test for out-bridge, but with Sebastian's explanation it is not
>> even called for DSI.
>> 
>> Maybe it is a false report by git bisect because this patch enables a change somewhere
>> else for the first time, which affects the DSI setup indirectly.
>> 
>> I have seen that there now is a similar, but not identical report for the N900 panel.
> 
> Note, that the N900 has an SDI panel, which is different from DSI.

Yes I know. But the symptom and the -rc or patch set where it appears for the first time
seems to be the same. So it may have a similar common reason.

> 
>>> Does the board have other display outputs? HDMI? If yes, could
>>> you try with HDMI disabled, e.g. set its status to "disabled" in
>>> the .dts.
>> 
>> My good/bad indicator is that there is no /dev/fb0 created any more. I have not
>> checked for HDMI but it is likely also missing then. Basically it stopped working
>> with v5.7-rc1 (as the basis where we add our private panel driver, some PMU/charger
>> driver, DTS on top) and bisect did report this commit.
>> 
>> Unfortunately I currently can't do tests on real hardware and play around with printk
>> in the code for the next weeks. Or partially reverting the patch step by step to see
>> which change has an influence.
> 
> So it might be HDMI (or VENC) not probing successfully and
> then resulting in -EPROBE_DEFER for omapdrm with no connection to
> DSI at all. I suggest to disable all non-DSI video devices in
> devicetree and check if this results in DSI panel coming up.

Ah, ok. There is no venc on omap5 but HDMI... Good thing to test.

BR,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-05  9:19                             ` H. Nikolaus Schaller
@ 2020-08-05 11:28                               ` Sebastian Reichel
  2020-08-05 11:49                                 ` H. Nikolaus Schaller
  0 siblings, 1 reply; 23+ messages in thread
From: Sebastian Reichel @ 2020-08-05 11:28 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Laurent Pinchart, Tony Lindgren, Tomi Valkeinen, Linux-OMAP,
	Jyri Sarha, kernel, Discussions about the Letux Kernel,
	David Shah


[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Hi,

On Wed, Aug 05, 2020 at 11:19:20AM +0200, H. Nikolaus Schaller wrote:
> What I do not yet understand is how Laurent's patch should be able
> to break it.

omapdrm will not probe successfully if any DT enabled component
does not probe correctly. Since the patch you identified touched
HDMI and VENC and you are probably using HDMI, I suggest looking
there first.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: module_mipi_dsi_driver panel with omapdrm?
  2020-08-05 11:28                               ` Sebastian Reichel
@ 2020-08-05 11:49                                 ` H. Nikolaus Schaller
  0 siblings, 0 replies; 23+ messages in thread
From: H. Nikolaus Schaller @ 2020-08-05 11:49 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Laurent Pinchart, Tony Lindgren, Tomi Valkeinen, Linux-OMAP,
	Jyri Sarha, kernel, Discussions about the Letux Kernel,
	David Shah

Hi,

> Am 05.08.2020 um 13:28 schrieb Sebastian Reichel <sebastian.reichel@collabora.com>:
> 
> Hi,
> 
> On Wed, Aug 05, 2020 at 11:19:20AM +0200, H. Nikolaus Schaller wrote:
>> What I do not yet understand is how Laurent's patch should be able
>> to break it.
> 
> omapdrm will not probe successfully if any DT enabled component
> does not probe correctly. Since the patch you identified touched
> HDMI and VENC and you are probably using HDMI, I suggest looking
> there first.

Yes, that is a very good explanation.

Maybe there is a subtle change in how the HDMI connector has to be defined
which is missing in our (private) DTB. Maybe the OMAP5-uEVM DTS gives a hint.

A quick check shows last hdmi specific change for omap5-board-common or uevm
was in 2017 but I may have missed something.

There are 715a5a978733f0 and 671ab615bd507f which arrived in v5.7-rc1 as well
and are related to hdmi clocks. So this may be (or not) and influencing factor.

BR and thanks,
Nikolaus


^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, back to index

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-05  6:52 OMAP5: inconsistency between target-module and dsi_of_data_omap5 H. Nikolaus Schaller
2020-07-05  7:40 ` H. Nikolaus Schaller
2020-07-05 13:47   ` H. Nikolaus Schaller
2020-07-05 14:26     ` Tony Lindgren
2020-07-05 14:36       ` Tony Lindgren
2020-07-05 15:40         ` H. Nikolaus Schaller
2020-07-06 14:36           ` Tony Lindgren
2020-07-06 16:10             ` H. Nikolaus Schaller
2020-07-07 18:01               ` Tony Lindgren
2020-07-07 19:04                 ` H. Nikolaus Schaller
2020-07-08  7:52                   ` OMAP5: inconsistency between target-module and dsi_of_data_omap5 / module_mipi_dsi_driver panel with omapdrm H. Nikolaus Schaller
2020-07-23  7:03                     ` Re:module_mipi_dsi_driver panel with omapdrm? H. Nikolaus Schaller
2020-07-24  1:24                       ` module_mipi_dsi_driver " Laurent Pinchart
2020-07-24  5:50                         ` H. Nikolaus Schaller
2020-08-01 13:43                         ` H. Nikolaus Schaller
2020-08-01 23:22                           ` Sebastian Reichel
2020-08-05  9:19                             ` H. Nikolaus Schaller
2020-08-05 11:28                               ` Sebastian Reichel
2020-08-05 11:49                                 ` H. Nikolaus Schaller
2020-08-04 12:43                           ` Tomi Valkeinen
2020-08-05  9:25                             ` H. Nikolaus Schaller
2020-08-05 11:07                               ` Sebastian Reichel
2020-08-05 11:14                                 ` H. Nikolaus Schaller

Linux-OMAP Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-omap/0 linux-omap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-omap linux-omap/ https://lore.kernel.org/linux-omap \
		linux-omap@vger.kernel.org
	public-inbox-index linux-omap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-omap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git