All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Thomas Abraham <thomas.abraham@linaro.org>
Cc: spi-devel-general@lists.sourceforge.net,
	devicetree-discuss@lists.ozlabs.org, kgene.kim@samsung.com,
	rob.herring@calxeda.com, grant.likely@secretlab.ca,
	jaswinder.singh@linaro.org, linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 10/10] spi: s3c64xx: add device tree support
Date: Wed, 9 May 2012 15:32:00 +0100	[thread overview]
Message-ID: <20120509143159.GU3955@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJuYYwQF9Hh3wJpPTfXm_5iirvHzgwDu6imuSgH-ggenj=Vc8Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote:
> On 9 May 2012 17:07, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:

> >> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no
> >> +  particular order). The format of the gpio specifier depends on the gpio
> >> +  controller.

> > This seems odd...  This isn't a bitbanging controller, and surely the
> > driver will need to know which signal is which?  I suspect this is
> > actually for pinmux rather than to identify the signals but that should
> > at least be made clear and really should be being done using the pinmux
> > API.

> The driver retrieves the list of gpio's that it is allowed to use. The
> gpio numbers for miso, mosi and clk are mandatory but the order in
> which they are specified is not important since the driver never needs
> to which gpio is which interface line. I agree the pinmux api should
> be used here, but the call to pinmux api would be a incremental change
> here, not changing the code this patch is adding.

I'd suggest just specifying the order - someone might want to use it
later for some reason and it's not really a hardship for someone to use
it.  Avoids any "how does that work?" questions like I had.

> >> +  - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as
> >> +    the slave select line by the spi controller. The format of the gpio
> >> +    specifier depends on the gpio controller.

> > We should really have a binding for this at the SPI level (and ideally
> > some code to manage setting the GPIO too) - it's pretty common to use a
> > GPIO as /CS.

> The existing implementations vary in the way the nCS gpio lines are
> specified. For some controllers, the nCS gpio's are included in the
> spi device node whereas in this implementation, the nCS gpio is listed
> in the spi slave device node.

Yeah, I know.  I'm saying we should try to come up with a binding for
this that can be used by new SPI contollers going forward so things are
consistent.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/10] spi: s3c64xx: add device tree support
Date: Wed, 9 May 2012 15:32:00 +0100	[thread overview]
Message-ID: <20120509143159.GU3955@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJuYYwQF9Hh3wJpPTfXm_5iirvHzgwDu6imuSgH-ggenj=Vc8Q@mail.gmail.com>

On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote:
> On 9 May 2012 17:07, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:

> >> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no
> >> + ?particular order). The format of the gpio specifier depends on the gpio
> >> + ?controller.

> > This seems odd... ?This isn't a bitbanging controller, and surely the
> > driver will need to know which signal is which? ?I suspect this is
> > actually for pinmux rather than to identify the signals but that should
> > at least be made clear and really should be being done using the pinmux
> > API.

> The driver retrieves the list of gpio's that it is allowed to use. The
> gpio numbers for miso, mosi and clk are mandatory but the order in
> which they are specified is not important since the driver never needs
> to which gpio is which interface line. I agree the pinmux api should
> be used here, but the call to pinmux api would be a incremental change
> here, not changing the code this patch is adding.

I'd suggest just specifying the order - someone might want to use it
later for some reason and it's not really a hardship for someone to use
it.  Avoids any "how does that work?" questions like I had.

> >> + ?- samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as
> >> + ? ?the slave select line by the spi controller. The format of the gpio
> >> + ? ?specifier depends on the gpio controller.

> > We should really have a binding for this at the SPI level (and ideally
> > some code to manage setting the GPIO too) - it's pretty common to use a
> > GPIO as /CS.

> The existing implementations vary in the way the nCS gpio lines are
> specified. For some controllers, the nCS gpio's are included in the
> spi device node whereas in this implementation, the nCS gpio is listed
> in the spi slave device node.

Yeah, I know.  I'm saying we should try to come up with a binding for
this that can be used by new SPI contollers going forward so things are
consistent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120509/15462c0f/attachment.sig>

  reply	other threads:[~2012-05-09 14:32 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-08 22:04 [PATCH 00/10] spi: s3c64xx: add support for device tree Thomas Abraham
2012-05-08 22:04 ` Thomas Abraham
2012-05-08 22:04 ` [PATCH 01/10] spi: s3c64xx: remove unused S3C64XX_SPI_ST_TRLCNTZ macro Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-20  4:41   ` Grant Likely
2012-05-20  4:41     ` Grant Likely
2012-05-08 22:04 ` [PATCH 02/10] spi: s3c64xx: move controller information into driver data Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-20  4:42   ` Grant Likely
2012-05-20  4:42     ` Grant Likely
2012-05-30  7:23   ` Olof Johansson
2012-05-30  7:23     ` Olof Johansson
2012-05-30  8:00     ` Thomas Abraham
2012-05-30  8:00       ` Thomas Abraham
2012-05-08 22:04 ` [PATCH 03/10] ARM: Samsung: Remove spi hardware controller information from platform data Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-08 22:04 ` [PATCH 04/10] ARM: Samsung: Remove pdev pointer paremeter from spi gpio setup functions Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-08 22:04 ` [PATCH 05/10] ARM: Samsung: Update the device names for spi clock lookup Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-09  8:52   ` Mark Brown
2012-05-09  8:52     ` Mark Brown
2012-05-09 13:40     ` Thomas Abraham
2012-05-09 13:40       ` Thomas Abraham
2012-05-09 14:28       ` Mark Brown
2012-05-09 14:28         ` Mark Brown
     [not found]         ` <20120509142836.GT3955-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-05-09 17:17           ` Thomas Abraham
2012-05-09 17:17             ` Thomas Abraham
2012-05-13 14:51             ` Mark Brown
2012-05-13 14:51               ` Mark Brown
2012-05-20  4:43               ` Grant Likely
2012-05-20  4:43                 ` Grant Likely
2012-05-08 22:04 ` [PATCH 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-09  8:56   ` Mark Brown
2012-05-09  8:56     ` Mark Brown
     [not found]     ` <20120509085617.GB28702-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2012-05-09  9:10       ` Heiko Stübner
2012-05-09  9:10         ` Heiko Stübner
2012-05-09 10:55         ` Mark Brown
2012-05-09 10:55           ` Mark Brown
2012-05-09 14:22           ` Thomas Abraham
2012-05-09 14:22             ` Thomas Abraham
2012-05-09 14:33             ` Mark Brown
2012-05-09 14:33               ` Mark Brown
2012-05-09 15:06               ` Thomas Abraham
2012-05-09 15:06                 ` Thomas Abraham
2012-05-08 22:04 ` [PATCH 07/10] spi: s3c64xx: Remove the 'set_level' callback from controller data Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-09  8:03   ` Jassi Brar
2012-05-09  8:03     ` Jassi Brar
2012-05-09  9:20   ` Heiko Stübner
2012-05-09  9:20     ` Heiko Stübner
2012-05-09 10:31     ` Jassi Brar
2012-05-09 10:31       ` Jassi Brar
2012-05-20  4:45   ` Grant Likely
2012-05-20  4:45     ` Grant Likely
2012-05-08 22:04 ` [PATCH 08/10] ARM: Exynos4: Fix the incorrect hierarchy of spi controller bus clock Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-08 22:04 ` [PATCH 09/10] ARM: Exynos5: Add spi clock support Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
2012-05-08 22:04 ` [PATCH 10/10] spi: s3c64xx: add device tree support Thomas Abraham
2012-05-08 22:04   ` Thomas Abraham
     [not found]   ` <1336514694-22393-11-git-send-email-thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-05-09  9:07     ` Mark Brown
2012-05-09  9:07       ` Mark Brown
2012-05-09 14:13       ` Thomas Abraham
2012-05-09 14:13         ` Thomas Abraham
2012-05-09 14:32         ` Mark Brown [this message]
2012-05-09 14:32           ` Mark Brown
2012-05-09 16:39           ` Thomas Abraham
2012-05-09 16:39             ` Thomas Abraham
2012-05-09 16:47             ` Mark Brown
2012-05-09 16:47               ` Mark Brown
2012-05-09 17:19               ` Thomas Abraham
2012-05-09 17:19                 ` Thomas Abraham
2012-05-09  8:17 ` [PATCH 00/10] spi: s3c64xx: add support for device tree Jassi Brar
2012-05-09  8:17   ` Jassi Brar
     [not found] ` <1336514694-22393-1-git-send-email-thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-05-22 12:35   ` padma venkat
2012-05-22 12:35     ` padma venkat

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=20120509143159.GU3955@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jaswinder.singh@linaro.org \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    --cc=spi-devel-general@lists.sourceforge.net \
    --cc=thomas.abraham@linaro.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.