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:26:43 -0600	[thread overview]
Message-ID: <538CA5C3.5050709@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/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt

> +  toradex,colibri_t30
> +  toradex,colibri_t30-eval-v3

Those don't seem to be related to Apalis support.

> diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts b/arch/arm/boot/dts/tegra30-apalis-eval.dts
> +	host1x@50000000 {
> +		dc@54200000 {
> +			rgb {
> +				status = "okay";
> +				nvidia,panel = <&panel>;
> +			};
> +		};
> +		hdmi@54280000 {

Nit: Add a blank line between the nodes. Check elsewhere too.

> +	serial@70006040 {
> +		compatible = "nvidia,tegra30-hsuart";
> +		status = "okay";
> +	};

Nit: Put the status property first followed by new/overridden
properties, to be consistent with other Tegra DTs. Check elsewhere too.

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

Nit: Add a blank line between properties and nodes. Check elsewhere too.

> +	sd1: sdhci@78000000 {
...
> +	mmc1: sdhci@78000400 {

Do those nodes really need labels? Nothing appears to reference them,
and I can't see why anything would.

Should the mmc1 node be non-removable? It seems a bit odd for a
removable device to have an 8-bit data bus.

> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +
> +		/* PWM0 */

Nit: No need for a blank line between a bunch of related properties.
Check elsewhere too.

> +	pwmleds {
> +		compatible = "pwm-leds";
> +
> +		pwm3 {
> +			label = "PWM3";
> +			pwms = <&pwm 1 19600>;
> +			max-brightness = <255>;
> +		};
> +		pwm2 {
> +			label = "PWM2";
> +			pwms = <&pwm 2 19600>;
> +			max-brightness = <255>;
> +		};
> +		pwm1 {
> +			label = "PWM1";
> +			pwms = <&pwm 3 19600>;
> +			max-brightness = <255>;
> +		};

Nit: Why not sort those nodes in numerical order?

> +	regulators {
> +		sys_5v0_reg: regulator@1 {

Nit: Why not start the numbering at 0?

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

> +	pinmux@70000868 {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&state_default>;
> +
> +		state_default: pinmux {

It might make sense to add all the pinmux data to
https://github.com/NVIDIA/tegra-pinmux-scripts, so that both the kernel
and U-Boot pinmux initialization tables can be auto-generated from a
single data-structure. I think that'll get a small amount of
error-/consistency-checking of the data too.

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:26:43 -0600	[thread overview]
Message-ID: <538CA5C3.5050709@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/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt

> +  toradex,colibri_t30
> +  toradex,colibri_t30-eval-v3

Those don't seem to be related to Apalis support.

> diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts b/arch/arm/boot/dts/tegra30-apalis-eval.dts
> +	host1x at 50000000 {
> +		dc at 54200000 {
> +			rgb {
> +				status = "okay";
> +				nvidia,panel = <&panel>;
> +			};
> +		};
> +		hdmi at 54280000 {

Nit: Add a blank line between the nodes. Check elsewhere too.

> +	serial at 70006040 {
> +		compatible = "nvidia,tegra30-hsuart";
> +		status = "okay";
> +	};

Nit: Put the status property first followed by new/overridden
properties, to be consistent with other Tegra DTs. Check elsewhere too.

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

Nit: Add a blank line between properties and nodes. Check elsewhere too.

> +	sd1: sdhci at 78000000 {
...
> +	mmc1: sdhci at 78000400 {

Do those nodes really need labels? Nothing appears to reference them,
and I can't see why anything would.

Should the mmc1 node be non-removable? It seems a bit odd for a
removable device to have an 8-bit data bus.

> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +
> +		/* PWM0 */

Nit: No need for a blank line between a bunch of related properties.
Check elsewhere too.

> +	pwmleds {
> +		compatible = "pwm-leds";
> +
> +		pwm3 {
> +			label = "PWM3";
> +			pwms = <&pwm 1 19600>;
> +			max-brightness = <255>;
> +		};
> +		pwm2 {
> +			label = "PWM2";
> +			pwms = <&pwm 2 19600>;
> +			max-brightness = <255>;
> +		};
> +		pwm1 {
> +			label = "PWM1";
> +			pwms = <&pwm 3 19600>;
> +			max-brightness = <255>;
> +		};

Nit: Why not sort those nodes in numerical order?

> +	regulators {
> +		sys_5v0_reg: regulator at 1 {

Nit: Why not start the numbering at 0?

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

> +	pinmux at 70000868 {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&state_default>;
> +
> +		state_default: pinmux {

It might make sense to add all the pinmux data to
https://github.com/NVIDIA/tegra-pinmux-scripts, so that both the kernel
and U-Boot pinmux initialization tables can be auto-generated from a
single data-structure. I think that'll get a small amount of
error-/consistency-checking of the data too.

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:26:43 -0600	[thread overview]
Message-ID: <538CA5C3.5050709@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/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt

> +  toradex,colibri_t30
> +  toradex,colibri_t30-eval-v3

Those don't seem to be related to Apalis support.

> diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts b/arch/arm/boot/dts/tegra30-apalis-eval.dts
> +	host1x@50000000 {
> +		dc@54200000 {
> +			rgb {
> +				status = "okay";
> +				nvidia,panel = <&panel>;
> +			};
> +		};
> +		hdmi@54280000 {

Nit: Add a blank line between the nodes. Check elsewhere too.

> +	serial@70006040 {
> +		compatible = "nvidia,tegra30-hsuart";
> +		status = "okay";
> +	};

Nit: Put the status property first followed by new/overridden
properties, to be consistent with other Tegra DTs. Check elsewhere too.

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

Nit: Add a blank line between properties and nodes. Check elsewhere too.

> +	sd1: sdhci@78000000 {
...
> +	mmc1: sdhci@78000400 {

Do those nodes really need labels? Nothing appears to reference them,
and I can't see why anything would.

Should the mmc1 node be non-removable? It seems a bit odd for a
removable device to have an 8-bit data bus.

> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +
> +		/* PWM0 */

Nit: No need for a blank line between a bunch of related properties.
Check elsewhere too.

> +	pwmleds {
> +		compatible = "pwm-leds";
> +
> +		pwm3 {
> +			label = "PWM3";
> +			pwms = <&pwm 1 19600>;
> +			max-brightness = <255>;
> +		};
> +		pwm2 {
> +			label = "PWM2";
> +			pwms = <&pwm 2 19600>;
> +			max-brightness = <255>;
> +		};
> +		pwm1 {
> +			label = "PWM1";
> +			pwms = <&pwm 3 19600>;
> +			max-brightness = <255>;
> +		};

Nit: Why not sort those nodes in numerical order?

> +	regulators {
> +		sys_5v0_reg: regulator@1 {

Nit: Why not start the numbering at 0?

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

> +	pinmux@70000868 {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&state_default>;
> +
> +		state_default: pinmux {

It might make sense to add all the pinmux data to
https://github.com/NVIDIA/tegra-pinmux-scripts, so that both the kernel
and U-Boot pinmux initialization tables can be auto-generated from a
single data-structure. I think that'll get a small amount of
error-/consistency-checking of the data too.

  parent reply	other threads:[~2014-06-02 16:26 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 [this message]
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=538CA5C3.5050709@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.