Fix Seaboard UART corruption on SPI activity

Fix Seaboard UART corruption on SPI activity

On Seaboard the UART and SPI interfere with each other. This causes the UART
to receive spurious zero bytes after SPI transactions and also means that
SPI can corrupt a few output characters when it starts up if they are still
in the UART buffer.

This hack corrects this by making SPI record that it may have corrupted the
UART, and making the UART take evasive action.

BUG=chromium-os:13228
TEST=Try developer U-Boot on Seaboard, make sure it auto-boots OK now

Change-Id: I130f5e8bdf1be48b20015c8b2228d972409cc135

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=030faed

[sjg, 2011-03-22 00:36:27]

Better ideas welcome.

[sjg, 2011-03-25 00:14:27]

Have changed this to keep the hack in SPI. PTAL, thanks.

[robotboy, 2011-03-25 00:18:23]

LGTM, a couple of questions that probably don't matter, but might make it even
simpler.

http://codereview.chromium.org/6715017/diff/6001/drivers/spi/tegra2_spi.c
File drivers/spi/tegra2_spi.c (right):

http://codereview.chromium.org/6715017/diff/6001/drivers/spi/tegra2_spi.c#new...
drivers/spi/tegra2_spi.c:160: NS16550_clear(CONFIG_SPI_CORRUPTS_UART);
Is clear strictly required here?  Is just calling drain sufficient?

http://codereview.chromium.org/6715017/diff/6001/drivers/spi/tegra2_spi.c#new...
drivers/spi/tegra2_spi.c:219: NS16550_drain(CONFIG_SPI_CORRUPTS_UART);
Same question as above, except in this case is drain really required?

[sjg, 2011-03-25 17:03:43]

One problem with this approach is that it does slow down SPI. For example
erasing 4MB of flash takes about 27s instead of 20s. With my original patch
(admittedly more complex) the time doesn't get any slower.

The basic problem is that we seem to need a delay of around 100us after SPI
releasing CS. The original version only did this when needed.

Thoughts?

[robotboy, 2011-03-25 17:12:25]

On 2011/03/25 17:03:43, sjg wrote:
> One problem with this approach is that it does slow down SPI. For example
> erasing 4MB of flash takes about 27s instead of 20s. With my original patch
> (admittedly more complex) the time doesn't get any slower.
> 
> The basic problem is that we seem to need a delay of around 100us after SPI
> releasing CS. The original version only did this when needed.
> 
> Thoughts?

Since it's only Seaboard that is effected (yes?) and the time isn't terrible,
and the result is a much simpler fix...  I think we should go with this
solution.

[sjg, 2011-03-25 17:24:38]

On 2011/03/25 17:12:25, robotboy wrote:
> On 2011/03/25 17:03:43, sjg wrote:
> > One problem with this approach is that it does slow down SPI. For example
> > erasing 4MB of flash takes about 27s instead of 20s. With my original patch
> > (admittedly more complex) the time doesn't get any slower.
> > 
> > The basic problem is that we seem to need a delay of around 100us after SPI
> > releasing CS. The original version only did this when needed.
> > 
> > Thoughts?
> 
> Since it's only Seaboard that is effected (yes?) and the time isn't terrible,
> and the result is a much simpler fix...  I think we should go with this
> solution.

OK will push, thanks.

[Tom Warren, 2011-03-31 15:20:47]

Simon,

Can you include me in CLs like this in the future? Thanks!

Tom

[sjg, 2011-03-31 16:38:16]

Yes will do. Sorry I didn't think of it in this case - Simon

On Thu, Mar 31, 2011 at 8:20 AM,  <twarren.nvidia@gmail.com> wrote:
> Simon,
>
> Can you include me in CLs like this in the future? Thanks!
>
> Tom
>
>
> http://codereview.chromium.org/6715017/
>

[Tom Warren, 2011-03-31 17:57:05]

When you fix the warnings (I'm seeing them for the 2 new NS16550 funcs, too, now
that I've turned on CONFIG_SPI_CORRUPTS_UART in my tegra2_seaboard_build), could
you also add a #define CONFIG_SPI_CORRUPTS_UART to the tegra2_seaboard.h config
file? That appears to work OK - I'm not seeing the comms corruption I was before
(that was happening because you removed the 2 udelay(1000) calls in
cs_activate/deactivate, and w/o CONFIG_SPI_CORRUPTS_UART defined, your new UART
code wasn't run).

Thanks,

Tom