On Wed, Dec 20, 2017 at 11:28:43AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Wed, Dec 20, 2017 at 11:23 AM, Simon Horman wrote:
> > On Mon, Dec 18, 2017 at 12:22:17PM +0100, Geert Uytterhoeven wrote:
> >> On Thu, Dec 14, 2017 at 3:11 PM, Ulf Hansson
Hi Simon,
On Wed, Dec 20, 2017 at 11:23 AM, Simon Horman wrote:
> On Mon, Dec 18, 2017 at 12:22:17PM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 14, 2017 at 3:11 PM, Ulf Hansson wrote:
>> > On 9 November 2017 at 14:27, Geert Uytterhoeven
On Mon, Dec 18, 2017 at 12:22:17PM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 14, 2017 at 3:11 PM, Ulf Hansson wrote:
> > On 9 November 2017 at 14:27, Geert Uytterhoeven
> > wrote:
> >> If an R-Car SYSC slave device is part of the CPG/MSTP or
On Thu, Dec 14, 2017 at 3:11 PM, Ulf Hansson wrote:
> On 9 November 2017 at 14:27, Geert Uytterhoeven
> wrote:
>> If an R-Car SYSC slave device is part of the CPG/MSTP or CPG/MSSR Clock
>> Domain and to be used as a wakeup source, it must be kept
On 9 November 2017 at 14:27, Geert Uytterhoeven wrote:
> If an R-Car SYSC slave device is part of the CPG/MSTP or CPG/MSSR Clock
> Domain and to be used as a wakeup source, it must be kept active during
> system suspend.
>
> Currently this is handled in device-specific
If an R-Car SYSC slave device is part of the CPG/MSTP or CPG/MSSR Clock
Domain and to be used as a wakeup source, it must be kept active during
system suspend.
Currently this is handled in device-specific drivers by explicitly
increasing the use count of the module clock when the device is