From mboxrd@z Thu Jan 1 00:00:00 1970 From: u.kleine-koenig@pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=) Date: Fri, 8 Jul 2011 11:09:03 +0200 Subject: [PATCH v5 1/3] ARM: mxs: add GPMI-NFC support for imx23/imx28 In-Reply-To: <4E16B47E.8090909@freescale.com> References: <1309406028-2924-1-git-send-email-b32955@freescale.com> <1309406028-2924-2-git-send-email-b32955@freescale.com> <201106301555.19440.arnd@arndb.de> <20110708073119.GP29624@pengutronix.de> <4E16B47E.8090909@freescale.com> Message-ID: <20110708090903.GQ29624@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello, On Fri, Jul 08, 2011 at 03:40:46PM +0800, Huang Shijie wrote: > ? 2011?07?08? 15:31, Uwe Kleine-K?nig ??: > >Hello, > > > >On Thu, Jun 30, 2011 at 03:55:19PM +0200, Arnd Bergmann wrote: > >>On Thursday 30 June 2011, Huang Shijie wrote: > >>>add GPMI-NFC support for imx23 and imx28. > >>> > >>>Signed-off-by: Huang Shijie > >>>+/** > >>>+ * struct gpmi_nfc_platform_data - GPMI NFC driver platform data. > >>>+ * > >>>+ * This structure communicates platform-specific information to the GPMI NFC > >>>+ * driver that can't be expressed as resources. > >>>+ * > >>>+ * @platform_init: A pointer to a function the driver will call to > >>>+ * initialize the platform (e.g., set up the pin mux). > >>>+ * @platform_exit: A pointer to a function the driver will call to > >>>+ * exit the platform (e.g., free pins). > >>>+ * @min_prop_delay_in_ns: Minimum propagation delay of GPMI signals to and > >>>+ * from the NAND Flash device, in nanoseconds. > >>>+ * @max_prop_delay_in_ns: Maximum propagation delay of GPMI signals to and > >>>+ * from the NAND Flash device, in nanoseconds. > >>>+ * @max_chip_count: The maximum number of chips for which the driver > >>>+ * should configure the hardware. This value most > >>>+ * likely reflects the number of pins that are > >>>+ * connected to a NAND Flash device. If this is > >>>+ * greater than the SoC hardware can support, the > >>>+ * driver will print a message and fail to initialize. > >>>+ * @partitions: An optional pointer to an array of partition > >>>+ * descriptions. > >>>+ * @partition_count: The number of elements in the partitions array. > >>>+ */ > >>>+struct gpmi_nfc_platform_data { > >>>+ /* SoC hardware information. */ > >>>+ int (*platform_init)(void); > >>>+ void (*platform_exit)(void); > >>>+ > >>>+ /* NAND Flash information. */ > >>>+ unsigned int min_prop_delay_in_ns; > >>>+ unsigned int max_prop_delay_in_ns; > >>>+ unsigned int max_chip_count; > >>>+ > >>>+ /* Medium information. */ > >>>+ struct mtd_partition *partitions; > >>>+ unsigned partition_count; > >>>+}; > >>When adding new infrastructure, always keep in mind how you want it to look > >>after the device tree conversion. The partitions and min/max_* are easily covered > >>with that, but the init/exit function pointers are somewhat problematic. > >> > >>Fortunately, you don't really require these functions for this driver. The _exit > >>function is completely unused, so just get rid of it. > >> > >>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? 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. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |