03 Jun, 2014

1 commit

  • Pull ARM SoC driver changes from Olof Johansson:
    "SoC-near driver changes that we're merging through our tree. Mostly
    because they depend on other changes we have staged, but in some cases
    because the driver maintainers preferred that we did it this way.

    This contains a largeish cleanup series of the omap_l3_noc bus driver,
    cpuidle rework for Exynos, some reset driver conversions and a long
    branch of TI EDMA fixes and cleanups, with more to come next release.

    The TI EDMA cleanups is a shared branch with the dmaengine tree, with
    a handful of Davinci-specific fixes on top.

    After discussion at last year's KS (and some more on the mailing
    lists), we are here adding a drivers/soc directory. The purpose of
    this is to keep per-vendor shared code that's needed by different
    drivers but that doesn't fit into the MFD (nor drivers/platform)
    model. We expect to keep merging contents for this hierarchy through
    arm-soc so we can keep an eye on what the vendors keep adding here and
    not making it a free-for-all to shove in crazy stuff"

    * tag 'drivers-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (101 commits)
    cpufreq: exynos: Fix driver compilation with ARCH_MULTIPLATFORM
    tty: serial: msm: Remove direct access to GSBI
    power: reset: keystone-reset: introduce keystone reset driver
    Documentation: dt: add bindings for keystone pll control controller
    Documentation: dt: add bindings for keystone reset driver
    soc: qcom: fix of_device_id table
    ARM: EXYNOS: Fix kernel panic when unplugging CPU1 on exynos
    ARM: EXYNOS: Move the driver to drivers/cpuidle directory
    ARM: EXYNOS: Cleanup all unneeded headers from cpuidle.c
    ARM: EXYNOS: Pass the AFTR callback to the platform_data
    ARM: EXYNOS: Move S5P_CHECK_SLEEP into pm.c
    ARM: EXYNOS: Move the power sequence call in the cpu_pm notifier
    ARM: EXYNOS: Move the AFTR state function into pm.c
    ARM: EXYNOS: Encapsulate the AFTR code into a function
    ARM: EXYNOS: Disable cpuidle for exynos5440
    ARM: EXYNOS: Encapsulate boot vector code into a function for cpuidle
    ARM: EXYNOS: Pass wakeup mask parameter to function for cpuidle
    ARM: EXYNOS: Remove ifdef for scu_enable in pm
    ARM: EXYNOS: Move scu_enable in the cpu_pm notifier
    ARM: EXYNOS: Use the cpu_pm notifier for pm
    ...

    Linus Torvalds
     

22 May, 2014

1 commit


21 May, 2014

2 commits


15 May, 2014

1 commit

  • The current implementation uses sunxi_reset_init function for both early
    init and platform device probe.

    The sunxi_reset_init function uses DT to retrieve device resources, which
    will be an issue if reset controllers are registered from an MFD device
    that define resources from mfd_cell definition.

    Moreover, we can make of devm functions when we're in the probe context.

    Signed-off-by: Boris BREZILLON
    Acked-by: Maxime Ripard
    Signed-off-by: Maxime Ripard
    Acked-by: Philipp Zabel

    Boris BREZILLON
     

26 Apr, 2014

1 commit

  • Add a reset-controller driver for the socfpga platform.
    The reset-controller has four banks with up to 32 entries all encapsulated in
    one module block.

    Signed-off-by: Steffen Trumtrar
    Acked-by: Philipp Zabel
    Signed-off-by: Dinh Nguyen
    ---

    Notes:
    Changes since v2:
    - remove superfluous ret in probe function
    - add Acked-by

    Changes since v1:
    - use BITS_PER_LONG everywhere instead of MAX_BANK_WIDTH
    - print pdev->dev.of_node->full_name on error
    - use proper IS_ERR/PTR_ERR

    Steffen Trumtrar
     

27 Mar, 2014

1 commit


11 Mar, 2014

5 commits

  • This patch adds softreset controller for STiH416 SOC, soft reset
    controller is based on system configuration registers which are mapped
    via regmap. This reset controller does not have any feedback or
    acknowledgement. With this patch a new device "st,stih416-softreset" is
    registered with system configuration registers based reset controller
    that controls the softreset state of the hardware such as Ethernet, IRB.

    Signed-off-by: Srinivas Kandagatla
    Acked-by: Philipp Zabel

    Srinivas Kandagatla
     
  • This patch adds softreset controller for STiH415 SOC, soft reset
    controller is based on system configuration registers which are mapped
    via regmap. This reset controller does not have any feedback or
    acknowledgement. With this patch a new device "st,stih415-softreset" is
    registered with system configuration registers based reset controller
    that controls the softreset state of the hardware such as Ethernet, IRB.

    Signed-off-by: Srinivas Kandagatla
    Acked-by: Philipp Zabel

    Srinivas Kandagatla
     
  • This patch adds a reset controller platform driver for the STiH416
    SoC. This initial version provides a compatible driver for the
    "st,stih416-powerdown" device, which registers a system configuration
    register based reset controller that controls the powerdown state of
    hardware such as the on-chip USB host controllers.

    Signed-off-by: Stephen Gallimore
    Signed-off-by: Srinivas Kandagatla
    Acked-by: Philipp Zabel

    Stephen Gallimore
     
  • This patch adds a reset controller platform driver for the STiH415
    SoC. This initial version provides a compatible driver for the
    "st,stih415-powerdown" device, which registers a system configuration
    register based reset controller that controls the powerdown state of
    hardware such as the on-chip USB host controllers.

    Signed-off-by: Stephen Gallimore
    Signed-off-by: Srinivas Kandagatla
    Acked-by: Philipp Zabel

    Stephen Gallimore
     
  • This patch adds a reset controller implementation for STMicroelectronics
    STi family SoCs; it allows a group of related reset like controls found
    in multiple system configuration registers to be represented by a single
    controller device. System configuration registers are accessed through
    the regmap framework and the mfd/syscon driver.

    The implementation optionally supports waiting for the reset action to
    be acknowledged in a separate status register and supports both
    active high and active low reset lines. These properties are common across
    all the reset channels in a specific reset controller instance, hence
    all channels in a paritcular controller are expected to behave in the
    same way.

    Signed-off-by: Stephen Gallimore
    Signed-off-by: Srinivas Kandagatla
    Acked-by: Philipp Zabel

    Stephen Gallimore
     

03 Feb, 2014

3 commits

  • In some cases, you might need to deassert from reset an hardware block that
    doesn't associated to a struct device (CPUs, timers, etc.).

    Add a small helper to retrieve the reset controller from the device tree
    without the need to pass a struct device.

    Signed-off-by: Maxime Ripard
    Signed-off-by: Philipp Zabel

    Maxime Ripard
     
  • Mark function of_reset_simple_xlate() as static in core.c
    because it is not used outside this file.
    Also, remove functions devm_reset_control_put() and
    devm_reset_control_match() because they are unused.

    This eliminates the following warnings in core.c:
    drivers/reset/core.c:46:5: warning: no previous prototype for ‘of_reset_simple_xlate’ [-Wmissing-prototypes]
    drivers/reset/core.c:262:6: warning: no previous prototype for ‘devm_reset_control_put’ [-Wmissing-prototypes]

    Signed-off-by: Rashika Kheria
    Reviewed-by: Josh Triplett
    Signed-off-by: Philipp Zabel

    Rashika Kheria
     
  • If the requested reset controller is not yet available, have reset_control_get
    and device_reset return -EPROBE_DEFER so the driver can decide to request
    probe deferral.

    Signed-off-by: Philipp Zabel
    Acked-by: Shawn Guo
    Reviewed-by: Stephen Warren

    Philipp Zabel
     

23 Nov, 2013

1 commit

  • The Allwinner A31 and most of the other Allwinner SoCs have an IP
    maintaining a few other IPs in the SoC in reset by default. Among these
    IPs are the A31's High Speed Timers, hence why we can't use the regular
    driver construct in every cases, and need to call the registering
    function directly during machine initialisation.

    Apart from this, the implementation is fairly straightforward, and could
    easily be moved to a generic MMIO-based reset controller driver if the
    need ever arise.

    Signed-off-by: Maxime Ripard
    Acked-by: Philipp Zabel

    Maxime Ripard
     

12 Apr, 2013

2 commits