Hi Uwe:

On Fri, Jul 08, 2011 at 12:24:22PM +0200, Lothar Wa?mann wrote:

quoted

Uwe Kleine-K?nig writes:

quoted

Hello Huang,

On Fri, Jul 08, 2011 at 05:27:11PM +0800, Huang Shijie wrote:

quoted

quoted

quoted

quoted

quoted

The init function is used only to set up iomux, so the logical replacement is
a pointer to the iomux data, and calling mxs_iomux_setup_multiple_pads
directly from the driver.

Why not put the iomux stuff into the per-machine table and get rid of
the init callback, too?

The mmc (ssp) has pin conflict with gpmi on both mx23evk and mx28evk.
So, it's better to initialize the pin when the driver(GPMI or MMC)
is enabled.

What do you do to prevent userspace from trying to use both devices?

The board can not support the two devices at the same time.
So the user can only use one device with the board.

quoted

I guess you need to configure the hardware somehow to switch between the
two using a jumper? Isn't it possible to detect the hardware setting and
setup the muxer accordingly?

IMHO an per-device init-callback is the wrong approach to solve a pin
conflict.

Do you have any good solution about this?

Put the pinmux corresponding to the one device that currently works in
the pinmux list!?

#define 'that currently works'

For a dedicated system that may not be a problem. But for development
kits and modular systems that allow peripheral modules to be plugged
in there is no 'one device that currently works'.

Yeah, I know that problem. Back when I worked for a company selling
development boards I solved it with clks. Not pretty but more convenient

Could you give me some more details about how did you solve it with clks?

I am confused about it.

thanks

Best Regards
Huang Shijie

than kernel parameters or #ifdefs.
The upside of doing it with clks is that if $customer tries to use both
conflicting devices you get an error message instead of breaking device1
when device2 is opened/probed.
IMHO this last scenario must not happen, so I strongly object to setup
the pinmuxing in an .init callback.

Best regards
Uwe