Hi Gerhard,
On Tue, Dec 31, 2013 at 01:34:25PM +0100, Gerhard Sittig wrote:
> On Thu, Dec 26, 2013 at 22:34 +0200, Baruch Siach wrote:
> > That's what I meant. The "dummy-cs" should be an internal
> > chip-select that does not control any slave signal. [ ... ]
>
> Ah, nevermind then, I simply misunderstood. :)
Thinking about it again I think that "dummy-cs" is not a good name. Maybe
"disconnected-cs" would be better. This is the actual hardware level
description of the chip-select, rather than software level use as dummy value.
[...]
> So the introduction of another dummy-cs property might be
> appropriate given the observed behaviour of the hardware.
> Alternatively one might just pick an arbitrary internal CS number
> at runtime (probably the highest internal number, i.e. the last
> one), which should not be a problem as long as this behaviour is
> documented -- GPIOs then can get used for this CS number and all
> numbers above, so no functionality is missing. Mind that this
> workaround then is a feature of the Linux driver, and not the DT
> binding.
Choosing an arbitrary chip-select number is dangerous. You might damage the
hardware by choosing wrong. I don't think that relying on documentation
(where?) is reasonable in this case.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
