[PATCH] pinctrl: imx5: start numbering pad from 0

[Shawn Guo]

On Wed, Aug 15, 2012 at 05:25:40PM +0800, Dong Aisheng wrote:
> On Wed, Aug 15, 2012 at 03:51:17PM +0800, Uwe Kleine-König wrote:
> > That is just
> > 
> > 	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 11
> > 
> > vs.
> > 
> > 	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x32c, 0x008, 7, 0x0, 0
> > 
> > isn't it? (Actually I'd not go for cpp as preprocessor, but that's a
> > different story.)
> > 
> Hmm, not sure if dt macro may support this kind of syntax but yes if it supports.
> Grant,
> Do you know if dt macro can support it?
> 
I have the same doubt there.  Copied Stephen who might have a better
insight on this.

> Now I'm a bit intend to admit that we probably could do like that if it supports.
> The benefit i see is that it could save much code lines in driver while having
> no using experience downgrade.
> 
> The left question is that how do we get the pin id from this kind of format data
> (0x32c, 0x008, 7, 0x0, 0), probably one way may be:
> For normal pads and NO_CONFIG pads, we could get it via:
> mux_reg_offset / 4
> for NO_MUX pads but have CONFIG pads, we may get it via:
> mux_reg_offset / 4 + PIN_NO_MUX_ID_BASE + config_reg_offset /4

In case of NO_MUX, mux_reg_offset is 0, so the formula becomes:

	PIN_NO_MUX_ID_BASE + config_reg_offset / 4

The question comes to how PIN_NO_MUX_ID_BASE gets determined?

> That may fix getting pin id issue from dt.
> 
> Another known issue is that via this way, that means the pinctrl subsystem
> can only see the using pads, this is a bit not align with the pinctrl
> subsystem design. No sure if Linus would like to see it.
> 
I do not quite follow on this.  The "enum imx51_pads" will still be
there, so all the pads will still be visible to the pinctrl system.

-- 
Regards,
Shawn