Четверг, 13 марта 2014, 11:04 +02:00 от Tomi Valkeinen <tomi.valkeinen@xxxxxx>:
> On 13/03/14 10:48, Alexander Shiyan wrote:
> > Четверг, 13 марта 2014, 10:23 +02:00 от Tomi Valkeinen <tomi.valkeinen@xxxxxx>:
> >> On 13/03/14 09:31, Alexander Shiyan wrote:
> >>> Provide dummy functions for LCD register()/unregister() if
> >>> CONFIG_LCD_CLASS_DEVICE is not set.
> >>
> >> Hmm, why do you want to do that? If a driver needs the LCD class, it
> >> should depend on or select it.
> >
> > I inspect my recent changes for the imxfb driver.
> > I use the LCD class for power management and contrast, nevertheless,
> > if it lack in the kernel this leads to an error.
>
> So is the CONFIG_LCD_CLASS_DEVICE optional for imxfb? It works fine with
> or without the LCD class support? Is there some reason to run it without
> LCD class support?
Some users of imxfb require contrast control (it is mandatory for SHARP displays,
for example), some users require power control, some require both controls,
some require nothing of described above.
So, this seems as an optional control, which (in theory) may be included in the
configuration or not, same as regulator class.
> > Yes, we can choose the LCD_CLASS_DEVICE symbol for the imxfb driver,
> > but at the same time we must choose BACKLIGHT_LCD_SUPPORT.
> > I do not think it's a good way.
>
> Why not?
>
> > In any case, I would like to revise the patch to use NULL as a result
> > if there is no support LCD_CLASS_DEVICE in the kernel.
>
> Why do you want to run imxfb without LCD_CLASS_DEVICE? Isn't it simpler
> to just depend on it?
Just an exceed dependency.
Making this option as optional allow us to increase compile coverage and
makes configuration more flexible.
>
> > Additionally, I have a plan to convert "menuconfig" entry for
> > BACKLIGHT_LCD_SUPPORT to the "menu".
>
> Hmm. That does make sense, as I don't see BACKLIGHT_LCD_SUPPORT
> affecting anything, except enabling the BL & LCD Kconfig menu.
>
> However, many of the items in BL & LCD menu have, for some reason,
> "default y" or "default m". So if you make BACKLIGHT_LCD_SUPPORT a menu,
> it means all those subitems are always enabled. So there definitely will
> be a side effect to that change.
>
> I guess there's legacy reasons why many of the items are enabled by
> default. It would make sense to me to have BACKLIGHT_LCD_SUPPORT as a
> menu, as you suggest, and having all the subitems disabled by default.
> But again, that would change the current behavior, which may or may not
> cause issues.
I think it should not cause any instability and possible discrepancies will
resolved during the life of these changes in the linux-next.
---
��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
