From: vinceh@nvidia•com (Vince Hsu)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 12/12] ARM: tegra: Convert PMC to a driver
Date: Tue, 22 Jul 2014 11:34:33 +0800 [thread overview]
Message-ID: <53CDDBC9.7020601@nvidia.com> (raw)
In-Reply-To: <20140721090208.GJ8843@ulmo>
On 07/21/2014 05:02 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Jul 21, 2014 at 03:09:29PM +0800, Vince Hsu wrote:
>> On 07/17/2014 07:01 PM, Thierry Reding wrote:
>>>> Old Signed by an unknown key
>>> On Thu, Jul 17, 2014 at 12:01:56PM +0300, Peter De Schrijver wrote:
>>>> On Thu, Jul 17, 2014 at 10:53:08AM +0200, Peter De Schrijver wrote:
>>>>> On Wed, Jul 16, 2014 at 08:57:16PM +0200, Thierry Reding wrote:
>>>>>>> Old Signed by an unknown key
>>>>>> On Wed, Jul 16, 2014 at 05:22:03PM +0200, Arnd Bergmann wrote:
>>>>>>> On Wednesday 16 July 2014 17:14:29 Thierry Reding wrote:
>>>>>>>>> Ok, I'll have a look. I think when this becomes a separate driver, it
>>>>>>>>> should also have its own header file, so maybe you can in the meantime
>>>>>>>>> make it a local header file in mach-tegra until we have found a good
>>>>>>>>> place for it.
>>>>>>>> Why do you think it should be a separate header? We already have a
>>>>>>>> couple in include/linux and I'm not sure it's useful to add even more.
>>>>>>>> If anything I would've thought it made sense to move the content of the
>>>>>>>> other headers into tegra-soc.h.
>>>>>>> I very much dislike the idea of having a per-vendor header file that
>>>>>>> everything gets crammed into. We should try to have proper subsystems
>>>>>>> and generic interfaces for these wherever possible.
>>>>>> I completely agree. However spreading the SoC-specific functions across
>>>>>> multiple header files isn't going to help. If we keep all the per-vendor
>>>>>> APIs in one file it makes it easier to see what could still be moved off
>>>>>> into a separate subsystem.
>>>>>>
>>>>>> Now for PMC specifically, we've investigated converting the powergate
>>>>>> API to power domains. I don't think it will be possible to make that
>>>>>> work. The issue is that there's a defined sequence that needs to be
>>>>>> respected to make sure the device is powered up properly. That sequence
>>>>>> involves the primary clock and reset of the device. It's been proposed
>>>>>> to make these clocks available to the PMC driver so that it can control
>>>>>> them, but then we can't make sure that clocks are really off if they
>>>>>> need to be, since we have two drivers accessing them. The only way I see
>>>>> resets do not have reference counts, so they can be controlled by a
>>>>> powerdomain driver without any problems. For clocks, there would only be
>>>>> a problem for the module clocks if the drivers don't use runtime PM. If
>>>>> we move all drivers to runtime PM, the clock control can move into the
>>>>> powerdomain code and runtime PM will ensure domains are not turned off
>>>>> with active modules.
>>>>>
>>>>>> to make that work reliably is by moving complete control of the
>>>>>> powergate into drivers so that they can make sure clocks and resets are
>>>>>> in the correct states.
>>>>>>
>>>>> Which won't work if you have domains which contain several modules.
>>>> We also need to control the memory clients in the domains using
>>>> MC_CLIENT_HOTRESET_CTRL.
>>> Oh, great. More interdependencies...
>> Some domains depend on others. Can we take this into account?
> I'm not aware of any dependencies. Can you point me at the relevant
> section in the TRM?
As we talked offline yesterday, that's in 5.6.6.7 - 5.6.6.9.
Thanks,
Vince
next prev parent reply other threads:[~2014-07-22 3:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 12:15 [PATCH 00/12] Add NVIDIA Tegra FUSE driver Thierry Reding
2014-07-11 12:16 ` [PATCH 01/12] ARM: tegra: Sort includes alphabetically Thierry Reding
2014-07-11 12:16 ` [PATCH 02/12] ARM: tegra: Use a function to get the chip ID Thierry Reding
2014-07-11 12:16 ` [PATCH 03/12] ARM: tegra: export apb dma readl/writel Thierry Reding
2014-07-11 12:16 ` [PATCH 04/12] ARM: tegra: move fuse exports to tegra-soc.h Thierry Reding
2014-07-11 12:16 ` [PATCH 05/12] soc/tegra: Add efuse driver for Tegra Thierry Reding
2014-10-19 3:12 ` Shawn Guo
2014-11-10 15:10 ` Thierry Reding
2014-07-11 12:16 ` [PATCH 06/12] soc/tegra: Add efuse and apbmisc bindings Thierry Reding
2014-07-11 12:16 ` [PATCH 07/12] soc/tegra: fuse: move APB DMA into Tegra20 fuse driver Thierry Reding
2014-07-11 12:16 ` [PATCH 08/12] misc: fuse: fix dummy functions Thierry Reding
2014-07-11 12:16 ` [PATCH 09/12] ARM: tegra: Setup CPU hotplug in a pure initcall Thierry Reding
2014-07-11 12:16 ` [PATCH 10/12] ARM: tegra: Always lock the CPU reset vector Thierry Reding
2014-07-11 12:16 ` [PATCH 11/12] soc/tegra: fuse: Set up in early initcall Thierry Reding
2014-07-11 12:16 ` [PATCH 12/12] ARM: tegra: Convert PMC to a driver Thierry Reding
2014-07-11 13:58 ` Peter De Schrijver
2014-07-14 8:06 ` Thierry Reding
2014-07-16 11:56 ` Arnd Bergmann
2014-07-16 13:22 ` Thierry Reding
2014-07-16 14:12 ` Arnd Bergmann
2014-07-16 15:14 ` Thierry Reding
2014-07-16 15:22 ` Arnd Bergmann
2014-07-16 18:57 ` Thierry Reding
2014-07-16 19:34 ` Olof Johansson
2014-07-17 8:54 ` Arnd Bergmann
2014-07-17 11:06 ` Thierry Reding
2014-07-21 12:06 ` Arnd Bergmann
2014-07-21 13:12 ` Thierry Reding
2014-07-21 13:16 ` Tejun Heo
2014-07-21 13:39 ` Thierry Reding
2014-07-17 8:53 ` Peter De Schrijver
2014-07-17 9:01 ` Peter De Schrijver
2014-07-17 11:01 ` Thierry Reding
2014-07-21 7:09 ` Vince Hsu
2014-07-21 9:02 ` Thierry Reding
2014-07-22 3:34 ` Vince Hsu [this message]
2014-07-13 6:38 ` [PATCH 00/12] Add NVIDIA Tegra FUSE driver Olof Johansson
2014-07-14 6:57 ` Thierry Reding
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=53CDDBC9.7020601@nvidia.com \
--to=vinceh@nvidia$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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