From: Andrew Morton <akpm@linux-foundation.org>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, david-b@pacbell.net,
s.hauer@pengutronix.de
Subject: Re: [PATCH 2/2] SPI: Add SPI driver for most known i.MX SoCs
Date: Tue, 23 Jun 2009 16:11:51 -0700 [thread overview]
Message-ID: <20090623161151.e77a6700.akpm@linux-foundation.org> (raw)
In-Reply-To: <1245308072-14392-3-git-send-email-s.hauer@pengutronix.de>
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?
> 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.
> + 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.
>
> ...
>
> +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?
> +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*.
> + if (!mxc_platform_info) {
> + dev_err(&pdev->dev, "can't get the platform data\n");
> + return -EINVAL;
Can this happen?
> + }
> +
> + master = spi_alloc_master(&pdev->dev, sizeof(struct mxc_spi_data));
> + if (!master)
> + return -ENOMEM;
> +
>
> ...
>
next prev parent reply other threads:[~2009-06-23 23:12 UTC|newest]
Thread overview: 7+ 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 [this message]
2009-06-24 9:09 ` Sascha Hauer
2009-06-23 22:58 ` [PATCH 1/2] remove i.MX SPI driver Andrew Morton
2009-06-24 9:24 ` Sascha Hauer
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=20090623161151.e77a6700.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=s.hauer@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox