the
> board.
>
> Signed-off-by: Mika Westerberg
> Acked-by: H Hartley Sweeten
Acked-by: Martin Guy
--
___
spi-devel-general mailing list
spi-devel-general@lis
On 5/9/10, Mika Westerberg wrote:
> On Sat, May 08, 2010 at 06:32:47PM +0100, Martin Guy wrote:
> > On 5/6/10, Mika Westerberg wrote:
> > > This patch adds an SPI master driver for the Cirrus EP93xx SPI
> controller found
> > > in EP93xx chips.
>
> >
On 5/8/10, Martin Guy wrote:
>I attach the board setup patches I had working with Sim.One v4
M
--
___
spi-devel-general mailing list
spi-devel-gene
On 5/6/10, Mika Westerberg wrote:
> This patch adds an SPI master driver for the Cirrus EP93xx SPI controller
> found
> in EP93xx chips.
Hi
I'm confused by the change in this version of the structure of the
board setup code.
Can you post example patches for the board definitions of the
ts
On 4/25/10, H Hartley Sweeten wrote:
> During the 512+2+1 message that is sent when the mmc_spi driver is
> doing a block read, the 512 byte transfer goes like this:
>
> 1) 8 writes, prime the tx fifo
> SFRMOUT asserts when the first bit of the first byte starts
> transmitting
>
On 4/25/10, H Hartley Sweeten wrote:
> > - /* clear the interrupt */
> > - ep93xx_spi_write_u8(espi, SSPICR, 0);
> >
> > /*
> > * If we got ROR (receive overrun) interrupt we know that
> something is
> > * wrong. Just abort the message.
> > */
Sorry about the incomplete message. Finger trouble.
On 4/25/10, Martin Guy wrote:
...
> SFRMOUT will have gone high:
> if (espi->tx >0 && espi->tx < t->len
&& !(ep93xx_spi_read_u16(espi, SSPSR) & SSPSR_BSY)) {
>
On 4/24/10, H Hartley Sweeten wrote:
> On Friday, April 23, 2010 10:24 AM, H Hartley Sweeten wrote:
> > I was able to hack your driver to keep the continuous transfer going in a
> > multi-transaction message.
> I modified my hack a bit so that the message transactions are dumped at
> the end
Hi, another little fix:
EP93xx User's Manual -> Synchronous Serial Port -> Registers
SSPIIR description:
"Read Only
Note: A write to this register clears the receive overrun interrupt,
regardless of the data
value written."
It doesn't affect the RIS/TIS ones, which are caused by the state
On 4/22/10, H Hartley Sweeten wrote:
> > Further, on a suspicion about the silliness of the per-transfer
> > bits_per_word being checked right down the bottom of the lowest lever
> > byte-read/writing routine instead of once per transfer, I split
> > ep93xx_spi_read and _write into 8 and 16-bi
On 4/22/10, H Hartley Sweeten wrote:
> First, every spi transaction, including a single byte transfer, is
> going to generate at least two interrupts. One when the interrupts
> are first enabled because the TX FIFO is empty. And a second when
> that byte has been transferred and the TX FIFO
On 4/22/10, H Hartley Sweeten wrote:
> I have added some debug messages to the driver trying to figure out
> how to chain the transfers in a message together in order to keep
> the SFRM signal asserted for the entire message. I still haven't
> worked out a good solution but I did notice somet
On 4/21/10, H Hartley Sweeten wrote:
> On Tuesday, April 20, 2010 4:55 PM, Martin Guy wrote:
> > On 4/20/10, H Hartley Sweeten wrote:
> >> So, since each transfer does a wait_for_completion, all the data is
> transmitted
> >> which causes the SFRMOUT pin to go
On 4/20/10, H Hartley Sweeten wrote:
> On Tuesday, April 20, 2010 8:12 AM, Mika Westerberg wrote:
> > This patch adds an SPI master driver for the Cirrus EP93xx SPI controller
> > found
> > in EP93xx chips (EP9301, EP9302, EP9307, EP9312 and EP9315).
>
> I discovered one gotcha with this driver
On 4/19/10, Grant Likely wrote:
> >> >> > + for (cpsr = 2; cpsr <= 254; cpsr += 2) {
> >> >> > + for (scr = 0; scr <= 255; scr++) {
> >> >>
> >> >> Non-deterministic.
> > Eh? Some new meaning of "non-deterministic" that I wasn'f familiar with? :)
> >
> > Yes, it does
On 4/19/10, Grant Likely wrote:
> >> > + /* read all received data */
> >> > + while ((ep93xx_spi_read_u8(espi, SSPSR) & SSPSR_RNE) &&
> >> > + espi->rx < t->len) {
> >> > + ep93xx_do_read(espi, t);
> >> > + espi->fifo_level--;
> >> > +
On 4/19/10, Grant Likely wrote:
> >> > +static int ep93xx_spi_flush(const struct ep93xx_spi *espi, unsigned
> long msecs)
> >> > +{
> >> > + unsigned long timeout = jiffies + msecs_to_jiffies(msecs);
> >> > +
> >> > + while (ep93xx_spi_read_u16(espi, SSPSR) & SSPSR_RNE) {
> >> >
(sorry for the duplicate, Mika, I forgot to include the list)
On 4/17/10, Mika Westerberg wrote:
> However, I'm not sure what you mean by limited only to built-in GPIOs?
> Currently
> the driver does:
>
> info->cs_control(spi->chip_select, value, info->data);
>
> when it wants to asse
and
- if (espi->tx == 0 && espi->rx == 0)
- espi->fifo_level = 0;
since it's always created as 0 and is always reset to 0 by the end of a transfer
and if you like
/* is transfer finished? */
- if (espi->tx == t->len && espi->rx == t->len) {
+ if
On 4/10/10, Mika Westerberg wrote:
> Can you try following with your devices?
Woo, nice one!
Same CPU usage (~57%) same throughput (315kb/s) and it's much more
elegant. :) Just using repeated interrupts to handle the last 4 words
instead of the nasty busy-wait loops seems fairer to other interru
Oops, I mean
- unsigned n; /* Number of bytes to send to the TX FIFO */
+ unsigned n; /* Number of words to send to the TX FIFO */
and
- n = t->len - espi->tx; /* Total number of bytes waiting to be
-* sent to the TX FIFO for this transf
Hi again
I've looked at this again, and v2 does send every complete block (up
to 512 bytes) before it returns from an interrupt. If you factor out
all the conditions that always have constant values, and those that
can never happen, from the central loop:
/*
* Write as long as TX
On 4/6/10, Mika Westerberg wrote:
> I only have one ep9302 board and 2 SPI devices
If you'd like one of the MMC-only boards to test on, I can ship it to
you - please provide smail mail address by private mail if that would
be welcome
> > Lastly, what is the meaning of conditional operator(s) i
On 4/6/10, Mika Westerberg wrote:
> On Thu, Apr 01, 2010 at 01:15:20AM +0100, Martin Guy wrote:
> > I have another question: like the Cirrus driver, this takes 100% CPU
> > doing busy wait for the current transfer to complete.
>
> I tried to find out whether the driver d
On 3/25/10, Mika Westerberg wrote:
> > > This patch adds an SPI master driver for the Cirrus EP93xx SPI
> controller found
> > > in EP93xx chips (EP9301, EP9302, EP9307, EP9312 and EP9315).
> > >
> > > Driver currently supports only interrupt driven mode but in future we
> may add
> > >
On 3/25/10, H Hartley Sweeten wrote:
> For parts 1 and 3.
>
> I tried testing them in my setup with the mmc_spi.c and sst25l.c drivers.
> Both
> did not work. For some reason the data read is always either 0x00 or 0xff.
>
> I will try to get some time this week/weekend to look into this.
I
On 3/18/10, Mika Westerberg wrote:
> This patch adds an SPI master driver for the Cirrus EP93xx SPI controller
> found
> in EP93xx chips (EP9301, EP9302, EP9307, EP9312 and EP9315).
>
> Driver currently supports only interrupt driven mode but in future we may add
> polling mode support as well
On 3/16/10, H Hartley Sweeten wrote:
> On Monday, March 15, 2010 11:06 AM, H Hartley Sweeten wrote:
> > On Monday, March 15, 2010 9:26 AM, Mika Westerberg wrote:
> >> + * %EP93XX_CHIP_REV_A
> >> + * %EP93XX_CHIP_REV_B
> >> + * %EP93XX_CHIP_REV_C
> >> + * %EP93XX_CHIP_REV_D0
> >> + * %EP93XX_
Hi Mika, thanks, great work
On 3/15/10, Mika Westerberg wrote:
> Added a new function: ep93xx_chip_revision() which reads chip revision from
> the
> sysconfig register.
>
> + * %EP93XX_CHIP_REV_D0
> + * %EP93XX_CHIP_REV_D1
> + * %EP93XX_CHIP_REV_E0
> + * %EP93XX_CHIP_REV_E1
> + * %EP93XX_C
29 matches
Mail list logo
