| Message ID | 20201105120333.947408-1-tomi.valkeinen@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Convert DSI code to use drm_mipi_dsi and drm_panel | expand |
Hi Tomi, > Am 05.11.2020 um 13:02 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > Hi, > > This is third version of the series sent by Sebastian in February: > > https://www.spinics.net/lists/linux-omap/msg153465.html > > I took the patches from his git tree, and rebased on 5.10-rc2. There > were some conflicts and compilation errors, and one bug that made dsi to > not work (videomode variable was not initialized to 0). > > I then fixed the few checkpatch and sparse issues. Overall, Sebastian's > patches are pretty much as they were previously. I did drop Laurent's > reviewed-bys, as it's been a long time since the previous series, and > the patches are not identical anyway. > > The topmost 5 patches are new ones, cleanups enabled by the DSI > conversion. They could be handled separately, but it's such a nice > cleanup, and I've been waiting for years to get this done, so here they > are. That said, there are still a _lot_ of cleanups to do. > > Almost all of the patches are omapdrm changes. The two non-omapdrm > changes are: > - After converting panel-dsi-cm to common DRM panel model, it is moved > to drm's panel directory. > - Add MIPI_DSI_MODE_ULPS_IDLE flag > > I have tested these with OMAP4 SDP, AM5 EVM and OMAP4 Panda. SDP has > command mode panel, and I don't have any videomode panels. > > Sebastian, I hope you're ok with all this? I did send you an email, but > didn't get a reply yet, so I thought to just proceed. If you want to > handle this in some other way, or don't want your > authorship/signed-off-by in some of the commits, just tell. That all is great. I was able to apply the patch set cleanly and compile. Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And I followed the latest existing panel-orisetech-otm8009a.c which uses a similar video mode controller and mipi-dsi. That one seems to be used by arch/arm/boot/dts/stm32f469-disco.dts. Unfortunately my panel driver is not even loaded by drm/omap so I can't debug. Does this set of drm/omap drivers need a modification of the device tree? If yes, which one? BR and thanks, Nikolaus
Hi, On 05/11/2020 19:15, H. Nikolaus Schaller wrote: > Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for > the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And > I followed the latest existing panel-orisetech-otm8009a.c which uses a > similar video mode controller and mipi-dsi. > > That one seems to be used by arch/arm/boot/dts/stm32f469-disco.dts. > > Unfortunately my panel driver is not even loaded by drm/omap so I can't > debug. Does this set of drm/omap drivers need a modification of the device > tree? If yes, which one? omapdrm doesn't load the panel drivers. If not even your panel's probe is called, then it hints at DT and/or driver's compatible string issue. The panel's probe should get called even if omapdrm is not loaded at all. Can you push your branch somewhere, so I can have a quick look? Tomi
> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > Hi, > > On 05/11/2020 19:15, H. Nikolaus Schaller wrote: > >> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for >> the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And >> I followed the latest existing panel-orisetech-otm8009a.c which uses a >> similar video mode controller and mipi-dsi. >> >> That one seems to be used by arch/arm/boot/dts/stm32f469-disco.dts. >> >> Unfortunately my panel driver is not even loaded by drm/omap so I can't >> debug. Does this set of drm/omap drivers need a modification of the device >> tree? If yes, which one? > > omapdrm doesn't load the panel drivers. If not even your panel's probe is called, then it hints at > DT and/or driver's compatible string issue. The panel's probe should get called even if omapdrm is > not loaded at all. Well, I use the same device tree that loads the old driver... > > Can you push your branch somewhere, so I can have a quick look? Yes, that would be nice! Here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-pyra-dsi-5.10-rc2 or: https://github.com/goldelico/letux-kernel/tree/letux-pyra-dsi-5.10-rc2 (full config is not included). BR and thanks, Nikolaus
On 05/11/2020 20:14, H. Nikolaus Schaller wrote: > >> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >> >> Hi, >> >> On 05/11/2020 19:15, H. Nikolaus Schaller wrote: >> >>> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for >>> the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And >>> I followed the latest existing panel-orisetech-otm8009a.c which uses a >>> similar video mode controller and mipi-dsi. >>> >>> That one seems to be used by arch/arm/boot/dts/stm32f469-disco.dts. >>> >>> Unfortunately my panel driver is not even loaded by drm/omap so I can't >>> debug. Does this set of drm/omap drivers need a modification of the device >>> tree? If yes, which one? >> >> omapdrm doesn't load the panel drivers. If not even your panel's probe is called, then it hints at >> DT and/or driver's compatible string issue. The panel's probe should get called even if omapdrm is >> not loaded at all. > > Well, I use the same device tree that loads the old driver... Yeah, I was mistaken above. With DSI the panel (may be) a child of the DSI host, so it will affect. Can you give pointers to the panel driver source and relevant dts files? BOE BTL507212-W677L? Tomi
> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 05/11/2020 20:14, H. Nikolaus Schaller wrote: >> >>> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> Hi, >>> >>> On 05/11/2020 19:15, H. Nikolaus Schaller wrote: >>> >>>> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for >>>> the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And >>>> I followed the latest existing panel-orisetech-otm8009a.c which uses a >>>> similar video mode controller and mipi-dsi. >>>> >>>> That one seems to be used by arch/arm/boot/dts/stm32f469-disco.dts. >>>> >>>> Unfortunately my panel driver is not even loaded by drm/omap so I can't >>>> debug. Does this set of drm/omap drivers need a modification of the device >>>> tree? If yes, which one? >>> >>> omapdrm doesn't load the panel drivers. If not even your panel's probe is called, then it hints at >>> DT and/or driver's compatible string issue. The panel's probe should get called even if omapdrm is >>> not loaded at all. >> >> Well, I use the same device tree that loads the old driver... > > Yeah, I was mistaken above. With DSI the panel (may be) a child of the DSI host, so it will affect. > > Can you give pointers to the panel driver source and relevant dts files? BOE BTL507212-W677L? Yes. It is (now) drivers/gpu/drm/panel/panel-boe-btl507212-w677l.c and arch/arm/boot/dts/omap5-letux-cortex15-common.dtsi (for the basic dsi definitions) arch/arm/boot/dts/pyra-display.dtsi (for the specific display) All this is merged by some arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.2.dts (I know there are quite a lot of variants but it is a modular system potentially able to accomodate a non-omap processor but the same display). BR, Nikolaus
Hi Tomi On Thu, Nov 05, 2020 at 02:02:37PM +0200, Tomi Valkeinen wrote: > Hi, > > This is third version of the series sent by Sebastian in February: > > https://www.spinics.net/lists/linux-omap/msg153465.html > > I took the patches from his git tree, and rebased on 5.10-rc2. There > were some conflicts and compilation errors, and one bug that made dsi to > not work (videomode variable was not initialized to 0). I for one would be more than happy to see these patches go in. I have looked at them before but was lost in all the conversions. But the general impression is that the drivers are left in a much better shape after the patch set. And the individual patches all looks good. So I am all for getting the patches applied. Perferably soonish so there is some time to fix any regressions that may be reported. Sam
On 05/11/2020 20:56, H. Nikolaus Schaller wrote: > >> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >> >> On 05/11/2020 20:14, H. Nikolaus Schaller wrote: >>> >>>> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>>> >>>> Hi, >>>> >>>> On 05/11/2020 19:15, H. Nikolaus Schaller wrote: >>>> >>>>> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for >>>>> the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And >>>>> I followed the latest existing panel-orisetech-otm8009a.c which uses a >>>>> similar video mode controller and mipi-dsi. >>>>> >>>>> That one seems to be used by arch/arm/boot/dts/stm32f469-disco.dts. >>>>> >>>>> Unfortunately my panel driver is not even loaded by drm/omap so I can't >>>>> debug. Does this set of drm/omap drivers need a modification of the device >>>>> tree? If yes, which one? >>>> >>>> omapdrm doesn't load the panel drivers. If not even your panel's probe is called, then it hints at >>>> DT and/or driver's compatible string issue. The panel's probe should get called even if omapdrm is >>>> not loaded at all. >>> >>> Well, I use the same device tree that loads the old driver... >> >> Yeah, I was mistaken above. With DSI the panel (may be) a child of the DSI host, so it will affect. >> >> Can you give pointers to the panel driver source and relevant dts files? BOE BTL507212-W677L? > > Yes. It is (now) > > drivers/gpu/drm/panel/panel-boe-btl507212-w677l.c > > and > > arch/arm/boot/dts/omap5-letux-cortex15-common.dtsi (for the basic dsi definitions) > arch/arm/boot/dts/pyra-display.dtsi (for the specific display) > > All this is merged by some arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.2.dts I took the driver and make my omap4-sdp dts to use it. It probes for me, but stop after that: [ 119.346374] omapdss_dss 58000000.dss: supply vdda_video not found, using dummy regulator [ 119.358398] DSS: OMAP DSS rev 4.0 [ 119.680053] panel-dsi-cm 58004000.encoder.0: failed to get video timing, using defaults [ 119.695709] panel-dsi-cm 58004000.encoder.0: supply vpnl not found, using dummy regulator [ 119.711242] panel-dsi-cm 58004000.encoder.0: supply vddi not found, using dummy regulator [ 119.769470] panel-btl507212-w677l 58005000.encoder.0: w677l_probe [ 119.779388] panel-btl507212-w677l 58005000.encoder.0: w677l_probe ok [ 119.846679] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 119.858673] omapdss_dss 58000000.dss: bound 58004000.encoder (ops dsi_component_ops [omapdrm]) [ 119.882629] omapdss_dss 58000000.dss: bound 58005000.encoder (ops dsi_component_ops [omapdrm]) [ 119.902069] omapdss_dss 58000000.dss: bound 58006000.encoder (ops hdmi4_component_ops [omapdrm]) [ 119.962066] dmm 4e000000.dmm: initialized all PAT entries [ 120.014770] panel-btl507212-w677l 58005000.encoder.0: w677l_get_modes I didn't debug yet where it's hanging. So you're not even getting the probe? Tomi
On 06/11/2020 16:37, Tomi Valkeinen wrote: > On 05/11/2020 20:56, H. Nikolaus Schaller wrote: >> >>> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> On 05/11/2020 20:14, H. Nikolaus Schaller wrote: >>>> >>>>> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>>>> >>>>> Hi, >>>>> >>>>> On 05/11/2020 19:15, H. Nikolaus Schaller wrote: >>>>> >>>>>> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for >>>>>> the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And >>>>>> I followed the latest existing panel-orisetech-otm8009a.c which uses a >>>>>> similar video mode controller and mipi-dsi. >>>>>> >>>>>> That one seems to be used by arch/arm/boot/dts/stm32f469-disco.dts. >>>>>> >>>>>> Unfortunately my panel driver is not even loaded by drm/omap so I can't >>>>>> debug. Does this set of drm/omap drivers need a modification of the device >>>>>> tree? If yes, which one? >>>>> >>>>> omapdrm doesn't load the panel drivers. If not even your panel's probe is called, then it hints at >>>>> DT and/or driver's compatible string issue. The panel's probe should get called even if omapdrm is >>>>> not loaded at all. >>>> >>>> Well, I use the same device tree that loads the old driver... >>> >>> Yeah, I was mistaken above. With DSI the panel (may be) a child of the DSI host, so it will affect. >>> >>> Can you give pointers to the panel driver source and relevant dts files? BOE BTL507212-W677L? >> >> Yes. It is (now) >> >> drivers/gpu/drm/panel/panel-boe-btl507212-w677l.c >> >> and >> >> arch/arm/boot/dts/omap5-letux-cortex15-common.dtsi (for the basic dsi definitions) >> arch/arm/boot/dts/pyra-display.dtsi (for the specific display) >> >> All this is merged by some arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.2.dts > > I took the driver and make my omap4-sdp dts to use it. It probes for me, but stop after that: > > [ 119.346374] omapdss_dss 58000000.dss: supply vdda_video not found, using dummy regulator > [ 119.358398] DSS: OMAP DSS rev 4.0 > [ 119.680053] panel-dsi-cm 58004000.encoder.0: failed to get video timing, using defaults > [ 119.695709] panel-dsi-cm 58004000.encoder.0: supply vpnl not found, using dummy regulator > [ 119.711242] panel-dsi-cm 58004000.encoder.0: supply vddi not found, using dummy regulator > [ 119.769470] panel-btl507212-w677l 58005000.encoder.0: w677l_probe > [ 119.779388] panel-btl507212-w677l 58005000.encoder.0: w677l_probe ok > [ 119.846679] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) > [ 119.858673] omapdss_dss 58000000.dss: bound 58004000.encoder (ops dsi_component_ops [omapdrm]) > [ 119.882629] omapdss_dss 58000000.dss: bound 58005000.encoder (ops dsi_component_ops [omapdrm]) > [ 119.902069] omapdss_dss 58000000.dss: bound 58006000.encoder (ops hdmi4_component_ops [omapdrm]) > [ 119.962066] dmm 4e000000.dmm: initialized all PAT entries > [ 120.014770] panel-btl507212-w677l 58005000.encoder.0: w677l_get_modes > > I didn't debug yet where it's hanging. So you're not even getting the probe? Oh, it's stuck in a loop trying to calculate suitable timings. It doesn't find it, as I'm running on omap4, with just 2 datalanes instead of 4 which the panel needs. Looks like the code could use some improvement there. Anyway, possibly on omap5 it goes fine. Tomi
Hi Tomi, > Am 06.11.2020 um 16:04 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > >> >> I took the driver and make my omap4-sdp dts to use it. It probes for me, but stop after that: >> >> [ 119.346374] omapdss_dss 58000000.dss: supply vdda_video not found, using dummy regulator >> [ 119.358398] DSS: OMAP DSS rev 4.0 >> [ 119.680053] panel-dsi-cm 58004000.encoder.0: failed to get video timing, using defaults >> [ 119.695709] panel-dsi-cm 58004000.encoder.0: supply vpnl not found, using dummy regulator >> [ 119.711242] panel-dsi-cm 58004000.encoder.0: supply vddi not found, using dummy regulator >> [ 119.769470] panel-btl507212-w677l 58005000.encoder.0: w677l_probe >> [ 119.779388] panel-btl507212-w677l 58005000.encoder.0: w677l_probe ok >> [ 119.846679] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) >> [ 119.858673] omapdss_dss 58000000.dss: bound 58004000.encoder (ops dsi_component_ops [omapdrm]) >> [ 119.882629] omapdss_dss 58000000.dss: bound 58005000.encoder (ops dsi_component_ops [omapdrm]) >> [ 119.902069] omapdss_dss 58000000.dss: bound 58006000.encoder (ops hdmi4_component_ops [omapdrm]) >> [ 119.962066] dmm 4e000000.dmm: initialized all PAT entries >> [ 120.014770] panel-btl507212-w677l 58005000.encoder.0: w677l_get_modes >> >> I didn't debug yet where it's hanging. So you're not even getting the probe? > > Oh, it's stuck in a loop trying to calculate suitable timings. It doesn't find it, as I'm running on > omap4, with just 2 datalanes instead of 4 which the panel needs. Looks like the code could use some > improvement there. > > Anyway, possibly on omap5 it goes fine. I have set up based on our complete letux-5.10-rc2 tree and maybe using our private config makes the difference. Anyways, the driver is now probed and I can see the call to w677l_get_modes(). I have still no image and no calls to prepare/unprepare etc. but now I can start to debug on omap5. And hopefully we are close to push the panel driver for review. And in a second step some device tree for the Pyra. The new tree is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel BR and thanks, Nikolaus
On 14:02-20201105, Tomi Valkeinen wrote: > Hi, > > This is third version of the series sent by Sebastian in February: > > https://www.spinics.net/lists/linux-omap/msg153465.html > > I took the patches from his git tree, and rebased on 5.10-rc2. There > were some conflicts and compilation errors, and one bug that made dsi to > not work (videomode variable was not initialized to 0). > > I then fixed the few checkpatch and sparse issues. Overall, Sebastian's > patches are pretty much as they were previously. I did drop Laurent's > reviewed-bys, as it's been a long time since the previous series, and > the patches are not identical anyway. > > The topmost 5 patches are new ones, cleanups enabled by the DSI > conversion. They could be handled separately, but it's such a nice > cleanup, and I've been waiting for years to get this done, so here they > are. That said, there are still a _lot_ of cleanups to do. > > Almost all of the patches are omapdrm changes. The two non-omapdrm > changes are: > - After converting panel-dsi-cm to common DRM panel model, it is moved > to drm's panel directory. > - Add MIPI_DSI_MODE_ULPS_IDLE flag > > I have tested these with OMAP4 SDP, AM5 EVM and OMAP4 Panda. SDP has > command mode panel, and I don't have any videomode panels. > > Sebastian, I hope you're ok with all this? I did send you an email, but > didn't get a reply yet, so I thought to just proceed. If you want to > handle this in some other way, or don't want your > authorship/signed-off-by in some of the commits, just tell. > > Tomi > > Sebastian Reichel (51): > drm/dsi: add MIPI_DSI_MODE_ULPS_IDLE > Revert "drm/omap: dss: Remove unused omap_dss_device operations" > drm/omap: 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/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: remove global dss_device variable > 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 > drm/omap: dsi: simplify pin config > ARM: omap2plus_defconfig: Update for moved DSI command mode panel > > Tomi Valkeinen (5): > drm/omap: squash omapdrm sub-modules into one > drm/omap: remove unused display.c > drm/omap: drop unused owner field > drm/omap: remove dispc_ops > drm/omap: remove dss_mgr_ops > Reviewed-by: Nikhil Devshatwar <nikhil.nd@ti.com> Thanks Nikhil D > arch/arm/configs/omap2plus_defconfig | 2 +- > drivers/gpu/drm/omapdrm/Kconfig | 120 +- > drivers/gpu/drm/omapdrm/Makefile | 19 +- > drivers/gpu/drm/omapdrm/displays/Kconfig | 10 - > drivers/gpu/drm/omapdrm/displays/Makefile | 2 - > .../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 1385 ----------------- > drivers/gpu/drm/omapdrm/dss/Kconfig | 135 -- > drivers/gpu/drm/omapdrm/dss/Makefile | 20 - > drivers/gpu/drm/omapdrm/dss/base.c | 87 +- > drivers/gpu/drm/omapdrm/dss/dispc.c | 101 +- > drivers/gpu/drm/omapdrm/dss/display.c | 60 - > drivers/gpu/drm/omapdrm/dss/dpi.c | 1 - > drivers/gpu/drm/omapdrm/dss/dsi.c | 1069 ++++++++----- > drivers/gpu/drm/omapdrm/dss/dss.c | 28 +- > drivers/gpu/drm/omapdrm/dss/dss.h | 72 +- > drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 - > drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 - > .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 229 --- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 278 +--- > drivers/gpu/drm/omapdrm/dss/output.c | 57 +- > drivers/gpu/drm/omapdrm/dss/sdi.c | 1 - > drivers/gpu/drm/omapdrm/dss/venc.c | 2 - > drivers/gpu/drm/omapdrm/omap_connector.c | 157 -- > drivers/gpu/drm/omapdrm/omap_connector.h | 28 - > drivers/gpu/drm/omapdrm/omap_crtc.c | 103 +- > drivers/gpu/drm/omapdrm/omap_crtc.h | 2 - > drivers/gpu/drm/omapdrm/omap_drv.c | 65 +- > drivers/gpu/drm/omapdrm/omap_drv.h | 3 +- > drivers/gpu/drm/omapdrm/omap_encoder.c | 59 +- > drivers/gpu/drm/omapdrm/omap_irq.c | 34 +- > drivers/gpu/drm/omapdrm/omap_plane.c | 12 +- > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-dsi-cm.c | 647 ++++++++ > include/drm/drm_mipi_dsi.h | 2 + > 35 files changed, 1718 insertions(+), 3084 deletions(-) > delete mode 100644 drivers/gpu/drm/omapdrm/displays/Kconfig > delete mode 100644 drivers/gpu/drm/omapdrm/displays/Makefile > delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c > delete mode 100644 drivers/gpu/drm/omapdrm/dss/Kconfig > delete mode 100644 drivers/gpu/drm/omapdrm/dss/Makefile > delete mode 100644 drivers/gpu/drm/omapdrm/dss/display.c > delete mode 100644 drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c > delete mode 100644 drivers/gpu/drm/omapdrm/omap_connector.c > delete mode 100644 drivers/gpu/drm/omapdrm/omap_connector.h > create mode 100644 drivers/gpu/drm/panel/panel-dsi-cm.c > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >
On 07/11/2020 14:19, H. Nikolaus Schaller wrote: > I have set up based on our complete letux-5.10-rc2 tree and maybe using our private config makes > the difference. Anyways, the driver is now probed and I can see the call to w677l_get_modes(). > > I have still no image and no calls to prepare/unprepare etc. but now I can start to debug on omap5. > And hopefully we are close to push the panel driver for review. And in a second step some device > tree for the Pyra. > > The new tree is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel Ok, good. Do you have a link the previous driver that works (omapdrm specific panel driver)? I think it's good to have that as a reference. Tomi
> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 07/11/2020 14:19, H. Nikolaus Schaller wrote: > >> I have set up based on our complete letux-5.10-rc2 tree and maybe using our private config makes >> the difference. Anyways, the driver is now probed and I can see the call to w677l_get_modes(). >> >> I have still no image and no calls to prepare/unprepare etc. but now I can start to debug on omap5. >> And hopefully we are close to push the panel driver for review. And in a second step some device >> tree for the Pyra. >> >> The new tree is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel > > Ok, good. Do you have a link the previous driver that works (omapdrm specific panel driver)? I think > it's good to have that as a reference. Yes, here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/panels BR and thanks, Nikolaus
On 09/11/2020 11:30, H. Nikolaus Schaller wrote: > >> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >> >> On 07/11/2020 14:19, H. Nikolaus Schaller wrote: >> >>> I have set up based on our complete letux-5.10-rc2 tree and maybe using our private config makes >>> the difference. Anyways, the driver is now probed and I can see the call to w677l_get_modes(). >>> >>> I have still no image and no calls to prepare/unprepare etc. but now I can start to debug on omap5. >>> And hopefully we are close to push the panel driver for review. And in a second step some device >>> tree for the Pyra. >>> >>> The new tree is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel >> >> Ok, good. Do you have a link the previous driver that works (omapdrm specific panel driver)? I think >> it's good to have that as a reference. > > Yes, here: > > https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/panels Ok. The old driver uses two separate VC configurations (request_vc calls), so it may not work with this series. I think we need to implement logic to the dsi driver to somehow handle this kind of setup. Tomi
> Am 09.11.2020 um 11:22 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 09/11/2020 11:30, H. Nikolaus Schaller wrote: >> >>> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> On 07/11/2020 14:19, H. Nikolaus Schaller wrote: >>> >>>> I have set up based on our complete letux-5.10-rc2 tree and maybe using our private config makes >>>> the difference. Anyways, the driver is now probed and I can see the call to w677l_get_modes(). >>>> >>>> I have still no image and no calls to prepare/unprepare etc. but now I can start to debug on omap5. >>>> And hopefully we are close to push the panel driver for review. And in a second step some device >>>> tree for the Pyra. >>>> >>>> The new tree is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel >>> >>> Ok, good. Do you have a link the previous driver that works (omapdrm specific panel driver)? I think >>> it's good to have that as a reference. >> >> Yes, here: >> >> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/panels > > Ok. The old driver uses two separate VC configurations (request_vc calls), yes indeed. I was not sure how to handle this with the new omapdrm drivers. > so it may not work with > this series. I think we need to implement logic to the dsi driver to somehow handle this kind of setup. I see. Anyways there is missing some simple thing which makes the driver not prepared/enabled. Or is this related to VC? BR and thanks, Nikolaus
On 09/11/2020 12:31, H. Nikolaus Schaller wrote: > >> Am 09.11.2020 um 11:22 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >> >> On 09/11/2020 11:30, H. Nikolaus Schaller wrote: >>> >>>> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>>> >>>> On 07/11/2020 14:19, H. Nikolaus Schaller wrote: >>>> >>>>> I have set up based on our complete letux-5.10-rc2 tree and maybe using our private config makes >>>>> the difference. Anyways, the driver is now probed and I can see the call to w677l_get_modes(). >>>>> >>>>> I have still no image and no calls to prepare/unprepare etc. but now I can start to debug on omap5. >>>>> And hopefully we are close to push the panel driver for review. And in a second step some device >>>>> tree for the Pyra. >>>>> >>>>> The new tree is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel >>>> >>>> Ok, good. Do you have a link the previous driver that works (omapdrm specific panel driver)? I think >>>> it's good to have that as a reference. >>> >>> Yes, here: >>> >>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/panels >> >> Ok. The old driver uses two separate VC configurations (request_vc calls), > > yes indeed. I was not sure how to handle this with the new omapdrm drivers. > >> so it may not work with >> this series. I think we need to implement logic to the dsi driver to somehow handle this kind of setup. > > I see. > Anyways there is missing some simple thing which makes the driver not prepared/enabled. > Or is this related to VC? No, that's not related to the VC. Tomi
> Am 09.11.2020 um 11:34 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 09/11/2020 12:31, H. Nikolaus Schaller wrote: >> >>> Am 09.11.2020 um 11:22 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> On 09/11/2020 11:30, H. Nikolaus Schaller wrote: >>>> >>>>> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>>>> >>>>> On 07/11/2020 14:19, H. Nikolaus Schaller wrote: >>>>> >>>>>> I have set up based on our complete letux-5.10-rc2 tree and maybe using our private config makes >>>>>> the difference. Anyways, the driver is now probed and I can see the call to w677l_get_modes(). >>>>>> >>>>>> I have still no image and no calls to prepare/unprepare etc. but now I can start to debug on omap5. >>>>>> And hopefully we are close to push the panel driver for review. And in a second step some device >>>>>> tree for the Pyra. >>>>>> >>>>>> The new tree is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel >>>>> >>>>> Ok, good. Do you have a link the previous driver that works (omapdrm specific panel driver)? I think >>>>> it's good to have that as a reference. >>>> >>>> Yes, here: >>>> >>>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/panels >>> >>> Ok. The old driver uses two separate VC configurations (request_vc calls), >> >> yes indeed. I was not sure how to handle this with the new omapdrm drivers. >> >>> so it may not work with >>> this series. I think we need to implement logic to the dsi driver to somehow handle this kind of setup. >> >> I see. >> Anyways there is missing some simple thing which makes the driver not prepared/enabled. >> Or is this related to VC? > > No, that's not related to the VC. Ok, then it is worth searching for that independently. Any idea/hint what could be missing? BR and thanks, Nikolaus
On 09/11/2020 13:09, H. Nikolaus Schaller wrote: >>> I see. >>> Anyways there is missing some simple thing which makes the driver not prepared/enabled. >>> Or is this related to VC? >> >> No, that's not related to the VC. > > Ok, then it is worth searching for that independently. Any idea/hint what could be missing? Well, if I had to guess, I would go for either 1) some registration or such is missing from the panel driver, or 2) some config value is invalid, which makes the DRM framework or the DSI driver fail before calling prepare or enable. Tomi
Hi Tomi, > Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 09/11/2020 13:09, H. Nikolaus Schaller wrote: > >>>> I see. >>>> Anyways there is missing some simple thing which makes the driver not prepared/enabled. >>>> Or is this related to VC? >>> >>> No, that's not related to the VC. >> >> Ok, then it is worth searching for that independently. Any idea/hint what could be missing? > > Well, if I had to guess, I would go for either 1) some registration or such is missing from the > panel driver, or 2) some config value is invalid, which makes the DRM framework or the DSI driver > fail before calling prepare or enable. I did now some tests based on v5.10-rc3 by adding mre and more printk() and dump_stack(). And I did blacklist the panel driver so that I could boot and after modprobing it manually I could trigger a re-probe by inserting some USB memory stick. With this procedure I could trace the problem down to this call sequence: dsi_probe() ... w677l_probe() drm_panel_add() -- after this, of_drm_find_panel() is successful ... component_add() try_to_bring_up_master() master->ops->bind(master->dev) This call to bind() does not return and likely the probing thread is then blocked and holds some locks which manifests itself in that the system isn't running stable any more (e.g. heartbeat LEDs are sometimes stuck although console still works). dbg_info() in try_to_bring_up_master() prints: [ 102.199362] omapdss_dss 58000000.dss: trying to bring up master So I am not sure if this is a panel driver issue at all or the DSI patch set is not running stable on OMAP5. Is a good next step to trace dss_bind() in drivers/gpu/drm/omapdrm//dss/dss.c? BR, Nikolaus
On 10/11/2020 15:49, H. Nikolaus Schaller wrote: > I did now some tests based on v5.10-rc3 by adding mre and more printk() and dump_stack(). > And I did blacklist the panel driver so that I could boot and after modprobing it manually > I could trigger a re-probe by inserting some USB memory stick. > > With this procedure I could trace the problem down to this call sequence: > > dsi_probe() > ... > w677l_probe() > drm_panel_add() -- after this, of_drm_find_panel() is successful > ... > component_add() > try_to_bring_up_master() > master->ops->bind(master->dev) > > This call to bind() does not return and likely the probing thread is then blocked and > holds some locks which manifests itself in that the system isn't running stable any > more (e.g. heartbeat LEDs are sometimes stuck although console still works). > > dbg_info() in try_to_bring_up_master() prints: > > [ 102.199362] omapdss_dss 58000000.dss: trying to bring up master > > So I am not sure if this is a panel driver issue at all or the DSI patch set is not > running stable on OMAP5. > > Is a good next step to trace dss_bind() in drivers/gpu/drm/omapdrm//dss/dss.c? For me, on omap5 uevm, the dss bind goes fine. But it gets stuck in videomode clock calculations. Something related to pixel clock, I think, as the pclk dsi receives is 3708754968 kHz (so, garbage). I'll try to debug more tomorrow. Tomi
> Am 10.11.2020 um 14:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > Hi Tomi, > >> Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >> >> On 09/11/2020 13:09, H. Nikolaus Schaller wrote: >> >>>>> I see. >>>>> Anyways there is missing some simple thing which makes the driver not prepared/enabled. >>>>> Or is this related to VC? >>>> >>>> No, that's not related to the VC. >>> >>> Ok, then it is worth searching for that independently. Any idea/hint what could be missing? >> >> Well, if I had to guess, I would go for either 1) some registration or such is missing from the >> panel driver, or 2) some config value is invalid, which makes the DRM framework or the DSI driver >> fail before calling prepare or enable. > > I did now some tests based on v5.10-rc3 by adding mre and more printk() and dump_stack(). > And I did blacklist the panel driver so that I could boot and after modprobing it manually > I could trigger a re-probe by inserting some USB memory stick. > > With this procedure I could trace the problem down to this call sequence: > > dsi_probe() > ... > w677l_probe() > drm_panel_add() -- after this, of_drm_find_panel() is successful > ... > component_add() > try_to_bring_up_master() > master->ops->bind(master->dev) > > This call to bind() does not return and likely the probing thread is then blocked and > holds some locks which manifests itself in that the system isn't running stable any > more (e.g. heartbeat LEDs are sometimes stuck although console still works). > > dbg_info() in try_to_bring_up_master() prints: > > [ 102.199362] omapdss_dss 58000000.dss: trying to bring up master > > So I am not sure if this is a panel driver issue at all or the DSI patch set is not > running stable on OMAP5. > > Is a good next step to trace dss_bind() in drivers/gpu/drm/omapdrm//dss/dss.c? There is indeed one kernel worker running at 100% CPU load. top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3196 root 20 0 0 0 0 R 100.0 0.0 2:58.76 kworker/0:8+events More analysis shows that it hangs in drm_client_modeset_probe() in the loop for (i = 0; i < connector_count; i++) total_modes_count += connectors[i]->funcs->fill_modes(connectors[i], width, height); Most likely not in the loop because that looks sane, but connectors[i]->funcs->fill_modes(). So I have to find out what function connectors[i]->funcs->fill_modes is... BTW: connector_count = 2. BR and thanks, Nikolaus
On 10/11/2020 18:49, H. Nikolaus Schaller wrote: > >> Am 10.11.2020 um 14:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>: >> >> Hi Tomi, >> >>> Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> On 09/11/2020 13:09, H. Nikolaus Schaller wrote: >>> >>>>>> I see. >>>>>> Anyways there is missing some simple thing which makes the driver not prepared/enabled. >>>>>> Or is this related to VC? >>>>> >>>>> No, that's not related to the VC. >>>> >>>> Ok, then it is worth searching for that independently. Any idea/hint what could be missing? >>> >>> Well, if I had to guess, I would go for either 1) some registration or such is missing from the >>> panel driver, or 2) some config value is invalid, which makes the DRM framework or the DSI driver >>> fail before calling prepare or enable. >> >> I did now some tests based on v5.10-rc3 by adding mre and more printk() and dump_stack(). >> And I did blacklist the panel driver so that I could boot and after modprobing it manually >> I could trigger a re-probe by inserting some USB memory stick. >> >> With this procedure I could trace the problem down to this call sequence: >> >> dsi_probe() >> ... >> w677l_probe() >> drm_panel_add() -- after this, of_drm_find_panel() is successful >> ... >> component_add() >> try_to_bring_up_master() >> master->ops->bind(master->dev) >> >> This call to bind() does not return and likely the probing thread is then blocked and >> holds some locks which manifests itself in that the system isn't running stable any >> more (e.g. heartbeat LEDs are sometimes stuck although console still works). >> >> dbg_info() in try_to_bring_up_master() prints: >> >> [ 102.199362] omapdss_dss 58000000.dss: trying to bring up master >> >> So I am not sure if this is a panel driver issue at all or the DSI patch set is not >> running stable on OMAP5. >> >> Is a good next step to trace dss_bind() in drivers/gpu/drm/omapdrm//dss/dss.c? > > There is indeed one kernel worker running at 100% CPU load. > > top: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3196 root 20 0 0 0 0 R 100.0 0.0 2:58.76 kworker/0:8+events > > More analysis shows that it hangs in drm_client_modeset_probe() in the loop > > for (i = 0; i < connector_count; i++) > total_modes_count += connectors[i]->funcs->fill_modes(connectors[i], width, height); > > Most likely not in the loop because that looks sane, but connectors[i]->funcs->fill_modes(). > > So I have to find out what function connectors[i]->funcs->fill_modes is... > > BTW: connector_count = 2. I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays there finding good clocks. Tomi
> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 10/11/2020 18:49, H. Nikolaus Schaller wrote: > > I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays > there finding good clocks. Yes, I could trace it down to exactly this point. So the culprit is somehow the panel driver. Because it asks for clocks that the PLL driver does not want to provide... Or is it the victim? Here is what dmesg reports with even more printk(): [ 276.970635] drm_helper_probe_single_connector_modes 12 count=1 [ 277.003509] drm_mode_validate_pipeline 2 ret=0 status=0 [ 277.038678] drm_bridge_chain_mode_valid: func=dsi_bridge_mode_valid+0x0/0xa0 [omapdrm] [ 277.047199] dsi_bridge_mode_valid [ 277.050786] __dsi_calc_config [ 277.057270] dsi_vm_calc [ 277.073251] dss_pll_calc_a clkin=19200000 pll_min=1555386656 pll_max=1555410656 func=dsi_vm_calc_pll_cb+0x0/0x48 [omapdrm] [ 277.084975] dss_pll_calc_a pll_hw_max=1800000000 fint_hw_min=150000 fint_hw_max=52000000 [ 277.093637] dss_pll_calc_a n_start=1 n_inc=1 n_stop=128 pll_max'=1555410656 [ 277.101062] dss_pll_calc_a n=1 clkin=19200000 fint=19200000 [ 277.107152] dss_pll_calc_a m_start=41 m_inc=1 m_stop=40 Ok, we have to wait quite a while until the for(m;;) loop ends, because m_stop < m_start and m_inc is positive. So something in the formulae in dss_pll_calc_a() does not fit or has unintended rounding effects. Or the values reported by w677l_get_modes() do not fit anything. I think these findings and ideas should help to find a fix. BR and thanks, Nikolaus
On 10/11/2020 23:04, H. Nikolaus Schaller wrote: > >> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >> >> On 10/11/2020 18:49, H. Nikolaus Schaller wrote: >> >> I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays >> there finding good clocks. > > Yes, I could trace it down to exactly this point. > > So the culprit is somehow the panel driver. Because it asks for clocks that the PLL driver does not want to provide... > Or is it the victim? > > Here is what dmesg reports with even more printk(): > > [ 276.970635] drm_helper_probe_single_connector_modes 12 count=1 > [ 277.003509] drm_mode_validate_pipeline 2 ret=0 status=0 > [ 277.038678] drm_bridge_chain_mode_valid: func=dsi_bridge_mode_valid+0x0/0xa0 [omapdrm] > [ 277.047199] dsi_bridge_mode_valid > [ 277.050786] __dsi_calc_config > [ 277.057270] dsi_vm_calc > [ 277.073251] dss_pll_calc_a clkin=19200000 pll_min=1555386656 pll_max=1555410656 func=dsi_vm_calc_pll_cb+0x0/0x48 [omapdrm] > [ 277.084975] dss_pll_calc_a pll_hw_max=1800000000 fint_hw_min=150000 fint_hw_max=52000000 > [ 277.093637] dss_pll_calc_a n_start=1 n_inc=1 n_stop=128 pll_max'=1555410656 > [ 277.101062] dss_pll_calc_a n=1 clkin=19200000 fint=19200000 > [ 277.107152] dss_pll_calc_a m_start=41 m_inc=1 m_stop=40 > > Ok, we have to wait quite a while until the for(m;;) loop ends, because m_stop < m_start and m_inc is positive. > > So something in the formulae in dss_pll_calc_a() does not fit or has unintended rounding effects. > Or the values reported by w677l_get_modes() do not fit anything. > > I think these findings and ideas should help to find a fix. drm_display_mode.clock is in kHz, but the panel driver writes Hz (w677l_PIXELCLOCK) to it. But there's more after fixing that. The DSI gets configured in bridge's modeset, which I think is before w677l_prepare where the panel already sends DSI commands. Also, the dsi driver fails to lock the PLL, so possibly the clock calcs are still wrong. Tomi
> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 10/11/2020 23:04, H. Nikolaus Schaller wrote: >> >>> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> On 10/11/2020 18:49, H. Nikolaus Schaller wrote: >>> >>> I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays >>> there finding good clocks. >> > > drm_display_mode.clock is in kHz, but the panel driver writes Hz (w677l_PIXELCLOCK) to it. Ok, fixing this removes the stuck thread issue. Thanks for pointing this out! > But > there's more after fixing that. The DSI gets configured in bridge's modeset, which I think is before > w677l_prepare where the panel already sends DSI commands. Also, the dsi driver fails to lock the > PLL, so possibly the clock calcs are still wrong. What I now get is [ 131.035006] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:55:crtc-0] flip_done timed out [ 141.272174] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:54:DSI-1] flip_done timed out I think for further experiments we could hack the device tree to compatible = "orisetech,otm8009a"; and configure for panel-orisetech-otm8009a.ko. Since this panel driver is known to work elsewhere we could exclude panel driver issues for the moment. To be safe we can modify otm8009a_dcs_write_buf() to just print what it would be doing. BR, Nikolaus
On 11/11/2020 09:48, H. Nikolaus Schaller wrote: > >> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >> >> On 10/11/2020 23:04, H. Nikolaus Schaller wrote: >>> >>>> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>>> >>>> On 10/11/2020 18:49, H. Nikolaus Schaller wrote: >>>> >>>> I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays >>>> there finding good clocks. >>> >> >> drm_display_mode.clock is in kHz, but the panel driver writes Hz (w677l_PIXELCLOCK) to it. > > Ok, fixing this removes the stuck thread issue. Thanks for pointing this out! > >> But >> there's more after fixing that. The DSI gets configured in bridge's modeset, which I think is before >> w677l_prepare where the panel already sends DSI commands. Also, the dsi driver fails to lock the >> PLL, so possibly the clock calcs are still wrong. > > What I now get is > > [ 131.035006] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:55:crtc-0] flip_done timed out > [ 141.272174] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:54:DSI-1] flip_done timed out > > I think for further experiments we could hack the device tree to compatible = "orisetech,otm8009a"; > and configure for panel-orisetech-otm8009a.ko. Since this panel driver is known to work elsewhere > we could exclude panel driver issues for the moment. To be safe we can modify otm8009a_dcs_write_buf() > to just print what it would be doing. I pushed some quick fixes/hacks to: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 5.11/dsi At least I get the DSI PLL configured, and kmstest --flip works with 60 fps. I'm pretty sure the panel won't work yet, though. Tomi
> Am 11.11.2020 um 11:11 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 11/11/2020 09:48, H. Nikolaus Schaller wrote: >> >>> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> On 10/11/2020 23:04, H. Nikolaus Schaller wrote: >>>> >>>>> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>>>> >>>>> On 10/11/2020 18:49, H. Nikolaus Schaller wrote: >>>>> >>>>> I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays >>>>> there finding good clocks. >>>> >>> >>> drm_display_mode.clock is in kHz, but the panel driver writes Hz (w677l_PIXELCLOCK) to it. >> >> Ok, fixing this removes the stuck thread issue. Thanks for pointing this out! >> >>> But >>> there's more after fixing that. The DSI gets configured in bridge's modeset, which I think is before >>> w677l_prepare where the panel already sends DSI commands. Also, the dsi driver fails to lock the >>> PLL, so possibly the clock calcs are still wrong. >> >> What I now get is >> >> [ 131.035006] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:55:crtc-0] flip_done timed out >> [ 141.272174] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:54:DSI-1] flip_done timed out >> >> I think for further experiments we could hack the device tree to compatible = "orisetech,otm8009a"; >> and configure for panel-orisetech-otm8009a.ko. Since this panel driver is known to work elsewhere >> we could exclude panel driver issues for the moment. To be safe we can modify otm8009a_dcs_write_buf() >> to just print what it would be doing. > > I pushed some quick fixes/hacks to: > > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 5.11/dsi > > At least I get the DSI PLL configured, and kmstest --flip works with 60 fps. > I'm pretty sure the panel won't work yet, though. Yes, as expected it still does not work. I see: [ 168.236405] dsi_bridge_mode_valid r=-22 [ 168.411769] omapdrm omapdrm.0: [drm] Cannot find any crtc or sizes [ 168.418382] omapdrm omapdrm.0: [drm] crtc_count = 0 width=-1 height=-1 The -EINVAL seems to come from dss_pll_calc_a() returning false. So clock calculation sill fails after fixing the pixel clock. No successful combination. BR, Nikolaus
Hi Tomi, I hope you had a good weekend. And I have added back the CC: list because I think we have progress after our internal discussion and only one issue remaining. > Am 13.11.2020 um 15:49 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: > > On 13/11/2020 16:41, H. Nikolaus Schaller wrote: >> Hi Tomi, >> >>> Am 13.11.2020 um 14:38 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>: >>> >>> On 13/11/2020 15:35, H. Nikolaus Schaller wrote: >>> >>>> So I'd say dsi_vc_send_short() fails if dsi_vc_enable_hs(0, 0) and not dsi_vc_enable_hs(0, 1) >>> >>> Oh, forgot to mention this: remove MIPI_DSI_MODE_LPM from the panel driver. >> >> Yes! This makes sending the init sequence work. >> >> I just have failures from w677l_read() but that may be the panel driver wrapper code. > > Ok, great! It would be good to have reads working too. I have fixed it. The call to mipi_dsi_dcs_read() was wrong. > That way we can know for sure if the commands > go back and forth correctly (e.g. verify the panel version ID). I can now read registers. Panel version ID is nonsense but I know that it was before. Maybe they did not flash it during production since I only read 0x40,0x00,0x00. But we can read it. > >> If I remove all read commands (they are not necessary for operation), there are no error >> messages and everything succeeds. I have a /dev/fb0. >> >> But I have no picture yet. >> >> Initially I thought that it was just the missing code to handle an external PWM backlight. >> But even with (and backlight working), I have just a framebuffer with black screen. >> >> Anyways, I think we are very close. And this is a great step forwards so that I need a >> break... >> >> Maybe I manage to consolidate the panel driver code before v5.10-rc4 arrives. This >> would give a freshly merged letux tree. > > Usually backlight glow is visible even if there's no picture. Well, it did not turn the PWM on at all. Now this works as well. Still I have no picture. But the readout of the register 0x45 (scan line) shows varying values. Therefore I think the vsync is running and incrementing the scan line counter. > But a comparison between the old, working driver, with dsi debugs enabled, may give some hints. A > DISPC & DSI reg dump for both cases may also give hints. I have a script to mount debugfs and dump registers. Results are attached. Significant difference seem to be in: DISPC_TIMING_H(LCD) DSI_CLK_CTRL DSI_VM_TIMING1 DSI_VM_TIMING6 DSI_VC_CTRL(0) DSI_VC_CTRL(1) DSI_DSIPHY_CFG2 The consolidated panel driver code is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/boe-w677-dsi-panel-v2 Well, not yet clean for upstreaming but functionally much better than before. What I have hacked is to mask out MIPI_DSI_MODE_LPM in mipi_dsi_attach(). This can/will be replaced if your series can handle it. BR, Nikolaus root@letux:~# ./debugdsi - DSS - FCK = 192000000 - DISPC - dispc fclk source = FCK fck 192000000 - DISPC-CORE-CLK - lck 192000000 lck div 1 - LCD - LCD clk source = PLL1:1 lck 153600000 lck div 1 pck 76800000 pck div 2 - LCD2 - LCD2 clk source = FCK lck 48000000 lck div 4 pck 48000000 pck div 1 - LCD3 - LCD3 clk source = FCK lck 48000000 lck div 4 pck 48000000 pck div 1 DISPC_REVISION 00000051 DISPC_SYSCONFIG 00002015 DISPC_SYSSTATUS 00000001 DISPC_IRQSTATUS 000000a2 DISPC_IRQENABLE 0812d640 DISPC_CONTROL 00018309 DISPC_CONFIG 0000020c DISPC_CAPABLE 00000000 DISPC_LINE_STATUS 000003e3 DISPC_LINE_NUMBER 00000000 DISPC_GLOBAL_ALPHA ffffffff DISPC_CONTROL2 00000000 DISPC_CONFIG2 00000000 DISPC_CONTROL3 00000000 DISPC_CONFIG3 00000000 DISPC_GLOBAL_MFLAG_ATTRIBUTE 00000001 DISPC_DEFAULT_COLOR(LCD) 00000000 DISPC_TRANS_COLOR(LCD) 00000000 DISPC_SIZE_MGR(LCD) 04ff02cf DISPC_TIMING_H(LCD) 0040a100 DISPC_TIMING_V(LCD) 0320323b DISPC_POL_FREQ(LCD) 00060000 DISPC_DIVISORo(LCD) 00010002 DISPC_DATA_CYCLE1(LCD) 00000000 DISPC_DATA_CYCLE2(LCD) 00000000 DISPC_DATA_CYCLE3(LCD) 00000000 DISPC_CPR_COEF_R(LCD) 00000000 DISPC_CPR_COEF_G(LCD) 00000000 DISPC_CPR_COEF_B(LCD) 00000000 DISPC_DEFAULT_COLOR(TV) 00000000 DISPC_TRANS_COLOR(TV) 00000000 DISPC_SIZE_MGR(TV) 00000000 DISPC_DEFAULT_COLOR(LCD2) 00000000 DISPC_TRANS_COLOR(LCD2) 00000000 DISPC_SIZE_MGR(LCD2) 00000000 DISPC_TIMING_H(LCD2) 00000000 DISPC_TIMING_V(LCD2) 00000000 DISPC_POL_FREQ(LCD2) 00000000 DISPC_DIVISORo(LCD2) 00040001 DISPC_DATA_CYCLE1(LCD2) 00000000 DISPC_DATA_CYCLE2(LCD2) 00000000 DISPC_DATA_CYCLE3(LCD2) 00000000 DISPC_CPR_COEF_R(LCD2) 00000000 DISPC_CPR_COEF_G(LCD2) 00000000 DISPC_CPR_COEF_B(LCD2) 00000000 DISPC_DEFAULT_COLOR(LCD3) 00000000 DISPC_TRANS_COLOR(LCD3) 00000000 DISPC_SIZE_MGR(LCD3) 00000000 DISPC_TIMING_H(LCD3) 00000000 DISPC_TIMING_V(LCD3) 00000000 DISPC_POL_FREQ(LCD3) 00000000 DISPC_DIVISORo(LCD3) 00040001 DISPC_DATA_CYCLE1(LCD3) 00000000 DISPC_DATA_CYCLE2(LCD3) 00000000 DISPC_DATA_CYCLE3(LCD3) 00000000 DISPC_CPR_COEF_R(LCD3) 00000000 DISPC_CPR_COEF_G(LCD3) 00000000 DISPC_CPR_COEF_B(LCD3) 00000000 DISPC_OVL_BA0(GFX) 10100000 DISPC_OVL_BA1(GFX) 10100000 DISPC_OVL_POSITION(GFX) 00000000 DISPC_OVL_SIZE(GFX) 04ff02cf DISPC_OVL_ATTRIBUTES(GFX) 320040b1 DISPC_OVL_FIFO_THRESHOLD(GFX) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(GFX) 00000500 DISPC_OVL_ROW_INC(GFX) 000074c1 DISPC_OVL_PIXEL_INC(GFX) 00000001 DISPC_OVL_PRELOAD(GFX) 000007ff DISPC_OVL_MFLAG_THRESHOLD(GFX) 05000400 DISPC_OVL_WINDOW_SKIP(GFX) 00000000 DISPC_OVL_TABLE_BA(GFX) 00000000 DISPC_OVL_BA0(VID1) 00000000 DISPC_OVL_BA1(VID1) 00000000 DISPC_OVL_POSITION(VID1) 00000000 DISPC_OVL_SIZE(VID1) 00000000 DISPC_OVL_ATTRIBUTES(VID1) 02808400 DISPC_OVL_FIFO_THRESHOLD(VID1) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(VID1) 00000800 DISPC_OVL_ROW_INC(VID1) 00000001 DISPC_OVL_PIXEL_INC(VID1) 00000001 DISPC_OVL_PRELOAD(VID1) 000007ff DISPC_OVL_MFLAG_THRESHOLD(VID1) 05000400 DISPC_OVL_FIR(VID1) 04000400 DISPC_OVL_PICTURE_SIZE(VID1) 00000000 DISPC_OVL_ACCU0(VID1) 00000000 DISPC_OVL_ACCU1(VID1) 00000000 DISPC_OVL_BA0_UV(VID1) 00000000 DISPC_OVL_BA1_UV(VID1) 00000000 DISPC_OVL_FIR2(VID1) 04000400 DISPC_OVL_ACCU2_0(VID1) 00000000 DISPC_OVL_ACCU2_1(VID1) 00000000 DISPC_OVL_ATTRIBUTES2(VID1) 00000000 DISPC_OVL_BA0(VID2) 00000000 DISPC_OVL_BA1(VID2) 00000000 DISPC_OVL_POSITION(VID2) 00000000 DISPC_OVL_SIZE(VID2) 00000000 DISPC_OVL_ATTRIBUTES(VID2) 02808400 DISPC_OVL_FIFO_THRESHOLD(VID2) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(VID2) 00000800 DISPC_OVL_ROW_INC(VID2) 00000001 DISPC_OVL_PIXEL_INC(VID2) 00000001 DISPC_OVL_PRELOAD(VID2) 000007ff DISPC_OVL_MFLAG_THRESHOLD(VID2) 05000400 DISPC_OVL_FIR(VID2) 04000400 DISPC_OVL_PICTURE_SIZE(VID2) 00000000 DISPC_OVL_ACCU0(VID2) 00000000 DISPC_OVL_ACCU1(VID2) 00000000 DISPC_OVL_BA0_UV(VID2) 00000000 DISPC_OVL_BA1_UV(VID2) 00000000 DISPC_OVL_FIR2(VID2) 04000400 DISPC_OVL_ACCU2_0(VID2) 00000000 DISPC_OVL_ACCU2_1(VID2) 00000000 DISPC_OVL_ATTRIBUTES2(VID2) 00000000 DISPC_OVL_BA0(VID3) 00000000 DISPC_OVL_BA1(VID3) 00000000 DISPC_OVL_POSITION(VID3) 00000000 DISPC_OVL_SIZE(VID3) 00000000 DISPC_OVL_ATTRIBUTES(VID3) 02808400 DISPC_OVL_FIFO_THRESHOLD(VID3) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(VID3) 00000800 DISPC_OVL_ROW_INC(VID3) 00000001 DISPC_OVL_PIXEL_INC(VID3) 00000001 DISPC_OVL_PRELOAD(VID3) 000007ff DISPC_OVL_MFLAG_THRESHOLD(VID3) 05000400 DISPC_OVL_FIR(VID3) 04000400 DISPC_OVL_PICTURE_SIZE(VID3) 00000000 DISPC_OVL_ACCU0(VID3) 00000000 DISPC_OVL_ACCU1(VID3) 00000000 DISPC_OVL_BA0_UV(VID3) 00000000 DISPC_OVL_BA1_UV(VID3) 00000000 DISPC_OVL_FIR2(VID3) 04000400 DISPC_OVL_ACCU2_0(VID3) 00000000 DISPC_OVL_ACCU2_1(VID3) 00000000 DISPC_OVL_ATTRIBUTES2(VID3) 00000000 DISPC_OVL_BA0(WB) 00000000 DISPC_OVL_BA1(WB) 00000000 DISPC_OVL_SIZE(WB) 00000000 DISPC_OVL_ATTRIBUTES(WB) 00808000 DISPC_OVL_FIFO_THRESHOLD(WB) 00080000 DISPC_OVL_FIFO_SIZE_STATUS(WB) 00000800 DISPC_OVL_ROW_INC(WB) 00000001 DISPC_OVL_PIXEL_INC(WB) 00000001 DISPC_OVL_MFLAG_THRESHOLD(WB) 03200280 DISPC_OVL_FIR(WB) 04000400 DISPC_OVL_PICTURE_SIZE(WB) 00000000 DISPC_OVL_ACCU0(WB) 00000000 DISPC_OVL_ACCU1(WB) 00000000 DISPC_OVL_BA0_UV(WB) 00000000 DISPC_OVL_BA1_UV(WB) 00000000 DISPC_OVL_FIR2(WB) 04000400 DISPC_OVL_ACCU2_0(WB) 00000000 DISPC_OVL_ACCU2_1(WB) 00000000 DISPC_OVL_ATTRIBUTES2(WB) 00000000 DISPC_OVL_FIR_COEF_H_0(VID1) 00000000 DISPC_OVL_FIR_COEF_H_1(VID1) 00000000 DISPC_OVL_FIR_COEF_H_2(VID1) 00000000 DISPC_OVL_FIR_COEF_H_3(VID1) 00000000 DISPC_OVL_FIR_COEF_H_4(VID1) 00000000 DISPC_OVL_FIR_COEF_H_5(VID1) 00000000 DISPC_OVL_FIR_COEF_H_6(VID1) 00000000 DISPC_OVL_FIR_COEF_H_7(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID1) 00000000 DISPC_OVL_CONV_COEF_0(VID1) 0199012a DISPC_OVL_CONV_COEF_1(VID1) 012a0000 DISPC_OVL_CONV_COEF_2(VID1) 079c0730 DISPC_OVL_CONV_COEF_3(VID1) 0000012a DISPC_OVL_CONV_COEF_4(VID1) 00000204 DISPC_OVL_FIR_COEF_V_0(VID1) 00000000 DISPC_OVL_FIR_COEF_V_1(VID1) 00000000 DISPC_OVL_FIR_COEF_V_2(VID1) 00000000 DISPC_OVL_FIR_COEF_V_3(VID1) 00000000 DISPC_OVL_FIR_COEF_V_4(VID1) 00000000 DISPC_OVL_FIR_COEF_V_5(VID1) 00000000 DISPC_OVL_FIR_COEF_V_6(VID1) 00000000 DISPC_OVL_FIR_COEF_V_7(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_0(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_1(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_2(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_3(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_4(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_5(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_6(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_7(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_0(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_1(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_2(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_3(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_4(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_5(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_6(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_7(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_0(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_1(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_2(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_3(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_4(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_5(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_6(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_7(VID1) 00000000 DISPC_OVL_FIR_COEF_H_0(VID2) 00000000 DISPC_OVL_FIR_COEF_H_1(VID2) 00000000 DISPC_OVL_FIR_COEF_H_2(VID2) 00000000 DISPC_OVL_FIR_COEF_H_3(VID2) 00000000 DISPC_OVL_FIR_COEF_H_4(VID2) 00000000 DISPC_OVL_FIR_COEF_H_5(VID2) 00000000 DISPC_OVL_FIR_COEF_H_6(VID2) 00000000 DISPC_OVL_FIR_COEF_H_7(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID2) 00000000 DISPC_OVL_CONV_COEF_0(VID2) 0199012a DISPC_OVL_CONV_COEF_1(VID2) 012a0000 DISPC_OVL_CONV_COEF_2(VID2) 079c0730 DISPC_OVL_CONV_COEF_3(VID2) 0000012a DISPC_OVL_CONV_COEF_4(VID2) 00000204 DISPC_OVL_FIR_COEF_V_0(VID2) 00000000 DISPC_OVL_FIR_COEF_V_1(VID2) 00000000 DISPC_OVL_FIR_COEF_V_2(VID2) 00000000 DISPC_OVL_FIR_COEF_V_3(VID2) 00000000 DISPC_OVL_FIR_COEF_V_4(VID2) 00000000 DISPC_OVL_FIR_COEF_V_5(VID2) 00000000 DISPC_OVL_FIR_COEF_V_6(VID2) 00000000 DISPC_OVL_FIR_COEF_V_7(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_0(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_1(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_2(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_3(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_4(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_5(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_6(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_7(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_0(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_1(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_2(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_3(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_4(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_5(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_6(VID2) 00000000 [ 117.525871] DSI: dsi_runtime_get [ 117.532527] DSI: dsi_runtime_put DISPC_OVL_FIR_COEF_HV2_7(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_0(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_1(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_2(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_3(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_4(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_5(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_6(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_7(VID2) 00000000 DISPC_OVL_FIR_COEF_H_0(VID3) 00000000 DISPC_OVL_FIR_COEF_H_1(VID3) 00000000 DISPC_OVL_FIR_COEF_H_2(VID3) 00000000 DISPC_OVL_FIR_COEF_H_3(VID3) 00000000 DISPC_OVL_FIR_COEF_H_4(VID3) 00000000 DISPC_OVL_FIR_COEF_H_5(VID3) 00000000 DISPC_OVL_FIR_COEF_H_6(VID3) 00000000 DISPC_OVL_FIR_COEF_H_7(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID3) 00000000 DISPC_OVL_CONV_COEF_0(VID3) 0199012a DISPC_OVL_CONV_COEF_1(VID3) 012a0000 DISPC_OVL_CONV_COEF_2(VID3) 079c0730 DISPC_OVL_CONV_COEF_3(VID3) 0000012a DISPC_OVL_CONV_COEF_4(VID3) 00000204 DISPC_OVL_FIR_COEF_V_0(VID3) 00000000 DISPC_OVL_FIR_COEF_V_1(VID3) 00000000 DISPC_OVL_FIR_COEF_V_2(VID3) 00000000 DISPC_OVL_FIR_COEF_V_3(VID3) 00000000 DISPC_OVL_FIR_COEF_V_4(VID3) 00000000 DISPC_OVL_FIR_COEF_V_5(VID3) 00000000 DISPC_OVL_FIR_COEF_V_6(VID3) 00000000 DISPC_OVL_FIR_COEF_V_7(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_0(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_1(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_2(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_3(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_4(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_5(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_6(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_7(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_0(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_1(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_2(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_3(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_4(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_5(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_6(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_7(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_0(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_1(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_2(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_3(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_4(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_5(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_6(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_7(VID3) 00000000 cat: /sys/kernel/debug/omapdss/dsi1_irqs: No such file or directory DSI_REVISION 00000040 DSI_SYSCONFIG 00000015 DSI_SYSSTATUS 00000001 DSI_IRQSTATUS 00000000 DSI_IRQENABLE 0015c000 DSI_CTRL 00eaee9f DSI_COMPLEXIO_CFG1 2a0dcba9 DSI_COMPLEXIO_IRQ_STATUS 00000000 DSI_COMPLEXIO_IRQ_ENABLE 3ff07fff DSI_CLK_CTRL a030400b DSI_TIMING1 ffff1000 DSI_TIMING2 ffffffff DSI_VM_TIMING1 00078003 DSI_VM_TIMING2 043c3232 DSI_VM_TIMING3 029a0500 DSI_CLK_TIMING 00001b10 DSI_TX_FIFO_VC_SIZE 13121110 DSI_RX_FIFO_VC_SIZE 13121110 DSI_COMPLEXIO_CFG2 00030000 DSI_RX_FIFO_VC_FULLNESS 00000000 DSI_VM_TIMING4 00000000 DSI_TX_FIFO_VC_EMPTINESS 1f1f1e1f DSI_VM_TIMING5 00000000 DSI_VM_TIMING6 01000007 DSI_VM_TIMING7 00100010 DSI_STOPCLK_TIMING 00000080 DSI_VC_CTRL(0) 20808f81 DSI_VC_TE(0) 00000000 DSI_VC_LONG_PACKET_HEADER(0) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(0) 00000000 DSI_VC_SHORT_PACKET_HEADER(0) 00000000 DSI_VC_IRQSTATUS(0) 00000000 DSI_VC_IRQENABLE(0) 000000db DSI_VC_CTRL(1) 20808fb1 DSI_VC_TE(1) 00000000 DSI_VC_LONG_PACKET_HEADER(1) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(1) 00000000 DSI_VC_SHORT_PACKET_HEADER(1) 00000000 DSI_VC_IRQSTATUS(1) 00000000 DSI_VC_IRQENABLE(1) 000000db DSI_VC_CTRL(2) 20808d81 DSI_VC_TE(2) 00000000 DSI_VC_LONG_PACKET_HEADER(2) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(2) 00000000 DSI_VC_SHORT_PACKET_HEADER(2) 00000000 DSI_VC_IRQSTATUS(2) 00000000 DSI_VC_IRQENABLE(2) 000000db DSI_VC_CTRL(3) 20808d81 DSI_VC_TE(3) 00000000 DSI_VC_LONG_PACKET_HEADER(3) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(3) 00000000 DSI_VC_SHORT_PACKET_HEADER(3) 00000000 DSI_VC_IRQSTATUS(3) 00000000 DSI_VC_IRQENABLE(3) 000000db DSI_DSIPHY_CFG0 132b1322 DSI_DSIPHY_CFG1 42c6103c DSI_DSIPHY_CFG2 b83e000f DSI_DSIPHY_CFG5 ff000000 DSI_PLL_CONTROL 00000018 DSI_PLL_STATUS 00006383 DSI_PLL_GO 00000000 DSI_PLL_CONFIGURATION1 10a03000 DSI_PLL_CONFIGURATION2 00656004 root@letux:~# root@letux:~# ./debugdsi - DSS - FCK = 192000000 - DISPC - dispc fclk source = FCK fck 192000000 - DISPC-CORE-CLK - lck 192000000 lck div 1 - LCD - LCD clk source = PLL1:1 lck 153600000 lck div 1 pck 76800000 pck div 2 - LCD2 - LCD2 clk source = FCK lck 48000000 lck div 4 pck 48000000 pck div 1 - LCD3 - LCD3 clk source = FCK lck 48000000 lck div 4 pck 48000000 pck div 1 DISPC_REVISION 00000051 DISPC_SYSCONFIG 00002015 DISPC_SYSSTATUS 00000001 DISPC_IRQSTATUS 000000a2 DISPC_IRQENABLE 0812d640 DISPC_CONTROL 00018309 DISPC_CONFIG 0000020c DISPC_CAPABLE 00000000 DISPC_LINE_STATUS 000001af DISPC_LINE_NUMBER 00000000 DISPC_GLOBAL_ALPHA ffffffff DISPC_CONTROL2 00000000 DISPC_CONFIG2 00000000 DISPC_CONTROL3 00000000 DISPC_CONFIG3 00000000 DISPC_GLOBAL_MFLAG_ATTRIBUTE 00000001 DISPC_DEFAULT_COLOR(LCD) 00000000 DISPC_TRANS_COLOR(LCD) 00000000 DISPC_SIZE_MGR(LCD) 04ff02cf DISPC_TIMING_H(LCD) 09d00800 DISPC_TIMING_V(LCD) 0320323b DISPC_POL_FREQ(LCD) 00060000 DISPC_DIVISORo(LCD) 00010002 DISPC_DATA_CYCLE1(LCD) 00000000 DISPC_DATA_CYCLE2(LCD) 00000000 DISPC_DATA_CYCLE3(LCD) 00000000 DISPC_CPR_COEF_R(LCD) 00000000 DISPC_CPR_COEF_G(LCD) 00000000 DISPC_CPR_COEF_B(LCD) 00000000 DISPC_DEFAULT_COLOR(TV) 00000000 DISPC_TRANS_COLOR(TV) 00000000 DISPC_SIZE_MGR(TV) 00000000 DISPC_DEFAULT_COLOR(LCD2) 00000000 DISPC_TRANS_COLOR(LCD2) 00000000 DISPC_SIZE_MGR(LCD2) 00000000 DISPC_TIMING_H(LCD2) 00000000 DISPC_TIMING_V(LCD2) 00000000 DISPC_POL_FREQ(LCD2) 00000000 DISPC_DIVISORo(LCD2) 00040001 DISPC_DATA_CYCLE1(LCD2) 00000000 DISPC_DATA_CYCLE2(LCD2) 00000000 DISPC_DATA_CYCLE3(LCD2) 00000000 DISPC_CPR_COEF_R(LCD2) 00000000 DISPC_CPR_COEF_G(LCD2) 00000000 DISPC_CPR_COEF_B(LCD2) 00000000 DISPC_DEFAULT_COLOR(LCD3) 00000000 DISPC_TRANS_COLOR(LCD3) 00000000 DISPC_SIZE_MGR(LCD3) 00000000 DISPC_TIMING_H(LCD3) 00000000 DISPC_TIMING_V(LCD3) 00000000 DISPC_POL_FREQ(LCD3) 00000000 DISPC_DIVISORo(LCD3) 00040001 DISPC_DATA_CYCLE1(LCD3) 00000000 DISPC_DATA_CYCLE2(LCD3) 00000000 DISPC_DATA_CYCLE3(LCD3) 00000000 DISPC_CPR_COEF_R(LCD3) 00000000 DISPC_CPR_COEF_G(LCD3) 00000000 DISPC_CPR_COEF_B(LCD3) 00000000 DISPC_OVL_BA0(GFX) d0003440 DISPC_OVL_BA1(GFX) d0003440 DISPC_OVL_POSITION(GFX) 00000000 DISPC_OVL_SIZE(GFX) 04ff02cf DISPC_OVL_ATTRIBUTES(GFX) 320040b1 DISPC_OVL_FIFO_THRESHOLD(GFX) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(GFX) 00000500 DISPC_OVL_ROW_INC(GFX) 000034c1 DISPC_OVL_PIXEL_INC(GFX) 00000001 DISPC_OVL_PRELOAD(GFX) 000007ff DISPC_OVL_MFLAG_THRESHOLD(GFX) 05000400 DISPC_OVL_WINDOW_SKIP(GFX) 00000000 DISPC_OVL_TABLE_BA(GFX) 00000000 DISPC_OVL_BA0(VID1) 00000000 DISPC_OVL_BA1(VID1) 00000000 DISPC_OVL_POSITION(VID1) 00000000 DISPC_OVL_SIZE(VID1) 00000000 DISPC_OVL_ATTRIBUTES(VID1) 02808400 DISPC_OVL_FIFO_THRESHOLD(VID1) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(VID1) 00000800 DISPC_OVL_ROW_INC(VID1) 00000001 DISPC_OVL_PIXEL_INC(VID1) 00000001 DISPC_OVL_PRELOAD(VID1) 000007ff DISPC_OVL_MFLAG_THRESHOLD(VID1) 05000400 DISPC_OVL_FIR(VID1) 04000400 DISPC_OVL_PICTURE_SIZE(VID1) 00000000 DISPC_OVL_ACCU0(VID1) 00000000 DISPC_OVL_ACCU1(VID1) 00000000 DISPC_OVL_BA0_UV(VID1) 00000000 DISPC_OVL_BA1_UV(VID1) 00000000 DISPC_OVL_FIR2(VID1) 04000400 DISPC_OVL_ACCU2_0(VID1) 00000000 DISPC_OVL_ACCU2_1(VID1) 00000000 DISPC_OVL_ATTRIBUTES2(VID1) 00000000 DISPC_OVL_BA0(VID2) 00000000 DISPC_OVL_BA1(VID2) 00000000 DISPC_OVL_POSITION(VID2) 00000000 DISPC_OVL_SIZE(VID2) 00000000 DISPC_OVL_ATTRIBUTES(VID2) 02808400 DISPC_OVL_FIFO_THRESHOLD(VID2) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(VID2) 00000800 DISPC_OVL_ROW_INC(VID2) 00000001 DISPC_OVL_PIXEL_INC(VID2) 00000001 DISPC_OVL_PRELOAD(VID2) 000007ff DISPC_OVL_MFLAG_THRESHOLD(VID2) 05000400 DISPC_OVL_FIR(VID2) 04000400 DISPC_OVL_PICTURE_SIZE(VID2) 00000000 DISPC_OVL_ACCU0(VID2) 00000000 DISPC_OVL_ACCU1(VID2) 00000000 DISPC_OVL_BA0_UV(VID2) 00000000 DISPC_OVL_BA1_UV(VID2) 00000000 DISPC_OVL_FIR2(VID2) 04000400 DISPC_OVL_ACCU2_0(VID2) 00000000 DISPC_OVL_ACCU2_1(VID2) 00000000 DISPC_OVL_ATTRIBUTES2(VID2) 00000000 DISPC_OVL_BA0(VID3) 00000000 DISPC_OVL_BA1(VID3) 00000000 DISPC_OVL_POSITION(VID3) 00000000 DISPC_OVL_SIZE(VID3) 00000000 DISPC_OVL_ATTRIBUTES(VID3) 02808400 DISPC_OVL_FIFO_THRESHOLD(VID3) 07ff07f8 DISPC_OVL_FIFO_SIZE_STATUS(VID3) 00000800 DISPC_OVL_ROW_INC(VID3) 00000001 DISPC_OVL_PIXEL_INC(VID3) 00000001 DISPC_OVL_PRELOAD(VID3) 000007ff DISPC_OVL_MFLAG_THRESHOLD(VID3) 05000400 DISPC_OVL_FIR(VID3) 04000400 DISPC_OVL_PICTURE_SIZE(VID3) 00000000 DISPC_OVL_ACCU0(VID3) 00000000 DISPC_OVL_ACCU1(VID3) 00000000 DISPC_OVL_BA0_UV(VID3) 00000000 DISPC_OVL_BA1_UV(VID3) 00000000 DISPC_OVL_FIR2(VID3) 04000400 DISPC_OVL_ACCU2_0(VID3) 00000000 DISPC_OVL_ACCU2_1(VID3) 00000000 DISPC_OVL_ATTRIBUTES2(VID3) 00000000 DISPC_OVL_BA0(WB) 00000000 DISPC_OVL_BA1(WB) 00000000 DISPC_OVL_SIZE(WB) 00000000 DISPC_OVL_ATTRIBUTES(WB) 00808000 DISPC_OVL_FIFO_THRESHOLD(WB) 00080000 DISPC_OVL_FIFO_SIZE_STATUS(WB) 00000800 DISPC_OVL_ROW_INC(WB) 00000001 DISPC_OVL_PIXEL_INC(WB) 00000001 DISPC_OVL_MFLAG_THRESHOLD(WB) 03200280 DISPC_OVL_FIR(WB) 04000400 DISPC_OVL_PICTURE_SIZE(WB) 00000000 DISPC_OVL_ACCU0(WB) 00000000 DISPC_OVL_ACCU1(WB) 00000000 DISPC_OVL_BA0_UV(WB) 00000000 DISPC_OVL_BA1_UV(WB) 00000000 DISPC_OVL_FIR2(WB) 04000400 DISPC_OVL_ACCU2_0(WB) 00000000 DISPC_OVL_ACCU2_1(WB) 00000000 DISPC_OVL_ATTRIBUTES2(WB) 00000000 DISPC_OVL_FIR_COEF_H_0(VID1) 00000000 DISPC_OVL_FIR_COEF_H_1(VID1) 00000000 DISPC_OVL_FIR_COEF_H_2(VID1) 00000000 DISPC_OVL_FIR_COEF_H_3(VID1) 00000000 DISPC_OVL_FIR_COEF_H_4(VID1) 00000000 DISPC_OVL_FIR_COEF_H_5(VID1) 00000000 DISPC_OVL_FIR_COEF_H_6(VID1) 00000000 DISPC_OVL_FIR_COEF_H_7(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID1) 00000000 DISPC_OVL_CONV_COEF_0(VID1) 0199012a DISPC_OVL_CONV_COEF_1(VID1) 012a0000 DISPC_OVL_CONV_COEF_2(VID1) 079c0730 DISPC_OVL_CONV_COEF_3(VID1) 0000012a DISPC_OVL_CONV_COEF_4(VID1) 00000204 DISPC_OVL_FIR_COEF_V_0(VID1) 00000000 DISPC_OVL_FIR_COEF_V_1(VID1) 00000000 DISPC_OVL_FIR_COEF_V_2(VID1) 00000000 DISPC_OVL_FIR_COEF_V_3(VID1) 00000000 DISPC_OVL_FIR_COEF_V_4(VID1) 00000000 DISPC_OVL_FIR_COEF_V_5(VID1) 00000000 DISPC_OVL_FIR_COEF_V_6(VID1) 00000000 DISPC_OVL_FIR_COEF_V_7(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_0(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_1(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_2(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_3(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_4(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_5(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_6(VID1) 00000000 DISPC_OVL_FIR_COEF_H2_7(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_0(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_1(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_2(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_3(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_4(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_5(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_6(VID1) 00000000 DISPC_OVL_FIR_COEF_HV2_7(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_0(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_1(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_2(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_3(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_4(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_5(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_6(VID1) 00000000 DISPC_OVL_FIR_COEF_V2_7(VID1) 00000000 DISPC_OVL_FIR_COEF_H_0(VID2) 00000000 DISPC_OVL_FIR_COEF_H_1(VID2) 00000000 DISPC_OVL_FIR_COEF_H_2(VID2) 00000000 DISPC_OVL_FIR_COEF_H_3(VID2) 00000000 DISPC_OVL_FIR_COEF_H_4(VID2) 00000000 DISPC_OVL_FIR_COEF_H_5(VID2) 00000000 DISPC_OVL_FIR_COEF_H_6(VID2) 00000000 DISPC_OVL_FIR_COEF_H_7(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID2) 00000000 DISPC_OVL_CONV_COEF_0(VID2) 0199012a DISPC_OVL_CONV_COEF_1(VID2) 012a0000 DISPC_OVL_CONV_COEF_2(VID2) 079c0730 DISPC_OVL_CONV_COEF_3(VID2) 0000012a DISPC_OVL_CONV_COEF_4(VID2) 00000204 DISPC_OVL_FIR_COEF_V_0(VID2) 00000000 DISPC_OVL_FIR_COEF_V_1(VID2) 00000000 DISPC_OVL_FIR_COEF_V_2(VID2) 00000000 DISPC_OVL_FIR_COEF_V_3(VID2) 00000000 DISPC_OVL_FIR_COEF_V_4(VID2) 00000000 DISPC_OVL_FIR_COEF_V_5(VID2) 00000000 DISPC_OVL_FIR_COEF_V_6(VID2) 00000000 DISPC_OVL_FIR_COEF_V_7(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_0(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_1(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_2(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_3(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_4(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_5(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_6(VID2) 00000000 DISPC_OVL_FIR_COEF_H2_7(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_0(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_1(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_2(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_3(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_4(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_5(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_6(VID2) 00000000 DISPC_OVL_FIR_COEF_HV2_7(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_0(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_1(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_2(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_3(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_4(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_5(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_6(VID2) 00000000 DISPC_OVL_FIR_COEF_V2_7(VID2) 00000000 DISPC_OVL_FIR_COEF_H_0(VID3) 00000000 DISPC_OVL_FIR_COEF_H_1(VID3) 00000000 DISPC_OVL_FIR_COEF_H_2(VID3) 00000000 DISPC_OVL_FIR_COEF_H_3(VID3) 00000000 DISPC_OVL_FIR_COEF_H_4(VID3) 00000000 DISPC_OVL_FIR_COEF_H_5(VID3) 00000000 DISPC_OVL_FIR_COEF_H_6(VID3) 00000000 DISPC_OVL_FIR_COEF_H_7(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID3) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID3) 00000000 DISPC_OVL_CONV_COEF_0(VID3) 0199012a DISPC_OVL_CONV_COEF_1(VID3) 012a0000 DISPC_OVL_CONV_COEF_2(VID3) 079c0730 DISPC_OVL_CONV_COEF_3(VID3) 0000012a DISPC_OVL_CONV_COEF_4(VID3) 00000204 DISPC_OVL_FIR_COEF_V_0(VID3) 00000000 DISPC_OVL_FIR_COEF_V_1(VID3) 00000000 DISPC_OVL_FIR_COEF_V_2(VID3) 00000000 DISPC_OVL_FIR_COEF_V_3(VID3) 00000000 DISPC_OVL_FIR_COEF_V_4(VID3) 00000000 DISPC_OVL_FIR_COEF_V_5(VID3) 00000000 DISPC_OVL_FIR_COEF_V_6(VID3) 00000000 DISPC_OVL_FIR_COEF_V_7(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_0(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_1(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_2(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_3(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_4(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_5(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_6(VID3) 00000000 DISPC_OVL_FIR_COEF_H2_7(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_0(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_1(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_2(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_3(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_4(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_5(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_6(VID3) 00000000 DISPC_OVL_FIR_COEF_HV2_7(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_0(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_1(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_2(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_3(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_4(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_5(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_6(VID3) 00000000 DISPC_OVL_FIR_COEF_V2_7(VID3) 00000000 cat: /sys/kernel/debug/omapdss/dsi1_irqs: No such file or directory DSI_REVISION 00000040 DSI_SYSCONFIG 00000015 DSI_SYSSTATUS 00000001 DSI_IRQSTATUS 00000000 DSI_IRQENABLE 0015c000 DSI_CTRL 00eaee9f DSI_COMPLEXIO_CFG1 2a0dcba9 DSI_COMPLEXIO_IRQ_STATUS 00000000 DSI_COMPLEXIO_IRQ_ENABLE 3ff07fff DSI_CLK_CTRL a030600b DSI_TIMING1 ffff1000 DSI_TIMING2 ffffffff DSI_VM_TIMING1 00005076 DSI_VM_TIMING2 043c3232 DSI_VM_TIMING3 029a0500 DSI_CLK_TIMING 00001b10 DSI_TX_FIFO_VC_SIZE 13121110 DSI_RX_FIFO_VC_SIZE 13121110 DSI_COMPLEXIO_CFG2 00030000 DSI_RX_FIFO_VC_FULLNESS 00000000 DSI_VM_TIMING4 00000000 DSI_TX_FIFO_VC_EMPTINESS 1f1f1f1f DSI_VM_TIMING5 00000000 DSI_VM_TIMING6 01340007 DSI_VM_TIMING7 00100010 DSI_STOPCLK_TIMING 00000080 DSI_VC_CTRL(0) 20808f91 DSI_VC_TE(0) 00000000 DSI_VC_LONG_PACKET_HEADER(0) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(0) 00000000 DSI_VC_SHORT_PACKET_HEADER(0) 00000000 DSI_VC_IRQSTATUS(0) 00000004 DSI_VC_IRQENABLE(0) 000000db DSI_VC_CTRL(1) 20808d81 DSI_VC_TE(1) 00000000 DSI_VC_LONG_PACKET_HEADER(1) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(1) 00000000 DSI_VC_SHORT_PACKET_HEADER(1) 00000000 DSI_VC_IRQSTATUS(1) 00000004 DSI_VC_IRQENABLE(1) 000000db DSI_VC_CTRL(2) 20808d81 DSI_VC_TE(2) 00000000 DSI_VC_LONG_PACKET_HEADER(2) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(2) 00000000 DSI_VC_SHORT_PACKET_HEADER(2) 00000000 DSI_VC_IRQSTATUS(2) 00000000 DSI_VC_IRQENABLE(2) 000000db DSI_VC_CTRL(3) 20808d81 DSI_VC_TE(3) 00000000 DSI_VC_LONG_PACKET_HEADER(3) 00000000 DSI_VC_LONG_PACKET_PAYLOAD(3) 00000000 DSI_VC_SHORT_PACKET_HEADER(3) 00000000 DSI_VC_IRQSTATUS(3) 00000000 DSI_VC_IRQENABLE(3) 000000db DSI_DSIPHY_CFG0 132b1322 DSI_DSIPHY_CFG1 42c6103c DSI_DSIPHY_CFG2 b800000f DSI_DSIPHY_CFG5 ff000000 DSI_PLL_CONTROL 00000018 DSI_PLL_STATUS 00006383 DSI_PLL_GO 00000000 DSI_PLL_CONFIGURATION1 10a03000 DSI_PLL_CONFIGURATION2 00656004 root@letux:~#
Hi, This is third version of the series sent by Sebastian in February: https://www.spinics.net/lists/linux-omap/msg153465.html I took the patches from his git tree, and rebased on 5.10-rc2. There were some conflicts and compilation errors, and one bug that made dsi to not work (videomode variable was not initialized to 0). I then fixed the few checkpatch and sparse issues. Overall, Sebastian's patches are pretty much as they were previously. I did drop Laurent's reviewed-bys, as it's been a long time since the previous series, and the patches are not identical anyway. The topmost 5 patches are new ones, cleanups enabled by the DSI conversion. They could be handled separately, but it's such a nice cleanup, and I've been waiting for years to get this done, so here they are. That said, there are still a _lot_ of cleanups to do. Almost all of the patches are omapdrm changes. The two non-omapdrm changes are: - After converting panel-dsi-cm to common DRM panel model, it is moved to drm's panel directory. - Add MIPI_DSI_MODE_ULPS_IDLE flag I have tested these with OMAP4 SDP, AM5 EVM and OMAP4 Panda. SDP has command mode panel, and I don't have any videomode panels. Sebastian, I hope you're ok with all this? I did send you an email, but didn't get a reply yet, so I thought to just proceed. If you want to handle this in some other way, or don't want your authorship/signed-off-by in some of the commits, just tell. Tomi Sebastian Reichel (51): drm/dsi: add MIPI_DSI_MODE_ULPS_IDLE Revert "drm/omap: dss: Remove unused omap_dss_device operations" drm/omap: 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/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: remove global dss_device variable 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 drm/omap: dsi: simplify pin config ARM: omap2plus_defconfig: Update for moved DSI command mode panel Tomi Valkeinen (5): drm/omap: squash omapdrm sub-modules into one drm/omap: remove unused display.c drm/omap: drop unused owner field drm/omap: remove dispc_ops drm/omap: remove dss_mgr_ops arch/arm/configs/omap2plus_defconfig | 2 +- drivers/gpu/drm/omapdrm/Kconfig | 120 +- drivers/gpu/drm/omapdrm/Makefile | 19 +- drivers/gpu/drm/omapdrm/displays/Kconfig | 10 - drivers/gpu/drm/omapdrm/displays/Makefile | 2 - .../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 1385 ----------------- drivers/gpu/drm/omapdrm/dss/Kconfig | 135 -- drivers/gpu/drm/omapdrm/dss/Makefile | 20 - drivers/gpu/drm/omapdrm/dss/base.c | 87 +- drivers/gpu/drm/omapdrm/dss/dispc.c | 101 +- drivers/gpu/drm/omapdrm/dss/display.c | 60 - drivers/gpu/drm/omapdrm/dss/dpi.c | 1 - drivers/gpu/drm/omapdrm/dss/dsi.c | 1069 ++++++++----- drivers/gpu/drm/omapdrm/dss/dss.c | 28 +- drivers/gpu/drm/omapdrm/dss/dss.h | 72 +- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 - drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 - .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 229 --- drivers/gpu/drm/omapdrm/dss/omapdss.h | 278 +--- drivers/gpu/drm/omapdrm/dss/output.c | 57 +- drivers/gpu/drm/omapdrm/dss/sdi.c | 1 - drivers/gpu/drm/omapdrm/dss/venc.c | 2 - drivers/gpu/drm/omapdrm/omap_connector.c | 157 -- drivers/gpu/drm/omapdrm/omap_connector.h | 28 - drivers/gpu/drm/omapdrm/omap_crtc.c | 103 +- drivers/gpu/drm/omapdrm/omap_crtc.h | 2 - drivers/gpu/drm/omapdrm/omap_drv.c | 65 +- drivers/gpu/drm/omapdrm/omap_drv.h | 3 +- drivers/gpu/drm/omapdrm/omap_encoder.c | 59 +- drivers/gpu/drm/omapdrm/omap_irq.c | 34 +- drivers/gpu/drm/omapdrm/omap_plane.c | 12 +- drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-dsi-cm.c | 647 ++++++++ include/drm/drm_mipi_dsi.h | 2 + 35 files changed, 1718 insertions(+), 3084 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/displays/Kconfig delete mode 100644 drivers/gpu/drm/omapdrm/displays/Makefile delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c delete mode 100644 drivers/gpu/drm/omapdrm/dss/Kconfig delete mode 100644 drivers/gpu/drm/omapdrm/dss/Makefile delete mode 100644 drivers/gpu/drm/omapdrm/dss/display.c delete mode 100644 drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c delete mode 100644 drivers/gpu/drm/omapdrm/omap_connector.c delete mode 100644 drivers/gpu/drm/omapdrm/omap_connector.h create mode 100644 drivers/gpu/drm/panel/panel-dsi-cm.c