[PATCH v8 0/3] Runtime Interpreted Power Sequences

[Alexandre Courbot]

Hi Simon,

On Sat, Apr 27, 2013 at 3:55 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi,
>
> On Thu, Nov 15, 2012 at 10:38 PM, Alexandre Courbot <acourbot at nvidia.com> wrote:
>> Hopefully the final series before the feature gets merged. Anton Vorontsov
>> kindly accepted to take it into his tree, so this series is mostly a call for
>> acks, tests and reviews notices before the merge window for 3.8 opens. If you
>> are interested in seeing this feature, please add your name.
>>
>> This series also adds an entry for the subsystem into MAINTAINERS, setting me as
>> the person in charge.
>>
>> Changes from v7:
>> - fix bug reported by Tony Prisk
>> - add MAINTAINERS entry
>>
>> Alexandre Courbot (3):
>>   Runtime Interpreted Power Sequences
>>   pwm_backlight: use power sequences
>>   Take maintainership of power sequences
>
> Did this actually land? I can't see it in linux-next.

It has not landed yet, and will not land in the form that I proposed
initially. There were some obvious issues with describing the
sequences in the device tree, and I decided to rethink the whole
thing, study the state of the art some more (especially ACPI) and
start again from a blank page.

The v2 idea is almost ready to be shared, but it needs a cleaner way
to manage GPIOs, which itself requires gpiolib to be refactored and
the GENERIC_GPIO option to be removed. These last two items will land
in 3.10, so I hope to have both the gpiod interface *and* the new
power seqs ready and approved for 3.11. Then my $@?*^! panel backlight
will maybe finally switch on (no kidding - that's really what this
whole thing is about).

The new power seqs will fundamentally work in a similar fashion to v1
(a simple bytecode that controls power-related items), but will not be
encoded through the DT. Instead, I'd like to have small power control
objects that can be referenced by the platform data of pseq-enabled
drivers, or fetched and associated to the driver through the
compatible property of the DT. These objects will have, as before,
power resources they need to request, and power methods that the
driver can call as needed.

I hate to give dates, but my wish is to come with a first version of
the code by the time the merge window closes. And yes, I still plan to
use Anton as a trojan horse to get this in. ;)

Thanks,
Alex.