[PATCH v2 0/7] drm/tilcdc: LCDC Revision 1 related fixes

Bartosz Golaszewski bgolaszewski at baylibre.com
Fri Nov 18 10:31:50 UTC 2016


2016-11-17 21:06 GMT+01:00 Jyri Sarha <jsarha at ti.com>:
> On 11/17/16 13:31, Bartosz Golaszewski wrote:
>> 2016-11-16 19:00 GMT+01:00 Jyri Sarha <jsarha at ti.com>:
>>> On 11/16/16 17:18, Bartosz Golaszewski wrote:
>>>> 2016-11-16 13:40 GMT+01:00 Jyri Sarha <jsarha at ti.com>:
>>>>> Changes since first version of the series:
>>>>>
>>>>> - Move tilcdc_regs.h changes from "drm/tilcdc: Enable palette loading
>>>>>   for revision 2 LCDC too" to "drm/tilcdc: Add tilcdc_write_mask() to
>>>>>   tilcdc_regs.h"
>>>>>
>>>>> These patches are inspired by this series form Bartosz Golaszewski:
>>>>> https://www.spinics.net/lists/arm-kernel/msg539629.html
>>>>>
>>>>> The patches are based on drm-next plus the earlier patches that I plan
>>>>> to send in a pull request for 4.10. The base + these patches are
>>>>> pushed here:
>>>>>
>>>>> https://github.com/jsarha/linux drm-next-tilcdc-for-4.10-wip
>>>>>
>>>>> Bartosz, please test if this branch works for rev1 LCDC, with your dts
>>>>> file!
>>>>>
>>>>
>>>> Hi Jyri,
>>>>
>>>> with your changes I'm getting the following warning on initialization:
>>>>
>>>> [drm] Initialized
>>>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>>> [drm] No driver support for vblank timestamp query.
>>>> ------------[ cut here ]------------
>>>> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1141
>>>> drm_atomic_helper_wait_for_vblanks+0x23c/0x24c
>>>> [CRTC:24] vblank wait timed out
>>>> Modules linked in:
>>>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc4-00939-ge79af2c #60
>>>> Hardware name: Generic DA850/OMAP-L138/AM18x
>>>> Backtrace:
>>>>     [snip]
>>>>
>>>> and the same when running simple modetest (no vsynced page flipping).
>>>>
>>>
>>> Weird. I have never seen that warning. Are you receiving
>>> LCDC_END_OF_FRAME0 interrupts at all?
>>>
>>
>> I'm only getting three right after drm initialization and then,
>> something seems to be disabling them (maybe as the result of vblank
>> timeout?).
>>
>>> Am I missing some interrupt enable bit for rev 1 LCDC?
>>>
>>
>> Rather the interrupt is disabled after being enabled first.
>>
>
> I double checked the my code, but could not find anything wrong with
> interrupt enables and disables (but I found something else to fix[1]).
>
> Could you check from debug-fs if the LCDC_RASTER_CTRL_REG bit 3 is
> really 1 (frame done interrupt enabled) when ever display is on [2]?
>
>>> AFAIK the drm_crtc_send_vblank_event() should get called for the drm
>>> atomic state even when the  LCDC_END_OF_FRAME0 interrupt is received and
>>> the (mandatory) framebuffer is on the screen.
>>>
>>
>> I'll investigate that, thanks for the hint.
>>
>>>> The default resolution still works and I can start a graphical environment.
>>>>
>>>
>>> Was this with the panel hack or using dumb-vga-dac bridge?
>>>
>>
>> Yes, still the panel hack. I'll test the vga-dac after I can sort out
>> this issue.
>>
>
> Ok, but do not expect that using vga-dac would make much difference.
>
> Cheers,
> Jyri
>
> [1] I found that I left the disabling of palette loaded irq for rev 1 in
> irc routine. My latest version removed the clearing all together.
> Calling the complete more than once should not make any harm, and the
> palette loaded interrupt appears to come only once anyway. I also added
> a timeout for wait_for_completion() because we do not want things to
> hang forever even if the interrupt never arrives. However, these changes
> should not make any difference on how the driver works on LCDC rev 1.
> The latest version, that is also rebased on the latest drm-next, is now in:
>
> https://github.com/jsarha/linux drm-next-tilcdc-for-4.10-wip
>
> [2] cat /sys/kernel/debug/dri/64/regs (as root)
>

Hi Jyri,

the current version hangs after

    [drm] Initialized
    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [drm] No driver support for vblank timestamp query.

I'll try applying one patch at a time and when I find the one that
breaks stuff I'll try to pinpoint the place where it fails.

Thanks,
Bartosz


More information about the dri-devel mailing list