[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170301155209.bohcksub6ahhrevu@sirena.org.uk>
Date: Wed, 1 Mar 2017 15:52:09 +0000
From: Mark Brown <broonie@...nel.org>
To: Cyrille Pitchen <cyrille.pitchen@...el.com>
Cc: Vignesh R <vigneshr@...com>, Richard Weinberger <richard@....at>,
David Woodhouse <dwmw2@...radead.org>,
Brian Norris <computersforpeace@...il.com>,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
Marek Vasut <marek.vasut@...il.com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-omap@...r.kernel.org, Frode Isaksen <fisaksen@...libre.com>,
linux-spi@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce
buffer support
On Wed, Mar 01, 2017 at 03:21:24PM +0100, Cyrille Pitchen wrote:
> Besides, some SPI controller drivers may already use their own bounce
> buffer for other reasons. Then for those controllers, it would be one
> more copy.
They probably shouldn't, there's a lot of legacy drivers that do all
sorts of fun stuff but if people are having performance problems we
should probably be putting pressure on the driver users to improve
things. Anything that has a bounce buffer probably isn't going to say
it can do DMA though...
> Then I don't whether we should:
> 1 - extend in SPI sub-system API to tell us if the SPI controller can
> deal with non-kmalloc'd buffer for DMA transfers
I don't think we can tell any better than anything else really. We
could tell if a driver has a bounce buffer or is PIO based but that's
not the whole story so it's not ideal.
> or
> 2 - get the answer at a system-wide level.
That seems better. It'd be really good if we had a function we could
call that'd do the mappings including any bounce buffering that's needed
rather than having to think about it in the subsystems.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists