Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 8 Sep 2021 13:22:16 +0000
From:   Charles Keepax <ckeepax@opensource.cirrus.com>
To:     Lucas Tanure <tanureal@opensource.cirrus.com>
CC:     Mark Brown <broonie@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Sanjay R Mehta <sanju.mehta@amd.com>,
        Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>,
        <linux-kernel@vger.kernel.org>, <linux-spi@vger.kernel.org>,
        <patches@opensource.cirrus.com>
Subject: Re: [PATCH 08/10] spi: amd: Fill FIFO buffer with the whole message
Message-ID: <20210908132216.GR9223@ediswmail.ad.cirrus.com>
References: <20210908113450.788452-1-tanureal@opensource.cirrus.com>
 <20210908113450.788452-9-tanureal@opensource.cirrus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20210908113450.788452-9-tanureal@opensource.cirrus.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Wed, Sep 08, 2021 at 12:34:49PM +0100, Lucas Tanure wrote:
> The controller is half-duplex, in that it cannot
> read data while it is sending data. But the FIFO
> is full-duplex, the writes and reads must be
> queued and executed together, and the read data
> will be offset in the FIFO by the length of the
> initial write data (as it would in a full-duplex
> SPI).
> 
> And the controller has an automatic CS which can
> only be activated during the transmission of the
> FIFO, which can make read|write data lose meaning
> as the CS will be toggle after the required
> read|write address.
> To avoid that set the max transfer and message
> size as AMD_SPI_FIFO_SIZE ensuring that incoming
> messages always fit inside a FIFO buffer
> 
> Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
> ---

Its only really this change I think that depends relates to the regmap/SPI
changes, it might be worth doing a separate series with the trivial
improvements to the SPI driver. As that allow that to get merged
quickly, and makes the series more focused and easy to review on
the more complex part of supporting the SPI hardwares weird CS/message
length quirk.

Thanks,
Charles