[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0D753D10438DA54287A00B027084269764CDF41635@AUSP01VMBX24.collaborationhost.net>
Date: Mon, 10 Jan 2011 16:36:50 -0600
From: H Hartley Sweeten <hartleys@...ionengravers.com>
To: David Brownell <david-b@...bell.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"spi-devel-general@...ts.sourceforge.net"
<spi-devel-general@...ts.sourceforge.net>
CC: David Woodhouse <dwmw2@...radead.org>,
Grant Likely <grant.likely@...retlab.ca>,
"Artem.Bityutskiy@...ia.com" <Artem.Bityutskiy@...ia.com>
Subject: RE: [PATCH] mtd: sst25l: fix reads with broken spi-masters
On Monday, January 10, 2011 3:20 PM, David Brownell wrote:
> --- On Mon, 1/10/11, H Hartley Sweeten <hartleys@...ionengravers.com> wrote:
> NAK. I'm surprised you even thought to submit
> such a clearly-wrong patch.
>
> The bug is in the SPI master driver, and thus
> so should the fix be. Or make your system use
> the GPIO based SPI master driver.
Sorry.
The bug _is_ in the spi peripheral on the ep93xx.
Unfortunately, hardware does exist that uses the SFRMOUT signal as part of
the chip select to access the device. The only way to get this signal to
do anything is by using the spi peripheral. The SFRMOUT signal cannot be
accessed using GPIO so the GPIO based SPI master driver is not an option.
If the SFRMOUT signal is _not_ used in the chip select logic then everything
works fine.
But... If it's a NAK.. It's a NAK... I'll try to figure out a way to handle
this in the SPI master driver.
Regards,
Hartley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists