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
--
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
