OMAP5: inconsistency between target-module and dsi_of_data_omap5

OMAP5: inconsistency between target-module and dsi_of_data_omap5

[H. Nikolaus Schaller]

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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[H. Nikolaus Schaller]

> 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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[H. Nikolaus Schaller]

> 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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[Tony Lindgren]

* 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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[Tony Lindgren]

* 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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[H. Nikolaus Schaller]

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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[Tony Lindgren]

* 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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[H. Nikolaus Schaller]

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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[Tony Lindgren]

* 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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5

[H. Nikolaus Schaller]

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

Re: OMAP5: inconsistency between target-module and dsi_of_data_omap5 / module_mipi_dsi_driver panel with omapdrm

[H. Nikolaus Schaller]

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

Re:module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[Laurent Pinchart]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[Sebastian Reichel]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[Tomi Valkeinen]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[Sebastian Reichel]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

> 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

Re: module_mipi_dsi_driver panel with omapdrm?

[Sebastian Reichel]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

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

Re: module_mipi_dsi_driver panel with omapdrm?

[Tomi Valkeinen]

On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
> 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.

HDMI should "just work", and has been tested. But maybe there's some conflict with HDMI and DSI.

 Tomi

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

Re: module_mipi_dsi_driver panel with omapdrm?

[David Shah]

I had a moment to give letux-5.7.y a test on the Pyra hardware.

I notice an error in dmesg:

 DSI: omapdss DSI error: unsupported DSI module

which comes from this code (with a small patch added by me):

	d = dsi->data->modules;
	while (d->address != 0 && d->address != dsi_mem->start)
		d++;

	if (d->address == 0) {
		DSSERR("unsupported DSI module (start: %08x)\n",
dsi_mem->start);
		return -ENODEV;
	}

"start" here is c0b3ba5c - a kernel virtual address - which definitely
doesn't seem right as it would never match. 

Not sure my kernel-fu is quite up to tracking this down yet, but I will
keep trying to trace out what is happening.

Best

Davidg

On Wed, 2020-08-05 at 15:08 +0300, Tomi Valkeinen wrote:
> On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
> > 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.
> 
> HDMI should "just work", and has been tested. But maybe there's some
> conflict with HDMI and DSI.
> 
>  Tomi
> 

Re: [Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[David Shah]

Sorry, my error. I forgot the Pyra is LPAE and therefore using 64-bit
physical addresses.

The start is indeed a correct physical address, 0x58005000, but off by
0x1000 from what the DSI driver is expecting.

On Thu, 2020-08-06 at 16:50 +0100, David Shah wrote:
> I had a moment to give letux-5.7.y a test on the Pyra hardware.
> 
> I notice an error in dmesg:
> 
>  DSI: omapdss DSI error: unsupported DSI module
> 
> which comes from this code (with a small patch added by me):
> 
> 	d = dsi->data->modules;
> 	while (d->address != 0 && d->address != dsi_mem->start)
> 		d++;
> 
> 	if (d->address == 0) {
> 		DSSERR("unsupported DSI module (start: %08x)\n",
> dsi_mem->start);
> 		return -ENODEV;
> 	}
> 
> "start" here is c0b3ba5c - a kernel virtual address - which
> definitely
> doesn't seem right as it would never match. 
> 
> Not sure my kernel-fu is quite up to tracking this down yet, but I
> will
> keep trying to trace out what is happening.
> 
> Best
> 
> Davidg
> 
> On Wed, 2020-08-05 at 15:08 +0300, Tomi Valkeinen wrote:
> > On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
> > > 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.
> > 
> > HDMI should "just work", and has been tested. But maybe there's
> > some
> > conflict with HDMI and DSI.
> > 
> >  Tomi
> > 
> 
> _______________________________________________
> https://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

Re: [Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[David Shah]

Following a bit of testing, the DSI issues are fixed by 
https://github.com/daveshah1/pyra-kernel-devel/commit/3161275854a0f2cd44a55b8eb039bd201f894486
 (I will prepare a proper patch set shortly). This makes the display
work with HDMI disabled.

There also seems to be a race condition between the hdmi0 connector
and tpd12s015 "encoder". This results in the tpd12s015 permanently
returning EPROBE_DEFER and the display subsystem never successfully
probing.

Reversing the order of the encoder and connector in the device tree
(omap5-board-common.dtsi) makes the display work again with HDMI
enabled; as does adding some printks to the display-connector driver.

On Thu, 2020-08-06 at 17:04 +0100, David Shah wrote:
> Sorry, my error. I forgot the Pyra is LPAE and therefore using 64-bit
> physical addresses.
> 
> The start is indeed a correct physical address, 0x58005000, but off
> by
> 0x1000 from what the DSI driver is expecting.
> 
> On Thu, 2020-08-06 at 16:50 +0100, David Shah wrote:
> > I had a moment to give letux-5.7.y a test on the Pyra hardware.
> > 
> > I notice an error in dmesg:
> > 
> >  DSI: omapdss DSI error: unsupported DSI module
> > 
> > which comes from this code (with a small patch added by me):
> > 
> > 	d = dsi->data->modules;
> > 	while (d->address != 0 && d->address != dsi_mem->start)
> > 		d++;
> > 
> > 	if (d->address == 0) {
> > 		DSSERR("unsupported DSI module (start: %08x)\n",
> > dsi_mem->start);
> > 		return -ENODEV;
> > 	}
> > 
> > "start" here is c0b3ba5c - a kernel virtual address - which
> > definitely
> > doesn't seem right as it would never match. 
> > 
> > Not sure my kernel-fu is quite up to tracking this down yet, but I
> > will
> > keep trying to trace out what is happening.
> > 
> > Best
> > 
> > Davidg
> > 
> > On Wed, 2020-08-05 at 15:08 +0300, Tomi Valkeinen wrote:
> > > On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
> > > > 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.
> > > 
> > > HDMI should "just work", and has been tested. But maybe there's
> > > some
> > > conflict with HDMI and DSI.
> > > 
> > >  Tomi
> > > 
> > 
> > _______________________________________________
> > https://projects.goldelico.com/p/gta04-kernel/
> > Letux-kernel mailing list
> > Letux-kernel@openphoenux.org
> > http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> 
> _______________________________________________
> Kernel mailing list
> Kernel@pyra-handheld.com
> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

Re: [Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

Hi David,
thanks for finding a fix faster than I could take a look at it!

> Am 06.08.2020 um 20:44 schrieb David Shah <dave@ds0.me>:
> 
> Following a bit of testing, the DSI issues are fixed by 
> https://github.com/daveshah1/pyra-kernel-devel/commit/3161275854a0f2cd44a55b8eb039bd201f894486
> (I will prepare a proper patch set shortly).
> This makes the display
> work with HDMI disabled.

So it seems that my conjecture:

> Am 05.08.2020 um 13:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> 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) an influencing factor.

was almost true. You patch seems to fix
5a507162f096b5 ("ARM: dts: Configure interconnect target module for omap5 dsi1")

> There also seems to be a race condition between the hdmi0 connector
> and tpd12s015 "encoder". This results in the tpd12s015 permanently
> returning EPROBE_DEFER and the display subsystem never successfully
> probing.
> 
> Reversing the order of the encoder and connector in the device tree
> (omap5-board-common.dtsi) makes the display work again with HDMI
> enabled; as does adding some printks to the display-connector driver.

Good to know where to look at.

So we will then have a fix for v5.7 and v5.8 and can start to test/compare
our module_mipi_dsi_driver with Sebastian's patches as soon as they
arrive and see what happens.

BR and thanks,
Nikolaus

> 
> On Thu, 2020-08-06 at 17:04 +0100, David Shah wrote:
>> Sorry, my error. I forgot the Pyra is LPAE and therefore using 64-bit
>> physical addresses.
>> 
>> The start is indeed a correct physical address, 0x58005000, but off
>> by
>> 0x1000 from what the DSI driver is expecting.
>> 
>> On Thu, 2020-08-06 at 16:50 +0100, David Shah wrote:
>>> I had a moment to give letux-5.7.y a test on the Pyra hardware.
>>> 
>>> I notice an error in dmesg:
>>> 
>>> DSI: omapdss DSI error: unsupported DSI module
>>> 
>>> which comes from this code (with a small patch added by me):
>>> 
>>> 	d = dsi->data->modules;
>>> 	while (d->address != 0 && d->address != dsi_mem->start)
>>> 		d++;
>>> 
>>> 	if (d->address == 0) {
>>> 		DSSERR("unsupported DSI module (start: %08x)\n",
>>> dsi_mem->start);
>>> 		return -ENODEV;
>>> 	}
>>> 
>>> "start" here is c0b3ba5c - a kernel virtual address - which
>>> definitely
>>> doesn't seem right as it would never match. 
>>> 
>>> Not sure my kernel-fu is quite up to tracking this down yet, but I
>>> will
>>> keep trying to trace out what is happening.
>>> 
>>> Best
>>> 
>>> Davidg
>>> 
>>> On Wed, 2020-08-05 at 15:08 +0300, Tomi Valkeinen wrote:
>>>> On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
>>>>> 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.
>>>> 
>>>> HDMI should "just work", and has been tested. But maybe there's
>>>> some
>>>> conflict with HDMI and DSI.
>>>> 
>>>> Tomi
>>>> 
>>> 
>>> _______________________________________________
>>> https://projects.goldelico.com/p/gta04-kernel/
>>> Letux-kernel mailing list
>>> Letux-kernel@openphoenux.org
>>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>> 
>> _______________________________________________
>> Kernel mailing list
>> Kernel@pyra-handheld.com
>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
> 

Re: [Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[David Shah]

Annoyingly, the display has started working consistently :) but I think there still
is a latent bug related to module load order or similar that would be nice to fix if we can
find a way to reproduce it reliably.

There is at least one other display related issue I notice in v5.7, that I don't 
think is related (but might be in some subtle way). With the omap5 X11 driver,
once the display has gone into DPMS sleep, and is then turned on again by DPMS,
it fails to turn on and I get a number of timeout errors:

[  393.549837] omapdrm omapdrm.0: atomic complete timeout (pipe 0)!
[  404.216533] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:55:crtc-0] flip_done timed out
[  414.453404] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:32:plane-0] flip_done timed out
[  414.723310] omapdrm omapdrm.0: atomic complete timeout (pipe 0)!
[  414.729686] ------------[ cut here ]------------
[  414.736909] WARNING: CPU: 0 PID: 4062 at drivers/gpu/drm/drm_atomic_helper.c:2312 drm_atomic_helper_commit_hw_done+0x140/0x15c [drm_kms_helper]
[  414.751458] Modules linked in: rfcomm cmac ctr ccm omapdrm snd_soc_omap_hdmi wl18xx bnep wlcore mac80211 panel_boe_w677l snd_soc_dmic cfg80211 libarc4 omapdss snd_soc_spdif_tx dwc3 omapdss_base
drm_kms_helper roles syscopyarea sysfillrect sysimgblt fb_sys_fops pvrsrvkm_omap5_sgx544_116 cec etnaviv ti_tpd12s015 display_connector gpu_sched snd_soc_simple_card snd_soc_omap_abe_twl6040 drm
snd_soc_simple_card_utils snd_soc_twl6040 wwan_on_off leds_gpio drm_panel_orientation_quirks snd_soc_gtm601 pwm_omap_dmtimer snd_soc_w2cbw003_bt ehci_omap binfmt_misc dwc3_omap wlcore_sdio hci_uart
btbcm snd_soc_ts3a227e bmp280_spi bmg160_i2c bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn bmg160_core leds_is31fl319x tsc2007 industrialio_triggered_buffer bmp280_i2c bno055
bluetooth palmas_gpadc gpio_twl6040 kfifo_buf bmp280 tca8418_keypad twl6040_vibra ecdh_generic industrialio ecc bq27xxx_battery_i2c input_polldev palmas_pwrbutton bq2429x_charger bq27xxx_battery
as5013 ina2xx usb3503
[  414.751690]  snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap_aess snd_soc_ti_sdma sunrpc ip_tables x_tables ipv6 nf_defrag_ipv6 autofs4
[  414.857830] CPU: 0 PID: 4062 Comm: kworker/0:0 Tainted: G        W         5.7.11-letux-lpae-dave #14
[  414.867564] Hardware name: Generic OMAP5 (Flattened Device Tree)
[  414.873974] Workqueue: events drm_mode_rmfb_work_fn [drm]
[  414.879725] [<c0211344>] (unwind_backtrace) from [<c020b8a4>] (show_stack+0x10/0x14)
[  414.887920] [<c020b8a4>] (show_stack) from [<c061cc20>] (dump_stack+0x90/0xa4)
[  414.895549] [<c061cc20>] (dump_stack) from [<c0231088>] (__warn+0xd0/0xf8)
[  414.902813] [<c0231088>] (__warn) from [<c0231448>] (warn_slowpath_fmt+0x64/0xc4)
[  414.910747] [<c0231448>] (warn_slowpath_fmt) from [<bf318880>] (drm_atomic_helper_commit_hw_done+0x140/0x15c [drm_kms_helper])
[  414.922807] [<bf318880>] (drm_atomic_helper_commit_hw_done [drm_kms_helper]) from [<bf41b3f4>] (omap_atomic_commit_tail+0x6c/0xc0 [omapdrm])
[  414.936138] [<bf41b3f4>] (omap_atomic_commit_tail [omapdrm]) from [<bf318d00>] (commit_tail+0x9c/0x194 [drm_kms_helper])
[  414.947643] [<bf318d00>] (commit_tail [drm_kms_helper]) from [<bf319a38>] (drm_atomic_helper_commit+0x134/0x158 [drm_kms_helper])
[  414.960008] [<bf319a38>] (drm_atomic_helper_commit [drm_kms_helper]) from [<bf395e68>] (drm_framebuffer_remove+0x3a4/0x434 [drm])
[  414.972393] [<bf395e68>] (drm_framebuffer_remove [drm]) from [<bf395f30>] (drm_mode_rmfb_work_fn+0x38/0x48 [drm])
[  414.983288] [<bf395f30>] (drm_mode_rmfb_work_fn [drm]) from [<c024d490>] (process_one_work+0x1e8/0x590)
[  414.993206] [<c024d490>] (process_one_work) from [<c024da80>] (worker_thread+0x248/0x528)
[  415.001842] [<c024da80>] (worker_thread) from [<c0253d48>] (kthread+0x190/0x194)
[  415.009655] [<c0253d48>] (kthread) from [<c0200138>] (ret_from_fork+0x14/0x3c)
[  415.017284] Exception stack(0xe109bfb0 to 0xe109bff8)
[  415.022625] bfa0:                                     00000000 00000000 00000000 00000000
[  415.031261] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  415.039898] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[  415.057506] ---[ end trace ce82871c75f51dc1 ]---
[  415.313182] omapdrm omapdrm.0: atomic complete timeout (pipe 0)!
[  425.330241] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:55:crtc-0] flip_done timed out
[  435.567303] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:54:DSI-1] flip_done timed out

Something else to look into.

Best

David

On Thu, 2020-08-06 at 21:01 +0200, H. Nikolaus Schaller wrote:
> Hi David,
> thanks for finding a fix faster than I could take a look at it!
> 
> > Am 06.08.2020 um 20:44 schrieb David Shah <dave@ds0.me>:
> > 
> > Following a bit of testing, the DSI issues are fixed by 
> > https://github.com/daveshah1/pyra-kernel-devel/commit/3161275854a0f2cd44a55b8eb039bd201f894486
> > (I will prepare a proper patch set shortly).
> > This makes the display
> > work with HDMI disabled.
> 
> So it seems that my conjecture:
> 
> > Am 05.08.2020 um 13:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > 
> > 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) an influencing factor.
> 
> was almost true. You patch seems to fix
> 5a507162f096b5 ("ARM: dts: Configure interconnect target module for omap5 dsi1")
> 
> > There also seems to be a race condition between the hdmi0 connector
> > and tpd12s015 "encoder". This results in the tpd12s015 permanently
> > returning EPROBE_DEFER and the display subsystem never successfully
> > probing.
> > 
> > Reversing the order of the encoder and connector in the device tree
> > (omap5-board-common.dtsi) makes the display work again with HDMI
> > enabled; as does adding some printks to the display-connector driver.
> 
> Good to know where to look at.
> 
> So we will then have a fix for v5.7 and v5.8 and can start to test/compare
> our module_mipi_dsi_driver with Sebastian's patches as soon as they
> arrive and see what happens.
> 
> BR and thanks,
> Nikolaus
> 
> > On Thu, 2020-08-06 at 17:04 +0100, David Shah wrote:
> > > Sorry, my error. I forgot the Pyra is LPAE and therefore using 64-bit
> > > physical addresses.
> > > 
> > > The start is indeed a correct physical address, 0x58005000, but off
> > > by
> > > 0x1000 from what the DSI driver is expecting.
> > > 
> > > On Thu, 2020-08-06 at 16:50 +0100, David Shah wrote:
> > > > I had a moment to give letux-5.7.y a test on the Pyra hardware.
> > > > 
> > > > I notice an error in dmesg:
> > > > 
> > > > DSI: omapdss DSI error: unsupported DSI module
> > > > 
> > > > which comes from this code (with a small patch added by me):
> > > > 
> > > > 	d = dsi->data->modules;
> > > > 	while (d->address != 0 && d->address != dsi_mem->start)
> > > > 		d++;
> > > > 
> > > > 	if (d->address == 0) {
> > > > 		DSSERR("unsupported DSI module (start: %08x)\n",
> > > > dsi_mem->start);
> > > > 		return -ENODEV;
> > > > 	}
> > > > 
> > > > "start" here is c0b3ba5c - a kernel virtual address - which
> > > > definitely
> > > > doesn't seem right as it would never match. 
> > > > 
> > > > Not sure my kernel-fu is quite up to tracking this down yet, but I
> > > > will
> > > > keep trying to trace out what is happening.
> > > > 
> > > > Best
> > > > 
> > > > Davidg
> > > > 
> > > > On Wed, 2020-08-05 at 15:08 +0300, Tomi Valkeinen wrote:
> > > > > On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
> > > > > > 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.
> > > > > 
> > > > > HDMI should "just work", and has been tested. But maybe there's
> > > > > some
> > > > > conflict with HDMI and DSI.
> > > > > 
> > > > > Tomi
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > https://projects.goldelico.com/p/gta04-kernel/
> > > > Letux-kernel mailing list
> > > > Letux-kernel@openphoenux.org
> > > > http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> > > 
> > > _______________________________________________
> > > Kernel mailing list
> > > Kernel@pyra-handheld.com
> > > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

Re: [Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[Tomi Valkeinen]

Hi David,

On 06/08/2020 21:44, David Shah wrote:
> Following a bit of testing, the DSI issues are fixed by 
> https://github.com/daveshah1/pyra-kernel-devel/commit/3161275854a0f2cd44a55b8eb039bd201f894486
>  (I will prepare a proper patch set shortly). This makes the display
> work with HDMI disabled.

Good catch, looks like a correct fix.

> There also seems to be a race condition between the hdmi0 connector
> and tpd12s015 "encoder". This results in the tpd12s015 permanently
> returning EPROBE_DEFER and the display subsystem never successfully
> probing.
> 
> Reversing the order of the encoder and connector in the device tree
> (omap5-board-common.dtsi) makes the display work again with HDMI
> enabled; as does adding some printks to the display-connector driver.

Ok, interesting... I was trying to boot up my omap5 uevm, but it halts during the boot, last print
being "palmas 0-0048: Irq flag is 0x00000008".

I'll try some other boards which have similar HDMI setup to see if I can reproduce.

 Tomi

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

Re: [Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

Hi David,

> Am 06.08.2020 um 20:44 schrieb David Shah <dave@ds0.me>:
> 
> Following a bit of testing, the DSI issues are fixed by 
> https://github.com/daveshah1/pyra-kernel-devel/commit/3161275854a0f2cd44a55b8eb039bd201f894486
> (I will prepare a proper patch set shortly). This makes the display
> work with HDMI disabled.

yes, it makes the LCD work (tested so far on 5.8-rc7).
But even with HDMI enabled.

> 
> There also seems to be a race condition between the hdmi0 connector
> and tpd12s015 "encoder". This results in the tpd12s015 permanently
> returning EPROBE_DEFER and the display subsystem never successfully
> probing.

> 
> Reversing the order of the encoder and connector in the device tree
> (omap5-board-common.dtsi) makes the display work again with HDMI
> enabled; as does adding some printks to the display-connector driver.

I didn't have to disable or reverse the order. Maybe the speed of the SD
card also has an influcence...

So I'll backport it to all our affected Letux kernels until it is merged/fixed
upstream.

Then we can work on debugging/testing a module_mipi_dsi_driver based panel
drivers as soon as Sebastian's new patches become available.

BR and thanks,
Nikolaus

> 
> On Thu, 2020-08-06 at 17:04 +0100, David Shah wrote:
>> Sorry, my error. I forgot the Pyra is LPAE and therefore using 64-bit
>> physical addresses.
>> 
>> The start is indeed a correct physical address, 0x58005000, but off
>> by
>> 0x1000 from what the DSI driver is expecting.
>> 
>> On Thu, 2020-08-06 at 16:50 +0100, David Shah wrote:
>>> I had a moment to give letux-5.7.y a test on the Pyra hardware.
>>> 
>>> I notice an error in dmesg:
>>> 
>>> DSI: omapdss DSI error: unsupported DSI module
>>> 
>>> which comes from this code (with a small patch added by me):
>>> 
>>> 	d = dsi->data->modules;
>>> 	while (d->address != 0 && d->address != dsi_mem->start)
>>> 		d++;
>>> 
>>> 	if (d->address == 0) {
>>> 		DSSERR("unsupported DSI module (start: %08x)\n",
>>> dsi_mem->start);
>>> 		return -ENODEV;
>>> 	}
>>> 
>>> "start" here is c0b3ba5c - a kernel virtual address - which
>>> definitely
>>> doesn't seem right as it would never match. 
>>> 
>>> Not sure my kernel-fu is quite up to tracking this down yet, but I
>>> will
>>> keep trying to trace out what is happening.
>>> 
>>> Best
>>> 
>>> Davidg
>>> 
>>> On Wed, 2020-08-05 at 15:08 +0300, Tomi Valkeinen wrote:
>>>> On 05/08/2020 14:49, H. Nikolaus Schaller wrote:
>>>>> 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.
>>>> 
>>>> HDMI should "just work", and has been tested. But maybe there's
>>>> some
>>>> conflict with HDMI and DSI.
>>>> 
>>>> Tomi
>>>> 
>>> 
>>> _______________________________________________
>>> https://projects.goldelico.com/p/gta04-kernel/
>>> Letux-kernel mailing list
>>> Letux-kernel@openphoenux.org
>>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>> 
>> _______________________________________________
>> Kernel mailing list
>> Kernel@pyra-handheld.com
>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
> 

Re: [Letux-kernel] module_mipi_dsi_driver panel with omapdrm?

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [200816 11:25]:
> Hi David,
> 
> > Am 06.08.2020 um 20:44 schrieb David Shah <dave@ds0.me>:
> > 
> > Following a bit of testing, the DSI issues are fixed by 
> > https://github.com/daveshah1/pyra-kernel-devel/commit/3161275854a0f2cd44a55b8eb039bd201f894486
> > (I will prepare a proper patch set shortly). This makes the display
> > work with HDMI disabled.
> 
> yes, it makes the LCD work (tested so far on 5.8-rc7).
> But even with HDMI enabled.

David, can you please send the above commit as a proper fix to
linux-omap and dts mailing lists so I can apply it into fixes?

Regards,

Tony

Re: module_mipi_dsi_driver panel with omapdrm?

[H. Nikolaus Schaller]

Hi David,
good to know! Would mean that the combination of HDMI and DSI may make trouble.

Maybe we should simply wait ca. 14 days until I have access to my own test setup and can run such tests easily and within minutes myself.
Since it is already broken since v5.7-rc1 it should be possible to wait that time :)

Best regards,
Nikolaus


> Am 05.08.2020 um 13:53 schrieb David Shah <dave@ds0.me>:
> 
> If it helps, I can confirm that HDMI was working fine on the uEVM the last time I test 5.7 (I think it was the final rc before release).
> 
> David
> 
> -------- Original message --------
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: 05/08/2020 12:49 (GMT+00:00)
> To: Sebastian Reichel <sebastian.reichel@collabora.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Tony Lindgren <tony@atomide.com>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Linux-OMAP <linux-omap@vger.kernel.org>, Jyri Sarha <jsarha@ti.com>, kernel@pyra-handheld.com, Discussions about the Letux Kernel <letux-kernel@openphoenux.org>, David Shah <dave@ds0.me>
> Subject: Re: module_mipi_dsi_driver panel with omapdrm?
> 
> 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
>