Re: [PATCH 5/6] dt-bindings: iio: adc: mcp320x: Update for mcp3550/1/3

On Mon, 4 Sep 2017 18:22:21 +0100
Mark Brown [off-list ref] wrote:

On Sun, Sep 03, 2017 at 02:37:49PM +0100, Jonathan Cameron wrote:

quoted

+cc Mark Brown and linux-spi to address question about how to represent
a hardwired chip select.  See below for why I think that is what we should
be representing rather than the fact it puts it in 'continuous mode'.  

There's a good chance that if you just send me mail with a not obviously
related subject line it might get discarded unread, people CC me on lots
of things that are of questionable relevance.

quoted

quoted

quoted

quoted

quoted

+   - microchip,continuous-conversion (boolean):
+                   Only applicable to MCP3550/1/3:  These ADCs have long
+                   conversion times and therefore support "continuous
+                   conversion mode" to allow retrieval of conversions
+                   at any time without observing a delay.  The mode is
+                   enabled by permanently driving CS low, e.g. by wiring
+                   it to ground.    

quoted

hmm.  This is odd.  We probably need to make the SPI subsystem aware of this.
It is possible to ask for exclusive use of an SPI bus and I think we should
be doing this here.  It may be wired low on your board, but it may be wired to  

This sounds like SPI_NO_CS, though it's vanishingly rare for it to be
implemented as there's a lot of ways for it to go wrong electrically -
it's a lot simpler to just have a chip select and minimise the number of
times it gets asserted.

Thanks Mark.  It sounds like we don't actually need it for the driver under
consideration on the particular platform it is being used on.  If it comes
up later, then adding bindings for SPI_NO_CS and adding relevant support
in the driver looks the way to go to me.

Jonathan


--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html