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

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

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

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

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?

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

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

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

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

[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