Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Hello Doug,
On 06/24/2014 06:05 AM, Doug Anderson wrote:
Andreas,
On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber afaer...@suse.de wrote:
Hi Doug,
Am 23.06.2014 21:47, schrieb Doug Anderson:
Thanks for posting! A first pass on this is below...
Thanks a lot for your quick review! My first big .dts patch, and no
datasheets for the hardware at hand as a user.
A first pass of replies to my defense. ;)
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
[...]
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
It is possible we may want to backpedal on the use of
exynos5250-cros-common.dtsi. I know that Olof (now CCed) said he
wasn't a fan of how it turned out.
The original idea was that it should include the arbitrary set of
things that are common between a chunk of Chrome OS boards. As more
boards were introduced things would need to migrate from the common
file to the board files.
At the moment the current conventional wisdom is that some duplication
is better than the confusing movement of everything back and forth.
See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
Another option is to identify DTS fragments that are common across boards and
create .dtsi files for these specific chunks instead of trying to group all set
of common things on a single .dtsi file.
For example, a quite common design for OMAP2+ based boards is to use a SMSC LAN
chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the
following files were created to reduce DTS duplication:
arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
Now that I think about it, is the same that what you did for
arm/boot/dts/cros-ec-keyboard.dtsi.
Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make it
more flexible/reusable?
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250,
samsung,exynos5;
+
+ pinctrl@1140 {
The new best way to do things is to put this down at the bottom. See
exynos5420-peach-pit as an example:
pinctrl_0 {
...
}
Note that I believe it was decided that top-level references like that
should be sorted alphabetically.
Thanks for the hint. (My chosen sort order here was by address.)
If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.
I can of course apply changes to Snow, but I cannot test them myself.
If you want to send up a patch like that I'm happy to give it a once
over and also to test it. ...but don't feel obligated
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
I'm pretty sure that the HSIC reset needed some funky code to make it
work and I'm not sure what the status of that is upstream
Yeah, you mentioned something along those
Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Re-sending ... the text-only encoding was not properly turned on on
the previous one and irritated the mailing lists.
On Mon, Jun 23, 2014 at 9:05 PM, Doug Anderson diand...@chromium.org wrote:
Andreas,
On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber afaer...@suse.de wrote:
Hi Doug,
Am 23.06.2014 21:47, schrieb Doug Anderson:
Thanks for posting! A first pass on this is below...
Thanks a lot for your quick review! My first big .dts patch, and no
datasheets for the hardware at hand as a user.
A first pass of replies to my defense. ;)
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
[...]
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
It is possible we may want to backpedal on the use of
exynos5250-cros-common.dtsi. I know that Olof (now CCed) said he
wasn't a fan of how it turned out.
The original idea was that it should include the arbitrary set of
things that are common between a chunk of Chrome OS boards. As more
boards were introduced things would need to migrate from the common
file to the board files.
At the moment the current conventional wisdom is that some duplication
is better than the confusing movement of everything back and forth.
See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250,
samsung,exynos5;
+
+ pinctrl@1140 {
The new best way to do things is to put this down at the bottom. See
exynos5420-peach-pit as an example:
pinctrl_0 {
...
}
Note that I believe it was decided that top-level references like that
should be sorted alphabetically.
Thanks for the hint. (My chosen sort order here was by address.)
If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.
I can of course apply changes to Snow, but I cannot test them myself.
If you want to send up a patch like that I'm happy to give it a once
over and also to test it. ...but don't feel obligated
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
I'm pretty sure that the HSIC reset needed some funky code to make it
work and I'm not sure what the status of that is upstream
Yeah, you mentioned something along those lines. However it's the
equivalent of the usb3-vbus-en in -snow.dts. Rename or drop?
It's clearly not equivalent, usb3-vbus-en just turns on/off the load
switch for VBUS
while the HSIC chip (USB3503) is an external PHY (and hub) for the
USB2 port, the reset of the PHY side of the HSIC needs to be done
within the proper timing window compared to the SoC HSIC controller to
get a working link.
As the current kernel has a binding for the SMSC
Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Javier, On Tue, Jun 24, 2014 at 3:06 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Doug, On 06/24/2014 06:05 AM, Doug Anderson wrote: Another option is to identify DTS fragments that are common across boards and create .dtsi files for these specific chunks instead of trying to group all set of common things on a single .dtsi file. For example, a quite common design for OMAP2+ based boards is to use a SMSC LAN chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the following files were created to reduce DTS duplication: arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi Now that I think about it, is the same that what you did for arm/boot/dts/cros-ec-keyboard.dtsi. Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make it more flexible/reusable? Yes, I think the config fragments can be cleaner but I think we have to be judicious about using them. There are definitely tradeoffs involved. The keyboard was such an excessively large thing and totally duplicated, so moving it out made sense. Other bits are less obvious (to me) because there are so many interactions / combinations and you end up with a bit of spaghetti in terms of which labels are used by and provided by each fragment. I guess possibly you could codify that better... A few thoughts looking at exynos5420-peach-pit: * backlight: seems (?) too board specific * samsung,exynos5420-oscclk: could totally be a fragment, but very small. * power key: could be a fragment for all boards that happen to use gpx1-2 for this * sound: could be a fragment for all devices using google,snow-audio-max98090, possibly. Personally I think that status = [enabled | disabled] only makes sense for IP blocks that are part of the SoC but may or may not be used by a board (e.g: i2c and spi buses, sdhci and usb host controllers, etc). DTS should be a description of the hardware so I agree that having a disabled node for a device that is not present in the board is not right. Right. We'll take a look again in v2 when cros-common isn't used. I think this could go in steps: 1. Don't use cros-common for spring 2. Don't use cros-common for snow (fold stuff in) 3. Introduce some fragments. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Andreas,
Thanks for posting! A first pass on this is below...
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
Adds initial support for the HP Chromebook 11.
Cc: Vincent Palatin vpala...@chromium.org
Cc: Doug Anderson diand...@chromium.org
Cc: Stephan van Schaik step...@synkhronix.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5250-spring.dts | 556
2 files changed, 557 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5986ff6..dc2c5aa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
exynos5420-arndale-octa.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
It is possible we may want to backpedal on the use of
exynos5250-cros-common.dtsi. I know that Olof (now CCed) said he
wasn't a fan of how it turned out.
The original idea was that it should include the arbitrary set of
things that are common between a chunk of Chrome OS boards. As more
boards were introduced things would need to migrate from the common
file to the board files.
At the moment the current conventional wisdom is that some duplication
is better than the confusing movement of everything back and forth.
See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250, samsung,exynos5;
+
+ pinctrl@1140 {
The new best way to do things is to put this down at the bottom. See
exynos5420-peach-pit as an example:
pinctrl_0 {
...
}
Note that I believe it was decided that top-level references like that
should be sorted alphabetically.
If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
I'm pretty sure that the HSIC reset needed some funky code to make it
work and I'm not sure what the status of that is upstream
+ };
+
+ vbat: vbat-fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = vbat-supply;
+ regulator-boot-on;
+ };
+
+ usb@1200 {
+ status = okay;
+ };
+
+ usb3_vbus_reg: regulator-usb3 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON;
+ regulator-min-microvolt
Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Hi Doug,
Am 23.06.2014 21:47, schrieb Doug Anderson:
Thanks for posting! A first pass on this is below...
Thanks a lot for your quick review! My first big .dts patch, and no
datasheets for the hardware at hand as a user.
A first pass of replies to my defense. ;)
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
[...]
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
It is possible we may want to backpedal on the use of
exynos5250-cros-common.dtsi. I know that Olof (now CCed) said he
wasn't a fan of how it turned out.
The original idea was that it should include the arbitrary set of
things that are common between a chunk of Chrome OS boards. As more
boards were introduced things would need to migrate from the common
file to the board files.
At the moment the current conventional wisdom is that some duplication
is better than the confusing movement of everything back and forth.
See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250,
samsung,exynos5;
+
+ pinctrl@1140 {
The new best way to do things is to put this down at the bottom. See
exynos5420-peach-pit as an example:
pinctrl_0 {
...
}
Note that I believe it was decided that top-level references like that
should be sorted alphabetically.
Thanks for the hint. (My chosen sort order here was by address.)
If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.
I can of course apply changes to Snow, but I cannot test them myself.
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
I'm pretty sure that the HSIC reset needed some funky code to make it
work and I'm not sure what the status of that is upstream
Yeah, you mentioned something along those lines. However it's the
equivalent of the usb3-vbus-en in -snow.dts. Rename or drop?
+ };
+
+ vbat: vbat-fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = vbat-supply;
+ regulator-boot-on;
+ };
+
+ usb@1200 {
+ status = okay;
+ };
+
+ usb3_vbus_reg: regulator-usb3 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpe1 0 1;
+ pinctrl-names = default;
+ pinctrl-0 = hsic_reset;
+ enable-active-high;
+ };
+
+ phy@1210 {
+ vbus-supply = usb3_vbus_reg;
+ };
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx1 1 0;
+ status = okay;
+ };
+
+
Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Andreas,
On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber afaer...@suse.de wrote:
Hi Doug,
Am 23.06.2014 21:47, schrieb Doug Anderson:
Thanks for posting! A first pass on this is below...
Thanks a lot for your quick review! My first big .dts patch, and no
datasheets for the hardware at hand as a user.
A first pass of replies to my defense. ;)
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
[...]
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
It is possible we may want to backpedal on the use of
exynos5250-cros-common.dtsi. I know that Olof (now CCed) said he
wasn't a fan of how it turned out.
The original idea was that it should include the arbitrary set of
things that are common between a chunk of Chrome OS boards. As more
boards were introduced things would need to migrate from the common
file to the board files.
At the moment the current conventional wisdom is that some duplication
is better than the confusing movement of everything back and forth.
See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250,
samsung,exynos5;
+
+ pinctrl@1140 {
The new best way to do things is to put this down at the bottom. See
exynos5420-peach-pit as an example:
pinctrl_0 {
...
}
Note that I believe it was decided that top-level references like that
should be sorted alphabetically.
Thanks for the hint. (My chosen sort order here was by address.)
If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.
I can of course apply changes to Snow, but I cannot test them myself.
If you want to send up a patch like that I'm happy to give it a once
over and also to test it. ...but don't feel obligated
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
I'm pretty sure that the HSIC reset needed some funky code to make it
work and I'm not sure what the status of that is upstream
Yeah, you mentioned something along those lines. However it's the
equivalent of the usb3-vbus-en in -snow.dts. Rename or drop?
On snow locally I see USB2 vbus is gpx1-1 and USB3 vbus is gpx2-7. I
don't see that in spring.
This will take more time than I have right now to track down. I added
Julius to the thread in case he has time to answer and can suggest
what to do for upstream purposes. I may be able to look more
tomorrow.
You can always send up the next version and include this and we'll
look at it again.
+ };
+
+ vbat: vbat-fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = vbat-supply;
+ regulator-boot-on;
+ };
+
+ usb@1200 {
+ status = okay;
+ };
+
+
[RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Adds initial support for the HP Chromebook 11.
Cc: Vincent Palatin vpala...@chromium.org
Cc: Doug Anderson diand...@chromium.org
Cc: Stephan van Schaik step...@synkhronix.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5250-spring.dts | 556
2 files changed, 557 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5986ff6..dc2c5aa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
exynos5420-arndale-octa.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
+
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250, samsung,exynos5;
+
+ pinctrl@1140 {
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ vbat: vbat-fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = vbat-supply;
+ regulator-boot-on;
+ };
+
+ usb@1200 {
+ status = okay;
+ };
+
+ usb3_vbus_reg: regulator-usb3 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpe1 0 1;
+ pinctrl-names = default;
+ pinctrl-0 = hsic_reset;
+ enable-active-high;
+ };
+
+ phy@1210 {
+ vbus-supply = usb3_vbus_reg;
+ };
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx1 1 0;
+ status = okay;
+ };
+
+ usb@1212 {
+ status = okay;
+ };
+
+ mmc@1222 {
+ /* MMC2 pins are used as GPIO for eDP bridge control. */
+ status = disabled;
+ };
+
+ mmc@1223 {
+ status = disabled;
+ };
+
+ i2c@12C6 {
+ max77686@09 {
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+
+ rtc {
+ reg = 0x6;
+ };
+ };
+
+ s5m8767_pmic@66 {
+ compatible = samsung,s5m8767-pmic;
+ reg = 0x66;
+ interrupt-parent = gpx3;
+ interrupts = 2 0;
+ pinctrl-names = default;
+
