[PATCH] imx-drm: gamma correction for imx-ldb

Lucas Stach l.stach at pengutronix.de
Mon Dec 9 08:29:00 PST 2013


Am Sonntag, den 08.12.2013, 22:20 +0100 schrieb Peter Seiderer:
> Hello Lucas,
> 
> On Fri, Dec 06, 2013 at 11:04:39AM +0100, Lucas Stach wrote:
> > Hi Peter,
> > 
> > Am Donnerstag, den 05.12.2013, 23:45 +0100 schrieb Peter Seiderer:
> > > Signed-off-by: Peter Seiderer <ps.report at gmx.net>
> > > ---
> > >  arch/arm/boot/dts/imx6q-sabrelite.dts       |  3 +++
> > >  drivers/staging/imx-drm/imx-drm-core.c      | 27 +++++++++++++++++++++++
> > >  drivers/staging/imx-drm/imx-drm.h           |  4 ++++
> > >  drivers/staging/imx-drm/imx-ldb.c           | 18 ++++++++++++++++
> > >  drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |  2 ++
> > >  drivers/staging/imx-drm/ipu-v3/ipu-dp.c     | 33 +++++++++++++++++++++++++++++
> > >  drivers/staging/imx-drm/ipuv3-crtc.c        |  9 ++++++++
> > >  7 files changed, 96 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
> > > index fca8f220..5dabc45 100644
> > > --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> > > +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> > > @@ -171,6 +171,9 @@
> > >     lvds-channel at 0 {
> > >             fsl,data-mapping = "spwg";
> > >             fsl,data-width = <18>;
> > > +           /* gamma = 0.6 */
> > > +           fsl,gamma-constk = /bits/ 16 <0x000 0x000 0x000 0x000 0x1ff 0x001 0x009 0x015 0x025 0x037 0x04d 0x064 0x07f 0x09c 0x0bb 0x0dc>;
> > > +           fsl,gamma-slopek = /bits/ 16 <0x000 0x000 0x000 0x000 0x002 0x008 0x00c 0x010 0x012 0x016 0x017 0x01b 0x01d 0x01f 0x021 0x022>;
> > >             status = "okay";
> 
> > Sorry, but I strongly oppose the addition of these values to the DT.
> > 
> > Gamma isn't a fixed hardware value, but something that should be
> > configurable from userspace via the KMS interface. Other drivers
> > historically did this through setting of the color LUT, but I see we may
> > need some other solution for imx-drm here. Still your proposed solution
> > doesn't look right.
> > 
> > Regards,
> > Lucas
> 
> My reasoning here was that for an embedded solution the gamma correction is more a fixed value depending on the output device (here the lvds display and no pluggable device) and should belong
> to the other lvds device specific values...
> 
> But nevertheless, do you have any more hint/suggestion where (or howto) to implement this feature?
> 
Hm, seems I was confused by the reference manual talking about a
polynomial and stuff.
At a second look it seems like you can just use the KMS interface (look
at the crtc's gamma_set() callback) to let usespace pass in the gamma
ramp, from which you can then extract the Gout1..15 values and use the
formula from the reference manual to calculate the appropriate register
values.

Be aware that the DRM interface seems to expect the gamma as a 8.8 fixed
number normalized to the gamma ramp size, so you need to do some
renormalization to meet the hardware expectations and any gamma ramp
size above 256 is invalid.

Regards,
Lucas

-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



More information about the dri-devel mailing list