[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140312015342.GL28112@sirena.org.uk>
Date: Wed, 12 Mar 2014 01:53:42 +0000
From: Mark Brown <broonie@...nel.org>
To: Max Filippov <jcmvbkbc@...il.com>
Cc: "linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>,
linux-spi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Chris Zankel <chris@...kel.net>,
Marc Gauthier <marc@...ence.com>,
Rob Herring <robh+dt@...nel.org>,
Grant Likely <grant.likely@...aro.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/3] spi: add xtfpga SPI controller driver
On Wed, Mar 12, 2014 at 05:43:49AM +0400, Max Filippov wrote:
> On Wed, Mar 12, 2014 at 5:08 AM, Mark Brown <broonie@...nel.org> wrote:
> > That's buggy, drivers should never configure anything more than 8 bits
> > per word with regmap.
> Ok, so the driver should allow for 8 bit transfers and regmap will arrange
> transfers as 8-bit pairs, making CS to be asserted for 16 bits, right?
> Hmmm... I see the only way to support that with that hardware: advertise
> 8 bit support, buffer bytes up to 16 bits, send 16 bit words on CS deassertion
> request, log violations verbosely. Other ideas?
That's about it. Like I keep saying for any sort of generic use you
really want to support 8 bits per word.
> > You're missing the point. The controller chip select line can do what
> > it likes, it's not connected to the target device if a GPIO is being
> > used.
> In my case SPI controller is wired directly to the codec with three
> wires: SDIN, SCLK and CS. There are no registers that can control
> either of these wires independently of others.
Right, but other users are likely to exist and the framework has support
for this so it's not much work to support.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists