[ Upstream commit effe89e40037038db7711bdab5d3401fe297d72c ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit a249ca66d15fa4b54dc6deaff4155df3db1308e1 ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 17ad4662595ea0c4fd7496b664523ef632e63349 ]

'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>
Signed-off-by: Sasha Levin <sashal@kernel.org>

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>

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
  ...

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
  ...

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>

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>

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>