On Mon, Oct 12, 2015 at 08:30:41PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Oct 09, 2015 at 12:32:32PM +0530, Sudip Mukherjee wrote:
> > On Thu, Oct 08, 2015 at 09:11:07PM +0100, Mike Rapoport wrote:
> > > Hi Sudip,
> > >
> > > On Thu, Oct 08, 2015 at 11:46:28AM +0530, Sudip Mukherjee wrote:
> > > > On Tue, Oct 06, 2015 at 04:49:13PM +0100, Mike Rapoport wrote:
> > > > > Currently the sii164 DVI controller support is unused anywhere in the rest of
> > > > > the driver, and, anyway it does not belong to framebuffer device driver.
> > > > > These patches remove the sii164 DVI controller support.
> > > > I am not sure if we can remove sii164. Sil164 has two configuration
> > > > method. One is from i2c R/W and the other is hardware gpio setting.
> > > >
> > > > Generally, we use hardware GPIO setting. So we don't need any driver for
> > > > sil164. And that is why you see it is unused here.
> > > >
> > > > But SM750LE will always require swi2c for its dvi chip. And SM750LE is a
> > > > special version of the hardware which only Huawei uses.
> > > >
> > > > And if i remember correctly sii164 code will be used if USE_DVICHIP and
> > > > USE_HW_I2C are not defined.
> > >
> > > The code from ddk750_dvi and ddk750_sii164 is never called from the rest
> > > of the driver, the USE_DVICHIP is defined and used only by ddk750_dvi
> > > and ddk750_sii164 themself, and USE_HW_I2C is used only by
> > > ddk750_sii164.
> >
> > Hmmm, I checked up the old code (v4.2) and the current one in staging.
> > sii164 will be initialized and would have been used by dviInit() and
> > dviInit() was being used by ddk750_initDVIDisp(). But ddk750_initDVIDisp()
> > has been removed by 86b5f4ed3525 ("staging: sm750fb: remove unused
> > ddk750_initDVIDisp function").
> > And the call to ddk750_initDVIDisp() was disabled by #ifdef 0 and that
> > was removed by 1282bade3b8e ("staging: sm750fb: remove dead code").
> >
> > I am not sure what should be done in this situation. Greg, can you
> > please suggest something... I think we can add another config option for
> > SM750LE and reintroduce ddk750_initDVIDisp() (with a better name) and
> > enable building them if CONFIG_SM750LE is enabled.
>
> Ick, why? More config options is never the right answer...
Then maybe the best option will be read the hardware ID from the
registers and based on that decide the execution flow. But the only (and
the main) problem is that I don't have SM750LE hardware, I only have the
SM750 normal hardware and so I will not be able to test the code on
SM750LE.
And besides, before investing more time to develop this code, what is
the future of this driver? Tomi is not that interested to have one more
fbdev driver. In that case, should I continue to develop this code for
moving out of staging or concentrate on having atleast a basic drm
driver to start with?
regards
sudip
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
