Re: [PATCH] spi-imx: imx6q add single burst transfer support

On Wednesday, June 01, 2016 02:54 PM, Sascha Hauer wrote:

On Wed, Jun 01, 2016 at 12:50:28PM +0800, Chris Ruehl wrote:

quoted

The patch add support for single burst transfer where chipselect will
hold active until transfer completes with a limit to 2^7 words transferred.
The single-burst-mode need set the burstlength in ECSPI_CONREG.BURST_LENGTH
and clear the ecspi channel related ss_ctl flag in ECSPI_CONFIGREG.SS_CTL.

The single-burst-mode is disabled by default. The activation from spidev
is implemented by set bit0 of the xfer.speed_hz, which don't break anything
in the mx51_ecspi_clkdiv() function.

xfer[0].speed_hz = 2000000 | 0x1; /* enable single burst mode with 1hz */

Erm, no. This is not acceptable in many ways. First of all the SPI API
between the kernel and userspace is driver agnostic. There is simply no
place for passing driver specific quirks from userspace to the spi-imx
driver. Then there is no API change needed because the way SPI
messages should be translated to the wire is well defined, the spi-imx
driver is just doing it wrong in this case which might be worth fixing.
This could be done without passing a "do it right" flag to the driver.

I expected AND except the "NO" on this!
But the userspace interface (xfer) does not have anything else then tx,rx-buf cs_change delay.. to carry infos forward to the driver.

On the other hand it's useful to have the 'native cs working' to give the
hardware manufactures a hand to fixup their stuff! And play with the
chips features. Lot of things going wrong with hardware cs, and its good
to have a fallback to GPIO chip selects when the native chip fails.

My opinion, support both ways and don't give the chip guys an excuse to
give us rubbish.

As noted in my response to the previous patch, I don't think we need a
fix for this at all, because we can always use GPIO chip selects which
works reliably not only in this case, but also in other cases where the
controller driven chipselect falls apart.

IMO there is only a single reason to keep controller driven chip select
support at all: On i.MX31 there is one dedicated chip select which can't
be configured as GPIO.

Sascha

Thank you, its worth have your opinion on this.

Chris


-- 
GTSYS Limited RFID Technology
9/F, Unit E, R07, Kwai Shing Industrial Building Phase 2,
42-46 Tai Lin Pai Road, Kwai Chung, N.T., Hong Kong
Tel (852) 9079 9521

Disclaimer: http://www.gtsys.com.hk/email/classified.html
--
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