If the DMA device supports per channel coherency configuration (a channel
can be configured to have coherent or not coherent view) then a single
device (the DMA controller's device) can not be used for dma_api for all
channels as channels can have different coherency.
Introduce custom_dma_mapping flag for the dma_chan and a new helper to get
the device pointer to be used for dma_api for the given channel.
Client drivers should be updated to be able to support per channel
coherency by:
- dma_map_single(chan->device->dev, ptr, size, DMA_TO_DEVICE);
+ struct device *dma_dev = dmaengine_get_dma_device(chan);
+
+ dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE);
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-9-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Additional configuration for the DMA event router might be needed for a
channel which can not be done during device_alloc_chan_resources callback
since the router information is not yet present for the drivers.
If there is a need for additional configuration for the channel if DMA
router is in use, then the driver can implement the device_router_config
callback.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-8-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Rings in RING mode should be using the DMA device for DMA API as in this
mode the ringacc will not access the ring memory in any ways, but the DMA
is.
Fix up the ring configuration and set the dma_dev unconditionally and let
the ringacc driver to select the correct device to use for DMA API.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20201208090440.31792-7-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
To better understand error that can be detected by the DMA controller,
manage the error flags before the transfer flags.
This way, it is possible to know if the FIFO error flag is set for an
over/underrun condition or a FIFO level error.
When a FIFO over/underrun condition occurs, the data is not lost because
peripheral request is not acknowledged by the stream until the over/
underrun condition is cleared. If this acknowledge takes too much time,
the peripheral itself may detect an over/underrun condition of its internal
buffer and data might be lost.
That's why in case the FIFO error flag is set, we check if the channel is
disabled or not, and if a Transfer Complete flag is set, which means that
the channel is disabled because of the end of transfer.
Because channel is disabled by hardware either by a FIFO level error, or by
an end of transfer.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Link: https://lore.kernel.org/r/20201120143320.30367-2-amelie.delaunay@st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit b722d7b9e4da ("hwmon: (pmbus) Driver for Delta power supplies
Q54SJ108A2") provides new documentation for DELTA Q54SJ108A2NC* drivers,
but the title underline was too short.
make htmldocs warns:
Documentation/hwmon/q54sj108a2.rst:4: WARNING: Title underline too short.
Adjust the title underline to the correct length.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20201207152658.32444-1-lukas.bulwahn@gmail.com
[groeck: Adjust subject]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
LTC2992 has 4 open-drain GPIOS. This patch exports to user
space the 4 GPIOs using the GPIO driver Linux API.
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
LTC2992 is a rail-to-rail system monitor that
measures current, voltage, and power of two supplies.
Two ADCs simultaneously measure each supply’s current.
A third ADC monitors the input voltages and four
auxiliary external voltages.
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Johan writes:
USB-serial updates for 5.11-rc1
Here are the USB-serial updates for 5.11-rc1, including:
- keyspan_pda write-implementation fixes
- digi_acceleport write-wakeup fix
- mos7720 parport-restore fix
- mos7720 parport-tasklet removal
- cp210x termios-handling cleanups
- option device-flag fix
- ftdi_sio GPIO CBUS-configuration improvements
- removal of in_interrupt() uses
Included are also various clean ups.
All have been in linux-next with no reported issues.
* tag 'usb-serial-5.11-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (30 commits)
USB: serial: ftdi_sio: log the CBUS GPIO validity
USB: serial: ftdi_sio: drop GPIO line checking dead code
USB: serial: ftdi_sio: report the valid GPIO lines to gpiolib
USB: serial: option: add interface-number sanity check to flag handling
USB: serial: cp210x: clean up dtr_rts()
USB: serial: cp210x: refactor flow-control handling
USB: serial: cp210x: drop flow-control debugging
USB: serial: cp210x: set terminal settings on open
USB: serial: cp210x: clean up line-control handling
USB: serial: cp210x: return early on unchanged termios
USB: serial: mos7720: defer state restore to a workqueue
USB: serial: mos7720: fix parallel-port state restore
USB: serial: remove write wait queue
USB: serial: digi_acceleport: fix write-wakeup deadlocks
USB: serial: keyspan_pda: drop redundant usb-serial pointer
USB: serial: keyspan_pda: use BIT() macro
USB: serial: keyspan_pda: clean up comments and whitespace
USB: serial: keyspan_pda: clean up xircom/entrega support
USB: serial: keyspan_pda: add write-fifo support
USB: serial: keyspan_pda: increase transmitter threshold
...
Drivers for multi-queue platform devices may also want managed interrupts
for handling HW queue completion interrupts, so add support.
The function accepts an affinity descriptor pointer, which covers all IRQs
expected for the device.
The function is devm class as the only current in-tree user will also use
devm method for requesting the interrupts; as such, the function is made
as devm as it can ensure ordering of freeing the irq and disposing of the
mapping.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1606905417-183214-5-git-send-email-john.garry@huawei.com
Add a function to allow the affinity of an interrupt be switched to
managed, such that interrupts allocated for platform devices may be
managed.
This new interface has certain limitations, and attempts to use it in the
following circumstances will fail:
- For when the kernel is configured for generic IRQ reservation mode (in
config GENERIC_IRQ_RESERVATION_MODE). The reason being that it could
conflict with managed vs. non-managed interrupt accounting.
- The interrupt is already started, which should not be the case during
init
- The interrupt is already configured as managed, which means double init
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1606905417-183214-2-git-send-email-john.garry@huawei.com
We have two flavours of platform-MSI:
- MSIs generated by devices for themselves (the usual case)
- MSIs generated on behalf of other devices, as the generating
device is some form of bridge (either a wire-to-MSI bridge,
or even a non-transparent PCI bridge that repaints the PCI
requester ID).
In the latter case, the underlying interrupt architecture may need
to track this in order to keep the mapping alive even when no MSI
are currently being generated.
Add a set of flags to the generic msi_alloc_info_t structure, as
well as the MSI_ALLOC_FLAGS_PROXY_DEVICE flag that will get
advertized by the platform-MSI code when allocating an irqdomain
for a device.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/20201129135208.680293-2-maz@kernel.org
ti_sci_intr_irq_domain_free() assumes that out_irq of intr is stored in
data->chip_data and uses it for calling ti_sci irq_free() and then
mark the out_irq as available resource. But ti_sci_intr_irq_domain_alloc()
is storing p_hwirq(parent's hardware irq) which is translated from out_irq.
This is causing resource leakage and eventually out_irq resources might
be exhausted. Fix ti_sci_intr_irq_domain_alloc() by storing the out_irq
in data->chip_data.
Fixes: a5b659bd4b ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201102120631.11165-1-lokeshvutla@ti.com
On a successful probe, the driver tries to print a success message with
INTA device id. It uses pdev->id for printing the id but id is stored in
inta->ti_sci_id. Fix it by correcting the dev_info parameter.
Fixes: 5c4b585d29 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201102120614.11109-1-lokeshvutla@ti.com
