dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jyri Sarha <jsarha@ti.com>
To: Karl Beldan <kbeldan@baylibre.com>,
	dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org
Cc: Kevin Hilman <khilman@baylibre.com>,
	Karl Beldan <karl.beldan+oss@gmail.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Sekhar Nori <nsekhar@ti.com>
Subject: Re: [PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1
Date: Tue, 23 Aug 2016 19:24:42 +0300	[thread overview]
Message-ID: <e659bff8-7c8e-35ed-e834-1e00d5c32931@ti.com> (raw)
In-Reply-To: <20160823125701.25700-1-kbeldan@baylibre.com>

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(-)
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2016-08-23 16:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 12:56 [PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1 Karl Beldan
2016-08-23 12:56 ` [PATCH 1/3] drm/tilcdc: Adjust the FB_CEILING address Karl Beldan
2016-08-23 12:57 ` [PATCH 2/3] drm/tilcdc: Enable EOF interrupts for v1 LCDC Karl Beldan
2016-08-23 12:57 ` [PATCH 3/3] drm/tilcdc: Advertise the DRM_FORMATs according to the IP revision Karl Beldan
2016-08-23 16:24 ` Jyri Sarha [this message]
2016-08-26 16:54   ` [PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1 Karl Beldan
2016-08-31 22:11   ` Kevin Hilman
2016-09-02 12:29     ` Jyri Sarha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e659bff8-7c8e-35ed-e834-1e00d5c32931@ti.com \
    --to=jsarha@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=karl.beldan+oss@gmail.com \
    --cc=kbeldan@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nsekhar@ti.com \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox