From: Chris Ruehl <chris.ruehl-CR359r9tUDPXPF5Rlphj1Q@public.gmane.org> To: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, anton.bondarenko.sama-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org Subject: Re: [PATCH] spi-imx: imx6q add single burst transfer support Date: Wed, 1 Jun 2016 15:09:13 +0800 [thread overview] Message-ID: <574E8A19.email@example.com> (raw) In-Reply-To: <20160601065437.GI31666-bIcnvbaLZ9MEGnE8C9+IrQ@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.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
next prev 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] ` <1464756628-25463-1-git-send-email-chris.ruehl-CR359r9tUDPXPF5Rlphj1Q@public.gmane.org> 2016-06-01 5:06 ` Chris Ruehl 2016-06-01 6:54 ` Sascha Hauer [not found] ` <20160601065437.GI31666-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2016-06-01 7:09 ` Chris Ruehl [this message] [not found] ` <574E8A19.3020603-CR359r9tUDPXPF5Rlphj1Q@public.gmane.org> 2016-06-01 14:32 ` Mark Brown [not found] ` <20160601143213.GA2282-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=574E8A19.firstname.lastname@example.org \ --email@example.com \ --cc=anton.bondarenko.sama-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \ --cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \ --subject='Re: [PATCH] spi-imx: imx6q add single burst transfer support' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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.