Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Sebastian, > Am 25.02.2020 um 00:20 schrieb Sebastian Reichel > : > > This updates the existing omapdrm DSI code, so that it uses > common drm_mipi_dsi API and drm_panel. > > The patchset has been tested with Droid 4 using Linux console, X.org and > Weston. The patchset is based on Laurent Pinchartl's patch series [0] > and removes the last custom panel driver, so quite a few cleanups on the > omapdrm codebase were possible. > > [0] [PATCH v7 00/54] drm/omap: Replace custom display drivers with drm_bridge > and drm_panel > > https://lore.kernel.org/dri-devel/20200222150106.22919-1-laurent.pinch...@ideasonboard.com/ >git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel > > I pushed this patchset into the following branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git > omapdrm/bridge/devel-with-dsi > > The previous version of this patchset has been sent quite some time ago. > This version has been rebased and required cleaning up most of the > hacks. I do not have a detailed changelog, but quite a few things > changed. I decided against doing anything special for the DT change > (adding DSI channel number), since only 3 devices are affected. It is > quite likely, that all developers of those devices update DT together > with kernel for those devices. My suggestion is to merge the first two > patches ASAP and backport to stable, since it does not affect old > kernels and the change is rather small. > > RFCv1: > https://lore.kernel.org/dri-devel/20191117023946.VjCC3yE08DMx7JIKxNagPoT5et7WTnKGVV6MtOtB9Ro@z/ is there something new for this series? Is there a repo where it has been rebased to v5.8-rc1 (and tested)? Our Pyra MIPI/DSI omap5 panel setup is broken by upstream changes since v5.7-rc1 and I am not sure if it is better to search in the old omapdrm code what is missing now. Or to wait for your DSI code and just update/fix our panel driver (and have a chance to get that one upstream). BR and thanks, Nikolaus > > -- Sebastian > > Sebastian Reichel (56): > ARM: dts: omap: add channel to DSI panels > ARM: dts: omap4-droid4: add panel compatible > Revert "drm/omap: dss: Remove unused omap_dss_device operations" > omap/drm: drop unused dsi.configure_pins > drm/omap: dsi: use MIPI_DSI_FMT_* instead of OMAP_DSS_DSI_FMT_* > drm/omap: constify write buffers > drm/omap: dsi: add generic transfer function > drm/omap: panel-dsi-cm: convert to transfer API > drm/omap: dsi: unexport specific data transfer functions > drm/omap: dsi: drop virtual channel logic > drm/omap: dsi: simplify write function > drm/omap: dsi: simplify read functions > drm/omap: dsi: switch dsi_vc_send_long/short to mipi_dsi_msg > drm/omap: dsi: introduce mipi_dsi_host > drm/omap: panel-dsi-cm: use DSI helpers > drm/omap: dsi: request VC via mipi_dsi_attach > drm/omap: panel-dsi-cm: drop hardcoded VC > drm/omap: panel-dsi-cm: use common MIPI DCS 1.3 defines > drm/omap: dsi: drop unused memory_read() > drm/omap: dsi: drop unused get_te() > drm/omap: dsi: drop unused enable_te() > drm/omap: dsi: drop useless sync() > drm/omap: dsi: use pixel-format and mode from attach > drm/omap: panel-dsi-cm: use bulk regulator API > drm/omap: dsi: lp/hs switching support for transfer() > drm/omap: dsi: move TE GPIO handling into core > drm/omap: dsi: drop custom enable_te() API > drm/omap: dsi: do bus locking in host driver > drm/omap: dsi: untangle ulps ops from enable/disable > drm/dsi: add MIPI_DSI_MODE_ULPS_IDLE > drm/omap: dsi: do ULPS in host driver > drm/omap: dsi: move panel refresh function to host > drm/omap: dsi: Reverse direction of the DSS device enable/disable >operations > drm/omap: dsi: drop custom panel capability support > drm/omap: dsi: convert to drm_panel > drm/omap: drop omapdss-boot-init > drm/omap: dsi: implement check timings > drm/omap: panel-dsi-cm: use DEVICE_ATTR_RO > drm/omap: panel-dsi-cm: support unbinding > drm/omap: panel-dsi-cm: fix remove() > drm/omap: dsi: return proper error code from dsi_update_all() > drm/omap: remove global dss_device variable > drm/omap: bind components with drm_device argument > drm/panel: Move OMAP's DSI command mode panel driver > drm/omap: dsi: Register a drm_bridge > drm/omap: remove legacy DSS device operations > drm/omap: remove unused omap_connector > drm/omap: simplify omap_display_id > drm/omap: drop unused DSS next pointer > drm/omap: drop empty omap_encoder helper functions > drm/omap: drop DSS ops_flags > drm/omap: drop dssdev display field > drm/omap: simplify DSI manual update code > ARM: omap2plus_defconfig: Update for moved DSI command mode panel > drm/panel/panel-dsi-cm: support rotation property > ARM: dts: omap4-droid4: add panel orientation > > .../bindings/display/panel/panel-dsi-cm.txt |4 +- > .../boot/dts/motorola-mapphone-common.dtsi|6 +- > arch/arm/boot/dts/omap3-n950.dts |3 +- > arch/arm/boot/dts/omap3.dtsi |
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
On 25/03/2020 15:03, Laurent Pinchart wrote: Hi Tomi, On Wed, Mar 25, 2020 at 02:47:48PM +0200, Tomi Valkeinen wrote: On 25/02/2020 01:20, Sebastian Reichel wrote: This updates the existing omapdrm DSI code, so that it uses common drm_mipi_dsi API and drm_panel. The patchset has been tested with Droid 4 using Linux console, X.org and Weston. The patchset is based on Laurent Pinchartl's patch series [0] and removes the last custom panel driver, so quite a few cleanups on the omapdrm codebase were possible. This is a big series, and I suggest to keep the cleanups to minimum. Things can be cleaned up afterwards after the functional parts of this series have been merged. There are a few cleanups at the bottom of the series that could be merged without waiting for the rest though :-) Yep. So, Sebastian, if there are patches that can be applied independently of this series, can you send those separately or move them to the beginning of the series. There was also the change to include/drm/drm_mipi_dsi.h which is outside the OMAP context. Maybe send that separately to the relevant maintainers. Or at least cc them, as now it's kind of hidden between all the omap changes. And I need to try to wake up one of my boards with a DSI video mode display for testing... 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: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Tomi, On Wed, Mar 25, 2020 at 02:47:48PM +0200, Tomi Valkeinen wrote: > On 25/02/2020 01:20, Sebastian Reichel wrote: > > This updates the existing omapdrm DSI code, so that it uses > > common drm_mipi_dsi API and drm_panel. > > > > The patchset has been tested with Droid 4 using Linux console, X.org and > > Weston. The patchset is based on Laurent Pinchartl's patch series [0] > > and removes the last custom panel driver, so quite a few cleanups on the > > omapdrm codebase were possible. > > This is a big series, and I suggest to keep the cleanups to minimum. > Things can be cleaned up afterwards after the functional parts of this > series have been merged. There are a few cleanups at the bottom of the series that could be merged without waiting for the rest though :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
On 25/02/2020 01:20, Sebastian Reichel wrote: This updates the existing omapdrm DSI code, so that it uses common drm_mipi_dsi API and drm_panel. The patchset has been tested with Droid 4 using Linux console, X.org and Weston. The patchset is based on Laurent Pinchartl's patch series [0] and removes the last custom panel driver, so quite a few cleanups on the omapdrm codebase were possible. This is a big series, and I suggest to keep the cleanups to minimum. Things can be cleaned up afterwards after the functional parts of this series have been merged. 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: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi, On Wed, Feb 26, 2020 at 02:28:23PM +0200, Tomi Valkeinen wrote: > On 25/02/2020 01:20, Sebastian Reichel wrote: > > This updates the existing omapdrm DSI code, so that it uses > > common drm_mipi_dsi API and drm_panel. > > > > The patchset has been tested with Droid 4 using Linux console, X.org and > > Weston. The patchset is based on Laurent Pinchartl's patch series [0] > > and removes the last custom panel driver, so quite a few cleanups on the > > omapdrm codebase were possible. > > I haven't done any reviews yet, but applied these (and the one > v2.1 patch) on top of Laurent's. I booted up AM5 EVM and loaded > the modules: > > [ 17.261560] WARNING: CPU: 0 PID: 419 at drivers/base/component.c:636 > component_bind_all+0x1f4/0x258 I did not see that warning for some reason. I guess I was always lucky, since its a race condition introduced by "drm/omap: bind components with drm_device argument". That patch moves component_bind_all from dss_bind() to omapdrm's probe() to get access to drm_dev. Currently omapdrm is the only DRM driver not supplying that as parameter and its required to move encoder init into the DSS output drivers. I assumed that it would be ok, since it just postpones the call a little bit. Unfortunately it also moves it out of the lock protection from dss_bind(). The only fix, that I see is to register the drm_dev is dss_bind and then supply it to omapdrm via pdata. But I think we could actually get rid of the omapdrm platform device completly and just use its parent "omapdss_dss". I suppose a follow-up patchset could merge the code into one module and do this merge. Probably it's the best to drop that patch for now. It's not yet used in the patches, that I sent. > [ 17.270811] Modules linked in: omapdrm(+) omapdss omapdss_base > panel_osd_osd101t2587_53ts panel_simple simple_bridge ti_tpd12s015 > display_connec > tor tc358767 tc358768 sii902x ti_tfp410 drm_kms_helper drm > drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea cec > [ 17.295521] CPU: 0 PID: 419 Comm: insmod Not tainted > 5.6.0-rc2-00375-g66c4203ed9d4 #2 > [ 17.303387] Hardware name: Generic DRA74X (Flattened Device Tree) > [ 17.309520] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 17.317306] [] (show_stack) from [] > (dump_stack+0xb4/0xd0) > [ 17.324567] [] (dump_stack) from [] (__warn+0xc0/0xf8) > [ 17.331477] [] (__warn) from [] > (warn_slowpath_fmt+0x58/0xb8) > [ 17.338998] [] (warn_slowpath_fmt) from [] > (component_bind_all+0x1f4/0x258) > [ 17.347768] [] (component_bind_all) from [] > (pdev_probe+0xe0/0x7a0 [omapdrm]) > [ 17.356709] [] (pdev_probe [omapdrm]) from [] > (platform_drv_probe+0x48/0x98) > [ 17.365537] [] (platform_drv_probe) from [] > (really_probe+0x200/0x478) > [ 17.373841] [] (really_probe) from [] > (driver_probe_device+0x6c/0x1b4) > [ 17.382145] [] (driver_probe_device) from [] > (device_driver_attach+0x58/0x60) > [ 17.391060] [] (device_driver_attach) from [] > (__driver_attach+0xa4/0x148) > [ 17.399713] [] (__driver_attach) from [] > (bus_for_each_dev+0x70/0xb4) > [ 17.407930] [] (bus_for_each_dev) from [] > (bus_add_driver+0x100/0x204) > [ 17.416233] [] (bus_add_driver) from [] > (driver_register+0x74/0x108) > [ 17.424361] [] (driver_register) from [] > (__platform_register_drivers+0x58/0x150) > [ 17.433628] [] (__platform_register_drivers) from [] > (do_one_initcall+0x48/0x2a0) > [ 17.442893] [] (do_one_initcall) from [] > (do_init_module+0x5c/0x234) > [ 17.451022] [] (do_init_module) from [] > (load_module+0x250c/0x28a4) > [ 17.459064] [] (load_module) from [] > (sys_finit_module+0xcc/0x110) > [ 17.467020] [] (sys_finit_module) from [] > (ret_fast_syscall+0x0/0x54) > [ 17.475233] Exception stack(0xea84bfa8 to 0xea84bff0) > [ 17.480307] bfa0: 0002 0003 0002a894 > bebd2d74 > [ 17.488524] bfc0: 0002 00028424 017b 0003eeb0 0002 > b6ffe000 > [ 17.496738] bfe0: bebd2bb8 bebd2ba8 00020d7c b6edb0b0 > [ 17.502365] ---[ end trace c20802296d6b2775 ]--- > [ 17.508567] omapdss_dss 5800.dss: bound 58001000.dispc (ops > dsi_framedone_timeout_work_callback [omapdss]) > [ 17.520358] omapdss_dss 5800.dss: bound 5804.encoder (ops > dsi_framedone_timeout_work_callback [omapdss]) > [ 17.559728] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 17.574544] [drm] Enabling DMM ywrap scrolling > [ 17.580606] omapdrm omapdrm.0: fb0: omapdrmdrmfb frame buffer device > [ 17.625099] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on > minor 0 > > Similar warning on module unload. The display works, though. same problem, with dss_unbind() and omapdrm's remove function. -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
On 25/02/2020 01:20, Sebastian Reichel wrote: > This updates the existing omapdrm DSI code, so that it uses > common drm_mipi_dsi API and drm_panel. > > The patchset has been tested with Droid 4 using Linux console, X.org and > Weston. The patchset is based on Laurent Pinchartl's patch series [0] > and removes the last custom panel driver, so quite a few cleanups on the > omapdrm codebase were possible. I haven't done any reviews yet, but applied these (and the one v2.1 patch) on top of Laurent's. I booted up AM5 EVM and loaded the modules: [ 17.261560] WARNING: CPU: 0 PID: 419 at drivers/base/component.c:636 component_bind_all+0x1f4/0x258 [ 17.270811] Modules linked in: omapdrm(+) omapdss omapdss_base panel_osd_osd101t2587_53ts panel_simple simple_bridge ti_tpd12s015 display_connec tor tc358767 tc358768 sii902x ti_tfp410 drm_kms_helper drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea cec [ 17.295521] CPU: 0 PID: 419 Comm: insmod Not tainted 5.6.0-rc2-00375-g66c4203ed9d4 #2 [ 17.303387] Hardware name: Generic DRA74X (Flattened Device Tree) [ 17.309520] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 17.317306] [] (show_stack) from [] (dump_stack+0xb4/0xd0) [ 17.324567] [] (dump_stack) from [] (__warn+0xc0/0xf8) [ 17.331477] [] (__warn) from [] (warn_slowpath_fmt+0x58/0xb8) [ 17.338998] [] (warn_slowpath_fmt) from [] (component_bind_all+0x1f4/0x258) [ 17.347768] [] (component_bind_all) from [] (pdev_probe+0xe0/0x7a0 [omapdrm]) [ 17.356709] [] (pdev_probe [omapdrm]) from [] (platform_drv_probe+0x48/0x98) [ 17.365537] [] (platform_drv_probe) from [] (really_probe+0x200/0x478) [ 17.373841] [] (really_probe) from [] (driver_probe_device+0x6c/0x1b4) [ 17.382145] [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [ 17.391060] [] (device_driver_attach) from [] (__driver_attach+0xa4/0x148) [ 17.399713] [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) [ 17.407930] [] (bus_for_each_dev) from [] (bus_add_driver+0x100/0x204) [ 17.416233] [] (bus_add_driver) from [] (driver_register+0x74/0x108) [ 17.424361] [] (driver_register) from [] (__platform_register_drivers+0x58/0x150) [ 17.433628] [] (__platform_register_drivers) from [] (do_one_initcall+0x48/0x2a0) [ 17.442893] [] (do_one_initcall) from [] (do_init_module+0x5c/0x234) [ 17.451022] [] (do_init_module) from [] (load_module+0x250c/0x28a4) [ 17.459064] [] (load_module) from [] (sys_finit_module+0xcc/0x110) [ 17.467020] [] (sys_finit_module) from [] (ret_fast_syscall+0x0/0x54) [ 17.475233] Exception stack(0xea84bfa8 to 0xea84bff0) [ 17.480307] bfa0: 0002 0003 0002a894 bebd2d74 [ 17.488524] bfc0: 0002 00028424 017b 0003eeb0 0002 b6ffe000 [ 17.496738] bfe0: bebd2bb8 bebd2ba8 00020d7c b6edb0b0 [ 17.502365] ---[ end trace c20802296d6b2775 ]--- [ 17.508567] omapdss_dss 5800.dss: bound 58001000.dispc (ops dsi_framedone_timeout_work_callback [omapdss]) [ 17.520358] omapdss_dss 5800.dss: bound 5804.encoder (ops dsi_framedone_timeout_work_callback [omapdss]) [ 17.559728] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 17.574544] [drm] Enabling DMM ywrap scrolling [ 17.580606] omapdrm omapdrm.0: fb0: omapdrmdrmfb frame buffer device [ 17.625099] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 0 Similar warning on module unload. The display works, though. 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: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
On 26/02/2020 01:52, Sebastian Reichel wrote: Well for now let's get Laurent's and my series forward. I think the next step would be to get rid of omap_encoder by moving the encoder init into the DSS output code. Technically we are already merging omapdrm and omapdss, e.g. omap_connector is gone from omapdrm after the series. After Laurent's series (now pushed) and this one, we can turn omapdrm into a single module, as it's supposed to be. I don't see a point in trying to change DSS internal encoders into separate modules, as they're all under DSS, and at times connected in ways which are not easily represented with generic APIs. In theory it should be possible, but I don't see any real benefit in such work. 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: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
* Sebastian Reichel [200225 23:03]: > Hi, > > On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > > * Sebastian Reichel [200225 02:29]: > > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > > BTW, I think there's also some refcount issue in general where > > > > the omapdrm related modules cannot be unloaded any longer? > > > > > > I wouldn't be too surprised. The dependencies are quite interesting > > > at the moment with omapdss registering omapdrm and then omapdrm > > > registers the drm_device, which references the encoders from > > > omapdss. I think this is something to look at once Laurent's and > > > my branch have been merged to avoid increasing the complexity. > > > Technically it should be possible to link everything into one > > > module. > > > > Well the DSS is really DOSSI for Display Output SubSystem > > Interconnect :) The devices on the interconnect are mostly > > independent and ideally the toplevel dss driver would just > > provide Linux generic resources to dispc and various output > > drivers. So probably not a good idea to try to build it all > > into a single module. > > All the output drivers and dispc are already in a single module: > omapdss.ko. There is omapdss-base.ko, omapdss.ko and omapdrm.ko > module. omapdss-base.ko contains a few helpers, omapdss.ko contains > dispc and all output encoders, omapdrm has the tiler code and > wraps some of the custom DSS APIs to DRM APIs. I think the best > way forward is to eliminate the custom API and use common DRM > APIs directly. Then merge all 3 modules into one module. > > In theory one could add modules for each encoder, but practically > this only increases complexity. DRM cannnot hotplug encoders, so > removing any module results in complete loss of DRM. Also during > probe we need to load all modules, since something might be > connected. So having extra modules is not really useful? Well my main concern here is that we should use generic Linux frameworks between the devices within DSS where possible. I can see a single driver pile of code quickly turn into a spaghetti of internal calls instead.. Also each devices on the DSS interconnect needs to do pm_runtime_get for it's struct device naturally. If you can avoid the issues above, then I have no objections of just having one module. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
* Sebastian Reichel [200225 02:29]: > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > BTW, I think there's also some refcount issue in general where > > the omapdrm related modules cannot be unloaded any longer? > > I wouldn't be too surprised. The dependencies are quite interesting > at the moment with omapdss registering omapdrm and then omapdrm > registers the drm_device, which references the encoders from > omapdss. I think this is something to look at once Laurent's and > my branch have been merged to avoid increasing the complexity. > Technically it should be possible to link everything into one > module. Well the DSS is really DOSSI for Display Output SubSystem Interconnect :) The devices on the interconnect are mostly independent and ideally the toplevel dss driver would just provide Linux generic resources to dispc and various output drivers. So probably not a good idea to try to build it all into a single module. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi, On Tue, Feb 25, 2020 at 03:09:37PM -0800, Tony Lindgren wrote: > * Sebastian Reichel [200225 23:03]: > > Hi, > > > > On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > > > * Sebastian Reichel [200225 02:29]: > > > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > > > BTW, I think there's also some refcount issue in general where > > > > > the omapdrm related modules cannot be unloaded any longer? > > > > > > > > I wouldn't be too surprised. The dependencies are quite interesting > > > > at the moment with omapdss registering omapdrm and then omapdrm > > > > registers the drm_device, which references the encoders from > > > > omapdss. I think this is something to look at once Laurent's and > > > > my branch have been merged to avoid increasing the complexity. > > > > Technically it should be possible to link everything into one > > > > module. > > > > > > Well the DSS is really DOSSI for Display Output SubSystem > > > Interconnect :) The devices on the interconnect are mostly > > > independent and ideally the toplevel dss driver would just > > > provide Linux generic resources to dispc and various output > > > drivers. So probably not a good idea to try to build it all > > > into a single module. > > > > All the output drivers and dispc are already in a single module: > > omapdss.ko. There is omapdss-base.ko, omapdss.ko and omapdrm.ko > > module. omapdss-base.ko contains a few helpers, omapdss.ko contains > > dispc and all output encoders, omapdrm has the tiler code and > > wraps some of the custom DSS APIs to DRM APIs. I think the best > > way forward is to eliminate the custom API and use common DRM > > APIs directly. Then merge all 3 modules into one module. > > > > In theory one could add modules for each encoder, but practically > > this only increases complexity. DRM cannnot hotplug encoders, so > > removing any module results in complete loss of DRM. Also during > > probe we need to load all modules, since something might be > > connected. So having extra modules is not really useful? > > Well my main concern here is that we should use generic > Linux frameworks between the devices within DSS where possible. Ack. > I can see a single driver pile of code quickly turn into a > spaghetti of internal calls instead. I was only talking about generating a single module, it contains multiple drivers. And we already have the spaghetti of internal calls between omapdrm and omapdss. With the modules it only means, that functions are either exported or accessed via callbacks. > Also each devices on the DSS interconnect needs to do > pm_runtime_get for it's struct device naturally. Sure, but you are talking about things that are already part of a single module (omapdss.ko). omapdss-base.ko and omapdrm.ko do not directly access hardware. > If you can avoid the issues above, then I have no objections > of just having one module. Well for now let's get Laurent's and my series forward. I think the next step would be to get rid of omap_encoder by moving the encoder init into the DSS output code. Technically we are already merging omapdrm and omapdss, e.g. omap_connector is gone from omapdrm after the series. -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Sebastian, On Wed, Feb 26, 2020 at 12:01:24AM +0100, Sebastian Reichel wrote: > On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > > * Sebastian Reichel [200225 02:29]: > > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > > BTW, I think there's also some refcount issue in general where > > > > the omapdrm related modules cannot be unloaded any longer? > > > > > > I wouldn't be too surprised. The dependencies are quite interesting > > > at the moment with omapdss registering omapdrm and then omapdrm > > > registers the drm_device, which references the encoders from > > > omapdss. I think this is something to look at once Laurent's and > > > my branch have been merged to avoid increasing the complexity. > > > Technically it should be possible to link everything into one > > > module. > > > > Well the DSS is really DOSSI for Display Output SubSystem > > Interconnect :) The devices on the interconnect are mostly > > independent and ideally the toplevel dss driver would just > > provide Linux generic resources to dispc and various output > > drivers. So probably not a good idea to try to build it all > > into a single module. > > All the output drivers and dispc are already in a single module: > omapdss.ko. There is omapdss-base.ko, omapdss.ko and omapdrm.ko > module. omapdss-base.ko contains a few helpers, omapdss.ko contains > dispc and all output encoders, omapdrm has the tiler code and > wraps some of the custom DSS APIs to DRM APIs. I think the best > way forward is to eliminate the custom API and use common DRM > APIs directly. Then merge all 3 modules into one module. > > In theory one could add modules for each encoder, but practically > this only increases complexity. DRM cannnot hotplug encoders, so > removing any module results in complete loss of DRM. Also during > probe we need to load all modules, since something might be > connected. So having extra modules is not really useful? This was considered previously, but blocked (IIRC) because it introduced circular dependencies with the omapdrm-specific display drivers in drivers/gpu/drm/omapdrm/displays/. Once panel-dsi-cm goes away, I think we can give it another try. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi, On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > * Sebastian Reichel [200225 02:29]: > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > BTW, I think there's also some refcount issue in general where > > > the omapdrm related modules cannot be unloaded any longer? > > > > I wouldn't be too surprised. The dependencies are quite interesting > > at the moment with omapdss registering omapdrm and then omapdrm > > registers the drm_device, which references the encoders from > > omapdss. I think this is something to look at once Laurent's and > > my branch have been merged to avoid increasing the complexity. > > Technically it should be possible to link everything into one > > module. > > Well the DSS is really DOSSI for Display Output SubSystem > Interconnect :) The devices on the interconnect are mostly > independent and ideally the toplevel dss driver would just > provide Linux generic resources to dispc and various output > drivers. So probably not a good idea to try to build it all > into a single module. All the output drivers and dispc are already in a single module: omapdss.ko. There is omapdss-base.ko, omapdss.ko and omapdrm.ko module. omapdss-base.ko contains a few helpers, omapdss.ko contains dispc and all output encoders, omapdrm has the tiler code and wraps some of the custom DSS APIs to DRM APIs. I think the best way forward is to eliminate the custom API and use common DRM APIs directly. Then merge all 3 modules into one module. In theory one could add modules for each encoder, but practically this only increases complexity. DRM cannnot hotplug encoders, so removing any module results in complete loss of DRM. Also during probe we need to load all modules, since something might be connected. So having extra modules is not really useful? -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
* Sebastian Reichel [200224 23:22]: > This updates the existing omapdrm DSI code, so that it uses > common drm_mipi_dsi API and drm_panel. > > The patchset has been tested with Droid 4 using Linux console, X.org and > Weston. The patchset is based on Laurent Pinchartl's patch series [0] > and removes the last custom panel driver, so quite a few cleanups on the > omapdrm codebase were possible. > > [0] [PATCH v7 00/54] drm/omap: Replace custom display drivers with drm_bridge > and drm_panel > > https://lore.kernel.org/dri-devel/20200222150106.22919-1-laurent.pinch...@ideasonboard.com/ > git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel > > I pushed this patchset into the following branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git > omapdrm/bridge/devel-with-dsi I gave your omapdrm/bridge/devel-with-dsi branch a quirk test on droid4, but get the following oops with mostly modular omap2_defconfig. BTW, I think there's also some refcount issue in general where the omapdrm related modules cannot be unloaded any longer? Regards, Tony 8< - Internal error: Oops: 805 [#1] PREEMPT SMP ARM Modules linked in: omapdss(+) omapdss_base drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_ors CPU: 0 PID: 811 Comm: modprobe Not tainted 5.6.0-rc2-00376-g163017c12d62a #1926 Hardware name: Generic OMAP4 (Flattened Device Tree) PC is at drm_bridge_remove+0x24/0x40 [drm] LR is at drm_bridge_remove+0x14/0x40 [drm] pc : []lr : []psr: 6013 sp : edc6fc88 ip : eda3a100 fp : bf38a5b4 r10: bf38c7d0 r9 : edc164b8 r8 : edc1606c r7 : edc1647c r6 : edc93010 r5 : bf2dc428 r4 : edc164b8 r3 : edc164fc r2 : r1 : r0 : bf2dc428 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: adc7404a DAC: 0051 Process modprobe (pid: 811, stack limit = 0x(ptrval)) Stack: (0xedc6fc88 to 0xedc7) fc80: edc16040 fdfb edc93010 bf37dfd0 0080 edc2eb00 fca0: edc16040 edc93010 edc93010 bf392178 bf392178 fcc0: 001e c0624424 edc93010 c0efafa0 c0efafa4 c06222e4 fce0: edc93010 bf392178 bf392178 c0622880 c06243a0 c06243dc c0e93210 c06225cc fd00: bf38c450 a013 bf38a5b4 edc93010 bf392178 c0622880 c06243a0 fd20: c06243dc c0622878 bf392178 edc93010 c06228d8 edc94fb4 edc6e000 fd40: bf392178 c062069c edc50eb8 ee8dae58 edc94fb4 d759a07d ee8dae6c bf392178 fd60: edc50e80 c0e93210 c0621618 bf38f0c0 bf3922c0 0006 bf392178 fd80: bf3922c0 0006 c0623db0 c062344c 0002 bf3922c0 0006 c06244fc fda0: bf38a5b0 bf38a5a8 000be666 c0ec0540 bf39a000 bf392308 0002 fdc0: edc2c300 c01dc694 edc6ff30 c0102fec c0ebbcf4 0cc0 c0d75a70 fde0: edc2c2c0 c02b4538 c0d75a70 a013 a013 0008 c01de5bc 0002 fe00: 0001 c01dc694 edc6ff30 d759a07d edbe7400 bf3922c0 0002 d759a07d fe20: bf392308 bf3922c0 edbe7400 edc2c2c0 bf392308 c01de5f8 0002 edc2c2c0 fe40: bf3922c0 0002 edc2c2c0 c01e0b1c bf3922cc 7fff bf3922c0 c01dd34c fe60: bf3a44ee 004c1a8f bf3922c0 bf3923d4 bf3924b8 c0a05fa8 bf38d075 fe80: 0001 c0bddd78 c0bc76d8 bf38a03c 0002 fea0: 6e72656b 6c65 fec0: fee0: d759a07d 7fff edc6e000 0003 004c1a8f 7fff ff00: 017b 004d56a0 c01e1050 7fff 0003 c093c724 ff20: 0002 f137 000e3464 f138b0c6 f138f3c0 f137 000e3464 ff40: f1452a3c f14527a4 f1425e58 00022000 00025680 a084 00027a0b ff60: a074 003e 003f 0021 0025 0018 ff80: d759a07d 004dcb80 64a54c46 b6f6a510 017b 017b c0101204 ffa0: edc6e000 c0101000 64a54c46 b6f6a510 0003 004c1a8f 004dcb80 ffc0: 64a54c46 b6f6a510 017b 017b 004dcb80 0001 004d56a0 ffe0: 004dcb80 bea7ba90 0043d1a9 b6f1d0b8 6030 0003 [] (drm_bridge_remove [drm]) from [] (dsi_probe+0x3ac/0x55c [omapdss]) [] (dsi_probe [omapdss]) from [] (platform_drv_probe+0x48/0x98) [] (platform_drv_probe) from [] (really_probe+0x1dc/0x340) [] (really_probe) from [] (driver_probe_device+0x5c/0x160) [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [] (device_driver_attach) from [] (__driver_attach+0x58/0xcc) [] (__driver_attach) from [] (bus_for_each_dev+0x78/0xb8) [] (bus_for_each_dev) from [] (bus_add_driver+0xf0/0x1d4) [] (bus_add_driver) from [] (driver_register+0x74/0x108) [] (driver_register) from [] (__platform_register_drivers+0x54/0xd0) [] (__platform_register_drivers) from [] (do_one_initcall+0x44/0x2a8) [] (do_one_initcall) from [] (do_init_module+0x5c/0x234) [] (do_init_module) from [] (load_module+0x22c4/0x2580) [] (load_module) from []
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi, On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > * Sebastian Reichel [200224 23:22]: > > This updates the existing omapdrm DSI code, so that it uses > > common drm_mipi_dsi API and drm_panel. > > > > The patchset has been tested with Droid 4 using Linux console, X.org and > > Weston. The patchset is based on Laurent Pinchartl's patch series [0] > > and removes the last custom panel driver, so quite a few cleanups on the > > omapdrm codebase were possible. > > > > [0] [PATCH v7 00/54] drm/omap: Replace custom display drivers with > > drm_bridge and drm_panel > > > > https://lore.kernel.org/dri-devel/20200222150106.22919-1-laurent.pinch...@ideasonboard.com/ > > git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel > > > > I pushed this patchset into the following branch: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git > > omapdrm/bridge/devel-with-dsi > > I gave your omapdrm/bridge/devel-with-dsi branch a quirk test > on droid4, but get the following oops with mostly modular > omap2_defconfig. :( I was testing with a non-modular kernel, since that gives me a much easier testing workflow. Guess I need to spend some time to get a good setup for testing modular kernel with Droid4. > BTW, I think there's also some refcount issue in general where > the omapdrm related modules cannot be unloaded any longer? I wouldn't be too surprised. The dependencies are quite interesting at the moment with omapdss registering omapdrm and then omapdrm registers the drm_device, which references the encoders from omapdss. I think this is something to look at once Laurent's and my branch have been merged to avoid increasing the complexity. Technically it should be possible to link everything into one module. > 8< - > Internal error: Oops: 805 [#1] PREEMPT SMP ARM > Modules linked in: omapdss(+) omapdss_base drm_kms_helper syscopyarea > sysfillrect sysimgblt fb_sys_fops drm drm_panel_ors > CPU: 0 PID: 811 Comm: modprobe Not tainted 5.6.0-rc2-00376-g163017c12d62a > #1926 > Hardware name: Generic OMAP4 (Flattened Device Tree) > PC is at drm_bridge_remove+0x24/0x40 [drm] > LR is at drm_bridge_remove+0x14/0x40 [drm] > pc : []lr : []psr: 6013 > sp : edc6fc88 ip : eda3a100 fp : bf38a5b4 > r10: bf38c7d0 r9 : edc164b8 r8 : edc1606c > r7 : edc1647c r6 : edc93010 r5 : bf2dc428 r4 : edc164b8 > r3 : edc164fc r2 : r1 : r0 : bf2dc428 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > Control: 10c5387d Table: adc7404a DAC: 0051 > Process modprobe (pid: 811, stack limit = 0x(ptrval)) > Stack: (0xedc6fc88 to 0xedc7) > fc80: edc16040 fdfb edc93010 bf37dfd0 0080 edc2eb00 > fca0: edc16040 edc93010 edc93010 bf392178 bf392178 > fcc0: 001e c0624424 edc93010 c0efafa0 c0efafa4 c06222e4 > fce0: edc93010 bf392178 bf392178 c0622880 c06243a0 c06243dc c0e93210 c06225cc > fd00: bf38c450 a013 bf38a5b4 edc93010 bf392178 c0622880 c06243a0 > fd20: c06243dc c0622878 bf392178 edc93010 c06228d8 edc94fb4 edc6e000 > fd40: bf392178 c062069c edc50eb8 ee8dae58 edc94fb4 d759a07d ee8dae6c bf392178 > fd60: edc50e80 c0e93210 c0621618 bf38f0c0 bf3922c0 0006 bf392178 > fd80: bf3922c0 0006 c0623db0 c062344c 0002 bf3922c0 0006 c06244fc > fda0: bf38a5b0 bf38a5a8 000be666 c0ec0540 bf39a000 bf392308 0002 > fdc0: edc2c300 c01dc694 edc6ff30 c0102fec c0ebbcf4 0cc0 c0d75a70 > fde0: edc2c2c0 c02b4538 c0d75a70 a013 a013 0008 c01de5bc 0002 > fe00: 0001 c01dc694 edc6ff30 d759a07d edbe7400 bf3922c0 0002 d759a07d > fe20: bf392308 bf3922c0 edbe7400 edc2c2c0 bf392308 c01de5f8 0002 edc2c2c0 > fe40: bf3922c0 0002 edc2c2c0 c01e0b1c bf3922cc 7fff bf3922c0 c01dd34c > fe60: bf3a44ee 004c1a8f bf3922c0 bf3923d4 bf3924b8 c0a05fa8 bf38d075 > fe80: 0001 c0bddd78 c0bc76d8 bf38a03c 0002 > fea0: 6e72656b 6c65 > fec0: > fee0: d759a07d 7fff edc6e000 0003 004c1a8f 7fff > ff00: 017b 004d56a0 c01e1050 7fff 0003 c093c724 > ff20: 0002 f137 000e3464 f138b0c6 f138f3c0 f137 000e3464 > ff40: f1452a3c f14527a4 f1425e58 00022000 00025680 a084 00027a0b > ff60: a074 003e 003f 0021 0025 0018 > ff80: d759a07d 004dcb80 64a54c46 b6f6a510 017b 017b c0101204 > ffa0: edc6e000 c0101000 64a54c46 b6f6a510 0003 004c1a8f 004dcb80 > ffc0: 64a54c46 b6f6a510 017b 017b 004dcb80 0001 004d56a0 > ffe0: 004dcb80 bea7ba90 0043d1a9 b6f1d0b8 6030 0003 > [] (drm_bridge_remove [drm]) from [] > (dsi_probe+0x3ac/0x55c
