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

[Bartosz Golaszewski]

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.

> 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.

Thanks,
Bartosz