From 9deef024a12ebae4965c89837f662905ac88944b Mon Sep 17 00:00:00 2001 From: Haikun Wang Date: Wed, 13 May 2015 18:12:15 +0800 Subject: spi: spi-fsl-dspi: Bug fix incorrect CS de-assert SPI chip select signal need to keep asserted between several spi_transfer in the same spi_message usually. But the driver will de-assert CS signal and the assert it between serval spi_transfer in the same spi_message under some condiations. This patch fix the bug. Here is an example: Assume you have two variables like the following, struct spi_transfer a; struct spi_transfer b; if you send a spi_message only includes 'a' first, and then you send a spi_message includes 'a' and 'b' but without resetting 'a'. Driver will de-assert CS and then assert CS between 'a' and 'b'. Signed-off-by: Haikun Wang Signed-off-by: Mark Brown --- drivers/spi/spi-fsl-dspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/spi') diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 5fe54cda309f..8af20aa65abf 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -341,10 +341,10 @@ static int dspi_transfer_one_message(struct spi_master *master, dspi->cur_msg = message; dspi->cur_chip = spi_get_ctldata(spi); dspi->cs = spi->chip_select; + dspi->cs_change = 0; if (dspi->cur_transfer->transfer_list.next == &dspi->cur_msg->transfers) - transfer->cs_change = 1; - dspi->cs_change = transfer->cs_change; + dspi->cs_change = 1; dspi->void_write_data = dspi->cur_chip->void_write_data; dspi->dataflags = 0; -- cgit v1.2.3 From 7a0a1759f7b157f56b8f291f3664db4b65963c8a Mon Sep 17 00:00:00 2001 From: Jane Wan Date: Fri, 1 May 2015 16:37:42 -0700 Subject: spi: fsl-espi: Fix an error that can cause fsl espi task blocked Incorrect condition is used in spin_event_timeout(). When the TX is done, the SPIE_NF bit in ESPI_SPIE register is set to 1 to indicate the Tx FIFO is not full. If the bit is 0, it indicates the Tx FIFO is full. Due to this error, if the Tx FIFO is full at the beginning, but becomes not full after handling the Rx FIFO (the SPIE_NF bit is set), the spin_event_timeout() returns with timeout occurred. It causes the interrupt handler not to send completion notification to the thread that called wait_for_complete() waiting for the notification. Signed-off-by: Jane Wan Signed-off-by: Mark Brown --- drivers/spi/spi-fsl-espi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'drivers/spi') diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c index d0a73a09a9bd..a0dbb51630d9 100644 --- a/drivers/spi/spi-fsl-espi.c +++ b/drivers/spi/spi-fsl-espi.c @@ -544,9 +544,13 @@ void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32 events) /* spin until TX is done */ ret = spin_event_timeout(((events = mpc8xxx_spi_read_reg( - ®_base->event)) & SPIE_NF) == 0, 1000, 0); + ®_base->event)) & SPIE_NF), 1000, 0); if (!ret) { dev_err(mspi->dev, "tired waiting for SPIE_NF\n"); + + /* Clear the SPIE bits */ + mpc8xxx_spi_write_reg(®_base->event, events); + complete(&mspi->done); return; } } -- cgit v1.2.3 From ce2f6ea1cbd41d78224f703af980a6ceeb0eb56a Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Tue, 26 May 2015 11:44:42 +0200 Subject: spi: orion: Fix maximum baud rates for Armada 370/XP The commit df59fa7f4bca "spi: orion: support armada extended baud rates" was too optimistic for the maximum baud rate that the Armada SoCs can support. According to the hardware datasheet the maximum frequency supported by the Armada 370 SoC is tclk/4. But for the Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and for the Armada 375 it is tclk/15. Currently the armada-370-spi compatible is only used by the Armada 370 and the Armada XP device tree. On Armada 370, tclk cannot be higher than 200MHz. In order to be able to handle both SoCs, we can take the minimum of 50MHz and tclk/4. A proper solution is adding a compatible string for each SoC, but it can't be done as a fix for compatibility reason (we can't modify device tree that have been already released) and it will be part of a separate patch. Fixes: df59fa7f4bca (spi: orion: support armada extended baud rates) Reported-by: Kostya Porotchkin Signed-off-by: Gregory CLEMENT Signed-off-by: Mark Brown Cc: --- drivers/spi/spi-orion.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) (limited to 'drivers/spi') diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c index 861664776672..ff97cabdaa81 100644 --- a/drivers/spi/spi-orion.c +++ b/drivers/spi/spi-orion.c @@ -61,6 +61,12 @@ enum orion_spi_type { struct orion_spi_dev { enum orion_spi_type typ; + /* + * min_divisor and max_hz should be exclusive, the only we can + * have both is for managing the armada-370-spi case with old + * device tree + */ + unsigned long max_hz; unsigned int min_divisor; unsigned int max_divisor; u32 prescale_mask; @@ -387,8 +393,9 @@ static const struct orion_spi_dev orion_spi_dev_data = { static const struct orion_spi_dev armada_spi_dev_data = { .typ = ARMADA_SPI, - .min_divisor = 1, + .min_divisor = 4, .max_divisor = 1920, + .max_hz = 50000000, .prescale_mask = ARMADA_SPI_CLK_PRESCALE_MASK, }; @@ -454,7 +461,21 @@ static int orion_spi_probe(struct platform_device *pdev) goto out; tclk_hz = clk_get_rate(spi->clk); - master->max_speed_hz = DIV_ROUND_UP(tclk_hz, devdata->min_divisor); + + /* + * With old device tree, armada-370-spi could be used with + * Armada XP, however for this SoC the maximum frequency is + * 50MHz instead of tclk/4. On Armada 370, tclk cannot be + * higher than 200MHz. So, in order to be able to handle both + * SoCs, we can take the minimum of 50MHz and tclk/4. + */ + if (of_device_is_compatible(pdev->dev.of_node, + "marvell,armada-370-spi")) + master->max_speed_hz = min(devdata->max_hz, + DIV_ROUND_UP(tclk_hz, devdata->min_divisor)); + else + master->max_speed_hz = + DIV_ROUND_UP(tclk_hz, devdata->min_divisor); master->min_speed_hz = DIV_ROUND_UP(tclk_hz, devdata->max_divisor); r = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- cgit v1.2.3