On Monday, April 26, 2010 7:36 AM, Martin Guy wrote:
> 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
On Monday, April 26, 2010 3:03 AM, Mika Westerberg wrote:
>
> 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 complex
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.
> > */
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)))
> >
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.
>
> Regardl
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 -0500
On Sunday, April 25, 2010 2:39 AM, Martin Guy wrote:
>
> 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_BS
On Saturday, April 24, 2010 11:15 AM, Martin Guy wrote:
> 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 wri
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)) {
> /* More to transmit but device has gone idl
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 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 drive
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 you
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
> star
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 t
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
>> ret
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 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.
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 wrote:
>> First, every spi transaction, including a single byte transfer, is
>> going to generate at least two interrupts. One when the interrupts
>>
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 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 be
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 cur
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, i
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 t
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 c
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);
> >
> >
On Wednesday, April 21, 2010 12:16 AM, Mika Westerberg wrote:
>>
>> These two functions can be combined.
>>
>> /**
>> * ep93xx_spi_chip_select() - select/deselect a given SPI device
>> * @espi: ep93xx SPI controller struct
>> * @spi: SPI device to select
>> * @assert: flag to assert the chip
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 tran
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-o
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 re
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).
> >
> > Sign
On Tuesday, April 20, 2010 6:10 PM, Martin Guy wrote:
> 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 caus
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 HIGH between each transfer in th
On Tuesday, April 20, 2010 5:11 PM, H Hartley Sweeten wrote:
> On Tuesday, April 20, 2010 4:55 PM, Martin Guy wrote:
>> On 4/20/10, H Hartley Sweeten wrote:
[snip]
>>> Is there anyway to keep the transfers going in a muiltipart message?
>>
>> I just changed the SPI mode selection, which is in th
On Tuesday, April 20, 2010 4:55 PM, Martin Guy wrote:
> 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 an
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 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,
I discovered one gotcha with this driver. Be
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,
I'm still looking this over but I have one quic
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
---
arch/arm/mach-ep93xx/include/mach/ep93xx_spi.h | 32 +
drivers/spi/Kconfig| 11 +
driver
41 matches
Mail list logo
