Dear Alan,
have both functions. The sort of devices we are talking typically
communicate over I2C or SPI buses though drivers for rs232 devices etc are
definitely on the cards. Basically we are interested in devices where direct
memory mapped access is not possible.
We have I2C and SPI
Packet data read from the RX buffer the when the RSV is at the end of the RX
buffer does not warp around. This causes packet loss, as the actual data is
never read. Fix this by calculating the right packet data location.
Thanks to Shachar Shemesh for suggesting the fix.
Signed-off-by: Baruch
Joakim == Joakim Tjernlund [EMAIL PROTECTED] writes:
Hi,
So long as you do the polling with IRQs enabled, I'd keep it
simple and just always poll. YMMV of course, but most devices
seem to prefer more like 10 MHz clocks than 1 MHz ones.
Joakim Sorry for the delay, forgot about this.
On Tuesday 02 December 2008, Joakim Tjernlund wrote:
The question is if the poll code I sent is good, even for longer
transfers?
Perhaps some sort of LOWLAT flag could be used for transfers that really
need them?
So long as you do the polling with IRQs enabled, I'd keep it
-Original Message-
From: Peter Korsgaard [mailto:[EMAIL PROTECTED] On Behalf Of Peter Korsgaard
Sent: den 2 december 2008 17:24
To: [EMAIL PROTECTED]
Cc: David Brownell; spi-devel-general@lists.sourceforge.net
Subject: Re: [spi-devel-general] Performance of spi_mpc83xx.c sucks.
On Tuesday 02 December 2008, Joakim Tjernlund wrote:
Oh, so the kernel thread actually gets pre-empted(is that a word?)
once it has consumed its time slice?
And potentially at other times. When an IRQ arrives and
is handled, that's a form of non-task preemption. And
when that IRQ enables a
On Tuesday 02 December 2008, Joakim Tjernlund wrote:
I've not observed polling from a task context to starve anyone,
when done sanely. The opposite is true for doing an order of
magnitude more instructions in IRQ context ...
When playing with this the app developer complained that the
On Tuesday 02 December 2008, Baruch Siach wrote:
Packet data read from the RX buffer the when the RSV is at the end of the RX
buffer does not warp around. This causes packet loss, as the actual data is
never read. Fix this by calculating the right packet data location.
Thanks to Shachar
HI David,
On Tue, Dec 02, 2008 at 02:44:02PM -0800, David Brownell wrote:
On Tuesday 02 December 2008, Baruch Siach wrote:
Our on-chip SPI master is the Synopsys DesignWare one. I wrote a driver
for this SPI master. This driver is somewhat usable, but not complete yet.
I'm now in the
