Hi Wolfram: See my comments. Best Regards, Richard Zhu Freescale Semiconductor Tel: +86-021-28937189 Email:Hong-Xing.Zhu@xxxxxxxxxxxxx -----Original Message----- From: Wolfram Sang [mailto:w.sang@xxxxxxxxxxxxxx] Sent: Friday, 24 September, 2010 14:43 To: Zhu Richard-R65037 Cc: linux-mmc@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Anton Vorontsov Subject: Re: [PATCH 0/4] Adding support for esdhc on mx35/51 Hi Richard, > * About the share between i.MX and PPC eSDHC. > Why configure a few parts be shared between the i.MX eSDHC and PPC > eSDHC? Can they be separated into two independent systems? The rule of thumb is to avoid code-duplication. Assume the PPC driver gets fixed an off-by-one error in the freq-calculation, you surely want to have that fix on imx, too. > It would bring the conveniences to maintain stuff in the future if we > separate them. If you can name these conveniences and they are convincing, we can keep them seperate. At the moment, I don't see them (what doesn't mean they don't exist) [<Zhu Richard-r65037>] As Anton's description different eSDHC IP on the i.MX and the PPC may have the different IC bugs or limitations. As I know that although in the i.MX SOC family, there are a few differences between different SOCs. And the behaviors of SW driver may be impacted by these differences. I'm afraid that the differences of eSDHC IP module between i.MX and PPC maybe bigger and bigger in future. BTW, the block size of the i.MX eSDHC is not forced to 2K size. Up to now, the default 512byes per sector is used in FSL i.MX Linux BSP. > And there is already one set of eSDHC driver for all the i.MX SOCs. I am confused: which set do you mean? [<Zhu Richard-r65037>] The driver used for i.MX eSDHC. The one used by i.MX35 in Linux kernel now, and the coming MX51 and so on. It is better that one driver supports all i.MX SOC's eSDHC modules in future (MX25, MX35, MX51, MX53...). > As we know that i.MX and PPC are the disparate SOC families. Well, if the eSDHC-core itself is the same or very similar, that doesn't really matter IMO. Especially as the of-platform-bus might disappear somewhen in the future, the PPC and imx-drivers could become more similar. > * About the driver name of i.MX eSDHC driver, I think that use the imx > to identify it is better than esdhc. I picked up Anton's suggestion 'sdhci-esdhc-imx.c' so far. Although I am still not sure if 'sdhci-esdhc-pltfm.c' would be more precise. > As I know that the eSDHC name wouldn't be used anymore in next > generation SOCs of i.MX family. > So the name of imx would be much clear and exact. Not really, because all _existing_ implementations are called eSDHC, no? :) If some future incarnations have a different name, but behave the same or very similar, this is usually no problem. Check for example the I2C eeprom driver which is named 'at24' but support basically all EEPROMs and not only Atmel ones. Same goes for a couple of RTC-drivers, etc... [<Zhu Richard-r65037>] :), ok. Kind regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
