> 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)
/*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
