[PATCH 1/6] spi-imx: add CSPI and eCSPI support for i.MX51 MCU
Uwe Kleine-König
u.kleine-koenig at pengutronix.de
Thu Sep 2 13:57:21 EDT 2010
Hello,
On Thu, Sep 02, 2010 at 08:29:09PM +0300, Baruch Siach wrote:
> Hi Lothar,
>
> On Thu, Sep 02, 2010 at 05:11:56PM +0200, Lothar Waßmann wrote:
> > > > - if (cpu_is_mx25() || cpu_is_mx31() || cpu_is_mx35()) {
> > > > + /* i.MX51 has two eCSPI and one CSPI controllers, eCSPI controllers are
> > > > + * not compatible with existing SPI controllers on other i.MX platforms,
> > > > + * while CSPI controller is 100% compatible with the one on the i.MX35.
> > > > + * We set the platform device id to 2 for this CSPI at i.MX51 board init
> > > > + * level to distinguish it from two eCSPI controllers.
> > > > + */
> > > This comment is missing in Sascha's driver. I like it.
> > > BTW, I'd like to make use of platform ids in this driver. This would
> > > make this ugly "on imx51 id2 is a cspi" distinction unnecessary.
> > >
> > > > + if (cpu_is_mx25() || cpu_is_mx31() || cpu_is_mx35() ||
> > > > + (cpu_is_mx51() && (pdev->id == 2))) {
> > I'd prefer a flag in the platform_data that tells the driver to act as
> > an eCSPI driver. This way the information about eCSPI or not would be
> > where it belongs (in the arch specific code).
>
> But this also increases the size of driver code, since the compiler can
> resolve cpu_is_* at compile time, and drop the dead code. Maybe an is_ecspi
> macro will make the above code clearer.
If you ask me the cleanest approach is using platform ids. That is the
devices on mx51 could be called:
imx51-ecspi.0
imx51-ecspi.1
imx51-cspi.0
I don't know what the implications on driver code size is, but I can
imagine that if done carefully the driver doesn't need to be bigger.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
More information about the linux-arm-kernel
mailing list