public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Courbot <acourbot@nvidia.com>
To: NeilBrown <neilb@suse.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thierry Reding <thierry.reding@avionic-design.de>
Subject: Re: Any news on Runtime Interpreted Power Sequences
Date: Fri, 25 Oct 2013 15:23:45 +0900	[thread overview]
Message-ID: <526A0E71.100@nvidia.com> (raw)
In-Reply-To: <20131025112224.6e5265e6@notabene.brown>

Hi Neil,

On 10/25/2013 09:22 AM, NeilBrown wrote:
>   I'm wondering if there was any news on the Runtime Interpreted Power
> Sequences?
> The most recent news I can find is
>    https://lkml.org/lkml/2013/4/27/73
> where you say they might be ready for 3.11.  Clearly that didn't work
> (predictions being hard, especially about the future).
>
> I'm really keen to see them turning into a reality and I gather others are
> too. So ... can we hope?

A prerequisite of power sequences was to merge the gpiod interface, and 
this is finally happening. It took much longer than I wanted, sorry 
about that.

Logically speaking nothing should now stand in the way of a new version 
of the power sequences. Expected maybe my own skepticism about them.

The first version of the power seqs is mainly the result of my 
misunderstanding of the device tree. Reconsidering it now, if we strip 
the DT support away power seqs would just become a simplified way to 
describe how to power a device up and down. In other words, it would be 
another way to express what can be expressed with C code and would not 
bring any additional flexibility that DT-described power seqs would have 
(and I say this totally convinced now that power sequences in the device 
tree were a bad idea).

The advantage I could see is that using power sequences we could get rid 
of the cumbersome and mistake-prone error checking code which is 
basically the same for most devices. You would just need to describe 
what you want to activate, and in which order, and the power seqs 
framework would catch and report any error.

I'm not sure if this is a sufficient reason to introduce another 
framework into the kernel, but if this is deemed a good reason by more 
experienced people then I'm ok to give it a shot. If you have other 
motivations for this, please also state them so I can get the whole 
picture. Maybe I just need to be a little bit more motivated about this 
idea myself. :)

Thanks,
Alex.


  reply	other threads:[~2013-10-25  6:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25  0:22 Any news on Runtime Interpreted Power Sequences NeilBrown
2013-10-25  6:23 ` Alex Courbot [this message]
2013-10-25  7:33   ` NeilBrown
2013-10-28 10:01     ` Alex Courbot
2013-10-28 11:10       ` NeilBrown
2013-10-28 23:53         ` Mark Brown
2013-10-29  0:10           ` NeilBrown
2013-10-29 16:18             ` Mark Brown
2013-10-31  4:59               ` NeilBrown
2013-10-31  5:23                 ` Alex Courbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=526A0E71.100@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=thierry.reding@avionic-design.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox