- 24 Aug, 2018 4 commits
-
-
Marc Zyngier authored
A number of the Rockchip-specific drivers (IOMMU, display controllers) are now assuming that CONFIG_PM is set, and may completely misbehave if that's not the case. Since there is hardly any reason for this configuration option not to be selected anyway, let's require it (in the same way Tegra already does). Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Olof Johansson <olof@lixom.net>
-
Amit Kucheria authored
The idle-states binding documentation[1] mentions that the 'entry-method' property is required on 64-bit platforms and must be set to "psci". commit a13f18f5 ("Documentation: arm: Fix typo in the idle-states bindings examples") attempted to fix this earlier but clearly more is needed. Fix the cpu-capacity.txt documentation that uses the incorrect value so we don't get copy-paste errors like these. Clarify the language in idle-states.txt by removing the reference to the psci bindings that might be causing this confusion. Finally, fix devicetrees of various boards to reflect current documentation. [1] Documentation/devicetree/bindings/arm/idle-states.txt (see idle-states node) Signed-off-by:
Amit Kucheria <amit.kucheria@linaro.org> Acked-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
Li Yang <leoyang.li@nxp.com> Signed-off-by:
-
git://git.pengutronix.de/git/pza/linuxOlof Johansson authored
Reset controller fixes for v4.18 This tag fixes reset assertion on i.MX7 for all non-inverted reset control bits. Currently only PCIE controller and PHY resets are used. * tag 'reset-fixes-for-4.18' of git://git.pengutronix.de/git/pza/linux: reset: imx7: Fix always writing bits as 0 Signed-off-by:
-
git://git.pengutronix.de/git/pza/linuxOlof Johansson authored
Reset controller changes for v4.19, part 2 This adds a single new driver for the Amlogic Meson Audio Memory Arbiter resets. * tag 'reset-for-4.19-2' of git://git.pengutronix.de/git/pza/linux: reset: meson: add meson audio arb driver reset: meson: add dt-bindings for meson-axg audio arb Signed-off-by:
-
- 26 Jul, 2018 6 commits
-
-
Olof Johansson authored
Merge tag 'v4.18-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into next/drivers - add pmic wrapper support for mt6797 - pmic wrapper fix chiper init - add support for pmic mt6351 * tag 'v4.18-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: soc: mediatek: pwrap: add mt6351 driver for mt6797 SoCs soc: mediatek: pwrap: add pwrap driver for mt6797 SoCs soc: mediatek: pwrap: fix cipher init setting error dt-bindings: pwrap: mediatek: add pwrap support for MT6797 Signed-off-by:
-
Olof Johansson authored
Merge tag 'samsung-drivers-exynos5440-4.19' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into next/drivers Exynos5440 drivers removal The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting server platforms but it did not make it to the market really. There are no development boards with it and probably there are no real products neither. The development for Exynos5440 ended in 2013 and since then the platform is in maintenance mode. Removing Exynos5440 makes our life slightly easier: less maintenance, smaller code, reduced number of quirks, no need to preserve DTB backward-compatibility. The Device Tree sources and some of the drivers for Exynos5440 were already removed. This removes remaining drivers. * tag 'samsung-drivers-exynos5440-4.19' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: usb: host: exynos: Remove support for Exynos5440 clk: samsung: Remove support for Exynos5440 cpufreq: exynos: Remove support for Exynos5440 ata: ahci-platform: Remove support for Exynos5440 Signed-off-by:
-
Sudeep Holla authored
Commit 7f9545aa ("arm64: smp: remove cpu and numa topology information when hotplugging out CPU") updates the cpu topology when the CPU is hotplugged out. However the PSCI checker code uses the topology_core_cpumask pointers for some of the cpu hotplug testing. Since the pointer to the core_cpumask of the first CPU in the group is used, which when that CPU itself is hotpugged out is just set to itself, the testing terminates after that particular CPU is tested out. But the intention of this tests is to cover all the CPU in the group. In order to support that, we need to stash the topology_core_cpumask before the start of the test and use that value instead of pointer to a cpumask which will be updated on CPU hotplug. Fixes: 7f9545aa ("arm64: smp: remove cpu and numa topology information when hotplugging out CPU") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Olof Johansson authored
Merge tag 'soc-fsl-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux into next/drivers Various updates to soc/fsl for 4.19 Moves DPAA2 DPIO driver from staging to fsl/soc Adds multiple-pin support to QE gpio driver * tag 'soc-fsl-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux: soc: fsl: cleanup Kconfig menu soc: fsl: dpio: Convert DPIO documentation to .rst staging: fsl-mc: Remove remaining files staging: fsl-mc: Move DPIO from staging to drivers/soc/fsl staging: fsl-dpaa2: eth: move generic FD defines to DPIO soc: fsl: qe: gpio: Add qe_gpio_set_multiple Signed-off-by:
-
Olof Johansson authored
Merge tag 'sunxi-drivers-for-4.19' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into next/drivers Allwinner drivers changes for 4.19 There's been work for this release cycles in both the SRAM controller driver in order to support more SoCs, as part of our VPU work, but also to enable the EMAC on the A64 (that needs to poke at registers within the same register space). Some work has been needed too to represent the bus to the display engine controllers that all need an SRAM to be mapped to the CPU to be able to access those controllers' registers. * tag 'sunxi-drivers-for-4.19' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: soc: sunxi: Add the A13, A23 and H3 system control compatibles drivers: soc: sunxi: Add support for the C1 SRAM region dt-bindings: sram: sunxi: Populate valid sections compatibles dt-bindings: sram: sunxi: Add A13, A20, A23 and H3 dedicated bindings soc: sunxi: sram: Add dt match for the A10 system-control compatible dt-bindings: sram: sunxi: Introduce new A10 binding for system-control bus: add bus driver for accessing Allwinner A64 DE2 dt-bindings: add binding for the Allwinner A64 DE2 bus soc: sunxi: sram: Add updated compatible string for A64 system control dt-bindings: sram: Rename A64 SRAM controller compatible soc: sunxi: export a regmap for EMAC clock reg on A64 Signed-off-by:
-
Olof Johansson authored
Merge tag 'qcom-drivers-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into next/drivers Qualcomm ARM Based Driver Updates for v4.19 * Add Qualcomm LLCC driver * Add Qualcomm RPMH controller * Fix memleak in Qualcomm RMTFS * Add dummy qcom_scm_assign_mem() * Fix check for global partition in SMEM * tag 'qcom-drivers-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux: soc: qcom: rmtfs-mem: fix memleak in probe error paths soc: qcom: llc-slice: Add missing MODULE_LICENSE() drivers: qcom: rpmh: fix unwanted error check for get_tcs_of_type() drivers: qcom: rpmh-rsc: fix the loop index check in get_req_from_tcs firmware: qcom: scm: add a dummy qcom_scm_assign_mem() drivers: qcom: rpmh-rsc: Check cmd_db_ready() to help children drivers: qcom: rpmh-rsc: allow active requests from wake TCS drivers: qcom: rpmh: add support for batch RPMH request drivers: qcom: rpmh: allow requests to be sent asynchronously drivers: qcom: rpmh: cache sleep/wake state requests drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS drivers: qcom: rpmh: add RPMH helper functions drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs drivers: soc: Add LLCC driver dt-bindings: Documentation for qcom, llcc soc: qcom: smem: Correct check for global partition Signed-off-by:
-
- 24 Jul, 2018 8 commits
-
-
Li Yang authored
Put NXP/Freescale QorIQ SoC drivers under a menu and make the item naming more aligned. Signed-off-by: -
Roy Pledge authored
Convert the Datapath I/O documentation to .rst format and move to the Documation/networking/dpaa2 directory Signed-off-by:
Roy Pledge <roy.pledge@nxp.com> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Reviewed-by:
Ioana Radulescu <ruxandra.radulescu@nxp.com> Signed-off-by:
-
Roy Pledge authored
Remove the staging/drivers/fsl-mc directory from the staging area now that all the components have been moved to the main kernel areas. Signed-off-by:
-
Roy Pledge authored
Move the NXP DPIO (Datapath I/O Driver) out of the drivers/staging directory and into the drivers/soc/fsl directory. The DPIO driver enables access to Queue and Buffer Manager (QBMAN) hardware on NXP DPAA2 devices. This is a prerequisite to moving the DPAA2 Ethernet driver out of staging. Signed-off-by:
-
Horia Geantă authored
Previous commits: commit 6e2387e8 ("staging: fsl-dpaa2/eth: Add Freescale DPAA2 Ethernet driver") commit 39163c0c ("staging: fsl-dpaa2/eth: Errors checking update") have added bits that are not specific to the WRIOP accelerator. Move these where they belong (in DPIO) such that other accelerators can make use of them. Signed-off-by:
-
Joakim Tjernlund authored
This cousin to gpio-mpc8xxx was lacking a multiple pins method, add one. Signed-off-by:
Joakim Tjernlund <joakim.tjernlund@infinera.com> Reviewed-by:
Qiang Zhao <qiang.zhao@nxp.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Krzysztof Kozlowski authored
The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Acked-by:
Stephen Boyd <sboyd@kernel.org> Acked-by:
Sylwester Nawrocki <snawrocki@kernel.org>
-
- 23 Jul, 2018 1 commit
-
-
Leonard Crestez authored
Right now the only user of reset-imx7 is pci-imx6 and the reset_control_assert and deassert calls on pciephy_reset don't toggle the PCIEPHY_BTN and PCIEPHY_G_RST bits as expected. Fix this by writing 1 or 0 respectively. The reference manual is not very clear regarding SRC_PCIEPHY_RCR but for other registers like MIPIPHY and HSICPHY the bits are explicitly documented as "1 means assert, 0 means deassert". The values are still reversed for IMX7_RESET_PCIE_CTRL_APPS_EN. Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de>
-
- 21 Jul, 2018 21 commits
-
-
Olof Johansson authored
Merge tag 'imx-drivers-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/drivers i.MX drivers update for 4.19: - Handle i.MX6SL chip errata ERR006287 in the safest possible way by keeping the DISP domain always-on, because Upon resuming from power gating, the modules in the display power domain (eLCDIF, EPDC, PXP and SPDC) might fail to perform register reads correctly. - Use GENPD_FLAG_ALWAYS_ON flag for i.MX6QP PU ERR009619 handling. It is functionally identical to the exsiting implementation but simpler and slightly faster. * tag 'imx-drivers-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: soc: imx6qp: Use GENPD_FLAG_ALWAYS_ON for PU errata soc: imx: gpc: Disable 6sl display power gating for ERR006287 Signed-off-by:
-
git://git.pengutronix.de/git/pza/linuxOlof Johansson authored
Reset controller changes for v4.19 This adds new drivers and bindings for the SDM845 AOSS (always on subsystem) reset controller and for the Uniphier USB3 core reset. SPI controller resets are added to the Uniphier reset driver. * tag 'reset-for-4.19' of git://git.pengutronix.de/git/pza/linux: reset: uniphier: add reset control support for SPI reset: uniphier: add USB3 core reset control dt-bindings: reset: uniphier: add USB3 core reset support reset: simple: export reset_simple_ops to be referred from modules reset: qcom: AOSS (always on subsystem) reset controller dt-bindings: reset: Add AOSS reset bindings for SDM845 SoCs Signed-off-by:
-
Johan Hovold authored
Make sure to set the mem device release callback before calling put_device() in a couple of probe error paths so that the containing object also gets freed. Fixes: d1de6d6c ("soc: qcom: Remote filesystem memory driver") Cc: stable <stable@vger.kernel.org> # 4.15 Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org>
-
Niklas Cassel authored
Add missing MODULE_LICENSE(). According to the SPDX-License-Identifier, the license is GPL v2. Fixes the following warning: WARNING: modpost: missing MODULE_LICENSE() in drivers/soc/qcom/llcc-slice.o Fixes: a3134fb0 ("drivers: soc: Add LLCC driver") Signed-off-by:
Niklas Cassel <niklas.cassel@linaro.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Raju P.L.S.S.S.N authored
The patch fixes the bug reported by Dan Carpenter. It removes the unnecessary err check for ‘tcs’ reported by static checker warning: drivers/soc/qcom/rpmh-rsc.c:111 tcs_invalidate() warn: 'tcs' isn't an ERR_PTR See also: drivers/soc/qcom/rpmh-rsc.c:178 get_tcs_for_msg() warn: 'tcs' isn't an ERR_PTR drivers/soc/qcom/rpmh-rsc.c:180 get_tcs_for_msg() warn: 'tcs' isn't an ERR_PTR https://www.spinics.net/lists/linux-soc/msg04624.html Fixes: 9a3afcfb ("drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Reviewed-by:
Lina Iyer <ilina@codeaurora.org> Signed-off-by:
-
Raju P.L.S.S.S.N authored
get_req_from_tcs introduced in patch[1] returns tcs_request from tcs_group. The size of tcs (of type - tcs_group) array in rsc_drv is TCS_TYPE_NR. So the loop index needs to be iterated up to TCS_TYPE_NR only. [1] https://patchwork.kernel.org/patch/10477547/Signed-off-by:
-
Niklas Cassel authored
Add a dummy qcom_scm_assign_mem() to enable building drivers when CONFIG_COMPILE_TEST=y && CONFIG_QCOM_SCM=n. All other qcom_scm_* functions already have a dummy version. Signed-off-by:
-
Douglas Anderson authored
Children of RPMh will need access to cmd_db. Rather than having each child have code to check if cmd_db is ready let's add the check to RPMh. With this we'll be able to remove this boilerplate code from clk-rpmh.c and qcom-rpmh-regulator.c. Neither of these files has landed upstream yet but patches are pretty far along. === This code is based upon v11 of Lina and Raju's RPMh series. Suggested-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
-
Lina Iyer authored
Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated TCS for active mode request, but drivers may still want to make active requests from these RSCs. In such cases re-purpose the wake TCS to send active state requests. The requirement for this is that the driver is aware that the wake TCS is being repurposed to send active request, hence the sleep and wake TCSes be invalidated before the active request is sent. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
Lina Iyer authored
Platform drivers need make a lot of resource state requests at the same time, say, at the start or end of an usecase. It can be quite inefficient to send each request separately. Instead they can give the RPMH library a batch of requests to be sent and wait on the whole transaction to be complete. rpmh_write_batch() is a blocking call that can be used to send multiple RPMH command sets. Each RPMH command set is set asynchronously and the API blocks until all the command sets are complete and receive their tx_done callbacks. Signed-off-by:
-
Lina Iyer authored
Platform drivers that want to send a request but do not want to block until the RPMH request completes have now a new API - rpmh_write_async(). The API allocates memory and send the requests and returns the control back to the platform driver. The tx_done callback from the controller is handled in the context of the controller's thread and frees the allocated memory. This API allows RPMH requests from atomic contexts as well. Signed-off-by:
-
Lina Iyer authored
Active state requests are sent immediately to the RSC controller, while sleep and wake state requests are cached in this driver to avoid taxing the RSC controller repeatedly. The cached values will be sent to the controller when the rpmh_flush() is called. Generally, flushing is a system PM activity and may be called from the system PM drivers when the system is entering suspend or deeper sleep modes during cpuidle. Also allow invalidating the cached requests, so they may be re-populated again. Signed-off-by:
Evan Green <evgreen@chromium.org> Reviewed-by:
-
Lina Iyer authored
Allow sleep and wake commands to be cleared from the respective TCSes, so that they can be re-populated. Signed-off-by:
-
Lina Iyer authored
Sleep and wake requests are sent when the application processor subsystem of the SoC is entering deep sleep states like in suspend. These requests help lower the system power requirements when the resources are not in use. Sleep and wake requests are written to the TCS slots but are not triggered at the time of writing. The TCS are triggered by the firmware after the last of the CPUs has executed its WFI. Since these requests may come in different batches of requests, it is the job of this controller driver to find and arrange the requests into the available TCSes. Signed-off-by:
-
Lina Iyer authored
Sending RPMH requests and waiting for response from the controller through a callback is common functionality across all platform drivers. To simplify drivers, add a library functions to create RPMH client and send resource state requests. rpmh_write() is a synchronous blocking call that can be used to send active state requests. Signed-off-by:
-
Lina Iyer authored
Log sent RPMH requests and interrupt responses in FTRACE. Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> [rplsssn@codeaurora.org: rebase to v4.18-rc1 & fix merge conflict] Signed-off-by:
-
Lina Iyer authored
Add device binding documentation for Qualcomm Technology Inc's RPMH RSC driver. The driver is used for communicating resource state requests for shared resources. Cc: devicetree@vger.kernel.org Signed-off-by:
Rob Herring <robh@kernel.org> [rplsssn@codeaurora.org: minor order correction for TCS type] Signed-off-by:
-
Lina Iyer authored
Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are <addr, value> with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by:
-
Rishabh Bhatnagar authored
LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own priority, size, ID and other config parameters. LLCC driver programs these parameters for each slice. Clients that are assigned to use LLCC need to get information such size & ID of the slice they get and activate or deactivate the slice as needed. LLCC driver provides API for the clients to perform these operations. Signed-off-by:
Channagoud Kadabi <ckadabi@codeaurora.org> Signed-off-by:
Rishabh Bhatnagar <rishabhb@codeaurora.org> Reviewed-by:
-
Rishabh Bhatnagar authored
Documentation for last level cache controller device tree bindings, client bindings usage examples. Signed-off-by:
-
Bjorn Andersson authored
The moved check for the global partition ended up in the wrong place and I failed to spot this in my review. This moves it to the correct place. Fixes: 11d2e7ed ("soc: qcom: smem: check sooner in qcom_smem_set_global_partition()") Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
