On Tue, Oct 13, 2015 at 11:27:54AM +0530, Sudip Mukherjee wrote:
> 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?
I think it's not a problem to add more fb drivers, but maybe it should
stay in staging for a while until Tomi comes to his senses :)
thanks,
greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
