On Mon, Mar 31, 2014 at 09:34:23AM +0200, Gerhard Sittig wrote: > On Sun, 2014-03-30 at 00:30 +0000, Mark Brown wrote: > > On Sat, Mar 29, 2014 at 04:09:10PM +0100, Gerhard Sittig wrote: > > That's what it's intended to do, yes (and what a bunch of drivers were > > doing). > Turns out I was wrong. CS gets deasserted if the caller > requested it (did not request to keep it asserted) _or_ if > transmission failed. CS only remains asserted if the caller > wanted it, _and_ transmission succeeded. > This is what the implementation does, and what the documentation > suggests. So it's good. I just wanted to correct my wrong > interpretation of the code, should somebody look at archives. Oh, sorry - I'd have said if I'd realised that was the bit you were trying to clarify. > > Well, the thing is that for hardware that can't control /CS from > > software so anything using it between transfers can't rely on it > > happening at all. Within a transfer you can always paper this over > > since there's full visibility of what's going to happen but that's > > not possible over transfers. > What I meant was that even those setups which do control CS from > software might not be able to "late deassert" a previously kept > CS signal upon new selection of another slave. Think of an array > of GPIO backed CS signals, asserting one of them won't change the > others' current signal. I don't understand why a GPIO based system would have trouble there? That's the simplest case. > The documentation might assume the specific behaviour of an > individual controller or CS decoding approach that just does not > apply in general. It's not a problem in the implementation, but > the documentation might need to get extended to become less > permissive. I prepared something along these lines (yet to get > sent). No, it's a problem in the implementation - the idea is that the controller is meant to deassert /CS if it was left asserted and another device needs to be selected. > > It could be I guess, though to be honest I've never been convinced that > > supporting set_cs on the final transfer is a sane idea in the first > > place - my guess is that it's actually going to cost more on average to > > implement it (what with remembering to deassert if another device is > > selected and so on) than just unconditionally disabling /CS. > The early decision of what CS should be after the transfer is not > specific to the last transfer and to keeping CS asserted after > the complete message. It applies to any transfer within a > message that might want to deassert CS. So it applies to those > intermediate transfers which want to pulse CS, as well as to the > last transfer in the regular case of deasserting CS after the > message. My point is that hardware limitations may make it impossible to implement the ability to leave /CS asserted outside of messages but within messages we can always fiddle things. > > Another thread would've been helpful - I was reading it thinking it was > > going to explain the poor performance! > In the MUA you will see that the performance and the CS semantics > are two separate subthreads that both are spawned from the patch > which switches MPC512x to the common message transmission > routine. I broke the thread for you, to not have the CS > semantics discussion for the SPI core within the MPC512x patch > feedback in trackers. Hope it helps. Right, but the reason it was confusing was that the topic had changed without the thread changing.
Attachment:
signature.asc
Description: Digital signature
