* Grygorii.Strashko@xxxxxxxxxx <grygorii.strashko@xxxxxxxxxx> [150417 10:33]:
> Hi Tony,
> On 04/16/2015 07:29 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@xxxxxxxxxxx> [150319 16:08]:
> >> * Tony Lindgren <tony@xxxxxxxxxxx> [150307 00:08]:
> >>> * grygorii.strashko@xxxxxxxxxx <grygorii.strashko@xxxxxxxxxx> [150306 11:27]:
> >>>> From: Grygorii Strashko <grygorii.strashko@xxxxxxxxxx>
> >>>>
> >>>> Now there are two points related to Runtime PM usage:
> >>>> 1) bank state doesn't need to be checked in places where
> >>>> Rintime PM is used, bacause Runtime PM maintains its
> >>>> own usage counter:
> >>>> if (!BANK_USED(bank))
> >>>> pm_runtime_get_sync(bank->dev);
> >>>> so, it's safe to drop such checks.
> >>>>
> >>>> 2) There is a call of pm_runtime_get_sync() in omap_gpio_irq_type(),
> >>>> but no corresponding put. As result, GPIO devices could be
> >>>> powered on forever if at least one GPIO was used as IRQ.
> >>>> Hence, allow powering off GPIO banks by adding missed
> >>>> pm_runtime_put(bank->dev) at the end of omap_gpio_irq_type().
> >>>
> >>> Nice to see this happening, but I think before merging this we need
> >>> to test to be sure that the pm_runtime calls actually match.. I'm
> >>> not convinced right now.. We may still have uninitialized entry
> >>> points similar to 3d009c8c61f9 ("gpio: omap: Fix bad device
> >>> access with setup_irq()").
> >>
> >> OK so I finally got around testing this along with your bank
> >> removal set. Looks like this patch causes a regression at least
> >> with n900 keyboard LEDs with off-idle. The LED won't come back
> >> on after restore from off-idle. Anyways, now we have something
> >> reproducable :) So I'll try to debug it further at some point,
> >> might be few days before I get to it.
> >
> > Sorry for the delay, finally got around to this one :)
> >
> > Here's what I came up with, only lightly tested so far. Note that
> > we need to keep the PM runtime per bank, not per GPIO. Will repost
> > a proper patch after some more testing.
>
> I've had a opposite idea actually ;) - use Runtime PM on per-gpio basis as
> it maintains all needed counters inside and we can be sure that
> PM runtime callbacks will be called once per bank.
Sorry looks like I missed this email earlier, the mail got buried
in all the threads in my inbox.
Anyways, we still need per bank pm runtime for a while until we
can make it per GPIO.
> Also, I've thought about moving the code from omap_enable_gpio_module()
> into Runtime PM callbacks.
> So, final goal - get rid of BANK_USED & LINE_USED.
>
> Were you able to identify broken calls sequence?
No, but it breaks things for omap3 off idle. And then I noticed all
the duplicate code as discussed in the newer thread.
> Also, Pay attention pls, that omap2_gpio_prepare_for/resume_after_idle()
> will be most probably a NOP now.
Looks like we can't do that change yet, it breaks omap3 off idle.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
