On Thu, 21 Jun 2018, Roger Quadros wrote:
> >>> probe()
> >>> pm_runtime_forbid() 1
>
> Can you call pm_runtime_forbid() before pm_runtime_enable()?
> Wouldn't it fail with -EACCES as dev->power.disable_depth > 0?
Look, there has been a lot of confusion in this email thread.
On Thu, Jun 21, 2018 at 11:17:36AM +0300, Roger Quadros wrote:
> On 21/06/18 01:55, Rafael J. Wysocki wrote:
> > On Thu, Jun 21, 2018 at 12:32 AM, Rafael J. Wysocki
> > wrote:
> >> On Wed, Jun 20, 2018 at 5:46 PM, Johan Hovold wrote:
> >>> On Wed, Jun 20, 2018 at 02:54:10PM +0200, Rafael J.
On Thu, Jun 21, 2018 at 12:55:26AM +0200, Rafael J. Wysocki wrote:
> On Thu, Jun 21, 2018 at 12:32 AM, Rafael J. Wysocki wrote:
> > On Wed, Jun 20, 2018 at 5:46 PM, Johan Hovold wrote:
> >> On Wed, Jun 20, 2018 at 02:54:10PM +0200, Rafael J. Wysocki wrote:
> >>> On Wednesday, June 20, 2018
On Thu, Jun 21, 2018 at 12:32:59AM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 20, 2018 at 5:46 PM, Johan Hovold wrote:
> > On Wed, Jun 20, 2018 at 02:54:10PM +0200, Rafael J. Wysocki wrote:
> >> On Wednesday, June 20, 2018 2:23:46 PM CEST Johan Hovold wrote:
> >> > On Wed, Jun 20, 2018 at
On 21/06/18 01:55, Rafael J. Wysocki wrote:
> On Thu, Jun 21, 2018 at 12:32 AM, Rafael J. Wysocki wrote:
>> On Wed, Jun 20, 2018 at 5:46 PM, Johan Hovold wrote:
>>> On Wed, Jun 20, 2018 at 02:54:10PM +0200, Rafael J. Wysocki wrote:
On Wednesday, June 20, 2018 2:23:46 PM CEST Johan Hovold
On Thu, Jun 21, 2018 at 12:32 AM, Rafael J. Wysocki wrote:
> On Wed, Jun 20, 2018 at 5:46 PM, Johan Hovold wrote:
>> On Wed, Jun 20, 2018 at 02:54:10PM +0200, Rafael J. Wysocki wrote:
>>> On Wednesday, June 20, 2018 2:23:46 PM CEST Johan Hovold wrote:
>>> > On Wed, Jun 20, 2018 at 02:16:59AM
On Wed, Jun 20, 2018 at 5:46 PM, Johan Hovold wrote:
> On Wed, Jun 20, 2018 at 02:54:10PM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, June 20, 2018 2:23:46 PM CEST Johan Hovold wrote:
>> > On Wed, Jun 20, 2018 at 02:16:59AM -0700, Tony Lindgren wrote:
>> > > Hi,
>> > >
>> > > Adding Rafael
On Wed, Jun 20, 2018 at 02:54:10PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, June 20, 2018 2:23:46 PM CEST Johan Hovold wrote:
> > On Wed, Jun 20, 2018 at 02:16:59AM -0700, Tony Lindgren wrote:
> > > Hi,
> > >
> > > Adding Rafael and linux-pm to Cc as well.
> > >
> > > * Felipe Balbi
On Wednesday, June 20, 2018 2:23:46 PM CEST Johan Hovold wrote:
> On Wed, Jun 20, 2018 at 02:16:59AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > Adding Rafael and linux-pm to Cc as well.
> >
> > * Felipe Balbi [180619 01:23]:
> > > This is a direct consequence of not paying attention to the
On Wed, Jun 20, 2018 at 02:16:59AM -0700, Tony Lindgren wrote:
> Hi,
>
> Adding Rafael and linux-pm to Cc as well.
>
> * Felipe Balbi [180619 01:23]:
> > This is a direct consequence of not paying attention to the order of
> > things. If driver were to assume that pm_domain->activate() would do
On Wed, Jun 20, 2018 at 1:05 PM, Felipe Balbi wrote:
> "Rafael J. Wysocki" writes:
>
>> On Wed, Jun 20, 2018 at 11:27 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Tony Lindgren writes:
* Felipe Balbi [180619 01:23]:
> This is a direct consequence of not paying attention to the order
"Rafael J. Wysocki" writes:
> On Wed, Jun 20, 2018 at 11:27 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Tony Lindgren writes:
>>> * Felipe Balbi [180619 01:23]:
This is a direct consequence of not paying attention to the order of
things. If driver were to assume that
On Wed, Jun 20, 2018 at 11:27 AM, Felipe Balbi wrote:
>
> Hi,
>
> Tony Lindgren writes:
>> * Felipe Balbi [180619 01:23]:
>>> This is a direct consequence of not paying attention to the order of
>>> things. If driver were to assume that pm_domain->activate() would do the
>>> right thing for the
Hi,
Tony Lindgren writes:
> * Felipe Balbi [180619 01:23]:
>> This is a direct consequence of not paying attention to the order of
>> things. If driver were to assume that pm_domain->activate() would do the
>> right thing for the device -- meaning that probe would run with an
>> active device
Hi,
Adding Rafael and linux-pm to Cc as well.
* Felipe Balbi [180619 01:23]:
> This is a direct consequence of not paying attention to the order of
> things. If driver were to assume that pm_domain->activate() would do the
> right thing for the device -- meaning that probe would run with an
>
* Tero Kristo [180619 12:13]:
>
> TI SoC arm64 PM is done via genpd attached to each domain, which in turn
> passes control messages to the PM firmware when transitions happen. See
> drivers/soc/ti_sci_pm_domains.c for details.
>
> Not quite sure about the discussion following later, but there
On 19/06/18 11:18, Felipe Balbi wrote:
Hi,
Roger Quadros writes:
I suggest merging this fix for 4.18-rc, and then Roger can rework the
driver so that it works also on OMAP.
omap has its own glue layer for several reasons. If you're talking about
Keystone devices, then okay, I understand.
Hi,
Roger Quadros writes:
>>> I suggest merging this fix for 4.18-rc, and then Roger can rework the
>>> driver so that it works also on OMAP.
>>
>> omap has its own glue layer for several reasons. If you're talking about
>> Keystone devices, then okay, I understand. But in
+Tero, Tony and some TI folks
On 18/06/18 15:21, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>> On 18/06/18 12:51, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Johan Hovold writes:
On Mon, Jun 18, 2018 at 12:33:44PM +0300, Felipe Balbi wrote:
> Johan Hovold writes:
Hi,
Roger Quadros writes:
> On 18/06/18 12:51, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Johan Hovold writes:
>>> On Mon, Jun 18, 2018 at 12:33:44PM +0300, Felipe Balbi wrote:
>>>
Johan Hovold writes:
>>>
> I suggest merging this fix for 4.18-rc, and then Roger can rework the
>
On 18/06/18 12:51, Felipe Balbi wrote:
>
> Hi,
>
> Johan Hovold writes:
>> On Mon, Jun 18, 2018 at 12:33:44PM +0300, Felipe Balbi wrote:
>>
>>> Johan Hovold writes:
>>
I suggest merging this fix for 4.18-rc, and then Roger can rework the
driver so that it works also on OMAP.
>>>
>>>
Hi,
Johan Hovold writes:
> On Wed, Jun 13, 2018 at 12:39:18PM +0300, Felipe Balbi wrote:
>> Roger Quadros writes:
>
>> > I'm still trying to get my head around this.
>> >
>> > in probe() we do
>> > {
>> >enable all clocks;
>> > pm_runtime_set_active(dev);
>> >
Hi,
Johan Hovold writes:
> On Mon, Jun 18, 2018 at 12:33:44PM +0300, Felipe Balbi wrote:
>
>> Johan Hovold writes:
>
>> > I suggest merging this fix for 4.18-rc, and then Roger can rework the
>> > driver so that it works also on OMAP.
>>
>> omap has its own glue layer for several reasons. If
On Mon, Jun 18, 2018 at 12:33:44PM +0300, Felipe Balbi wrote:
> Johan Hovold writes:
> > I suggest merging this fix for 4.18-rc, and then Roger can rework the
> > driver so that it works also on OMAP.
>
> omap has its own glue layer for several reasons. If you're talking about
> Keystone
Hi,
Johan Hovold writes:
> On Mon, Jun 18, 2018 at 11:15:41AM +0300, Felipe Balbi wrote:
>
>> 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
On Mon, Jun 18, 2018 at 11:15:41AM +0300, Felipe Balbi wrote:
> 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
On Wed, Jun 13, 2018 at 12:39:18PM +0300, Felipe Balbi wrote:
> Roger Quadros 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);
> >
Roger Quadros writes:
> On 13/06/18 11:05, Felipe Balbi wrote:
>> Roger Quadros writes:
>>
>>> Hi Johan,
>>>
>>> On 31/05/18 17:45, Johan Hovold wrote:
The clocks have already been explicitly disabled and put as part of
remove() so the runtime suspend callback must not be run when
On 13/06/18 11:05, Felipe Balbi wrote:
> Roger Quadros writes:
>
>> Hi Johan,
>>
>> On 31/05/18 17:45, Johan Hovold wrote:
>>> The clocks have already been explicitly disabled and put as part of
>>> remove() so the runtime suspend callback must not be run when balancing
>>> the runtime PM usage
Roger Quadros writes:
> Hi Johan,
>
> On 31/05/18 17:45, Johan Hovold wrote:
>> The clocks have already been explicitly disabled and put as part of
>> remove() so the runtime suspend callback must not be run when balancing
>> the runtime PM usage count before returning.
>>
>> Fixes:
Hi Johan,
On 31/05/18 17:45, Johan Hovold wrote:
> The clocks have already been explicitly disabled and put as part of
> remove() so the runtime suspend callback must not be run when balancing
> the runtime PM usage count before returning.
>
> Fixes: 16adc674d0d6 ("usb: dwc3: add generic OF glue
On Thu, May 31, 2018 at 04:45:52PM +0200, Johan Hovold wrote:
> The clocks have already been explicitly disabled and put as part of
> remove() so the runtime suspend callback must not be run when balancing
> the runtime PM usage count before returning.
>
> Fixes: 16adc674d0d6 ("usb: dwc3: add
The clocks have already been explicitly disabled and put as part of
remove() so the runtime suspend callback must not be run when balancing
the runtime PM usage count before returning.
Fixes: 16adc674d0d6 ("usb: dwc3: add generic OF glue layer")
Signed-off-by: Johan Hovold
---
Changes in v2
-
33 matches
Mail list logo
