commit 980a637d11fe8dfc734f508a422185c2de55e669 upstream.
While compile-testing randconfig builds for the upcoming boardfile
removal, I noticed that an earlier patch of mine was completely
broken, and the introduction of CONFIG_ARCH_OMAP1_ANY only replaced
one set of build failures with another one, now resulting in
link failures like
ld: drivers/video/fbdev/omap/omapfb_main.o: in function `omapfb_do_probe':
drivers/video/fbdev/omap/omapfb_main.c:1703: undefined reference to `omap_set_dma_priority'
ld: drivers/dma/ti/omap-dma.o: in function `omap_dma_free_chan_resources':
drivers/dma/ti/omap-dma.c:777: undefined reference to `omap_free_dma'
drivers/dma/ti/omap-dma.c:1685: undefined reference to `omap_get_plat_info'
ld: drivers/usb/gadget/udc/omap_udc.o: in function `next_in_dma':
drivers/usb/gadget/udc/omap_udc.c:820: undefined reference to `omap_get_dma_active_status'
I tried reworking it, but the resulting patch ended up much bigger than
simply avoiding the original problem of unused-function warnings like
arch/arm/mach-omap1/mcbsp.c:76:30: error: unused variable 'omap1_mcbsp_ops' [-Werror,-Wunused-variable]
As a result, revert the previous fix, and rearrange the code that
produces warnings to hide them. For mcbsp, the #ifdef check can
simply be removed as the cpu_is_omapxxx() checks already achieve
the same result, while in the io.c the easiest solution appears to
be to merge the common map bits into each soc specific portion.
This gets cleaned in a nicer way after omap7xx support gets dropped,
as the remaining SoCs all have the exact same I/O map.
Fixes: 615dce5bf7 ("ARM: omap1: fix build with no SoC selected")
Cc: stable@vger.kernel.org
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Based on the normalized pattern:
this program is free software you can redistribute it and/or modify it
under the terms of the gnu general public license version 2 as
published by the free software foundation this program is distributed
as is without any warranty of any kind whether express or implied
without even the implied warranty of merchantability or fitness for a
particular purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference.
Reviewed-by: Allison Randal <allison@lohutok.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Based on the normalized pattern:
this program is free software you can redistribute it and/or modify it
under the terms of the gnu general public license as published by the
free software foundation version 2 this program is distributed as is
without any warranty of any kind whether express or implied without
even the implied warranty of merchantability or fitness for a
particular purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference.
Reviewed-by: Allison Randal <allison@lohutok.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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 <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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 <felipe.balbi@linux.intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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
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 <d-gerlach@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.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>
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>
The ringacc driver has been converted to use the new set_cfg function to
configure the ring, the old config ops can be removed.
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>
The sysfw ring configuration message has been extended to include virtid
and asel value for the ring.
Add the ASEL_VALID to TI_SCI_MSG_VALUE_RM_ALL_NO_ORDER as it is required
for DMA rings.
Instead of extending the current .config() ops - which would need same
patch change in the ringacc driver - add ti_sci_msg_rm_ring_cfg struct and
a new ops using it to configure the ring.
This will allow easy update path in case new members are added for the ring
configuration.
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>
Sysfw added 'extended_ch_type' to the tx_ch_cfg_req message which should be
used when BCDMA block copy channels are configured:
extended_ch_type = 0 : the channel is split tx channel (tchan)
extended_ch_type = 1 : the channel is block copy channel (bchan)
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Sysfw added support for a second range in the resource range API to be able
to describe complex allocations mainly for DMA channels.
Update the ti_sci part to consider the second range as well.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Use the ti_sci_resource_desc directly and update it's start and num members
directly instead of requiring individual parameters for them.
This will allow easy extension of the RM parameters without changing API.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The system controller's resource manager have support for configuring the
TDTYPE of TCHAN_CFG register on j721e.
With this parameter the teardown completion can be controlled:
TDTYPE == 0: Return without waiting for peer to complete the teardown
TDTYPE == 1: Wait for peer to complete the teardown
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
With SYSFW ABI 3.0 changes, interrupts coming out of an interrupt
controller is identified by a type and it is consistent across SoCs.
Similarly global events for Interrupt aggregator. So add an API to get
resource range using a resource type.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200806074826.24607-4-lokeshvutla@ti.com
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Drop the repeated word "an" in a comment.
Insert "and" between "source" and "destination" as is done a few
lines earlier.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Add new API k3_ringacc_request_rings_pair() to request pair of rings at
once, as in the most cases Rings are used with DMA channels, which need to
request pair of rings - one to feed DMA with descriptors (TX/RX FDQ) and
one to receive completions (RX/TX CQ). This will allow to simplify Ringacc
API users.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
