Date: Mon, 18 Feb 2008 23:49:18 +0100
From: Haavard Skinnemoen <hskinnemoen@atmel.com>
To: David Brownell <david-b@pacbell.net>
Cc: spi-devel-general@lists.sourceforge.net,
       Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-kernel@vger.kernel.org
Subject: Re: [spi-devel-general] atmel_spi clock polarity
Message-ID: <20080218234918.3d09022a@siona>
In-Reply-To: <200802181157.57299.david-b@pacbell.net>
References: <20080216.223252.25909396.anemo@mba.ocn.ne.jp>
	<20080218124237.0b5f701c@dhcp-252-066.norway.atmel.com>
	<20080218.231243.41197917.anemo@mba.ocn.ne.jp>
	<200802181157.57299.david-b@pacbell.net>
Organization: Atmel
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1564
Lines: 42

On Mon, 18 Feb 2008 11:57:56 -0800
David Brownell <david-b@pacbell.net> 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 patch from Haavard is likely
> the right change.

Hopefully it is...

> > 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, sure -- no chip should care.

...but what I'm afraid of is that since we're using GPIO chipselects,
the controller may _think_ that no chip is selected and change the
clock polarity just before it would pull the chipselect low if we were
using automatic chipselects...

If that's the case, it would be a bit strange if it actually helped to
initialize all the CSRn registers, but it would also offer us a nice
workaround...

Atsushi, do you by any chance have debugging enabled? That would
explain the long delay from CS activation to the change of clock
polarity. Compared to printk() the DMA setup takes almost no time at
all.

If you can confirm that my patch helps, I think that's the one we want
in mainline.

Haavard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/