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

[Chris Ruehl <chris.ruehl-CR359r9tUDPXPF5Rlphj1Q@public.gmane.org>]

On Wednesday, June 01, 2016 02:54 PM, Sascha Hauer wrote:
> On Wed, Jun 01, 2016 at 12:50:28PM +0800, Chris Ruehl wrote:
>> 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