Re: omap4: support for manually updated display
Hi Tony, On Saturday, 20 October 2018 03:38:12 EET Tony Lindgren wrote: > * Sebastian Reichel [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 0278 > (hdmi_runtime_resume [omapdss]) from [] > (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] > (rpm_callback+0x20/0x80) > (rpm_callback) from [] (rpm_resume+0x60c/0x828) > (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) > (__pm_runtime_resume) from [] > (device_release_driver_internal+0x130/0x234) > (device_release_driver_internal) from [] > (driver_detach+0x38/0x6c) (driver_detach) from [] > (bus_remove_driver+0x4c/0xa4) > (bus_remove_driver) from [] > (platform_unregister_drivers+0x20/0x2c) (platform_unregister_drivers) from > [] (sys_delete_module+0x1c0/0x230) (sys_delete_module) from > [] (ret_fast_syscall+0x0/0x28) > > > Unload of dsi: > > Unable to handle kernel NULL pointer dereference at virtual address 0278 > (dsi_runtime_resume [omapdss]) from [] > (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] > (rpm_callback+0x20/0x80) > (rpm_callback) from [] (rpm_resume+0x60c/0x828) > (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) > (__pm_runtime_resume) from [] (driver_probe_device+0x38/0x164) > (driver_probe_device) from [] (__driver_attach+0xe4/0xe8) > (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) > (bus_for_each_dev) from [] (bus_add_driver+0x198/0x1fc) > (bus_add_driver) from [] (driver_register+0x74/0x108) > (driver_register) from [] (do_one_initcall+0x80/0x31c) > (do_one_initcall) from [] (do_init_module+0x5c/0x1f8) > (do_init_module) from [] (load_module+0x1360/0x16c0) > (load_module) from [] (sys_finit_module+0xbc/0xdc) > (sys_finit_module) from [] (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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
* Tony Lindgren [181022 16:31]:
> * Tomi Valkeinen [181022 08:14]:
> > On 20/10/18 03:38, Tony Lindgren wrote:
> > > * Sebastian Reichel [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
* Tomi Valkeinen [181022 08:14]: > On 20/10/18 03:38, Tony Lindgren wrote: > > * Sebastian Reichel [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 5800.dss: 5800.dss supply vdda_video not found, using dummy regulator [ 24.851959] omapdss_dss 5800.dss: Linked as a consumer to regulator.0 [ 24.859497] omapdss_dss 5800.dss: Dropping the link to regulator.0 [ 24.869628] omapdss_dss 5800.dss: 5800.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 5800.dss: Linked as a consumer to regulator.0 [ 24.886932] [ cut here ] [ 24.886932] omapdss_dss 5800.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] 4400.ocp:L3 Standard Error: MASTER MPU TARGET DSS (Read Link): At Address: 0x5044 : 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] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 25.021392] [] (show_stack) from [] (dump_stack+0xb0/0xe8) [ 25.022827] [] (dump_stack) from [] (__warn.part.3+0xa8/0xe8) [ 25.032867] [] (__warn.part.3) from [] (warn_slowpath_fmt+0x5c/0x88) [ 25.042724] [] (warn_slowpath_fmt) from [] (l3_interrupt_handler+0x2dc/0x36c) [ 25.052764] [] (l3_interrupt_handler) from [] (__handle_irq_event_percpu+0x44/0x358) [ 25.062774] [] (__handle_irq_event_percpu) from [] (handle_irq_event_percpu+0x28/0x80) [ 25.062866] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c) [ 25.081420] [] (handle_irq_event) from [] (handle_fasteoi_irq+0xbc/0x174) [ 25.082885] [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x20/0x34) [ 25.092773] [] (generic_handle_irq) from [] (__handle_domain_irq+0x64/0xe0) [ 25.102813] [] (__handle_domain_irq) from [] (gic_handle_irq+0x4c/0xa8) [ 25.115814] [] (gic_handle_irq) from [] (__irq_svc+0x70/0x98) [ 25.122741] Exception stack(0xed993c60 to 0xed993ca8) [ 25.128417] 3c60: eebeb810 0001 0001 bf4795a8 eda79010 eda7b480 eebeb800 eebeb810 [ 25.132751] 3c80: eda79484 bf47f160 002a bf477048 0001 ed993cb0 c01a3cd4 bf46b850 [ 25.144866] 3ca0: 2013 [ 25.144866] [] (__irq_svc) from [] (dsi_probe+0x428/0x60c [omapdss]) [ 25.152770] [] (dsi_probe [omapdss]) from [] (platform_drv_probe+0x48/0x98) [ 25.165557] [] (platform_drv_probe) from [] (really_probe+0x1dc/0x2d0) [ 25.172851] [] (really_probe) from [] (driver_probe_device+0x5c/0x164) [ 25.172851] [] (driver_probe_device) from [] (__driver_attach+0xe4/0xe8) [ 25.182800] [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) [ 25.192779] [] (bus_for_each_dev) from [] (bus_add_driver+0x198/0x1fc) [ 25.192779] [] (bus_add_driver) from [] (driver_register+0x74/0x108) [ 25.215332] [] (driver_register) from [] (__platform_register_drivers+0x54/0xd0) [ 25.222747] [] (__platform_register_drivers) from []
Re: omap4: support for manually updated display
On 20/10/18 03:38, Tony Lindgren wrote: > * Sebastian Reichel [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
* Sebastian Reichel [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 at virtual address 0278 (hdmi_runtime_resume [omapdss]) from [] (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] (rpm_callback+0x20/0x80) (rpm_callback) from [] (rpm_resume+0x60c/0x828) (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) (__pm_runtime_resume) from [] (device_release_driver_internal+0x130/0x234) (device_release_driver_internal) from [] (driver_detach+0x38/0x6c) (driver_detach) from [] (bus_remove_driver+0x4c/0xa4) (bus_remove_driver) from [] (platform_unregister_drivers+0x20/0x2c) (platform_unregister_drivers) from [] (sys_delete_module+0x1c0/0x230) (sys_delete_module) from [] (ret_fast_syscall+0x0/0x28) Unload of dsi: Unable to handle kernel NULL pointer dereference at virtual address 0278 (dsi_runtime_resume [omapdss]) from [] (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] (rpm_callback+0x20/0x80) (rpm_callback) from [] (rpm_resume+0x60c/0x828) (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) (__pm_runtime_resume) from [] (driver_probe_device+0x38/0x164) (driver_probe_device) from [] (__driver_attach+0xe4/0xe8) (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) (bus_for_each_dev) from [] (bus_add_driver+0x198/0x1fc) (bus_add_driver) from [] (driver_register+0x74/0x108) (driver_register) from [] (do_one_initcall+0x80/0x31c) (do_one_initcall) from [] (do_init_module+0x5c/0x1f8) (do_init_module) from [] (load_module+0x1360/0x16c0) (load_module) from [] (sys_finit_module+0xbc/0xdc) (sys_finit_module) from [] (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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
* Pavel Machek [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
Hi, On Fri, Oct 19, 2018 at 09:44:50AM -0700, Tony Lindgren wrote: > * Pavel Machek [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 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
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 signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
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 signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
* Laurent Pinchart [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
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 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
omap4: support for manually updated display
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 signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
