11 Apr, 2019

1 commit

  • 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/
    Signed-off-by: Heiko Stuebner

    Heiko Stuebner
     

25 Mar, 2019

2 commits

  • 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
    Signed-off-by: Heiko Stuebner

    Douglas Anderson
     
  • 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
    Signed-off-by: Heiko Stuebner

    Douglas Anderson
     

17 Jun, 2018

1 commit

  • 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
    Acked-by: Brian Norris
    Acked-by: Matthias Brugger
    Acked-by: Douglas Anderson
    Signed-off-by: Heiko Stuebner

    Klaus Goger
     

02 Jan, 2017

1 commit

  • 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
    [also adapted the gpio interrupts]
    Signed-off-by: Heiko Stuebner

    Andy Yan
     

07 Apr, 2016

2 commits


21 Aug, 2015

1 commit

  • 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
    Reviewed-by: Javier Martinez Canillas
    Signed-off-by: Heiko Stuebner

    Brian Norris
     

16 Jul, 2015

1 commit