linux-toradex.git/include/linux/soc/ti, branch v5.19-rc8

ARM: omap1: fix build with no SoC selected

2022-04-22T09:08:55+00:00

In a multiplatform randconfig kernel, one can have
CONFIG_ARCH_OMAP1 enabled, but none of the specific SoCs.
This leads to some build issues as the code is not
meant to deal with this configuration at the moment:

arch/arm/mach-omap1/io.c:86:20: error: unused function 'omap1_map_common_io' [-Werror,-Wunused-function]
arch/arm/mach-omap1/pm.h:113:2: error: "Power management for this processor not implemented yet" [-Werror,-W#warnings]

Use the same trick as on OMAP2 and guard the actual compilation
of platform code with another Makefile ifdef check based
on an option that depends on having at least one SoC enabled.

The io.c file still needs to get compiled to allow building
device drivers with a dependency on CONFIG_ARCH_OMAP1.

Acked-by: Tony Lindgren 
Signed-off-by: Arnd Bergmann

ARM: omap1: move some headers to include/linux/soc

2022-04-21T13:01:02+00:00

There are three remaining header files that are used by omap1
specific device drivers:

- mach/soc.h provides cpu_is_omapXXX abstractions
- mach/hardware.h provides omap_read/omap_write functions
  and physical addresses
- mach/mux.h provides an omap specific pinctrl abstraction

This is generally not how we do platform abstractions today,
and it would be good to completely get rid of these in favor
of passing information through platform devices and the pinctrl
subsystem.

However, given that nobody is working on that, just move it
one step forward by splitting out the header files that are
used by drivers today from the machine headers that are only
used internally.

Acked-by: Tony Lindgren 
Signed-off-by: Arnd Bergmann

ARM: omap1: move mach/usb.h to include/linux/soc

2022-04-21T13:00:59+00:00

The register definitions in this header are used in at least four
different places, with little hope of completely cleaning that up.

Split up the file into a portion that becomes a linux-wide header
under include/linux/soc/ti/, and the parts that are actually only
needed by board files.

Acked-by: Felipe Balbi 
Acked-by: Tony Lindgren 
Signed-off-by: Arnd Bergmann

Merge tag 'mailbox-v5.18' of git://git.linaro.org/landing-teams/working/fujitsu/integration

2022-03-27T21:21:57+00:00

Pull mailbox updates from Jassi Brar:
 "qcom:
   - add support for MSM8976

  mtk:
   - enable mt8186
   - add ADSP controller driver

  ti:
   - use poll mode during suspend

  tegra:
   - fix tx channel flush

  imx:
   - add i.MX8 SECO MU support
   - prepare for, and add iMX93 support"

* tag 'mailbox-v5.18' of git://git.linaro.org/landing-teams/working/fujitsu/integration:
  dt-bindings: mailbox: add definition for mt8186
  mailbox: ti-msgmgr: Operate mailbox in polled mode during system suspend
  mailbox: ti-msgmgr: Refactor message read during interrupt handler
  mailbox: imx: support i.MX93 S401 MU
  mailbox: imx: support dual interrupts
  mailbox: imx: extend irq to an array
  dt-bindings: mailbox: imx-mu: add i.MX93 S4 MU support
  dt-bindings: mailbox: imx-mu: add i.MX93 MU
  mailbox: imx: add i.MX8 SECO MU support
  mailbox: imx: introduce rxdb callback
  dt-bindings: mailbox: imx-mu: add i.MX8 SECO MU support
  mailbox: imx: enlarge timeout while reading/writing messages to SCFW
  mailbox: imx: fix crash in resume on i.mx8ulp
  mailbox: imx: fix wakeup failure from freeze mode
  mailbox: mediatek: add support for adsp mailbox controller
  dt-bindings: mailbox: mtk,adsp-mbox: add mtk adsp-mbox document
  mailbox: qcom-apcs-ipc: Add compatible for MSM8976 SoC
  dt-bindings: mailbox: Add compatible for the MSM8976
  mailbox: tegra-hsp: Flush whole channel

mailbox: ti-msgmgr: Operate mailbox in polled mode during system suspend

2022-03-13T01:33:30+00:00

During the system suspend path we must set all queues to operate in
polled mode as it is possible for any protocol built using this mailbox,
such as TISCI, to require communication during the no irq phase of suspend,
and we cannot rely on interrupts there.

Polled mode is implemented by allowing the mailbox user to define an
RX channel as part of the message that is sent which is what gets polled
for a response. If polled mode is enabled, this will immediately be
polled for a response at the end of the mailbox send_data op before
returning success for the data send or timing out if no response is
received.

Finally, to ensure polled mode is always enabled during system suspend,
iterate through all queues to set RX queues to polled mode during system
suspend and disable polled mode for all in the resume handler.

Signed-off-by: Dave Gerlach 
Signed-off-by: Jassi Brar

firmware: ti_sci: Fix compilation failure when CONFIG_TI_SCI_PROTOCOL is not defined

2022-02-02T19:12:37+00:00

Remove an extra ";" which breaks compilation.

Fixes: 53bf2b0e4e4c ("firmware: ti_sci: Add support for getting resource with subtype")
Signed-off-by: Christophe JAILLET 
Signed-off-by: Nishanth Menon 
Link: https://lore.kernel.org/r/e6c3cb793e1a6a2a0ae2528d5a5650dfe6a4b6ff.1640276505.git.christophe.jaillet@wanadoo.fr

soc: ti: ti_sci_inta_msi: Remove ti_sci_inta_msi_domain_free_irqs()

2021-12-16T21:22:19+00:00

The function has no users and is pointless now that the core frees the MSI
descriptors, which means potential users can just use msi_domain_free_irqs().

Signed-off-by: Thomas Gleixner 
Tested-by: Nishanth Menon 
Reviewed-by: Jason Gunthorpe 
Link: https://lore.kernel.org/r/20211206210748.793119155@linutronix.de

soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()

2021-12-16T21:16:41+00:00

Just use the core function msi_get_virq().

Signed-off-by: Thomas Gleixner 
Tested-by: Nishanth Menon 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Jason Gunthorpe 
Acked-by: Arnd Bergmann 
Acked-by: Vinod Koul 
Acked-by: Nishanth Menon 
Link: https://lore.kernel.org/r/20211210221815.269468319@linutronix.de

soc: ti: k3-ringacc: add AM64 DMA rings support.

2020-12-11T15:50:09+00:00

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 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20201208090440.31792-17-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul

soc: ti: k3-ringacc: Use correct device for allocation in RING mode

2020-11-02T03:38:05+00:00

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 
Reviewed-by: Grygorii Strashko 
Signed-off-by: Santosh Shilimkar