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

Jyri Sarha jsarha at ti.com
Thu Nov 17 20:06:17 UTC 2016


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)



More information about the dri-devel mailing list