summaryrefslogtreecommitdiff
path: root/drivers/soc/ti
AgeCommit message (Collapse)AuthorFilesLines
2021-02-21Merge tag 'arm-drivers-v5.12' of ↵Linus Torvalds5-46/+61
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Arnd Bergmann: "Updates for SoC specific drivers include a few subsystems that have their own maintainers but send them through the soc tree: SCMI firmware: - add support for a completion interrupt Reset controllers: - new driver for BCM4908 - new devm_reset_control_get_optional_exclusive_released() function Memory controllers: - Renesas RZ/G2 support - Tegra124 interconnect support - Allow more drivers to be loadable modules TEE/optee firmware: - minor code cleanup The other half of this is SoC specific drivers that do not belong into any other subsystem, most of them living in drivers/soc: - Allwinner/sunxi power management work - Allwinner H616 support - ASpeed AST2600 system identification support - AT91 SAMA7G5 SoC ID driver - AT91 SoC driver cleanups - Broadcom BCM4908 power management bus support - Marvell mbus cleanups - Mediatek MT8167 power domain support - Qualcomm socinfo driver support for PMIC - Qualcomm SoC identification for many more products - TI Keystone driver cleanups for PRUSS and elsewhere" * tag 'arm-drivers-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (89 commits) soc: aspeed: socinfo: Add new systems soc: aspeed: snoop: Add clock control logic memory: tegra186-emc: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE memory: samsung: exynos5422-dmc: Correct function names in kerneldoc memory: ti-emif-pm: Drop of_match_ptr from of_device_id table optee: simplify i2c access drivers: soc: atmel: fix type for same7 tee: optee: remove need_resched() before cond_resched() soc: qcom: ocmem: don't return NULL in of_get_ocmem optee: sync OP-TEE headers tee: optee: fix 'physical' typos drivers: optee: use flexible-array member instead of zero-length array tee: fix some comment typos in header files soc: ti: k3-ringacc: Use of_device_get_match_data() soc: ti: pruss: Refactor the CFG sub-module init soc: mediatek: pm-domains: Don't print an error if child domain is deferred soc: mediatek: pm-domains: Add domain regulator supply dt-bindings: power: Add domain regulator supply soc: mediatek: cmdq: Remove cmdq_pkt_flush() soc: mediatek: pm-domains: Add support for mt8167 ...
2021-02-01soc: ti: k3-ringacc: Use of_device_get_match_data()Suman Anna1-4/+3
Simplify the retrieval of getting the match data in the probe function by directly using of_device_get_match_data() instead of using of_match_node() and getting data. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-02-01soc: ti: pruss: Refactor the CFG sub-module initSuman Anna1-41/+50
The CFG sub-module is not present on some earlier SoCs like the DA850/OMAPL-138 in the TI Davinci family. Refactor out the CFG sub-module parse and initialization logic into a separate function to make it easier to add logic for the PRUSS IP on the above legacy SoC families. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-01-25soc: ti: pruss: Correct the pruss_clk_init error trace textSuman Anna1-1/+1
The pruss_clk_init() function can register more than one clock. Correct the existing misleading error trace upon a failure within this function. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-01-25soc: ti: pm33xx: Fix some resource leak in the error handling paths of the ↵Christophe JAILLET1-1/+4
probe function 'am33xx_pm_rtc_setup()' allocates some resources that must be freed on the error. Commit 2152fbbd47c0 ("soc: ti: pm33xx: Simplify RTC usage to prepare to drop platform data") has introduced the use of these resources but has only updated the remove function. Fix the error handling path of the probe function now. Fixes: 2152fbbd47c0 ("soc: ti: pm33xx: Simplify RTC usage to prepare to drop platform data") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-01-25soc: ti: knav_qmss: Put refcount for dev node in failure caseVasyl Gomonovych2-0/+4
for_each_child_of_node increases refcount for each device_node and decreases previous one in a loop, but in case jump out of a loop current node refcount has no chnase for decreases so requires an of_node_put for jupm out cases. Fix based on raport from scripts/coccinelle/iterators/for_each_child.cocci Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-01-15Merge branch 'cpuidle-fix' into fixesTony Lindgren10-148/+780
2020-12-30soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1Tony Lindgren1-0/+11
We have rst_map_012 used for various accelerators like dsp, ipu and iva. For these use cases, we have rstctrl bit 2 control the subsystem module reset, and have and bits 0 and 1 control the accelerator specific features. If the bootloader, or kexec boot, has left any accelerator specific reset bits deasserted, deasserting bit 2 reset will potentially enable an accelerator with unconfigured MMU and no firmware. And we may get spammed with a lot by warnings on boot with "Data Access in User mode during Functional access", or depending on the accelerator, the system can also just hang. This issue can be quite easily reproduced by setting a rst_map_012 type rstctrl register to 0 or 4 in the bootloader, and booting the system. Let's just assert all reset bits for rst_map_012 type resets. So far it looks like the other rstctrl types don't need this. If it turns out that the other type rstctrl bits also need reset on init, we need to add an instance specific reset mask for the bits to avoid resetting unwanted bits. Reported-by: Carl Philipp Klemm <philipp@uvos.xyz> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Suman Anna <s-anna@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Tested-by: Carl Philipp Klemm <philipp@uvos.xyz> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-12-17Merge tag 'dmaengine-5.11-rc1' of ↵Linus Torvalds1-7/+318
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine updates from Vinod Koul: "The last dmaengine updates for this year :) This contains couple of new drivers, new device support and updates to bunch of drivers. New drivers/devices: - Qualcomm ADM driver - Qualcomm GPI driver - Allwinner A100 DMA support - Microchip Sama7g5 support - Mediatek MT8516 apdma Updates: - more updates to idxd driver and support for IAX config - runtime PM support for dw driver - TI drivers" * tag 'dmaengine-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (75 commits) soc: ti: k3-ringacc: Use correct error casting in k3_ringacc_dmarings_init dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA dmaengine: ti: k3-udma: Initial support for K3 PKTDMA dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling dmaengine: ti: k3-udma: Initial support for K3 BCDMA soc: ti: k3-ringacc: add AM64 DMA rings support. dmaengine: ti: Add support for k3 event routers dmaengine: ti: k3-psil: Add initial map for AM64 dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA dt-bindings: dma: ti: Add document for K3 PKTDMA dt-bindings: dma: ti: Add document for K3 BCDMA dmaengine: dmatest: Use dmaengine_get_dma_device dmaengine: doc: client: Update for dmaengine_get_dma_device() usage dmaengine: Add support for per channel coherency handling dmaengine: of-dma: Add support for optional router configuration callback dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings dmaengine: ti: k3-udma-glue: Get the ringacc from udma_dev dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API dmaengine: ti: k3-udma: Add support for second resource range from sysfw dmaengine: ti: k3-udma: Wait for peer teardown completion if supported ...
2020-12-17Merge tag 'arm-soc-omap-genpd-5.11' of ↵Linus Torvalds1-20/+254
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC OMAP GenPD updates from Arnd Bergmann: "These are additional updates for the power domain support on OMAP, moving to an implementation based on device tree information instead of SoC specific code. This is the latest step in the ongoing process for moving code out of arch/arm/mach-omap2. I kept this separate from the other driver changes since it touches code in multiple areas" * tag 'arm-soc-omap-genpd-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (51 commits) ARM: OMAP2+: Fix am4 only build after genpd changes ARM: dts: Configure power domain for omap5 dss ARM: dts: omap5: add remaining PRM instances soc: ti: omap-prm: omap5: add genpd support for remaining PRM instances ARM: OMAP2+: Drop legacy platform data for dra7 gpmc ARM: dts: Configure interconnect target module for dra7 iva ARM: dts: dra7: add remaining PRM instances soc: ti: omap-prm: dra7: add genpd support for remaining PRM instances clk: ti: dra7: Drop idlest polling from IVA clkctrl clocks ARM: OMAP2+: Drop legacy platform data for omap4 gpmc ARM: OMAP2+: Drop legacy platform data for omap4 iva ARM: dts: Configure power domain for omap4 dsp ARM: dts: Configure power domain for omap4 dss ARM: dts: omap4: add remaining PRM instances soc: ti: omap-prm: omap4: add genpd support for remaining PRM instances clk: ti: omap4: Drop idlest polling from IVA clkctrl clocks ARM: OMAP2+: Drop legacy remaining legacy platform data for am4 ARM: dts: Use simple-pm-bus for genpd for am4 l3 ARM: dts: Move am4 l3 noc to a separate node ARM: dts: Use simple-pm-bus for genpd for am4 l4_per ...
2020-12-14soc: ti: k3-ringacc: Use correct error casting in k3_ringacc_dmarings_initPeter Ujfalusi1-1/+1
Use ERR_CAST() when devm_ioremap_resource() fails. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201214065421.5138-1-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11soc: ti: k3-ringacc: add AM64 DMA rings support.Grygorii Strashko1-7/+318
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a separate and generic ringacc is used. The ring SW interface is similar to ringacc with some major architectural differences, like They are part of the DMA (BCDMA or PKTDMA). They are dual mode rings are modeled as pair of Rings objects which has common configuration and memory buffer, but separate real-time control register sets for each direction mem2dev (forward) and dev2mem (reverse). The ringacc driver must be initialized for DMA rings use with k3_ringacc_dmarings_init() as it is not an independent device as ringacc is. AM64 rings must be requested only using k3_ringacc_request_rings_pair(), and forward ring must always be initialized/configured. After this any other Ringacc APIs can be used without any callers changes. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-17-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-09Merge tag 'drivers_soc_for_5.11' of ↵Arnd Bergmann9-116/+112
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone into arm/drivers drivers: soc: TI SOC changes for 5.11 - ti_sci changes towards DMSS support - Static warning fixes - Kconfig update for Keystone ARM64 socs - AM64X SOC family support * tag 'drivers_soc_for_5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone: (23 commits) drivers: soc: ti: knav_qmss_queue: Fix error return code in knav_queue_probe soc: ti: Fix reference imbalance in knav_dma_probe soc: ti: pruss: Remove wrong check against *get_match_data return value soc: ti: Kconfig: Drop ARM64 SoC specific configs soc: ti: k3-ringacc: Provide documentation for 'k3_ring's 'state' soc: ti: wkup_m3_ipc: Document 'm3_ipc' parameter throughout soc: ti: pm33xx: Remove set but unused variable 'ret' soc: ti: knav_dma: Fix a kernel function doc formatting issue soc: ti: knav_qmss_queue: Fix a whole host of function documentation issues soc: ti: knav_qmss_queue: Remove set but unchecked variable 'ret' soc: ti: omap-prm: Do not check rstst bit on deassert if already deasserted soc: ti: knav_qmss: fix reference leak in knav_queue_probe soc: ti: k3-socinfo: Add entry for AM64X SoC family soc: ti: k3-ringacc: Use correct device for allocation in RING mode firmware: ti_sci: rm: Remove unused config() from ti_sci_rm_ringacc_ops soc: ti: k3-ringacc: Use the ti_sci set_cfg callback for ring configuration firmware: ti_sci: rm: Add new ops for ring configuration firmware: ti_sci: rm: Remove ring_get_config support firmware: ti_sci: rm: Add support for extended_ch_type for tx channel soc: ti: ti_sci_inta_msi: Add support for second range in resource ranges ... Link: https://lore.kernel.org/r/1606851405-26338-1-git-send-email-santosh.shilimkar@oracle.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09Merge tag 'omap-for-v5.11/genpd-drivers-signed' of ↵Arnd Bergmann2-5/+96
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/drivers Driver changes for omaps for genpd for v5.11 merge window This series of changes allows booting am335x with genpd and device tree data without the legacy platform data. Also at least am437x can be booted with gendp with power domain and dts data. The SoC specific dts changes will be a separate pull request. We need the following driver changes merged before the dts changes can be done: - platform code needs a few improvments to probe l4_wkup first for clocks, and to bail out when there is no platform data - ti-sysc driver needs a non-urgent fix for asserting rstctrl reset only after disabling the clocks, to probe modules with no known control registers, and added quirk handling for gpmc devices - omap-prm driver needs a non-urgent fix for reset status bit, support added for pm_clk, and then we add the rest of am335x power domain data - clock driver for am335x needs to keep l3_main clock enabled with genpd for suspend and resume to work - wkup_m3 remoteproc driver needs support added for reset control if available instead of the legacy pdata callbacks - pm33xx driver needs PM runtime support added for genpd The am335x specific driver changes for the clock, wkup_m3, pm33xx and remoteproc drivers are quite trivial and have not caused merge conflicts in Linux next. I did not get acks for these changes except from Santosh but had already pushed out the branch already at that point. So I've added the related driver maintainers to Cc. * tag 'omap-for-v5.11/genpd-drivers-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: remoteproc/wkup_m3: Use reset control driver if available soc: ti: pm33xx: Enable basic PM runtime support for genpd soc: ti: omap-prm: am3: add genpd support for remaining PRM instances soc: ti: omap-prm: Add pm_clk for genpd clk: ti: am33xx: Keep am3 l3 main clock always on for genpd bus: ti-sysc: Implement GPMC debug quirk to drop platform data bus: ti-sysc: Support modules without control registers ARM: OMAP2+: Probe PRCM first to probe l4_wkup with simple-pm-bus ARM: OMAP2+: Check for inited flag bus: ti-sysc: Assert reset only after disabling clocks soc: ti: omap-prm: Do not check rstst bit on deassert if already deasserted bus: ti-sysc: Fix bogus resetdone warning on enable for cpsw bus: ti-sysc: Fix reset status check for modules with quirks ARM: OMAP2+: Fix missing select PM_GENERIC_DOMAINS_OF ARM: OMAP2+: Fix location for select PM_GENERIC_DOMAINS Link: https://lore.kernel.org/r/pull-1606806458-694517@atomide.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-11-22drivers: soc: ti: knav_qmss_queue: Fix error return code in knav_queue_probeZhihao Cheng1-1/+2
Fix to return the error code from of_get_child_by_name() instaed of 0 in knav_queue_probe(). Fixes: 41f93af900a20d1a0a ("soc: ti: add Keystone Navigator QMSS driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: Fix reference imbalance in knav_dma_probeZhang Qilong1-2/+11
The patch fix two reference leak. 1) pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to call put operation will result in reference leak. 2) The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced. We fix it by: 1) adding call pm_runtime_put_noidle or pm_runtime_put_sync in error handling. 2) adding pm_runtime_disable in error handling, to keep usage counter and disable depth balanced. Fixes: 88139ed030583 ("soc: ti: add Keystone Navigator DMA support") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: pruss: Remove wrong check against *get_match_data return valueGrzegorz Jaszczyk1-6/+0
Since the of_device_get_match_data() doesn't return error code, remove wrong IS_ERR test. Proper check against NULL pointer is already done later before usage: if (data && data->...). Additionally, proceeding with empty device data is valid (e.g. in case of "ti,am3356-pruss"). Reported-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: Kconfig: Drop ARM64 SoC specific configsNishanth Menon1-18/+0
With the integration of chip-id detection scheme in kernel[1], there is no specific need to maintain multitudes of SoC specific config options, discussed as per [2], we have deprecated the usage in other places for v5.10-rc1. Drop the configuration for the follow on kernel. [1] drivers/soc/ti/k3-socinfo.c commit 907a2b7e2fc7 ("soc: ti: add k3 platforms chipid module driver") Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: k3-ringacc: Provide documentation for 'k3_ring's 'state'Lee Jones1-0/+1
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/k3-ringacc.c:163: warning: Function parameter or member 'state' not described in 'k3_ring' Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: wkup_m3_ipc: Document 'm3_ipc' parameter throughoutLee Jones1-2/+6
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/wkup_m3_ipc.c:227: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_set_mem_type' drivers/soc/ti/wkup_m3_ipc.c:236: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_set_resume_address' drivers/soc/ti/wkup_m3_ipc.c:248: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_request_pm_status' drivers/soc/ti/wkup_m3_ipc.c:268: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_prepare_low_power' drivers/soc/ti/wkup_m3_ipc.c:322: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_finish_low_power' drivers/soc/ti/wkup_m3_ipc.c:369: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_set_rtc_only' drivers/soc/ti/wkup_m3_ipc.c:369: warning: Excess function parameter 'wkup_m3_wakeup' description in 'wkup_m3_set_rtc_only' Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: pm33xx: Remove set but unused variable 'ret'Lee Jones1-3/+1
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/pm33xx.c: In function ‘am33xx_do_sram_idle’: drivers/soc/ti/pm33xx.c:138:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: knav_dma: Fix a kernel function doc formatting issueLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/knav_dma.c:507: warning: Function parameter or member 'channel' not described in 'knav_dma_close_channel' Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Sandeep Nair <sandeep_n@ti.com> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: knav_qmss_queue: Fix a whole host of function documentation issuesLee Jones1-29/+30
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/knav_qmss_queue.c:528: warning: Function parameter or member 'flags' not described in 'knav_queue_open' drivers/soc/ti/knav_qmss_queue.c:528: warning: Function parameter or member 'id' not described in 'knav_queue_open' drivers/soc/ti/knav_qmss_queue.c:528: warning: Function parameter or member 'name' not described in 'knav_queue_open' drivers/soc/ti/knav_qmss_queue.c:551: warning: Excess function parameter 'qh' description in 'knav_queue_close' drivers/soc/ti/knav_qmss_queue.c:551: warning: Function parameter or member 'qhandle' not described in 'knav_queue_close' drivers/soc/ti/knav_qmss_queue.c:583: warning: Excess function parameter 'qh' description in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:583: warning: Function parameter or member 'arg' not described in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:583: warning: Function parameter or member 'cmd' not described in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:583: warning: Function parameter or member 'qhandle' not described in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:635: warning: Excess function parameter 'data' description in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Excess function parameter 'qh' description in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'dma' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'flags' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'qhandle' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'size' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:655: warning: Excess function parameter 'qh' description in 'knav_queue_pop' drivers/soc/ti/knav_qmss_queue.c:655: warning: Function parameter or member 'qhandle' not described in 'knav_queue_pop' drivers/soc/ti/knav_qmss_queue.c:655: warning: Function parameter or member 'size' not described in 'knav_queue_pop' drivers/soc/ti/knav_qmss_queue.c:759: warning: Function parameter or member 'name' not described in 'knav_pool_create' drivers/soc/ti/knav_qmss_queue.c:759: warning: Function parameter or member 'num_desc' not described in 'knav_pool_create' drivers/soc/ti/knav_qmss_queue.c:759: warning: Function parameter or member 'region_id' not described in 'knav_pool_create' drivers/soc/ti/knav_qmss_queue.c:862: warning: Excess function parameter 'pool' description in 'knav_pool_destroy' drivers/soc/ti/knav_qmss_queue.c:862: warning: Function parameter or member 'ph' not described in 'knav_pool_destroy' drivers/soc/ti/knav_qmss_queue.c:892: warning: Excess function parameter 'pool' description in 'knav_pool_desc_get' drivers/soc/ti/knav_qmss_queue.c:892: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_get' drivers/soc/ti/knav_qmss_queue.c:911: warning: Excess function parameter 'pool' description in 'knav_pool_desc_put' drivers/soc/ti/knav_qmss_queue.c:911: warning: Function parameter or member 'desc' not described in 'knav_pool_desc_put' drivers/soc/ti/knav_qmss_queue.c:911: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_put' drivers/soc/ti/knav_qmss_queue.c:931: warning: Excess function parameter 'pool' description in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'desc' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'dma' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'dma_sz' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'size' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:956: warning: Excess function parameter 'pool' description in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:956: warning: Function parameter or member 'dma' not described in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:956: warning: Function parameter or member 'dma_sz' not described in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:956: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:975: warning: Excess function parameter 'pool' description in 'knav_pool_count' drivers/soc/ti/knav_qmss_queue.c:975: warning: Function parameter or member 'ph' not described in 'knav_pool_count' Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Sandeep Nair <sandeep_n@ti.com> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: knav_qmss_queue: Remove set but unchecked variable 'ret'Lee Jones1-2/+1
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/knav_qmss_queue.c: In function ‘knav_setup_queue_pools’: drivers/soc/ti/knav_qmss_queue.c:1310:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Sandeep Nair <sandeep_n@ti.com> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: omap-prm: Do not check rstst bit on deassert if already deassertedTony Lindgren1-0/+4
If a rstctrl reset bit is already deasserted, we can just bail out early not wait for rstst to clear. Otherwise we can have deassert fail for already deasserted resets. Fixes: c5117a78dd88 ("soc: ti: omap-prm: poll for reset complete during de-assert") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-22soc: ti: knav_qmss: fix reference leak in knav_queue_probeZhang Qilong1-0/+1
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in knav_queue_probe, so we should fix it. Fixes: 41f93af900a20 ("soc: ti: add Keystone Navigator QMSS driver") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-19soc: ti: omap-prm: omap5: add genpd support for remaining PRM instancesTero Kristo1-4/+57
Add genpd support for mpu, dsp, coreaon, core, iva, cam, dss, gpu, l3init, custefuse, wkupaon and emu instances. Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19soc: ti: omap-prm: dra7: add genpd support for remaining PRM instancesTero Kristo1-9/+97
Add genpd support for mpu, dsp, ipu, coreaon, core, iva, cam, dss, gpu, l3init, l4per, custefuse, wkupaon, emu, eve, rtc and vpe instances. Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-19soc: ti: omap-prm: omap4: add genpd support for remaining PRM instancesTero Kristo1-4/+67
Add genpd support for mpu, tesla, always_on_core, core, ivahd, cam, dss, gfx, l3init, l4per, cefuse, wkup and emu instances. Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-16soc: ti: omap-prm: am4: add genpd support for remaining PRM instancesTero Kristo1-3/+33
Add genpd support for mpu, rtc, tamper, cefuse, per and wkup instances. Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-16soc: ti: pm33xx: Enable basic PM runtime support for genpdTony Lindgren1-2/+15
To prepare for moving to use genpd, let's enable basic PM runtime support. Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-16soc: ti: omap-prm: am3: add genpd support for remaining PRM instancesTero Kristo1-3/+33
Add genpd support for per, wkup, mpu, rtc and cefuse instances. Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-16soc: ti: omap-prm: Add pm_clk for genpdTony Lindgren1-0/+44
In order to probe l3 and l4 interconnects with simple-pm-bus, we want genpd to manage the clocks for the interconnects. For interconnect target modules, we already have ti-sysc manage the clocks so let's skipe managing clocks for ti-sysc modules. Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-13soc: ti: omap-prm: Do not check rstst bit on deassert if already deassertedTony Lindgren1-0/+4
If a rstctrl reset bit is already deasserted, we can just bail out early not wait for rstst to clear. Otherwise we can have deassert fail for already deasserted resets. Fixes: c5117a78dd88 ("soc: ti: omap-prm: poll for reset complete during de-assert") Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-11-02soc: ti: k3-socinfo: Add entry for AM64X SoC familyPeter Ujfalusi1-0/+1
It's JTAG PARTNO is 0xBB38. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-02soc: ti: k3-ringacc: Use correct device for allocation in RING modePeter Ujfalusi1-5/+13
In RING mode the ringacc does not access the ring memory. In this access mode the ringacc coherency does not have meaning. If the ring is configured in RING mode, then the ringacc itself will not access to the ring memory. Only the requester (user) of the ring is going to read/write to the memory. Extend the ring configuration parameters with a device pointer to be used for DMA API when the ring is configured in RING mode. Extending the ring configuration struct will allow per ring selection of device to be used for allocation, thus allowing per ring coherency. To avoid regression, fall back to use the ringacc dev in case the alloc_dev is not provided. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-02soc: ti: k3-ringacc: Use the ti_sci set_cfg callback for ring configurationPeter Ujfalusi1-47/+32
Switch to the new set_cfg to configure the ring. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-02soc: ti: ti_sci_inta_msi: Add support for second range in resource rangesPeter Ujfalusi1-0/+12
Allocate MSI entries for both first and second range if they are valid Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-10-30soc: ti: ti_sci_pm_domains: check for proper args count in xlateTero Kristo1-1/+1
K2G devices still only use single parameter for power-domains property, so check for this properly in the driver. Without this, every peripheral fails to probe resulting in boot failure. Link: https://lore.kernel.org/r/20201029093337.21170-1-t-kristo@ti.com Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one") Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-10-24Merge tag 'armsoc-drivers' of ↵Linus Torvalds8-158/+523
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC-related driver updates from Olof Johansson: "Various driver updates for platforms. A bulk of this is smaller fixes or cleanups, but some of the new material this time around is: - Support for Nvidia Tegra234 SoC - Ring accelerator support for TI AM65x - PRUSS driver for TI platforms - Renesas support for R-Car V3U SoC - Reset support for Cortex-M4 processor on i.MX8MQ There are also new socinfo entries for a handful of different SoCs and platforms" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (131 commits) drm/mediatek: reduce clear event soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add address shift in jump soc: mediatek: mtk-infracfg: Fix kerneldoc soc: amlogic: pm-domains: use always-on flag reset: sti: reset-syscfg: fix struct description warnings reset: imx7: add the cm4 reset for i.MX8MQ dt-bindings: reset: imx8mq: add m4 reset reset: Fix and extend kerneldoc reset: reset-zynqmp: Added support for Versal platform dt-bindings: reset: Updated binding for Versal reset driver reset: imx7: Support module build soc: fsl: qe: Remove unnessesary check in ucc_set_tdm_rxtx_clk soc: fsl: qman: convert to use be32_add_cpu() ...
2020-10-24Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds2-8/+313
Pull ARM SoC platform updates from Olof Johansson: "SoC changes, a substantial part of this is cleanup of some of the older platforms that used to have a bunch of board files. In particular: - Remove non-DT i.MX platforms that haven't seen activity in years, it's time to remove them. - A bunch of cleanup and removal of platform data for TI/OMAP platforms, moving over to genpd for power/reset control (yay!) - Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them closer to multiplatform support (not quite there yet, but getting close). There are a few other changes too, smaller fixlets, etc. For new platform support, the primary ones are: - New SoC: Hisilicon SD5203, ARM926EJ-S platform. - Cpufreq support for i.MX7ULP" * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits) ARM: mstar: Select MStar intc ARM: stm32: Replace HTTP links with HTTPS ones ARM: debug: add UART early console support for SD5203 ARM: hisi: add support for SD5203 SoC ARM: omap3: enable off mode automatically clk: imx: imx35: Remove mx35_clocks_init() clk: imx: imx31: Remove mx31_clocks_init() clk: imx: imx27: Remove mx27_clocks_init() ARM: imx: Remove unused definitions ARM: imx35: Retrieve the IIM base address from devicetree ARM: imx3: Retrieve the AVIC base address from devicetree ARM: imx3: Retrieve the CCM base address from devicetree ARM: imx31: Retrieve the IIM base address from devicetree ARM: imx27: Retrieve the CCM base address from devicetree ARM: imx27: Retrieve the SYSCTRL base address from devicetree ARM: s3c64xx: bring back notes from removed debug-macro.S ARM: s3c24xx: fix Wunused-variable warning on !MMU ARM: samsung: fix PM debug build with DEBUG_LL but !MMU MAINTAINERS: mark linux-samsung-soc list non-moderated ARM: imx: Remove remnant board file support pieces ...
2020-10-16PM: AVS: smartreflex Move driver to soc specific driversUlf Hansson2-0/+1046
The avs drivers are all SoC specific drivers that doesn't share any code. Instead they are located in a directory, mostly to keep similar functionality together. From a maintenance point of view, it makes better sense to collect SoC specific drivers like these, into the SoC specific directories. Therefore, let's move the smartreflex driver for OMAP to the ti directory. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-21soc: ti: Convert to DEFINE_SHOW_ATTRIBUTEQinglang Miao2-25/+5
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-12soc: ti: k3-socinfo: Add entry for J7200Peter Ujfalusi1-0/+1
Update K3 chipinfo driver to support new TI J7200 SoC. It's JTAG PARTNO is 0xBB6D. Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-12soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUXGrzegorz Jaszczyk1-7/+177
The IEPCLK_MUX is present on all SoCs whereas the CORECLK_MUX is present only on AM65x SoCs and J721E. Add support for both these CLK muxes. This allows the clock rates and clock parents for these to be controlled through DT leveraging the clk infrastructure for configuring the default parents and rates. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-12soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of oneTero Kristo1-130/+121
Current implementation of the genpd support over TI SCI uses a single genpd across the whole SoC, and attaches multiple devices to this. This solution has its drawbacks, like it is currently impossible to attach more than one power domain to a device; the core genpd implementation requires one genpd per power-domain entry in DT for a single device. Also, some devices like USB apparently require their own genpd during probe time, the current shared approach in use does not work at all. Switch the implementation over to use a single genpd per power domain entry in DT. The domains are registered with the onecell approach, but we also add our own xlate service due to recent introduction of the extended flag for TI SCI PM domains; genpd core xlate service requires a single cell per powerdomain, but we are using two cells. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-12soc: ti: pruss: Enable support for ICSSG subsystems on K3 J721E SoCsSuman Anna1-0/+1
The K3 J721E family of SoCs have a revised version of the PRU-ICSS (ICSSG) processor subsystem present on K3 AM65x SoCs. These SoCs contain typically two ICSSG instances named ICSSG0 and ICSSG1. The two ICSSGs are identical to each other for the most part with minor SoC integration differences and capabilities. The ICSSG1 supports slightly enhanced features like SGMII mode Ethernet, while the ICSSG0 instance is limited to MII mode only. There is no change in the Interrupt Controller w.r.t AM65x. All other integration aspects are very similar to the ICSSGs on AM65x SoCs. The existing pruss platform driver has been updated to support these new ICSSG instances through new J721E specific compatibles. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-12soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCsSuman Anna2-1/+2
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem capable of supporting Gigabit Ethernet, and is commonly referred to as ICSSG. These SoCs contain typically three ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are identical to each other for the most part with minor SoC integration differences and capabilities. The ICSSG2 supports slightly enhanced features like SGMII mode Ethernet, while the ICSS0 and ICSSG1 instances are limited to MII mode only. The ICSSGs on K3 AM65x SoCs are in general super-sets of the PRUSS on the AM57xx/66AK2G SoCs. They include two additional auxiliary PRU cores called RTUs and few other additional sub-modules. The interrupt integration is also different on the K3 AM65x SoCs and are propagated through various SoC-level Interrupt Router and Interrupt Aggregator blocks. Other IP level differences include different constant tables, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. The existing pruss platform driver has been updated to support these new ICSSG instances through new AM65x specific compatibles. A build dependency with ARCH_K3 is added to enable building all the existing PRUSS platform drivers for this ARMv8 platform. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-12soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoCSuman Anna2-1/+2
The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other with few minor SoC integration differences, and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data RAM size is larger and the number of interrupts coming into MPU INTC is like the instances on AM437x. There are also few other differences attributing to integration in Keystone architecture (like no SYSCFG register or PRCM handshake protocols). Other IP level differences include different constant table, differences in system event interrupt input sources etc. They also do not have a programmable module reset line like those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. The existing PRUSS platform driver has been enhanced to support these 66AK2G PRU-ICSS instances through new 66AK2G specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with ARCH_KEYSTONE is added to enable the driver to be built in K2G-only configuration. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-09-12soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCsSuman Anna2-1/+2
The AM57xx family of SoCs supports two PRU-ICSS instances, each of which has two PRU processor cores. The two PRU-ICSS instances are identical to each other, and are very similar to the PRU-ICSS1 of AM33xx/AM43xx except for a few minor differences like the RAM sizes and the number of interrupts coming into the MPU INTC. They do not have a programmable module reset line unlike those present on AM33xx/AM43xx SoCs. The modules are reset just like any other IP with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also preceded by a Crossbar that enables multiple external events to be routed to a specific number of input interrupt events. Any interrupt event directed towards PRUSS needs this crossbar to be setup properly on the firmware side. The existing PRUSS platform driver has been enhanced to support these AM57xx PRU-ICSS instances through new AM57xx specific compatible for properly probing and booting all the different PRU cores in each PRU-ICSS processor subsystem. A build dependency with SOC_DRA7XX is also added to enable the driver to be built in AM57xx-only configuration (there is no separate Kconfig option for AM57xx vs DRA7xx). Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>