[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190502024524.GV14916@sirena.org.uk>
Date: Thu, 2 May 2019 11:45:24 +0900
From: Mark Brown <broonie@...nel.org>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc: "robh+dt@...nel.org" <robh+dt@...nel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
Hamish Martin <Hamish.Martin@...iedtelesis.co.nz>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tthayer@...nsource.altera.com" <tthayer@...nsource.altera.com>
Subject: Re: [PATCH 0/3] spi: SPI bus multiplexer
On Sun, Apr 28, 2019 at 10:28:16PM +0000, Chris Packham wrote:
> One other problem that I encounter is the interaction between cs-gpio
> and SPI_MASTER_GPIO_SS. Having cs-gpio automatically sets SPI_CS_HIGH
> which has the undesired side-effect that now my real chip select is
> inverted. I actually wonder if this change breaks commit 8eee6b9dd30d
> ("spi: Add Flag to Enable Slave Select with GPIO Chip Select.") since
> now there is an extra inversion on the CS enable.
That sounds like a framework bug which should just be fixed - we
shouldn't be disrupting users of real chip selects when using a GPIO
chip select. Depending on the hardware we might need a chip select
assigned that isn't connected to anything for use while the GPIOs are
doing the real work but otherwise we shouldn't be breaking things.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists