On 2021-04-27 11:27, Mauro Carvalho Chehab wrote:
Despite other *_get()/*_put() functions, where usage count is
incremented only if not errors, the pm_runtime_get_sync() has
a different behavior, incrementing the counter *even* on
errors.
That's an error prone behavior, as people often forget to
On 2020-11-04 08:14, Maxime Ripard wrote:
Hi Christoph,
On Tue, Nov 03, 2020 at 10:55:38AM +0100, Christoph Hellwig wrote:
Linux 5.10-rc1 switched from having a single dma offset in struct device
to a set of DMA ranges, and introduced a new helper to set them,
dma_direct_set_offset.
This in fa
On 2020-10-14 17:27, Helen Koike wrote:
Hi Tomasz,
On 9/26/20 10:00 AM, Tomasz Figa wrote:
Hi Helen,
On Wed, Jul 22, 2020 at 12:55:32PM -0300, Helen Koike wrote:
From: Shunqian Zheng
RK3399 has two ISPs, but only isp0 was tested.
Add isp0 node in rk3399 dtsi
Verified with:
make ARCH=arm64
On 2020-08-19 11:28, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:02:54 -0700
John Stultz escreveu:
On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:47:55 +0100
Basically, the DT binding has this, for IOMMU
On 2020-08-18 23:02, John Stultz wrote:
On Tue, Aug 18, 2020 at 9:26 AM Robin Murphy wrote:
On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
Em Tue, 18 Aug 2020 15:47:55 +0100
Basically, the DT binding has this, for IOMMU:
smmu_lpae {
compatible = "hisilicon,smmu
On 2020-08-18 16:29, Mauro Carvalho Chehab wrote:
Hi Robin,
Em Tue, 18 Aug 2020 15:47:55 +0100
Robin Murphy escreveu:
On 2020-08-17 08:49, Mauro Carvalho Chehab wrote:
Add a driver for the Kirin 960/970 iommu.
As on the past series, this starts from the original 4.9 driver from
the
On 2020-08-17 08:49, Mauro Carvalho Chehab wrote:
Add a driver for the Kirin 960/970 iommu.
As on the past series, this starts from the original 4.9 driver from
the 96boards tree:
https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
The remaining patches add SPDX headers and make
Hi Jim,
Thanks for taking this on!
On 2020-06-16 21:55, Jim Quinlan wrote:
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
This
On 24/07/2019 15:09, Dmitry Osipenko wrote:
24.07.2019 17:03, Yuehaibing пишет:
On 2019/7/24 21:49, Robin Murphy wrote:
On 24/07/2019 11:30, Sakari Ailus wrote:
Hi Yue,
On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA
On 24/07/2019 11:30, Sakari Ailus wrote:
Hi Yue,
On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
in the Kconfig, for example, CONFIG_TEGRA_VDE is
On 14/06/2019 15:50, 'Christoph Hellwig' wrote:
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
Does this still guarantee that requests for 16k will not cross a 16k boundary?
It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to
Hi Roy,
On 26/03/18 20:05, Roy Pledge wrote:
The error path in the dpaa2_dpio_probe() function was not properly
unmapping the QBMan device memory on the error path. This was also
missing from the dpaa2_dpio_release() function.
Also addresses a memory leak of the device private data structure.
On 17/07/17 14:26, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> Split the 64-bit accesses in 32-bit accesses because there's no real
> constrain in MC to do only atomic 64-bit. There's only one place
> where ordering is important: when writing the MC command header the
> first 32-bi
On 17/07/17 14:26, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> No need to use arch-specific memory barriers; switch to using generic
> ones. The rmb()s were useless so drop them.
>
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/staging/fsl-mc/bus/mc-sys.c | 6 ++
> 1 file
On 10/03/17 10:31, Brian Starkey wrote:
> Hi,
>
> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>
> [snip]
>
>>>
>>> For me those patches are going in the right direction.
>>>
>>> I still have few questions:
>>> - since alignmen
Hi Michael,
On 31/10/16 19:53, Michael Zoran wrote:
> On Mon, 2016-10-31 at 11:40 -0700, Michael Zoran wrote:
>> On Mon, 2016-10-31 at 11:36 -0700, Eric Anholt wrote:
>>> Michael Zoran writes:
>>>
Setting the DMA mask is optional on 32 bit but
is mandatory on 64 bit. Set the DMA mask a
On 03/02/16 06:49, Gujulan Elango, Hari Prasath (H.) wrote:
From: Hari Prasath Gujulan Elango
Use the managed version of the dma_alloc_coherent() i.e. the
dmam_alloc_coherent() & accordingly cleanup the error handling
part.Also,remove the references to dma_free_coherent
That last aspect looks
Hi Laura,
On 17/07/15 17:50, Laura Abbott wrote:
On 07/17/2015 08:21 AM, Robin Murphy wrote:
Hi Tixy,
On 17/07/15 12:01, Jon Medhurst (Tixy) wrote:
Use dma_get_sgtable rather than dma_common_get_sgtable so a device's
dma_ops aren't bypassed. This is essential in situations wher
at least this patch
definitely makes things less wrong in that respect.
Reviewed-by: Robin Murphy
---
This also begs the question as to what happens if the memory region _is_
contiguous but is in highmem or an ioremapped region. Should a device
always provide dma_ops for that case? Because I
19 matches
Mail list logo
