Hi,
I just answer to this last message as it seems that continuous
transfer is really not a 100% solid solution; It makes things more
complicated than need to be and benefit for that is probably not
worth the additional complexity. Feel free to disagree :)
On Sun, Apr 25, 2010 at 03:25:16PM
On Sun, Apr 25, 2010 at 03:25:16PM -0500, H Hartley Sweeten wrote:
With a slow enough clock you can probably get to a point where SFRMOUT
will stay deasserted during the entire 512 byte transfer. But it would
still de-assert during the switch to the next transfer in the message.
Regardless,
On Sun, Apr 25, 2010 at 02:55:08PM -0500, H Hartley Sweeten wrote:
On Saturday, April 24, 2010 11:15 AM, Martin Guy wrote:
static irqreturn_t ep93xx_spi_interrupt(int irq, void *dev_id)
{
...
if (!(irq_status (SSPIIR_RORIS | SSPIIR_TIS | SSPIIR_RIS)))
return
On 4/25/10, H Hartley Sweeten hartl...@visionengravers.com 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.
On 4/25/10, H Hartley Sweeten hartl...@visionengravers.com 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
On 4/24/10, H Hartley Sweeten hartl...@visionengravers.com 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
Sorry about the incomplete message. Finger trouble.
On 4/25/10, Martin Guy martinw...@gmail.com wrote:
...
SFRMOUT will have gone high:
if (espi-tx 0 espi-tx t-len
!(ep93xx_spi_read_u16(espi, SSPSR) SSPSR_BSY)) {
/* More to transmit but device has
On Sunday, April 25, 2010 2:39 AM, Martin Guy wrote:
Sorry about the incomplete message. Finger trouble.
On 4/25/10, Martin Guy martinw...@gmail.com wrote:
...
SFRMOUT will have gone high:
if (espi-tx 0 espi-tx t-len
!(ep93xx_spi_read_u16(espi, SSPSR)
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 of
On Thursday, April 22, 2010 10:20 PM, Mika Westerberg wrote:
On Thu, Apr 22, 2010 at 03:43:24PM -0500, H Hartley Sweeten wrote:
On Thursday, April 22, 2010 10:55 AM, Mika Westerberg wrote:
Could you test this in your setup?
Same results.
OK. thanks for testing.
I hacked your driver to
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. Unfortunately I don't have an easy way to
generate a diff to send the necessary patch. The hack does work with the
sst25l driver.
On 4/22/10, H Hartley Sweeten hartl...@visionengravers.com 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
On 4/22/10, H Hartley Sweeten hartl...@visionengravers.com 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
Martin,
I'm replying to both of your previous messages.
On Thursday, April 22, 2010 7:28 AM, Martin Guy wrote:
On 4/22/10, H Hartley Sweeten hartl...@visionengravers.com wrote:
First, every spi transaction, including a single byte transfer, is
going to generate at least two interrupts. One
On Wed, Apr 21, 2010 at 01:00:56PM -0500, H Hartley Sweeten wrote:
Same results are your v4 driver. But, I think your on the right track.
I think the problem is in the ep93xx_spi_read_write routine. That function
returns 0 as long as there is still data left in the current transfer. The
On 4/22/10, H Hartley Sweeten hartl...@visionengravers.com 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
On Thursday, April 22, 2010 10:55 AM, Mika Westerberg wrote:
On Wed, Apr 21, 2010 at 01:00:56PM -0500, H Hartley Sweeten wrote:
Same results are your v4 driver. But, I think your on the right track.
I think the problem is in the ep93xx_spi_read_write routine. That function
returns 0 as
Mika Westerberg wrote:
On Wed, Apr 21, 2010 at 01:00:56PM -0500, H Hartley Sweeten wrote:
Same results are your v4 driver. But, I think your on the right track.
Thanks for testing.
I think the problem is in the ep93xx_spi_read_write routine. That function
returns 0 as long as there is
On Thu, Apr 22, 2010 at 03:43:24PM -0500, H Hartley Sweeten wrote:
On Thursday, April 22, 2010 10:55 AM, Mika Westerberg wrote:
Could you test this in your setup?
Same results.
OK. thanks for testing.
I hacked your driver to allow me to toggle a gpio when the interrupt routine
starts and
On Tue, Apr 20, 2010 at 05:16:10PM -0500, 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).
Signed-off-by:
On Tue, Apr 20, 2010 at 08:52:26PM -0500, H Hartley Sweeten wrote:
On Tuesday, April 20, 2010 6:10 PM, Martin Guy wrote:
I have noticed on card insertion, the last line of:
mmc0: problem reading switch capabilities, performance might suffer.
mmc0: host does not support reading read-only
On Tue, Apr 20, 2010 at 12:24:26PM -0500, 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).
Signed-off-by:
On Tue, Apr 20, 2010 at 08:52:26PM -0500, H Hartley Sweeten wrote:
On Tuesday, April 20, 2010 6:10 PM, Martin Guy wrote:
Not easily, but it seems a likely cause.
To prevent card deselection mid-message I think we would need to
handle multi-transfer messages by making the start of transfers
On Wed, Apr 21, 2010 at 11:47:13AM -0500, H Hartley Sweeten wrote:
On Wednesday, April 21, 2010 12:16 AM, Mika Westerberg wrote:
I think it is more readable to do:
ep93xx_spi_select_device(espi, msg-spi);
and
ep93xx_spi_deselect_device(espi, msg-spi);
It can be seen from
On Tuesday, April 20, 2010 11:37 PM, Mika Westerberg wrote:
On Tue, Apr 20, 2010 at 05:16:10PM -0500, 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,
On Wednesday, April 21, 2010 3:47 AM, Mika Westerberg wrote:
On Tue, Apr 20, 2010 at 08:52:26PM -0500, H Hartley Sweeten wrote:
On Tuesday, April 20, 2010 6:10 PM, Martin Guy wrote:
Not easily, but it seems a likely cause.
To prevent card deselection mid-message I think we would need to
Mika,
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 something else.
First, every spi transaction,
On Wed, Apr 21, 2010 at 01:00:56PM -0500, H Hartley Sweeten wrote:
Same results are your v4 driver. But, I think your on the right track.
Thanks for testing.
I think the problem is in the ep93xx_spi_read_write routine. That function
returns 0 as long as there is still data left in the
On Wed, Apr 21, 2010 at 09:47:14PM -0500, 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
This patch adds an SPI master driver for the Cirrus EP93xx SPI controller found
in EP93xx chips (EP9301, EP9302, EP9307, EP9312 and EP9315).
Signed-off-by: Mika Westerberg mika.westerb...@iki.fi
---
arch/arm/mach-ep93xx/include/mach/ep93xx_spi.h | 32 +
drivers/spi/Kconfig
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).
Signed-off-by: Mika Westerberg mika.westerb...@iki.fi
Mika,
I'm still looking this over
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).
Signed-off-by: Mika Westerberg mika.westerb...@iki.fi
Mika,
I discovered one gotcha with
On 4/20/10, H Hartley Sweeten hartl...@visionengravers.com 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
On Tuesday, April 20, 2010 4:55 PM, Martin Guy wrote:
On 4/20/10, H Hartley Sweeten hartl...@visionengravers.com 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,
On 4/21/10, H Hartley Sweeten hartl...@visionengravers.com wrote:
On Tuesday, April 20, 2010 4:55 PM, Martin Guy wrote:
On 4/20/10, H Hartley Sweeten hartl...@visionengravers.com wrote:
So, since each transfer does a wait_for_completion, all the data is
transmitted
which causes the
On Tuesday, April 20, 2010 6:10 PM, Martin Guy wrote:
On 4/21/10, H Hartley Sweeten hartl...@visionengravers.com wrote:
On Tuesday, April 20, 2010 4:55 PM, Martin Guy wrote:
On 4/20/10, H Hartley Sweeten hartl...@visionengravers.com wrote:
So, since each transfer does a wait_for_completion,
36 matches
Mail list logo
