mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sowjanya Komatineni <skomatineni@nvidia.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: <thierry.reding@gmail.com>, <jonathanh@nvidia.com>,
	<broonie@kernel.org>, <robh+dt@kernel.org>, <lukas@wunner.de>,
	<bbrezillon@kernel.org>, <p.yadav@ti.com>,
	<tudor.ambarus@microchip.com>, <linux-spi@vger.kernel.org>,
	<linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH v3 5/9] spi: spi-mem: Allow masters to transfer dummy cycles directly by hardware
Date: Sat, 12 Dec 2020 09:28:50 -0800	[thread overview]
Message-ID: <7efb281a-98d7-68c5-1515-0e980b6cfe12@nvidia.com> (raw)
In-Reply-To: <20201212115715.31a8d755@collabora.com>


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.

  reply	other threads:[~2020-12-12 17:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-11 21:15 [PATCH v3 0/9] Add Tegra Quad SPI driver Sowjanya Komatineni
2020-12-11 21:15 ` [PATCH v3 1/9] dt-bindings: clock: tegra: Add clock ID TEGRA210_CLK_QSPI_PM Sowjanya Komatineni
2020-12-15 16:03   ` Rob Herring
2020-12-11 21:15 ` [PATCH v3 2/9] dt-bindings: spi: Add Tegra Quad SPI device tree binding Sowjanya Komatineni
2020-12-15 16:13   ` Rob Herring
2020-12-11 21:15 ` [PATCH v3 3/9] MAINTAINERS: Add Tegra Quad SPI driver section Sowjanya Komatineni
2020-12-11 21:15 ` [PATCH v3 4/9] spi: tegra210-quad: Add support for Tegra210 QSPI controller Sowjanya Komatineni
2020-12-12 12:06   ` Lukas Wunner
2020-12-11 21:15 ` [PATCH v3 5/9] spi: spi-mem: Allow masters to transfer dummy cycles directly by hardware Sowjanya Komatineni
2020-12-12 10:57   ` Boris Brezillon
2020-12-12 17:28     ` Sowjanya Komatineni [this message]
2020-12-13  9:54       ` Boris Brezillon
2020-12-13 11:28         ` Boris Brezillon
2020-12-13 17:34           ` Sowjanya Komatineni
2020-12-14 16:23     ` Mark Brown
2020-12-11 21:16 ` [PATCH v3 6/9] spi: tegra210-quad: Add support for hardware dummy cycles Sowjanya Komatineni
2020-12-13 10:14   ` Boris Brezillon
2020-12-11 21:16 ` [PATCH v3 7/9] arm64: tegra: Enable QSPI on Jetson Nano Sowjanya Komatineni
2020-12-11 21:16 ` [PATCH v3 8/9] arm64: tegra: Add QSPI nodes on Tegra194 Sowjanya Komatineni
2020-12-11 21:16 ` [PATCH v3 9/9] arm64: tegra: Enable QSPI on Jetson Xavier NX Sowjanya Komatineni

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=7efb281a-98d7-68c5-1515-0e980b6cfe12@nvidia.com \
    --to=skomatineni@nvidia.com \
    --cc=bbrezillon@kernel.org \
    --cc=boris.brezillon@collabora.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=p.yadav@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tudor.ambarus@microchip.com \
    /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

all inboxes | Powered by JetHome®