[PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel

[Tomi Valkeinen]

On 11/11/2020 09:48, H. Nikolaus Schaller wrote:
> 
>> Am 11.11.2020 um 07:40 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
>>
>> On 10/11/2020 23:04, H. Nikolaus Schaller wrote:
>>>
>>>> Am 10.11.2020 um 17:52 schrieb Tomi Valkeinen <tomi.valkeinen at 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

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