| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
gpio
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3288-tinker.dt.yaml: tsadc: otp-gpio:
{'phandle': [[54]], 'rockchip,pins': [[0, 10, 0, 118]]}
is not of type 'array'
'gpio' is a sort of reserved nodename and should not be used
for pinctrl in combination with 'rockchip,pins', so change
nodes that end with 'gpio' to end with 'pin' or 'pins'.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/
dtschema/schemas/gpio/gpio.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200524160636.16547-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
This enables the Broadcom uart bluetooth driver on uart0 and gives it
ownership of its gpios. In order to use this, you must enable the
following kconfig options:
- CONFIG_BT_HCIUART_BCM
- CONFIG_SERIAL_DEV
This is applicable to rk3288-veyron series boards that use the bcm43540
wifi+bt chips.
As part of this change, also refactor the pinctrl across the various
boards. All the boards using broadcom bluetooth shouldn't touch the
bt_dev_wake pin.
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20191127223909.253873-2-abhishekpandit@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
veyron jaq, jerry, minnie and speedy have mostly redundant regulator
and pinctrl configurations for the panel/backlight. Consolidate these
pieces in the eDP .dtsi.
Also change the default power supply for the panel to
'panel_regulator', instead of overriding it in all the board files.
pinky is the only device that uses 'vcc33_lcd' (the prior default),
so overwrite it in this case. pinky doesn't have a complete display
configuration, to keep things as they were delete the common nodes
that didn't exist previously in pinky's board file.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The downstream Chrome OS 3.14 kernel for jerry limits WiFi TX power
through calibration data in the device tree [1]. Add a DT node for
the WiFi chip and use the downstream calibration data.
Not all calibration data entries have the length specified in the
binding (Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt),
however this is the data used by the downstream ('official') kernel
and the binding mentions that "the length can vary between hw
versions".
[1] https://crrev.com/c/271237
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
This is like the same change for rk3288-veyron-minnie. See that patch
for more details.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
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>
|
|
When the rk3288-jerry device tree was first submitted we left out the
dvs-gpios because I pointed out that the property "dvs-gpios" wasn't
yet supported upstream [1]. Soon after that the property was added in
commit bad47ad2eef3 ("regulator: rk808: fixed the overshoot when
adjust voltage"). ...but we forgot to go back and add the property to
the jerry device tree file. Let's do so now.
NOTE: without this patch, jerry is likely still stable (thanks to the
fallback of making many small jumps in the rk808 regulator code) but
it'll take quite a bit longer to make voltage transitions.
[1] https://lore.kernel.org/linux-arm-kernel/CAD=FV=WwFgjzbk9xF5TU_ie6UnHQMyrZ176D4+jJTWWOoaKC2Q@mail.gmail.com/
Fixes: f3ee390e4ef2 ("ARM: dts: rockchip: add veyron-jerry board")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
As far as I can tell/remember rev10 was originally created to support
making a SKU of jerry that had a different LCD. rev11-rev15 were
added to give some wiggle room for future builds. Downstream has a
separate device tree for rev10-rev15 (compared to rev3-rev7) with the
expectation that differences relating to the LCD would be accounted
for there but nothing was ever added to the rev10-rev15 making it
identical to the rev3-rev7 one.
It's likely nothing actually shipped with rev10-rev15 but they are
listed in the downstream kernel's device tree and it seems like it
should add a little safety if we match them here just in case
something actually shipped with one of these revisions and that device
will break if we don't claim support.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
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>
|
|
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>
|
|
Jerry and Speedy don't need any special handling wrt the backlight or
panel, so only need their backlight and panel-regulators hooked up.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Douglas Anderson <dianders@chromium.org>
|
|
The panels need a bit of time to actually turn on. If this isn't
observed, this results in problems when trying talk to the panels
and thus produces detection errors. 100ms seem to be a safe value
for the time being.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Douglas Anderson <dianders@chromium.org>
|
|
When getting translated from a downstream device tree that used slightly
different DT bindings, these regulators got labeled with the
"on-in-suspend" state, when they were actually supposed to be turned off
for S3 suspend. This was harmless, but not intentional, AFAICT.
Let's turn them off to get the optimal power state.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Hisense Chromebook C11, also named jerry.
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
|
