summaryrefslogtreecommitdiff
path: root/drivers/soc/ti/omap_prm.c
AgeCommit message (Collapse)AuthorFilesLines
2022-04-15soc: ti: omap_prm: Use of_device_get_match_data()Minghao Chi (CGEL ZTE)1-5/+2
Since omap_prm_id_table all have (and expected to have) data entries, use of_device_get_match_data() to simplify the code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220307033736.2075221-1-chi.minghao@zte.com.cn
2021-09-30soc: ti: omap-prm: Fix external abort for am335x prussTony Lindgren1-12/+15
Starting with v5.15-rc1, we may now see some am335x beaglebone black device produce the following error on pruss probe: Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0326000 This has started with the enabling of pruss for am335x in the dts files. Turns out the is caused by the PRM reset handling not waiting for the reset bit to clear. To fix the issue, let's always wait for the reset bit to clear, even if there is a separate reset status register. We attempted to fix a similar issue for dra7 iva with a udelay() in commit effe89e40037 ("soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva"). There is no longer a need for the udelay() for dra7 iva reset either with the check added for reset bit clearing. Cc: Drew Fustini <pdp7pdp7@gmail.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: "H. Nikolaus Schaller" <hns@goldelico.com> Cc: Robert Nelson <robertcnelson@gmail.com> Cc: Yongqin Liu <yongqin.liu@linaro.org> Fixes: effe89e40037 ("soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva") Reported-by: Matti Vaittinen <mazziesaccount@gmail.com> Tested-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10soc: ti: omap-prm: Allow hardware supported retention when idleTony Lindgren1-4/+12
When moving the l4 interconnect instances to probe with simple-pm-bus and genpd, we will have l4per and core domains stop idling unless we configure the domain bits to allow retention when idle. As the TI SoCs have hardware autoidle capabilities, this is safe to do. The domains will only enter retention on WFI when none of the devices on the domain block autoidle in the hardware. This follows what we are already currently doing. Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-02-18soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 ivaTony Lindgren1-1/+5
On reset deassert, we must wait a bit after the rstst bit change before we allow clockdomain autoidle again. Otherwise we get the following oops sometimes on dra7 with iva: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 44000000.ocp:L3 Standard Error: MASTER MPU TARGET IVA_CONFIG (Read Link): At Address: 0x0005A410 : Data Access in User mode during Functional access Internal error: : 1406 [#1] SMP ARM ... (sysc_write_sysconfig) from [<c0782cb0>] (sysc_enable_module+0xcc/0x260) (sysc_enable_module) from [<c0782f0c>] (sysc_runtime_resume+0xc8/0x174) (sysc_runtime_resume) from [<c0a3e1ac>] (genpd_runtime_resume+0x94/0x224) (genpd_runtime_resume) from [<c0a33f0c>] (__rpm_callback+0xd8/0x180) It is unclear what all devices this might affect, but presumably other devices with the rstst bit too can be affected. So let's just enable the delay for all the devices with rstst bit for now. Later on we may want to limit the list to the know affected devices if needed. Fixes: d30cd83f6853 ("soc: ti: omap-prm: add support for denying idle for reset clockdomain") Reported-by: Yongqin Liu <yongqin.liu@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-02-15soc: ti: omap-prm: Fix reboot issue with invalid pcie reset map for dra7Tony Lindgren1-1/+1
Yongqin Liu <yongqin.liu@linaro.org> reported an issue where reboot hangs on beagleboard-x15. This started happening after commit 7078a5ba7a58 ("soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1"). We now assert any 012 type resets on init to prevent unconfigured accelerator MMUs getting enabled on init depending on the bootloader or kexec configured state. Turns out that we now also wrongly assert dra7 l3init domain PCIe reset bits causing a hang during reboot. Let's fix the l3init reset bits to use a 01 map instead of 012 map. There are only two rstctrl bits and not three. This is documented in TRM "Table 3-1647. RM_PCIESS_RSTCTRL". Fixes: 5a68c87afde0 ("soc: ti: omap-prm: dra7: add genpd support for remaining PRM instances") Fixes: 7078a5ba7a58 ("soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1") Cc: Kishon Vijay Abraham I <kishon@ti.com> Reported-by: Yongqin Liu <yongqin.liu@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-01-15Merge branch 'cpuidle-fix' into fixesTony Lindgren1-23/+335
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-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: 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-08-18soc: ti: omap-prm: Configure omap4 and 5 l4_abe power domainTony Lindgren1-0/+22
Let's add omap4 and 5 l4_abe interconnect instance for the power domain. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-08-18soc: ti: omap-prm: Configure sgx power domain for am3 and am4Tony Lindgren1-2/+22
Let's configure only sgx power domain for am3 and am4 to start with. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-08-18soc: ti: omap-prm: Add basic power domain supportTony Lindgren1-1/+227
The PRM controller has currently only support for resets while the power domains are still handled in the platform code. Let's add basic power domain support to enable and disable a PRM controlled power domain if configured in the devicetree. This can be used for various hardware accelerators, and interconnect instances. Further support can be added later on as needed for runtime configuration based on domain-idle-states. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-05-19soc: ti: omap-prm: use atomic iopoll instead of sleeping oneTero Kristo1-4/+4
The reset handling APIs for omap-prm can be invoked PM runtime which runs in atomic context. For this to work properly, switch to atomic iopoll version instead of the current which can sleep. Otherwise, this throws a "BUG: scheduling while atomic" warning. Issue is seen rather easily when CONFIG_PREEMPT is enabled. Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-29soc: ti: omap-prm: fix return value check in omap_prm_probe()Wei Yongjun1-2/+2
In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 3e99cb214f03 ("soc: ti: add initial PRM driver with reset control support") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: omap-prm: add omap5 PRM dataTero Kristo1-0/+9
Add PRM instance data for omap5 family of SoCs. Initially this is just used to provide reset support. Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: omap-prm: add am4 PRM dataTero Kristo1-0/+20
Add PRM instance data for am4 family of SoCs. Initially this is just used to provide reset support. Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: omap-prm: add dra7 PRM dataTero Kristo1-0/+14
Add PRM instance data for dra7 family of SoCs. Initially this is just used to provide reset support. Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: omap-prm: add data for am33xxTero Kristo1-0/+24
Add PRM instance data for AM33xx SoC. Includes some basic register definitions and reset data for now. Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: omap-prm: add omap4 PRM dataTero Kristo1-0/+22
Add PRM data for omap4 family of SoCs. Initially this is just used to provide reset support. Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: omap-prm: add support for denying idle for reset clockdomainTero Kristo1-2/+34
TI SoCs hardware reset signals require the parent clockdomain to be in force wakeup mode while de-asserting the reset, otherwise it may never complete. To support this, add pdata hooks to control the clockdomain directly. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: omap-prm: poll for reset complete during de-assertTero Kristo1-0/+12
Poll for reset completion status during de-assertion of reset, otherwise the IP in question might be accessed before it has left reset properly. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2019-10-09soc: ti: add initial PRM driver with reset control supportTero Kristo1-0/+258
Add initial PRM (Power and Reset Management) driver for TI OMAP class SoCs. Initially this driver only supports reset control, but can be extended to support rest of the functionality, like powerdomain control, PRCM irq support etc. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>