[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Oct 2018 22:21:51 +0000
From: Trent Piepho <tpiepho@...inj.com>
To: "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"talel@...zon.com" <talel@...zon.com>,
"mark.rutland@....com" <mark.rutland@....com>,
"broonie@...nel.org" <broonie@...nel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "barakw@...zon.com" <barakw@...zon.com>,
"ronenk@...zon.com" <ronenk@...zon.com>,
"dwmw@...zon.co.uk" <dwmw@...zon.co.uk>
Subject: Re: [PATCH 1/2] dt-bindings: spi: dw: add cs-override property
On Wed, 2018-10-10 at 10:08 +0300, Talel Shenhar wrote:
>
> The dw spi controller has an auto-deselect of Chip-Select, in case there is
> no data inside the Tx FIFO. While working on platforms with Alpine chips,
> auto-deselect mode causes an issue for some spi devices that can't handle
> the Chip-Select deselect in the middle of a transaction. It is a normal
> behavior for a Tx FIFO to be empty in the middle of a transaction, due to
>
So that's the problem! I, like everyone else I suspect, switched to
using GPIO chip selects with this driver because of this. I narrowed
it down to a CS de-assert when the bus switched from TX to RX, which of
course makes a SPI register read fail on most devices. The TX FIFO
would empty at this point, so that would explain it.
Did the designers of this IP ever read a SPI device datasheet???
Got to agree with Mark Brown, why would anyone ever want to NOT have it
work properly? The previous behavior is not "alternate correct", it's
Broken.
Powered by blists - more mailing lists