All of lore.kernel.org
 help / color / mirror / Atom feed
From: Knut Wohlrab <knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
To: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
Cc: <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Vladimir Zapolskiy
	<vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>,
	Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] spi: imx: only do necessary changes to ECSPIx_CONFIGREG
Date: Thu, 17 Mar 2016 16:00:30 +0100	[thread overview]
Message-ID: <56EAC68E.4040103@de.bosch.com> (raw)
In-Reply-To: <20160317075911.GV30994-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Am 03/17/2016 um 08:59 AM schrieb Sascha Hauer:
> On Tue, Mar 15, 2016 at 02:24:36PM +0100, Dirk Behme wrote:
>> > From: Knut Wohlrab <knut.wohlrab-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
>> > 
>> > If the SPI chip select (CS) for a dedicated channel is done manually by
>> > the used higher device driver, the CS may be active while writing to
>> > ECSPIx_CONFIGREG. To prevent unwanted clock edges when selecting
>> > the clock mode,  only do the necessary changes to the i.MX SPI
>> > configuration register and leave not selected channels untouched.
>> > 
>> > To prevent unwanted clock edges on first use, an empty dummy
>> > transmission shall be done by the initialization procedure of the device
>> > driver of this channel. This will set the clock mode to the correct state.
> The patch does the right thing, so:
> 
> Acked-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> 
> Only the above sentence is not clear to me. By device driver you mean
> the SPI slave driver (flash, PMIC), right? Isn't this what
> bitbang->setup_transfer(spi, NULL), called from spi_bitbang_setup() already
> does? spi_bitbang_setup should be called while adding a new SPI slave
> device and the setup_transfer with an empty message should setup the
> config register correctly without involing the slave device driver.
> 
> Sascha
> 
"Higher device driver" is a "historical" protocol stack to unify our
data transfer via several physical interfaces, here SPI. This driver
requires own control to the CS signal to start data transfer only if CS
is acknowledged by the external SPI slave device via GPIO/IRQ. Therefore
we can not rely on iMX6 SPI controller IP or kernel driver CS/RDY
functionality. The CS signal is active before the SPI driver is involved
and if the SPI driver changes the clock polarity, the unwanted clock
edge is destroying the data transfer.

Thanks and regards

Knut
--
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

WARNING: multiple messages have this Message-ID (diff)
From: knut.wohlrab@de.bosch.com (Knut Wohlrab)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] spi: imx: only do necessary changes to ECSPIx_CONFIGREG
Date: Thu, 17 Mar 2016 16:00:30 +0100	[thread overview]
Message-ID: <56EAC68E.4040103@de.bosch.com> (raw)
In-Reply-To: <20160317075911.GV30994@pengutronix.de>

Am 03/17/2016 um 08:59 AM schrieb Sascha Hauer:
> On Tue, Mar 15, 2016 at 02:24:36PM +0100, Dirk Behme wrote:
>> > From: Knut Wohlrab <knut.wohlrab@de.bosch.com>
>> > 
>> > If the SPI chip select (CS) for a dedicated channel is done manually by
>> > the used higher device driver, the CS may be active while writing to
>> > ECSPIx_CONFIGREG. To prevent unwanted clock edges when selecting
>> > the clock mode,  only do the necessary changes to the i.MX SPI
>> > configuration register and leave not selected channels untouched.
>> > 
>> > To prevent unwanted clock edges on first use, an empty dummy
>> > transmission shall be done by the initialization procedure of the device
>> > driver of this channel. This will set the clock mode to the correct state.
> The patch does the right thing, so:
> 
> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> Only the above sentence is not clear to me. By device driver you mean
> the SPI slave driver (flash, PMIC), right? Isn't this what
> bitbang->setup_transfer(spi, NULL), called from spi_bitbang_setup() already
> does? spi_bitbang_setup should be called while adding a new SPI slave
> device and the setup_transfer with an empty message should setup the
> config register correctly without involing the slave device driver.
> 
> Sascha
> 
"Higher device driver" is a "historical" protocol stack to unify our
data transfer via several physical interfaces, here SPI. This driver
requires own control to the CS signal to start data transfer only if CS
is acknowledged by the external SPI slave device via GPIO/IRQ. Therefore
we can not rely on iMX6 SPI controller IP or kernel driver CS/RDY
functionality. The CS signal is active before the SPI driver is involved
and if the SPI driver changes the clock polarity, the unwanted clock
edge is destroying the data transfer.

Thanks and regards

Knut

  parent reply	other threads:[~2016-03-17 15:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-15 13:24 [PATCH] spi: imx: only do necessary changes to ECSPIx_CONFIGREG Dirk Behme
2016-03-15 13:24 ` Dirk Behme
     [not found] ` <1458048276-31884-1-git-send-email-dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
2016-03-17  7:59   ` Sascha Hauer
2016-03-17  7:59     ` Sascha Hauer
     [not found]     ` <20160317075911.GV30994-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2016-03-17 15:00       ` Knut Wohlrab [this message]
2016-03-17 15:00         ` Knut Wohlrab
2016-03-17 11:45   ` Applied "spi: imx: only do necessary changes to ECSPIx_CONFIGREG" to the spi tree Mark Brown

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=56EAC68E.4040103@de.bosch.com \
    --to=knut.wohlrab-v5te9ogctavwk0htik3j/w@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.