Message-ID: <518B77C1.70107@st.com>
Date:	Thu, 09 May 2013 11:17:37 +0100
From:	Srinivas KANDAGATLA <srinivas.kandagatla@...com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	dong.aisheng@...aro.org, sameo@...ux.intel.com,
	Rob Landley <rob@...dley.net>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Russell King <linux@....linux.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Stuart Menefy <stuart.menefy@...com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Olof Johansson <olof@...om.net>,
	Jason Cooper <jason@...edaemon.net>,
	Stephen Warren <swarren@...dia.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Nicolas Pitre <nico@...aro.org>,
	Will Deacon <will.deacon@....com>,
	Dave Martin <dave.martin@...aro.org>,
	Marc Zyngier <marc.zyngier@....com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org, linux-serial@...r.kernel.org
Subject: Re: [RFC 3/8] mfd:syscon: Introduce claim/read/write/release APIs

Hi Arnd,
Thankyou for extending the discussion.

On 08/05/13 20:48, Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
>> the pinctrl driver calls syconf_claim(np, "st,alt-control) to get a
>> field and then do a read/write on the field.
>>
>> Just in pinctrl driver we use around 50-100 sysconf registers scatters
>> across different groups.
>>
>> Without these new APIs, its very difficult to pass this information to
>> the drivers.
> But are those necessarily things you would configure using DT?
In last comment.
>
> If there are so many registers that are shared between mutliple
> subsystems, maybe using drivers/mfd/syscon for that is taking things
> further than you should, since it is unlike what any of the other
> SoC families need from syscon.
I agree, my initial approach was having a dedicated driver specific to
ST syscon, however syscon seems to do things very much similar to what
we want, so I have integrated those 3 functions in syscon.
Am happy to go back with my first approach of adding ST specific syscon
driver if no one is actually going to benefit with such a change to
syscon driver.

>
> Can you describe how your syscon registers are laid out?
On STiH416 SOC we have 9 SYSCONF(aka System Configuration
Registers)named banks/groups, each bank has its own memory map.
Each sysconf bank has number of 32 bit registers which vary from bank to
bank, like sysconf bank "sbc" has range from SYSTEM_CONFIG0 to
SYSTEM_CONFIG999 where as  sysconf bank "front" has range of
SYSTEM_CONFIG1000 to SYSTEM_CONFIG1999 and so on.

Each register is assigned with a unique SYCONF number, example:
SYSTEM_CONFIG100, SYSTEM_CONFIG101 , .. and so on.
Each sysconf contains bits of the IP configurations wired-up to the
sysconf register bits.

As example:

- Each pinctrl entry for set of 8 pins uses around 8-10 sysconfig
register to control pinconf and pin functions.
- IPs like Ethernet have few bit like Ethernet-Mode selection external
or internal phyclk wired up to bits in sysconf registers,
- Few clocks are controlled by sysconf registers.
- Reset to IPs are wired up to bits of sysconf same registers.
- ARM core soft reset is wired up to the sysconf registers...
And most of the IPs have similar requirements ......

Total layout of the sysconf changes per SOC, and the bit arrangements
aswell, however the core IP(pinctrl, etherenet ...) and logic to drive
those bits remains exactly same.

As the code remains the same, the information about the hardware
configuration and offsets to the registers are passed by device trees
using the node properties.

In general the requirements of the sysconf support to the SOC/driver
support is.
1> It should be able to read/write a sysconf register bits without
having to "if" each SOC in the code. So that code is totally abstracted.
Which is currently achieved by passing the information from the device
trees and the driver just uses the property to get it.
2> The infrastructure should protect the claimed registers from
over-writing by other drivers. We do this by claim-read/write-release
style API.
3> The driver should be able to set a group of sysconf registers bits to
a particular values before initialises the IP. I was thinking of doing
this in a same way as pinctrl state.

Any suggestion is most appreciated?

Thanks,
srini

> Which subsystems beside pinctrl need to directly interact
> with it? Is there any logical structure in it or do you just
> have tons of bits scattered around an MMIO area?
>
> 	Arnd
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists