From: Ulf Hansson <ulf.hansson@linaro.org>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>,
Jon Hunter <jonathanh@nvidia.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Kevin Hilman <khilman@kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Sricharan <sricharan@codeaurora.org>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
Date: Tue, 22 Nov 2016 14:05:50 +0100 [thread overview]
Message-ID: <CAPDyKFo4okrLLM+HVKTOn8pDvwO5aRKCYnyznt+Vrokp64yjqQ@mail.gmail.com> (raw)
In-Reply-To: <4bafcd71-edc9-9ddd-d8c4-093e4d9c58db@linaro.org>
On 17 November 2016 at 16:39, Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
> Hi,
>
> On 11/17/2016 04:31 AM, Rajendra Nayak wrote:
>>
>>
>> On 11/16/2016 06:41 PM, Ulf Hansson wrote:
>>> On 2 November 2016 at 09:56, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>>>> Hi Jon,
>>>>
>>>> On 10/31/2016 04:14 PM, Jon Hunter wrote:
>>>>> Hi Rajendra,
>>>>>
>>>>> On 06/10/16 09:43, Rajendra Nayak wrote:
>>>>>>
>>>>>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
>>>>>>> Hi Rajendra,
>>>>>>>
>>>>>>> On 06/10/16 07:04, Rajendra Nayak wrote:
>>>>>>>>
>>>>>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>>>>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>>>>>>>> controllers) is partitioned across 3 PM domains which are:
>>>>>>>>> - XUSBA: Superspeed logic (for USB 3.0)
>>>>>>>>> - XUSBB: Device controller
>>>>>>>>> - XUSBC: Host controller
>>>>>>>>>
>>>>>>>>> These power domains are not nested and can be powered-up and down
>>>>>>>>> independently of one another. In practice different scenarios require
>>>>>>>>> different combinations of the power domains, for example:
>>>>>>>>> - Superspeed host: XUSBA and XUSBC
>>>>>>>>> - Superspeed device: XUSBA and XUSBB
>>>>>>>>>
>>>>>>>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>>>>>>>> domains under the XUSBA, superspeed may not always be used/required and
>>>>>>>>> so this would keep it on unnecessarily.
>>>>>>>>
>>>>>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
>>>>>>>> for a device (which then will *all* be powered on/off together) or does
>>>>>>>> it also provide for more granular control of these powerdomains?
>>>>>>>
>>>>>>> Only to specify multiple power-domains for a device and not the later.
>>>>>>>
>>>>>>>> The above statement seems to suggest you would need more granular control
>>>>>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not
>>>>>>>> needed) but I can't seem to figure out how you achieve it with this series.
>>>>>>>
>>>>>>> It is an interesting point but today we have always kept the superspeed
>>>>>>> partition on if the device is configured for superspeed regardless of
>>>>>>> what is actually connected. I will check to see if the h/w would allow
>>>>>>> us to turn it off if a non-superspeed device is in use but I did not
>>>>>>> think so.
>>>>>>>
>>>>>>> Do you have any interesting use-cases that would make use of this or
>>>>>>> require other such enhancements?
>>>>>>
>>>>>> We do have atleast a few devices which need to control multiple power domains,
>>>>>> I will need to look more to see if any of them can be controlled individually.
>>>>>> The downstream code we have models these (powerdomains) as regulators and
>>>>>> the drivers hence have individual control on each (specifying multiple -supply's
>>>>>> in DT)
>>>>>
>>>>> Were you able to check to see if you need to have individual control for the power-domains?
>>>>
>>>> I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different
>>>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core
>>>> which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic,
>>>> so for things like firmware image loading you ideally need only venus PD to be ON, but during
>>>> an encode/decode operation you would need all 3 to be ON.
>>>
>>> Isn't there a scenario when encoding *or* decoding happens, not always both?
>>>
>>> If so, doesn't that mean you may have venus + venus_core0 powered and
>>> in some other case venus + venus_core1 powered?
>>>
>>>> The downstream driver turns *all* of them together, and does not control them individually.
>>>> For upstream, the way we have it working (the driver is not merged) is by having venus be the parent
>>>> of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as
>>>> the powerdomain for the video decode block in DT.
>>>>
>>>> So in summary, there is still no need to control them individually, but given there is no way to
>>>> specify more than one powerdomain for a given device, we are ending up hooking up some
>>>> parent/child relations in the powerdomain code.
>>>>
>>>
>>> I think a better solution would be to model the video decode block as
>>> three struct devices.
>>>
>>> 1) The main ARM device, attached to the venus PM domain.
>>> 2) The encoder device, having the main device assigned as its parent
>>> and being attached to the venus_core0 PM domain.
>>> 3) The decoder device, having the main device assigned as its parent
>>> and being attached to the venus_core1 PM domain.
>>>
>>> Then there is no need to specific a PM domain hierarchy (which seems
>>> to be the issue here), but instead only the parent/child relationships
>>> between the struct devices.
>>>
>>> Moreover, as you deploy runtime PM for these devices, you can more
>>> easily distinguish which device you need to operate on
>>> (pm_runtime_get|put*()) depending on what particular operations you
>>> want to do (encode, decode etc).
>>
>> Stan, is this something you think is possible to do, given the way the
>> vidc driver is designed? This is mainly for 8996 which has 3 different
>> powerdomains associated with the video decode block.
>
> Even if it is possible it will be difficult for many reasons.
>
> On the other side, current design (firmware) doesn't expect kernel
> driver to have control over venus_core0 and venus_core1 pm domains. The
> firmware manages those two pm domains internally and the only thing
> which we need to do is to prepare those domains (and follow the power up
> sequence) to be in hardware control mode. So I think the best we could
> do is to model those two power domains as genpd subdomains of the parent
> venus pm domain.
Okay, so that was easy then. Why all the fuzz? :-)
Kind regards
Uffe
next prev parent reply other threads:[~2016-11-22 13:05 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 10:28 [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Jon Hunter
2016-09-20 10:28 ` [RFC PATCH 1/3] PM / Domains: Add helper functions for finding and attaching PM domains Jon Hunter
2016-09-20 10:28 ` [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains Jon Hunter
2016-09-20 17:54 ` Jon Hunter
2016-09-21 8:53 ` Geert Uytterhoeven
2016-09-21 10:01 ` Jon Hunter
2016-09-21 14:37 ` Jon Hunter
2016-09-21 14:57 ` Geert Uytterhoeven
2016-09-23 12:57 ` Jon Hunter
2016-09-23 14:27 ` Geert Uytterhoeven
2016-09-30 8:05 ` Jon Hunter
2016-10-07 9:14 ` Kevin Hilman
2016-10-10 11:24 ` Jon Hunter
2016-09-20 10:28 ` [RFC PATCH 3/3] dt-bindings: Add support for devices with multiple PM domains Jon Hunter
2016-10-06 6:04 ` [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Rajendra Nayak
2016-10-06 8:25 ` Jon Hunter
2016-10-06 8:43 ` Rajendra Nayak
2016-10-31 10:44 ` Jon Hunter
2016-11-02 8:56 ` Rajendra Nayak
2016-11-16 13:11 ` Ulf Hansson
2016-11-17 2:31 ` Rajendra Nayak
2016-11-17 15:39 ` Stanimir Varbanov
2016-11-22 13:05 ` Ulf Hansson [this message]
2016-11-23 3:48 ` Rajendra Nayak
2016-10-06 12:22 ` Ulf Hansson
2016-10-10 11:18 ` Jon Hunter
2016-10-10 14:04 ` Ulf Hansson
2016-10-11 9:15 ` Jon Hunter
2016-11-03 14:20 ` Jon Hunter
2016-11-16 10:48 ` Jon Hunter
2016-11-16 12:53 ` Rafael J. Wysocki
2016-11-22 11:12 ` Jon Hunter
2016-11-22 13:31 ` Ulf Hansson
2016-11-22 14:28 ` Jon Hunter
2016-11-22 18:26 ` Kevin Hilman
2016-11-22 18:41 ` Jon Hunter
2016-11-24 2:30 ` Stephen Boyd
2016-11-29 11:33 ` Marek Szyprowski
2016-12-15 11:38 ` Jon Hunter
2016-11-22 21:55 ` Rafael J. Wysocki
2016-11-23 9:29 ` Jon Hunter
2016-11-23 13:15 ` Rafael J. Wysocki
2017-02-28 15:18 ` Jon Hunter
2017-02-28 15:29 ` Geert Uytterhoeven
2017-03-13 9:37 ` Jon Hunter
2017-03-13 11:45 ` Ulf Hansson
2017-03-13 14:09 ` Jon Hunter
2017-03-13 14:19 ` Geert Uytterhoeven
2017-03-13 14:27 ` Jon Hunter
2017-03-13 14:38 ` Geert Uytterhoeven
2017-03-13 14:51 ` Jon Hunter
2017-03-13 14:42 ` Ulf Hansson
2017-03-15 8:57 ` Jon Hunter
2017-03-15 3:47 ` Nayak, Rajendra
2017-03-15 9:03 ` Jon Hunter
2017-03-01 6:19 ` Rajendra Nayak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPDyKFo4okrLLM+HVKTOn8pDvwO5aRKCYnyznt+Vrokp64yjqQ@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=jonathanh@nvidia.com \
--cc=khilman@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rnayak@codeaurora.org \
--cc=sricharan@codeaurora.org \
--cc=stanimir.varbanov@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).