All of
 help / color / mirror / Atom feed
From: Chris Ruehl <>
To: Sascha Hauer <>
Subject: Re: [PATCH] spi-imx: imx6q add single burst transfer support
Date: Wed, 1 Jun 2016 15:09:13 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.


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

To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to
More majordomo info at

  parent reply	other threads:[~2016-06-01  7:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01  4:50 Chris Ruehl
     [not found] ` <>
2016-06-01  5:06   ` Chris Ruehl
2016-06-01  6:54   ` Sascha Hauer
     [not found]     ` <>
2016-06-01  7:09       ` Chris Ruehl [this message]
     [not found]         ` <>
2016-06-01 14:32           ` Mark Brown
     [not found]             ` <>
2016-06-02  1:27               ` Chris Ruehl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] spi-imx: imx6q add single burst transfer support' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.