Hi Ulf,
On Wed, Apr 26, 2017 at 11:04 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> On 26 April 2017 at 10:06, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>>> However, we currently know about at least two different SoCs that need
>>> this. Perhaps we can extend the below list to justify adding a new
>>> framework/APIs. Something along the lines what you propose in $subject
>>> patchset.
>>>
>>> 1) Nvidia; to solve the USB super-speed host/device problem.
>>> 2) QCOM, which has pointed to several cases where the PM topology is
>>> laid out like devices having two PM domains..
>>> 3?) I don't fully remember - but I think Geert also pointed to some
>>> examples where a device could reside in a clock domain but also in
>>> power domain for a Renesas SoC!?
>>> 4) ?
>>
>> Most Renesas SoCs have module clocks, which we model as a clock domain.
>> Some Renesas SoCs have power domains for CPUs, others have them for
>> devices as well.
>> As we always provide a virtual "always-on" power domain in the power domain
>> controller, all devices can refer to it using "power-domains" properties,
>> and the driver for the power domain controller can just forward the clock
>> domain operations to the clock driver.
>
> Okay, thanks for clarifying this.
>
> Thinking about this as bit more, when I realized that *if* we would
> add a new PM domain framework for explicit control of PM domains, that
> would mean you need to deploy support for that in the drivers.
Correct. And we have to update DT bindings and DTS.
> On the other hand, as you anyway would need to change the drivers, you
> could instead deploy clock support in the drivers, which would avoid
> using the clock domain. In that way, you could still stay with one PM
> domain pointer per device, used to control the power domains instead.
> Right? Or would that have other implications?
That's exactly what we're doing already.
Which means that if you allow multiple entries in power-domains, we
have to change drivers, DT bindings, and DTS again (which we may
decide not to do ;-)
On SH/R-Mobile, we always did it that way, as the user manual had an
explicit "always-on" power domain.
On R-Car Gen2, the power domains contain CPU and L2 and GPU only,
so devices had their power-domains pointing to the clock controller.
On R-Car Gen3, some devices were moved into power domains, so we
generalized this by creating a virtual "always-on" power domain, and
letting all devices point their power-domains properties to the power
domain controller, which forwards clock handling to the clock controller.
For consistency, this was applied to R-Car Gen2 as well.
Cfr. some late relics fixed in e.g. commit 24b2d930a50662c1
('ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound'),
but technically the fix was not needed, as it worked fine without.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
