diff mbox series

[v3] spi: dw: support 4-16 bits per word

Message ID 20180904194944.19721-1-simon.k.r.goldschmidt@gmail.com (mailing list archive)
State Accepted
Commit af060b3f72b801962033f75a2fda25fff992796d
Headers show
Series [v3] spi: dw: support 4-16 bits per word | expand

Commit Message

Simon Goldschmidt Sept. 4, 2018, 7:49 p.m. UTC 
The spi-dw driver currently only supports 8 or 16 bits per word.

Since the hardware supports 4-16 bits per word, adapt the driver
to also support this.

Tested on socfpga cyclone5 with a 9-bit SPI display.

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
Changes in v3
- remove the check for valid 'bits_per_word' from dw_spi_transfer_one()
- add reviewed-by tag

Changes in v2:
- use DIV_ROUND_UP to calculate number of bytes per word instead of
  if/else range checks

 drivers/spi/spi-dw.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

Comments

Mark Brown Sept. 6, 2018, 11:09 a.m. UTC | #1 
On Tue, Sep 04, 2018 at 09:49:44PM +0200, Simon Goldschmidt wrote:
> The spi-dw driver currently only supports 8 or 16 bits per word.
> 
> Since the hardware supports 4-16 bits per word, adapt the driver
> to also support this.

Please don't send new patches in reply to old patch serieses, it makes
it harder to follow what the current version of things is and makes it
much easier for the patches to get lost in the old threads.
Simon Goldschmidt Sept. 6, 2018, 11:23 a.m. UTC | #2 
On Thu, Sep 6, 2018 at 1:09 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Sep 04, 2018 at 09:49:44PM +0200, Simon Goldschmidt wrote:
> > The spi-dw driver currently only supports 8 or 16 bits per word.
> >
> > Since the hardware supports 4-16 bits per word, adapt the driver
> > to also support this.
>
> Please don't send new patches in reply to old patch serieses, it makes
> it harder to follow what the current version of things is and makes it
> much easier for the patches to get lost in the old threads.

Ok, no problem and thanks for the hint! Where does this requirement
come from? Patchwork or mail sorting habits?

Anyway, how does this continue, will you pick the patch or do I need
to somehow collect yet more reviews?

Regards,
Simon
Mark Brown Sept. 6, 2018, 1:23 p.m. UTC | #3 
On Thu, Sep 06, 2018 at 01:23:34PM +0200, Simon Goldschmidt wrote:
> On Thu, Sep 6, 2018 at 1:09 PM Mark Brown <broonie@kernel.org> wrote:

> > Please don't send new patches in reply to old patch serieses, it makes
> > it harder to follow what the current version of things is and makes it
> > much easier for the patches to get lost in the old threads.

> Ok, no problem and thanks for the hint! Where does this requirement
> come from? Patchwork or mail sorting habits?

Mail sorting.  It can mean that you get things like someone deleting a
thread and the new patch getting caught up in a thread delete command
and hence missed.

> Anyway, how does this continue, will you pick the patch or do I need
> to somehow collect yet more reviews?

You should've got a mail at about the same time saying it's been
applied.
Simon Goldschmidt Sept. 6, 2018, 1:37 p.m. UTC | #4 
On Thu, Sep 6, 2018 at 3:23 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Sep 06, 2018 at 01:23:34PM +0200, Simon Goldschmidt wrote:
> > On Thu, Sep 6, 2018 at 1:09 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > Please don't send new patches in reply to old patch serieses, it makes
> > > it harder to follow what the current version of things is and makes it
> > > much easier for the patches to get lost in the old threads.
>
> > Ok, no problem and thanks for the hint! Where does this requirement
> > come from? Patchwork or mail sorting habits?
>
> Mail sorting.  It can mean that you get things like someone deleting a
> thread and the new patch getting caught up in a thread delete command
> and hence missed.
>
> > Anyway, how does this continue, will you pick the patch or do I need
> > to somehow collect yet more reviews?
>
> You should've got a mail at about the same time saying it's been
> applied.

Right, got it. Thanks again.
diff mbox series

Patch

diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index f693bfe95ab9..58a7caf31d59 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -307,15 +307,10 @@  static int dw_spi_transfer_one(struct spi_controller *master,
 		dws->current_freq = transfer->speed_hz;
 		spi_set_clk(dws, chip->clk_div);
 	}
-	if (transfer->bits_per_word == 8) {
-		dws->n_bytes = 1;
-		dws->dma_width = 1;
-	} else if (transfer->bits_per_word == 16) {
-		dws->n_bytes = 2;
-		dws->dma_width = 2;
-	} else {
-		return -EINVAL;
-	}
+
+	dws->n_bytes = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
+	dws->dma_width = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
+
 	/* Default SPI mode is SCPOL = 0, SCPH = 0 */
 	cr0 = (transfer->bits_per_word - 1)
 		| (chip->type << SPI_FRF_OFFSET)
@@ -493,7 +491,7 @@  int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
 	}
 
 	master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
-	master->bits_per_word_mask = SPI_BPW_MASK(8) | SPI_BPW_MASK(16);
+	master->bits_per_word_mask =  SPI_BPW_RANGE_MASK(4, 16);
 	master->bus_num = dws->bus_num;
 	master->num_chipselect = dws->num_cs;
 	master->setup = dw_spi_setup;