On 02/07/2022 23:37, Sam Protsenko wrote:
> SysMMU v7 might have different register layouts (VM capable or non-VM
> capable). Check which layout is implemented in current SysMMU module and
> prepare the corresponding register table for futher usage. This way is
> faster and more elegant than
On 02/07/2022 23:37, Sam Protsenko wrote:
> SysMMU v7 can have Virtual Machine registers, which implement multiple
> translation domains. The driver should know if it's true or not, as VM
> registers shouldn't be accessed if not present. Read corresponding
> capabilities register to obtain that
On 02/07/2022 23:37, Sam Protsenko wrote:
> SysMMU v5+ supports 36 bit physical address space. Set corresponding DMA
> mask to avoid falling back to SWTLBIO usage in dma_map_single() because
> of failed dma_capable() check.
>
> The original code for this fix was suggested by Marek.
>
>
On Sat 2022-06-11 21:48 +0100, Aaron Tomlin wrote:
> This patch will attempt to describe the region type in the event
> that a given RMRR entry is not within a reserved region.
Any thoughts?
Kind regards,
--
Aaron Tomlin
___
iommu mailing list
On 01.07.22 23:00, Samuel Holland wrote:
Hello Samuel
Some architectures and irqchip drivers modify the cpumask returned by
irq_data_get_affinity_mask, usually by copying in to it. This is
problematic for uniprocessor configurations, where the affinity mask
should be constant, as it is
On Fri, Jul 1, 2022 at 10:01 PM Samuel Holland wrote:
>
> Now that the irq_data_update_affinity helper exists, enforce its use
> by returning a a const cpumask from irq_data_get_affinity_mask.
>
> Since the previous commit already updated places that needed to call
> irq_data_update_affinity,
From: Samuel Holland Sent: Friday, July 1, 2022 1:01 PM
>
> Now that the irq_data_update_affinity helper exists, enforce its use
> by returning a a const cpumask from irq_data_get_affinity_mask.
Nit: duplicate word "a"
>
> Since the previous commit already updated places that needed to call
>
On Sun, 2022-07-03 at 00:48 +0300, Sam Protsenko wrote:
[...]
> Hi Marek,
>
> As I understand, you have some board with SysMMU v7, which is not VM
> capable (judging from the patches you shared earlier). Could you
> please somehow verify if this series works fine for you? For example,
> this
kmalloc will round up the request size to power of 2, and current
iova_magazine's size is 1032 (1024+8) bytes, so each instance
allocated will get 2048 bytes from kmalloc, causing around 1KB
waste.
Change IOVA_MAG_SIZE from 128 to 127 to make size of 'iova_magazine'
1024 bytes so that no memory
