ARM: dts: rockchip: reserve unusable memory region on rk3288
Heiko Stübner
maintainerPATCH v2 1/2 ARM: dts: rockchip: reserve unusable memory region on rk3288
The all current Rockchip SoCs supporting 4GB of ram have problems accessing the memory region 0xfe000000~0xff000000. This also seems to includes the rk3368 arm64 soc.
All current code handling dma memory oddities I could find, seem to involve soc-specific code (zone-dma or so) while this issue is shared between arm32 and arm64 socs from Rockchip, which would need to have this described in the soc devicetree on both socs.
Limiting the dma-zone alone also does not solve the issue and as the dma-masks need to be a power-of-two in the kernel, the next lower dma-mask brings memory usable for dma down to 2GB.
So as a stop-gap block off the affected region to prevent its use by devices with 4GB of memory, like some recent Chromebooks.
---
changes since v1:
- expand reasons for the reserved memory
arch/arm/boot/dts/rk3288.dtsi | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
arch/arm/boot/dts/rk3288.dtsi +20 -0
@@ -169,6 +169,26 @@ }; }; + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + /* + * The rk3288 cannot use the memory area above 0xfe000000 + * for dma operations for some reason. While there is + * probably a better solution available somewhere, we + * haven't found it yet and while devices with 2GB of ram + * are not affected, this issue prevents 4GB from booting. + * So to make these devices at least bootable, block + * this area for the time being until the real solution + * is found. + */ + dma-unusable at fe000000 { + reg = <0xfe000000 0x1000000>; + }; + }; + xin24m: oscillator { compatible = "fixed-clock"; clock-frequency = <24000000>;
Signature · 1 line
2.1.4
Heiko Stübner
maintainerPATCH v2 2/2 ARM: dts: rockchip: add veyron-minnie board
From: Alexandru M Stan <[email protected]>
Also known as the Asus Chromebook Flip.
--- Documentation/devicetree/bindings/arm/rockchip.txt | 7 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-minnie.dts | 253 +++++++++++++++++++++ 3 files changed, 261 insertions(+) create mode 100644 arch/arm/boot/dts/rk3288-veyron-minnie.dts
Documentation/devicetree/bindings/arm/rockchip.txt +7 -0
@@ -38,6 +38,13 @@ Rockchip platforms device tree bindings "google,veyron-jerry-rev3", "google,veyron-jerry", "google,veyron", "rockchip,rk3288"; +- Google Minnie (Asus Chromebook Flip C100P): + Required root node properties: + - compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3", + "google,veyron-minnie-rev2", "google,veyron-minnie-rev1", + "google,veyron-minnie-rev0", "google,veyron-minnie", + "google,veyron", "rockchip,rk3288"; + - Google Pinky (dev-board): Required root node properties: - compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
arch/arm/boot/dts/Makefile +1 -0
@@ -491,6 +491,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3288-firefly.dtb \ rk3288-r89.dtb \ rk3288-veyron-jerry.dtb \ + rk3288-veyron-minnie.dtb \ rk3288-veyron-pinky.dtb \ rk3288-veyron-speedy.dtb dtb-$(CONFIG_ARCH_S3C24XX) += \
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +253 -0
253 lines not on this page · raw message
Signature · 1 line
2.1.4
PATCH v2 2/2 ARM: dts: rockchip: add veyron-minnie board
Heiko,
Quoted 22 lines · Heiko St?bner
+&i2c3 {
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +21
-0+ status = "okay"; + + /* + * Touchscreen pin control is shared between Atmel and Elan devices, + * so we have to pull it up to the bus level. + */ + pinctrl-names = "default"; + pinctrl-0 = <&i2c3_xfer &touch_int &touch_rst>; + + clock-frequency = <400000>; + i2c-scl-falling-time-ns = <50>; + i2c-scl-rising-time-ns = <300>; + + touchscreen at 10 { + compatible = "elan,ekth3500"; + reg = <0x10>; + interrupt-parent = <&gpio2>; + interrupts = <14 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>; + vcc33-supply = <&vcc33_touch>; + vccio-supply = <&vcc33_touch>;
arch/arm/boot/dts/rk3288-veyron-minnie.dts line 145
Quoted 10 lines
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +10
-0+ }; + + touchscreen at 4a { + compatible = "atmel,atmel_mxt_ts"; + reg = <0x4a>; + atmel,reset-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>; + avdd-supply = <&vcc5v_touch>; + interrupt-parent = <&gpio2>; + interrupts = <14 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&vcc33_touch>;
Technically I don't think most of these properties exist upstream, but Dmitry (now CCed) might know more.
...actually similar for elan. At least I don't see 'reset-gpios', nor 'vcc33-supply' and 'vccio-supply' in the bindings when I checkout linuxnext...
Oh, and also locally our tree has hacks in it to handle the fact that both atmel and elan will try to grab the same reset GPIO. I'm nearly certain that Dmitry said that the current hacks we have wouldn't be appropriate for upstream. I had some proposals for better solutions, but they were slightly more controversial. In any case, I think all shipping devices ended up using one or the other of these two touchscreens (I forget which), so you could probably simplify and just pick one of them. If old prototype devices don't work upstream it wouldn't be the end of the world.
Everything else looks fine to me, so if you avoid using non-upstream properties for the touchscreens then you can add my Reviewed-by.
-Doug
PATCH v2 2/2 ARM: dts: rockchip: add veyron-minnie board
Quoted 39 lines · Doug Anderson
Heiko,
Quoted 22 lines · Heiko St?bner
+&i2c3 {
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +21
-0+ status = "okay"; + + /* + * Touchscreen pin control is shared between Atmel and Elan devices, + * so we have to pull it up to the bus level. + */ + pinctrl-names = "default"; + pinctrl-0 = <&i2c3_xfer &touch_int &touch_rst>; + + clock-frequency = <400000>; + i2c-scl-falling-time-ns = <50>; + i2c-scl-rising-time-ns = <300>; + + touchscreen at 10 { + compatible = "elan,ekth3500"; + reg = <0x10>; + interrupt-parent = <&gpio2>; + interrupts = <14 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>; + vcc33-supply = <&vcc33_touch>; + vccio-supply = <&vcc33_touch>;arch/arm/boot/dts/rk3288-veyron-minnie.dts line 145
Quoted 10 lines
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +10
-0+ }; + + touchscreen at 4a { + compatible = "atmel,atmel_mxt_ts"; + reg = <0x4a>; + atmel,reset-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>; + avdd-supply = <&vcc5v_touch>; + interrupt-parent = <&gpio2>; + interrupts = <14 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&vcc33_touch>;Technically I don't think most of these properties exist upstream, but Dmitry (now CCed) might know more.
Quoted 4 lines
...actually similar for elan. At least I don't see 'reset-gpios', nor 'vcc33-supply' and 'vccio-supply' in the bindings when I checkout linuxnext...
I just merged the Elan regulator/gpio support, it will show up in the next next.
Quoted 9 lines
Oh, and also locally our tree has hacks in it to handle the fact that both atmel and elan will try to grab the same reset GPIO. I'm nearly certain that Dmitry said that the current hacks we have wouldn't be appropriate for upstream. I had some proposals for better solutions, but they were slightly more controversial. In any case, I think all shipping devices ended up using one or the other of these two touchscreens (I forget which), so you could probably simplify and just pick one of them. If old prototype devices don't work upstream it wouldn't be the end of the world.
I think if you pick Elan for this board it will cover majority (all?) devices that actually shipped.
Thanks.
Signature · 1 line
Dmitry
Heiko Stübner
maintainerPATCH v2 2/2 ARM: dts: rockchip: add veyron-minnie board
Am Freitag, 7. August 2015, 15:13:13 schrieb Dmitry Torokhov:
Quoted 56 lines · Doug Anderson
Quoted 39 lines
Heiko,
Quoted 22 lines · Heiko St?bner
+&i2c3 {
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +4
-0+ status = "okay"; + + /* + * Touchscreen pin control is shared between Atmel and Elandevices, + * so we have to pull it up to the bus level.
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +16
-0+ */ + pinctrl-names = "default"; + pinctrl-0 = <&i2c3_xfer &touch_int &touch_rst>; + + clock-frequency = <400000>; + i2c-scl-falling-time-ns = <50>; + i2c-scl-rising-time-ns = <300>; + + touchscreen at 10 { + compatible = "elan,ekth3500"; + reg = <0x10>; + interrupt-parent = <&gpio2>; + interrupts = <14 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>; + vcc33-supply = <&vcc33_touch>; + vccio-supply = <&vcc33_touch>;arch/arm/boot/dts/rk3288-veyron-minnie.dts line 145
Quoted 10 lines
arch/arm/boot/dts/rk3288-veyron-minnie.dts new file +10
-0+ }; + + touchscreen at 4a { + compatible = "atmel,atmel_mxt_ts"; + reg = <0x4a>; + atmel,reset-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>; + avdd-supply = <&vcc5v_touch>; + interrupt-parent = <&gpio2>; + interrupts = <14 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&vcc33_touch>;Technically I don't think most of these properties exist upstream, but Dmitry (now CCed) might know more.
Quoted 3 lines
...actually similar for elan. At least I don't see 'reset-gpios', nor 'vcc33-supply' and 'vccio-supply' in the bindings when I checkout linuxnext...
I just merged the Elan regulator/gpio support, it will show up in the next next.
Quoted 9 lines
Oh, and also locally our tree has hacks in it to handle the fact that both atmel and elan will try to grab the same reset GPIO. I'm nearly certain that Dmitry said that the current hacks we have wouldn't be appropriate for upstream. I had some proposals for better solutions, but they were slightly more controversial. In any case, I think all shipping devices ended up using one or the other of these two touchscreens (I forget which), so you could probably simplify and just pick one of them. If old prototype devices don't work upstream it wouldn't be the end of the world.
Quoted 2 lines
I think if you pick Elan for this board it will cover majority (all?) devices that actually shipped.
I guess I'll simply drop the touchscreens for for this initial submission - at this point in time we don't have support for the internal display anyway, so I can sort out the touchscreens a bit later.
armsoc has a slightly early cutoff most of the time, so I'll try to land the initial support and worry about the smaller tidbits later :-)
Heiko
Heiko Stübner
maintainerPATCH v2 2/2 ARM: dts: rockchip: add veyron-minnie board
In reply to Heiko StübnerAm Donnerstag, 6. August 2015, 19:37:54 schrieb Heiko St?bner:
Quoted 6 lines
From: Alexandru M Stan <[email protected]>
Also known as the Asus Chromebook Flip.
Signed-off-by Alexandru M Stan <[email protected]>Signed-off-by Heiko Stuebner <[email protected]>
applied both patches with Dougs Reviewed-by after dropping the touchscreen nodes from the initial set.
PATCH v2 1/2 ARM: dts: rockchip: reserve unusable memory region on rk3288
In reply to Heiko StübnerHeiko,
Quoted 16 lines · Heiko St?bner
The all current Rockchip SoCs supporting 4GB of ram have problems accessing the memory region 0xfe000000~0xff000000. This also seems to includes the rk3368 arm64 soc.
All current code handling dma memory oddities I could find, seem to involve soc-specific code (zone-dma or so) while this issue is shared between arm32 and arm64 socs from Rockchip, which would need to have this described in the soc devicetree on both socs.
Limiting the dma-zone alone also does not solve the issue and as the dma-masks need to be a power-of-two in the kernel, the next lower dma-mask brings memory usable for dma down to 2GB.
So as a stop-gap block off the affected region to prevent its use by devices with 4GB of memory, like some recent Chromebooks.
Quoted 7 lines
Signed-off-by Heiko Stuebner <[email protected]>---
changes since v1:
- expand reasons for the reserved memoryarch/arm/boot/dts/rk3288.dtsi | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
As discussed earlier, I'm now convinced that this is an appropriate stopgap. ...and the description looks good to me.