Hi,
Johan Hovold <johan@xxxxxxxxxx> writes:
> On Wed, Jun 13, 2018 at 12:39:18PM +0300, Felipe Balbi wrote:
>> Roger Quadros <rogerq@xxxxxx> writes:
>
>> > I'm still trying to get my head around this.
>> >
>> > in probe() we do
>> > {
>> > enable all clocks;
>> > pm_runtime_set_active(dev);
>> > pm_runtime_enable(dev);
>> > pm_runtime_get_sync(dev);
>> > }
>> >
>> > How will runtime suspend work at all?
>> > We're holding a positive RPM count in probe().
>>
>> echo auto > /path/to/dwc3/power/control
>
> That makes no difference, user space cannot modify the always-active
> behaviour given that probe returns with a positive usage count.
>
>> Granted, that get_sync() would've been better as a pm_runtime_forbid()
>
> Yeah, that would allow user space some control, albeit in a way that
> may override a user space configuration (as the platform device would
> already have been registered).
>
> Why are you trying to prevent runtime pm in the first place? Shouldn't
> the device be allowed to suspend when it has no active child by
> default?
I don't use this glue layer, actually. As long as there are no
regressions, you can change it to your heart's content. I still it's
best to start with pm runtime blocked and let userspace decide what and
when should have pm runtime enabled.
--
balbi
Attachment:
signature.asc
Description: PGP signature
