From: Huang Shijie <b32955@freescale.com> To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: "Arnd Bergmann" <arnd@arndb.de>, s.hauer@pengutronix.de, w.sang@pengutronix.de, thierry.nolf.barco@gmail.com, linux-mtd@lists.infradead.org, "Shawn Guo" <shawn.guo@freescale.com>, shijie8@gmail.com, linux-arm-kernel@lists.infradead.org, "Lothar Waßmann" <LW@KARO-electronics.de> Subject: Re: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28 Date: Mon, 11 Jul 2011 16:30:34 +0800 [thread overview] Message-ID: <4E1AB4AA.7020702@freescale.com> (raw) In-Reply-To: <20110711080003.GE13840@pengutronix.de> Hi Uwe: > 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 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 >
WARNING: multiple messages have this Message-ID (diff)
From: b32955@freescale.com (Huang Shijie) 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 16:30:34 +0800 [thread overview] Message-ID: <4E1AB4AA.7020702@freescale.com> (raw) In-Reply-To: <20110711080003.GE13840@pengutronix.de> Hi Uwe: > 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 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 >
next prev parent reply other threads:[~2011-07-11 8:30 UTC|newest] Thread overview: 52+ 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 ` Huang Shijie 2011-06-30 3:53 ` [PATCH v5 1/3] ARM: mxs: add " Huang Shijie 2011-06-30 3:53 ` Huang Shijie 2011-06-30 13:55 ` Arnd Bergmann 2011-06-30 13:55 ` Arnd Bergmann 2011-06-30 14:58 ` Lothar Waßmann 2011-06-30 14:58 ` Lothar Waßmann 2011-06-30 22:22 ` Arnd Bergmann 2011-06-30 22:22 ` Arnd Bergmann 2011-07-01 5:59 ` Lothar Waßmann 2011-07-01 5:59 ` Lothar Waßmann 2011-07-01 6:03 ` Wolfram Sang 2011-07-01 6:03 ` Wolfram Sang 2011-07-01 7:53 ` Huang Shijie 2011-07-01 7:53 ` Huang Shijie 2011-07-01 8:01 ` Wolfram Sang 2011-07-01 8:01 ` Wolfram Sang 2011-07-01 8:39 ` Huang Shijie 2011-07-01 8:39 ` Huang Shijie 2011-07-01 8:45 ` Huang Shijie 2011-07-01 8:45 ` Huang Shijie 2011-07-01 9:25 ` Arnd Bergmann 2011-07-01 9:25 ` Arnd Bergmann 2011-07-08 7:31 ` Uwe Kleine-König 2011-07-08 7:31 ` Uwe Kleine-König 2011-07-08 7:40 ` Huang Shijie 2011-07-08 7:40 ` Huang Shijie 2011-07-08 9:09 ` Uwe Kleine-König 2011-07-08 9:09 ` Uwe Kleine-König 2011-07-08 9:27 ` Huang Shijie 2011-07-08 9:27 ` Huang Shijie 2011-07-08 10:16 ` Uwe Kleine-König 2011-07-08 10:16 ` Uwe Kleine-König 2011-07-08 10:24 ` Lothar Waßmann 2011-07-08 10:24 ` Lothar Waßmann 2011-07-11 8:00 ` Uwe Kleine-König 2011-07-11 8:00 ` Uwe Kleine-König 2011-07-11 8:30 ` Huang Shijie [this message] 2011-07-11 8:30 ` Huang Shijie 2011-07-11 8:37 ` Lothar Waßmann 2011-07-11 8:37 ` Lothar Waßmann 2011-07-08 9:02 ` Arnd Bergmann 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 3:53 ` Huang Shijie 2011-06-30 7:55 ` Uwe Kleine-König 2011-06-30 7:55 ` Uwe Kleine-König 2011-06-30 8:37 ` Huang Shijie 2011-06-30 8:37 ` Huang Shijie 2011-06-30 3:53 ` [PATCH v5 3/3] ARM: mxs/mx28evk: " Huang Shijie 2011-06-30 3:53 ` 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=4E1AB4AA.7020702@freescale.com \ --to=b32955@freescale.com \ --cc=LW@KARO-electronics.de \ --cc=arnd@arndb.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mtd@lists.infradead.org \ --cc=s.hauer@pengutronix.de \ --cc=shawn.guo@freescale.com \ --cc=shijie8@gmail.com \ --cc=thierry.nolf.barco@gmail.com \ --cc=u.kleine-koenig@pengutronix.de \ --cc=w.sang@pengutronix.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.