[PATCH/RFC] ARM: omap3: Split the pinmux core device

[Laurent Pinchart]

Hi Tony,

On Wednesday 04 December 2013 10:24:37 Tony Lindgren wrote:
> * Laurent Pinchart <laurent.pinchart at ideasonboard.com> [131204 09:59]:
> > Hi Tony,
> > 
> > On Wednesday 04 December 2013 09:28:53 Tony Lindgren wrote:
> > > * Laurent Pinchart <laurent.pinchart at ideasonboard.com> [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 at ideasonboard.com>
> > > > ---
> > > > 
> > > >  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)
> 		...
> 	>;

That's a good idea, it would be much more readable. Would you like to submit a 
patch ? Should I rebase my patch on top of that, or the other way around ?

-- 
Regards,

Laurent Pinchart