Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs

[Pavel Machek <pavel@ucw.cz>]

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

Hi!


> >Agreed.
> >
> >>I believe it would be best to add a custom "mode" attribute
> >>to the led classdev, with "manual" and "on-when-charging"
> >>modes, this would then control bits 0-1 of reg 0x5e1f and
> >>by default these bits should be left as is when the driver
> >>loads.
> >
> >No. This is not first hardware when we have something like this, and
> >we need something generic here.
> >
> >One possibility would be magic "hardware drives this led"
> >trigger. Hmm? (Jacek disliked this idea before, but maybe we can
> >convince him).
> >
> >Generic "is this driven by hardware or not" attribute might be
> >possible, too... but its interaction with triggers/brightness/etc
> >would be confusing.
> 
> In this case the interaction is not that tricky, but it will
> likely be different per led controller, so I do not think that
> we can ever come up with a truely generic solution.
> 
> Basically the charge led has 3 states:
> 
> 1) Off
> 2) On
> 3) On when charging
> 
> And then when on it has 4 patterns:
> 
> 1) Permanently off (so still not really on)
> 2) Permanently on
> 3) Blinking
> 4) Breathing

Ok, so you don't really need to support _both_ off methods.

Still sounds like a normal LED, with special "yoga-charging" and
"yoga-breathing" triggers. (All the normal triggers should still work,
too.)

> These 4 patterns can be selected when on, independent
> of being perma-on or ondemand-on

Yeah, but we don't really want to expose that to userspace.

> >>As for the 0x5e20 settings, I believe another custom
> >>sysfs attribute, called "breathing" would be a good idea to
> >>export the breathing functionality.
> >
> >We have "pattern" trigger that can do this kind of stuff in
> >software. But I'm not sure if this is worth supporting.
> 
> The problem is that any changes made are permanent, they
> survice reboots and the default is Breathing, so we need
> a way to restore that which does not involve removing
> the internal battery of these devices.

Wow. Now that's a broken hardware.

Anyway, in such case I'd propose having rmmod/reboot/poweroff hook
that just sets it to breathing. No need to expose it to userspace.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]