summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/rk3288-veyron-mickey.dts
AgeCommit message (Collapse)Author
2019-06-04ARM: dts: rockchip: Add pin names for rk3288-veyron jaq, mickey, speedyDouglas Anderson
This is like commit 0ca87bd5baa6 ("ARM: dts: rockchip: Add pin names for rk3288-veyron-jerry") and commit ca3516b32cd9 ("ARM: dts: rockchip: Add pin names for rk3288-veyron-minnie") but for 3 more veyron boards. A few notes: - While there is most certainly duplication between all the veyron boards, it still feels like it is sane to just have each board have a full list of its pin names. The format of "gpio-line-names" does not lend itself to one-off overriding and besides it seems sane to more fully match schematic names. Also note that the extra duplication here is only in source code and is unlikely to ever change (since these boards are shipped). Duplication in the .dtb files is unavoidable. - veyron-jaq and veyron-mighty are very closely related and so I have shared a single list for them both with comments on how they are different. This is just a typo fix on one of the boards, a possible missing signal on one of the boards (or perhaps I was never given the most recent schematics?) and dealing with the fact that one of the two boards has full sized SD. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-05-22ARM: dts: rockchip: Configure the GPU thermal zone for mickeyMatthias Kaehlcke
mickey crams a lot of hardware into a tiny package, which requires more aggressive thermal throttling than for devices with a larger footprint. Configure the GPU thermal zone to throttle the GPU progressively at temperatures >= 60°C. Heat dissipated by the CPUs also affects the GPU temperature, hence we cap the CPU frequency to 1.4 GHz for temperatures above 65°C. Further throttling of the CPUs may be performed by the CPU thermal zone. The configuration matches that of the downstream Chrome OS 3.14 kernel, the 'official' kernel for mickey. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-05-22ARM: dts: rockchip: Use the GPU to cool CPU thermal zone of veyron mickeyMatthias Kaehlcke
On rk3288 the CPU and GPU temperatures are correlated. Limit the GPU frequency on veyron mickey to 400 MHz for CPU temperatures >= 65°C and to 300 MHz for CPU temperatures >= 85°C. This matches the configuration of the downstream Chrome OS 3.14 kernel, the 'official' kernel for mickey. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-05-20ARM: dts: rockchip: Make rk3288-veyron-mickey's emmc work againDouglas Anderson
When I try to boot rk3288-veyron-mickey I totally fail to make the eMMC work. Specifically my logs (on Chrome OS 4.19): mmc_host mmc1: card is non-removable. mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) mmc1: switch to bus width 8 failed mmc1: switch to bus width 4 failed mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 HAG2e 14.7 GiB mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0) mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) mmc1: switch to bus width 8 failed mmc1: switch to bus width 4 failed mmc1: tried to HW reset card, got error -110 mmcblk1: error -110 requesting status mmcblk1: recovery failed! print_req_error: I/O error, dev mmcblk1, sector 0 ... When I remove the '/delete-property/mmc-hs200-1_8v' then everything is hunky dory. That line comes from the original submission of the mickey dts upstream, so presumably at the time the HS200 was failing and just enumerating things as a high speed device was fine. ...or maybe it's just that some mickey devices work when enumerating at "high speed", just not mine? In any case, hs200 seems good now. Let's turn it on. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-05-20ARM: dts: rockchip: Remove bogus 'i2s_clk_out' from rk3288-veyron-mickeyDouglas Anderson
The rk3288-veyron-mickey device tree overrides the default "i2s" clock settings to add the clock for "i2s_clk_out". That clock is only present in the bindings downstream Chrome OS 3.14 tree. Upstream the i2s port bindings doesn't specify that as a possible clock. Let's remove it. NOTE: for other rk3288-veyron devices this clock is consumed by 'maxim,max98090'. Presumably if this clock is needed for mickey it'll need to be consumed by something similar. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-11ARM: dts: rockchip: bulk convert gpios to their constant counterpartsHeiko Stuebner
Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-11-19ARM: dts: rockchip: Add all CPUs in cooling mapsViresh Kumar
Each CPU can (and does) participate in cooling down the system but the DT only captures a handful of them, normally CPU0, in the cooling maps. Things work by chance currently as under normal circumstances its the first CPU of each cluster which is used by the operating systems to probe the cooling devices. But as soon as this CPU ordering changes and any other CPU is used to bring up the cooling device, we will start seeing failures. Also the DT is rather incomplete when we list only one CPU in the cooling maps, as the hardware doesn't have any such limitations. Update cooling maps to include all devices affected by individual trip points. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-17ARM: dts: rockchip: use SPDX-License-IdentifierKlaus Goger
Update all 32bit rockchip devicetree files to use SPDX-License-Identifiers. All files except rk3288-veyron-analog-audio.dtsi (which is GPL 2.0 only) claim to be GPL and X11 while the actual license text is MIT. Use the MIT SPDX tag for them. Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com> Acked-by: Brian Norris <briannorris@chromium.org> Acked-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-01-02ARM: dts: rockchip: use pin constants to describe gpiosAndy Yan
Use macros to describe gpios will make the dts easier to read and write. All the modifications done with sed: sed -i -e 's/ 0 GPIO_ACTIVE_/ RK_PA0 GPIO_ACTIVE_/' arch/arm/boot/dts/rk* sed -i -e 's/ 1 GPIO_ACTIVE_/ RK_PA1 GPIO_ACTIVE_/' arch/arm/boot/dts/rk* sed -i -e 's/ 2 GPIO_ACTIVE_/ RK_PA2 GPIO_ACTIVE_/' arch/arm/boot/dts/rk* ....... ....... sed -i -e 's/ 30 GPIO_ACTIVE_/ RK_PD6 GPIO_ACTIVE_/' arch/arm/boot/dts/rk* sed -i -e 's/ 31 GPIO_ACTIVE_/ RK_PD7 GPIO_ACTIVE_/' arch/arm/boot/dts/rk* Tested with: for i in dts-old/*dtb; do scripts/dtc/dtx_diff $i dts-new/$(basename $i); done Signed-off-by: Andy Yan <andy.yan@rock-chips.com> [also adapted the gpio interrupts] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2015-12-03ARM: dts: rockchip: add veyron-mickey boardChris Zhong
Also known as the Asus Chromebit. Signed-off-by: Chris Zhong <zyw@rock-chips.com> Tested-by: Caesar Wang <wxt@rock-chips.com> For the license change: Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>