On 23/05/13 22:44, Arnd Bergmann wrote: Thankyou Arnd for extending this discussion. > On Monday 20 May 2013, Srinivas KANDAGATLA wrote: >> On 17/05/13 15:36, Arnd Bergmann wrote: >> >> On the other hand using device trees to describe the HW >> configuration(sysconfs) made more sense and got rid of SOC specific >> callbacks. > > I'm sure it's possible to reduce the duplication without going all > the way to describing every bit in DT. Yes, I agree with you. I think just passing the offset information from DT would enough in cases like Ethernet or USB where the sysconf registers tend to be mostly standard. And the generic higher level function should be able to do the rest. >> I forget to mention a important point here, the protection is at bit >> level for the sysconfs. Some of sysconfs have bits shared across IPs, so >> protecting them while the IP is still using it is what we are trying to >> achieve with sysconf-claim/release apis. >> While it may be overkill, but In past it has found bugs and been helpful >> with a meaning full debug output. > > Can you give an example of something that is shared across multiple IPs? > > Are those always done in the way that you have e.g. the ethernet pinctrl > in the same register as the usb pinctrl, or could you have an ethernet > pinctrl setting mixed together with the usb clock setting for instance? > > If the hardware has been designed in a sensible way rather than just > grown by randomly adding bits in open spaces, I would assume that it's > possible to have high-level interfaces built around ranges of registers > rather than arbitrary subsets of registers. We have decided to go with using higher level functions as you suggested, hopefully based on regmap with some helper functions on top of it. System configuration registers in the past used to very much shared across IPs, However with the new chips they seems be mostly dedicated registers for specific IP configurations. As we have no plans to support very old chips, So I think I can move this out bit level information from device tree and add a higher level functions to be accessed by the drivers. As an example the below sysconf register for a STi7105 chip(Very old SOC) looks like: SYSTEM_CONFIG7 Comms/Ethernet config control register [31:28] RESERVED [27] ENMII: 1: MII mode 0: Reverse MII mode [26:25] PHY_INTF_SELECT: Selects the type of Ethernet mode 00: MII mode (Default) 01: Reserved 1x: Reserved [23] GLOBAL_POWER_DOWN: 1: Activate low power [24] RESERVED 0: Normal mode [22] DAA_CONFIG_CTRL: DAA configuration control [21] RESERVED [20] MAC_SPEED_SEL: 1: Indicates that the MAC is running at 100 Mbps speed 0: Indicates that the MAC is running at 10 Mbps speed [19] RESERVED [18] RMII_MODE: 1: RMII interface activated 0: MII interface activated [17] MIIM_DIO_SELECT: 1: MIIM_DIO from external input, else from GMAC 0: All MII pads in input mode [16] ETHERNET_INTERFACE_ON: 1: Ethernet on (pads enables controlled by MAC) [15:13] RESERVED [12] DAA_SERIAL_MODE: DAA serial interface mode select pin [11] SC1_COND_VCC_ENABLE: Enables control of smart card VCC upon bit in the PDES. [10] SC_DETECT_VPP_POL: 1: Output pin SC_NOT_SETVPP is inverted of PDES_SC_SETVPP 0: Output pin SC_NOT_SETVPP is PDES_SC_SETVPP [9] IRB_DATA_OUT_POL_OD: Selection of polarity of IRB output signal routed as alternate function ... ... Thanks, srini > > Arnd > > -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
