aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/soc
AgeCommit message (Collapse)AuthorFilesLines
2020-05-07soc: fsl: dpio: properly compute the consumer indexIoana Ciornei1-0/+1
Mask the consumer index before using it. Without this, we would be writing frame descriptors beyond the ring size supported by the QBMAN block. Fixes: 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array mode with ring mode enqueue") Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Li Yang <leoyang.li@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-07soc/tegra: pmc: Enable PMIC wake event on Tegra194Jon Hunter1-0/+1
The PMIC wake event can be used to bring the system out of suspend based on certain events happening on the PMIC (such as an RTC alarm). Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-05-07soc/tegra: pmc: Select GENERIC_PINCONFCorentin Labbe1-0/+1
I have hit the following build error: armv7a-hardfloat-linux-gnueabi-ld: drivers/soc/tegra/pmc.o: in function `pinconf_generic_dt_node_to_map_pin': pmc.c:(.text+0x500): undefined reference to `pinconf_generic_dt_node_to_map' armv7a-hardfloat-linux-gnueabi-ld: drivers/soc/tegra/pmc.o:(.rodata+0x1f88): undefined reference to `pinconf_generic_dt_free_map' So SOC_TEGRA_PMC should select GENERIC_PINCONF. Fixes: 4a37f11c8f57 ("soc/tegra: pmc: Implement pad configuration via pinctrl") Cc: stable <stable@vger.kernel.org> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-05-07rpmsg: glink: Integrate glink_ssr in qcom_glinkBjorn Andersson3-180/+0
In all but the very special case of a system with _only_ glink_rpm, GLINK is dependent on glink_ssr, so move it to rpmsg and combine it with qcom_glink_native in the new qcom_glink kernel module. Acked-by: Chris Lew <clew@codeaurora.org> Acked-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/20200423003736.2027371-4-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-07soc: qcom: glink_ssr: Internalize ssr_notifiersBjorn Andersson1-5/+19
Rather than carrying a special purpose blocking notifier for glink_ssr in remoteproc's qcom_common.c, move it into glink_ssr so allow wider reuse of the common one. The rpmsg glink header file is used in preparation for the next patch. Acked-by: Chris Lew <clew@codeaurora.org> Acked-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Link: https://lore.kernel.org/r/20200423003736.2027371-3-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-04soc: renesas: Add Renesas R8A7742 config optionLad Prabhakar1-0/+7
Add configuration option for the RZ/G1H (R8A77420) SoC. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Link: https://lore.kernel.org/r/1588197415-13747-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-04-30soc: renesas: rcar-rst: Add support for RZ/G1HLad Prabhakar1-0/+1
Add support for RZ/G1H (R8A7742) to the R-Car RST driver. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Link: https://lore.kernel.org/r/1587678050-23468-6-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-04-30soc: renesas: rcar-sysc: Add R8A7742 supportLad Prabhakar5-0/+51
Add support for RZ/G1H (R8A7742) SoC power areas to the R-Car SYSC driver. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Link: https://lore.kernel.org/r/1587678050-23468-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-04-28firmware: xilinx: Remove eemi ops for set_requirementRajan Vaja1-14/+2
Use direct function call instead of using eemi ops for set_requirement. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-19-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for release_nodeRajan Vaja1-4/+1
Use direct function call instead of using eemi ops for release_node. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-18-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for request_nodeRajan Vaja1-4/+1
Use direct function call instead of using eemi ops for request_node. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-17-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for set_suspend_modeRajan Vaja1-5/+1
Use direct function call instead of eemi ops for set_suspend_mode. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-16-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for init_finalizeRajan Vaja1-8/+1
Use direct function call instead of eemi ops for init_finalize. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-15-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for get_api_versionRajan Vaja1-2/+2
Use direct function calls instead of using eemi ops. So remove eemi ops for get_api_version and use direct function call. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-2-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-22soc/tegra: fuse: Update the SoC revision attribute to display a nameJon Hunter1-1/+2
Currently the SoC revision attribute for Tegra devices displays the value of the enum associated with a particular revision. This is not very useful because to obtain the actual revision you need to use the tegra_revision enumeration to translate the value. It is more meaningful to display a name for the revision, such as 'A01', than the enumarated value and therefore, update the revision attribute to display a name. This change does alter the ABI, which is unfortunate, but this is more meaningful and maintable. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-04-22soc/tegra: fuse: Trivial clean-up of tegra_init_revision()Jon Hunter1-13/+9
Clean-up the tegra_init_revision() function by removing the 'rev' variable which is not needed and use the newly added helper function tegra_get_minor_rev() to get the minor revision. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-04-22soc/tegra: fuse: Add custom SoC attributesJon Hunter5-0/+79
Add a custom SoC attribute for Tegra to expose the HIDREV register fields to userspace via the sysfs. This register provides additional details about the type of device (eg, silicon, FPGA, etc) as well as revision. Exposing this information is useful for identifying the exact device revision and device type. For Tegra devices up until Tegra186, the majorrev and minorrev fields of the HIDREV register are used to determine the device revision and device type. For Tegra194, the majorrev and minorrev fields only determine the revision. Starting with Tegra194, there is an additional field, pre_si_platform (which occupies bits 20-23), that now determines device type. Therefore, for all Tegra devices, add a custom SoC attribute for the majorrev and minorrev fields and for Tegra194 add an additional attribute for the pre_si_platform field. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-04-22soc/tegra: pmc: Enable PMIC wake event on Tegra186Thierry Reding1-0/+1
The PMIC wake event can be used to bring the system out of suspend based on certain events happening on the PMIC (such as an RTC alarm). Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com>
2020-04-21Merge tag 'zynqmp-soc-for-v5.7-rc3' of https://github.com/Xilinx/linux-xlnx into arm/fixesArnd Bergmann1-2/+2
arm64: soc: ZynqMP SoC fixes for v5.7 - Fix firmware driver dependency - Fix one spare warning in firmware driver * tag 'zynqmp-soc-for-v5.7-rc3' of https://github.com/Xilinx/linux-xlnx: firmware: xilinx: make firmware_debugfs_root static drivers: soc: xilinx: fix firmware driver Kconfig dependency Link: https://lore.kernel.org/r/4c6daeb0-bc61-8bdb-6ed6-5f58cd915326@monstr.eu Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-04-20soc: qcom: pdr: Remove impossible error conditionSibi Sankar1-4/+0
The patch fbe639b44a82: "soc: qcom: Introduce Protection Domain Restart helpers" leads to the following static checker warning: drivers/soc/qcom/pdr_interface.c:158 pdr_register_listener() '(resp.curr_state < (-((~0 >> 1)) - 1)) => (s32min-s32max < s32min)' These are casted to int so they can't be outside of int range. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200415062955.21439-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-20soc: qcom: rpmh: Dirt can only make you dirtier, not cleanerDouglas Anderson1-4/+4
Adding an item into the cache should never be able to make the cache cleaner. Use "|=" rather than "=" to update the dirty flag. Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Thanks, Maulik Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: bb7000677a1b ("soc: qcom: rpmh: Update dirty flag only when data changes") Reported-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200417141531.1.Ia4b74158497213eabad7c3d474c50bfccb3f342e@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-20soc: qcom: rpmhpd: Add SM8250 power domainsBjorn Andersson1-0/+19
Tested-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200415062154.741179-2-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-19soc: qcom: cmd-db: Properly endian swap the slv_id for debugfsStephen Boyd1-1/+1
Read the slv_id properly by making sure the 16-bit number is endian swapped from little endian to CPU native before we read it to figure out what to print for the human readable name. Otherwise we may just show that all the elements in the cmd-db are "Unknown" which isn't right. Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reported-by: kbuild test robot <lkp@intel.com> Cc: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200417000645.234693-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-19soc: qcom: cmd-db: Use 5 digits for printing addressStephen Boyd1-1/+1
The top few bits aren't relevant to pad out because they're always zero. Let's just print 5 digits instead of 8 so that it's a little shorter and more readable. Reviewed-by: Lina Iyer <ilina@codeaurora.org> Suggested-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200415192916.78339-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-19soc: qcom: cmd-db: Cast sizeof() to int to silence field width warningStephen Boyd1-1/+1
We pass the result of sizeof() here to tell the printk format specifier how many bytes to print. That expects an int though and sizeof() isn't that type. Cast to int to silence this warning: drivers/soc/qcom/cmd-db.c: In function 'cmd_db_debugfs_dump': drivers/soc/qcom/cmd-db.c:281:30: warning: field width specifier '*' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=] Reviewed-by: Guenter Roeck <linux@roeck-us.net> Fixes: d6815c5c43d4 ("soc: qcom: cmd-db: Add debugfs dumping file") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200415062033.66406-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-17soc: imx8: select SOC_BUSArnd Bergmann1-0/+1
Compile-testing the driver can result in a link failure when CONFIG_SOC_BUS is disabled: x86_64-linux-ld: drivers/soc/imx/soc-imx8m.o: in function `imx8_soc_init': soc-imx8m.c:(.init.text+0x28d): undefined reference to `soc_device_register' Select it from Kconfig, as we do from the other SoC drivers. Link: https://lore.kernel.org/r/20200409075208.2824062-1-arnd@arndb.de Fixes: fc40200ebf82 ("soc: imx: increase build coverage for imx8m soc driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-04-17soc: fsl: dpio: avoid stack usage warningArnd Bergmann1-5/+14
A 1024 byte variable on the stack will warn on any 32-bit architecture during compile-testing, and is generally a bad idea anyway: fsl/dpio/dpio-service.c: In function 'dpaa2_io_service_enqueue_multiple_desc_fq': fsl/dpio/dpio-service.c:495:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] There are currently no callers of this function, so I cannot tell whether dynamic memory allocation is allowed once callers are added. Change it to kcalloc for now, if anyone gets a warning about calling this in atomic context after they start using it, they can fix it later. Link: https://lore.kernel.org/r/20200408185834.434784-1-arnd@arndb.de Fixes: 9d98809711ae ("soc: fsl: dpio: Adding QMAN multiple enqueue interface") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-04-17soc: fsl: dpio: fix incorrect pointer conversionsArnd Bergmann1-4/+2
Building dpio for 32 bit shows a new compiler warning from converting a pointer to a u64: drivers/soc/fsl/dpio/qbman-portal.c: In function 'qbman_swp_enqueue_multiple_desc_direct': drivers/soc/fsl/dpio/qbman-portal.c:870:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 870 | addr_cena = (uint64_t)s->addr_cena; The variable is not used anywhere, so removing the assignment seems to be the correct workaround. After spotting what seemed to be some confusion about address spaces, I ran the file through sparse, which showed more warnings: drivers/soc/fsl/dpio/qbman-portal.c:756:42: warning: incorrect type in argument 1 (different address spaces) drivers/soc/fsl/dpio/qbman-portal.c:756:42: expected void const volatile [noderef] <asn:2> *addr drivers/soc/fsl/dpio/qbman-portal.c:756:42: got unsigned int [usertype] *[assigned] p drivers/soc/fsl/dpio/qbman-portal.c:902:42: warning: incorrect type in argument 1 (different address spaces) drivers/soc/fsl/dpio/qbman-portal.c:902:42: expected void const volatile [noderef] <asn:2> *addr drivers/soc/fsl/dpio/qbman-portal.c:902:42: got unsigned int [usertype] *[assigned] p Here, the problem is passing a token from memremap() into __raw_readl(), which is only defined to work on MMIO addresses but not RAM. Turning this into a simple pointer dereference avoids this warning as well. Link: https://lore.kernel.org/r/20200408185904.460563-1-arnd@arndb.de Fixes: 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array mode with ring mode enqueue") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-04-15drivers: soc: xilinx: fix firmware driver Kconfig dependencyArnd Bergmann1-2/+2
The firmware driver is optional, but the power driver depends on it, which needs to be reflected in Kconfig to avoid link errors: aarch64-linux-ld: drivers/soc/xilinx/zynqmp_power.o: in function `zynqmp_pm_isr': zynqmp_power.c:(.text+0x284): undefined reference to `zynqmp_pm_invoke_fn' The firmware driver can probably be allowed for compile-testing as well, so it's best to drop the dependency on the ZYNQ platform here and allow building as long as the firmware code is built-in. Fixes: ab272643d723 ("drivers: soc: xilinx: Add ZynqMP PM driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200408155224.2070880-1-arnd@arndb.de Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-04-14soc: qcom: rpmpd: Allow RPMPD driver to be loaded as a moduleJohn Stultz2-2/+7
This patch allow the rpmpd driver to be loaded as a permenent module. Meaning it can be loaded from a module, but then cannot be unloaded. Ideally, it would include a remove hook and related logic, but apparently the genpd code isn't able to track usage and cleaning things up? (See: https://lkml.org/lkml/2019/1/24/38) So making it a permenent module at least improves things slightly over requiring it to be a built in driver. Cc: Todd Kjos <tkjos@google.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rajendra Nayak <rnayak@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Acked-by: Saravana Kannan <saravanak@google.com> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20200326224459.105170-2-john.stultz@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-14soc: qcom: rpmhpd: Allow RPMHPD driver to be loaded as a moduleJohn Stultz2-1/+6
This patch allow the rpmhpd driver to be loaded as a permenent module. Meaning it can be loaded from a module, but then cannot be unloaded. Ideally, it would include a remove hook and related logic, but apparently the genpd code isn't able to track usage and cleaning things up? So making it a permenent module at least improves things slightly over requiring it to be a built in driver. Cc: Todd Kjos <tkjos@google.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rajendra Nayak <rnayak@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Acked-by: Saravana Kannan <saravanak@google.com> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20200326224459.105170-4-john.stultz@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-14soc: qcom: rpmh: Allow RPMH driver to be loaded as a moduleJohn Stultz2-1/+6
This patch allow the rpmh driver to be loaded as a permenent module. Meaning it can be loaded from a module, but then cannot be unloaded. Ideally, it would include a remove hook and related logic, but the rpmh driver is fairly core to the system, so once its loaded with almost anythign else to get the system to go, the dependencies are not likely to ever also be removed. So making it a permenent module at least improves things slightly over requiring it to be a built in driver. Acked-by: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Saravana Kannan <saravanak@google.com> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rajendra Nayak <rnayak@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20200326224459.105170-3-john.stultz@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-14soc: imx8m: No need to put node when of_find_compatible_node() failedAnson Huang1-4/+3
No need to put node when of_find_compatible_node() failed, return immediately to simplify the code. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-13soc: qcom: rpmh-rsc: read_tcs_reg()/write_tcs_reg() are not for IRQDouglas Anderson1-5/+6
The RSC_DRV_IRQ_ENABLE, RSC_DRV_IRQ_STATUS, and RSC_DRV_IRQ_CLEAR registers are not part of TCS 0. Let's not pretend that they are by using read_tcs_reg() and write_tcs_reg() and passing a bogus tcs_id of 0. We could introduce a new wrapper for these registers but it wouldn't buy us much. Let's just read/write directly. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.10.I2adf93809c692d0b673e1a86ea97c45644aa8d97@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Caller handles tcs_invalidate() exclusivityDouglas Anderson3-30/+15
Auditing tcs_invalidate() made me worried. Specifically I saw that it used spin_lock(), not spin_lock_irqsave(). That always worries me unless I can trace for sure that I'm in the interrupt handler or that someone else already disabled interrupts. Looking more at it, there is actually no reason for these locks anyway. Specifically the only reason you'd ever call rpmh_rsc_invalidate() is if you cared that the sleep/wake TCSes were empty. That means that they need to continue to be empty even after rpmh_rsc_invalidate() returns. The only way that can happen is if the caller already has done something to keep all other RPMH users out. It should be noted that even though the caller is only worried about making sleep/wake TCSes empty, they also need to worry about stopping active-only transfers if they need to handle the case where active-only transfers might borrow the wake TCS. At the moment rpmh_rsc_invalidate() is only called in PM code from the last CPU. If that later changes the caller will still need to solve the above problems themselves, so these locks will never be useful. Continuing to audit tcs_invalidate(), I found a bug. The function didn't properly check for a borrowed TCS if we hadn't recently written anything into the TCS. Specifically, if we've never written to the WAKE_TCS (or we've flushed it recently) then tcs->slots is empty. We'll early-out and we'll never call tcs_is_free(). I thought about fixing this bug by either deleting the early check for bitmap_empty() or possibly only doing it if we knew we weren't on a TCS that could be borrowed. However, I think it's better to just delete the checks. As argued above it's up to the caller to make sure that all other users of RPMH are quiet before tcs_invalidate() is called. Since callers need to handle the zero-active-TCS case anyway that means they need to make sure that the active-only transfers are quiet before calling too. The one way tcs_invalidate() gets called today is through rpmh_rsc_cpu_pm_callback() which calls rpmh_rsc_ctrlr_is_busy() to handle this. When we have another path to get to tcs_invalidate() it will also need to come up with something similar and it won't need this extra check either. If we later find some code path that actually needs this check back in (and somehow manages to be race free) we can always add it back in. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.9.I07c1f70e0e8f2dc0004bd38970b4e258acdc773e@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Don't double-check rpmh payloadDouglas Anderson1-17/+1
The calls rpmh_rsc_write_ctrl_data() and rpmh_rsc_send_data() are only ever called from rpmh.c. We know that rpmh.c already error checked the message. There's no reason to do it again in rpmh-rsc. Suggested-by: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.8.I8e187cdfb7a31f5bb7724f1f937f2862ee464a35@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: tcs_is_free() can just check tcs_in_useDouglas Anderson1-3/+1
tcs_is_free() had two checks in it: does the software think that the TCS is free and does the hardware think that the TCS is free. I couldn't figure out in which case the hardware could think that a TCS was in-use but software thought it was free. Apparently there is no case and the extra check can be removed. This apparently has already been done in a downstream patch. Suggested-by: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.7.Icf2213131ea652087f100129359052c83601f8b0@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: A lot of commentsDouglas Anderson2-37/+247
I've been pouring through the rpmh-rsc code and trying to understand it. Document everything to the best of my ability. All documentation here is strictly from code analysis--no actual knowledge of the hardware was used. If something is wrong in here I either misunderstood the code, had a typo, or the code has a bug in it leading to my incorrect understanding. In a few places here I have documented things that don't make tons of sense. A future patch will try to address this. While this means I'm adding comments / todos and then later fixing them in the series, it seemed more urgent to get things documented first so that people could understand the later patches. Any comments I adjusted I also tried to make match kernel-doc better. Specifically: - kernel-doc says do not leave a blank line between the function description and the arguments - kernel-doc examples always have things starting w/ a capital and ending with a period. This should be a no-op. It's just comment changes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200413100321.v4.6.I52653eb85d7dc8981ee0dafcd0b6cc0f273e9425@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Kill cmd_cache and find_match() with fireDouglas Anderson2-49/+0
The "cmd_cache" in RPMH wasn't terribly sensible. Specifically: - The current code doesn't really detect "conflicts" properly any case where the sequence being checked has more than one entry. One simple way to see this in the current code is that if cmd[0].addr isn't found then cmd[1].addr is never checked. - The code attempted to use the "cmd_cache" to update an existing message in a sleep/wake TCS with new data. The goal appeared to be to update part of a TCS while leaving the rest of the TCS alone. We never actually do this. We always fully invalidate and re-write everything. - If/when we try to optimize things to not fully invalidate / re-write every time we update the TCSes we'll need to think it through very carefully. Specifically requirement of find_match() that the new sequence of addrs must match exactly the old sequence of addrs seems inflexible. It's also not documented in rpmh_write() and rpmh_write_batch(). In any case, if we do decide to require updates to keep the exact same sequence and length then presumably the API and data structures should be updated to understand groups more properly. The current algorithm doesn't really keep track of the length of the old sequence and there are several boundary-condition bugs because of that. Said another way: if we decide to do something like this in the future we should start from scratch and thus find_match() isn't useful to keep around. This patch isn't quite a no-op. Specifically: - It should be a slight performance boost of not searching through so many arrays. - The old code would have done something useful in one case: it would allow someone calling rpmh_write() to override the data that came from rpmh_write_batch(). I don't believe that actually happens in reality. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.5.I6d3d0a3ec810dc72ff1df3cbf97deefdcdeb8eef@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Remove get_tcs_of_type() abstractionDouglas Anderson1-12/+5
The get_tcs_of_type() function doesn't provide any value. It's not conceptually difficult to access a value in an array, even if that value is in a structure and we want a pointer to the value. Having the function in there makes me feel like it's doing something fancier like looping or searching. Remove it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.4.Ia348ade7c6ed1d0d952ff2245bc854e5834c8d9a@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Fold tcs_ctrl_write() into its single callerDouglas Anderson1-22/+17
I was trying to write documentation for the functions in rpmh-rsc and I got to tcs_ctrl_write(). The documentation for the function would have been: "This is the core of rpmh_rsc_write_ctrl_data(); all the caller does is error-check and then call this". Having the error checks in a separate function doesn't help for anything since: - There are no other callers that need to bypass the error checks. - It's less documenting. When I read tcs_ctrl_write() I kept wondering if I need to handle cases other than ACTIVE_ONLY or cases with more commands than could fit in a TCS. This is obvious when the error checks and code are together. - The function just isn't that long, so there's no problem understanding the combined function. Things were even more confusing because the two functions names didn't make obvious (at least to me) their relationship. Simplify by folding one function into the other. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.3.Ie88ce5ccfc0c6055903ccca5286ae28ed3b85ed3@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Document the register layout betterDouglas Anderson1-5/+74
Perhaps it's just me, it took a really long time to understand what the register layout of rpmh-rsc was just from the #defines. Let's add a bunch of comments describing which blocks are part of other blocks. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200413100321.v4.2.Iaddc29b72772e6ea381238a0ee85b82d3903e5f2@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Clean code reading/writing TCS regs/cmdsDouglas Anderson1-14/+19
This patch makes two changes, both of which should be no-ops: 1. Make read_tcs_reg() / read_tcs_cmd() symmetric to write_tcs_reg() / write_tcs_cmd(). 2. Change the order of operations in the above functions to make it more obvious to me what the math is doing. Specifically first you want to find the right TCS, then the right register, and then multiply by the command ID if necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/20200413100321.v4.1.I1b754137e8089e46cf33fc2ea270734ec3847ec4@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Allow using free WAKE TCS for active requestMaulik Shah1-12/+11
When there are more than one WAKE TCS available and there is no dedicated ACTIVE TCS available, invalidating all WAKE TCSes and waiting for current transfer to complete in first WAKE TCS blocks using another free WAKE TCS to complete current request. Remove rpmh_rsc_invalidate() to happen from tcs_write() when WAKE TCSes is re-purposed to be used for Active mode. Clear only currently used WAKE TCS's register configuration. Fixes: 2de4b8d33eab (drivers: qcom: rpmh-rsc: allow active requests from wake TCS) Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1586703004-13674-7-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh-rsc: Clear active mode configuration for wake TCSRaju P.L.S.S.S.N1-23/+54
For RSCs that have sleep & wake TCS but no dedicated active TCS, wake TCS can be re-purposed to send active requests. Once the active requests are sent and response is received, the active mode configuration needs to be cleared so that controller can use wake TCS for sending wake requests. Introduce enable_tcs_irq() to enable completion IRQ for repurposed TCSes. Fixes: 2de4b8d33eab (drivers: qcom: rpmh-rsc: allow active requests from wake TCS) Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> [mkshah: call enable_tcs_irq() within drv->lock, update commit message] Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1586703004-13674-6-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh: Invoke rpmh_flush() for dirty cachesMaulik Shah3-37/+139
Add changes to invoke rpmh flush() from CPU PM notification. This is done when the last the cpu is entering deep CPU idle states and controller is not busy. Controllers that have 'HW solver' mode like display RSC do not need to register for CPU PM notification. They may be in autonomous mode executing low power mode and do not require rpmh_flush() to happen from CPU PM notification. Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1586703004-13674-5-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh: Invalidate SLEEP and WAKE TCSes before flushing new dataMaulik Shah1-23/+18
TCSes have previously programmed data when rpmh_flush() is called. This can cause old data to trigger along with newly flushed. Fix this by cleaning SLEEP and WAKE TCSes before new data is flushed. With this there is no need to invoke rpmh_rsc_invalidate() call from rpmh_invalidate(). Simplify rpmh_invalidate() by moving invalidate_batch() inside. Fixes: 600513dfeef3 ("drivers: qcom: rpmh: cache sleep/wake state requests") Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1586703004-13674-4-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: rpmh: Update dirty flag only when data changesMaulik Shah1-8/+11
Currently rpmh ctrlr dirty flag is set for all cases regardless of data is really changed or not. Add changes to update dirty flag when data is changed to newer values. Update dirty flag everytime when data in batch cache is updated since rpmh_flush() may get invoked from any CPU instead of only last CPU going to low power mode. Also move dirty flag updates to happen from within cache_lock and remove unnecessary INIT_LIST_HEAD() call and a default case from switch. Fixes: 600513dfeef3 ("drivers: qcom: rpmh: cache sleep/wake state requests") Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Srinivas Rao L <lsrao@codeaurora.org> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1586703004-13674-3-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: smp2p: Delete an error message in qcom_smp2p_probe()Markus Elfring1-3/+1
The function platform_get_irq() can log an error already. Thus omit a redundant message for the exception handling in the calling function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://lore.kernel.org/r/eb92fcfb-6181-1f9d-2601-61e5231bd892@web.de Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-13soc: qcom: cmd-db: Add debugfs dumping fileStephen Boyd1-2/+76
It's useful for kernel devs to understand what resources and data is stored inside command db. Add a file in debugufs called 'cmd-db' to dump the memory contents and strings for resources along with their addresses. E.g. Command DB DUMP Slave ARC (v16.0) ------------------------- 0x00030000: cx.lvl [00 00 10 00 40 00 80 00 c0 00 00 01 80 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00] 0x00030004: cx.tmr 0x00030010: mx.lvl [00 00 10 00 00 01 80 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00] 0x00030014: mx.tmr Cc: Lina Iyer <ilina@codeaurora.org> Cc: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200309185704.2491-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.