On Tue, 6 Oct 2020, Christoph Hellwig wrote:
> On Fri, Oct 02, 2020 at 01:21:25PM -0700, Stefano Stabellini wrote:
> > On Fri, 2 Oct 2020, Christoph Hellwig wrote:
> > > Hi Stefano,
> > >
> > > I've looked over xen-swiotlb in linux-next, that is with your recent
> > > changes to take dma offsets
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
>
> When interrupt remapping isn't enabled, only the first 255 CPUs can
No, only CPUs with an APICid < 255
> receive external interrupts. Set the appropriate max affinity for
> the IOAPIC and MSI IRQ domains
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
>
> This is the mask of CPUs to which IRQs can be delivered without interrupt
> remapping.
>
> +/* Mask of CPUs which can be targeted by non-remapped interrupts. */
> +cpumask_t x86_non_ir_cpumask = { CPU_BITS_ALL };
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> +/**
> + * irq_domain_set_affinity - Set maximum CPU affinity for domain
> + * @parent: Domain to set affinity for
> + * @affinity:Pointer to cpumask, consumed by domain
> + *
> + * Sets the maximal set of CPUs to which interrupts in
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
>
> This is the maximum possible set of CPUs which can be used. Use it
> to calculate the default affinity requested from __irq_alloc_descs()
> by first attempting to find the intersection with irq_default_affinity,
> or
On 6 October 2020 22:01:18 BST, Thomas Gleixner wrote:
>On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
>>
>> #else /* CONFIG_SMP */
>>
>> +#define irq_default_affinity (NULL)
>
>...
>
>> static int alloc_descs(unsigned int start, unsigned int cnt, int
>node,
>>
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
> It already takes an array of affinities for each individual irq being
> allocated but that's awkward to allocate and populate in the case
> where they're all the same and inherited from the irqdomain, so pass
> the
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
>
> #else /* CONFIG_SMP */
>
> +#define irq_default_affinity (NULL)
...
> static int alloc_descs(unsigned int start, unsigned int cnt, int node,
> const struct irq_affinity_desc *affinity,
> +
On Mon, Oct 5, 2020 at 10:26 AM Christoph Hellwig wrote:
>
> On Fri, Oct 02, 2020 at 05:50:40PM +, Tomasz Figa wrote:
> > Hi Christoph,
> >
> > On Wed, Sep 30, 2020 at 06:09:17PM +0200, Christoph Hellwig wrote:
> > > Add a new API that returns a virtually non-contigous array of pages
> > >
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> -static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg)
> +static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg,
> int dmar)
bool dmar?
> +/*
> + * The Intel IOMMU (ab)uses the high bits of the MSI
Hi,
> Am 15.07.2020 um 09:06 schrieb Tomasz Nowicki :
>
> The series is meant to support SMMU for AP806 and a workaround
> for accessing ARM SMMU 64bit registers is the gist of it.
>
> For the record, AP-806 can't access SMMU registers with 64bit width.
> This patches split the readq/writeq
Hi all,
On 10/5/20 3:08 PM, Christoph Hellwig wrote:
> On Mon, Oct 05, 2020 at 11:44:10AM +0100, Lorenzo Pieralisi wrote:
>>> I see that there are both OF and ACPI hooks in pci_dma_configure() and
>>> both modify dev->dma_mask, which is what pci-sysfs is exposing here,
>>> but I'm not convinced
Hi Zenghui,
On 9/24/20 3:42 PM, Zenghui Yu wrote:
> Hi Eric,
>
> On 2020/3/21 0:19, Eric Auger wrote:
>> The VFIO API was enhanced to support nested stage control: a bunch of
>> new iotcls, one DMA FAULT region and an associated specific IRQ.
>>
>> Let's document the process to follow to set up
Hello Al,
On 10/2/20 8:23 PM, Al Stone wrote:
> On 24 Sep 2020 11:54, Auger Eric wrote:
>> Hi,
>>
>> Adding Al in the loop
>>
>> On 9/24/20 11:38 AM, Michael S. Tsirkin wrote:
>>> On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael
On 10/6/20 3:23 AM, Christoph Hellwig wrote:
On Mon, Oct 05, 2020 at 10:35:43AM -0400, Jonathan Marek wrote:
The cache synchronization doesn't have anything to do with IOMMU (for
example: cache synchronization would be useful in cases where drm/msm
doesn't use IOMMU).
It has to do with doing
On Fri, Oct 02, 2020 at 01:21:25PM -0700, Stefano Stabellini wrote:
> On Fri, 2 Oct 2020, Christoph Hellwig wrote:
> > Hi Stefano,
> >
> > I've looked over xen-swiotlb in linux-next, that is with your recent
> > changes to take dma offsets into account. One thing that puzzles me
> > is that
On Wed, 30 Sep 2020 18:09:13 Christoph Hellwig wrote:
>
> Prepare for supporting the DMA_ATTR_NO_KERNEL_MAPPING flag in
> dma_alloc_pages.
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/dma/direct.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git
On Mon, Oct 05, 2020 at 10:35:43AM -0400, Jonathan Marek wrote:
> The cache synchronization doesn't have anything to do with IOMMU (for
> example: cache synchronization would be useful in cases where drm/msm
> doesn't use IOMMU).
It has to do with doing DMA. And we have two frameworks for doing
On Tue, Oct 06, 2020 at 12:26:45PM +0800, Yong Wu wrote:
> Hi Krzysztof,
>
> On Fri, 2020-10-02 at 13:10 +0200, Krzysztof Kozlowski wrote:
> > On Wed, Sep 30, 2020 at 03:06:29PM +0800, Yong Wu wrote:
> > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > >
> > > mt8192 also is MTK IOMMU
On Wed, Sep 30, 2020 at 03:06:41PM +0800, Yong Wu wrote:
> After extending v7s, our pagetable already support iova reach
> 16GB(34bit). the master got the iova via dma_alloc_attrs may reach
> 34bits, but its HW register still is 32bit. then how to set the
> bit32/bit33 iova? this depend on a SMI
On Tue, 6 Oct 2020 at 06:27, Yong Wu wrote:
>
> On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote:
> > On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote:
> > > Convert MediaTek SMI to DT schema.
> > >
> > > Signed-off-by: Yong Wu
> > > ---
> > > .../mediatek,smi-common.txt
21 matches
Mail list logo
