On Fri, Jan 13, 2012 at 10:16:36AM -0800, Stephen Warren wrote:
...

For reference, that message is:

Linusw wrote:

quoted

On Mon, Dec 5, 2011 at 3:43 AM, Dong Aisheng <dongas86 <at> gmail.com> wrote:

quoted

My current plan is to define all (might be frequently) used functoin
and groups for the exist upstreamed board like 53 Loco and etc, is
that ok?

Yes, but do it in respective board file, so if we say, one day
stops to support a certain board we can just delete that board
file and be done with it.

Plus this gives us a nice separation as we move toward
device trees. (I think.)

My interpretation of what Dong wrote there is "I'm only going to define
the functions and groups that are actually in use by upstream boards,
not everything the SoC supports". However, your (Shawn's) references to
the email, it sounds like you're interpreting what Dong wrong as "I'm
going to define some virtual groups that don't exist in HW but represent
common use-cases of the HW".

Then what does the word 'groups' in Dong's sentence means with your
understanding, considering there is no HW level pingroup on imx?

Admittedly, the wording of Linusw's actually seems to agree more with how
you're interpreting what Dong said, but in that case, I don't think his
reply makes sense - the whole purpose of the mux mapping table is to
represent the board-specific configuration. If we're going to circumvent
it, we should completely remove it from the pinctrl subsystem, rather than
having some boards avoid using it by creating virtual pin groups instead.

IMO, it's a compromise.  It still makes sense to have concept of
pingroup in pinctrl subsystem, because platforms like Tegra have
the HW pingroup.

quoted

quoted

quoted

For imx6q example, we have 193 pins as the muxable entities, and for
each of those pin, there are 8 alternative functions.  Let's see what
we will have if we enumerate all the available functions for each pin.

...

quoted

quoted

quoted

We simply do not want to over bloat imx6q pinctrl driver with such
enumeration.

Yes, I see you'd end up with a huge number of function definitions here.

You may be able to avoid this by changing the way you name/number the
functions though.

The example above has a unique function name for every individual signal.
instead, can you name functions based on the controller they connect to?

So, instead of having:

IMX6Q_PAD_SD2_DAT1__USDHC2_DAT1
IMX6Q_PAD_SD2_DAT2__USDHC2_DAT2
IMX6Q_PAD_SD2_DAT3__USDHC2_DAT3
IMX6Q_PAD_SD2_DAT4__USDHC2_DAT4

Can you replace this with a single:

IMX_FUNC_USDHC2

So all 'enum imx6q_pad_*' goes away, and instead, we define macros
IMX_FUNC_* at controller basis, correct?

Yes, something like that. The best set to choose probably differs based
on the SoC and its mux capabilities. But thinking more, if you're going
along this kind of route, I'd prefer to just define the "func0", "func1",
... "func7" functions that represent the raw HW selection instead.

In this case, I do not see any point to define them, since it does not
make too much difference than integer 0, 1, ..., 7.

-- 
Regards,
Shawn