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-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
