Re: [PATCH 00/55]: ARM: OMAP2+: PRCM move to drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/01/2014 01:09 AM, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [140331 08:20]:
Hi,

This set is continuation for the work started earlier to cleanup the CM/PRM
and attempt to make it a separate driver. This set depends on these
two sets:

CM/PRM cleanup set:
http://marc.info/?l=linux-omap&m=139395000918201&w=2

OMAP2 clock DT set:
http://comments.gmane.org/gmane.linux.ports.arm.omap/111257

This set is pretty huge but the patches can be applied in stages if need be.
Anyway, it would be good to get some feedback whether the driver folder
locations etc. are good, and whether the effort taken here will be enough
to actually move the driver. Clockdomain / powerdomain code can also be
moved easily under the drivers/power/omap folder (or someplace else if
requested) once this set is in. Also, clockdomain / powerdomain data
should be possible to convert to DT format or some sort of firmware
blob once this is done.

Good to see this happening :)

Patch #55 in this set is pretty massive as it moves all the C files at
the same time, this should probably be split up as multiple patches.

Maybe try to break this series into few smaller sets of patches?

Yes, this was the idea once getting the initial feedback for the approach itself. I will post smaller sets (split from this one) once the CM/PRM cleanup set referenced above gets in.


Then a diffstat with these kind of large patch sets would be nice
in the cover letter to get some kind of idea what's going on :)

Browsing through the set it seems that all the patches in this
series moving register defines "to a public location" are bad news.

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.


To avoid that, you can probably do something like this:

1. Set up the PRCM registers as multiple regmap areas

See for example these commits in linux next how one of the SCM misc
register areas is now available for drivers as tisyscon defined
in the .dts files:

11469e0bb1c5 regulator: add pbias regulator support
cd042fe5c1f6 ARM: dts: add pbias dt node

So basically we now have drivers/regulators/pbias-regulator.c
that claims some of the tisyscon registers and implements a
regulator. Then the MMC driver can just use the standard regulator
related functions.

It seems that you can set up multiple PRCM register ranges in a
similar way as regmap ranges and that way partition the PRCM
register areas to something that's private to individual drivers.

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

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.

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.

-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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux