| Age | Commit message (Collapse) | Author |
|---|
|
This is the 4.9.166 stable release
|
|
[ Upstream commit 6454368a804c4955ccd116236037536f81e5b1f1 ]
In case of mapping error the DMA addresses are invalid and continuing
will screw system memory or potentially something else.
[ 222.480310] dmatest: dma0chan7-copy0: summary 1 tests, 3 failures 6 iops 349 KB/s (0)
...
[ 240.912725] check: Corrupted low memory at 00000000c7c75ac9 (2940 phys) = 5656000000000000
[ 240.921998] check: Corrupted low memory at 000000005715a1cd (2948 phys) = 279f2aca5595ab2b
[ 240.931280] check: Corrupted low memory at 000000002f4024c0 (2950 phys) = 5e5624f349e793cf
...
Abort any test if mapping failed.
Fixes: 4076e755dbec ("dmatest: convert to dmaengine_unmap_data")
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit dc3f595b6617ebc0307e0ce151e8f2f2b2489b95 ]
atchan->status variable is used to store two different information:
- pass channel interrupts status from interrupt handler to tasklet;
- channel information like whether it is cyclic or paused;
This causes a bug when device_terminate_all() is called,
(AT_XDMAC_CHAN_IS_CYCLIC cleared on atchan->status) and then a late End
of Block interrupt arrives (AT_XDMAC_CIS_BIS), which sets bit 0 of
atchan->status. Bit 0 is also used for AT_XDMAC_CHAN_IS_CYCLIC, so when
a new descriptor for a cyclic transfer is created, the driver reports
the channel as in use:
if (test_and_set_bit(AT_XDMAC_CHAN_IS_CYCLIC, &atchan->status)) {
dev_err(chan2dev(chan), "channel currently used\n");
return NULL;
}
This patch fixes the bug by adding a different struct member to keep
the interrupts status separated from the channel status bits.
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 341198eda723c8c1cddbb006a89ad9e362502ea2 upstream.
Once the "ld_queue" list is not empty, next descriptor will migrate
into "ld_active" list. The "desc" variable will be overwritten
during that transition. And later the dmaengine_desc_get_callback_invoke()
will use it as an argument. As result we invoke wrong callback.
That behaviour was in place since:
commit fcaaba6c7136 ("dmaengine: imx-dma: fix callback path in tasklet").
But after commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job")
things got worse, since possible delay between tasklet_schedule()
from DMA irq handler and actual tasklet function execution got bigger.
And that gave more time for new DMA request to be submitted and
to be put into "ld_queue" list.
It has been noticed that DMA issue is causing problems for "mxc-mmc"
driver. While stressing the system with heavy network traffic and
writing/reading to/from sd card simultaneously the timeout may happen:
10013000.sdhci: mxcmci_watchdog: read time out (status = 0x30004900)
That often lead to file system corruption.
Signed-off-by: Leonid Iziumtsev <leonid.iziumtsev@gmail.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9e528c799d17a4ac37d788c81440b50377dd592d upstream.
There are multiple issues with bcm2835_dma_abort() (which is called on
termination of a transaction):
* The algorithm to abort the transaction first pauses the channel by
clearing the ACTIVE flag in the CS register, then waits for the PAUSED
flag to clear. Page 49 of the spec documents the latter as follows:
"Indicates if the DMA is currently paused and not transferring data.
This will occur if the active bit has been cleared [...]"
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
So the function is entering an infinite loop because it is waiting for
PAUSED to clear which is always set due to the function having cleared
the ACTIVE flag. The only thing that's saving it from itself is the
upper bound of 10000 loop iterations.
The code comment says that the intention is to "wait for any current
AXI transfer to complete", so the author probably wanted to check the
WAITING_FOR_OUTSTANDING_WRITES flag instead. Amend the function
accordingly.
* The CS register is only read at the beginning of the function. It
needs to be read again after pausing the channel and before checking
for outstanding writes, otherwise writes which were issued between
the register read at the beginning of the function and pausing the
channel may not be waited for.
* The function seeks to abort the transfer by writing 0 to the NEXTCONBK
register and setting the ABORT and ACTIVE flags. Thereby, the 0 in
NEXTCONBK is sought to be loaded into the CONBLK_AD register. However
experimentation has shown this approach to not work: The CONBLK_AD
register remains the same as before and the CS register contains
0x00000030 (PAUSED | DREQ_STOPS_DMA). In other words, the control
block is not aborted but merely paused and it will be resumed once the
next DMA transaction is started. That is absolutely not the desired
behavior.
A simpler approach is to set the channel's RESET flag instead. This
reliably zeroes the NEXTCONBK as well as the CS register. It requires
less code and only a single MMIO write. This is also what popular
user space DMA drivers do, e.g.:
https://github.com/metachris/RPIO/blob/master/source/c_pwm/pwm.c
Note that the spec is contradictory whether the NEXTCONBK register
is writeable at all. On the one hand, page 41 claims:
"The value loaded into the NEXTCONBK register can be overwritten so
that the linked list of Control Block data structures can be
dynamically altered. However it is only safe to do this when the DMA
is paused."
On the other hand, page 40 specifies:
"Only three registers in each channel's register set are directly
writeable (CS, CONBLK_AD and DEBUG). The other registers (TI,
SOURCE_AD, DEST_AD, TXFR_LEN, STRIDE & NEXTCONBK), are automatically
loaded from a Control Block data structure held in external memory."
Fixes: 96286b576690 ("dmaengine: Add support for BCM2835")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v3.14+
Cc: Frank Pavlic <f.pavlic@kunbus.de>
Cc: Martin Sperl <kernel@martin.sperl.org>
Cc: Florian Meier <florian.meier@koalo.de>
Cc: Clive Messer <clive.m.messer@gmail.com>
Cc: Matthias Reichl <hias@horus.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Florian Kauer <florian.kauer@koalo.de>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f7da7782aba92593f7b82f03d2409a1c5f4db91b upstream.
If IRQ handlers are threaded (either because CONFIG_PREEMPT_RT_BASE is
enabled or "threadirqs" was passed on the command line) and if system
load is sufficiently high that wakeup latency of IRQ threads degrades,
SPI DMA transactions on the BCM2835 occasionally break like this:
ks8851 spi0.0: SPI transfer timed out
bcm2835-dma 3f007000.dma: DMA transfer could not be terminated
ks8851 spi0.0 eth2: ks8851_rdfifo: spi_sync() failed
The root cause is an assumption made by the DMA driver which is
documented in a code comment in bcm2835_dma_terminate_all():
/*
* Stop DMA activity: we assume the callback will not be called
* after bcm_dma_abort() returns (even if it does, it will see
* c->desc is NULL and exit.)
*/
That assumption falls apart if the IRQ handler bcm2835_dma_callback() is
threaded: A client may terminate a descriptor and issue a new one
before the IRQ handler had a chance to run. In fact the IRQ handler may
miss an *arbitrary* number of descriptors. The result is the following
race condition:
1. A descriptor finishes, its interrupt is deferred to the IRQ thread.
2. A client calls dma_terminate_async() which sets channel->desc = NULL.
3. The client issues a new descriptor. Because channel->desc is NULL,
bcm2835_dma_issue_pending() immediately starts the descriptor.
4. Finally the IRQ thread runs and writes BCM2835_DMA_INT to the CS
register to acknowledge the interrupt. This clears the ACTIVE flag,
so the newly issued descriptor is paused in the middle of the
transaction. Because channel->desc is not NULL, the IRQ thread
finalizes the descriptor and tries to start the next one.
I see two possible solutions: The first is to call synchronize_irq()
in bcm2835_dma_issue_pending() to wait until the IRQ thread has
finished before issuing a new descriptor. The downside of this approach
is unnecessary latency if clients desire rapidly terminating and
re-issuing descriptors and don't have any use for an IRQ callback.
(The SPI TX DMA channel is a case in point.)
A better alternative is to make the IRQ thread recognize that it has
missed descriptors and avoid finalizing the newly issued descriptor.
So first of all, set the ACTIVE flag when acknowledging the interrupt.
This keeps a newly issued descriptor running.
If the descriptor was finished, the channel remains idle despite the
ACTIVE flag being set. However the ACTIVE flag can then no longer be
used to check whether the channel is idle, so instead check whether
the register containing the current control block address is zero
and finalize the current descriptor only if so.
That way, there is no impact on latency and throughput if the client
doesn't care for the interrupt: Only minimal additional overhead is
introduced for non-cyclic descriptors as one further MMIO read is
necessary per interrupt to check for idleness of the channel. Cyclic
descriptors are sped up slightly by removing one MMIO write per
interrupt.
Fixes: 96286b576690 ("dmaengine: Add support for BCM2835")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v3.14+
Cc: Frank Pavlic <f.pavlic@kunbus.de>
Cc: Martin Sperl <kernel@martin.sperl.org>
Cc: Florian Meier <florian.meier@koalo.de>
Cc: Clive Messer <clive.m.messer@gmail.com>
Cc: Matthias Reichl <hias@horus.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Florian Kauer <florian.kauer@koalo.de>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit aeaebcc17cdf37065d2693865eeb1ff1c7dc5bf3 ]
Clang warns:
drivers/dma/xilinx/zynqmp_dma.c:166:4: warning: attribute 'aligned' is
ignored, place it after "struct" to apply attribute to type declaration
[-Wignored-attributes]
}; __aligned(64)
^
./include/linux/compiler_types.h:200:38: note: expanded from macro
'__aligned'
^
1 warning generated.
As Nick pointed out in the previous version of this patch, the author
likely intended for this struct to be 8-byte (64-bit) aligned, not
64-byte, which is the default. Remove the hanging __aligned attribute.
Fixes: b0cc417c1637 ("dmaengine: Add Xilinx zynqmp dma engine driver support")
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 59861547ec9a9736e7882f6fb0c096a720ff811a upstream.
The driver defines three states for a cppi channel.
- idle: .chan_busy == 0 && not in .pending list
- pending: .chan_busy == 0 && in .pending list
- busy: .chan_busy == 1 && not in .pending list
There are cases in which the cppi channel could be in the pending state
when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
is called.
cppi41_stop_chan() has a bug for these cases to set channels to idle state.
It only checks the .chan_busy flag, but not the .pending list, then later
when cppi41_runtime_resume() is called the channels in .pending list will
be transitioned to busy state.
Removing channels from the .pending list solves the problem.
Fixes: 975faaeb9985 ("dma: cppi41: start tear down only if channel is busy")
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Bin Liu <b-liu@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 4.9.144 stable release
|
|
commit 77e75fda94d2ebb86aa9d35fb1860f6395bf95de upstream.
of_dma_controller_free() was not called on module onloading.
This lead to a soft lockup:
watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
Modules linked in: at_hdmac [last unloaded: at_hdmac]
when of_dma_request_slave_channel() tried to call ofdma->of_dma_xlate().
Cc: stable@vger.kernel.org
Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding")
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 98f5f932254b88ce828bc8e4d1642d14e5854caa upstream.
The leak was found when opening/closing a serial port a great number of
time, increasing kmalloc-32 in slabinfo.
Each time the port was opened, dma_request_slave_channel() was called.
Then, in at_dma_xlate(), atslave was allocated with devm_kzalloc() and
never freed. (Well, it was free at module unload, but that's not what we
want).
So, here, kzalloc is more suited for the job since it has to be freed in
atc_free_chan_resources().
Cc: stable@vger.kernel.org
Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding")
Reported-by: Mario Forner <m.forner@be4energy.com>
Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 54f919a04cf221bc1601d1193682d4379dacacbd ]
The driver calls clk_get() with the clock name set to NULL, which means
that the driver could only work when probed from devicetree. From now
on, we explicitly require the driver to be probed from devicetree.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit cfb03be6c7e8a1591285849c361d67b09f5149f7 ]
The following lockdep splat was observed:
[ 1222.241750] ======================================================
[ 1222.271301] WARNING: possible circular locking dependency detected
[ 1222.301060] 4.16.0-10.el8+5.x86_64+debug #1 Not tainted
[ 1222.326659] ------------------------------------------------------
[ 1222.356565] systemd-shutdow/1 is trying to acquire lock:
[ 1222.382660] ((&ioat_chan->timer)){+.-.}, at: [<00000000f71e1a28>] del_timer_sync+0x5/0xf0
[ 1222.422928]
[ 1222.422928] but task is already holding lock:
[ 1222.451743] (&(&ioat_chan->prep_lock)->rlock){+.-.}, at: [<000000008ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma]
:
[ 1223.524987] Chain exists of:
[ 1223.524987] (&ioat_chan->timer) --> &(&ioat_chan->cleanup_lock)->rlock --> &(&ioat_chan->prep_lock)->rlock
[ 1223.524987]
[ 1223.594082] Possible unsafe locking scenario:
[ 1223.594082]
[ 1223.622630] CPU0 CPU1
[ 1223.645080] ---- ----
[ 1223.667404] lock(&(&ioat_chan->prep_lock)->rlock);
[ 1223.691535] lock(&(&ioat_chan->cleanup_lock)->rlock);
[ 1223.728657] lock(&(&ioat_chan->prep_lock)->rlock);
[ 1223.765122] lock((&ioat_chan->timer));
[ 1223.784095]
[ 1223.784095] *** DEADLOCK ***
[ 1223.784095]
[ 1223.813492] 4 locks held by systemd-shutdow/1:
[ 1223.834677] #0: (reboot_mutex){+.+.}, at: [<0000000056d33456>] SYSC_reboot+0x10f/0x300
[ 1223.873310] #1: (&dev->mutex){....}, at: [<00000000258dfdd7>] device_shutdown+0x1c8/0x660
[ 1223.913604] #2: (&dev->mutex){....}, at: [<0000000068331147>] device_shutdown+0x1d6/0x660
[ 1223.954000] #3: (&(&ioat_chan->prep_lock)->rlock){+.-.}, at: [<000000008ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma]
In the ioat_shutdown() function:
spin_lock_bh(&ioat_chan->prep_lock);
set_bit(IOAT_CHAN_DOWN, &ioat_chan->state);
del_timer_sync(&ioat_chan->timer);
spin_unlock_bh(&ioat_chan->prep_lock);
According to the synchronization rule for the del_timer_sync() function,
the caller must not hold locks which would prevent completion of the
timer's handler.
The timer structure has its own lock that manages its synchronization.
Setting the IOAT_CHAN_DOWN bit should prevent other CPUs from
trying to use that device anyway, there is probably no need to call
del_timer_sync() while holding the prep_lock. So the del_timer_sync()
call is now moved outside of the prep_lock critical section to prevent
the circular lock dependency.
Signed-off-by: Waiman Long <longman@redhat.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 4.9.130 stable release
|
|
[ Upstream commit 8bbafed8dd5cfa81071b50ead5cb60367fdef3a9 ]
The mv_xor_v2 driver uses a tasklet, initialized during the probe()
routine. However, it forgets to cleanup the tasklet using
tasklet_kill() function during the remove() routine, which this patch
fixes. This prevents the tasklet from potentially running after the
module has been removed.
Fixes: 19a340b1a820 ("dmaengine: mv_xor_v2: new driver")
Signed-off-by: Hanna Hawa <hannah@marvell.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit e49756544a21f5625b379b3871d27d8500764670 ]
In pl330_update() when checking if a channel has been aborted, the
channel's lock is not taken, only the overall pl330_dmac lock. But in
pl330_terminate_all() the aborted flag (req_running==-1) is set under
the channel lock and not the pl330_dmac lock.
With threaded interrupts, this leads to a potential race:
pl330_terminate_all pl330_update
------------------- ------------
lock channel
entry
lock pl330
_stop channel
unlock pl330
lock pl330
check req_running != -1
req_running = -1
_start channel
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 4.9.127 stable release
Conflicts:
drivers/gpu/drm/imx/imx-ldb.c
drivers/staging/android/ion/ion_priv.h
|
|
[ Upstream commit c4c2b7644cc9a41f17a8cc8904efe3f66ae4c7ed ]
The d->chans[] array has d->dma_requests elements so the > should be
>= here.
Fixes: 8e6152bc660e ("dmaengine: Add hisilicon k3 DMA engine driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit e3f329c600033f011a978a8bc4ddb1e2e94c4f4d ]
The reported residue is already calculated in BURST unit granularity, so
advertise this capability properly to other devices in the system.
Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The swap is swapped between the i.MX8QM RevA and RevB
this patch handle this difference to set swap correctly
otherwise, the eDMA will not work on the i.MX8QM RevB
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
|
|
Add device_synchronize for edma driver, since some driver such as
Audio need it to make sure dma done callback never come out after
resource related with dma channel free-ed by Audio driver. Android
team report such issue on MA-12087.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
|
|
Add device_synchronize for edma driver, since some driver such as
Audio need it to make sure dma done callback never come out after
resource related with dma channel free-ed by Audio driver.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
|
|
Add new cell for sw_done/sw_done_selector, because PDM need enable
software done feature in sdma script.
The new fourth cell defined as below:
Bit31: sw_done
Bit15~bit0: selector
For example: 0x80000000 means sw_done enabled for done0 sector which
is for PDM on i.mx8mm.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
|
|
Avoid touch unused edma channel register in susped/resume, otherwise,
kernel crash if XRDC enabled in scfw.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
|
|
interrupt
In SMP, the current running descriptor maybe freeed during done interrupt
because 'sdmac->vc.lock' will be unlock before driver callback run, thus
'sdmac->desc' maybe NULL and the memory also freeed if channel terminaed
in that time(sdma_terminate_all()), unfortunately, the local 'desc' in
sdma_update_channel_loop() which gets the old value of 'sdmac->desc'
still used to count 'desc->buftail', that cause memory currupt as below.
Check 'sdmac->desc' instead of local 'desc' in the while(), so do nothing
in this corner case. That make sense since this channel was already
terminated and no one care the callback coming after that.
[ 1863.117625] Unable to handle kernel paging request at virtual address bfffa1002
[ 1863.117629] pgd = ffff800008e1e000
[ 1863.117634] [bfffa1002] *pgd=0000000092ae8003, *pud=0000000000000000
[ 1863.117638] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 1863.117646] Modules linked in: ath10k_pci ath10k_core ath
[ 1863.117653] CPU: 0 PID: 23381 Comm: id.printspooler Not tainted 4.9.78 #1
[ 1863.117654] Hardware name: Freescale i.MX8MQ EVK (DT)
[ 1863.117657] task: ffff80005249de80 task.stack: ffff8000506e4000
[ 1863.117670] PC is at sdma_int_handler+0x16c/0x34c
[ 1863.117674] LR is at sdma_int_handler+0x158/0x34c
[ 1863.117677] pc : [<ffff000008549b20>] lr : [<ffff000008549b0c>] pstate: 600001c5
[ 1863.117678] sp : ffff80005ff62eb0
[ 1863.117683] x29: ffff80005ff62eb0 x28: ffff80004e748300
[ 1863.117686] x27: 0000000000000003 x26: 0000000000000001
[ 1863.117690] x25: ffff800056a64018 x24: 0000000000000002
[ 1863.117694] x23: ffff800056a64258 x22: 0000000000000001
[ 1863.117698] x21: 0000000000000000 x20: ffff800056a64258
[ 1863.117701] x19: ffff800056a641b8 x18: 0000000000000008
[ 1863.117705] x17: 0000e2b0dbd9baa4 x16: 0000e2b0dbdd9dd0
[ 1863.117709] x15: 000000000000088e x14: 000000007173d1d8
[ 1863.117713] x13: 0000e2b0b97d1760 x12: 0000e2b0cd0794e0
[ 1863.117716] x11: 0000000000000008 x10: 0000000000000040
[ 1863.117720] x9 : 0000000040000000 x8 : 0012355ad191c9ca
[ 1863.117724] x7 : ffffffffa540c8fe x6 : 0000000000000018
[ 1863.117727] x5 : 000000003b9ac9ff x4 : 0000000000000000
[ 1863.117731] x3 : 0000000ffff80000 x2 : 0000000000000000
[ 1863.117735] x1 : 0000000bfffa0000 x0 : 0000000bfffa1000
[ 1863.117737]
[ 1863.117737] SP: 0xffff80005ff62e30:
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
|
|
When output height is eight, yscale of ps engine will be
over two, it not support by pxp.
According to pxp doc, a factor greater than 2 is not
supported with the bilinear filter. so correct it when
this case happen in order to ensure that pxp will be
not hang up.
Reviewed-by: Robby.cai <robby.cai@nxp.com>
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
|
|
When PxP convert yuyv to nv12 format, some color dots will
introdue to output image. IC recommend that YCBCR_MODE and
BYPASS bit of CSC1_COEF0 should be 1.
Reviewed-by: robby.cai <robby.cai@nxp.com>
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
|
|
Fix below issue reported by Coverity, actually, don't need this
condition check here, remove it.
CID undefined (#1 of 1): Wrong operator used (CONSTANT_EXPRESSION_RESULT)operator_confusion:
(16UL /* 1UL << 4 */) | (__u16)(__le16)tcd->csr is always 1/true regardless of the values of its operand.
This occurs as the logical first operand of "&&".
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
|
|
The type IMX_DMATYPE_MULTI_SAI is used for SAI multi-fifo mode,
in this mode, the fifo num parameter is configured through
dma_slave_config
The watermark definition is:
bit0~7: wartermark level
bit8~11: fifo number
bit16~19: fifo offset
bit27~24: sw done selector
bit23: sw done enabled
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Robin Gong<yibin.gong@nxp.com>
|
|
update sdma script for multi fifo SAI on i.mx8MQ.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
|
|
Add suspend to save channel registers and resume to restore them back since
edmav3 may powered off in suspend.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
|
|
update buswidth that is supported by sdma.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
|
|
The driver already supports DMA_DEV_TO_DEV in sdma_config(),
DMA_SLAVE_BUSWIDTH_2_BYTES and DMA_SLAVE_BUSWIDTH_1_BYTE in
sdma_prep_slave_sg(). So this patch adds them to the lists.
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry-picked from commit f9d4a398f121b00f581da1428bff9b93d955452d)
|
|
On i.mx8 mscale B0 chip, AHB/SDMA clock ratio 2:1 can't be supportted,
since SDMA clock ration has to be increased to 250Mhz, AHB can't reach
to 500Mhz, so use 1:1 instead.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
|
|
enable mxs-dma clock before HW reset and disable clock after it.
BuildInfo:
- SCFW 15d20cde, IMX-MKIMAGE ff9860c5, ATF
- U-Boot 2017.03-00003-gd09f5db
Signed-off-by: Han Xu <han.xu@nxp.com>
|
|
mxs-dma init function will call runtime pm init, the redundant
pm_runtime_force_resume will mess up the counter. Also remove some
unnecessary code.
BuildInfo:
- SCFW 66189d08, IMX-MKIMAGE ea027c4b, ATF
- U-Boot 2017.03-imx_4.9.51_8qm_beta1_8qxp_alpha+g325ac1e
Signed-off-by: Han Xu <han.xu@nxp.com>
Reviewed-by: Frank Li <frank.li@nxp.com>
|
|
enable runtime pm for mxs-dma
BuildInfo:
- SCFW 60e110f9, IMX-MKIMAGE e131af10, ATF
- U-Boot 2017.03-imx_4.9.51_8qm_beta1_8qxp_alpha+gfcc9bdc
Signed-off-by: Han Xu <han.xu@nxp.com>
|
|
There is only one clock need to be handled after the clock code change
for i.MX7D. remove the redundant code.
Signed-off-by: Han Xu <han.xu@nxp.com>
|
|
That's caused by commit 593034f1b908 ("MLK-16437: dma: fsl-edma-v3:
fix kernel crash while edma interrupt trigger after channel disabled").
Because fsl_chan->vchan.lock will be hold always and trigger RCU report
as below:
1571.3 Playing WAVE '/mnt/nfs/vte_mx82/../test_stream/esai_stream/48k16bit-six.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 6
1571.5 [ 4642.698771] INFO: rcu_preempt detected stalls on CPUs/tasks:
1571.6 [ 4642.704443] 0-...: (1 GPs behind) idle=2c5/140000000000000/0 softirq=155373/155374 fqs=2541
1571.7 [ 4642.712967] (detected by 2, t=5252 jiffies, g=104259, c=104258, q=22)
1571.8 [ 4642.719501] Task dump for CPU 0:
1571.9 [ 4642.722724] aplay R running task 0 15723 15721 0x00000202
1571.10 [ 4642.729786] Call trace:
1571.11 [ 4642.732239] [<ffff0000080855e4>] __switch_to+0x8c/0xa0
1571.12 [ 4642.737379] [<ffff0000084e3a48>] dma_chan_put+0x70/0xa0
1571.13 [ 4642.742603] [<ffff0000084e3aac>] dma_release_channel+0x34/0xa0
1571.14 [ 4642.748435] [<ffff000008972240>] fsl_asrc_dma_hw_free+0x38/0x50
1571.15 [ 4642.754358] [<ffff000008960568>] soc_pcm_hw_free+0x110/0x1a8
1571.16 [ 4642.760013] [<ffff000008963bcc>] dpcm_fe_dai_hw_free+0x6c/0xe0
1571.17 [ 4642.765844] [<ffff000008948ae8>] snd_pcm_common_ioctl1+0xb40/0xce0
1571.18 [ 4642.772028] [<ffff000008948e64>] snd_pcm_playback_ioctl1+0x1dc/0x310
1571.19 [ 4642.778378] [<ffff000008948fc0>] snd_pcm_playback_ioctl+0x28/0x40
1571.20 [ 4642.784470] [<ffff0000081ee0a4>] do_vfs_ioctl+0xa4/0x748
1571.21 [ 4642.789784] [<ffff0000081ee7d4>] SyS_ioctl+0x8c/0xa0
1571.22 [ 4642.794745] [<ffff000008082f4c>] __sys_trace_return+0x0/0x4
1571.23 [ 4705.718740] INFO: rcu_preempt detected stalls on CPUs/tasks:
1571.24 [ 4705.724420] 0-...: (1 GPs behind) idle=2c5/140000000000000/0 softirq=155373/155374 fqs=10407
1571.25 [ 4705.733030] (detected by 1, t=21010 jiffies, g=104259, c=104258, q=119)
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reported-by: Jason Liu <jason.hui.liu@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Fixes: 593034f1b908 ("MLK-16437: dma: fsl-edma-v3: fix kernel crash
while edma interrupt trigger after channel disabled").
|
|
after channel disabled
edma interrupt may come after channel terminated, so should ignore
interrupts, else kernel crash as below since fsl_chan->edesc set
to NULL when terminate.
606.837306] Unable to handle kernel NULL pointer dereference at virtual address 00000060
[ 606.845411] pgd = ffff000009295000
[ 606.848814] [00000060] *pgd=00000008bfffe003[ 606.852906] , *pud=00000008bfffd003
, *pmd=0000000000000000[ 606.858395]
[ 606.859885] Internal error: Oops: 96000006 1 PREEMPT SMP
[ 606.865460] Modules linked in:
[ 606.868522] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.11-03371-g9904ea0 #42
[ 606.875832] Hardware name: Freescale i.MX8QXP LPDDR4 ARM2 (DT)
[ 606.881662] task: ffff000009120680 task.stack: ffff000009110000
[ 606.887588] PC is at fsl_edma3_tx_handler+0x50/0x150
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Tested-by: Daniel Baluta <daniel.baluta@nxp.com>
|
|
Enable PS and AS colorkey function if user enable and
set colorkey parameters of s0 and overlay buffer.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit f2ed3bfca174b3e370fc37cd5f75a67334822093)
|
|
In pxp lib, the unit of stride parameter is pixel and stride
is not equal with width parameter of out buffer in some cases.
In order to use latest pxp lib in old version rootfs, PXP_DEVICE_LEGACY
macro is used to distinguish pxp drvier version. Because the
new pxp driver define a new variable and pxp lib can know this
through PXP_DEVICE_LEGACY, and determine if use it.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Fancy Fang <chen.fang@nxp.com>
(cherry picked from commit 91da74e81cfdd2774b39a7574edf93de3f2a3f25)
|
|
1) add PXP_PIX_FMT_BGRA32 format support for AS buffer
2) add PXP_PIX_FMT_BGRA32 format support for OUT buffer
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Fancy Fang <chen.fang@nxp.com>
(cherry picked from commit 4eeefd54cdbb8d1d3ffd64bd444ea7b759101a35)
|
|
In support of both g2d and pxp lib alpha blending, there
must be two alpha blending versions. So there is one rule
that user should obey for different usage cases.
1) g2d alpha blending: user should set combine_enable
member of struct pxp_proc_data.
2) pxp lib alpha blending: user should set combine_enable
member of struct pxp_layer_param if the pxp_layer_param
describe overlay buffer parameters.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Reviewed-by: Fancy Fang <chen.fang@nxp.com>
(cherry picked from commit 7c62393a556d043f88dd188edac3c0d250039358)
|
|
Since there are multi edmav3 instances on i.mx8, every edma channel name
is better unique.But so far, all edma channel name is 'edma-channel(id)-
tx',thus some edma channels which share the same channel id but different
edma instance will show the same channel name in kernel and this is not
friendly to debug in kernel.
Now the edma channel name(interrupt-names property) is define in dts
as below:
"edmaX-chanX-Xx"
| | |---> receive/transmit, r or t
| |---> channel id, the max number is 32
|---> edma controller instance, 0, 1, 2,..etc
and get below correct name with 'cat /proc/interrupts':
43: 0 0 0 0 GICv3 466 Level edma0-chan8-rx
44: 0 0 0 0 GICv3 467 Level edma0-chan9-tx
45: 79 0 0 0 GICv3 468 Level edma0-chan10-rx
46: 311 0 0 0 GICv3 469 Level edma0-chan11-tx
47: 0 0 0 0 GICv3 470 Level edma0-chan12-rx
48: 0 0 0 0 GICv3 471 Level edma0-chan13-tx
49: 0 0 0 0 GICv3 472 Level edma0-chan14-rx
50: 0 0 0 0 GICv3 473 Level edma0-chan15-tx
51: 0 0 0 0 GICv3 406 Level edma2-chan0-tx
52: 0 0 0 0 GICv3 407 Level edma2-chan1-tx
53: 0 0 0 0 GICv3 408 Level edma2-chan2-tx
54: 0 0 0 0 GICv3 409 Level edma2-chan3-tx
55: 0 0 0 0 GICv3 410 Level edma2-chan4-tx
56: 0 0 0 0 GICv3 411 Level edma2-chan5-tx
57: 0 0 0 0 GICv3 442 Level edma2-chan6-rx, edma2-chan7-tx
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
|
|
There was no pxp background register setting, so the
background we see always black.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
(cherry picked from commit d3ee45e2671478854a165f34f91fabac247e8a39)
|
|
PxP PS engine support YUV420 format, but not YVU420. The difference
between two format is U and V, if we exchange U and V base address,
the PxP driver can also support YVU420 format.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Fancy Fang <chen.fang@nxp.com>
(cherry picked from commit cbc71da10afe67ae815a97a68e4a1b0dff4693eb)
|
|
g2d code has different parameter setting about stride parameter.
For compatibility with all cases of using PxP, we need add this
improved feature.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Reviewed-by: Fancy Fang <chen.fang@nxp.com>
(cherry picked from commit 53c8ffffec181a765f4487a9d1bf2eb05b1b78f7)
|
|
If pxp use crop x/y valuse as the upper left coordinate in
out buffer, pxp driver only need to write out buffer base
address to pxp out_buf register. If pxp driver use zero as
ps_ulc register value, pxp out_buf register need an offset
added with out buffer base address.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Reviewed-by: Fancy Fang <chen.fang@nxp.com>
(cherry picked from commit 14c988f1eb7e9471b0875016df29708865727fbb)
|
|
Because of IC limitation, pxp only can use rotation0 engine to
do rotation operation.
Correct coordinate settings of ps and out buffer.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Reviewed-by: Fancy Fang <chen.fang@nxp.com>
|
