Re: module_mipi_dsi_driver panel with omapdrm?

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
> 

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?

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

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