On 3 November 2014 18:28, Kevin Hilman <khil...@kernel.org> wrote:
> Mathieu Poirier <mathieu.poir...@linaro.org> writes:
>
>> On 3 November 2014 08:34, Geert Uytterhoeven <geert+rene...@glider.be> wrote:
>>> Hi Rafael, Simon, Magnus,
>>>
>>> This patch series enables DT support for PM domains on Renesas R-Mobile
>>> SoCs.
>>>
>>> Currently it's limited to R-Mobile A1 (r8a7740), but given the similarity of
>>> the SYSC System-Controller on the various SH-Mobile/R-Mobile SoCs, and the
>>> abstraction of PM domains in DT, it should be sufficiently generic to handle
>>> other SoCs in the future (e.g. SH-Mobile AP4 (sh7372), SH-Mobile AG5
>>> (sh73a0),
>>> R-Mobile APE6 (r8a73a4)).
>>>
>>> Functionality-wise, this behaves the same as the legacy (non-DT) version
>>> (modulo missing DT support in some device drivers).
>>>
>>> Dependencies:
>>> - This is based on Simon Horman's renesas-devel-20141030-v3.18-rc2, and
>>> Rafael J. Wysocki's linux-pm.git#linux-next,
>>> - This depends on "PM / Domains: Change prototype for the ->attach_dev()
>>> callback" from Ulf hanson, which is intended to still enter v3.18-rcX
>>> through the linux-pm tree.
>>> As this is a one-line change, I included this patch as the first patch
>>> of
>>> this series. Perhaps it's even acceptable for Simon to (also) apply
>>> it, so
>>> we don't have to wait for the v3.18-rcX that will include it?
>>>
>>> For your convenience, I've also pushed this to
>>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#rmobile-genpd
>>>
>>> Changes compared to v3 (more detailed changelogs in the individual patches):
>>> - I dropped the patch to add preliminary PM domain latencies, as I want
>>> to do
>>> more measurements for PM domains that are currently never powered off.
>>> Values seem to range between 8.5 and 26 us, depending on the PM domain.
>>> - I dropped all patches related to QoS device latencies, as these need
>>> more
>>> discussion,
>>> - The power-{on,off}-latency properties have been changed from a single
>>> value
>>> to a list,
>>> - Device save/restore state latencies have been dropped, as they're Linux
>>> driver-specific, and thus don't belong in DT,
>>> - Use proper pm_clk_create()/pm_clk_destroy(), and update for attach_dev()
>>> returning an error code again,
>>> - New patch to enable module clocks if !CONFIG_PM_RUNTIME,
>>> - Always keep D4 powered, until the new Coresight code handles runtime
>>> PM,
>>
>> I took the time to really look at the problems you are experiencing
>> with pm runtime in hw_breackpoint.c this weekend. The coresight
>> patchset, when supplemented with PM runtime awareness, will fix that
>> problem *only* when traces are activated. The other obvious condition
>> is that other component using the same power domain are also converted
>> to using runtime PM.
>>
>> That being said, the coresight framework and breakpoint handler code
>> are two different subsystem. Their only commonality is that they make
>> use of the debug registers (and not even the same ones). As such (and
>> in my opinion) the code in hw_breakpoint should be getting its own pm
>> runtime reference without relying on the coresight subsystem. As
>> indicated above, that would only work in some cases.
>>
>> Supplementing hw_breakpoint to interact with the runtime PM may prove
>> trickier than it seems... I'm especially worried about the
>> non-blocking requirement inherent to using "smp_call_function()". I'm
>> stepping forward to look into that problem but before doing so I need
>> to finish runtime PM on coresight.
>
> Matthieu, without looking more deeply myself, I'm not sure this is what
> you need, but have a look at the "IRQ safe" mode of runtime PM. If you
> know your devices runtime PM callbacks are IRQ safe, you can call
> pm_runtime_irq_safe(), and your callbacks will be called with IRQs
> disabled.
Thanks for the follow up - I will have to dig further into the
irq_safe() API along with understanding the exact requirements
stemming from hw_breakpoint.c. I did a few test yesterday and it
turns out the "reset_ctrl_regs()" problem in hw_breakpoint.c is
exactly the same as a corner case popping up on coresight. As such
fixing one readily provides a solution for the other.
>
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
