Support NVIDIA Tegra-based Ouya game console
Subsystems (3)
v3 cover Support NVIDIA Tegra-based Ouya game console
Good Day,
This series introduces upstream kernel support for the Ouya game console device. Please review and apply. Thank you in advance.
Changelog:
v3: - Reorder aliases per Dmitry Osipenko's review.
- Add sdio clocks per Dmitry Osipenko's review.
- Add missing ti sleep bits per Dmitry Osipenko's review.
- Enable lp1 sleep mode.
- Fix bluetooth comment and add missing power supplies.
v2: - Update pmic and clock handles per Rob Herring's review.
- Add acks from Rob Herring to patch 2 and 3.
Peter Geis (3):
ARM: tegra: Add device-tree for Ouya
dt-bindings: Add vendor prefix for Ouya Inc.
dt-bindings: ARM: tegra: Add Ouya game console
.../devicetree/bindings/arm/tegra.yaml | 3 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/tegra30-ouya.dts | 4511 +++++++++++++++++ 4 files changed, 4518 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/tegra30-ouya.dts
Signature · 1 line
2.25.1
PATCH v3 1/3 ARM: tegra: Add device-tree for Ouya
The Ouya was the sole device produced by Ouya Inc in 2013.
It was a game console originally running Android 5 on top of Linux 3.1.10.
This patch adds the device tree supporting the Ouya. It has been tested on the original variant with Samsung ram.
--- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/tegra30-ouya.dts | 4511 ++++++++++++++++++++++++++++ 2 files changed, 4513 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/tegra30-ouya.dts
arch/arm/boot/dts/Makefile +2 -1
@@ -1228,7 +1228,8 @@ dtb-$(CONFIG_ARCH_TEGRA_3x_SOC) += \ tegra30-beaver.dtb \ tegra30-cardhu-a02.dtb \ tegra30-cardhu-a04.dtb \ - tegra30-colibri-eval-v3.dtb + tegra30-colibri-eval-v3.dtb \ + tegra30-ouya.dtb dtb-$(CONFIG_ARCH_TEGRA_114_SOC) += \ tegra114-dalmore.dtb \ tegra114-roth.dtb \
arch/arm/boot/dts/tegra30-ouya.dts new file +4511 -0
2,991 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
2.25.1
Part of the diff is not shown here. View the raw message.
Re: [PATCH v3 1/3] ARM: tegra: Add device-tree for Ouya
04.10.2020 16:31, Peter Geis пишет:
arch/arm/boot/dts/tegra30-ouya.dts line 436
Quoted 11 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +11
-0+ thermal-zones { + cpu_thermal: cpu-thermal { + polling-delay = <5000>; + polling-delay-passive = <5000>; + + thermal-sensors = <&cpu_temp 1>; + + trips { + cpu_alert0: cpu-alert0 { + temperature = <50000>; + hysteresis = <10000>;
Hello, Peter!
A day ago I was tuning thermal zones for Nexus 7 because found that the current variant is a bit too unpractical. In particular temperature hysteresis should be small, otherwise cpufreq could get throttled enormously to the point that device becomes unusable. This is an active-cooling zone, but it looks to me that hysteresis is a bit too high and should make Ouya much noisier than it could be.
I suggest to try to set hysteresis to 0.2C here, i.e. hysteresis = <200>.
I also suggest to bump the temperature threshold to 55C in order to ignore temporal temperature spikes because CPU temp should be about 40C during idle and then it may raise quickly for a brief moments during average usage.
arch/arm/boot/dts/tegra30-ouya.dts line 443
Quoted 7 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +7
-0+ type = "active"; + }; + cpu_alert1: cpu-alert1 { + temperature = <70000>; + hysteresis = <5000>; + type = "passive"; + };
And here to 0.2C as well.
arch/arm/boot/dts/tegra30-ouya.dts line 448
Quoted 5 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +5
-0+ cpu_crit: cpu-crit { + temperature = <90000>; + hysteresis = <2000>; + type = "critical"; + };
The critical zone perhaps should be fine as-is.
Re: [PATCH v3 1/3] ARM: tegra: Add device-tree for Ouya
Quoted 23 lines · Dmitry Osipenko
04.10.2020 16:31, Peter Geis пишет:
arch/arm/boot/dts/tegra30-ouya.dts line 436
Quoted 11 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +11
-0+ thermal-zones { + cpu_thermal: cpu-thermal { + polling-delay = <5000>; + polling-delay-passive = <5000>; + + thermal-sensors = <&cpu_temp 1>; + + trips { + cpu_alert0: cpu-alert0 { + temperature = <50000>; + hysteresis = <10000>;Hello, Peter!
A day ago I was tuning thermal zones for Nexus 7 because found that the current variant is a bit too unpractical. In particular temperature hysteresis should be small, otherwise cpufreq could get throttled enormously to the point that device becomes unusable. This is an active-cooling zone, but it looks to me that hysteresis is a bit too high and should make Ouya much noisier than it could be.
Quoted 6 lines
I suggest to try to set hysteresis to 0.2C here, i.e. hysteresis = <200>.
I also suggest to bump the temperature threshold to 55C in order to ignore temporal temperature spikes because CPU temp should be about 40C during idle and then it may raise quickly for a brief moments during average usage.
Good Morning,
The Ouya has a rather large heatsink with poor conductivity and a single stage fan.
The fan is not terribly loud, as it runs at a rather low rpm. The temperature at the cpu tends to be much higher than observed at the heatsink.
I've found that a low hysteresis value leads to a situation where the fan is constantly toggling on and off.
I actually burned out the power transistor driving the fan on my first Ouya this way.
The high hysteresis value provides a good balance of fan on/off time under most loads.
The temperature threshold was chosen for this as well.
Quoted 10 lines
arch/arm/boot/dts/tegra30-ouya.dts line 443
Quoted 8 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +7
-0+ type = "active"; + }; + cpu_alert1: cpu-alert1 { + temperature = <70000>; + hysteresis = <5000>; + type = "passive"; + };And here to 0.2C as well.
This value was chosen to protect the CPU in case of fan failure. Again, with the large heatsink and poor conductivity we need to maintain throttling for longer.
Otherwise the cpu temp will overshoot and risk thermal shutdown before throttling can prevent it.
Quoted 8 lines
arch/arm/boot/dts/tegra30-ouya.dts line 448
Quoted 6 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +5
-0+ cpu_crit: cpu-crit { + temperature = <90000>; + hysteresis = <2000>; + type = "critical"; + };The critical zone perhaps should be fine as-is.
Re: [PATCH v3 1/3] ARM: tegra: Add device-tree for Ouya
05.10.2020 17:22, Peter Geis пишет:
Quoted 55 lines · Dmitry Osipenko
Quoted 23 lines
04.10.2020 16:31, Peter Geis пишет:
arch/arm/boot/dts/tegra30-ouya.dts line 436
Quoted 11 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +11
-0+ thermal-zones { + cpu_thermal: cpu-thermal { + polling-delay = <5000>; + polling-delay-passive = <5000>; + + thermal-sensors = <&cpu_temp 1>; + + trips { + cpu_alert0: cpu-alert0 { + temperature = <50000>; + hysteresis = <10000>;Hello, Peter!
A day ago I was tuning thermal zones for Nexus 7 because found that the current variant is a bit too unpractical. In particular temperature hysteresis should be small, otherwise cpufreq could get throttled enormously to the point that device becomes unusable. This is an active-cooling zone, but it looks to me that hysteresis is a bit too high and should make Ouya much noisier than it could be.
Quoted 6 lines
I suggest to try to set hysteresis to 0.2C here, i.e. hysteresis = <200>.
I also suggest to bump the temperature threshold to 55C in order to ignore temporal temperature spikes because CPU temp should be about 40C during idle and then it may raise quickly for a brief moments during average usage.
Good Morning,
The Ouya has a rather large heatsink with poor conductivity and a single stage fan.
The fan is not terribly loud, as it runs at a rather low rpm. The temperature at the cpu tends to be much higher than observed at the heatsink.
I've found that a low hysteresis value leads to a situation where the fan is constantly toggling on and off.
I actually burned out the power transistor driving the fan on my first Ouya this way.
The high hysteresis value provides a good balance of fan on/off time under most loads.
The temperature threshold was chosen for this as well.Quoted 9 lines
Quoted 8 lines
arch/arm/boot/dts/tegra30-ouya.dts new file +7
-0+ type = "active"; + }; + cpu_alert1: cpu-alert1 { + temperature = <70000>; + hysteresis = <5000>; + type = "passive"; + };
Quoted 7 lines
Quoted 1 line
And here to 0.2C as well.
This value was chosen to protect the CPU in case of fan failure. Again, with the large heatsink and poor conductivity we need to maintain throttling for longer.
Otherwise the cpu temp will overshoot and risk thermal shutdown before throttling can prevent it.
Alright! Then I don't have any more comments for now, thanks :)
Re: [PATCH v3 1/3] ARM: tegra: Add device-tree for Ouya
In reply to Peter Geis04.10.2020 16:31, Peter Geis пишет:
Quoted 8 lines
The Ouya was the sole device produced by Ouya Inc in 2013.
It was a game console originally running Android 5 on top of Linux 3.1.10.This patch adds the device tree supporting the Ouya. It has been tested on the original variant with Samsung ram.
Signed-off-by Peter Geis <[email protected]>---
PATCH v3 2/3 dt-bindings: Add vendor prefix for Ouya Inc.
In reply to Peter GeisOuya is a defunct company from 2012 to 2015.
They produced a single device, the Ouya game console.
In 2015 they were purchased by Razer Inc. and the Ouya was discontinued. All Ouya services were shuttered in 2019.
--- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
@@ -786,6 +786,8 @@ patternProperties: description: Ortus Technology Co., Ltd. "^osddisplays,.*": description: OSD Displays + "^ouya,.*": + description: Ouya Inc. "^overkiz,.*": description: Overkiz SAS "^ovti,.*":
Signature · 1 line
2.25.1
Re: [PATCH v3 2/3] dt-bindings: Add vendor prefix for Ouya Inc.
04.10.2020 16:31, Peter Geis пишет:
Quoted 7 lines
Ouya is a defunct company from 2012 to 2015.
They produced a single device, the Ouya game console.
In 2015 they were purchased by Razer Inc. and the Ouya was discontinued. All Ouya services were shuttered in 2019.Signed-off-by Peter Geis <[email protected]>Acked-by Rob Herring <[email protected]>
Please note that your s-b tag always should be the last line of the commit message. This is not important, so no need to make v4 because of that.
Quoted 10 lines
--- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+)Documentation/devicetree/bindings/vendor-prefixes.yaml +0
-0
Documentation/devicetree/bindings/vendor-prefixes.yaml patternProperties: · line 793
Quoted 8 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml +2
-0@@ -786,6 +786,8 @@ patternProperties: description: Ortus Technology Co., Ltd. "^osddisplays,.*": description: OSD Displays + "^ouya,.*": + description: Ouya Inc. "^overkiz,.*": description: Overkiz SAS "^ovti,.*":
PATCH v3 3/3 dt-bindings: ARM: tegra: Add Ouya game console
In reply to Peter GeisAdd a binding for the Tegra30-based Ouya game console.
--- Documentation/devicetree/bindings/arm/tegra.yaml | 3 +++ 1 file changed, 3 insertions(+)
Documentation/devicetree/bindings/arm/tegra.yaml +3 -0
@@ -69,6 +69,9 @@ properties: - const: asus,tilapia - const: asus,grouper - const: nvidia,tegra30 + - items: + - const: ouya,ouya + - const: nvidia,tegra30 - items: - enum: - nvidia,dalmore
Signature · 1 line
2.25.1
Re: [PATCH v3 3/3] dt-bindings: ARM: tegra: Add Ouya game console
04.10.2020 16:31, Peter Geis пишет:
Quoted 14 lines
Add a binding for the Tegra30-based Ouya game console.
Signed-off-by Peter Geis <[email protected]>Acked-by Rob Herring <[email protected]>--- Documentation/devicetree/bindings/arm/tegra.yaml | 3 +++ 1 file changed, 3 insertions(+)Documentation/devicetree/bindings/arm/tegra.yaml +0
-0
Documentation/devicetree/bindings/arm/tegra.yaml properties: · line 77
Quoted 9 lines
Documentation/devicetree/bindings/arm/tegra.yaml +3
-0@@ -69,6 +69,9 @@ properties: - const: asus,tilapia - const: asus,grouper - const: nvidia,tegra30 + - items: + - const: ouya,ouya + - const: nvidia,tegra30 - items: - enum: - nvidia,dalmore
Quoted 19 lines · Peter Geis
Good Day,
This series introduces upstream kernel support for the Ouya game console device. Please review and apply. Thank you in advance.
Changelog:
v3: - Reorder aliases per Dmitry Osipenko's review.
- Add sdio clocks per Dmitry Osipenko's review.
- Add missing ti sleep bits per Dmitry Osipenko's review.
- Enable lp1 sleep mode.
- Fix bluetooth comment and add missing power supplies.v2: - Update pmic and clock handles per Rob Herring's review.
- Add acks from Rob Herring to patch 2 and 3.Peter Geis (3):
ARM: tegra: Add device-tree for Ouya
dt-bindings: Add vendor prefix for Ouya Inc.
dt-bindings: ARM: tegra: Add Ouya game console
Quoted 6 lines
.../devicetree/bindings/arm/tegra.yaml | 3 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/tegra30-ouya.dts | 4511 +++++++++++++++++ 4 files changed, 4518 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/tegra30-ouya.dts
This looks good to me and I see that Dmitry is happy with it. I'll make a mental note to apply it after the merge window closes.
Thanks,
Thierry
Hi Peter,
Quoted 4 lines · Peter Geis
Good Day,
This series introduces upstream kernel support for the Ouya game console device. Please review and apply. Thank you in advance.
Interesting patchset, maybe I can give my Ouya a second live now :-) Do you happen to have (a link) to instructions how to flash the device?
Btw, there was also a driver for the Bluetooth controller on the ML once, maybe a good time to revive that:
https://spinics.net/lists/linux-input/msg56288.html
--
Stefan
Quoted 22 lines
Changelog:
v3: - Reorder aliases per Dmitry Osipenko's review.
- Add sdio clocks per Dmitry Osipenko's review.
- Add missing ti sleep bits per Dmitry Osipenko's review.
- Enable lp1 sleep mode.
- Fix bluetooth comment and add missing power supplies.v2: - Update pmic and clock handles per Rob Herring's review.
- Add acks from Rob Herring to patch 2 and 3.Peter Geis (3):
ARM: tegra: Add device-tree for Ouya
dt-bindings: Add vendor prefix for Ouya Inc.
dt-bindings: ARM: tegra: Add Ouya game console.../devicetree/bindings/arm/tegra.yaml | 3 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/tegra30-ouya.dts | 4511 +++++++++++++++++ 4 files changed, 4518 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/tegra30-ouya.dts
Hi all,
The Bluetooth controller driver sent to linux-input by Lukas Rusak (CC'd) is a bit of a concern. Here is the original driver:
https://github.com/ouya/ouya_1_1-kernel/blob/master/drivers/hid/hid-ouya.c
and you can see that there is no SPDX header, no license information and no MODULE_LICENSE declaration. I'd previously noticed this as a possible cause for concern in upstreaming the driver.
Meanwhile, Lukas's driver is clearly derived from the Ouya Inc. driver and even retains the Ouya Inc. copyright notice line. However, Lukas's driver now has a MODULE_LICENSE("GPL") declaration added.
Lukas, did you get clear permission to license the driver as GPL?
Alternatively, kernel developers with greater legal or Ouya knowledge, is this actually a concern or is it nothing to worry about?
Thanks,
Bob
Quoted 41 lines · Stefan Agner
Hi Peter,
Quoted 4 lines · Peter Geis
Good Day,
This series introduces upstream kernel support for the Ouya game console device. Please review and apply. Thank you in advance.
Interesting patchset, maybe I can give my Ouya a second live now :-) Do you happen to have (a link) to instructions how to flash the device?
Btw, there was also a driver for the Bluetooth controller on the ML once, maybe a good time to revive that:
https://spinics.net/lists/linux-input/msg56288.html--
StefanQuoted 22 lines
Changelog:
v3: - Reorder aliases per Dmitry Osipenko's review.
- Add sdio clocks per Dmitry Osipenko's review.
- Add missing ti sleep bits per Dmitry Osipenko's review.
- Enable lp1 sleep mode.
- Fix bluetooth comment and add missing power supplies.v2: - Update pmic and clock handles per Rob Herring's review.
- Add acks from Rob Herring to patch 2 and 3.Peter Geis (3):
ARM: tegra: Add device-tree for Ouya
dt-bindings: Add vendor prefix for Ouya Inc.
dt-bindings: ARM: tegra: Add Ouya game console.../devicetree/bindings/arm/tegra.yaml | 3 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/tegra30-ouya.dts | 4511 +++++++++++++++++ 4 files changed, 4518 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/tegra30-ouya.dts
07.10.2020 16:36, Bob Ham пишет:
Quoted 11 lines
Hi all,
The Bluetooth controller driver sent to linux-input by Lukas Rusak (CC'd) is a bit of a concern. Here is the original driver:
https://github.com/ouya/ouya_1_1-kernel/blob/master/drivers/hid/hid-ouya.c
and you can see that there is no SPDX header, no license information and no
MODULE_LICENSEdeclaration. I'd previously noticed this as a possible cause for concern in upstreaming the driver.
Quoted 8 lines
Meanwhile, Lukas's driver is clearly derived from the Ouya Inc. driver and even retains the Ouya Inc. copyright notice line. However, Lukas's driver now has a
MODULE_LICENSE("GPL")declaration added.Lukas, did you get clear permission to license the driver as GPL?
Alternatively, kernel developers with greater legal or Ouya knowledge, is this actually a concern or is it nothing to worry about?
Hello Bob,
That can't be a problem because:
1. Ouya Inc. doesn't exists anymore.
2. If code was officially published, then this implies that it can be derived.
3. Ouya's driver uses kernel symbols that are explicitly marked as GPL-only, see hid_open_report for example. Hence Ouya's driver inherents the GPL license.
4. Lukas's patch doesn't remind the original code at all.
5. In practice nobody cares about legal much if money aren't involved. Even if it happened that driver was 100% violating some copyrights, then it either won't be accepted to upstream or will be removed by request from the copyrights holder.
...
Quoted 3 lines
3. Ouya's driver uses kernel symbols that are explicitly marked as GPL-only, see
hid_open_reportfor example. Hence Ouya's driver inherents the GPL license.
Actually, the __hid_register_driver is a better example because hid_open_report didn't exist when Ouya's driver was created.
Quoted 34 lines · Dmitry Osipenko
07.10.2020 16:36, Bob Ham пишет:
Quoted 11 lines
Hi all,
The Bluetooth controller driver sent to linux-input by Lukas Rusak (CC'd) is a bit of a concern. Here is the original driver:
https://github.com/ouya/ouya_1_1-kernel/blob/master/drivers/hid/hid-ouya.c
and you can see that there is no SPDX header, no license information and no
MODULE_LICENSEdeclaration. I'd previously noticed this as a possible cause for concern in upstreaming the driver.Quoted 8 lines
Meanwhile, Lukas's driver is clearly derived from the Ouya Inc. driver and even retains the Ouya Inc. copyright notice line. However, Lukas's driver now has a
MODULE_LICENSE("GPL")declaration added.Lukas, did you get clear permission to license the driver as GPL?
Alternatively, kernel developers with greater legal or Ouya knowledge, is this actually a concern or is it nothing to worry about?
Hello Bob,
That can't be a problem because:
1. Ouya Inc. doesn't exists anymore.
2. If code was officially published, then this implies that it can be derived.
3. Ouya's driver uses kernel symbols that are explicitly marked as GPL-only, see
hid_open_reportfor example. Hence Ouya's driver inherents the GPL license.
Quoted 6 lines
4. Lukas's patch doesn't remind the original code at all.
5. In practice nobody cares about legal much if money aren't involved. Even if it happened that driver was 100% violating some copyrights, then it either won't be accepted to upstream or will be removed by request from the copyrights holder.
This definitely isn't the correct attitude to copyright.
The facts[1] that Ouya published the code and that it used GPL-only symbols certainly does imply that they *should* have published under GPL or a compatible license, but doesn't mean that they definitely did. The only way to know that for sure is for there to be evidence in the file content or git history, such as license headers or Signed-off-by lines.
When someone writes Signed-off-by in their code submission, which is required to contribute to upstream Linux, they are stating/warranting certain things about the code they're submitting. One aspect is that they definitely have the rights to submit the code under the given license. Without evidence to this effect, or having written the code themselves, nobody can state/warrant this. Take a look at the following link to see what you're stating/warranting when writing Signed-off-by in a code submission:
https://developercertificate.org/
[1] I haven't checked the facts.
Quoted 19 lines · Stephen Warren
This definitely isn't the correct attitude to copyright.
The facts[1] that Ouya published the code and that it used GPL-only symbols certainly does imply that they *should* have published under GPL or a compatible license, but doesn't mean that they definitely did. The only way to know that for sure is for there to be evidence in the file content or git history, such as license headers or Signed-off-by lines.
When someone writes Signed-off-by in their code submission, which is required to contribute to upstream Linux, they are stating/warranting certain things about the code they're submitting. One aspect is that they definitely have the rights to submit the code under the given license. Without evidence to this effect, or having written the code themselves, nobody can state/warrant this. Take a look at the following link to see what you're stating/warranting when writing Signed-off-by in a code submission:
Quoted 3 lines
https://developercertificate.org/
[1] I haven't checked the facts.
Unfortunately the only source release I've been able to find is the last release.
Ouya purposely purged the git history for the current source release, it's also completely lacking in signoffs and commit history.
[1] is the commit that added this driver to their source.
Their original source release had the git history intact, but I never got a copy of it before Ouya purged it from their repos.
[1] https://github.com/ouya/ouya_1_1-kernel/commit/407e72990e39d5c29d015e21110b9497aea2dfe3
07.10.2020 19:08, Stephen Warren пишет:
...
Quoted 5 lines
The facts[1] that Ouya published the code and that it used GPL-only symbols certainly does imply that they *should* have published under GPL or a compatible license, but doesn't mean that they definitely did. The only way to know that for sure is for there to be evidence in the file content or git history, such as license headers or Signed-off-by lines.
The code wasn't only published, but also was distributed in a binary form to end users. This means that even if Ouya Inc. still existed and they made a mistake by using GPL-only symbols plus GPL-incompatible license for the driver, then they had to resilience the code. Hence either way it's okay to use downstream code as a reference for the upstream driver.
This is my understanding.
Thierry Reding
AppliedQuoted 19 lines · Peter Geis
Good Day,
This series introduces upstream kernel support for the Ouya game console device. Please review and apply. Thank you in advance.
Changelog:
v3: - Reorder aliases per Dmitry Osipenko's review.
- Add sdio clocks per Dmitry Osipenko's review.
- Add missing ti sleep bits per Dmitry Osipenko's review.
- Enable lp1 sleep mode.
- Fix bluetooth comment and add missing power supplies.v2: - Update pmic and clock handles per Rob Herring's review.
- Add acks from Rob Herring to patch 2 and 3.Peter Geis (3):
ARM: tegra: Add device-tree for Ouya
dt-bindings: Add vendor prefix for Ouya Inc.
dt-bindings: ARM: tegra: Add Ouya game console
Quoted 6 lines
.../devicetree/bindings/arm/tegra.yaml | 3 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/tegra30-ouya.dts | 4511 +++++++++++++++++ 4 files changed, 4518 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/tegra30-ouya.dts
Applied, thanks.
Thierry