On 4 November 2014 14:59, Rafael J. Wysocki wrote:
> On Tuesday, November 04, 2014 10:11:35 AM Ulf Hansson wrote:
>> On 4 November 2014 02:57, Rafael J. Wysocki wrote:
>> > On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
>> >> On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
>> >>
On Tuesday, November 04, 2014 10:11:35 AM Ulf Hansson wrote:
> On 4 November 2014 02:57, Rafael J. Wysocki wrote:
> > On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
> >> On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
> >>
> >> > That makes it pretty horrid from the point of view
On 4 November 2014 02:57, Rafael J. Wysocki wrote:
> On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
>> On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
>>
>> > That makes it pretty horrid from the point of view of having bus
>> > management code, because we now have the management
On wto, 2014-11-04 at 02:57 +0100, Rafael J. Wysocki wrote:
> On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
> > On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
> >
> > > That makes it pretty horrid from the point of view of having bus
> > > management code, because we now have
On wto, 2014-11-04 at 02:57 +0100, Rafael J. Wysocki wrote:
On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
That makes it pretty horrid from the point of view of having bus
management code, because we now have the
On 4 November 2014 02:57, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
That makes it pretty horrid from the point of view of having bus
management code, because we now have the
On Tuesday, November 04, 2014 10:11:35 AM Ulf Hansson wrote:
On 4 November 2014 02:57, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
That makes it pretty horrid from the point of
On 4 November 2014 14:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, November 04, 2014 10:11:35 AM Ulf Hansson wrote:
On 4 November 2014 02:57, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
On Mon, 3 Nov 2014, Russell King
On pon, 2014-11-03 at 15:44 +, Russell King - ARM Linux wrote:
> On Mon, Nov 03, 2014 at 10:41:02AM -0500, Alan Stern wrote:
> > Bear in mind, however, that once the irq_safe flag has been set, the
> > runtime PM core offers no way to turn it off again.
>
> Ah, I thought it did permit it to
On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
> On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
>
> > That makes it pretty horrid from the point of view of having bus
> > management code, because we now have the management of the bus clock
> > split between the bus layer and the
Russell King - ARM Linux writes:
[...]
> Would another possible solution be to remember the irq-safeness in the
> suspend handler, and use that in the resume handler? Resume should
> /always/ undo what the suspend handler previously did wrt clk API stuff.
This seems more reasonable to me.
On Mon, Nov 03, 2014 at 10:41:02AM -0500, Alan Stern wrote:
> Bear in mind, however, that once the irq_safe flag has been set, the
> runtime PM core offers no way to turn it off again.
Ah, I thought it did permit it to change both ways. In that case, we
don't need to validate that it doesn't
On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
> That makes it pretty horrid from the point of view of having bus
> management code, because we now have the management of the bus clock
> split between the bus layer and the device driver.
>
> This is /really/ a problem for runtime PM.
On Mon, Nov 03, 2014 at 09:36:45AM +0100, Krzysztof Kozlowski wrote:
> On sob, 2014-11-01 at 01:01 +, Russell King - ARM Linux wrote:
> > Would another possible solution be to remember the irq-safeness in the
> > suspend handler, and use that in the resume handler? Resume should
> > /always/
On sob, 2014-11-01 at 01:01 +, Russell King - ARM Linux wrote:
> On Sat, Nov 01, 2014 at 12:55:14AM +, Russell King - ARM Linux wrote:
> > On Sat, Nov 01, 2014 at 01:45:47AM +0100, Rafael J. Wysocki wrote:
> > > On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
> > > > @@
On sob, 2014-11-01 at 01:01 +, Russell King - ARM Linux wrote:
On Sat, Nov 01, 2014 at 12:55:14AM +, Russell King - ARM Linux wrote:
On Sat, Nov 01, 2014 at 01:45:47AM +0100, Rafael J. Wysocki wrote:
On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
@@ -198,8
On Mon, Nov 03, 2014 at 09:36:45AM +0100, Krzysztof Kozlowski wrote:
On sob, 2014-11-01 at 01:01 +, Russell King - ARM Linux wrote:
Would another possible solution be to remember the irq-safeness in the
suspend handler, and use that in the resume handler? Resume should
/always/ undo
On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
That makes it pretty horrid from the point of view of having bus
management code, because we now have the management of the bus clock
split between the bus layer and the device driver.
This is /really/ a problem for runtime PM. Runtime PM
On Mon, Nov 03, 2014 at 10:41:02AM -0500, Alan Stern wrote:
Bear in mind, however, that once the irq_safe flag has been set, the
runtime PM core offers no way to turn it off again.
Ah, I thought it did permit it to change both ways. In that case, we
don't need to validate that it doesn't
Russell King - ARM Linux li...@arm.linux.org.uk writes:
[...]
Would another possible solution be to remember the irq-safeness in the
suspend handler, and use that in the resume handler? Resume should
/always/ undo what the suspend handler previously did wrt clk API stuff.
This seems more
On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
That makes it pretty horrid from the point of view of having bus
management code, because we now have the management of the bus clock
split between the bus layer and the device
On pon, 2014-11-03 at 15:44 +, Russell King - ARM Linux wrote:
On Mon, Nov 03, 2014 at 10:41:02AM -0500, Alan Stern wrote:
Bear in mind, however, that once the irq_safe flag has been set, the
runtime PM core offers no way to turn it off again.
Ah, I thought it did permit it to change
On Sat, Nov 01, 2014 at 12:55:14AM +, Russell King - ARM Linux wrote:
> On Sat, Nov 01, 2014 at 01:45:47AM +0100, Rafael J. Wysocki wrote:
> > On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
> > > @@ -198,8 +217,10 @@ static int amba_probe(struct device *dev)
> > >
On Sat, Nov 01, 2014 at 01:45:47AM +0100, Rafael J. Wysocki wrote:
> On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
> > @@ -198,8 +217,10 @@ static int amba_probe(struct device *dev)
> > pm_runtime_enable(dev);
> >
> > ret = pcdrv->probe(pcdev, id);
>
On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
> The AMBA bus driver defines runtime Power Management functions which
> disable and unprepare AMBA bus clock. This is problematic for runtime PM
> because unpreparing a clock might sleep so it is not interrupt safe.
>
> However
On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
The AMBA bus driver defines runtime Power Management functions which
disable and unprepare AMBA bus clock. This is problematic for runtime PM
because unpreparing a clock might sleep so it is not interrupt safe.
However some
On Sat, Nov 01, 2014 at 01:45:47AM +0100, Rafael J. Wysocki wrote:
On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
@@ -198,8 +217,10 @@ static int amba_probe(struct device *dev)
pm_runtime_enable(dev);
ret = pcdrv-probe(pcdev, id);
-
On Sat, Nov 01, 2014 at 12:55:14AM +, Russell King - ARM Linux wrote:
On Sat, Nov 01, 2014 at 01:45:47AM +0100, Rafael J. Wysocki wrote:
On Monday, October 20, 2014 11:04:46 AM Krzysztof Kozlowski wrote:
@@ -198,8 +217,10 @@ static int amba_probe(struct device *dev)
The AMBA bus driver defines runtime Power Management functions which
disable and unprepare AMBA bus clock. This is problematic for runtime PM
because unpreparing a clock might sleep so it is not interrupt safe.
However some drivers may want to implement runtime PM functions in
interrupt-safe way
The AMBA bus driver defines runtime Power Management functions which
disable and unprepare AMBA bus clock. This is problematic for runtime PM
because unpreparing a clock might sleep so it is not interrupt safe.
However some drivers may want to implement runtime PM functions in
interrupt-safe way
30 matches
Mail list logo
