[PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1

Jyri Sarha jsarha at ti.com
Tue Aug 23 09:24:42 PDT 2016


Thanks a lot!
This is very helpful as I do not have LCDC rev1 HW my self, but only
am335x based boards.

On 08/23/16 15:56, Karl Beldan wrote:
> Hi,
> 
> I found some missing bits for rev1 of the LCDC and here are some of the
> changes I am using to use the DRM driver on an LCDCK (which has a rev1).
> 1/3 seems required by rev1 of the IP and without it my the LCDC on my
> LCDK keeps can't sync, 2/3 is required by the driver logic, while 3/3
> is less of a requirement.

I'll drop 3/3, because my recent patches should take care of that:
http://www.spinics.net/lists/devicetree/msg138885.html

However, there will be v2 round of those patches. Only the DT binding
and its default value should change.

> Although 1,2/3 would have fitted drm-fixes I based them on drm-next as
> 2/3 would conflict with the recent changes in drm-next.
> 

I'll pick these two up for my next pull request. Thanks!

> Another thing which is also an absolute requirement for the rev1 but 
> with which rev2 seems to cope fine is the palette loading (even if the DRM
> uses >= 16bpp formats), dixit the TRM:
> "12-, 16-, and 24-BPP modes do not need a palette; i.e., the pixel data is
> the desired RGB value. However, the first 32 bytes are still considered a
> palette. The first entry should be 4000h (bit 14 is 1) while the remaining
> entries must be filled with 0.".
> ATM I am using a local crude way of loading the palette to verify the
> missing bits to get the DRM driver properly working on the LCDK (as I
> haven't seen how things work in the DRM subsystem I can't post any proper
> change for that).
> 

I see. Reading from the TRM, that should be done for rev2 too. I'll try
to come up with a patch for that at some point, unless you send me one
first.

> The posted changes and the above mentioned palette loading missing bit 
> are specific to the DRM driver.
> 
> However there are other shortcomings to the proper functioning of the 
> LCDC on some platforms (I am currently focusing on the LCDK but I guess 
> it should be true for all da850 based systems), which are not inherent to
> the DRM driver driver but which strongly relate to it:
> 
> - The pixel clock rate setting (eg. currently the davinci clk can't cope
> properly with the DRM driver way of setting the clock and doesn't use
> the common clock framework)
> - The memory bandwidth/latency requirements for the LCDC are not met 
> with the default priority settings (apparently there is a fix in
> da850_lcd_hw_init of: http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-omapl138-lcdk.c;h=689b4f304011e09e262782cf8c4b96eba00ac28b;hb=HEAD).
> Of course this one affects both the DRM and framebuffer systems.
> 

There is also memory bandwidth issues on am335x and we are still looking
for a proper system level fix.

> Hence to test the LCDK my crude local changes include (ie. on top of the
> posted changes and some dts or sync_lost recovery bits):
> - palette loading
> - tweak of the pixel clock to cope with davinci clk

If you have proper a fixes for these, please send a patch. The palette
loading is something I can probably do myself too, but the clock thing
is something that I at least can not test.

> - adjustment of the memory master priorities
> 

That would be a system level fix and I can not say whether or not to
take such a fix.

> 
> BTW, with the recent changes of tilcdc from drm-next, I see this warning
> when loading the module:
> "drm:drm_helper_disable_unused_functions [drm_kms_helper]] *ERROR* Called for atomic driver, this is not what you want."
> 

That is also fixed in my latest patch series above.

Best regards,
Jyri

> 
> Regards, 
> Karl
> 
> 
> Karl Beldan (3):
>   drm/tilcdc: Adjust the FB_CEILING address
>   drm/tilcdc: Enable EOF interrupts for v1 LCDC
>   drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision
> 
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c  | 4 +++-
>  drivers/gpu/drm/tilcdc/tilcdc_plane.c | 7 ++++++-
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 




More information about the linux-arm-kernel mailing list