From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28
Date: Mon, 11 Jul 2011 10:00:03 +0200 [thread overview]
Message-ID: <20110711080003.GE13840@pengutronix.de> (raw)
In-Reply-To: <19990.56022.592145.982784@ipc1.ka-ro>
On Fri, Jul 08, 2011 at 12:24:22PM +0200, Lothar Wa?mann wrote:
> Uwe Kleine-K?nig writes:
> > Hello Huang,
> >
> > On Fri, Jul 08, 2011 at 05:27:11PM +0800, Huang Shijie wrote:
> > > >>>>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.
> > >
> > > >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
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
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2011-07-11 8:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 3:53 [PATCH v5 0/3] add the GPMI-NFC support for imx23/imx28 Huang Shijie
2011-06-30 3:53 ` [PATCH v5 1/3] ARM: mxs: add " Huang Shijie
2011-06-30 13:55 ` Arnd Bergmann
2011-06-30 14:58 ` Lothar Waßmann
2011-06-30 22:22 ` Arnd Bergmann
2011-07-01 5:59 ` Lothar Waßmann
2011-07-01 6:03 ` Wolfram Sang
2011-07-01 7:53 ` Huang Shijie
2011-07-01 8:01 ` Wolfram Sang
2011-07-01 8:39 ` Huang Shijie
2011-07-01 8:45 ` Huang Shijie
2011-07-01 9:25 ` Arnd Bergmann
2011-07-08 7:31 ` Uwe Kleine-König
2011-07-08 7:40 ` Huang Shijie
2011-07-08 9:09 ` Uwe Kleine-König
2011-07-08 9:27 ` Huang Shijie
2011-07-08 10:16 ` Uwe Kleine-König
2011-07-08 10:24 ` Lothar Waßmann
2011-07-11 8:00 ` Uwe Kleine-König [this message]
2011-07-11 8:30 ` Huang Shijie
2011-07-11 8:37 ` Lothar Waßmann
2011-07-08 9:02 ` Arnd Bergmann
2011-06-30 3:53 ` [PATCH v5 2/3] ARM: mxs/mx23evk: add GPMI-NFC device Huang Shijie
2011-06-30 7:55 ` Uwe Kleine-König
2011-06-30 8:37 ` Huang Shijie
2011-06-30 3:53 ` [PATCH v5 3/3] ARM: mxs/mx28evk: " Huang Shijie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110711080003.GE13840@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).