[PATCH v3] drm/fsl-dcu: Implement gamma_lut atomic crtc properties
Ville Syrjälä
ville.syrjala at linux.intel.com
Mon Sep 26 08:17:53 UTC 2016
On Mon, Sep 26, 2016 at 09:59:25AM +0200, Daniel Vetter wrote:
> On Mon, Sep 26, 2016 at 06:04:09AM +0000, Meng Yi wrote:
> >
> >
> > > On Wed, Sep 21, 2016 at 11:10:11AM -0700, Stefan Agner wrote:
> > > > On 2016-09-13 01:49, Meng Yi wrote:
> > > > >> > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig
> > > > >> > b/drivers/gpu/drm/fsl-dcu/Kconfig index 14a72c4..f9c76b1 100644
> > > > >> > --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> > > > >> > +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> > > > >> > @@ -11,3 +11,9 @@ config DRM_FSL_DCU
> > > > >> > help
> > > > >> > Choose this option if you have an Freescale DCU chipset.
> > > > >> > If M is selected the module will be called fsl-dcu-drm.
> > > > >> > +
> > > > >> > +config DRM_FSL_DCU_GAMMA
> > > > >> > + bool "Gamma Correction Support for NXP/Freescale DCU"
> > > > >> > + depends on DRM_FSL_DCU
> > > > >> > + help
> > > > >> > + Enable support for gamma correction.
> > > > >>
> > > > >> What is the reason for making this a configuration option? Are
> > > > >> there implementation without support for the Gamma tables?
> > > > >>
> > > > > When gamma correction is enabled, the color won't display normally
> > > > > since The gamma tables are not filled with correct data. So I give a
> > > > > choice to not using The gamma correction when you don't want to use
> > > > > it.
> > > > >
> > > > > Should I remove this configuration?
> > > >
> > > > Yeah making this a compile time configuration seems wrong to me.
> > > >
> > > > I guess we should fill the table with a reasonable default then. The
> > > > omapdrm driver seems to do something similar.
> > >
> > > Yup Kconfig is definitely not the correct way to fix a setup problem in your
> > > driver. Note that even when you enable gamma lut userspace is allowed to set
> > > a NULL table, and in that case you need to either disable the gamma lut, or fill it
> > > with a 1:1 mapping (if you hw doesn't have a disable flag). At boot-up the table
> > > will also be NULL (except when you have special setup code), and if that results
> > > in a black screen your driver is buggy. Papering over a driver bug with Kconfig is
> > > definitely not ok.
> >
> > How about initialize the tables with static array(such as gmma = 2.2, etc)
>
> Linear ramp as the default (which is dead easy to generate) should be good
> enough imo, but I guess you can go with something else too.
Linear would seem like a sane default choice to me as photos/videos etc. are
typically stored with gamma included. And when the compositor/etc. is not gamma
aware you might not want to apply the gamma twice for such things.
> -Daniel
>
> >
> > /*gamma = 2.2*/
> > u32 gamma_default_lut[] = {
> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02,
> > 0x02, 0x02, 0x02, 0x02, 0x03, 0x03, 0x03, 0x03, 0x03, 0x04, 0x04, 0x04, 0x04, 0x05, 0x05, 0x05,
> > 0x06, 0x06, 0x06, 0x07, 0x07, 0x07, 0x08, 0x08, 0x08, 0x09, 0x09, 0x09, 0x0A, 0x0A, 0x0B, 0x0B,
> > 0x0B, 0x0C, 0x0C, 0x0D, 0x0D, 0x0E, 0x0E, 0x0E, 0x0F, 0x0F, 0x10, 0x10, 0x11, 0x11, 0x12, 0x13,
> > 0x13, 0x14, 0x14, 0x15, 0x15, 0x16, 0x17, 0x17, 0x18, 0x18, 0x19, 0x1A, 0x1A, 0x1B, 0x1C, 0x1C,
> > 0x1D, 0x1E, 0x1E, 0x1F, 0x20, 0x20, 0x21, 0x22, 0x23, 0x23, 0x24, 0x25, 0x26, 0x27, 0x27, 0x28,
> > 0x29, 0x2A, 0x2B, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x32, 0x33, 0x34, 0x35, 0x36,
> > 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F, 0x40, 0x41, 0x42, 0x43, 0x44, 0x46, 0x47,
> > 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4F, 0x50, 0x51, 0x52, 0x53, 0x54, 0x56, 0x57, 0x58, 0x59,
> > 0x5B, 0x5C, 0x5D, 0x5E, 0x60, 0x61, 0x62, 0x64, 0x65, 0x66, 0x68, 0x69, 0x6A, 0x6C, 0x6D, 0x6F,
> > 0x70, 0x71, 0x73, 0x74, 0x76, 0x77, 0x79, 0x7A, 0x7C, 0x7D, 0x7F, 0x80, 0x82, 0x83, 0x85, 0x86,
> > 0x88, 0x89, 0x8B, 0x8C, 0x8E, 0x90, 0x91, 0x93, 0x95, 0x96, 0x98, 0x9A, 0x9B, 0x9D, 0x9F, 0xA0,
> > 0xA2, 0xA4, 0xA5, 0xA7, 0xA9, 0xAB, 0xAC, 0xAE, 0xB0, 0xB2, 0xB4, 0xB6, 0xB7, 0xB9, 0xBB, 0xBD,
> > 0xBF, 0xC1, 0xC3, 0xC4, 0xC6, 0xC8, 0xCA, 0xCC, 0xCE, 0xD0, 0xD2, 0xD4, 0xD6, 0xD8, 0xDA, 0xDC,
> > 0xDE, 0xE0, 0xE2, 0xE4, 0xE6, 0xE8, 0xEB, 0xED, 0xEF, 0xF1, 0xF3, 0xF5, 0xF7, 0xFA, 0xFC, 0xFE,
> > };
> >
> > static void fsl_dcu_drm_init_gamma_tables(struct drm_crtc *crtc, uint32_t size)
> > {
> > unsigned int i;
> > struct drm_color_lut lut[size];
> >
> > for (i = 0; i < size; i++) {
> > lut[i].red = gamma_default_lut[i];
> > lut[i].green = gamma_default_lut[i];
> > lut[i].blue = gamma_default_lut[i];
> > }
> >
> > fsl_crtc_gamma_set(crtc, lut, size);
> > }
> >
> > And call "fsl_dcu_drm_init_gamma_tables" within "fsl_dcu_drm_crtc_create".
> >
> > But it seems not graceful putting a static array within the source code. Or generate that array within "fsl_dcu_drm_init_gamma_tables"?
> >
> > Best Regards,
> > Meng
> >
> > > -Daniel
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
More information about the dri-devel
mailing list