All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Ziswiler <marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	stefan-XLVq0VzYD2Y@public.gmane.org
Subject: Re: [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds
Date: Tue, 03 Jun 2014 08:02:37 +0200	[thread overview]
Message-ID: <538D64FD.2010909@ziswiler.com> (raw)
In-Reply-To: <20140602221627.GP31751-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>

On 06/03/2014 12:16 AM, Mark Brown wrote:
> On Mon, Jun 02, 2014 at 06:28:37PM +0200, Marcel Ziswiler wrote:
>> On 06/02/2014 06:11 PM, Stephen Warren wrote:
>
>>>> +CONFIG_SPI_SPIDEV=y
>
>>> Is this useful with DT? I thought that unlike I2C_CHARDEV, spidev needed
>>> dummy devices to exist in DT for spidev to work? If so, there's not much
>>> point adding the option to defconfig, since people can add it when they
>>> put the dummy devices into DT.
>
>> Yes, the Apalis T30 DT I sent actually contains two of them which we call
>> generic Apalis SPI1 and SPI2 out-of-the-box configured for exactly that.
>> Without the config enabled though it probably does not make much sense to
>> include it in the DT so I would consider removing it again.
>
> Your DT is broken if it's got a "spidev" node in it, you should be
> describing the hardware not the Linux implementation of the software.
> It would be really nice if we had a good way of handling this but we
> don't yet.

I strongly disagree, it almost perfectly describes the hardware. Unlike 
on I2c where modelling a bus is enough to allow generic user space 
access unfortunately on SPI this is not enough as it requires a specific 
chip-select as well. This is exactly what spidev does and maps to our 
hardware perfectly which has one dedicated chip-select per SPI bus on a 
dedicated header which allows our customers out-of-the-box spidev user 
space access to almost any SPI device connected to those buses just like 
with i2c-devs on I2C buses.

WARNING: multiple messages have this Message-ID (diff)
From: marcel@ziswiler.com (Marcel Ziswiler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds
Date: Tue, 03 Jun 2014 08:02:37 +0200	[thread overview]
Message-ID: <538D64FD.2010909@ziswiler.com> (raw)
In-Reply-To: <20140602221627.GP31751@sirena.org.uk>

On 06/03/2014 12:16 AM, Mark Brown wrote:
> On Mon, Jun 02, 2014 at 06:28:37PM +0200, Marcel Ziswiler wrote:
>> On 06/02/2014 06:11 PM, Stephen Warren wrote:
>
>>>> +CONFIG_SPI_SPIDEV=y
>
>>> Is this useful with DT? I thought that unlike I2C_CHARDEV, spidev needed
>>> dummy devices to exist in DT for spidev to work? If so, there's not much
>>> point adding the option to defconfig, since people can add it when they
>>> put the dummy devices into DT.
>
>> Yes, the Apalis T30 DT I sent actually contains two of them which we call
>> generic Apalis SPI1 and SPI2 out-of-the-box configured for exactly that.
>> Without the config enabled though it probably does not make much sense to
>> include it in the DT so I would consider removing it again.
>
> Your DT is broken if it's got a "spidev" node in it, you should be
> describing the hardware not the Linux implementation of the software.
> It would be really nice if we had a good way of handling this but we
> don't yet.

I strongly disagree, it almost perfectly describes the hardware. Unlike 
on I2c where modelling a bus is enough to allow generic user space 
access unfortunately on SPI this is not enough as it requires a specific 
chip-select as well. This is exactly what spidev does and maps to our 
hardware perfectly which has one dedicated chip-select per SPI bus on a 
dedicated header which allows our customers out-of-the-box spidev user 
space access to almost any SPI device connected to those buses just like 
with i2c-devs on I2C buses.

WARNING: multiple messages have this Message-ID (diff)
From: Marcel Ziswiler <marcel@ziswiler.com>
To: Mark Brown <broonie@kernel.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	thierry.reding@gmail.com, linux@arm.linux.org.uk,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
	stefan@agner.ch
Subject: Re: [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds
Date: Tue, 03 Jun 2014 08:02:37 +0200	[thread overview]
Message-ID: <538D64FD.2010909@ziswiler.com> (raw)
In-Reply-To: <20140602221627.GP31751@sirena.org.uk>

On 06/03/2014 12:16 AM, Mark Brown wrote:
> On Mon, Jun 02, 2014 at 06:28:37PM +0200, Marcel Ziswiler wrote:
>> On 06/02/2014 06:11 PM, Stephen Warren wrote:
>
>>>> +CONFIG_SPI_SPIDEV=y
>
>>> Is this useful with DT? I thought that unlike I2C_CHARDEV, spidev needed
>>> dummy devices to exist in DT for spidev to work? If so, there's not much
>>> point adding the option to defconfig, since people can add it when they
>>> put the dummy devices into DT.
>
>> Yes, the Apalis T30 DT I sent actually contains two of them which we call
>> generic Apalis SPI1 and SPI2 out-of-the-box configured for exactly that.
>> Without the config enabled though it probably does not make much sense to
>> include it in the DT so I would consider removing it again.
>
> Your DT is broken if it's got a "spidev" node in it, you should be
> describing the hardware not the Linux implementation of the software.
> It would be really nice if we had a good way of handling this but we
> don't yet.

I strongly disagree, it almost perfectly describes the hardware. Unlike 
on I2c where modelling a bus is enough to allow generic user space 
access unfortunately on SPI this is not enough as it requires a specific 
chip-select as well. This is exactly what spidev does and maps to our 
hardware perfectly which has one dedicated chip-select per SPI bus on a 
dedicated header which allows our customers out-of-the-box spidev user 
space access to almost any SPI device connected to those buses just like 
with i2c-devs on I2C buses.

  parent reply	other threads:[~2014-06-03  6:02 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c5522b0efcbfc7690dcde6aaf78b9dd568f99604.1401665237.git.marcel@ziswiler.com>
     [not found] ` <c5522b0efcbfc7690dcde6aaf78b9dd568f99604.1401665237.git.marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-01 23:37   ` [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
2014-06-02 16:11     ` Stephen Warren
2014-06-02 16:11       ` Stephen Warren
2014-06-02 16:28       ` Marcel Ziswiler
2014-06-02 16:28         ` Marcel Ziswiler
     [not found]         ` <538CA635.4050502-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-02 22:16           ` Mark Brown
2014-06-02 22:16             ` Mark Brown
2014-06-02 22:16             ` Mark Brown
     [not found]             ` <20140602221627.GP31751-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-03  6:02               ` Marcel Ziswiler [this message]
2014-06-03  6:02                 ` Marcel Ziswiler
2014-06-03  6:02                 ` Marcel Ziswiler
     [not found]                 ` <538D64FD.2010909-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-03  9:45                   ` Mark Brown
2014-06-03  9:45                     ` Mark Brown
2014-06-03  9:45                     ` Mark Brown
     [not found]                     ` <20140603094537.GQ31751-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-04  6:20                       ` Marcel Ziswiler
2014-06-04  6:20                         ` Marcel Ziswiler
2014-06-04  6:20                         ` Marcel Ziswiler
2014-06-04 11:17                         ` Mark Brown
2014-06-04 11:17                           ` Mark Brown
     [not found]                           ` <20140604111755.GG2520-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-09 22:16                             ` Marcel Ziswiler
2014-06-09 22:16                               ` Marcel Ziswiler
2014-06-09 22:16                               ` Marcel Ziswiler
2014-06-09 22:57                               ` Mark Brown
2014-06-09 22:57                                 ` Mark Brown
2014-06-01 23:37   ` [PATCH 3/3] arm: tegra: initial support for apalis t30 Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
2014-06-01 23:37     ` Marcel Ziswiler
     [not found]     ` <b470c9c8631a6ef021d140192eb07006de3cfd93.1401665237.git.marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-02 16:26       ` Stephen Warren
2014-06-02 16:26         ` Stephen Warren
2014-06-02 16:26         ` Stephen Warren
     [not found]         ` <538CA5C3.5050709-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-02 20:18           ` Marcel Ziswiler
2014-06-02 20:18             ` Marcel Ziswiler
2014-06-02 20:18             ` Marcel Ziswiler
     [not found]             ` <538CDC08.7020106-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>
2014-06-02 20:33               ` Stephen Warren
2014-06-02 20:33                 ` Stephen Warren
2014-06-02 20:33                 ` Stephen Warren
2014-06-02 16:33       ` Stephen Warren
2014-06-02 16:33         ` Stephen Warren
2014-06-02 16:33         ` Stephen Warren
     [not found]         ` <538CA749.3010106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-02 20:24           ` Marcel Ziswiler
2014-06-02 20:24             ` Marcel Ziswiler
2014-06-02 20:24             ` Marcel Ziswiler

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=538D64FD.2010909@ziswiler.com \
    --to=marcel-mitwqz+t+m9wk0htik3j/w@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=stefan-XLVq0VzYD2Y@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@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.