Thread (25 messages) flat view 25 messages, 7 authors, 2013-01-24

Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support

From: Thierry Reding <hidden>
Date: 2013-01-22 07:17:40
Also in: linux-tegra, lkml

On Mon, Jan 21, 2013 at 05:18:11PM +0900, Alex Courbot wrote:
Hi Thierry,

On Monday 21 January 2013 15:49:28 Thierry Reding wrote:
quoted
Eventually this should all be covered by the CDF, but since that's not
ready yet we want something ad-hoc to get the hardware supported. As
such I would like to see this go into some sort of minimalistic, Tegra-
specific display/panel framework. I'd prefer to keep the pwm-backlight
driver as simple and generic as possible, that is, a driver for a PWM-
controlled backlight.

Another advantage of moving this into a sort of display framework is
that it may help in defining the requirements for a CDF and that moving
the code to the CDF should be easier once it is done.

Last but not least, abstracting away the panel allows other things such
as physical dimensions and display modes to be properly encapsulated. I
think that power-on/off timing requirements for panels also belong to
this set since they are usually specific to a given panel.

Maybe adding these drivers to tegra-drm for now would be a good option.
That way the corresponding glue can be added without a need for inter-
tree dependencies.
IIRC (because that was a while ago already) having a Tegra-only display 
framework is exactly what we wanted to avoid in the first place. This series 
does nothing but leverage the callbacks mechanism that already exists in pwm-
backlight and make it available to DT systems. If we start making a Tegra-
specific solution, then other architectures will have to reinvent the wheel 
again. I really don't think we want to go that way.

These patches only makes slight changes to pwm_bl.c and do not extend its 
capabilities. I agree that a suitable solution will require the CDF, but by 
the meantime, let's go for the practical route instead of repeating the same 
mistakes (i.e. architecture-specific frameworks) again.

There are certainly better ways to do this, but I'm not convinced at all that 
a Tegra-only solution is one of them.
Well, your proposal is a Tegra-only solution as well. Anything we come
up with now will be Tegra-only because it will eventually be integrated
with the CDF.

Trying to come up with something generic would be counter-productive.
CDF *is* the generic solution. All we would be doing is add a competing
framework.

Thierry

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help