arm64: dts: rockchip: add missing address and size cells for rk3399 mipi dsi
Subsystems (2)
Heiko Stuebner
maintainerPATCH 1/3 arm64: dts: rockchip: add missing address and size cells for rk3399 mipi dsi
DSI controllers are also the hosts of their dsi bus and therefore contain nodes describing the attached panels with their reg properties containing the virtual ids.
The dsi controller nodes on rk3399 lacked the #address-cells and #size-cells for these subnodes, so add them.
--- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm64/boot/dts/rockchip/rk3399.dtsi +4 -0
@@ -1720,6 +1720,8 @@ resets = <&cru SRST_P_MIPI_DSI0>; reset-names = "apb"; rockchip,grf = <&grf>; + #address-cells = <1>; + #size-cells = <0>; status = "disabled"; ports {
@@ -1754,6 +1756,8 @@ resets = <&cru SRST_P_MIPI_DSI1>; reset-names = "apb"; rockchip,grf = <&grf>; + #address-cells = <1>; + #size-cells = <0>; status = "disabled"; ports {
Signature · 1 line
2.17.0
Heiko Stuebner
maintainerPATCH 1/3 arm64: dts: rockchip: add missing address and size cells for rk3399 mipi dsi
Am Mittwoch, 22. August 2018, 14:02:12 CEST schrieb Heiko Stuebner:
Quoted 8 lines
DSI controllers are also the hosts of their dsi bus and therefore contain nodes describing the attached panels with their reg properties containing the virtual ids.
The dsi controller nodes on rk3399 lacked the #address-cells and #size-cells for these subnodes, so add them.
Signed-off-by Heiko Stuebner <[email protected]>
applied the easy one for 4.20
Quoted 27 lines
--- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++++ 1 file changed, 4 insertions(+)arch/arm64/boot/dts/rockchip/rk3399.dtsi +4
-0@@ -1720,6 +1720,8 @@ resets = <&cru SRST_P_MIPI_DSI0>; reset-names = "apb"; rockchip,grf = <&grf>; + #address-cells = <1>; + #size-cells = <0>; status = "disabled"; ports {@@ -1754,6 +1756,8 @@ resets = <&cru SRST_P_MIPI_DSI1>; reset-names = "apb"; rockchip,grf = <&grf>; + #address-cells = <1>; + #size-cells = <0>; status = "disabled"; ports {
Heiko Stuebner
maintainerPATCH 2/3 dt-bindings: firmware: coreboot: document board variant properties
In reply to Heiko StuebnerSince at least 2014 coreboot exports board specific variant ids for board-revision, used ram-modules and component variants on the same board into the loaded devicetree.
These are set on all devicetree-based Chromebooks since then, so at least we can make the effort to document these long-used properties.
A case where these are used is for example to determine the touchscreen type that is only identifyable via the sku-id when updating its firmware on the Scarlet tablet from the Gru ChromeOS family.
--- Documentation/devicetree/bindings/firmware/coreboot.txt | 6 ++++++ 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/firmware/coreboot.txt +6 -0
@@ -21,6 +21,12 @@ Required properties: 0xc0389481 that resides in the topmost 8 bytes of the area. See coreboot's src/include/imd.h for details. +Board variant properties determined via strapping measures (like gpios): + - board-id: board-specific id indicating the board-revision + - ram-code: board-specific id identifying the used ram-module + - sku-id: board-specific id indicating a variant (using different + display panels for example) + Example: firmware { ranges;
Signature · 1 line
2.17.0
Rob Herring
maintainerPATCH 2/3 dt-bindings: firmware: coreboot: document board variant properties
Quoted 6 lines · Heiko Stuebner
Since at least 2014 coreboot exports board specific variant ids for board-revision, used ram-modules and component variants on the same board into the loaded devicetree.
These are set on all devicetree-based Chromebooks since then, so at least we can make the effort to document these long-used properties.
Long used, but never reviewed, so that doesn't really matter.
Quoted 15 lines
A case where these are used is for example to determine the touchscreen type that is only identifyable via the sku-id when updating its firmware on the Scarlet tablet from the Gru ChromeOS family.
Signed-off-by Heiko Stuebner <[email protected]>--- Documentation/devicetree/bindings/firmware/coreboot.txt | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/firmware/coreboot.txt +0
-0
Documentation/devicetree/bindings/firmware/coreboot.txt Required properties: · line 28
Quoted 8 lines
Documentation/devicetree/bindings/firmware/coreboot.txt +5
-0@@ -21,6 +21,12 @@ Required properties: 0xc0389481 that resides in the topmost 8 bytes of the area. See coreboot's src/include/imd.h for details. +Board variant properties determined via strapping measures (like gpios): + - board-id: board-specific id indicating the board-revision + - ram-code: board-specific id identifying the used ram-module + - sku-id: board-specific id indicating a variant (using different + display panels for example)
The appear to be consumed by coreboot, but the purpose of the /firmware nodes has describing firmware interfaces provided by the platform.
Not saying we can't put things to configure the firmware there, but it would be a departure and something we should consider. These properties aren't really coreboot specific and probably belong at the root node. Though I think we already discussed a 'board-id' property for QCom (and ended up with a compatible string approach instead.
Rob
Heiko Stuebner
maintainerPATCH 2/3 dt-bindings: firmware: coreboot: document board variant properties
Hi Rob,
Am Freitag, 31. August 2018, 14:18:36 CEST schrieb Rob Herring:
Quoted 37 lines · Heiko Stuebner
Quoted 6 lines
Since at least 2014 coreboot exports board specific variant ids for board-revision, used ram-modules and component variants on the same board into the loaded devicetree.
These are set on all devicetree-based Chromebooks since then, so at least we can make the effort to document these long-used properties.
Long used, but never reviewed, so that doesn't really matter.
Quoted 15 lines
A case where these are used is for example to determine the touchscreen type that is only identifyable via the sku-id when updating its firmware on the Scarlet tablet from the Gru ChromeOS family.
Signed-off-by Heiko Stuebner <[email protected]>--- Documentation/devicetree/bindings/firmware/coreboot.txt | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/firmware/coreboot.txt +0
-0Documentation/devicetree/bindings/firmware/coreboot.txt Required properties: · line 28
Quoted 8 lines
Documentation/devicetree/bindings/firmware/coreboot.txt +5
-0@@ -21,6 +21,12 @@ Required properties: 0xc0389481 that resides in the topmost 8 bytes of the area. See coreboot's src/include/imd.h for details. +Board variant properties determined via strapping measures (like gpios): + - board-id: board-specific id indicating the board-revision + - ram-code: board-specific id identifying the used ram-module + - sku-id: board-specific id indicating a variant (using different + display panels for example)The appear to be consumed by coreboot, but the purpose of the /firmware nodes has describing firmware interfaces provided by the platform.
Quoted 5 lines
Not saying we can't put things to configure the firmware there, but it would be a departure and something we should consider. These properties aren't really coreboot specific and probably belong at the root node. Though I think we already discussed a 'board-id' property for QCom (and ended up with a compatible string approach instead.
These are not for configuring the firmware. Coreboot is reading the values from hardware-strappings, like special gpios and inserts the properties into the devicetree for the kernel or userspace to read back if needed.
So coreboot loads a devicetree without them from the boot-partition and amends that devicetree we these properties.
As indicated above, devices since 2014 do that, so I thought it might make sense to document that behaviour.
Heiko
Rob Herring
maintainerPATCH 2/3 dt-bindings: firmware: coreboot: document board variant properties
Quoted 50 lines · Heiko Stuebner
Hi Rob,
Am Freitag, 31. August 2018, 14:18:36 CEST schrieb Rob Herring:
Quoted 37 lines · Heiko Stuebner
Quoted 6 lines
Since at least 2014 coreboot exports board specific variant ids for board-revision, used ram-modules and component variants on the same board into the loaded devicetree.
These are set on all devicetree-based Chromebooks since then, so at least we can make the effort to document these long-used properties.
Long used, but never reviewed, so that doesn't really matter.
Quoted 15 lines
A case where these are used is for example to determine the touchscreen type that is only identifyable via the sku-id when updating its firmware on the Scarlet tablet from the Gru ChromeOS family.
Signed-off-by Heiko Stuebner <[email protected]>--- Documentation/devicetree/bindings/firmware/coreboot.txt | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/firmware/coreboot.txt +0
-0Documentation/devicetree/bindings/firmware/coreboot.txt Required properties: · line 28
Quoted 8 lines
Documentation/devicetree/bindings/firmware/coreboot.txt +5
-0@@ -21,6 +21,12 @@ Required properties: 0xc0389481 that resides in the topmost 8 bytes of the area. See coreboot's src/include/imd.h for details. +Board variant properties determined via strapping measures (like gpios): + - board-id: board-specific id indicating the board-revision + - ram-code: board-specific id identifying the used ram-module + - sku-id: board-specific id indicating a variant (using different + display panels for example)The appear to be consumed by coreboot, but the purpose of the /firmware nodes has describing firmware interfaces provided by the platform.
Quoted 5 lines
Not saying we can't put things to configure the firmware there, but it would be a departure and something we should consider. These properties aren't really coreboot specific and probably belong at the root node. Though I think we already discussed a 'board-id' property for QCom (and ended up with a compatible string approach instead.
These are not for configuring the firmware. Coreboot is reading the values from hardware-strappings, like special gpios and inserts the properties into the devicetree for the kernel or userspace to read back if needed.
Quoted 5 lines
So coreboot loads a devicetree without them from the boot-partition and amends that devicetree we these properties.
As indicated above, devices since 2014 do that, so I thought it might make sense to document that behaviour.
Reading strapping values and putting into DT seems like a perfectly reasonable thing to do (I'm assuming the pins get initialized to their function and reading them later is not possible), but that has nothing to do coreboot really. We don't put things u-boot touches under a u-boot node. These should go at the top-level IMO.
And maybe it is compelling to just take them having been in use for some time on widely deploying devices, but that's not really good precedence.
Rob
PATCH 2/3 dt-bindings: firmware: coreboot: document board variant properties
Quoted 5 lines · Rob Herring
Reading strapping values and putting into DT seems like a perfectly reasonable thing to do (I'm assuming the pins get initialized to their function and reading them later is not possible), but that has nothing to do coreboot really. We don't put things u-boot touches under a u-boot node. These should go at the top-level IMO.
Where, exactly? Do you have a suggested property name?
Regarding compatible-based approach (from prior email): we do heavily use the top-level 'compatible' property too for a similar purpose, but sometimes there's a useful difference between "I booted with DTB <foo>, which is compatible with revision X, Y, Z, ..." and "the exact revision I booted is N". So the properties are definitely useful.
Quoted 2 lines
And maybe it is compelling to just take them having been in use for some time on widely deploying devices, but that's not really good precedence.
Well, we ain't changing the old firmware. Coming up with a new name can work, and we can modify new firmware to start doing both. But it'd still probably be wise to note what's actively in-use, especially if it's not substantively different than what we settle on.
Brian
Heiko Stuebner
maintainerPATCH 3/3 arm64: dts: rockchip: add Gru Scarlet devicetrees
In reply to Heiko StuebnerGru-Scarlet is a tablet device using ChomeOS, dual-dsi display and Wacom touchscreen with stylus.
There exist two variants in the market using different displays that are differentiated via their sku-id.
The bootloader on them also determines the correct devicetree to load via the sku-id.
So add a common scarlet dtsi and two minimal board devicetrees for the two display variants.
--- .../devicetree/bindings/arm/rockchip.txt | 34 + arch/arm64/boot/dts/rockchip/Makefile | 2 + .../dts/rockchip/rk3399-gru-scarlet-inx.dts | 33 + .../dts/rockchip/rk3399-gru-scarlet-kd.dts | 46 ++ .../boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 594 ++++++++++++++++++ 5 files changed, 709 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi
Documentation/devicetree/bindings/arm/rockchip.txt +34 -0
@@ -144,6 +144,40 @@ Rockchip platforms device tree bindings - compatible = "google,veyron-pinky-rev2", "google,veyron-pinky", "google,veyron", "rockchip,rk3288"; +- Google Scarlet - with display from Kingdisplay + Required root node properties: + - compatible = "google,scarlet-rev15-sku7", "google,scarlet-rev15", + "google,scarlet-rev14-sku7", "google,scarlet-rev14", + "google,scarlet-rev13-sku7", "google,scarlet-rev13", + "google,scarlet-rev12-sku7", "google,scarlet-rev12", + "google,scarlet-rev11-sku7", "google,scarlet-rev11", + "google,scarlet-rev10-sku7", "google,scarlet-rev10", + "google,scarlet-rev9-sku7", "google,scarlet-rev9", + "google,scarlet-rev8-sku7", "google,scarlet-rev8", + "google,scarlet-rev7-sku7", "google,scarlet-rev7", + "google,scarlet-rev6-sku7", "google,scarlet-rev6", + "google,scarlet-rev5-sku7", "google,scarlet-rev5", + "google,scarlet-rev4-sku7", "google,scarlet-rev4", + "google,scarlet-rev3-sku7", "google,scarlet-rev3", + "google,scarlet", "google,gru", "rockchip,rk3399"; + +- Google Scarlet - with display from Innolux + Required root node properties: + - compatible = "google,scarlet-rev15-sku6", "google,scarlet-rev15", + "google,scarlet-rev14-sku6", "google,scarlet-rev14", + "google,scarlet-rev13-sku6", "google,scarlet-rev13", + "google,scarlet-rev12-sku6", "google,scarlet-rev12", + "google,scarlet-rev11-sku6", "google,scarlet-rev11", + "google,scarlet-rev10-sku6", "google,scarlet-rev10", + "google,scarlet-rev9-sku6", "google,scarlet-rev9", + "google,scarlet-rev8-sku6", "google,scarlet-rev8", + "google,scarlet-rev7-sku6", "google,scarlet-rev7", + "google,scarlet-rev6-sku6", "google,scarlet-rev6", + "google,scarlet-rev5-sku6", "google,scarlet-rev5", + "google,scarlet-rev4-sku6", "google,scarlet-rev4", + "google,scarlet", "google,gru", "rockchip,rk3399"; + + - Google Speedy (Asus C201 Chromebook): Required root node properties: - compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
arch/arm64/boot/dts/rockchip/Makefile +2 -0
@@ -14,6 +14,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-ficus.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-bob.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-inx.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-kd.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dts new file +33 -0
@@ -0,0 +1,33 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Google Gru-Scarlet Rev4+ (SKU-6/Innolux) board device tree source + * + * Copyright 2018 Google, Inc + */ + +/dts-v1/; + +#include "rk3399-gru-scarlet.dtsi" + +/ { + model = "Google Scarlet"; + compatible = "google,scarlet-rev15-sku6", "google,scarlet-rev15", + "google,scarlet-rev14-sku6", "google,scarlet-rev14", + "google,scarlet-rev13-sku6", "google,scarlet-rev13", + "google,scarlet-rev12-sku6", "google,scarlet-rev12", + "google,scarlet-rev11-sku6", "google,scarlet-rev11", + "google,scarlet-rev10-sku6", "google,scarlet-rev10", + "google,scarlet-rev9-sku6", "google,scarlet-rev9", + "google,scarlet-rev8-sku6", "google,scarlet-rev8", + "google,scarlet-rev7-sku6", "google,scarlet-rev7", + "google,scarlet-rev6-sku6", "google,scarlet-rev6", + "google,scarlet-rev5-sku6", "google,scarlet-rev5", + "google,scarlet-rev4-sku6", "google,scarlet-rev4", + "google,scarlet", "google,gru", "rockchip,rk3399"; +}; + +&mipi_panel { + compatible = "innolux,p097pfg"; + avdd-supply = <&ppvarp_lcd>; + avee-supply = <&ppvarn_lcd>; +};
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dts new file +46 -0
46 lines not on this page · raw message
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi new file +594 -0
594 lines not on this page · raw message
Signature · 1 line
2.17.0