On 08/07/2012 01:16 AM, Stephen Warren wrote:
On 08/05/2012 08:27 PM, Alex Courbot wrote:
On 08/04/2012 11:12 PM, Mark Brown wrote:
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
I missed some of the earlier bits of the th
On 08/05/2012 08:27 PM, Alex Courbot wrote:
> On 08/04/2012 11:12 PM, Mark Brown wrote:
>> On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
>>> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
>>
I missed some of the earlier bits of the thread here but why can't
we do
>>
Hi Anton,
Sorry for the late reply. I was away and back now.
On Mon, Jul 30, 2012 at 4:40 AM, Anton Vorontsov wrote:
> On Mon, Jul 30, 2012 at 10:51:42AM +0900, Alex Courbot wrote:
> [...]
>> On the other hand I have just noticed that the apparently unrelated
>> Adaptive Voltage Scaling driver j
On 08/04/2012 11:12 PM, Mark Brown wrote:
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
I missed some of the earlier bits of the thread here but why can't we do
device based lookups?
That is because the phandles would no
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
> >I missed some of the earlier bits of the thread here but why can't we do
> >device based lookups?
> That is because the phandles would not be properties of the device
> node bu
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
On Thu, Aug 02, 2012 at 10:21:57AM +0200, Thierry Reding wrote:
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
The problem is, how do we turn these phandles into the resource of
interest. The type of the resource can be infe
On Thu, Aug 02, 2012 at 10:21:57AM +0200, Thierry Reding wrote:
> On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> > The problem is, how do we turn these phandles into the resource of
> > interest. The type of the resource can be infered by the name of the
> > property. The hard par
On Thu 02 Aug 2012 05:45:41 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
Old Signed by an unknown key
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot
On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
> On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> >>On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >>>Oh I see. That's a
On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
Oh I see. That's a little confusing. Why not just reference the relevant
resources directly in ea
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >Oh I see. That's a little confusing. Why not just reference the relevant
> >resources directly in each step; something more like:
> >
> > gpio@1 {
> > act
On 07/31/2012 07:45 AM, Stephen Warren wrote:
Oh I see. That's a little confusing. Why not just reference the relevant
resources directly in each step; something more like:
gpio@1 {
action = "enable-gpio";
gpio = <&gpio 1 0>;
On Wed, Aug 01, 2012 at 02:55:31PM +0100, Mark Brown wrote:
> On Wed, Aug 01, 2012 at 03:38:14PM +0200, Thierry Reding wrote:
> > On Wed, Aug 01, 2012 at 02:26:51PM +0100, Mark Brown wrote:
>
> > > This is why __devinit data will only be discarded when this is not
> > > possible.
>
> > That's exa
On Wed, Aug 01, 2012 at 03:38:14PM +0200, Thierry Reding wrote:
> On Wed, Aug 01, 2012 at 02:26:51PM +0100, Mark Brown wrote:
> > This is why __devinit data will only be discarded when this is not
> > possible.
> That's exactly my point. But I seem to have miserably failed to get that
> across. =
On Wed, Aug 01, 2012 at 02:26:51PM +0100, Mark Brown wrote:
> On Wed, Aug 01, 2012 at 09:41:13AM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
>
> > > Sure there is - take a copy of the platform data in probe().
>
> > Yes, but that will only work for
On Wed, Aug 01, 2012 at 09:41:13AM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
> > Sure there is - take a copy of the platform data in probe().
> Yes, but that will only work for built-in drivers. If you unload the
> module and that causes the platfo
On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
> On Tue, Jul 31, 2012 at 04:32:35PM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 03:26:07PM +0100, Mark Brown wrote:
>
> > > This is framework code - it doesn't have much option. Disabling HOTPLUG
> > > is totally reasonable
On Wed, Aug 01, 2012 at 11:50:35AM +0900, Alex Courbot wrote:
> On 07/31/2012 07:19 PM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Tue, Jul 31, 2012 at 06:51:03PM +0900, Alex Courbot wrote:
> >>I would like to do that actually. The issue is that it did not work
> >>go well wi
On 07/31/2012 07:19 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jul 31, 2012 at 06:51:03PM +0900, Alex Courbot wrote:
On 07/30/2012 08:33 PM, Thierry Reding wrote:
+You will need an instance of power_seq_resources to keep track of the resources
+that are already allocated.
On 8/1/2012 9:47 AM, Alex Courbot wrote:
> On 07/31/2012 09:55 PM, Mitch Bradley wrote:
>> On 7/31/2012 8:38 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900,
On 07/31/2012 09:55 PM, Mitch Bradley wrote:
On 7/31/2012 8:38 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen War
On 07/31/2012 09:22 PM, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same structure/array as input and output would
simplify the API; the platfo
On Mon, Jul 30, 2012 at 10:59:39PM +0200, Rafael J. Wysocki wrote:
[...]
> > Well, currently drivers/power/ is indeed just for power supply class
> > subsystem and drivers. But if the trend is to gather power management
> > ("policy") stuff under one directory, i.e.
> >
> > drivers/
> > power/
>
On Tue, Jul 31, 2012 at 09:42:45AM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 31, 2012 at 05:22:30PM +0100, Mark Brown wrote:
> > Hrm? I'm not sure I understand the direct relevance here - we're
> > talking about platform data.
> The platform data was marked __devdata, and you said it could
On Tue, Jul 31, 2012 at 05:22:30PM +0100, Mark Brown wrote:
> On Tue, Jul 31, 2012 at 09:19:54AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
> > > On Tue, Jul 31, 2012 at 04:32:35PM +0200, Thierry Reding wrote:
>
> > > > can gracefully handle it
On 07/31/2012 04:32 AM, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
...
>> If the nodes have a unit address (i.e. end in "@n"), which they will
>> have to if all named "step" and there's more than one of them, then they
>> will need a matching reg property. Equally, the pare
On Tue, Jul 31, 2012 at 09:19:54AM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
> > On Tue, Jul 31, 2012 at 04:32:35PM +0200, Thierry Reding wrote:
> > > can gracefully handle its platform data being discarded.
> > Sure there is - take a copy of t
On Tue, Jul 31, 2012 at 04:39:41PM +0100, Mark Brown wrote:
> On Tue, Jul 31, 2012 at 04:32:35PM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 03:26:07PM +0100, Mark Brown wrote:
>
> > > This is framework code - it doesn't have much option. Disabling HOTPLUG
> > > is totally reasonable
On Tue, Jul 31, 2012 at 04:32:35PM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 03:26:07PM +0100, Mark Brown wrote:
> > This is framework code - it doesn't have much option. Disabling HOTPLUG
> > is totally reasonable on space constrained systems, there's no reason
> > for the code to b
On Tue, Jul 31, 2012 at 03:26:07PM +0100, Mark Brown wrote:
> On Tue, Jul 31, 2012 at 04:22:17PM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 03:13:29PM +0100, Mark Brown wrote:
>
> > > __devinit can be discarded if you disable enough kernel features,
> > > HOTPLUG is the main one IIRC
On Tue, Jul 31, 2012 at 04:22:17PM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 03:13:29PM +0100, Mark Brown wrote:
> > __devinit can be discarded if you disable enough kernel features,
> > HOTPLUG is the main one IIRC, modules might also need to go - drivers
> > really ought to take a c
On Tue, Jul 31, 2012 at 05:37:07PM +0900, Alex Courbot wrote:
> On 07/30/2012 08:00 PM, Simon Glass wrote:
> >For the delay, I think milliseconds is reasonable. I suppose there is
> >no reasonable need for microseconds?
> I don't see any need for microseconds myself - anybody sees use for
> finer
On Tue, Jul 31, 2012 at 03:13:29PM +0100, Mark Brown wrote:
> On Tue, Jul 31, 2012 at 12:56:40PM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>
> > > The thing is that I am not sure what happens to the platform data
> > > once probe() is done. Isn'
On Tue, Jul 31, 2012 at 12:56:40PM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> > The thing is that I am not sure what happens to the platform data
> > once probe() is done. Isn't it customary to mark it with __devinit
> > and have it freed after p
On Tue, Jul 31, 2012 at 06:51:03PM +0900, Alex Courbot wrote:
> 2) On cleanup, it cleans the resources that needs to be freed (i.e.
> those that are not devm-handled).
> 2) can certainly be removed either by enforcing use of devm, or by
> doing reference counting. 1) seems more difficult to avoid
On 7/31/2012 8:38 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
> I wonder if using th
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
> On 7/31/2012 6:56 PM, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> >> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >>> I wonder if using the same structure/array as input and output woul
On 7/31/2012 6:56 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>> I wonder if using the same structure/array as input and output would
>>> simplify the API; the platform data would fill in the fields ment
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >I wonder if using the same structure/array as input and output would
> >simplify the API; the platform data would fill in the fields mentioned
> >above, and power_seq_build() would parse
On Tue, Jul 31, 2012 at 07:11:41PM +0900, Alex Courbot wrote:
> On 07/31/2012 06:13 PM, Thierry Reding wrote:
> >>I don't see any need for microseconds myself - anybody sees use for
> >>finer-grained delays?
> >>
> >>Btw, I noticed I was using mdelay instead of msleep - caught and fixed that.
> >
>
On 07/31/2012 07:45 AM, Stephen Warren wrote:
+- Delay to wait before performing the action,
+- Delay to wait after performing the action.
I don't see a need to have a delay both before and after an action;
except at the start of the sequence, step n's post-delay is at the same
point in the seq
On Tue, Jul 31, 2012 at 06:51:03PM +0900, Alex Courbot wrote:
> On 07/30/2012 08:33 PM, Thierry Reding wrote:
> >>+You will need an instance of power_seq_resources to keep track of the
> >>resources
> >>+that are already allocated. On success, the function returns a devm
> >>allocated
> >>+resolv
On 07/31/2012 07:26 AM, Stephen Warren wrote:
On 07/30/2012 09:44 AM, Rob Herring wrote:
On 07/27/2012 07:05 AM, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise
On 07/31/2012 06:13 PM, Thierry Reding wrote:
I don't see any need for microseconds myself - anybody sees use for
finer-grained delays?
Btw, I noticed I was using mdelay instead of msleep - caught and fixed that.
You might want to take a look at Documentation/timers/timers-howto.txt.
msleep()
On 07/30/2012 08:33 PM, Thierry Reding wrote:
+You will need an instance of power_seq_resources to keep track of the resources
+that are already allocated. On success, the function returns a devm allocated
+resolved sequence that is ready to be passed to power_seq_run(). In case of
+failure, and
On Mon, Jul 30, 2012 at 04:47:06PM +0100, Mark Brown wrote:
> On Mon, Jul 30, 2012 at 10:44:29AM -0500, Rob Herring wrote:
> > On 07/27/2012 07:05 AM, Alexandre Courbot wrote:
>
> > > + power-on-sequence {
> > > + regulator@0 {
> > > + id = "power";
On Tue, Jul 31, 2012 at 05:37:07PM +0900, Alex Courbot wrote:
> Hi Simon,
>
> On 07/30/2012 08:00 PM, Simon Glass wrote:
> >For the delay, I think milliseconds is reasonable. I suppose there is
> >no reasonable need for microseconds?
>
> I don't see any need for microseconds myself - anybody sees
Hi Simon,
On 07/30/2012 08:00 PM, Simon Glass wrote:
For the delay, I think milliseconds is reasonable. I suppose there is
no reasonable need for microseconds?
I don't see any need for microseconds myself - anybody sees use for
finer-grained delays?
Btw, I noticed I was using mdelay instead
On 07/27/2012 06:05 AM, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequences are board-sp
On 07/30/2012 09:44 AM, Rob Herring wrote:
> On 07/27/2012 07:05 AM, Alexandre Courbot wrote:
>> Some device drivers (panel backlights especially) need to follow precise
>> sequences for powering on and off, involving gpios, regulators, PWMs
>> with a precise powering order and delays to respect be
On Monday, July 30, 2012, Anton Vorontsov wrote:
> On Mon, Jul 30, 2012 at 10:51:42AM +0900, Alex Courbot wrote:
> [...]
> > On the other hand I have just noticed that the apparently unrelated
> > Adaptive Voltage Scaling driver just appeared in drivers/power/avs.
> > So if Anton and David are ok w
On Mon, Jul 30, 2012 at 10:44:29AM -0500, Rob Herring wrote:
> On 07/27/2012 07:05 AM, Alexandre Courbot wrote:
> > + power-on-sequence {
> > + regulator@0 {
> > + id = "power";
> > + enable;
> What do this mean? Isn'
On 07/27/2012 07:05 AM, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequences are board-sp
On Fri, Jul 27, 2012 at 09:05:48PM +0900, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequ
Hi,
On Fri, Jul 27, 2012 at 1:05 PM, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequenc
> On Mon, Jul 30, 2012 at 10:51:42AM +0900, Alex Courbot wrote:
> [...]
> > On the other hand I have just noticed that the apparently unrelated
> > Adaptive Voltage Scaling driver just appeared in drivers/power/avs.
> > So if Anton and David are ok with this, maybe I could put the power
> > sequenc
On Mon, Jul 30, 2012 at 10:51:42AM +0900, Alex Courbot wrote:
[...]
> On the other hand I have just noticed that the apparently unrelated
> Adaptive Voltage Scaling driver just appeared in drivers/power/avs.
> So if Anton and David are ok with this, maybe I could put the power
> sequences code in i
On 07/28/2012 03:19 AM, Greg Kroah-Hartman wrote:
On Fri, Jul 27, 2012 at 09:05:48PM +0900, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and del
On Fri, Jul 27, 2012 at 09:05:48PM +0900, Alexandre Courbot wrote:
> +++ b/include/linux/power_seq.h
> @@ -0,0 +1,139 @@
> +/*
> + * power_seq.h
> + *
> + * Simple interpreter for defining power sequences as platform data or device
> + * tree properties. Initially designed for use with backlight dr
On Fri, Jul 27, 2012 at 09:05:48PM +0900, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequ
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between each steps.
These sequences are board-specific, and do not belong to a particular
driver - theref
61 matches
Mail list logo
