Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

On 26/09/13 14:51, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote:
> [...]
>> But if you and Thierry think this version is good, I'll take it.
> 
> That sounds like you want to take it through the fbdev tree. Jingoo is
> listed (along with Richard, but he hasn't been responsive to email for
> years) as maintainer for the backlight subsystem. Furthermore back at

Ah, so they are. I just thought it falls under fbdev, as it's under
drivers/video/ =).

I don't have any particular "want" to take it through fbdev tree. But I
can take it.

> the time when I began working on the PWM subsystem, the backlight sub-
> system was pretty much orphaned, and pwm-backlight was by far the
> biggest user of the PWM subsystem. I adopted the driver at the time
> because it needed to be updated for PWM subsystem changes.
> 
> What's the plan going forward? Given the coupling between the PWM
> subsystem and the pwm-backlight driver it might be useful to keep
> maintaining it as part of the PWM subsystem. On the other hand, there's
> some coupling between the driver and the backlight subsystem too.

And backlight is coupled with fbdev... Which is something I don't like.

> I have a couple of patches queued up for 3.13 that rework parts of the
> driver, so it'd be good to know how you guys want to handle this.

Well. I'm happy if somebody wants to maintain the backlight side. In
fact, I'd be happy if somebody would start restructuring it totally,
it's rather messy. The link with fbdev should be removed, and some
backlight drivers are actually panel drivers. However, perhaps Common
Display Framework is required until it can be fully cleaned.

So... For the time being, I'm fine with merging pwm-backlight via any
tree that works best. I'm presuming here that backlight framework and
fbdev (for the parts that are relevant for backlight) are not really
being changed, so there shouldn't be conflicts.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]