spi: spi-ep93xx: always handle transfer specific settings

PATCH Applied H Hartley Sweeten 4 participants 7 messages Jun 28, 2013 – Jul 1, 2013 SPI

Share & tools

H Hartley Sweeten

author

2013-06-28 18:43 UTC #0 lore raw

PATCH 3/8 spi: spi-ep93xx: always handle transfer specific settings

__spi_async(), which starts every SPI message transfer, initializes the bits_per_word and max speed for every transfer in the message. Since the conditional test in ep93xx_spi_process_transfer() will always succeed just remove it and always call ep93xx_spi_chip_setup() to configure the hardware for each transfer in the message.

Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer() which just initializes the hardware to the "default" based on the SPI device.

Signed-off-by H Hartley Sweeten <[email protected]>

Cc Ryan Mallon <[email protected]>

Cc Mika Westerberg <[email protected]>

Cc Mark Brown <[email protected]>

Cc Grant Likely <[email protected]>

---
 drivers/spi/spi-ep93xx.c | 43 ++++++++++---------------------------------
 1 file changed, 10 insertions(+), 33 deletions(-)

drivers/spi/spi-ep93xx.c +10 ~~-33~~

index 93ae7b6..bcfd35a 100644
@@ -684,38 +684,20 @@ static void ep93xx_spi_process_transfer(struct ep93xx_spi *espi,
 					struct spi_transfer *t)
 {
 	struct ep93xx_spi_chip *chip = spi_get_ctldata(msg->spi);
+	int err;
 
 	msg->state = t;
 
-	/*
-	 * Handle any transfer specific settings if needed. We use
-	 * temporary chip settings here and restore original later when
-	 * the transfer is finished.
-	 */
-	if (t->speed_hz || t->bits_per_word) {
-		struct ep93xx_spi_chip tmp_chip = *chip;
-
-		if (t->speed_hz) {
-			int err;
-
-			err = ep93xx_spi_calc_divisors(espi, &tmp_chip,
-						       t->speed_hz);
-			if (err) {
-				dev_err(&espi->pdev->dev,
-					"failed to adjust speed\n");
-				msg->status = err;
-				return;
-			}
-		}
+	err = ep93xx_spi_calc_divisors(espi, chip, t->speed_hz);
+	if (err) {
+		dev_err(&espi->pdev->dev, "failed to adjust speed\n");
+		msg->status = err;
+		return;
+	}
 
-		if (t->bits_per_word)
-			tmp_chip.dss = bits_per_word_to_dss(t->bits_per_word);
+	chip->dss = bits_per_word_to_dss(t->bits_per_word);
 
-		/*
-		 * Set up temporary new hw settings for this transfer.
-		 */
-		ep93xx_spi_chip_setup(espi, &tmp_chip);
-	}
+	ep93xx_spi_chip_setup(espi, chip);
 
 	espi->rx = 0;
 	espi->tx = 0;

@@ -759,9 +741,6 @@ static void ep93xx_spi_process_transfer(struct ep93xx_spi *espi,
 			ep93xx_spi_cs_control(msg->spi, true);
 		}
 	}
-
-	if (t->speed_hz || t->bits_per_word)
-		ep93xx_spi_chip_setup(espi, chip);
 }
 
 /*

@@ -814,10 +793,8 @@ static void ep93xx_spi_process_message(struct ep93xx_spi *espi,
 	espi->fifo_level = 0;
 
 	/*
-	 * Update SPI controller registers according to spi device and assert
-	 * the chipselect.
+	 * Assert the chipselect.
 	 */
-	ep93xx_spi_chip_setup(espi, spi_get_ctldata(msg->spi));
 	ep93xx_spi_cs_control(msg->spi, true);
 
 	list_for_each_entry(t, &msg->transfers, transfer_list) {

Signature · 1 line

1.8.1.4

Ryan Mallon

2013-06-28 23:17 UTC #1 lore raw

Quoted 18 lines · H Hartley Sweeten

__spi_async(), which starts every SPI message transfer, initializes the bits_per_word and max speed for every transfer in the message. Since the conditional test in ep93xx_spi_process_transfer() will always succeed just remove it and always call ep93xx_spi_chip_setup() to configure the hardware for each transfer in the message.
Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer() which just initializes the hardware to the "default" based on the SPI device.
Signed-off-by H Hartley Sweeten <[email protected]>
Cc Ryan Mallon <[email protected]>
Cc Mika Westerberg <[email protected]>
Cc Mark Brown <[email protected]>
Cc Grant Likely <[email protected]>
---

drivers/spi/spi-ep93xx.c static void ep93xx_spi_process_transfer(struct ep93xx_spi *espi, · line 693

Quoted 3 lines

drivers/spi/spi-ep93xx.c +3 -0

+	err = ep93xx_spi_calc_divisors(espi, chip, t->speed_hz);
+	if (err) {
+		dev_err(&espi->pdev->dev, "failed to adjust speed\n");

Printing out the speed it was trying to set might be useful here?

~Ryan

H Hartley Sweeten

author

2013-06-28 23:42 UTC #2 lore raw

Quoted 19 lines · Ryan Mallon

Quoted 16 lines · H Hartley Sweeten
__spi_async(), which starts every SPI message transfer, initializes the bits_per_word and max speed for every transfer in the message. Since the conditional test in ep93xx_spi_process_transfer() will always succeed just remove it and always call ep93xx_spi_chip_setup() to configure the hardware for each transfer in the message.
Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer() which just initializes the hardware to the "default" based on the SPI device.
Signed-off-by H Hartley Sweeten <[email protected]>
Cc Ryan Mallon <[email protected]>
Cc Mika Westerberg <[email protected]>
Cc Mark Brown <[email protected]>
Cc Grant Likely <[email protected]>
---

Quoted 6 lines

drivers/spi/spi-ep93xx.c static void ep93xx_spi_process_transfer(struct ep93xx_spi *espi, · line 693
Quoted 3 lines
drivers/spi/spi-ep93xx.c +3 -0
+	err = ep93xx_spi_calc_divisors(espi, chip, t->speed_hz);
+	if (err) {
+		dev_err(&espi->pdev->dev, "failed to adjust speed\n");
Printing out the speed it was trying to set might be useful here?

Technically I don't think this can ever happen.

The minimum and maximum possible speeds are determined during the probe.

	espi->max_rate = clk_get_rate(espi->clk) / 2;
	espi->min_rate = clk_get_rate(espi->clk) / (254 * 256);

Each transfer is validated to make sure the speed is greater than the minimum.

		if (t->speed_hz < espi->min_rate)
			return -EINVAL;

Then the rate is clamped to the min/max rates.

	rate = clamp(rate, espi->min_rate, espi->max_rate);

The calculations for the div_csr and div_cpsr values needed to produce the desired rate should always succeed.

Patch 7/8 actually replaces that dev_err() message with a more generic one. In reality, even the new message, and the error checking, could probably be removed.

Regards,
Hartley

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

Mika Westerberg

Acked-by on v1 3/8

2013-06-30 16:26 UTC #3 lore raw

In reply to H Hartley Sweeten

Quoted 6 lines · H Hartley Sweeten

__spi_async(), which starts every SPI message transfer, initializes the bits_per_word and max speed for every transfer in the message. Since the conditional test in ep93xx_spi_process_transfer() will always succeed just remove it and always call ep93xx_spi_chip_setup() to configure the hardware for each transfer in the message.

Quoted 7 lines

Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer() which just initializes the hardware to the "default" based on the SPI device.
Signed-off-by H Hartley Sweeten <[email protected]>
Cc Ryan Mallon <[email protected]>
Cc Mika Westerberg <[email protected]>

Acked-by Mika Westerberg <[email protected]>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

Mark Brown

maintainer Applied

2013-07-01 10:27 UTC #4 lore raw

In reply to H Hartley Sweeten

Quoted 5 lines · H Hartley Sweeten

__spi_async(), which starts every SPI message transfer, initializes the bits_per_word and max speed for every transfer in the message. Since the conditional test in ep93xx_spi_process_transfer() will always succeed just remove it and always call ep93xx_spi_chip_setup() to configure the hardware for each transfer in the message.

Applied, thanks.

H Hartley Sweeten

author

2013-07-01 18:15 UTC #5 lore raw

Quoted 8 lines · Mark Brown

Quoted 5 lines · H Hartley Sweeten
__spi_async(), which starts every SPI message transfer, initializes the bits_per_word and max speed for every transfer in the message. Since the conditional test in ep93xx_spi_process_transfer() will always succeed just remove it and always call ep93xx_spi_chip_setup() to configure the hardware for each transfer in the message.
Applied, thanks.

Mark,

I was going to redo this series based on the comments I have received so far. Did you already apply this one? Should I push it to the front of my patchset?

Regards,
Hartley

Mark Brown

maintainer

2013-07-01 19:11 UTC #6 lore raw

Quoted 7 lines · H Hartley Sweeten

Quoted 1 line · Mark Brown
Applied, thanks.
I was going to redo this series based on the comments I have received so far. Did you already apply this one? Should I push it to the front of my patchset?

That's what I said. You shouldn't resend it at all, you should base your updates off the relevant topic branch.