From: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Greg Ungerer <gerg-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
fabio.estevam-3arQi8VN3Tc@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
Subject: Re: [PATCH 0/2] spi: imx: native chip selects and devicetree
Date: Mon, 20 Mar 2017 15:35:40 +0800 [thread overview]
Message-ID: <20170320073538.GC3443@dragon> (raw)
In-Reply-To: <1489726983-17706-1-git-send-email-gerg-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
On Fri, Mar 17, 2017 at 03:03:01PM +1000, Greg Ungerer wrote:
>
> Selecting native chip selects for iMX SPI devices in a devicetree
> configuration does not work. That is the case for imx25 based SoC
> parts, and I think for imx31 SoC as well. There is no problem with
> configuring SPI ports to use a GPIO as chip select.
>
> Selecting native chip selects via the old platform setup code will
> work, it is only devicetree configurations that are broken.
>
> With platform configuration you specify a native chip select by
> setting the cs_gpio for the SPI device to be "32 - chipselect",
> This will be a negative number - and thus not a valid GPIO number.
> And that "chipselect" is the actual hardware native chip select
> number.
>
> You cannot specify the cs_gpio in dvicetree as a negative number,
> so this whole scheme does not work. The common method in devicetree
> is to set the cs_gpio entry for your device to be "<0>". If you do
> this to configure your SPI device to use a native chip select it is
> valid, but the SPI device cannot be accessed (no valid read data
> returned from it).
>
> The problem lies in the way the spi-imx.c driver sets up the
> controlling registers of the iMX SPI block. It doesn't have the
> correct logic for using nativce chip selects in the devicetree case.
>
> The best fix is to use the "chip_select" associated with the SPI
> device as passed in from the devicetree (as the "reg" tag) or directly
> in the platform data structure. The hitch with that is that field is
> not set correctly by some platform device code.
>
> The following patches fix the platform setup code to correctly set
> the "chip_select" for the SPI device and to set the SPI registers
> correctly based on that.
>
> These changes affect the iMX machine code and drivers/spi subsystem so
> I have sent this to both lists for feedback.
>
> Signed-off-by: Greg Ungerer <gerg-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
The device tree support was added for imx spi driver with only the case
of GPIO being chip select in consideration, as that's the case for all
recent i.MX SoCs. So, yes, native chip select never worked for device
tree case before. Thanks for getting it work.
Shawn
--
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
prev parent reply other threads:[~2017-03-20 7:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-17 5:03 [PATCH 0/2] spi: imx: native chip selects and devicetree Greg Ungerer
2017-03-17 5:03 ` [PATCH 1/2] spi: imx: set correct chip_select in platform setup Greg Ungerer
[not found] ` <1489726983-17706-2-git-send-email-gerg-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2017-03-20 7:38 ` Shawn Guo
2017-03-20 11:52 ` Greg Ungerer
[not found] ` <1489726983-17706-1-git-send-email-gerg-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2017-03-17 5:03 ` [PATCH 2/2] spi: imx: fix use of native chip-selects with devicetree Greg Ungerer
2017-03-20 7:39 ` Shawn Guo
[not found] ` <1489726983-17706-3-git-send-email-gerg-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2017-03-20 13:22 ` Vladimir Zapolskiy
2017-03-21 2:05 ` Greg Ungerer
[not found] ` <4a8449d9-cc38-d642-0853-246f46ee7059-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2017-03-21 8:05 ` Uwe Kleine-König
2017-03-21 11:53 ` Greg Ungerer
[not found] ` <942cfc4b-445b-ca51-1823-2391cea62abf-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2017-03-21 12:11 ` Uwe Kleine-König
[not found] ` <20170321121133.jcmhhbszj2d42h3w-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-03-21 13:22 ` Greg Ungerer
[not found] ` <20678cef-f667-9915-aa00-8877ad152a8c-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2017-03-21 19:23 ` Uwe Kleine-König
2017-03-21 20:15 ` Geert Uytterhoeven
[not found] ` <CAMuHMdW+KcPCAweneu4pTg1Pb-uAvYGz1+Z=oEDYoOt4gWrjhA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-22 0:50 ` Greg Ungerer
2017-03-22 7:09 ` Geert Uytterhoeven
2017-09-04 12:47 ` Applied "spi: imx: fix use of native chip-selects with devicetree" to the spi tree Mark Brown
2017-10-10 20:38 ` [2/2] spi: imx: fix use of native chip-selects with devicetree Trent Piepho
2017-10-12 6:26 ` Greg Ungerer
[not found] ` <209bb901-875e-8007-06f8-3ae9698a0e41-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2017-10-12 20:41 ` Trent Piepho
2017-03-20 7:35 ` Shawn Guo [this message]
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=20170320073538.GC3443@dragon \
--to=shawnguo-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=fabio.estevam-3arQi8VN3Tc@public.gmane.org \
--cc=gerg-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).