* Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> [131204 09:59]: > Hi Tony, > > On Wednesday 04 December 2013 09:28:53 Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> [131204 09:12]: > > > The omap3_pmx_core pinmux device in the device tree handles the system > > > controller module (SCM) PADCONFS fonction. Its control registers are > > > split in two distinct areas, with other SCM registers in-between. Those > > > other registers can't thus be requested by other drivers as the memory > > > region gets reserved by the pinmux driver. > > > > > > Split the omap3_pmx_core device tree node in two for the two memory > > > regions. > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > > --- > > > > > > arch/arm/boot/dts/omap3-beagle-xm.dts | 45 ++++++++++++++++++++++++------ > > > arch/arm/boot/dts/omap3-beagle.dts | 28 +++++++++++++++------- > > > arch/arm/boot/dts/omap3-igep0020.dts | 26 ++++++++++---------- > > > arch/arm/boot/dts/omap3-zoom3.dts | 19 ++++++++++----- > > > arch/arm/boot/dts/omap3.dtsi | 13 +++++++++- > > > 5 files changed, 95 insertions(+), 36 deletions(-) > > > > > > While working on the OMAP3 ISP driver I've run into a failure to request a > > > memory region already requested by the pinctrl-single driver. This patch > > > is an attempt to fix the problem. An alternative approach would be to > > > support multiple reg values in the pinctrl-single driver, but that might > > > not be much cleaner. I'm open to suggestions. > > > > Makes sense to me to split it into two, we can save some memory that way > > too. > > > > It should not cause problems with the wake-up interrupts either as we're > > already using a single chained wake-up interrupt between core and wkup > > pins. > > > > Do you have some perl or sed script to look for and convert the core2 > > registers? Or do we just not have that many of them defined yet? > > This patch should cover all the ones we have in mainline. As this is an RFC > I've performed the conversion manually. OK. I wonder if we should add something like this to make it easier to use the padconf values from the TRM: #define OMAP_IOPAD_OFFSET(pa, offset) ((pa) & 0xffff) - (offset)) #define OMAP2_CORE_IOPAD(pa, val) (OMAP_IOPAD_OFFSET((pa), 0x0030) (val)) #define OMAP3_CORE1_IOPAD(pa, val) OMAP2_CORE_IOPAD((pa), (val)) #define OMAP3_CORE2_IOPAD(pa, val) (OMAP_IOPAD_OFFSET((pa), 0x05a0) (val)) #define OMAP4_CORE_IOPAD(pa, val) (OMAP_IOPAD_OFFSET((pa), 0x0040) (val)) #define OMAP4_WKUP_IOPAD(pa, val) (OMAP_IOPAD_OFFSET((pa), 0xe040) (val)) #define OMAP5_CORE_IOPAD(pa, val) (OMAP_IOPAD_OFFSET((pa), 0x0840) (val)) #define OMAP5_WKUP_IOPAD(pa, val) (OMAP_IOPAD_OFFSET((pa), 0xc850) (val)) ... Then we would have entries like: pinctrl-single,pins = < OMAP3_CORE1_IOPAD(0x158, PIN_INPUT_PULLUP | MUX_MODE0) ... >; instead of: pinctrl-single,pins = < 0x128 (PIN_INPUT_PULLUP | MUX_MODE0) ... >; Regards, Tony -- 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
