From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Torsten Fleischer <to-fleischer@t-online.de>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: spi_mpc8xxx.c: chip select polarity problem
Date: Mon, 16 Nov 2009 20:10:37 +0300 [thread overview]
Message-ID: <20091116171037.GA26163@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <200911161742.46663.to-fleischer@t-online.de>
On Mon, Nov 16, 2009 at 05:42:46PM +0100, Torsten Fleischer wrote:
> Hi all,
>
> I have 3 devices connected to the SPI bus of the MPC8313. For the Chip Select
> (CS) signals 3 GPIOs of the controller are used. But the driver uses the
> inverse polarity of the CS either during the initialization or at the transfer
> - depending on the setup of the flattened device tree.
>
> Here is what I discovered:
> The driver uses a polarity flag for each CS signal (the alow_flags array).
> These flags are set according to the 'gpios' property of the SPI node of the
> flattened device tree.
> Is it correct that alow_flags[x] = 1 means CSx is active low?
Either way should work. Though, now I tend to I think that
'spi-cs-high' is actually already encoded in the compatible
name. E.g. for device X we always know that the device assumes
CS to be active low, so it has no spi-cs-high.
How chip selects are wired to a device is another matter.
> During the initialization the driver sets the CS to the value of
> alow_flags[x]. I.e. CSx is High if alow_flags[x] = 1 and otherwise Low.
>
> The flags are used in the function mpc8xxx_spi_cs_control() to take care about
> the polarity when setting the appropriate GPIO pin. But the function
> mpc8xxx_spi_chipselect() that calls the mpc8xxx_spi_cs_control() takes also
> care about the polarity of the CS (bool pol = spi->mode & SPI_CS_HIGH).
>
> Lets assume alow_flags[x] = 1 and the property 'spi-cs-high' is not set for
> the SPI device. During initialization the driver sets the chip select signal
> 'x' to High (see of_mpc8xxx_spi_get_chipselects()). This is OK if the chip
> select is active low, because this disables the device on start-up. But during
> the transfer the chip select signal is High and after the transfer is
> completed the signal is set to Low. This is not the intended behavior for an
> active low chip select.
>
> I also tried to set alow_flags[x] = 0 for active low. In this case the
> transfer works, but the initial value for the CS is wrong (Low instead of
> High).
So it might be better to fix up initial value in the platform code?
> The problem seems to be that the polarity is taken into account twice (as
> described above).
Yep. So, today I'd suggest to not use spe-cs-high, even though
I was OK with it before.
> So what would be the better solution: removing the usage of the alow_flags in
> mpc8xxx_spi_cs_control() or the variable 'pol' in mpc8xxx_spi_chipselect()?
Neither. 'pol' is still needed. Don't mix device wiring and the
chip select type. Driver may play active-low/high games with
a device, some drivers pass or clear SPI_CS_HIGH flags by themselves
(e.g. mmc_spi.c), so device-tree don't have to have spi-cs-high
flag specified.
But the wire from a GPIO controller to a SPI device can be inverted,
so you'll have to account that too!
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2009-11-16 17:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-16 16:42 spi_mpc8xxx.c: chip select polarity problem Torsten Fleischer
2009-11-16 17:10 ` Anton Vorontsov [this message]
2009-11-16 18:00 ` Anton Vorontsov
2009-11-17 20:09 ` Torsten Fleischer
2009-11-17 20:22 ` Anton Vorontsov
2009-11-17 23:28 ` Anton Vorontsov
2009-11-18 16:20 ` Torsten Fleischer
2009-11-18 23:29 ` Anton Vorontsov
2009-11-21 8:45 ` Grant Likely
2009-11-21 16:08 ` Torsten Fleischer
2009-11-25 0:33 ` Grant Likely
2009-11-25 20:41 ` Torsten Fleischer
2009-11-25 22:11 ` Grant Likely
2009-11-25 22:11 ` Grant Likely
2009-11-26 12:12 ` Anton Vorontsov
2009-11-26 12:12 ` Anton Vorontsov
2009-11-26 17:27 ` Torsten Fleischer
2009-11-26 18:18 ` Grant Likely
2009-11-26 18:18 ` Grant Likely
2009-11-26 18:16 ` Grant Likely
2009-11-26 18:16 ` Grant Likely
2009-11-26 18:41 ` Anton Vorontsov
2009-11-26 18:50 ` Grant Likely
2009-11-26 18:50 ` Grant Likely
2009-11-26 19:01 ` Anton Vorontsov
2009-11-26 19:01 ` Anton Vorontsov
2009-11-26 19:17 ` Grant Likely
2009-11-26 19:17 ` Grant Likely
2009-12-09 15:49 ` Torsten Fleischer
2009-12-09 17:46 ` Grant Likely
2009-12-09 19:13 ` Torsten Fleischer
2009-12-14 16:54 ` Torsten Fleischer
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=20091116171037.GA26163@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=to-fleischer@t-online.de \
/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.