From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, david-b@pacbell.net
Subject: Re: [PATCH 2/2] SPI: Add SPI driver for most known i.MX SoCs
Date: Wed, 24 Jun 2009 11:09:02 +0200 [thread overview]
Message-ID: <20090624090902.GV31396@pengutronix.de> (raw)
In-Reply-To: <20090623161151.e77a6700.akpm@linux-foundation.org>
On Tue, Jun 23, 2009 at 04:11:51PM -0700, Andrew Morton wrote:
> On Thu, 18 Jun 2009 08:54:32 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > v2: Updated and tested on i.MX35
> >
> > While there already is a SPI driver for i.MX1 in the tree there are
> > good reasons to replace it:
> >
> > - The inkernel driver implements a full blown SPI driver, but
> > the hardware can be fully supported using a bitbang driver.
> > This greatly reduces the size and complexity of the driver.
> > - The inkernel driver only works on i.MX1 SoCs. Unfortunately
> > Freescale decided to randomly mix the register bits for each
> > new SoC, This is quite hard to handle with the current driver
> > since it has register accesses in many places.
> > - The DMA API of the durrent driver is broken for arch-mx1 (as opposed
> > to arch-imx) and nobody cared to fix it yet.
>
> ah, there's some detail. I'l move this into the changelog for
> spi-remove-imx-spi-driver.patch.
>
> Still, it seesm that the current driver does work for some people.
> Removing it in this manner seems a bit risky. Unnecessarily risky?
ATM the old driver does not even compile, but we could keep both drivers
parallel for some time to see if somebody cares to fix it.
>
> > This driver has been tested on i.MX1/i.MX27/i.MX35 with an AT25 type
> > EEPROM and on i.MX27/i.MX31 with a Freescale MC13783 PMIC.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >
> > ...
> >
> > +#define MXC_SPI_BUF_RX(type) \
> > +static void mxc_spi_buf_rx_##type(struct mxc_spi_data *mxc_spi) \
> > +{ \
> > + unsigned int val = readl(mxc_spi->base + MXC_CSPIRXDATA); \
> > + \
> > + if (mxc_spi->rx_buf) { \
> > + *(type *)mxc_spi->rx_buf = val; \
> > + mxc_spi->rx_buf += sizeof(type); \
> > + } \
> > +}
> > +
> > +#define MXC_SPI_BUF_TX(type) \
> > +static void mxc_spi_buf_tx_##type(struct mxc_spi_data *mxc_spi) \
> > +{ \
> > + type val = 0; \
> > + \
> > + if (mxc_spi->tx_buf) { \
> > + val = *(type *)mxc_spi->tx_buf; \
>
> Are these operations endian-safe? Seems not. Should they be? It
> would be pretty simple to do.
Honestly, I don't know if they should be endian-safe. So far i.MX only
works in little endian mode on Linux. I prefer making these functions
being obviously not endian-safe rather than pretending that I really
know what I'm doing.
>
> > + mxc_spi->tx_buf += sizeof(type); \
> > + } \
> > + \
> > + mxc_spi->count -= sizeof(type); \
> > + \
> > + writel(val, mxc_spi->base + MXC_CSPITXDATA); \
> > +}
> > +
> > +MXC_SPI_BUF_RX(u8)
> > +MXC_SPI_BUF_TX(u8)
> > +MXC_SPI_BUF_RX(u16)
> > +MXC_SPI_BUF_TX(u16)
> > +MXC_SPI_BUF_RX(u32)
> > +MXC_SPI_BUF_TX(u32)
> > +
> > +/* First entry is reserved, second entry is valid only if SDHC_SPIEN is set
> > + * (which is currently not the case in this driver)
> > + */
> > +static int mxc_clkdivs[] = {0, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128, 192,
> > + 256, 384, 512, 768, 1024};
>
> Could be made const - it's slightly preferable to have data in
> read-only locations if possible. It means that we'll get a nice oops
> if someone accidentally writes to them and sometimes it means that the
> data doesn't need to be copied out to read/write memory at boot-time.
>
> Perhaps the compiler does this anyway.
Ok, I'll change this.
>
> >
> > ...
> >
> > +static void mx27_trigger(struct mxc_spi_data *mxc_spi)
> > +{
> > + unsigned int reg;
> > +
> > + reg = readl(mxc_spi->base + MXC_CSPICTRL);
> > + reg |= MX27_CSPICTRL_XCH;
> > + writel(reg, mxc_spi->base + MXC_CSPICTRL);
> > +}
>
> This all looks rather SMP/preempt/interrupt-unsafe. Or does the SPI core
> provide the needed locking?
The spi core serialises accesses to the driver. The trigger/config
functions are only called with chip interrupts disabled or from the
interrupt handler. I think it should be safe.
>
> > +static int mx27_config(struct mxc_spi_data *mxc_spi,
> > + struct mxc_spi_config *config)
> > +{
> > + unsigned int reg = MX27_CSPICTRL_ENABLE | MX27_CSPICTRL_MASTER;
> > +
> > + reg |= mxc_spi_clkdiv_1(mxc_spi->spi_clk, config->speed_hz) <<
> > + MX27_CSPICTRL_DR_SHIFT;
> > + reg |= config->bpw - 1;
> > +
> > + if (config->mode & SPI_CPHA)
> > + reg |= MX27_CSPICTRL_PHA;
> > + if (config->mode & SPI_CPOL)
> > + reg |= MX27_CSPICTRL_POL;
> > + if (config->mode & SPI_CS_HIGH)
> > + reg |= MX27_CSPICTRL_SSPOL;
> > + if (config->cs < 0)
> > + reg |= (config->cs + 32) << MX27_CSPICTRL_CS_SHIFT;
> > +
> > + writel(reg, mxc_spi->base + MXC_CSPICTRL);
> > +
> > + return 0;
> > +}
>
> Dittoes everywhere.
>
> > +static int mx27_rx_available(struct mxc_spi_data *mxc_spi)
> > +{
> > + return readl(mxc_spi->base + MXC_CSPIINT) & MX27_INTREG_RR;
> > +}
> > +
> >
> > ...
> >
> > +static int __init mxc_spi_probe(struct platform_device *pdev)
> > +{
> > + struct spi_imx_master *mxc_platform_info;
> > + struct spi_master *master;
> > + struct mxc_spi_data *mxc_spi;
> > + struct resource *res;
> > + int i, ret;
> > +
> > + mxc_platform_info = (struct spi_imx_master *)pdev->dev.platform_data;
>
> Unneeded and undesirable cast of a void*.
Ok,
>
> > + if (!mxc_platform_info) {
> > + dev_err(&pdev->dev, "can't get the platform data\n");
> > + return -EINVAL;
>
> Can this happen?
Yes, it happens when the platform code doesn't provide platform data.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2009-06-24 9:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-18 6:54 Sascha Hauer
2009-06-18 6:54 ` [PATCH 1/2] remove i.MX SPI driver Sascha Hauer
2009-06-18 6:54 ` [PATCH 2/2] SPI: Add SPI driver for most known i.MX SoCs Sascha Hauer
2009-06-23 23:11 ` Andrew Morton
2009-06-24 9:09 ` Sascha Hauer [this message]
2009-06-23 22:58 ` [PATCH 1/2] remove i.MX SPI driver Andrew Morton
2009-06-24 9:24 ` Sascha Hauer
-- strict thread matches above, loose matches on Subject: below --
2009-06-17 10:40 Sascha Hauer
2009-06-17 10:40 ` [PATCH 1/2] remove " Sascha Hauer
[not found] ` <1245235220-23816-2-git-send-email-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-06-17 10:40 ` [PATCH 2/2] SPI: Add SPI driver for most known i.MX SoCs Sascha Hauer
[not found] ` <1245235220-23816-3-git-send-email-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-06-17 18:12 ` Guennadi Liakhovetski
[not found] ` <Pine.LNX.4.64.0906172010400.4218-0199iw4Nj15frtckUFj5Ag@public.gmane.org>
2009-06-18 7:52 ` Julien Boibessot
[not found] ` <4A39F255.2090301-GANU6spQydw@public.gmane.org>
2009-06-18 8:30 ` Guennadi Liakhovetski
[not found] ` <Pine.LNX.4.64.0906181028120.5779-0199iw4Nj15frtckUFj5Ag@public.gmane.org>
2009-06-21 12:59 ` Julien Boibessot
2009-06-21 13:53 ` Guennadi Liakhovetski
2009-07-24 10:07 ` Guennadi Liakhovetski
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=20090624090902.GV31396@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.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 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.