On Thu, May 09, 2013 at 05:39:03PM +0100, Grant Likely wrote:
> +1. You can /minimize/ up-down cycles with the kind of optimization
> that is being attempted here, but the driver still *must* deal with
> bringing resources back up if they get requested "later than you would
> otherwise like".
On Thu, May 09, 2013 at 05:39:03PM +0100, Grant Likely wrote:
+1. You can /minimize/ up-down cycles with the kind of optimization
that is being attempted here, but the driver still *must* deal with
bringing resources back up if they get requested later than you would
otherwise like.
Now that
On 16:07 Thu 09 May , Russell King - ARM Linux wrote:
> On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote:
> > On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
> >
> > > > Even if the driver
On 05/09/2013 11:09 AM, Grant Likely wrote:
On Thu, May 9, 2013 at 5:52 PM, Saravana Kannan wrote:
On 05/09/2013 04:50 AM, Grant Likely wrote:
On Thu, May 9, 2013 at 11:07 AM, Ming Lei wrote:
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan
wrote:
The most obvious fallback of using
On Thu, May 9, 2013 at 5:52 PM, Saravana Kannan wrote:
> On 05/09/2013 04:50 AM, Grant Likely wrote:
>>
>> On Thu, May 9, 2013 at 11:07 AM, Ming Lei wrote:
>>>
>>> On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan
>>> wrote:
The most obvious fallback of using late_initcall_sync()
On 05/09/2013 04:50 AM, Grant Likely wrote:
On Thu, May 9, 2013 at 11:07 AM, Ming Lei wrote:
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan wrote:
The most obvious fallback of using late_initcall_sync() also doesn't work
since the deferred probing work initated during late_initcall() is
On Thu, May 9, 2013 at 3:14 PM, Russell King - ARM Linux
wrote:
> On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
>> On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote:
>>
>> > However, if a device that shuts down resources after init has
>> > completed and then cannot turn
On Thu, May 09, 2013 at 04:07:50PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote:
> > That's clearly a "don't do that then" sort of thing; while we don't want
> > to be unhelpful there's no guarantees with this approach.
> That's not a "don't
On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote:
> On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
> > On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
>
> > > Even if the driver copes fine it can still be desirable to avoid the
> > > power down/up
On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
> > Even if the driver copes fine it can still be desirable to avoid the
> > power down/up cycle if it involves some user visible effect - things
> > like
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan wrote:
> Kernel framework (Eg: regulator, clock, etc) might want to do some clean up
> work (Eg: turn off unclaimed resources) after all devices are done probing
> during kernel init. Before deferred probing was introduced, this was
Generally,
On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
> On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote:
>
> > However, if a device that shuts down resources after init has
> > completed and then cannot turn those resources back on when another
> > driver requests them then it
On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote:
> However, if a device that shuts down resources after init has
> completed and then cannot turn those resources back on when another
> driver requests them then it sounds like there is a bigger design
> problem. We're in a hotplug
On Thu, May 9, 2013 at 11:07 AM, Ming Lei wrote:
> On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan
> wrote:
>>
>> The most obvious fallback of using late_initcall_sync() also doesn't work
>> since the deferred probing work initated during late_initcall() is done in
>> a workqueue. So,
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan wrote:
>
> The most obvious fallback of using late_initcall_sync() also doesn't work
> since the deferred probing work initated during late_initcall() is done in
> a workqueue. So, frameworks that want to wait for all devices to finish
> probing
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan skan...@codeaurora.org wrote:
The most obvious fallback of using late_initcall_sync() also doesn't work
since the deferred probing work initated during late_initcall() is done in
a workqueue. So, frameworks that want to wait for all devices to
On Thu, May 9, 2013 at 11:07 AM, Ming Lei tom.leim...@gmail.com wrote:
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan skan...@codeaurora.org
wrote:
The most obvious fallback of using late_initcall_sync() also doesn't work
since the deferred probing work initated during late_initcall() is
On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote:
However, if a device that shuts down resources after init has
completed and then cannot turn those resources back on when another
driver requests them then it sounds like there is a bigger design
problem. We're in a hotplug world
On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote:
However, if a device that shuts down resources after init has
completed and then cannot turn those resources back on when another
driver requests them then it sounds
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan skan...@codeaurora.org wrote:
Kernel framework (Eg: regulator, clock, etc) might want to do some clean up
work (Eg: turn off unclaimed resources) after all devices are done probing
during kernel init. Before deferred probing was introduced, this
On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
Even if the driver copes fine it can still be desirable to avoid the
power down/up cycle if it involves some user visible effect - things
like blinking the
On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote:
On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
Even if the driver copes fine it can still be desirable to avoid the
power down/up cycle if
On Thu, May 09, 2013 at 04:07:50PM +0100, Russell King - ARM Linux wrote:
On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote:
That's clearly a don't do that then sort of thing; while we don't want
to be unhelpful there's no guarantees with this approach.
That's not a don't do that
On Thu, May 9, 2013 at 3:14 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote:
However, if a device that shuts down resources after init has
completed and then
On 05/09/2013 04:50 AM, Grant Likely wrote:
On Thu, May 9, 2013 at 11:07 AM, Ming Lei tom.leim...@gmail.com wrote:
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan skan...@codeaurora.org wrote:
The most obvious fallback of using late_initcall_sync() also doesn't work
since the deferred probing
On Thu, May 9, 2013 at 5:52 PM, Saravana Kannan skan...@codeaurora.org wrote:
On 05/09/2013 04:50 AM, Grant Likely wrote:
On Thu, May 9, 2013 at 11:07 AM, Ming Lei tom.leim...@gmail.com wrote:
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan skan...@codeaurora.org
wrote:
The most obvious
On 05/09/2013 11:09 AM, Grant Likely wrote:
On Thu, May 9, 2013 at 5:52 PM, Saravana Kannan skan...@codeaurora.org wrote:
On 05/09/2013 04:50 AM, Grant Likely wrote:
On Thu, May 9, 2013 at 11:07 AM, Ming Lei tom.leim...@gmail.com wrote:
On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan
On 16:07 Thu 09 May , Russell King - ARM Linux wrote:
On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote:
On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
Even if the driver copes fine it
28 matches
Mail list logo
