From: David Brownell <david-b@pacbell.net>
To: Vitaly Wool <vwool@ru.mvista.com>
Subject: Re: [PATCH 2.6-git] SPI: add set_clock() to bitbang
Date: Thu, 22 Dec 2005 16:37:07 -0800
User-Agent: KMail/1.7.1
Cc: linux-kernel@vger.kernel.org, spi-devel-general@sourceforge.net
References: <20051222180449.4335a8e6.vwool@ru.mvista.com> <200512221337.39305.david-b@pacbell.net> <43AB1DB7.3080505@ru.mvista.com>
In-Reply-To: <43AB1DB7.3080505@ru.mvista.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200512221637.07895.david-b@pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1076
Lines: 26


> No, suppose there're two devices behind the same SPI bus that have 
> different clock constraints. As active SPI device change may well happen 
> when each new message is processed, we'll need to set up clocks again 
> for each message. Right?

Clock is coupled to chipselect/device.  When the bus controller
switches to the other device, it updates the clock accordingly.

How exactly that's done is system-specific.  Many controllers
just have a register per chipselect, listing stuff like SPI mode,
clock divisor, and word size.  So switching to that chipselect
kicks those in automatically ... devices ignore the clock unless
they've been selected.

So it's like I said earlier.  And going to a new message will
normally involve a new chipselect, yes ... but maybe not, there's
that hint available to avoid the switching.


-
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/