Mainly addressed to Greg but anyone is welcome to join the
discussion...
Several ARM platforms have system controllers. In this I
include all custom terminology such as:
- System Control
- Chip Controller
- Core Module control registers
- Power Reset Control Management Units
- Multimedia Communications Port
- ASIC control of "stuff"
These are register-mapped ranges controlling "various" or
"misc" parts of the system. The registers you find there can
do e.g.:
* Reset or shut down the system
arch/arm/mach-integrator/core.c
arch/arm/mach-bcmring/include/mach/csp/chipcHw_inline.h
* Reset individual ASIC blocks
drivers/mfd/db8500-prcmu.c
arch/arm/mach-bcmring/include/mach/csp/chipcHw_inline.h
* Control some core voltage domains
drivers/mfd/db8500-prcmu.c
* Control system frequency
arch/arm/mach-integrator/cpu.c
drivers/mfd/db8500-prcmu.c
* Select clocking of indvidual ASIC IP blocks:
drivers/mfd/db8500-prcmu.c
arch/arm/mach-bcmring/include/mach/csp/chipcHw_inline.h
* Provide some versioning numbers for the entire system
drivers/misc/atmel-ssc.c
arch/arm/mach-bcmring/include/mach/csp/chipcHw_inline.h
(Integrator, Versatile, RealView, Versatile Express)
* Enable and reset external buses such as PCI
arch/arm/mach-integrator/pci_v3.c
* (De)protect flash memory
arch/arm/mach-integrator/integrator_cp.c
* Provide a communication channel to another control unit
drivers/mfd/mcp-core.c
drivers/mfd/db8500-prcmu.c
* Set some clock divisors for misc units
drivers/mfd/mcp-core.c
(also PL810 as discussed recently)
* LEDs, GPIO etc communication channel
drivers/mfd/asic3.c
* USB transciever control:
arch/arm/mach-omap2/omap_phy_internal.c
* Get OTP (one-time-programmable) bits:
arch/arm/mach-bcmring/include/mach/csp/chipcHw_inline.h
arch/powerpc/platforms/ps3/os-area.c
arch/powerpc/platforms/chrp/nvram.c
* Set up DDR control registers:
arch/arm/mach-bcmring/include/mach/csp/chipcHw_inline.h
* Pin control:
arch/arm/mach-bcmring/include/mach/csp/chipcHw_inline.h
(Some non-ARM examples included for fun.)
As can be seen from the diverse examples there is a fit
to various extent to existing subsystems, and often mfd is
increasingly used as an arbitration point for other
subsystems.
The current way to split this problem is to:
- Push each subfunctionality into a specialized subsystem
PLL and clocks to drivers/clk using the new framework
RealSoonNow for example, pin control we have in place
regulators can handle domain switches...
- Put in place an arbitration hub-like mechanism using MFD
This can be done in two ways:
- Permanently map the register range and let subdrivers
poke directly into the registers they're interested in.
- Map the register range in a hub driver (often MFD) and
write accessor functions for all subfunctionality.
As far as the drivers are small and nice the heterogeneous
character of these device register ranges are not much
of a problem. Some will argue to not fix what ain't broken
and not move these out of arch/arm/* at all.
What we need to discuss is if this is how we go about
taking care of these devices going forward - what shall be
the preferred design pattern?
My current assumption is that we need to get these things
out of arch/arm/* and into proper subsystems, using
drivers/mfd/* as an arbitration point. However I am not
sure that everyone really agrees on this. Right now it's
more a modus operandi and following what someone else
does than a conscious decision to do this.
We have discussed creating drivers/scm/* (system controller
modules) but I'm pretty unsure of what the definition of
such creatures would be, and the border toward MFD
would be pretty blurred.
x86 have conveniently put some of their equivalents under
drivers/platform/x86 but if I understood Arnd correctly
creating drivers/platform/arm would break the intentions
of that directory.
Thoughts, ideas?
Yours,
Linus Walleij
On Tue, Feb 28, 2012 at 06:48:12AM +0100, Linus Walleij wrote:
> Mainly addressed to Greg but anyone is welcome to join the
> discussion...
>
> Several ARM platforms have system controllers. In this I
> include all custom terminology such as:
>
> - System Control
> - Chip Controller
> - Core Module control registers
> - Power Reset Control Management Units
> - Multimedia Communications Port
Why do you include this? If you include this, you should include things
like SSP/SPI ports, I2C and other such buses.
On Tue, Feb 28, 2012 at 9:38 AM, Russell King - ARM Linux
<[email protected]> wrote:
> On Tue, Feb 28, 2012 at 06:48:12AM +0100, Linus Walleij wrote:
>> Mainly addressed to Greg but anyone is welcome to join the
>> discussion...
>>
>> Several ARM platforms have system controllers. In this I
>> include all custom terminology such as:
>>
>> - System Control
>> - Chip Controller
>> - Core Module control registers
>> - Power Reset Control Management Units
>> - Multimedia Communications Port
>
> Why do you include this? ?If you include this, you should include things
> like SSP/SPI ports, I2C and other such buses.
Mainly because it has these specific MCP controller oddity
functions:
mcp_set_telecom_divisor()
mcp_set_audio_divisor()
i.e. it has some "strangeness" of system controller type
(telecom? que?) But it's quite little and no big deal, drop
it off the list.
Thanks,
Linus Walleij
On Wed, Feb 29, 2012 at 10:59:23AM +0100, Linus Walleij wrote:
> On Tue, Feb 28, 2012 at 9:38 AM, Russell King - ARM Linux
> <[email protected]> wrote:
> > On Tue, Feb 28, 2012 at 06:48:12AM +0100, Linus Walleij wrote:
> >> Mainly addressed to Greg but anyone is welcome to join the
> >> discussion...
> >>
> >> Several ARM platforms have system controllers. In this I
> >> include all custom terminology such as:
> >>
> >> - System Control
> >> - Chip Controller
> >> - Core Module control registers
> >> - Power Reset Control Management Units
> >> - Multimedia Communications Port
> >
> > Why do you include this? ?If you include this, you should include things
> > like SSP/SPI ports, I2C and other such buses.
>
> Mainly because it has these specific MCP controller oddity
> functions:
>
> mcp_set_telecom_divisor()
> mcp_set_audio_divisor()
>
> i.e. it has some "strangeness" of system controller type
> (telecom? que?) But it's quite little and no big deal, drop
> it off the list.
MCP = Multimedia Communication Port. It is designed to work with the
UCB1200 and UCB1300 codec devices, which have two parts to them: a
telecom / pots interface and an audio interface.
The host side needs to be programmed with the appropriate sample rate -
it's the host side which controls the sample rate not the codec.
On Tuesday 28 February 2012, Linus Walleij wrote:
>
> * Reset or shut down the system
> * Reset individual ASIC blocks
> * Control some core voltage domains
> * Control system frequency
> * Select clocking of indvidual ASIC IP blocks:
> * Provide some versioning numbers for the entire system
> * Enable and reset external buses such as PCI
> * (De)protect flash memory
> * Provide a communication channel to another control unit
> * Set some clock divisors for misc units
> * LEDs, GPIO etc communication channel
> * USB transciever control:
> * Get OTP (one-time-programmable) bits:
> * Set up DDR control registers:
> * Pin control:
Nice list, thanks for putting that together.
> The current way to split this problem is to:
>
> - Push each subfunctionality into a specialized subsystem
> PLL and clocks to drivers/clk using the new framework
> RealSoonNow for example, pin control we have in place
> regulators can handle domain switches...
>
> - Put in place an arbitration hub-like mechanism using MFD
Right.
> This can be done in two ways:
>
> - Permanently map the register range and let subdrivers
> poke directly into the registers they're interested in.
>
> - Map the register range in a hub driver (often MFD) and
> write accessor functions for all subfunctionality.
Generally, I would always prefer the second of these ways,
because it allows one to keep the necessary locking local to
the implementation of the system controller driver.
> As far as the drivers are small and nice the heterogeneous
> character of these device register ranges are not much
> of a problem. Some will argue to not fix what ain't broken
> and not move these out of arch/arm/* at all.
That argument certainly has its merits, after all the way that
the system controller works is one of the central aspects
of a platform/subarchitecture.
> What we need to discuss is if this is how we go about
> taking care of these devices going forward - what shall be
> the preferred design pattern?
>
> My current assumption is that we need to get these things
> out of arch/arm/* and into proper subsystems, using
> drivers/mfd/* as an arbitration point. However I am not
> sure that everyone really agrees on this. Right now it's
> more a modus operandi and following what someone else
> does than a conscious decision to do this.
>
> We have discussed creating drivers/scm/* (system controller
> modules) but I'm pretty unsure of what the definition of
> such creatures would be, and the border toward MFD
> would be pretty blurred.
Agreed.
> x86 have conveniently put some of their equivalents under
> drivers/platform/x86 but if I understood Arnd correctly
> creating drivers/platform/arm would break the intentions
> of that directory.
The problem I have with using drivers/platform for this is that
it encourages grouping of drivers by their host-side connection
rather than by their functionality. We're moving away from
that model in most other places in the kernel, and we should
try to discourage it for new code. The drivers/platform/x86
directory contains stuff like rfkill, input, backlight, etc
drivers, all of which have (or should have) other places for
them to live in already.
I don't mind having a new location for system controllers
outside of (or below) drivers/mfd, but I would try to avoid
naming it "platform" because I fear that leads people to stuff
all sorts of drivers in there because they happen to be
implemented as 'platform_driver'.
Arnd