On 26 April 2017 at 11:17, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> 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.
No really, but perhaps I was not clear enough.
Currently you deploy only runtime PM support in the driver and don't
do any clk_get() etc. Then you have a PM domain (genpd) attached to
the device and makes use of genpd's device specific callbacks, in
struct gpd_dev_ops ->start|stop(), which allows you to control clocks
for each device. Of course this is perfectly okay.
So then my question is/was; does there exist cases when these devices
(already attached to a PM domain) would needed to be attach to yet
another separate PM domain? From the nicely detailed description
below, I find the answer to be *no*!?
> 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.
Thanks for the detailed summary!
Kind regards
Uffe
--
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
