linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [spi-devel-general] PATCH [1/1] SPI: AMBA_PL022: Limit TX FIFO fills based on current RX FIFO used
       [not found] <083DF309106F364B939360100EC290F805C4BF1E97@eu1rdcrdc1wx030.exi.nxp.com>
@ 2010-01-22 12:56 ` Linus Walleij
  2010-02-03 17:48   ` Grant Likely
  0 siblings, 1 reply; 3+ messages in thread
From: Linus Walleij @ 2010-01-22 12:56 UTC (permalink / raw)
  To: linux-arm-kernel

2010/1/20 Kevin Wells <kevin.wells@nxp.com>:

> Added logic to cap TX FIFO fill size based on current free RX
> FIFO entries instead of TX status flags. This is to prevent
> an issue with RX FIFO overflows

Excellent patch and works like a charm on the U300. My loopback code
would generate
spurious overfill errors before and now it *never* fails so you hit
exactly the right spot.
I remember being intrigued by this when I worked on the driver and now
it is finally
nailed.

As some sort of maintainer of this file I have signed it off and put
it into Russells
patch tracker for inclusion, OK? See;
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5893/1

Linus Walleij

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [spi-devel-general] PATCH [1/1] SPI: AMBA_PL022: Limit TX FIFO fills based on current RX FIFO used
  2010-01-22 12:56 ` [spi-devel-general] PATCH [1/1] SPI: AMBA_PL022: Limit TX FIFO fills based on current RX FIFO used Linus Walleij
@ 2010-02-03 17:48   ` Grant Likely
  2010-02-03 22:15     ` Linus Walleij
  0 siblings, 1 reply; 3+ messages in thread
From: Grant Likely @ 2010-02-03 17:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jan 22, 2010 at 5:56 AM, Linus Walleij
<linus.ml.walleij@gmail.com> wrote:
> 2010/1/20 Kevin Wells <kevin.wells@nxp.com>:
>
>> Added logic to cap TX FIFO fill size based on current free RX
>> FIFO entries instead of TX status flags. This is to prevent
>> an issue with RX FIFO overflows
>
> Excellent patch and works like a charm on the U300. My loopback code
> would generate
> spurious overfill errors before and now it *never* fails so you hit
> exactly the right spot.
> I remember being intrigued by this when I worked on the driver and now
> it is finally
> nailed.
>
> As some sort of maintainer of this file I have signed it off and put
> it into Russells
> patch tracker for inclusion, OK? See;
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5893/1

I'm actively maintaining SPI now.  In general, I'd prefer SPI patches
to go through the SPI tree, unless there are commit ordering issues
with arch code.  I'm tracking SPI patches with patchwork:

http://patchwork.kernel.org/project/spi-devel-general/list/

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [spi-devel-general] PATCH [1/1] SPI: AMBA_PL022: Limit TX FIFO fills based on current RX FIFO used
  2010-02-03 17:48   ` Grant Likely
@ 2010-02-03 22:15     ` Linus Walleij
  0 siblings, 0 replies; 3+ messages in thread
From: Linus Walleij @ 2010-02-03 22:15 UTC (permalink / raw)
  To: linux-arm-kernel

2010/2/3 Grant Likely <grant.likely@secretlab.ca>:

> I'm actively maintaining SPI now. ?In general, I'd prefer SPI patches
> to go through the SPI tree, unless there are commit ordering issues
> with arch code.

Sorry, will queue them in your tree next time, and thanks for picking
up SPI.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-02-03 22:15 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <083DF309106F364B939360100EC290F805C4BF1E97@eu1rdcrdc1wx030.exi.nxp.com>
2010-01-22 12:56 ` [spi-devel-general] PATCH [1/1] SPI: AMBA_PL022: Limit TX FIFO fills based on current RX FIFO used Linus Walleij
2010-02-03 17:48   ` Grant Likely
2010-02-03 22:15     ` Linus Walleij

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).