From: Mark Brown <broonie@kernel.org>
To: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: ks.giri@samsung.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] spi/s3c64xx: Update DT binding documentation to match code
Date: Fri, 7 Mar 2014 10:48:41 +0800 [thread overview]
Message-ID: <20140307024841.GV13126@sirena.org.uk> (raw)
In-Reply-To: <1394125539-28062-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On Thu, Mar 06, 2014 at 05:05:39PM +0000, Charles Keepax wrote:
> The following patch added support for spi controllers with a dedicated
> chip select pin:
>
> commit 3146beec21b64f4551fcf0ac148381d54dc41b1b
> spi: s3c64xx: Added provision for dedicated cs pin
>
> It updated the device tree binding to require a "cs-gpio" property to be
> specified on the spi controller node if chip selects will be given as
> GPIOs per slave, rather than the controller having a dedicated internal
> chip select pin.
No, it doesn't - it's saying that if the device has a "cs-gpio" property
then to use that as the chip select. It's not a boolean, it's a GPIO
specifier. Looking at the code it looks like the intention is to search
all children for a cs-gpio during the controller probe, it's possible
that this isn't working correctly.
> Apologies if I missed something but there are a couple of
> things I am not sure about in the original patch, there
> seems to be no special handling for the dedicated case, like
> set a bit that enables this or some such, which implies that
> parts with dedicated cs pins will always update them even
> if cs-gpio is specified. In which case wasn't what existed
> before reasonable?
The chip select signal within the IP always needs to be manipulated for
the hardware to work regardless of a GPIO being used, if a GPIO is being
used as the actual chip select then the expecation is that the pinmux
will be set up so that the signal isn't actually brought out of the
device.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-03-07 3:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 17:05 Charles Keepax
2014-03-07 2:48 ` Mark Brown [this message]
2014-03-07 9:19 ` Charles Keepax
2014-03-09 8:43 ` 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=20140307024841.GV13126@sirena.org.uk \
--to=broonie@kernel.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=devicetree@vger.kernel.org \
--cc=ks.giri@samsung.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®