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

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:

quoted

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