87c7bf7 ("iommu: Remove struct iommu_ops *iommu from
arch_setup_dma_ops()")
Signed-off-by: Robin Murphy
---
drivers/media/platform/ti/omap3isp/isp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/ti/omap3isp/isp.c
b/drivers/media/platform/ti/omap3isp
preferred.
Thanks,
Robin.
[1]
https://lore.kernel.org/linux-iommu/c44545c6d07c65d89daa297298c27bb0f15c8b84.1728393458.git.robin.mur...@arm.com/
Robin Murphy (4):
remoteproc/omap: Handle ARM dma_iommu_mapping
media: omap3isp: Handle ARM dma_iommu_mapping
iommu/omap: Add minimal fwnode suppo
With the last external caller of bus_iommu_probe() now gone, make it
internal as it really should be.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 3 ++-
include/linux/iommu.h | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu
rnel.org/linux-iommu/0dbde87b-593f-4b14-8929-b78e18954...@ti.com/
Reported-by: H. Nikolaus Schaller
Link:
https://lore.kernel.org/linux-media/a7c284a9-33a5-4e21-9b57-9c4c213cc...@goldelico.com/
Fixes: 17de3f5fdd35 ("iommu: Retire bus ops")
Signed-off-by: Robin Murphy
---
d
87c7bf7 ("iommu: Remove struct iommu_ops *iommu from
arch_setup_dma_ops()")
Signed-off-by: Robin Murphy
---
drivers/remoteproc/omap_remoteproc.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remote
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Robin Murphy
---
Hi Rob, Frank,
Bit of an old one bit it's rebased cleanly - Mauro reckoned[1] this
would suit the OF tree better than media, are you happy to pick it up?
Thanks,
Robin.
[1] https://patchwork.kernel.org/patch/10598085/
dr
knows as actual system/device memory" to better explain the WARN...
Either way, though,
Reviewed-by: Robin Murphy
- BUG_ON(pfn_valid(PHYS_PFN(phys_addr)));
+ if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
+ return DMA_MAPPING_ERROR;
if (dma_is_direct(ops))
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation i
On 08/12/2018 17:36, Christoph Hellwig wrote:
There is no need to have an additional kernel mapping for a contiguous
allocation if the device already is DMA coherent, so skip it.
FWIW, the "need" was that it kept the code in this path simple and the
mapping behaviour consistent with the regula
On 2018-12-07 7:28 pm, Souptick Joarder wrote:
On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox wrote:
On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long
On 06/12/2018 18:39, Souptick Joarder wrote:
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new functi
, while at best it's an example of incorrect
DMA API usage which has proven to mislead readers.
Signed-off-by: Robin Murphy
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
b/drivers/
Hi Marek,
On 20/02/18 09:36, Marek Szyprowski wrote:
Hi Robin,
On 2018-02-19 17:29, Robin Murphy wrote:
Hi Maciej,
On 19/02/18 15:43, Maciej Purski wrote:
When a driver is going to use clk_bulk_get() function, it has to
initialize an array of clk_bulk_data, by filling its id fields.
Add a
Hi Maciej,
On 19/02/18 15:43, Maciej Purski wrote:
When a driver is going to use clk_bulk_get() function, it has to
initialize an array of clk_bulk_data, by filling its id fields.
Add a new function to the core, which dynamically allocates
clk_bulk_data array and fills its id fields. Add clk_bu
On 06/02/18 13:14, Hans Verkuil wrote:
[...]
The one thing that I worry about is if these structs are the same for
32 and 64 bit arm.
I see some enums and bools in there - in general the storage size of
those isn't even guaranteed to be consistent between different compiler
implementations on
On 31/01/18 09:37, Arnd Bergmann wrote:
On Wed, Jan 31, 2018 at 8:29 AM, Maxime Ripard
wrote:
Hi Thierry,
On Tue, Jan 30, 2018 at 11:01:50AM +0100, Thierry Reding wrote:
On Tue, Jan 30, 2018 at 10:59:16AM +0100, Thierry Reding wrote:
On Tue, Jan 30, 2018 at 10:24:48AM +0100, Arnd Bergmann wr
On 08/09/17 07:02, Hoegeun Kwon wrote:
> The gscaler has hardware rotation limits that need to be hardcoded
> into driver. Distinguish them and add them to the property list.
>
> The hardware rotation limits are related to the cropped source size.
> When swap occurs, use rot_max size instead of cr
On 08/09/17 07:02, Hoegeun Kwon wrote:
> Exynos 5250 and 5420 have different hardware rotation limits. However,
> currently it uses only one compatible - "exynos5-gsc". Since we have
> to distinguish between these two, we add different compatible.
>
> Signed-off-by: Hoegeun Kwon
> ---
> arch/arm
On 26/07/17 11:38, Tomasz Figa wrote:
> Hi Robin,
>
> On Wed, Jul 19, 2017 at 10:37 PM, Robin Murphy wrote:
>> On 19/07/17 04:12, Yong Zhi wrote:
>>> From: Tomasz Figa
>>>
>>> This driver translates Intel IPU3 internal virtual
>>> address to p
On 20/07/17 22:49, Sakari Ailus wrote:
> Hi Robin,
>
> On Wed, Jul 19, 2017 at 02:37:12PM +0100, Robin Murphy wrote:
> ...
>>> +static int ipu3_mmu_map(struct iommu_domain *domain, unsigned long iova,
>>> + phys_addr_t paddr, size_t size, i
On 19/07/17 04:12, Yong Zhi wrote:
> From: Tomasz Figa
>
> This patch adds support for the IPU3 DMA mapping API.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Yong Zhi
> ---
> drivers/media/pci/intel/ipu3/Kconfig | 8 +
> drivers/media/pci/intel/ipu3/Makefile | 2 +-
> driver
On 19/07/17 04:12, Yong Zhi wrote:
> From: Tomasz Figa
>
> This driver translates Intel IPU3 internal virtual
> address to physical address.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Yong Zhi
> ---
> drivers/media/pci/intel/ipu3/Kconfig| 9 +
> drivers/media/pci/intel/ipu3/Makefil
On 09/06/17 07:20, Tomasz Figa wrote:
> On Fri, Jun 9, 2017 at 3:07 AM, Robin Murphy wrote:
>> On 08/06/17 15:35, Tomasz Figa wrote:
>>> On Thu, Jun 8, 2017 at 10:22 PM, Robin Murphy wrote:
>>>> On 07/06/17 10:47, Tomasz Figa wrote:
>>>>>
On 08/06/17 15:35, Tomasz Figa wrote:
> On Thu, Jun 8, 2017 at 10:22 PM, Robin Murphy wrote:
>> On 07/06/17 10:47, Tomasz Figa wrote:
>>> Hi Yong,
>>>
>>> +Robin, Joerg, IOMMU ML
>>>
>>> Please see my comments inline.
>>&g
On 07/06/17 10:47, Tomasz Figa wrote:
> Hi Yong,
>
> +Robin, Joerg, IOMMU ML
>
> Please see my comments inline.
>
> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote:
>> IPU3 mmu based DMA mapping driver
>>
>> Signed-off-by: Yong Zhi
>> ---
>> drivers/media/pci/intel/ipu3/Kconfig | 6 +
>
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 Laurent,
On 09/11/15 14:18, Laurent Pinchart wrote:
Hello everybody,
Ping ?
Apologies, I did start writing a response a while ago, but it ended up
getting subsumed into the bigger DMA API discussion thread.
On Tuesday 13 October 2015 16:18:36 Laurent Pinchart wrote:
The maximum DMA se
On 04/11/15 05:12, Tomasz Figa wrote:
On Wed, Nov 4, 2015 at 2:41 AM, Robin Murphy wrote:
Hi Tomasz,
On 02/11/15 13:43, Tomasz Figa wrote:
I'd like to know what is the boundary mask and what hardware imposes
requirements like this. The cost here is not only over-allocating a
little
Hi Tomasz,
On 02/11/15 13:43, Tomasz Figa wrote:
I'd like to know what is the boundary mask and what hardware imposes
requirements like this. The cost here is not only over-allocating a
little, but making many, many buffers contiguously mappable on the
CPU, unmappable contiguously in IOMMU, whic
Hi Dan,
On 30/10/15 01:17, Daniel Kurtz wrote:
+linux-media & VIDEOBUF2 FRAMEWORK maintainers since this is about the
v4l2-contig's usage of the DMA API.
Hi Robin,
On Tue, Oct 27, 2015 at 12:55 AM, Robin Murphy wrote:
On 26/10/15 13:44, Yong Wu wrote:
On Thu, 2015-10-01 at 20
Hi Hans,
On 21/09/15 14:13, Hans Verkuil wrote:
Hi Tiffany!
On 21-09-15 14:26, Tiffany Lin wrote:
vb2_dc_prepare use the number of SG entries dma_map_sg_attrs return.
But in dma_sync_sg_for_device, it use lengths of each SG entries
before dma_map_sg_attrs. dma_map_sg_attrs will concatenate
SGs
Hi Sumit,
On 21/01/15 04:16, Sumit Semwal wrote:
From: Rob Clark
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices shari
32 matches
Mail list logo
