omap4: support for manually updated display

omap4: support for manually updated display

[Pavel Machek]

Hi!

There's neat series of patches on

https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=droid4-pending-v4.19

They enable display support for my hardware. As you can imagine,
display is rather important for a cellphone.

Tomi, can you take the patches? I can resubmit them in email, or
shuffle them to another branch without mfd changes, or clean them up
etc...

Thanks,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180830/48d8ce66/attachment.sig>

omap4: support for manually updated display

[Tomi Valkeinen]

Hi Pavel,

(dropping Dave, no need to spam him)

On 30/08/18 12:04, Pavel Machek wrote:
> Hi!
> 
> There's neat series of patches on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=droid4-pending-v4.19
> 
> They enable display support for my hardware. As you can imagine,
> display is rather important for a cellphone.
> 
> Tomi, can you take the patches? I can resubmit them in email, or
> shuffle them to another branch without mfd changes, or clean them up
> etc...

A large omapdrm change set from Laurent was merged into drm-next, and
I'm certain they conflict with this series. Laurent also has continued
that work, and while those new patches haven't been sent for review yet,
I fear they'll also conflict with these.

So in the minimum, a rebase on top of drm-next is needed.

I also continue to be very worried that adding DSI support to omapdrm at
this stage will be a huge extra burden for Laurent's work.

We should transform the panel-dsi-cm.c towards the common DRM model.
With a quick look, there seems to be a driver for Samsung's S6E63J0X03
panel. So possibly all the DSI features are there in the DRM framework,
but someone needs to check that and start working on panel-dsi-cm.c so
that it's ready when we finally switch to the DRM model.

In my opinion, which I've also expressed before, the above work is much
easier to do by first changing the omapdrm to DRM model, without any DSI
displays, and then add the DSI command mode support. But if people
insist on adding the DSI support already now, I would appreciate the
same people working on the DSI support so that Laurent doesn't have to
do it all.

 Tomi

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

omap4: support for manually updated display

[Laurent Pinchart]

Hello,

On Monday, 10 September 2018 14:59:23 EEST Tomi Valkeinen wrote:
> Hi Pavel,
> 
> (dropping Dave, no need to spam him)
> 
> On 30/08/18 12:04, Pavel Machek wrote:
> > Hi!
> > 
> > There's neat series of patches on
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/
> > ?h=droid4-pending-v4.19
> > 
> > They enable display support for my hardware. As you can imagine,
> > display is rather important for a cellphone.
> > 
> > Tomi, can you take the patches? I can resubmit them in email, or
> > shuffle them to another branch without mfd changes, or clean them up
> > etc...
> 
> A large omapdrm change set from Laurent was merged into drm-next, and
> I'm certain they conflict with this series. Laurent also has continued
> that work, and while those new patches haven't been sent for review yet,
> I fear they'll also conflict with these.
> 
> So in the minimum, a rebase on top of drm-next is needed.
> 
> I also continue to be very worried that adding DSI support to omapdrm at
> this stage will be a huge extra burden for Laurent's work.
> 
> We should transform the panel-dsi-cm.c towards the common DRM model.
> With a quick look, there seems to be a driver for Samsung's S6E63J0X03
> panel. So possibly all the DSI features are there in the DRM framework,
> but someone needs to check that and start working on panel-dsi-cm.c so
> that it's ready when we finally switch to the DRM model.
> 
> In my opinion, which I've also expressed before, the above work is much
> easier to do by first changing the omapdrm to DRM model, without any DSI
> displays, and then add the DSI command mode support. But if people
> insist on adding the DSI support already now, I would appreciate the
> same people working on the DSI support so that Laurent doesn't have to
> do it all.

I want to make it clear that I don't want to claim any privilege in getting 
patches merged first. I am however worried that, without an easy way to test 
DSI support, and without enough time to focus on it, I would break whatever 
would be merged now in future reworks. I would thus like to find out how to 
collaborate on this task, hopefully to move towards usage of drm_bridge and 
drm_panel for DSI-based pipelines.

-- 
Regards,

Laurent Pinchart

omap4: support for manually updated display

[Tony Lindgren]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [180910 12:28]:
> On Monday, 10 September 2018 14:59:23 EEST Tomi Valkeinen wrote:
> > A large omapdrm change set from Laurent was merged into drm-next, and
> > I'm certain they conflict with this series. Laurent also has continued
> > that work, and while those new patches haven't been sent for review yet,
> > I fear they'll also conflict with these.
> > 
> > So in the minimum, a rebase on top of drm-next is needed.
> > 
> > I also continue to be very worried that adding DSI support to omapdrm at
> > this stage will be a huge extra burden for Laurent's work.
> > 
> > We should transform the panel-dsi-cm.c towards the common DRM model.
> > With a quick look, there seems to be a driver for Samsung's S6E63J0X03
> > panel. So possibly all the DSI features are there in the DRM framework,
> > but someone needs to check that and start working on panel-dsi-cm.c so
> > that it's ready when we finally switch to the DRM model.
> > 
> > In my opinion, which I've also expressed before, the above work is much
> > easier to do by first changing the omapdrm to DRM model, without any DSI
> > displays, and then add the DSI command mode support. But if people
> > insist on adding the DSI support already now, I would appreciate the
> > same people working on the DSI support so that Laurent doesn't have to
> > do it all.
> 
> I want to make it clear that I don't want to claim any privilege in getting 
> patches merged first. I am however worried that, without an easy way to test 
> DSI support, and without enough time to focus on it, I would break whatever 
> would be merged now in future reworks. I would thus like to find out how to 
> collaborate on this task, hopefully to move towards usage of drm_bridge and 
> drm_panel for DSI-based pipelines.

Real users with mainline kernel with a real product should
always have priority over any ongoing clean-up.

And for testing, a bunch of real users is something you can't
beat for proper testing of code on ongoing basis!

Naturally the burden of getting the patches ready is on the people
using them for rebase and fixing comments. And Sebastian has
already agreed help with maintaining it.

I've been actually using DSI command mode support and testing
Linux next several times a week to prevent regressions from
sneaking into -rc1 in general. So now I can't test omapdrm with
next until Sebastian is done with rebasing.. Back to headless
testing then.

Anyways, I'd say let's add the DSI command mode support ASAP after
rebasing, there are at least Sebastian, Pavel and I then testing
and helping with further ongoing panel conversion work.

Regards,

Tony

omap4: support for manually updated display

[Tomi Valkeinen]

On 10/09/18 20:44, Tony Lindgren wrote:

>> I want to make it clear that I don't want to claim any privilege in getting 
>> patches merged first. I am however worried that, without an easy way to test 
>> DSI support, and without enough time to focus on it, I would break whatever 
>> would be merged now in future reworks. I would thus like to find out how to 
>> collaborate on this task, hopefully to move towards usage of drm_bridge and 
>> drm_panel for DSI-based pipelines.
> 
> Real users with mainline kernel with a real product should
> always have priority over any ongoing clean-up.

If this were cleanup, it would of course be a low priority work. But
this is changing omapdrm to support DRM panels and bridges, which is
needed to support many real products in the mainline kernel.

Droid/N9 are no exceptions here, I have been keeping support for
multiple boards out of mainline for this same reason: I don't want to
add omapdrm specific code that will need to be rewritten and would
complicate this big change. Well, Droid/N9 are different in the sense
that they are much more complex cases than the boards I've been keeping out.

In any case, Laurent was ok with merging the patches, so let's merge
them after rebasing.

 Tomi

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

omap4: support for manually updated display

[Pavel Machek]

Hi!

> > I want to make it clear that I don't want to claim any privilege in getting 
> > patches merged first. I am however worried that, without an easy way to test 
> > DSI support, and without enough time to focus on it, I would break whatever 
> > would be merged now in future reworks. I would thus like to find out how to 
> > collaborate on this task, hopefully to move towards usage of drm_bridge and 
> > drm_panel for DSI-based pipelines.
> 
> Real users with mainline kernel with a real product should
> always have priority over any ongoing clean-up.
> 
> And for testing, a bunch of real users is something you can't
> beat for proper testing of code on ongoing basis!
> 
> Naturally the burden of getting the patches ready is on the people
> using them for rebase and fixing comments. And Sebastian has
> already agreed help with maintaining it.
> 
> I've been actually using DSI command mode support and testing
> Linux next several times a week to prevent regressions from
> sneaking into -rc1 in general. So now I can't test omapdrm with
> next until Sebastian is done with rebasing.. Back to headless
> testing then.
> 
> Anyways, I'd say let's add the DSI command mode support ASAP after
> rebasing, there are at least Sebastian, Pavel and I then testing
> and helping with further ongoing panel conversion work.

Are there any news here? Does someone have a patch set that actually
works?

Are there any in-progress patches I could help with?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20181019/e7b5e3f2/attachment.sig>

omap4: support for manually updated display

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [181018 22:15]:
> Hi!
> 
> > > I want to make it clear that I don't want to claim any privilege in getting 
> > > patches merged first. I am however worried that, without an easy way to test 
> > > DSI support, and without enough time to focus on it, I would break whatever 
> > > would be merged now in future reworks. I would thus like to find out how to 
> > > collaborate on this task, hopefully to move towards usage of drm_bridge and 
> > > drm_panel for DSI-based pipelines.
> > 
> > Real users with mainline kernel with a real product should
> > always have priority over any ongoing clean-up.
> > 
> > And for testing, a bunch of real users is something you can't
> > beat for proper testing of code on ongoing basis!
> > 
> > Naturally the burden of getting the patches ready is on the people
> > using them for rebase and fixing comments. And Sebastian has
> > already agreed help with maintaining it.
> > 
> > I've been actually using DSI command mode support and testing
> > Linux next several times a week to prevent regressions from
> > sneaking into -rc1 in general. So now I can't test omapdrm with
> > next until Sebastian is done with rebasing.. Back to headless
> > testing then.
> > 
> > Anyways, I'd say let's add the DSI command mode support ASAP after
> > rebasing, there are at least Sebastian, Pavel and I then testing
> > and helping with further ongoing panel conversion work.
> 
> Are there any news here? Does someone have a patch set that actually
> works?

I was wondering about that too.. I only have the v4.19-rc1 based
patches and can no longer test with Linux next. Sebastian, any
update?

> Are there any in-progress patches I could help with?

I can put in some effort too if needed.

Regards,

Tony

omap4: support for manually updated display

[Sebastian Reichel]

Hi,

On Fri, Oct 19, 2018 at 09:44:50AM -0700, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [181018 22:15]:
> > Hi!
> > 
> > > > I want to make it clear that I don't want to claim any privilege in getting 
> > > > patches merged first. I am however worried that, without an easy way to test 
> > > > DSI support, and without enough time to focus on it, I would break whatever 
> > > > would be merged now in future reworks. I would thus like to find out how to 
> > > > collaborate on this task, hopefully to move towards usage of drm_bridge and 
> > > > drm_panel for DSI-based pipelines.
> > > 
> > > Real users with mainline kernel with a real product should
> > > always have priority over any ongoing clean-up.
> > > 
> > > And for testing, a bunch of real users is something you can't
> > > beat for proper testing of code on ongoing basis!
> > > 
> > > Naturally the burden of getting the patches ready is on the people
> > > using them for rebase and fixing comments. And Sebastian has
> > > already agreed help with maintaining it.
> > > 
> > > I've been actually using DSI command mode support and testing
> > > Linux next several times a week to prevent regressions from
> > > sneaking into -rc1 in general. So now I can't test omapdrm with
> > > next until Sebastian is done with rebasing.. Back to headless
> > > testing then.
> > > 
> > > Anyways, I'd say let's add the DSI command mode support ASAP after
> > > rebasing, there are at least Sebastian, Pavel and I then testing
> > > and helping with further ongoing panel conversion work.
> > 
> > Are there any news here? Does someone have a patch set that actually
> > works?
> 
> I was wondering about that too.. I only have the v4.19-rc1 based
> patches and can no longer test with Linux next. Sebastian, any
> update?
> 
> > Are there any in-progress patches I could help with?
> 
> I can put in some effort too if needed.

I have some in-progress patches, that are not yet working. The
reversal of display pipeline initialization introduced some
issues with DSI (since the panel cannot be fully initialized
without DSI controller). I got this resolved by registering
the DSI display before the DSI controller is fully intialized.
This is obviously racy and breaks for device with DSI backlight
(since display probe function tries to do DSI queries). I think
properly solving this mess requires full migration to
the common mipi_dsi_host/mipi_dsi_device infrastructure. This
should obviously be done anyways, but for now the hack should
be good enough. There is still some other issue, though. I do
not yet understand the origin of that one.

I uploaded my current status here. It's not based on the newest
-next, but contains the interesting patches from Laurent. Also
the last few patches are not yet cleaned up, sorry for the mess.

https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/log/?h=droid4-display-omapdrm-4.20-next

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20181020/68068820/attachment.sig>

omap4: support for manually updated display

[Tony Lindgren]

* Sebastian Reichel <sre@kernel.org> [181019 15:58]:
> I uploaded my current status here. It's not based on the newest
> -next, but contains the interesting patches from Laurent. Also
> the last few patches are not yet cleaned up, sorry for the mess.

Way to go, thanks :) Here's a quick fix for issues with loading
and unloading modules, seems like this should be fixed somewhere
else though?

Regards,

Tony

8< -----------------------
Unload of hdmi:

Unable to handle kernel NULL pointer dereference@virtual address 00000278
(hdmi_runtime_resume [omapdss]) from [<c060d944>] (__rpm_callback+0x144/0x1d8)
(__rpm_callback) from [<c060d9f8>] (rpm_callback+0x20/0x80)
(rpm_callback) from [<c060d580>] (rpm_resume+0x60c/0x828)
(rpm_resume) from [<c060d7e8>] (__pm_runtime_resume+0x4c/0x64)
(__pm_runtime_resume) from [<c06027ac>] (device_release_driver_internal+0x130/0x234)
(device_release_driver_internal) from [<c06028f4>] (driver_detach+0x38/0x6c)
(driver_detach) from [<c0601658>] (bus_remove_driver+0x4c/0xa4)
(bus_remove_driver) from [<c06041fc>] (platform_unregister_drivers+0x20/0x2c)
(platform_unregister_drivers) from [<c01f0ef8>] (sys_delete_module+0x1c0/0x230)
(sys_delete_module) from [<c0101000>] (ret_fast_syscall+0x0/0x28)


Unload of dsi:

Unable to handle kernel NULL pointer dereference at virtual address 00000278
(dsi_runtime_resume [omapdss]) from [<c060d944>] (__rpm_callback+0x144/0x1d8)
(__rpm_callback) from [<c060d9f8>] (rpm_callback+0x20/0x80)
(rpm_callback) from [<c060d580>] (rpm_resume+0x60c/0x828)
(rpm_resume) from [<c060d7e8>] (__pm_runtime_resume+0x4c/0x64)
(__pm_runtime_resume) from [<c0602364>] (driver_probe_device+0x38/0x164)
(driver_probe_device) from [<c0602574>] (__driver_attach+0xe4/0xe8)
(__driver_attach) from [<c0600418>] (bus_for_each_dev+0x70/0xb4)
(bus_for_each_dev) from [<c06015a8>] (bus_add_driver+0x198/0x1fc)
(bus_add_driver) from [<c06032ec>] (driver_register+0x74/0x108)
(driver_register) from [<c0102fe4>] (do_one_initcall+0x80/0x31c)
(do_one_initcall) from [<c01f0fc4>] (do_init_module+0x5c/0x1f8)
(do_init_module) from [<c01f2e0c>] (load_module+0x1360/0x16c0)
(load_module) from [<c01f33d4>] (sys_finit_module+0xbc/0xdc)
(sys_finit_module) from [<c0101000>] (ret_fast_syscall+0x0/0x28)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5484,6 +5484,9 @@ static int dsi_runtime_resume(struct device *dev)
 	struct dsi_data *dsi = dev_get_drvdata(dev);
 	int r;
 
+	if (!dsi || !dsi->dss || !dsi->dss->dispc)
+		return -ENODEV;
+
 	r = dispc_runtime_get(dsi->dss->dispc);
 	if (r)
 		return r;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -847,6 +847,9 @@ static int hdmi_runtime_resume(struct device *dev)
 	struct omap_hdmi *hdmi = dev_get_drvdata(dev);
 	int r;
 
+	if (!hdmi || !hdmi->dss || !hdmi->dss->dispc)
+		return -ENODEV;
+
 	r = dispc_runtime_get(hdmi->dss->dispc);
 	if (r < 0)
 		return r;
-- 
2.19.1

omap4: support for manually updated display

[Tomi Valkeinen]

On 20/10/18 03:38, Tony Lindgren wrote:
> * Sebastian Reichel <sre@kernel.org> [181019 15:58]:
>> I uploaded my current status here. It's not based on the newest
>> -next, but contains the interesting patches from Laurent. Also
>> the last few patches are not yet cleaned up, sorry for the mess.
> 
> Way to go, thanks :) Here's a quick fix for issues with loading
> and unloading modules, seems like this should be fixed somewhere
> else though?

I didn't get that far on drm-next with pandaboard. When loading modules, dsi_probe crashes. It is missing runtime_get(). But after adding runtime_get call, it fails and I see:

[   44.671081] omap_hwmod: dss_dsi2: _wait_target_ready failed: -16
[   44.677459] omapdss_dsi 58005000.encoder: use pm_runtime_put_sync_suspend() in driver?

Why is dsi2 busy (and what does it even mean)...

 Tomi

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

omap4: support for manually updated display

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [181022 08:14]:
> On 20/10/18 03:38, Tony Lindgren wrote:
> > * Sebastian Reichel <sre@kernel.org> [181019 15:58]:
> >> I uploaded my current status here. It's not based on the newest
> >> -next, but contains the interesting patches from Laurent. Also
> >> the last few patches are not yet cleaned up, sorry for the mess.
> > 
> > Way to go, thanks :) Here's a quick fix for issues with loading
> > and unloading modules, seems like this should be fixed somewhere
> > else though?

Sorry one oops was for rmmod, the other one was for modprobe.

> I didn't get that far on drm-next with pandaboard. When loading modules, dsi_probe crashes. It is missing runtime_get(). But after adding runtime_get call, it fails and I see:
> 
> [   44.671081] omap_hwmod: dss_dsi2: _wait_target_ready failed: -16
> [   44.677459] omapdss_dsi 58005000.encoder: use pm_runtime_put_sync_suspend() in driver?
> 
> Why is dsi2 busy (and what does it even mean)...

Hmm below segfault is what I see on pandaboard-es with
next-20181019 with no extra patches.

Regards,

Tony


[   24.842620] omapdss_dss 58000000.dss: 58000000.dss supply vdda_video not found, using dummy regulator
[   24.851959] omapdss_dss 58000000.dss: Linked as a consumer to regulator.0
[   24.859497] omapdss_dss 58000000.dss: Dropping the link to regulator.0
[   24.869628] omapdss_dss 58000000.dss: 58000000.dss supply vdda_video not found, using dummy regulator
[   24.877441] omapdss_dsi 58005000.encoder: Linked as a consumer to regulator.14
[   24.886932] omapdss_dss 58000000.dss: Linked as a consumer to regulator.0
[   24.886932] ------------[ cut here ]------------
[   24.886932] omapdss_dss 58000000.dss: Dropping the link to regulator.0
[   24.898498] WARNING: CPU: 0 PID: 508 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x2dc/0x36c
[   24.898498] 44000000.ocp:L3 Standard Error: MASTER MPU TARGET DSS (Read Link): At Address: 0x00005044 : Data Access in User mo
de during Functional access
[   24.898498] Modules linked in: omapdss(+) drm drm_panel_orientation_quirks omapdss_base cec cfbimgblt cfbfillrect cfbcopyarea
gpio_pca953x hid_generic usbhid smsc95xx smsc75xx usbnet usb_f_acm u_ether usb_f_mass_storage usb_f_serial u_serial xhci_plat_hcd
 xhci_hcd dwc3_omap dwc3 ohci_hcd ehci_hcd phy_omap_usb2 phy_generic libcomposite udc_core snd_soc_simple_card snd_soc_simple_car
d_utils snd_usb_audio snd_usbmidi_lib usbcore usb_common snd_soc_omap_mcbsp snd_soc_omap_dmic snd_soc_omap_twl4030 snd_soc_dmic s
nd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_sdma snd_soc_twl6040 snd_soc_twl4030 snd_soc_core snd_hwdep snd_pcm_dmaengine
snd_pcm snd_timer snd_rawmidi snd soundcore rtc_ds1307 rtc_palmas rtc_twl palmas_pwrbutton extcon_palmas cpufreq_dt ti_soc_therma
l thermal_sys hwmon clk_palmas lib80211 ccm
[   24.999755] CPU: 0 PID: 508 Comm: modprobe Not tainted 4.19.0-rc8-next-20181019 #976
[   25.007537] Hardware name: Generic OMAP4 (Flattened Device Tree)
[   25.007537] [<c01129a8>] (unwind_backtrace) from [<c010d040>] (show_stack+0x10/0x14)
[   25.021392] [<c010d040>] (show_stack) from [<c08e91ac>] (dump_stack+0xb0/0xe8)
[   25.022827] [<c08e91ac>] (dump_stack) from [<c013a3b4>] (__warn.part.3+0xa8/0xe8)
[   25.032867] [<c013a3b4>] (__warn.part.3) from [<c013a450>] (warn_slowpath_fmt+0x5c/0x88)
[   25.042724] [<c013a450>] (warn_slowpath_fmt) from [<c053ec54>] (l3_interrupt_handler+0x2dc/0x36c)
[   25.052764] [<c053ec54>] (l3_interrupt_handler) from [<c01b13b4>] (__handle_irq_event_percpu+0x44/0x358)
[   25.062774] [<c01b13b4>] (__handle_irq_event_percpu) from [<c01b16f0>] (handle_irq_event_percpu+0x28/0x80)
[   25.062866] [<c01b16f0>] (handle_irq_event_percpu) from [<c01b1780>] (handle_irq_event+0x38/0x5c)
[   25.081420] [<c01b1780>] (handle_irq_event) from [<c01b50f8>] (handle_fasteoi_irq+0xbc/0x174)
[   25.082885] [<c01b50f8>] (handle_fasteoi_irq) from [<c01b05e8>] (generic_handle_irq+0x20/0x34)
[   25.092773] [<c01b05e8>] (generic_handle_irq) from [<c01b0be0>] (__handle_domain_irq+0x64/0xe0)
[   25.102813] [<c01b0be0>] (__handle_domain_irq) from [<c053d0cc>] (gic_handle_irq+0x4c/0xa8)
[   25.115814] [<c053d0cc>] (gic_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0x98)
[   25.122741] Exception stack(0xed993c60 to 0xed993ca8)
[   25.128417] 3c60: eebeb810 00000001 00000001 bf4795a8 eda79010 eda7b480 eebeb800 eebeb810
[   25.132751] 3c80: eda79484 bf47f160 0000002a bf477048 00000001 ed993cb0 c01a3cd4 bf46b850
[   25.144866] 3ca0: 20000013 ffffffff
[   25.144866] [<c01019f0>] (__irq_svc) from [<bf46b850>] (dsi_probe+0x428/0x60c [omapdss])
[   25.152770] [<bf46b850>] (dsi_probe [omapdss]) from [<c0604184>] (platform_drv_probe+0x48/0x98)
[   25.165557] [<c0604184>] (platform_drv_probe) from [<c0602134>] (really_probe+0x1dc/0x2d0)
[   25.172851] [<c0602134>] (really_probe) from [<c0602388>] (driver_probe_device+0x5c/0x164)
[   25.172851] [<c0602388>] (driver_probe_device) from [<c0602574>] (__driver_attach+0xe4/0xe8)
[   25.182800] [<c0602574>] (__driver_attach) from [<c0600418>] (bus_for_each_dev+0x70/0xb4)
[   25.192779] [<c0600418>] (bus_for_each_dev) from [<c06015a8>] (bus_add_driver+0x198/0x1fc)
[   25.192779] [<c06015a8>] (bus_add_driver) from [<c06032ec>] (driver_register+0x74/0x108)
[   25.215332] [<c06032ec>] (driver_register) from [<c060425c>] (__platform_register_drivers+0x54/0xd0)
[   25.222747] [<c060425c>] (__platform_register_drivers) from [<c0102fe4>] (do_one_initcall+0x80/0x31c)
[   25.233795] [<c0102fe4>] (do_one_initcall) from [<c01f0fc4>] (do_init_module+0x5c/0x1f8)
[   25.241943] [<c01f0fc4>] (do_init_module) from [<c01f2e0c>] (load_module+0x1360/0x16c0)
[   25.242767] [<c01f2e0c>] (load_module) from [<c01f33d4>] (sys_finit_module+0xbc/0xdc)
[   25.252838] [<c01f33d4>] (sys_finit_module) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[   25.262725] Exception stack(0xed993fa8 to 0xed993ff0)
[   25.267669] 3fa0:                   00040000 00000000 00000007 0045829e 00000000 0046bf30
[   25.272827] 3fc0: 00040000 00000000 00040000 0000017b b6f69610 00040000 00000000 0046bf30
[   25.282775] 3fe0: be92f984 be92f968 00450fc4 b6f022d8
[   25.292694] irq event stamp: 16738
[   25.292877] hardirqs last  enabled at (16737): [<c0909534>] _raw_spin_unlock_irqrestore+0x3c/0x44
[   25.305053] hardirqs last disabled at (16738): [<c01019e0>] __irq_svc+0x60/0x98
[   25.305053] softirqs last  enabled at (16702): [<c0102464>] __do_softirq+0x2c4/0x514
[   25.320190] softirqs last disabled at (16689): [<c0141ba8>] irq_exit+0xc0/0x1a0
[   25.322753] ---[ end trace a2d85a181bf0d3fb ]---
[   25.332336] Unhandled fault: imprecise external abort (0x1406) at 0xbf47f074
[   25.332855] pgd = (ptrval)
[   25.332855] [bf47f074] *pgd=ad997811, *pte=be51665f, *ppte=be51645f
[   25.342864] Internal error: : 1406 [#1] SMP ARM
[   25.352752] Modules linked in: omapdss(+) drm drm_panel_orientation_quirks omapdss_base cec cfbimgblt cfbfillrect cfbcopyarea
gpio_pca953x hid_generic usbhid smsc95xx smsc75xx usbnet usb_f_acm u_ether usb_f_mass_storage usb_f_serial u_serial xhci_plat_hcd
 xhci_hcd dwc3_omap dwc3 ohci_hcd ehci_hcd phy_omap_usb2 phy_generic libcomposite udc_core snd_soc_simple_card snd_soc_simple_car
d_utils snd_usb_audio snd_usbmidi_lib usbcore usb_common snd_soc_omap_mcbsp snd_soc_omap_dmic snd_soc_omap_twl4030 snd_soc_dmic s
nd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_sdma snd_soc_twl6040 snd_soc_twl4030 snd_soc_core snd_hwdep snd_pcm_dmaengine
snd_pcm snd_timer snd_rawmidi snd soundcore rtc_ds1307 rtc_palmas rtc_twl palmas_pwrbutton extcon_palmas cpufreq_dt ti_soc_therma
l thermal_sys hwmon clk_palmas lib80211 ccm
[   25.422729] CPU: 0 PID: 508 Comm: modprobe Tainted: G        W         4.19.0-rc8-next-20181019 #976
[   25.432800] Hardware name: Generic OMAP4 (Flattened Device Tree)
[   25.433746] PC is at dsi_probe+0x428/0x60c [omapdss]
[   25.444854] LR is at lockdep_hardirqs_on+0x108/0x1e0
[   25.444854] pc : [<bf46b850>]    lr : [<c01a3cd4>]    psr: 20000013
[   25.452728] sp : ed993cb0  ip : 00000001  fp : bf477048
[   25.460693] r10: 0000002a  r9 : bf47f160  r8 : eda79484
[   25.462768] r7 : eebeb810  r6 : eebeb800  r5 : eda7b480  r4 : eda79010
[   25.472717] r3 : bf4795a8  r2 : 00000001  r1 : 00000001  r0 : eebeb810
[   25.472717] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   25.482788] Control: 10c5387d  Table: ad99804a  DAC: 00000051
[   25.482788] Process modprobe (pid: 508, stack limit = 0x(ptrval))
[   25.498809] Stack: (0xed993cb0 to 0xed994000)
[   25.502838] 3ca0:                                     00000080 eeba6480 eda79010 bf47f160
[   25.502838] 3cc0: eebeb810 00000000 bf47f160 00000000 00000000 c0604184 eebeb810 c1600d20
[   25.512756] 3ce0: c1600d24 00000000 00000000 c0602134 eebeb810 bf47f160 eebeb844 c0e08948
[   25.522735] 3d00: c0604100 c060413c c0e9cd68 c0602388 c0e08948 c0604100 c060413c eebeb810
[   25.536071] 3d20: bf47f160 eebeb844 c0e08948 c0604100 c060413c c0602574 eeb9d150 bf47f160
[   25.542755] 3d40: c0602490 c0600418 ed983d80 eea26ea4 eeb9d150 acef1296 eea26ed4 bf47f160
[   25.542755] 3d60: ed983d80 c0e9cd68 00000000 c06015a8 bf47c2ac bf47f280 00000006 bf47f160
[   25.560729] 3d80: bf47f280 00000006 c0603c40 c06032ec 00000002 bf47f280 00000006 c060425c
[   25.562744] 3da0: bf477044 bf47703c 60000013 c0ec3c60 c0e08974 c0e08948 bf489000 00000000
[   25.572784] 3dc0: c0ec2de4 bf47f280 c0e08948 c0102fe4 c02730ec c01a3778 ffffe000 00000000
[   25.582733] 3de0: 60000013 c0e08974 ee8000c0 c019f1c4 c0e8835c c0ec2fe5 c0ec49f8 c01be6b8
[   25.592773] 3e00: ed99df00 c02c6e90 60000013 edb1f800 ffffe000 0000000c 60000013 acef1296
[   25.592773] 3e20: bf47f280 c0ec4318 ed99df00 bf47f3f0 bf47f28c 00000000 bf47f280 c01f0fc4
[   25.602752] 3e40: c0e8835c c0ec4318 c0ec2eee c0ec4318 c0e08974 c01f2e0c ffff8000 00007fff
[   25.612731] 3e60: bf47f280 c01f0204 bf47f3d4 0045829e bf480000 00000000 bf47f280 c0a05f28
[   25.622802] 3e80: ed993f2c c0bc972c c02e0001 00000000 c0c64ff4 c0c5659c 00000000 00000000
[   25.632751] 3ea0: 00000000 00000000 00000000 00000000 6e72656b 00006c65 00000000 00000000
[   25.642730] 3ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   25.642730] 3ee0: 00000000 00000000 00000000 acef1296 7fffffff c0e08948 00000000 00000007
[   25.659362] 3f00: 0045829e 7fffffff 00000000 0000017b 0046bf30 c01f33d4 7fffffff 00000000
[   25.666076] 3f20: 00000003 c019cfa4 ed993f4c f4552000 000e4214 00000000 f456cab7 f45712c0
[   25.672790] 3f40: f4552000 000e4214 f46358b4 f4635648 f460aa20 00021000 00025920 00000000
[   25.684020] 3f60: 00000000 00000000 00009c20 00000039 0000003a 0000001c 00000020 00000013
[   25.684020] 3f80: 00000000 acef1296 00000728 00040000 00000000 00040000 0000017b c01011c4
[   25.692840] 3fa0: ed992000 c0101000 00040000 00000000 00000007 0045829e 00000000 0046bf30
[   25.702758] 3fc0: 00040000 00000000 00040000 0000017b b6f69610 00040000 00000000 0046bf30
[   25.716888] 3fe0: be92f984 be92f968 00450fc4 b6f022d8 60000010 00000007 00000000 00000000
[   25.725189] [<bf46b850>] (dsi_probe [omapdss]) from [<c0604184>] (platform_drv_probe+0x48/0x98)
[   25.732757] [<c0604184>] (platform_drv_probe) from [<c0602134>] (really_probe+0x1dc/0x2d0)
[   25.742248] [<c0602134>] (really_probe) from [<c0602388>] (driver_probe_device+0x5c/0x164)
[   25.743286] [<c0602388>] (driver_probe_device) from [<c0602574>] (__driver_attach+0xe4/0xe8)
[   25.752716] [<c0602574>] (__driver_attach) from [<c0600418>] (bus_for_each_dev+0x70/0xb4)
[   25.762786] [<c0600418>] (bus_for_each_dev) from [<c06015a8>] (bus_add_driver+0x198/0x1fc)
[   25.772796] [<c06015a8>] (bus_add_driver) from [<c06032ec>] (driver_register+0x74/0x108)
[   25.782714] [<c06032ec>] (driver_register) from [<c060425c>] (__platform_register_drivers+0x54/0xd0)
[   25.792877] [<c060425c>] (__platform_register_drivers) from [<c0102fe4>] (do_one_initcall+0x80/0x31c)
[   25.792877] [<c0102fe4>] (do_one_initcall) from [<c01f0fc4>] (do_init_module+0x5c/0x1f8)
[   25.802825] [<c01f0fc4>] (do_init_module) from [<c01f2e0c>] (load_module+0x1360/0x16c0)
[   25.812744] [<c01f2e0c>] (load_module) from [<c01f33d4>] (sys_finit_module+0xbc/0xdc)
[   25.822784] [<c01f33d4>] (sys_finit_module) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[   25.832794] Exception stack(0xed993fa8 to 0xed993ff0)
[   25.834411] 3fa0:                   00040000 00000000 00000007 0045829e 00000000 0046bf30
[   25.842773] 3fc0: 00040000 00000000 00040000 0000017b b6f69610 00040000 00000000 0046bf30
[   25.852752] 3fe0: be92f984 be92f968 00450fc4 b6f022d8
[   25.855926] Code: 0affff98 eb471873 e5840024 eaffffa3 (e3a02008)
[   25.862731] ---[ end trace a2d85a181bf0d3fc ]---
Segmentation fault

omap4: support for manually updated display

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [181022 16:31]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [181022 08:14]:
> > On 20/10/18 03:38, Tony Lindgren wrote:
> > > * Sebastian Reichel <sre@kernel.org> [181019 15:58]:
> > >> I uploaded my current status here. It's not based on the newest
> > >> -next, but contains the interesting patches from Laurent. Also
> > >> the last few patches are not yet cleaned up, sorry for the mess.
> > > 
> > > Way to go, thanks :) Here's a quick fix for issues with loading
> > > and unloading modules, seems like this should be fixed somewhere
> > > else though?
> 
> Sorry one oops was for rmmod, the other one was for modprobe.
> 
> > I didn't get that far on drm-next with pandaboard. When loading modules, dsi_probe crashes. It is missing runtime_get(). But after adding runtime_get call, it fails and I see:
> > 
> > [   44.671081] omap_hwmod: dss_dsi2: _wait_target_ready failed: -16
> > [   44.677459] omapdss_dsi 58005000.encoder: use pm_runtime_put_sync_suspend() in driver?
> > 
> > Why is dsi2 busy (and what does it even mean)...
> 
> Hmm below segfault is what I see on pandaboard-es with
> next-20181019 with no extra patches.

And git bisect points to these issues starting with commit
27d624527d99 ("drm/omap: dss: Acquire next dssdev at probe time")
if that might help.

Regards,

Tony

omap4: support for manually updated display

[Laurent Pinchart]

Hi Tony,

On Saturday, 20 October 2018 03:38:12 EET Tony Lindgren wrote:
> * Sebastian Reichel <sre@kernel.org> [181019 15:58]:
> > I uploaded my current status here. It's not based on the newest
> > -next, but contains the interesting patches from Laurent. Also
> > the last few patches are not yet cleaned up, sorry for the mess.
> 
> Way to go, thanks :) Here's a quick fix for issues with loading
> and unloading modules, seems like this should be fixed somewhere
> else though?

Thanks for the report, I'll have a look at this.

> 8< -----------------------
> Unload of hdmi:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000278
> (hdmi_runtime_resume [omapdss]) from [<c060d944>]
> (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [<c060d9f8>]
> (rpm_callback+0x20/0x80)
> (rpm_callback) from [<c060d580>] (rpm_resume+0x60c/0x828)
> (rpm_resume) from [<c060d7e8>] (__pm_runtime_resume+0x4c/0x64)
> (__pm_runtime_resume) from [<c06027ac>]
> (device_release_driver_internal+0x130/0x234)
> (device_release_driver_internal) from [<c06028f4>]
> (driver_detach+0x38/0x6c) (driver_detach) from [<c0601658>]
> (bus_remove_driver+0x4c/0xa4)
> (bus_remove_driver) from [<c06041fc>]
> (platform_unregister_drivers+0x20/0x2c) (platform_unregister_drivers) from
> [<c01f0ef8>] (sys_delete_module+0x1c0/0x230) (sys_delete_module) from
> [<c0101000>] (ret_fast_syscall+0x0/0x28)
> 
> 
> Unload of dsi:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000278
> (dsi_runtime_resume [omapdss]) from [<c060d944>]
> (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [<c060d9f8>]
> (rpm_callback+0x20/0x80)
> (rpm_callback) from [<c060d580>] (rpm_resume+0x60c/0x828)
> (rpm_resume) from [<c060d7e8>] (__pm_runtime_resume+0x4c/0x64)
> (__pm_runtime_resume) from [<c0602364>] (driver_probe_device+0x38/0x164)
> (driver_probe_device) from [<c0602574>] (__driver_attach+0xe4/0xe8)
> (__driver_attach) from [<c0600418>] (bus_for_each_dev+0x70/0xb4)
> (bus_for_each_dev) from [<c06015a8>] (bus_add_driver+0x198/0x1fc)
> (bus_add_driver) from [<c06032ec>] (driver_register+0x74/0x108)
> (driver_register) from [<c0102fe4>] (do_one_initcall+0x80/0x31c)
> (do_one_initcall) from [<c01f0fc4>] (do_init_module+0x5c/0x1f8)
> (do_init_module) from [<c01f2e0c>] (load_module+0x1360/0x16c0)
> (load_module) from [<c01f33d4>] (sys_finit_module+0xbc/0xdc)
> (sys_finit_module) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5484,6 +5484,9 @@ static int dsi_runtime_resume(struct device *dev)
>  	struct dsi_data *dsi = dev_get_drvdata(dev);
>  	int r;
> 
> +	if (!dsi || !dsi->dss || !dsi->dss->dispc)
> +		return -ENODEV;
> +
>  	r = dispc_runtime_get(dsi->dss->dispc);
>  	if (r)
>  		return r;
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c ---
> a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -847,6 +847,9 @@ static int hdmi_runtime_resume(struct device *dev)
>  	struct omap_hdmi *hdmi = dev_get_drvdata(dev);
>  	int r;
> 
> +	if (!hdmi || !hdmi->dss || !hdmi->dss->dispc)
> +		return -ENODEV;
> +
>  	r = dispc_runtime_get(hdmi->dss->dispc);
>  	if (r < 0)
>  		return r;

-- 
Regards,

Laurent Pinchart

omap4: support for manually updated display

[Sebastian Reichel]

Hi,

On Mon, Sep 10, 2018 at 03:24:37PM +0300, Laurent Pinchart wrote:
> On Monday, 10 September 2018 14:59:23 EEST Tomi Valkeinen wrote:
> > On 30/08/18 12:04, Pavel Machek wrote:
> > > There's neat series of patches on
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/
> > > ?h=droid4-pending-v4.19
> > > 
> > > They enable display support for my hardware. As you can imagine,
> > > display is rather important for a cellphone.
> > > 
> > > Tomi, can you take the patches? I can resubmit them in email, or
> > > shuffle them to another branch without mfd changes, or clean them up
> > > etc...
> > 
> > A large omapdrm change set from Laurent was merged into drm-next, and
> > I'm certain they conflict with this series. Laurent also has continued
> > that work, and while those new patches haven't been sent for review yet,
> > I fear they'll also conflict with these.
> > 
> > So in the minimum, a rebase on top of drm-next is needed.
> > 
> > I also continue to be very worried that adding DSI support to omapdrm at
> > this stage will be a huge extra burden for Laurent's work.
> > 
> > We should transform the panel-dsi-cm.c towards the common DRM model.
> > With a quick look, there seems to be a driver for Samsung's S6E63J0X03
> > panel. So possibly all the DSI features are there in the DRM framework,
> > but someone needs to check that and start working on panel-dsi-cm.c so
> > that it's ready when we finally switch to the DRM model.
> > 
> > In my opinion, which I've also expressed before, the above work is much
> > easier to do by first changing the omapdrm to DRM model, without any DSI
> > displays, and then add the DSI command mode support. But if people
> > insist on adding the DSI support already now, I would appreciate the
> > same people working on the DSI support so that Laurent doesn't have to
> > do it all.
> 
> I want to make it clear that I don't want to claim any privilege in getting 
> patches merged first. I am however worried that, without an easy way to test 
> DSI support, and without enough time to focus on it, I would break whatever 
> would be merged now in future reworks. I would thus like to find out how to 
> collaborate on this task, hopefully to move towards usage of drm_bridge and 
> drm_panel for DSI-based pipelines.

I'm currently quite busy and barely find enough time to do my work
as power-supply subsystem maintainer, but I already started to
rebase the series. I agree, that it would be very nice to move towards
usage of common DRM framework(s), but it's also nice to see which
patch breaks DSI ;)

P.S.: Laurent, if its helpful for your work I'm willing to sponsor
a Droid 4. It's OMAP4 based and uses a manually updated DSI panel.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180910/211fdd70/attachment.sig>

omap4: support for manually updated display

[Pavel Machek]

Hi!

> > > A large omapdrm change set from Laurent was merged into drm-next, and
> > > I'm certain they conflict with this series. Laurent also has continued
> > > that work, and while those new patches haven't been sent for review yet,
> > > I fear they'll also conflict with these.
> > > 
> > > So in the minimum, a rebase on top of drm-next is needed.
> > > 
> > > I also continue to be very worried that adding DSI support to omapdrm at
> > > this stage will be a huge extra burden for Laurent's work.
> > > 
> > > We should transform the panel-dsi-cm.c towards the common DRM model.
> > > With a quick look, there seems to be a driver for Samsung's S6E63J0X03
> > > panel. So possibly all the DSI features are there in the DRM framework,
> > > but someone needs to check that and start working on panel-dsi-cm.c so
> > > that it's ready when we finally switch to the DRM model.
> > > 
> > > In my opinion, which I've also expressed before, the above work is much
> > > easier to do by first changing the omapdrm to DRM model, without any DSI
> > > displays, and then add the DSI command mode support. But if people
> > > insist on adding the DSI support already now, I would appreciate the
> > > same people working on the DSI support so that Laurent doesn't have to
> > > do it all.
> > 
> > I want to make it clear that I don't want to claim any privilege in getting 
> > patches merged first. I am however worried that, without an easy way to test 
> > DSI support, and without enough time to focus on it, I would break whatever 
> > would be merged now in future reworks. I would thus like to find out how to 
> > collaborate on this task, hopefully to move towards usage of drm_bridge and 
> > drm_panel for DSI-based pipelines.
> 
> I'm currently quite busy and barely find enough time to do my work
> as power-supply subsystem maintainer, but I already started to
> rebase the series. I agree, that it would be very nice to move towards
> usage of common DRM framework(s), but it's also nice to see which
> patch breaks DSI ;)

I was thinking of doing rebase myself... so if you need some help, or
run out of a time and will need someone to finish it, let me know.

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180911/1361818d/attachment.sig>