On 04/01/2014 08:13 PM, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [140401 01:38]:
On 04/01/2014 01:09 AM, Tony Lindgren wrote:
We don't want to make access to these registers available without
proper frameworks as that will lead into misuse by various drivers.
And cleaning up that mess later in is a huge pain.
Currently, only thing that requires access to the register offsets
is basically all the legacy clock data still in the kernel (when can
we get rid of this, I have posted patches for it already?) and also
the clockdomain / powerdomain data. I can work on getting
clockdomain + powerdomain data to DT format if this would be
preferred, then we can remove these data files also. Alternatively I
can just move all these defines to the C files which actually use
them.
With display support getting merged hopefully we can retry
dropping omap3 legacy booting as long as we get the missing
boards working.
I don't know how urgent of an issue the clock and power domains
are for the data compared to clocks and muxes. But if it allows us
to easily add support for new SoC variants, then yes it makes sense.
But in any case the defines should be private to the code claiming
the PRCM register area.
So, basically you are proposing to add a regmap or regmap like API
for the PRCM, which would provide access to a subset of registers
only outside the PRCM driver? Some functions provided by PRCM spawn
to multiple registers (like clocks), and the ranges have holes, and
would require finetuning a register / bit level access map (some
registers may contain functions for several drivers.)
Yeah something like that as that allows implementing the Linux
generic frameworks where the code really should be. And does not
require exporting tons of custom functions.
2. Have the core PRCM driver(s) claim some of the regmap ranges
Some PRCM features can potentially be implemented using existing
Linux generic frameworks where possible for clocks, regulators, reset
drivers etc. That way you can keep the register defines for these
ranges private to the core PRCM driver(s). Ideally with no need
to add _any_ custom exported functions here.
There is separate work ongoing for reset driver, and for VC/VP,
there has been some regulator related work. But yes, mostly this
approach should be fine.
OK cool.
3. Have the other drivers claim some regmap ranges
The register ranges that are clearly owned by some driver should
be claimed by those drivers. Then the defines for those registers
can stay private to that driver. Some drivers that can probably
own some PRCM ranges are clock drivers and voltage related drivers.
Yeah, this sounds reasonable.
Hi all,
Just letting you know, that I created a kind of v2 for this set, however
I am not going to post it publicly before the pre-reqs for this set are
covered, basically the OMAP2 clock DT set. CM/PRM cleanup set is
outdated with this series though (I'll post a note on it separately) and
its contents are merged to this latest re-work.
The latest wip branch is available publicly if someone is interested:
https://github.com/t-kristo/linux-pm/tree/3.14-rc4-cm-prm-driver-wip
I also added Tony's vc fixes set to this branch and removed the direct
prm register accesses added there.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
