[PATCH 00/55]: ARM: OMAP2+: PRCM move to drivers
t-kristo at ti.com
Sat Apr 12 03:21:32 PDT 2014
On 04/01/2014 08:13 PM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo at ti.com> [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
> 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.
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:
I also added Tony's vc fixes set to this branch and removed the direct
prm register accesses added there.
More information about the linux-arm-kernel