All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Marcel Ziswiler <marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: 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 3/3] arm: tegra: initial support for apalis t30
Date: Mon, 02 Jun 2014 10:33:13 -0600	[thread overview]
Message-ID: <538CA749.3010106@wwwdotorg.org> (raw)
In-Reply-To: <b470c9c8631a6ef021d140192eb07006de3cfd93.1401665237.git.marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org>

On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
> This patch adds the device tree to support Toradex Apalis T30, a
> computer on module which can be used on different carrier boards.
> 
> The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
> RAM, eMMC, an LM95245 temperature sensor chip, an i210 resp. i211
> gigabit Ethernet controller, an STMPE811 ADC/touch controller as well
> as two MCP2515 CAN controllers. Furthermore, there is an SGTL5000 audio
> codec which is not yet supported. Anything that is not self contained
> on the module is disabled by default.
> 
> The device tree for the Evaluation Board includes the modules device
> tree and enables the supported peripherals of the carrier board (the
> Evaluation Board supports almost all of them).
> 
> While at it also add the device tree binding documentation for Apalis
> T30 as well as the previously missing one for the recently added
> Colibri T30.

> diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts b/arch/arm/boot/dts/tegra30-apalis-eval.dts

> +	/* SPI1: Apalis SPI1 */
> +	spi@7000d400 {
> +		status = "okay";
> +		spi-max-frequency = <25000000>;
> +		spidev0: spidev@1 {
> +			compatible = "spidev";
> +			reg = <1>;
> +			spi-max-frequency = <25000000>;
> +		};
> +	};

I vaguely recall people speaking out against including "spidev" devices
in DT because they don't represent actual HW, but rather a way to
request that the SPI bus be exposed to user-space, which is a pure SW
issue. Wouldn't it be better if the spidev interface worked like
I2C_CHARDEV, where fake devices weren't actually required?

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] arm: tegra: initial support for apalis t30
Date: Mon, 02 Jun 2014 10:33:13 -0600	[thread overview]
Message-ID: <538CA749.3010106@wwwdotorg.org> (raw)
In-Reply-To: <b470c9c8631a6ef021d140192eb07006de3cfd93.1401665237.git.marcel@ziswiler.com>

On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
> This patch adds the device tree to support Toradex Apalis T30, a
> computer on module which can be used on different carrier boards.
> 
> The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
> RAM, eMMC, an LM95245 temperature sensor chip, an i210 resp. i211
> gigabit Ethernet controller, an STMPE811 ADC/touch controller as well
> as two MCP2515 CAN controllers. Furthermore, there is an SGTL5000 audio
> codec which is not yet supported. Anything that is not self contained
> on the module is disabled by default.
> 
> The device tree for the Evaluation Board includes the modules device
> tree and enables the supported peripherals of the carrier board (the
> Evaluation Board supports almost all of them).
> 
> While at it also add the device tree binding documentation for Apalis
> T30 as well as the previously missing one for the recently added
> Colibri T30.

> diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts b/arch/arm/boot/dts/tegra30-apalis-eval.dts

> +	/* SPI1: Apalis SPI1 */
> +	spi at 7000d400 {
> +		status = "okay";
> +		spi-max-frequency = <25000000>;
> +		spidev0: spidev at 1 {
> +			compatible = "spidev";
> +			reg = <1>;
> +			spi-max-frequency = <25000000>;
> +		};
> +	};

I vaguely recall people speaking out against including "spidev" devices
in DT because they don't represent actual HW, but rather a way to
request that the SPI bus be exposed to user-space, which is a pure SW
issue. Wouldn't it be better if the spidev interface worked like
I2C_CHARDEV, where fake devices weren't actually required?

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Marcel Ziswiler <marcel@ziswiler.com>, thierry.reding@gmail.com
Cc: 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 3/3] arm: tegra: initial support for apalis t30
Date: Mon, 02 Jun 2014 10:33:13 -0600	[thread overview]
Message-ID: <538CA749.3010106@wwwdotorg.org> (raw)
In-Reply-To: <b470c9c8631a6ef021d140192eb07006de3cfd93.1401665237.git.marcel@ziswiler.com>

On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
> This patch adds the device tree to support Toradex Apalis T30, a
> computer on module which can be used on different carrier boards.
> 
> The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
> RAM, eMMC, an LM95245 temperature sensor chip, an i210 resp. i211
> gigabit Ethernet controller, an STMPE811 ADC/touch controller as well
> as two MCP2515 CAN controllers. Furthermore, there is an SGTL5000 audio
> codec which is not yet supported. Anything that is not self contained
> on the module is disabled by default.
> 
> The device tree for the Evaluation Board includes the modules device
> tree and enables the supported peripherals of the carrier board (the
> Evaluation Board supports almost all of them).
> 
> While at it also add the device tree binding documentation for Apalis
> T30 as well as the previously missing one for the recently added
> Colibri T30.

> diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts b/arch/arm/boot/dts/tegra30-apalis-eval.dts

> +	/* SPI1: Apalis SPI1 */
> +	spi@7000d400 {
> +		status = "okay";
> +		spi-max-frequency = <25000000>;
> +		spidev0: spidev@1 {
> +			compatible = "spidev";
> +			reg = <1>;
> +			spi-max-frequency = <25000000>;
> +		};
> +	};

I vaguely recall people speaking out against including "spidev" devices
in DT because they don't represent actual HW, but rather a way to
request that the SPI bus be exposed to user-space, which is a pure SW
issue. Wouldn't it be better if the spidev interface worked like
I2C_CHARDEV, where fake devices weren't actually required?


  parent reply	other threads:[~2014-06-02 16:33 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
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 [this message]
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=538CA749.3010106@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@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=marcel-mitwqZ+T+m9Wk0Htik3J/w@public.gmane.org \
    --cc=stefan-XLVq0VzYD2Y@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.