On Wednesday 20 February 2008, Haavard Skinnemoen wrote:
> >
> > Unfortunately it did not work. The clock state did not change by
> > writing MR register.
>
> Ok, thanks for testing.
>
> In that case, I think the best fix is to let NPCS0 stay selected
> permanently in MR and overwrite CSR0
On Wednesday 20 February 2008, Atsushi Nemoto wrote:
> > David, do you want me to pass on the patch with my signoff or just ask
> > Andrew to add my Acked-by to the patch already in mm?
>
> The patch in mm also lacks my Signed-off line. I had thought Andrew
> never take a patch without
On Wed, 20 Feb 2008 10:34:46 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
wrote:
> In that case, I think the best fix is to let NPCS0 stay selected
> permanently in MR and overwrite CSR0 with to the new slave's settings
> before asserting CS. But that's a more complicated change, and I don't
>
On Wed, 20 Feb 2008 14:21:09 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Feb 2008 15:31:58 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
> wrote:
> > > Anyway, I will try your patch in a few days.
> >
> > Ok, thanks. If it works, that would be great, but given your
> >
On Wed, 20 Feb 2008 14:21:09 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
On Mon, 18 Feb 2008 15:31:58 +0100, Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
Anyway, I will try your patch in a few days.
Ok, thanks. If it works, that would be great, but given your
description above
On Wed, 20 Feb 2008 10:34:46 +0100, Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
In that case, I think the best fix is to let NPCS0 stay selected
permanently in MR and overwrite CSR0 with to the new slave's settings
before asserting CS. But that's a more complicated change, and I don't
know
On Wednesday 20 February 2008, Haavard Skinnemoen wrote:
Unfortunately it did not work. The clock state did not change by
writing MR register.
Ok, thanks for testing.
In that case, I think the best fix is to let NPCS0 stay selected
permanently in MR and overwrite CSR0 with to the
On Wednesday 20 February 2008, Atsushi Nemoto wrote:
David, do you want me to pass on the patch with my signoff or just ask
Andrew to add my Acked-by to the patch already in mm?
The patch in mm also lacks my Signed-off line. I had thought Andrew
never take a patch without Signed-off line
On Mon, 18 Feb 2008 15:31:58 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
wrote:
> > Anyway, I will try your patch in a few days.
>
> Ok, thanks. If it works, that would be great, but given your
> description above I'm not sure if I dare hope for it.
Unfortunately it did not work. The clock
On Mon, 18 Feb 2008 23:49:18 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
wrote:
> > > CLK __|~|___|~~~|___|~~~|___|~~~|___
> >
> > ... and at T1 CPOL is changed?? That's wrong. There should
> > never be a partial clock period while a chipselect is active.
> > While
On Mon, 18 Feb 2008 23:49:18 +0100, Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
CLK __|~|___|~~~|___|~~~|___|~~~|___
... and at T1 CPOL is changed?? That's wrong. There should
never be a partial clock period while a chipselect is active.
While it's inactive,
On Mon, 18 Feb 2008 15:31:58 +0100, Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
Anyway, I will try your patch in a few days.
Ok, thanks. If it works, that would be great, but given your
description above I'm not sure if I dare hope for it.
Unfortunately it did not work. The clock state
On Mon, 18 Feb 2008 11:57:56 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 18 February 2008, Atsushi Nemoto wrote:
> > IIRC the clock state follows
> > CSRn.CPOL just before the real transfer.
>
> No ... clock state should be valid *before* chipselect goes
> active. So I'm
On Monday 18 February 2008, Atsushi Nemoto wrote:
>IIRC the clock state follows
> CSRn.CPOL just before the real transfer.
No ... clock state should be valid *before* chipselect goes
active. So I'm thinking the patch from Haavard is likely
the right change.
> Like this (previous
On Mon, 18 Feb 2008 23:12:43 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> T0-T1 was relatively longer then T1-T2. I suppose T1 is not the
> point of updating MR register, but the point of starting DMA transfer.
Aw. I see.
> Anyway, I will try your patch in a few days.
Ok, thanks.
On Mon, 18 Feb 2008 12:42:37 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
wrote:
> > Here is my quick workaround for this problem. It makes all CSRn.CPOL
> > match for the transfer before activating chipselect. I'm not quite
> > sure my analysis is correct, and there might be better solution.
On Sat, 16 Feb 2008 22:32:52 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> Here is my quick workaround for this problem. It makes all CSRn.CPOL
> match for the transfer before activating chipselect. I'm not quite
> sure my analysis is correct, and there might be better solution.
>
On Sat, 16 Feb 2008 22:32:52 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
Here is my quick workaround for this problem. It makes all CSRn.CPOL
match for the transfer before activating chipselect. I'm not quite
sure my analysis is correct, and there might be better solution.
Could you
On Mon, 18 Feb 2008 12:42:37 +0100, Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
Here is my quick workaround for this problem. It makes all CSRn.CPOL
match for the transfer before activating chipselect. I'm not quite
sure my analysis is correct, and there might be better solution.
Could
On Mon, 18 Feb 2008 23:12:43 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
T0-T1 was relatively longer then T1-T2. I suppose T1 is not the
point of updating MR register, but the point of starting DMA transfer.
Aw. I see.
Anyway, I will try your patch in a few days.
Ok, thanks. If it
On Monday 18 February 2008, Atsushi Nemoto wrote:
IIRC the clock state follows
CSRn.CPOL just before the real transfer.
No ... clock state should be valid *before* chipselect goes
active. So I'm thinking the patch from Haavard is likely
the right change.
Like this (previous transfer
On Mon, 18 Feb 2008 11:57:56 -0800
David Brownell [EMAIL PROTECTED] wrote:
On Monday 18 February 2008, Atsushi Nemoto wrote:
IIRC the clock state follows
CSRn.CPOL just before the real transfer.
No ... clock state should be valid *before* chipselect goes
active. So I'm thinking the
I found that atmel_spi driver does not initialize clock polarity
correctly (except for at91rm9200 CS0 channel) in some case.
The atmel_spi driver uses gpio-controlled chipselect. OTOH spi clock
signal is controlled by CSRn.CPOL bit, but this register controls
clock signal correctly only in 'real
I found that atmel_spi driver does not initialize clock polarity
correctly (except for at91rm9200 CS0 channel) in some case.
The atmel_spi driver uses gpio-controlled chipselect. OTOH spi clock
signal is controlled by CSRn.CPOL bit, but this register controls
clock signal correctly only in 'real
24 matches
Mail list logo
