| Message ID | 1607721363-8879-6-git-send-email-skomatineni@nvidia.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add Tegra Quad SPI driver | expand |
On Fri, 11 Dec 2020 13:15:59 -0800 Sowjanya Komatineni <skomatineni@nvidia.com> wrote: > This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers > that support transfer of dummy cycles by the hardware directly. Hm, not sure this is a good idea. I mean, if we expect regular SPI devices to use this feature, then why not, but if it's just for spi-mem, I'd recommend implementing a driver-specific exec_op() instead of using the default one. If we go for those core changes, we should at least add a ctrl->max_dummy_cycles field so the core can fallback to regular writes when the number of dummy cycles in the spi_mem_op exceeds what the controller can do. > > For controller with this flag set, spi-mem driver will skip dummy bytes > transfer in the spi message. > > Controller drivers can get the number of dummy cycles from spi_message. > > Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> > --- > drivers/spi/spi-mem.c | 18 +++++++++++------- > include/linux/spi/spi.h | 8 ++++++++ > 2 files changed, 19 insertions(+), 7 deletions(-) > > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c > index f3a3f19..38a523b 100644 > --- a/drivers/spi/spi-mem.c > +++ b/drivers/spi/spi-mem.c > @@ -350,13 +350,17 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > } > > if (op->dummy.nbytes) { > - memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); > - xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; > - xfers[xferpos].len = op->dummy.nbytes; > - xfers[xferpos].tx_nbits = op->dummy.buswidth; > - spi_message_add_tail(&xfers[xferpos], &msg); > - xferpos++; > - totalxferlen += op->dummy.nbytes; > + if (ctlr->flags & SPI_MASTER_USES_HW_DUMMY_CYCLES) { > + msg.dummy_cycles = (op->dummy.nbytes * 8) / op->dummy.buswidth; > + } else { > + memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); > + xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; > + xfers[xferpos].len = op->dummy.nbytes; > + xfers[xferpos].tx_nbits = op->dummy.buswidth; > + spi_message_add_tail(&xfers[xferpos], &msg); > + xferpos++; > + totalxferlen += op->dummy.nbytes; > + } > } > > if (op->data.nbytes) { > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h > index aa09fdc..2024149 100644 > --- a/include/linux/spi/spi.h > +++ b/include/linux/spi/spi.h > @@ -512,6 +512,8 @@ struct spi_controller { > > #define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must select slave */ > > +#define SPI_MASTER_USES_HW_DUMMY_CYCLES BIT(6) /* HW dummy bytes transfer */ > + > /* flag indicating this is an SPI slave controller */ > bool slave; > > @@ -1022,6 +1024,12 @@ struct spi_message { > unsigned actual_length; > int status; > > + /* > + * dummy cycles in the message transfer. This is used by the controller > + * drivers supports transfer of dummy cycles directly by the hardware. > + */ > + u8 dummy_cycles; > + > /* for optional use by whatever driver currently owns the > * spi_message ... between calls to spi_async and then later > * complete(), that's the spi_controller controller driver.
On 12/12/20 2:57 AM, Boris Brezillon wrote: > On Fri, 11 Dec 2020 13:15:59 -0800 > Sowjanya Komatineni <skomatineni@nvidia.com> wrote: > >> This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers >> that support transfer of dummy cycles by the hardware directly. > Hm, not sure this is a good idea. I mean, if we expect regular SPI > devices to use this feature, then why not, but if it's just for > spi-mem, I'd recommend implementing a driver-specific exec_op() instead > of using the default one. dummy cycles programming is SPI device specific. Transfer of dummy bytes by SW or HW controller can be depending on features supported by controller. Adding controller driver specific exec_op() Just for skipping dummy bytes transfer will have so much of redundant code pretty much what all spi_mem_exec_op does. So in v1, I handled this in controller driver by skipping SW transfer of dummy bytes during dummy phase and programming dummy cycles in controller register to allow HW to transfer. Based on v1 feedback discussion, added this flag SPI_MASTER_USES_HW_DUMMY_CYCLES which can be used by controllers supporting HW dummy bytes transfer and updated spi_mem_exec_op to skip SW dummy bytes. This helps other controllers supporting HW transfer of dummy bytes as well just to set the flag and use dummy cycles directly. > If we go for those core changes, we should at least add a > ctrl->max_dummy_cycles field so the core can fallback to regular writes > when the number of dummy cycles in the spi_mem_op exceeds what the > controller can do. Yes makes sense. Will add this once we decide on keeping this flag to identify controllers supporting HW transfer of dummy bytes Vs SW transfer. >> For controller with this flag set, spi-mem driver will skip dummy bytes >> transfer in the spi message. >> >> Controller drivers can get the number of dummy cycles from spi_message. >> >> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> >> --- >> drivers/spi/spi-mem.c | 18 +++++++++++------- >> include/linux/spi/spi.h | 8 ++++++++ >> 2 files changed, 19 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c >> index f3a3f19..38a523b 100644 >> --- a/drivers/spi/spi-mem.c >> +++ b/drivers/spi/spi-mem.c >> @@ -350,13 +350,17 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) >> } >> >> if (op->dummy.nbytes) { >> - memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); >> - xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; >> - xfers[xferpos].len = op->dummy.nbytes; >> - xfers[xferpos].tx_nbits = op->dummy.buswidth; >> - spi_message_add_tail(&xfers[xferpos], &msg); >> - xferpos++; >> - totalxferlen += op->dummy.nbytes; >> + if (ctlr->flags & SPI_MASTER_USES_HW_DUMMY_CYCLES) { >> + msg.dummy_cycles = (op->dummy.nbytes * 8) / op->dummy.buswidth; >> + } else { >> + memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); >> + xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; >> + xfers[xferpos].len = op->dummy.nbytes; >> + xfers[xferpos].tx_nbits = op->dummy.buswidth; >> + spi_message_add_tail(&xfers[xferpos], &msg); >> + xferpos++; >> + totalxferlen += op->dummy.nbytes; >> + } >> } >> >> if (op->data.nbytes) { >> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h >> index aa09fdc..2024149 100644 >> --- a/include/linux/spi/spi.h >> +++ b/include/linux/spi/spi.h >> @@ -512,6 +512,8 @@ struct spi_controller { >> >> #define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must select slave */ >> >> +#define SPI_MASTER_USES_HW_DUMMY_CYCLES BIT(6) /* HW dummy bytes transfer */ >> + >> /* flag indicating this is an SPI slave controller */ >> bool slave; >> >> @@ -1022,6 +1024,12 @@ struct spi_message { >> unsigned actual_length; >> int status; >> >> + /* >> + * dummy cycles in the message transfer. This is used by the controller >> + * drivers supports transfer of dummy cycles directly by the hardware. >> + */ >> + u8 dummy_cycles; >> + >> /* for optional use by whatever driver currently owns the >> * spi_message ... between calls to spi_async and then later >> * complete(), that's the spi_controller controller driver.
On Sat, 12 Dec 2020 09:28:50 -0800 Sowjanya Komatineni <skomatineni@nvidia.com> wrote: > On 12/12/20 2:57 AM, Boris Brezillon wrote: > > On Fri, 11 Dec 2020 13:15:59 -0800 > > Sowjanya Komatineni <skomatineni@nvidia.com> wrote: > > > >> This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers > >> that support transfer of dummy cycles by the hardware directly. > > Hm, not sure this is a good idea. I mean, if we expect regular SPI > > devices to use this feature, then why not, but if it's just for > > spi-mem, I'd recommend implementing a driver-specific exec_op() instead > > of using the default one. > > dummy cycles programming is SPI device specific. > > Transfer of dummy bytes by SW or HW controller can be depending on > features supported by controller. > > Adding controller driver specific exec_op() Just for skipping dummy > bytes transfer will have so much of redundant code pretty much what all > spi_mem_exec_op does. > > So in v1, I handled this in controller driver by skipping SW transfer of > dummy bytes during dummy phase and programming dummy cycles in > controller register to allow HW to transfer. > > Based on v1 feedback discussion, added this flag > SPI_MASTER_USES_HW_DUMMY_CYCLES which can be used by controllers > supporting HW dummy bytes transfer and updated spi_mem_exec_op to skip > SW dummy bytes. > > This helps other controllers supporting HW transfer of dummy bytes as > well just to set the flag and use dummy cycles directly. Except saying a spi_message has X dummy cycle is not precise enough. Where are those dummy cycles in the transfer sequence? spi-mem has well defined sequencing (cmd[+addr][+dummy][+data]) so we know exacly where dummy cycles are, but trying to retro-fit the dummy-cycle concept in the generic spi_message is confusing IMHO. If want to avoid code duplication, I'm pretty sure the driver can be reworked so the spi_transfer/exec_op() path can share most of the logic (that probably implies declaring a tegra_qspi_op). > > > If we go for those core changes, we should at least add a > > ctrl->max_dummy_cycles field so the core can fallback to regular writes > > when the number of dummy cycles in the spi_mem_op exceeds what the > > controller can do. > Yes makes sense. Will add this once we decide on keeping this flag to > identify controllers supporting HW transfer of dummy bytes Vs SW transfer. > >> For controller with this flag set, spi-mem driver will skip dummy bytes > >> transfer in the spi message. > >> > >> Controller drivers can get the number of dummy cycles from spi_message. > >> > >> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> > >> --- > >> drivers/spi/spi-mem.c | 18 +++++++++++------- > >> include/linux/spi/spi.h | 8 ++++++++ > >> 2 files changed, 19 insertions(+), 7 deletions(-) > >> > >> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c > >> index f3a3f19..38a523b 100644 > >> --- a/drivers/spi/spi-mem.c > >> +++ b/drivers/spi/spi-mem.c > >> @@ -350,13 +350,17 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > >> } > >> > >> if (op->dummy.nbytes) { > >> - memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); > >> - xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; > >> - xfers[xferpos].len = op->dummy.nbytes; > >> - xfers[xferpos].tx_nbits = op->dummy.buswidth; > >> - spi_message_add_tail(&xfers[xferpos], &msg); > >> - xferpos++; > >> - totalxferlen += op->dummy.nbytes; > >> + if (ctlr->flags & SPI_MASTER_USES_HW_DUMMY_CYCLES) { > >> + msg.dummy_cycles = (op->dummy.nbytes * 8) / op->dummy.buswidth; > >> + } else { > >> + memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); > >> + xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; > >> + xfers[xferpos].len = op->dummy.nbytes; > >> + xfers[xferpos].tx_nbits = op->dummy.buswidth; > >> + spi_message_add_tail(&xfers[xferpos], &msg); > >> + xferpos++; > >> + totalxferlen += op->dummy.nbytes; > >> + } > >> } > >> > >> if (op->data.nbytes) { > >> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h > >> index aa09fdc..2024149 100644 > >> --- a/include/linux/spi/spi.h > >> +++ b/include/linux/spi/spi.h > >> @@ -512,6 +512,8 @@ struct spi_controller { > >> > >> #define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must select slave */ > >> > >> +#define SPI_MASTER_USES_HW_DUMMY_CYCLES BIT(6) /* HW dummy bytes transfer */ > >> + > >> /* flag indicating this is an SPI slave controller */ > >> bool slave; > >> > >> @@ -1022,6 +1024,12 @@ struct spi_message { > >> unsigned actual_length; > >> int status; > >> > >> + /* > >> + * dummy cycles in the message transfer. This is used by the controller > >> + * drivers supports transfer of dummy cycles directly by the hardware. > >> + */ > >> + u8 dummy_cycles; > >> + > >> /* for optional use by whatever driver currently owns the > >> * spi_message ... between calls to spi_async and then later > >> * complete(), that's the spi_controller controller driver.
On Sun, 13 Dec 2020 10:54:26 +0100 Boris Brezillon <boris.brezillon@collabora.com> wrote: > On Sat, 12 Dec 2020 09:28:50 -0800 > Sowjanya Komatineni <skomatineni@nvidia.com> wrote: > > > On 12/12/20 2:57 AM, Boris Brezillon wrote: > > > On Fri, 11 Dec 2020 13:15:59 -0800 > > > Sowjanya Komatineni <skomatineni@nvidia.com> wrote: > > > > > >> This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers > > >> that support transfer of dummy cycles by the hardware directly. > > > Hm, not sure this is a good idea. I mean, if we expect regular SPI > > > devices to use this feature, then why not, but if it's just for > > > spi-mem, I'd recommend implementing a driver-specific exec_op() instead > > > of using the default one. > > > > dummy cycles programming is SPI device specific. > > > > Transfer of dummy bytes by SW or HW controller can be depending on > > features supported by controller. > > > > Adding controller driver specific exec_op() Just for skipping dummy > > bytes transfer will have so much of redundant code pretty much what all > > spi_mem_exec_op does. > > > > So in v1, I handled this in controller driver by skipping SW transfer of > > dummy bytes during dummy phase and programming dummy cycles in > > controller register to allow HW to transfer. > > > > Based on v1 feedback discussion, added this flag > > SPI_MASTER_USES_HW_DUMMY_CYCLES which can be used by controllers > > supporting HW dummy bytes transfer and updated spi_mem_exec_op to skip > > SW dummy bytes. > > > > This helps other controllers supporting HW transfer of dummy bytes as > > well just to set the flag and use dummy cycles directly. > > Except saying a spi_message has X dummy cycle is not precise enough. > Where are those dummy cycles in the transfer sequence? spi-mem has well > defined sequencing (cmd[+addr][+dummy][+data]) so we know exacly where > dummy cycles are, but trying to retro-fit the dummy-cycle concept in > the generic spi_message is confusing IMHO. If want to avoid code > duplication, I'm pretty sure the driver can be reworked so the > spi_transfer/exec_op() path can share most of the logic (that probably > implies declaring a tegra_qspi_op). Something like that might also do the trick: --->8--- diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index ef53290b7d24..8b0476f37fbb 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -353,6 +353,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; xfers[xferpos].len = op->dummy.nbytes; xfers[xferpos].tx_nbits = op->dummy.buswidth; + xfers[xferpos].dummy_data = 1; spi_message_add_tail(&xfers[xferpos], &msg); xferpos++; totalxferlen += op->dummy.nbytes; diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 99380c0825db..ecf7989318c5 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -807,6 +807,10 @@ extern void spi_res_release(struct spi_controller *ctlr, * transfer. If 0 the default (from @spi_device) is used. * @bits_per_word: select a bits_per_word other than the device default * for this transfer. If 0 the default (from @spi_device) is used. + * @dummy_data: set to 1 for a dummy transfer (a transfer whose data is + * ignored). Controllers that are able to issue dummy cycles can ignore + * tx_buf, for those that can't tx_buf will contain dummy bytes. The + * number of dummy cycles to issue is (len * tx_bits) / 8. * @cs_change: affects chipselect after this transfer completes * @cs_change_delay: delay between cs deassert and assert when * @cs_change is set and @spi_transfer is not the last in @spi_message @@ -919,6 +923,7 @@ struct spi_transfer { struct sg_table tx_sg; struct sg_table rx_sg; + unsigned dummy_data:1; unsigned cs_change:1; unsigned tx_nbits:3; unsigned rx_nbits:3;
On 12/13/20 3:28 AM, Boris Brezillon wrote: > On Sun, 13 Dec 2020 10:54:26 +0100 > Boris Brezillon <boris.brezillon@collabora.com> wrote: > >> On Sat, 12 Dec 2020 09:28:50 -0800 >> Sowjanya Komatineni <skomatineni@nvidia.com> wrote: >> >>> On 12/12/20 2:57 AM, Boris Brezillon wrote: >>>> On Fri, 11 Dec 2020 13:15:59 -0800 >>>> Sowjanya Komatineni <skomatineni@nvidia.com> wrote: >>>> >>>>> This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers >>>>> that support transfer of dummy cycles by the hardware directly. >>>> Hm, not sure this is a good idea. I mean, if we expect regular SPI >>>> devices to use this feature, then why not, but if it's just for >>>> spi-mem, I'd recommend implementing a driver-specific exec_op() instead >>>> of using the default one. >>> dummy cycles programming is SPI device specific. >>> >>> Transfer of dummy bytes by SW or HW controller can be depending on >>> features supported by controller. >>> >>> Adding controller driver specific exec_op() Just for skipping dummy >>> bytes transfer will have so much of redundant code pretty much what all >>> spi_mem_exec_op does. >>> >>> So in v1, I handled this in controller driver by skipping SW transfer of >>> dummy bytes during dummy phase and programming dummy cycles in >>> controller register to allow HW to transfer. >>> >>> Based on v1 feedback discussion, added this flag >>> SPI_MASTER_USES_HW_DUMMY_CYCLES which can be used by controllers >>> supporting HW dummy bytes transfer and updated spi_mem_exec_op to skip >>> SW dummy bytes. >>> >>> This helps other controllers supporting HW transfer of dummy bytes as >>> well just to set the flag and use dummy cycles directly. >> Except saying a spi_message has X dummy cycle is not precise enough. >> Where are those dummy cycles in the transfer sequence? spi-mem has well >> defined sequencing (cmd[+addr][+dummy][+data]) so we know exacly where >> dummy cycles are, but trying to retro-fit the dummy-cycle concept in >> the generic spi_message is confusing IMHO. If want to avoid code >> duplication, I'm pretty sure the driver can be reworked so the >> spi_transfer/exec_op() path can share most of the logic (that probably >> implies declaring a tegra_qspi_op). > Something like that might also do the trick: > > --->8--- > > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c > index ef53290b7d24..8b0476f37fbb 100644 > --- a/drivers/spi/spi-mem.c > +++ b/drivers/spi/spi-mem.c > @@ -353,6 +353,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; > xfers[xferpos].len = op->dummy.nbytes; > xfers[xferpos].tx_nbits = op->dummy.buswidth; > + xfers[xferpos].dummy_data = 1; > spi_message_add_tail(&xfers[xferpos], &msg); > xferpos++; > totalxferlen += op->dummy.nbytes; > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h > index 99380c0825db..ecf7989318c5 100644 > --- a/include/linux/spi/spi.h > +++ b/include/linux/spi/spi.h > @@ -807,6 +807,10 @@ extern void spi_res_release(struct spi_controller *ctlr, > * transfer. If 0 the default (from @spi_device) is used. > * @bits_per_word: select a bits_per_word other than the device default > * for this transfer. If 0 the default (from @spi_device) is used. > + * @dummy_data: set to 1 for a dummy transfer (a transfer whose data is > + * ignored). Controllers that are able to issue dummy cycles can ignore > + * tx_buf, for those that can't tx_buf will contain dummy bytes. The > + * number of dummy cycles to issue is (len * tx_bits) / 8. > * @cs_change: affects chipselect after this transfer completes > * @cs_change_delay: delay between cs deassert and assert when > * @cs_change is set and @spi_transfer is not the last in @spi_message > @@ -919,6 +923,7 @@ struct spi_transfer { > struct sg_table tx_sg; > struct sg_table rx_sg; > > + unsigned dummy_data:1; > unsigned cs_change:1; > unsigned tx_nbits:3; > unsigned rx_nbits:3; Thanks Boris. Sorry was thinking of spi flash device only as we only support quad spi flash on Tegra QSPI interface. But to make it more generic where spi message preparation can happen from any client driver, agree order of transfers may vary. Also having controller driver implement exec_op callback is also not useful considering cases where spi message transfers dont' go thru spi_mem. Yes adding dummy_data field to indicate transfer is dummy bytes transfer helps for any types of message transfers. Tegra QSPI controller dummy cycles need be programmed with transfer after which dummy cycles are needed. So, will have v4 to add dummy_data to spi_transfer and will update controller driver to convert dummy bytes to dummy cycles and program dummy cycles with its previous transfer and skip dummy transfer buffer. Thanks Sowjanya
On Sat, Dec 12, 2020 at 11:57:15AM +0100, Boris Brezillon wrote: > Sowjanya Komatineni <skomatineni@nvidia.com> wrote: > > This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers > > that support transfer of dummy cycles by the hardware directly. > Hm, not sure this is a good idea. I mean, if we expect regular SPI > devices to use this feature, then why not, but if it's just for > spi-mem, I'd recommend implementing a driver-specific exec_op() instead > of using the default one. I *have* seen other high speed devices which had padding bits in the transfer (see regmap's pad_bits feature), I think that corresponds to flash dummy bits but haven't checked that the hardware support lines up. I'm not sure it's ever been seen as something that we particularly needed to speed up with hardware offload though. > If we go for those core changes, we should at least add a > ctrl->max_dummy_cycles field so the core can fallback to regular writes > when the number of dummy cycles in the spi_mem_op exceeds what the > controller can do. That seems sensible if there's a risk of controllers being too limited, which knowing hardware seems likely.
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index f3a3f19..38a523b 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -350,13 +350,17 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) } if (op->dummy.nbytes) { - memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); - xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; - xfers[xferpos].len = op->dummy.nbytes; - xfers[xferpos].tx_nbits = op->dummy.buswidth; - spi_message_add_tail(&xfers[xferpos], &msg); - xferpos++; - totalxferlen += op->dummy.nbytes; + if (ctlr->flags & SPI_MASTER_USES_HW_DUMMY_CYCLES) { + msg.dummy_cycles = (op->dummy.nbytes * 8) / op->dummy.buswidth; + } else { + memset(tmpbuf + op->addr.nbytes + 1, 0xff, op->dummy.nbytes); + xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1; + xfers[xferpos].len = op->dummy.nbytes; + xfers[xferpos].tx_nbits = op->dummy.buswidth; + spi_message_add_tail(&xfers[xferpos], &msg); + xferpos++; + totalxferlen += op->dummy.nbytes; + } } if (op->data.nbytes) { diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index aa09fdc..2024149 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -512,6 +512,8 @@ struct spi_controller { #define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must select slave */ +#define SPI_MASTER_USES_HW_DUMMY_CYCLES BIT(6) /* HW dummy bytes transfer */ + /* flag indicating this is an SPI slave controller */ bool slave; @@ -1022,6 +1024,12 @@ struct spi_message { unsigned actual_length; int status; + /* + * dummy cycles in the message transfer. This is used by the controller + * drivers supports transfer of dummy cycles directly by the hardware. + */ + u8 dummy_cycles; + /* for optional use by whatever driver currently owns the * spi_message ... between calls to spi_async and then later * complete(), that's the spi_controller controller driver.
This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers that support transfer of dummy cycles by the hardware directly. For controller with this flag set, spi-mem driver will skip dummy bytes transfer in the spi message. Controller drivers can get the number of dummy cycles from spi_message. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> --- drivers/spi/spi-mem.c | 18 +++++++++++------- include/linux/spi/spi.h | 8 ++++++++ 2 files changed, 19 insertions(+), 7 deletions(-)