14 May, 2017

1 commit

  • commit 9b1b23f03abdd25ffde8bbfe5824b89bc0448c28 upstream.

    The mux_pll_src_apll_dpll_gpll_usb480m_p parent list was missing a ","
    between the 3rd and 4th parent names, making them fall together and thus
    lookups fail. Fix that.

    Fixes: 5190c08b2989 ("clk: rockchip: add clock controller for rk3036")
    Signed-off-by: Heiko Stuebner
    Signed-off-by: Stephen Boyd
    Signed-off-by: Greg Kroah-Hartman

    Heiko Stuebner
     

16 Oct, 2016

1 commit

  • rockchip_clk_register_ddrclk should not return NULL when failing
    to call clk_register, otherwise rockchip_clk_register_branches
    prints "unknown clock type". The actual case is that it's a known
    clock type but we fail to register it, which may makes user confuse
    the reason of failure. And the pr_err here is pointless as
    rockchip_clk_register_branches will also print the similar message.

    Signed-off-by: Shawn Lin
    Signed-off-by: Heiko Stuebner

    Shawn Lin
     

07 Sep, 2016

1 commit

  • …mmind/linux-rockchip into clk-next

    Pull rockchip clk driver updates from Heiko Stuebner:

    The biggest addition is probably the special clock-type for ddr clock
    control. While reading that clock is done the normal way from the
    registers, setting it always requires some sort of special handling
    to let the system survive this addition.

    As the commit message explains, there are currently 3 handling-types
    known. General SRAM-based code on rk3288 and before (which is waiting
    essentially for the PIE support that is currently being worked on),
    SCPI-based clk setting on the rk3368 through a coprocessor, which we
    might support once the support for legacy scpi-variants has matured
    and now on the rk3399 (and probably later) using a dcf controller that
    is controlled from the arm-trusted-firmware and gets accessed through
    firmware calls from the kernel. This is the variant we currently
    support, but the clock type is made to support the other variants in
    the future as well.

    Apart from that slightly bigger chunk, we have a mix of PLL rates,
    clock-ids and flags mainly for the rk3399.

    And interestingly an iomap fix for the legacy gate driver, where I
    hopefully could deter the submitter from actually using that in any
    new works.

    * tag 'v4.9-rockchip-clk1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
    clk: rockchip: use the dclk_vop_frac clock ids on rk3399
    clk: rockchip: drop CLK_SET_RATE_PARENT from rk3399 fractional dividers
    clk: rockchip: add 2016M to big cpu clk rate table on rk3399
    clk: rockchip: add rk3399 ddr clock support
    clk: rockchip: add dclk_vop_frac ids for rk3399 vop
    clk: rockchip: add new clock-type for the ddrclk
    soc: rockchip: add header for ddr rate SIP interface
    clk: rockchip: add SCLK_DDRC id for rk3399 ddrc
    clk: rockchip: handle of_iomap failures in legacy clock driver
    clk: rockchip: mark rk3399 hdcp_noc and vio_noc as critical
    clk: rockchip: use general clock flag when registering pll
    clk: rockchip: delete the CLK_IGNORE_UNUSED from aclk_pcie on rk3399
    clk: rockchip: add 65MHz and 106.5MHz rates to rk3399 plls used for HDMI

    Stephen Boyd
     

05 Sep, 2016

4 commits


01 Sep, 2016

1 commit

  • Changing the rate of the DDR clock needs special care, as the DDR
    is of course in use and will react badly if the rate changes under it.

    Over time different approaches to handle that were used.

    Past SoCs like the rk3288 and before would store some code in SRAM
    while the rk3368 used a SCPI variant and let a coprocessor handle that.

    New rockchip platforms like the rk3399 have a dcf controller to do ddr
    frequency scaling, and support for this controller will be implemented
    in the arm-trusted-firmware.

    This new clock-type should over time handle all these methods for
    handling DDR rate changes, but right now it will concentrate on the
    SIP interface used to talk to ARM trusted firmware.

    The SIP interface counterpart was merged from pull-request #684 [0]
    into the upstream arm-trusted-firmware codebase.

    [0] https://github.com/ARM-software/arm-trusted-firmware/pull/684

    Signed-off-by: Lin Huang
    Signed-off-by: Heiko Stuebner

    Lin Huang
     

25 Aug, 2016

1 commit

  • We don't have code to handle any of the noc clocks in rk3399 and they're
    all just listed as critical clocks. Let's do the same for
    aclk_emmc_noc.

    Without this clock being marked as critical we have problems around
    suspend/resume after commit 20c389e656a8 ("clk: rockchip: fix incorrect
    aclk_emmc source gate bits on rk3399"). Before that change we were
    presumably not actually gating any of these clocks because we were
    setting the wrong gate.

    Fixes: 20c389e656a8 ("clk: rockchip: fix incorrect aclk_emmc source gate bits on rk3399")
    Signed-off-by: Xing Zheng
    Signed-off-by: Douglas Anderson
    Signed-off-by: Heiko Stuebner

    Xing Zheng
     

24 Aug, 2016

1 commit


13 Aug, 2016

1 commit

  • Sorry to refer incorrect clock diagram, we double check it that the bits
    configuration of the Xpll_aclk_perihp_src need to be fixed:
    bit 1 - shows aclk_perihp_cpll_src_en
    bit 0 - shows aclk_perihp_gpll_src_en

    Through the testing that plug/unplug the USB ethernet cable on the RK3399 kevin board.

    1. the hclk_host0 and hclk_host1 are endpoint clocks:
    cpll --> G5[1] --> aclk_perihp_cpll_src --\ |--> hclk_host0
    | --> ... ---> |
    gpll --> G5[0] --> aclk_perihp_gpll_src --/ |--> hclk_host1

    2. there is no clock below the cpll_aclk_perihp_src,
    and the hclk_hostX are below the gpll_aclk_perihp_src:
    pll_cpll 1 1 800000000 0 0
    cpll 7 19 800000000 0 0
    cpll_aclk_perihp_src 0 0 800000000 0 0
    ...
    pll_gpll 1 1 594000000 0 0
    gpll 10 10 594000000 0 0
    gpll_aclk_perihp_src 2 2 594000000 0 0
    hclk_perihp 5 5 74250000 0 0
    hclk_host1_arb 2 2 74250000 0 0
    hclk_host1 2 2 74250000 0 0
    hclk_host0_arb 2 2 74250000 0 0
    hclk_host0 2 2 74250000 0 0

    3. by default, G5[0] and G5[1] are enabled:
    localhost ~ # mem r 0xff760314
    0x000003e0

    4. close the G5[1] (aclk_perihp_cpll_src), and plug/unplug USB ethernet cable,
    the DUT still works well:
    localhost ~ # mem w 0xff760314 0xffff03e2
    localhost ~ # mem r 0xff760314
    0x000003e2
    plug/unplug, the work statue is ok

    5. close the G5[0] (aclk_perihp_gpll_src), , and plug/unplug USB ethernet cable,
    the DUT will be crashed:
    localhost ~ # mem w 0xff760314 0xffff03e1
    localhost ~ # mem r 0xff760314
    0x000003e1
    plug/unplug, the DUT is crashed

    Summary:
    bit 1 - shows aclk_perihp_cpll_src_en
    bit 0 - shows aclk_perihp_gpll_src_en

    Fixes: 3bd14ae9da91 ("clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src")
    Signed-off-by: Xing Zheng

    [here the clock-documentation in the manual was actually stating the wrong
    bits and thus only Xing's testing above revealed the issue]
    Signed-off-by: Heiko Stuebner

    Xing Zheng
     

12 Aug, 2016

3 commits


08 Aug, 2016

3 commits


02 Jul, 2016

1 commit

  • …mmind/linux-rockchip into clk-next

    Pull rockchip clk driver updates from Heiko Stuebner:

    Placeholder for the rk3399 watchdog pclk, some newly exported
    rk3228 clockids and a small fix for the not yet used spdif to
    displayport clock on the rk3399.

    * tag 'v4.8-rockchip-clk1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
    clk: rockchip: fix incorrect rk3399 spdif-DPTX divider bits
    clk: rockchip: export rk3228 MAC clocks
    clk: rockchip: rename rk3228 sclk_macphy_50m to sclk_mac_extclk
    clk: rockchip: export rk3228 audio clocks
    clk: rockchip: include rk3228 downstream muxes into fractional dividers
    clk: rockchip: fix incorrect rk3228 clock registers
    clk: rockchip: add clock-ids for rk3228 MAC clocks
    clk: rockchip: add clock-ids for rk3228 audio clocks
    clk: rockchip: add a dummy clock for the watchdog pclk on rk3399

    Stephen Boyd
     

01 Jul, 2016

5 commits


22 Jun, 2016

1 commit


03 Jun, 2016

1 commit


30 May, 2016

6 commits

  • Like rk3288, the pclk supplying the watchdog is controlled via the
    SGRF register area. Additionally the SGRF isn't even writable in
    every boot mode.

    But still the clock control is available and in the future someone
    might want to use it. Therefore define a simple clock for the time
    being so that the watchdog driver can read its rate.

    Signed-off-by: Xing Zheng
    Reviewed-by: Stephen Barber
    Signed-off-by: Heiko Stuebner

    Xing Zheng
     
  • It maybe due to a copy-paste error the error handing should be
    cclk not clk when checking if the cpuclk registration succeeded.

    Reported-by: Lin Huang
    Signed-off-by: Xing Zheng
    Signed-off-by: Heiko Stuebner

    Xing Zheng
     
  • This reverts commit 7a03fe6f48f3 ("clk: rockchip: reset init state
    before mmc card initialization").

    Though not totally obvious from the commit message nor from the source
    code, that commit appears to be trying to reset the "_drv" MMC clocks to
    90 degrees (note that the "_sample" MMC clocks have a shift of 0 so are
    not touched).

    The major problem here is that it doesn't properly reset things. The
    phase is a two bit field and the commit only touches one of the two
    bits. Thus the commit had the following affect:
    - phase 0 => phase 90
    - phase 90 => phase 90
    - phase 180 => phase 270
    - phase 270 => phase 270

    Things get even weirder if you happen to have a bootloader that was
    actually using delay elements (should be no reason to, but you never
    know), since those are additional bits that weren't touched by the
    original patch.

    This is unlikely to be what we actually want. Checking on rk3288-veyron
    devices, I can see that the bootloader leaves these clocks as:
    - emmc: phase 180
    - sdmmc: phase 90
    - sdio0: phase 90

    Thus on rk3288-veyron devices the commit we're reverting had the effect
    of changing the eMMC clock to phase 270. This probably explains the
    scattered reports I've heard of eMMC devices not working on some veyron
    devices when using the upstream kernel.

    The original commit was presumably made because previously the kernel
    didn't touch the "_drv" phase at all and relied on whatever value was
    there when the kernel started. If someone was using a bootloader that
    touched the "_drv" phase then, indeed, we should have code in the kernel
    to fix that. ...and also, to get ideal timings, we should also have the
    kernel change the phase depending on the speed mode. In fact, that's
    the subject of a recent patch I posted at
    .

    Ideally, we should take both the patch posted to dw_mmc and this
    revert. Since those will likely go through different trees, here I
    describe behavior with the combos:

    1. Just this revert: likely will fix rk3288-veyron eMMC on some devices
    + other cases; might break someone with a strange bootloader that
    sets the phase to 0 or one that uses delay elements (pretty
    unpredicable what would happen in that case).
    2. Just dw_mmc patch: fixes everyone. Effectly the dw_mmc patch will
    totally override the broken patch and fix everything.
    3. Both patches: fixes everyone. Once dw_mmc is initting properly then
    any defaults from the clock code doesn't mattery.

    Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization")
    Signed-off-by: Douglas Anderson
    Reviewed-by: Shawn Lin

    [emmc and sdmmc still work on all current boards in mainline after this
    revert, so they should take precedence over any out-of-tree board that
    will hopefully again get fixed with the better upcoming dw_mmc change.]
    Signed-off-by: Heiko Stuebner

    Douglas Anderson
     
  • There was a typo, swapping 'c' 'g'.

    Signed-off-by: Xing Zheng
    Signed-off-by: Brian Norris
    Reviewed-by: Douglas Anderson
    Signed-off-by: Heiko Stuebner

    Xing Zheng
     
  • We never want to kill the GIC.

    Noticed when making other clock fixups, and seeing the newly-constructed
    clock tree try to disable cpll, where we had this parent structure:

    aclk_gic
    Reviewed-by: Douglas Anderson
    Signed-off-by: Heiko Stuebner

    Brian Norris
     
  • The flags element of clk_init_data was never initialized for mmc-
    phase-clocks resulting in the element containing a random value
    and thus possibly enabling unwanted clock flags.

    Fixes: 89bf26cbc1a0 ("clk: rockchip: Add support for the mmc clock phases using the framework")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiko Stuebner

    Heiko Stuebner
     

13 May, 2016

1 commit

  • …mmind/linux-rockchip into clk-next

    Pull rockchip clk updates from Heiko Stuebner:

    Another small rk3399 fixup as well as simplifications around
    our handling of the General-Register-Files syscon.

    * tag 'v4.7-rockchip-clk4' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
    clk: rockchip: drop old_rate calculation on pll rate changes
    clk: rockchip: simplify GRF handling in pll clocks
    clk: rockchip: lookup General Register Files in rockchip_clk_init
    clk: rockchip: fix the rk3399 sdmmc sample / drv name

    Stephen Boyd
     

09 May, 2016

4 commits

  • Previously when everything happened in the set_rate callbacks itself we
    needed the old_rate value for the possible rate rollback, so that made
    it easy to also use it in the debug output.

    Now with the param-handling being done in separate functions, reading and
    recalculating the current pll rate only to use it in a debug message that
    won't get displayed in regular cases anyway is quite a waste.

    Therefore drop that value from the debug output. In the worst case that
    previous rate will have been displayed on the rate change before.

    Signed-off-by: Heiko Stuebner

    Heiko Stuebner
     
  • With the previous commit, the clock drivers now know at init time if the
    GRF regmap is available. That means if it isn't available then, it also
    won't become available later and we can therefore switch PLLs, that need
    the GRF for the lock-status, to read-only mode - similar behaviour as the
    aborting of rate changes we did before.

    This saves some conditionals on every rate change and we can also drop
    the rockchip_clk_get_grf function completely.

    Signed-off-by: Heiko Stuebner

    Heiko Stuebner
     
  • In the distant past syscons were initialized pretty late and weren't
    available at the time the clock init ran. As the GRF is mainly needed
    for PLL lock-status checking, we had this lazy init that tried to grab
    the syscon on PLL rate changes and denied these changes if it was not
    available.

    These days syscons are available very early and recent addition to
    rockchip clocks, like the PLL clk_init actually also rely on them
    being available at that time, so there is no need to keep that lazy
    init around, as it will also result in some more simplifications in
    other parts of the clock-code.

    Signed-off-by: Heiko Stuebner

    Heiko Stuebner
     
  • The rk3399 clock table had a simple typo in it, calling the SDMMC sample
    and drive clocks by the wrong name. Fix this minor typo.

    Signed-off-by: Douglas Anderson
    Tested-by: Brian Norris
    Acked-by: Brian Norris
    Signed-off-by: Heiko Stuebner

    Douglas Anderson
     

03 May, 2016

1 commit

  • …mmind/linux-rockchip into clk-next

    Pull rockchip clk updates from Heiko Stuebner:

    A spelling fix and a bunch of rk3399 clock fixes.

    * tag 'v4.7-rockchip-clk3' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
    clk: rockchip: fix the rk3399 cifout clock
    clk: rockchip: drop unnecessary CLK_IGNORE_UNUSED flags from rk3399
    clk: rockchip: add some frequencies on the rk3399 PLL table
    clk: rockchip: assign more necessary rk3399 clock ids
    clk: rockchip: export some necessary rk3399 clock ids
    clk: rockchip: rename rga clock-id on rk3399
    clk: rockchip: add general gpu soft-reset on rk3399
    clk: rockchip: fix the gate bit for i2c4 and i2c8 on rk3399
    clk: rockchip: fix of spelling mistake on unsuccessful in pll clock type

    Stephen Boyd
     

26 Apr, 2016

3 commits