Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 26 Sep 2022 15:42:30 +0200
From:   Vincent Whitchurch <vincent.whitchurch@axis.com>
To:     Mark Brown <broonie@kernel.org>
CC:     <krzysztof.kozlowski@linaro.org>, <andi@etezian.org>,
        <kernel@axis.com>, <alim.akhtar@samsung.com>,
        <linux-spi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-samsung-soc@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/4] spi: s3c64xx: Fix large transfers with DMA
Message-ID: <YzGsRkyf9tyvjvBy@axis.com>
References: <20220916113951.228398-1-vincent.whitchurch@axis.com>
 <20220916113951.228398-5-vincent.whitchurch@axis.com>
 <Yyh+5ZWXel9SHuWi@sirena.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Yyh+5ZWXel9SHuWi@sirena.org.uk>
Precedence: bulk

On Mon, Sep 19, 2022 at 03:38:29PM +0100, Mark Brown wrote:
> On Fri, Sep 16, 2022 at 01:39:51PM +0200, Vincent Whitchurch wrote:
> > The COUNT_VALUE in the PACKET_CNT register is 16-bit so the maximum
> > value is 65535.  Asking the driver to transfer a larger size currently
> > leads to the DMA transfer timing out.  Fix this by splitting the
> > transfer as needed.
> 
> The driver should just set max_transfer_size and let the core
> handle this.

Hmm, AFAICS, the core doesn't actually do anything with
max_transfer_size?  It's only used from spi-mem and a handful of other
clients via spi_max_transfer_size().