Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 : > > On 13/11/2020 16:41, H. Nikolaus Schaller wrote: >> Hi Tomi, >> >>> Am 13.11.2020 um 14:38 schrieb Tomi Valkeinen : >>> >>> 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 = 19200 - DISPC - dispc fclk source = FCK fck 19200 - DISPC-CORE-CLK - lck 19200 lck div 1 - LCD - LCD clk source = PLL1:1 lck 15360 lck div 1 pck 7680pck div 2 - LCD2 - LCD2 clk source = FCK lck 4800lck div 4 pck 4800pck div 1 - LCD3 - LCD3 clk source = FCK lck 4800lck div 4 pck 4800pck div 1 DISPC_REVISION 0051 DISPC_SYSCONFIG2015 DISPC_SYSSTATUS0001 DISPC_IRQSTATUS00a2 DISPC_IRQENABLE0812d640 DISPC_CONTROL 00018309 DISPC_CONFIG 020c DISPC_CAPABLE DISPC_LINE_STATUS 03e3 DISPC_LINE_NUMBER DISPC_GLOBAL_ALPHA DISPC_CONTROL2 DISPC_CONFIG2 DISPC_CONTROL3 DISPC_CONFIG3 DISPC_GLOBAL_MFLAG_ATTRIBUTE 0001 DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_SIZE_MGR(LCD)04ff02cf DISPC_TIMING_H(LCD)0040a100 DISPC_TIMING_V(LCD)0320323b DISPC_POL_FREQ(LCD)0006 DISPC_DIVISORo(LCD)00010002 DISPC_DATA_CYCLE1(LCD) DISPC_DATA_CYCLE2(LCD) DISPC_DATA_CYCLE3(LCD) DISPC_CPR_COEF_R(LCD)
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 11.11.2020 um 11:11 schrieb Tomi Valkeinen : > > On 11/11/2020 09:48, H. Nikolaus Schaller wrote: >> >>> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen : >>> >>> On 10/11/2020 23:04, H. Nikolaus Schaller wrote: > Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen : > > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
On 11/11/2020 09:48, H. Nikolaus Schaller wrote: > >> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen : >> >> On 10/11/2020 23:04, H. Nikolaus Schaller wrote: >>> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen : 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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
On 10/11/2020 23:04, H. Nikolaus Schaller wrote: > >> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen : >> >> 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=1920 pll_min=1555386656 > pll_max=1555410656 func=dsi_vm_calc_pll_cb+0x0/0x48 [omapdrm] > [ 277.084975] dss_pll_calc_a pll_hw_max=18 fint_hw_min=15 > fint_hw_max=5200 > [ 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=1920 fint=1920 > [ 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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 10.11.2020 um 14:49 schrieb H. Nikolaus Schaller : > > Hi Tomi, > >> Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen : >> >> 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 5800.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 NIVIRTRESSHR 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Tomi, > Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen : > > 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 5800.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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen : > > On 10/11/2020 23:04, H. Nikolaus Schaller wrote: >> >>> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen : >>> >>> 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen : > > 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=1920 pll_min=1555386656 pll_max=1555410656 func=dsi_vm_calc_pll_cb+0x0/0x48 [omapdrm] [ 277.084975] dss_pll_calc_a pll_hw_max=18 fint_hw_min=15 fint_hw_max=5200 [ 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=1920 fint=1920 [ 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
On 10/11/2020 18:49, H. Nikolaus Schaller wrote: > >> Am 10.11.2020 um 14:49 schrieb H. Nikolaus Schaller : >> >> Hi Tomi, >> >>> Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen : >>> >>> 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 5800.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 NIVIRTRESSHR 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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 5800.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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen : > > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 09.11.2020 um 11:34 schrieb Tomi Valkeinen : > > On 09/11/2020 12:31, H. Nikolaus Schaller wrote: >> >>> Am 09.11.2020 um 11:22 schrieb Tomi Valkeinen : >>> >>> On 09/11/2020 11:30, H. Nikolaus Schaller wrote: > Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen : > > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 09.11.2020 um 11:22 schrieb Tomi Valkeinen : > > On 09/11/2020 11:30, H. Nikolaus Schaller wrote: >> >>> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen : >>> >>> 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
On 09/11/2020 12:31, H. Nikolaus Schaller wrote: > >> Am 09.11.2020 um 11:22 schrieb Tomi Valkeinen : >> >> On 09/11/2020 11:30, H. Nikolaus Schaller wrote: >>> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen : 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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
On 09/11/2020 11:30, H. Nikolaus Schaller wrote: > >> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen : >> >> 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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Tomi, > Am 06.11.2020 um 16:04 schrieb Tomi Valkeinen : > >> >> 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 5800.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 5800.dss: bound 58001000.dispc (ops >> dispc_component_ops [omapdrm]) >> [ 119.858673] omapdss_dss 5800.dss: bound 58004000.encoder (ops >> dsi_component_ops [omapdrm]) >> [ 119.882629] omapdss_dss 5800.dss: bound 58005000.encoder (ops >> dsi_component_ops [omapdrm]) >> [ 119.902069] omapdss_dss 5800.dss: bound 58006000.encoder (ops >> hdmi4_component_ops [omapdrm]) >> [ 119.962066] dmm 4e00.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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 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
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 : >>> >>> On 05/11/2020 20:14, H. Nikolaus Schaller wrote: > Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen : > > 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 5800.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 5800.dss: bound 58001000.dispc (ops > dispc_component_ops [omapdrm]) > [ 119.858673] omapdss_dss 5800.dss: bound 58004000.encoder (ops > dsi_component_ops [omapdrm]) > [ 119.882629] omapdss_dss 5800.dss: bound 58005000.encoder (ops > dsi_component_ops [omapdrm]) > [ 119.902069] omapdss_dss 5800.dss: bound 58006000.encoder (ops > hdmi4_component_ops [omapdrm]) > [ 119.962066] dmm 4e00.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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
On 05/11/2020 20:56, H. Nikolaus Schaller wrote: > >> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen : >> >> On 05/11/2020 20:14, H. Nikolaus Schaller wrote: >>> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen : 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 5800.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 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 119.858673] omapdss_dss 5800.dss: bound 58004000.encoder (ops dsi_component_ops [omapdrm]) [ 119.882629] omapdss_dss 5800.dss: bound 58005000.encoder (ops dsi_component_ops [omapdrm]) [ 119.902069] omapdss_dss 5800.dss: bound 58006000.encoder (ops hdmi4_component_ops [omapdrm]) [ 119.962066] dmm 4e00.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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen : > > On 05/11/2020 20:14, H. Nikolaus Schaller wrote: >> >>> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen : >>> >>> 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen : > > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Tomi, > Am 05.11.2020 um 13:02 schrieb Tomi Valkeinen : > > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
On 05/11/2020 20:14, H. Nikolaus Schaller wrote: > >> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen : >> >> 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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 -- 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: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
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 -
