Hi,
On 2020-08-26 03:45, Doug Anderson wrote:
Hi,
On Tue, Aug 25, 2020 at 12:01 PM Sai Prakash Ranjan
wrote:
Hi,
On 2020-08-25 21:40, Doug Anderson wrote:
> Hi,
>
> On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan
> wrote:
>>
>> Currently the non-strict or lazy mode of TLB invalidation
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
Dear All,
During the Exynos DRM GEM rework and fixing the issues in the.
drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most
drivers in DRM framework incorrectly use nents and orig_nents entries of
the struct sg_table.
In case of the most DMA-mapping implementations exchanging
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
It is a common operation done by DRM drivers to check the contiguity
of the DMA-mapped buffer described by a scatterlist in the
sg_table object. Let's add a common helper for this operation.
Signed-off-by: Marek Szyprowski
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/drm_gem_cma_helper.c |
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.
No functional change, because the code already properly did all the
scaterlist related calls.
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/omapdrm/omap_gem.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
Use common helper for checking the contiguity of the imported dma-buf and
do this check before allocating resources, so the error path is simpler.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 28 ++
1 file changed, 6 insertions(+), 22
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
Reviewed-by: Andrzej Hajda
Acked-by : Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
Replace the current hand-crafted code for extracting pages and DMA
addresses from the given scatterlist by the much more robust
code based on the generic scatterlist iterators and recently
introduced sg_table-based wrappers. The resulting code is simple and
easy to understand, so the comment
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the
On Wed, Aug 26 2020 at 16:40, Boqun Feng wrote:
> I hit a compiler error while I was trying to compile this patchset:
>
> arch/x86/kernel/devicetree.c: In function ‘dt_irqdomain_alloc’:
> arch/x86/kernel/devicetree.c:232:6: error: ‘struct irq_alloc_info’ has no
> member named ‘ioapic_id’; did you
Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/dmar.c | 74
BIOS allocate reserved memory ranges that may be DMA targets.
BIOS may report each such reserved memory region through the
RMRR structures,along with the devices that requires access to
the specified reserved memory region.
The purpose of this series is to achieve ACPI device in RMRR
access
After acpi device in RMRR is detected,it is necessary
to establish a mapping for these devices.
In acpi_device_create_direct_mappings(),create a mapping
for the acpi device in RMRR.
Add a helper to achieve the acpi namespace device can
access the RMRR region.
Signed-off-by: FelixCuioc
---
In the probe_acpi_namespace_devices function,when the physical
node of the acpi device is NULL,the unlock function is missing.
Add mutex_unlock(>physical_node_lock).
Reported-by: Dan Carpenter
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/iommu.c | 1 +
1 file changed, 1 insertion(+)
diff
Hi Thomas,
I hit a compiler error while I was trying to compile this patchset:
arch/x86/kernel/devicetree.c: In function ‘dt_irqdomain_alloc’:
arch/x86/kernel/devicetree.c:232:6: error: ‘struct irq_alloc_info’ has no
member named ‘ioapic_id’; did you mean ‘ioapic’?
232 | tmp.ioapic_id =
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards building mtk_iommu as a kernel module.
[1]
On Wed, Aug 26, 2020 at 06:27:51AM -0400, FelixCuioc wrote:
> After acpi device in RMRR is detected,it is necessary
> to establish a mapping for these devices.
> In acpi_device_create_direct_mappings(),create a mapping
> for the acpi device in RMRR.
> Add a helper to achieve the acpi namespace
The "page" pointer can be used with out being initialized.
Fixes: d7e673ec2c8e ("dma-pool: Only allocate from CMA when in same memory
zone")
Signed-off-by: Dan Carpenter
---
kernel/dma/pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/pool.c
From: Thomas Gleixner
Some past platform removal forgot to get rid of this unused ballast.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/mpspec.h | 10 --
arch/x86/include/asm/x86_init.h | 10 --
arch/x86/kernel/mpparse.c | 26
Composing the MSI message at the MSI chip level is wrong because the
underlying parent domain is the one which knows how the message should be
composed for the direct vector delivery or the interrupt remapping table
entry.
The interrupt remapping aware PCI/MSI chip does that already. Make the
Setting the irq_set_vcpu_affinity() callback to
irq_chip_set_vcpu_affinity_parent() is a pointless exercise because the
function which utilizes it searchs the domain hierarchy to find a parent
domain which has such a callback.
Remove the useless indirection.
Signed-off-by: Thomas Gleixner
---
This is the second version of providing a base to support device MSI (non
PCI based) and on top of that support for IMS (Interrupt Message Storm)
based devices in a halfways architecture independent way.
The first version can be found here:
The documentation of irq_chip_compose_msi_msg() claims that with
hierarchical irq domains the first chip in the hierarchy which has an
irq_compose_msi_msg() callback is chosen. But the code just keeps
iterating after it finds a chip with a compose callback.
The x86 HPET MSI implementation relies
From: Thomas Gleixner
None of the DMAR specific fields are required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |6 --
arch/x86/kernel/apic/msi.c| 10 +-
2 files changed, 5 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++
From: Thomas Gleixner
Now that the iommu implementations handle the X86_*_GET_PARENT_DOMAIN
types, consolidate the two getter functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irq_remapping.h |8
arch/x86/kernel/apic/io_apic.c |2 +-
From: Thomas Gleixner
Dereferencing irq_data before checking it for NULL is suboptimal.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/amd/iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3717,8
VMD has it's own PCI/MSI interrupt domain which is not in any way depending
on the x86 vector domain. PCI devices behind VMD share the VMD MSIX vector
entries via a VMD specific message translation to the actual VMD MSIX
vector. The VMD device interrupt handler for the VMD MSIX vectors invokes
all
Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/dmar.c | 74
BIOS allocate reserved memory ranges that may be DMA targets.
BIOS may report each such reserved memory region through the
RMRR structures,along with the devices that requires access to
the specified reserved memory region.
The purpose of this series is to achieve ACPI device in RMRR
access
After acpi device in RMRR is detected,it is necessary
to establish a mapping for these devices.
In acpi_device_create_direct_mappings(),create a mapping
for the acpi device in RMRR.
Add a helper to achieve the acpi namespace device can
access the RMRR region.
Signed-off-by: FelixCuioc
---
In the probe_acpi_namespace_devices function,when the physical
node of the acpi device is NULL,the unlock function is missing.
Add mutex_unlock(>physical_node_lock).
Reported-by: Dan Carpenter
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/iommu.c | 1 +
1 file changed, 1 insertion(+)
diff
On Wed, Aug 26, 2020 at 06:27:50AM -0400, FelixCuioc wrote:
> Some ACPI devices need to issue dma requests to access
> the reserved memory area.BIOS uses the device scope type
> ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
> This patch add support for detecting ACPI devices in RMRR.
On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
Currently the non-strict or lazy mode of TLB invalidation can only be set
for all or no domains. This works well for development platforms where
setting to non-strict/lazy mode is fine for performance reasons but on
production devices, we need a
From: Thomas Gleixner
Move the UV specific fields into their own struct for readability sake. Get
rid of the #ifdeffery as it does not matter at all whether the alloc info
is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h | 21
From: Thomas Gleixner
Now that interrupt remapping sets the irqdomain pointer when a PCI device
is added it's possible to store the default irq domain in the device struct
in pcibios_add_device().
If the bus to which a device is connected has an irq domain associated then
this domain is used
From: Thomas Gleixner
To support MSI irq domains which do not fit at all into the regular MSI
irqdomain scheme, like the XEN MSI interrupt management for PV/HVM/DOM0,
it's necessary to allow to override the alloc/free implementation.
This is a preperatory step to switch X86 away from
From: Thomas Gleixner
The only user is in the same file and the name is too generic because this
function is only ever used for HVM domains.
Signed-off-by: Thomas Gleixner
Reviewed-by: Juergen Gross
---
arch/x86/pci/xen.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
From: Thomas Gleixner
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/amd/iommu.c | 65 ++
1 file changed, 21 insertions(+), 44
From: Thomas Gleixner
No functional change.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |4 ++--
arch/x86/kernel/apic/msi.c |6 +++---
drivers/iommu/amd/iommu.c | 24
drivers/iommu/intel/irq_remapping.c | 18
From: Thomas Gleixner
None of the magic HPET fields are required in any way.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |7 ---
arch/x86/kernel/apic/msi.c | 14 +++---
drivers/iommu/amd/iommu.c |2 +-
From: Thomas Gleixner
Adding a function call before the first #ifdef in arch_pci_init() triggers
a 'mixed declarations and code' warning if PCI_DIRECT is enabled.
Use stub functions and move the #ifdeffery to the header file where it is
not in the way.
Signed-off-by: Thomas Gleixner
---
From: Thomas Gleixner
For the upcoming device MSI support a new allocation type is
required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -40,6 +40,7 @@
From: Thomas Gleixner
To allow utilizing the irq domain pointer in struct device it is necessary
to make XEN/MSI irq domain compatible.
While the right solution would be to truly convert XEN to irq domains, this
is an exercise which is not possible for mere mortals with limited XENology.
From: Thomas Gleixner
PCI devices behind a VMD bus are not subject to interrupt remapping, but
the irq domain for VMD MSI cannot be distinguished from a regular PCI/MSI
irq domain.
Add a new domain bus token and allow it in the bus token check in
msi_check_reservation_mode() to keep the
From: Thomas Gleixner
Devices on the VMD bus use their own MSI irq domain, but it is not
distinguishable from regular PCI/MSI irq domains. This is required
to exclude VMD devices from getting the irq domain pointer set by
interrupt remapping.
Override the default bus token.
Signed-off-by:
From: Thomas Gleixner
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/irq_remapping.c | 67
1 file changed, 24 insertions(+), 43
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into an
irq domain.
Move the x86_msi ops setup
Now that the domain can be retrieved through device::msi_domain the domain
search for PCI_MSI[X] is not longer required. Remove it.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/iommu/intel/irq_remapping.c |3 ---
1 file changed, 3 deletions(-)
---
From: Thomas Gleixner
The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture
requires them or not. Architectures which are fully utilizing hierarchical
irq domains should never call into that code.
It's not only architectures which depend on that by implementing one or
more of
From: Thomas Gleixner
Get rid of all the gunk and remove the 'select PCI_MSI_ARCH_FALLBACK' from
the x86 Kconfig so the weak functions in the PCI core are replaced by stubs
which emit a warning, which ensures that any fail to set the irq domain
pointer results in a warning when the device is
From: Thomas Gleixner
As a first step to make X86 utilize the direct MSI irq domain operations
store the irq domain pointer in the device struct when a device is probed.
This is done from dmar_pci_bus_add_dev() because it has to work even when
DMA remapping is disabled. It only overrides the
From: Thomas Gleixner
irq_remapping_ir_irq_domain() is used to retrieve the remapping parent
domain for an allocation type. irq_remapping_irq_domain() is for retrieving
the actual device domain for allocating interrupts for a device.
The two functions are similar and can be unified by using
From: Thomas Gleixner
No point to call it from both 32bit and 64bit implementations of
default_setup_apic_routing(). Move it to the caller.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c |3 +++
arch/x86/kernel/apic/probe_32.c |3 ---
From: Thomas Gleixner
Retrieve the PCI device from the msi descriptor instead of doing so at the
call sites.
Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
---
V2: Address Bjorns comments (subject prefix, pdev/dev)
---
arch/x86/kernel/apic/msi.c |2 +-
drivers/pci/msi.c
From: Thomas Gleixner
struct irq_alloc_info is a horrible zoo of unnamed structs in a union. Many
of the struct fields can be generic and don't have to be type specific like
hpet_id, ioapic_id...
Provide a generic set of members to prepare for the consolidation. The goal
is to make
From: Thomas Gleixner
Provide a helper function to check whether a PCI device is handled by a
non-standard PCI/MSI domain. This will be used to exclude such devices
which hang of a special bus, e.g. VMD, to be excluded from the irq domain
override in irq remapping.
Signed-off-by: Thomas
From: Thomas Gleixner
As the next step to make X86 utilize the direct MSI irq domain operations
store the irq domain pointer in the device struct when a device is probed.
It only overrides the irqdomain of devices which are handled by a regular
PCI/MSI irq domain which protects PCI devices
From: Thomas Gleixner
pci_msi_get_hwirq() and pci_msi_set_desc are not longer special. Enable the
generic MSI domain ops in the core and PCI MSI code unconditionally and get
rid of the x86 specific implementations in the X86 MSI code and in the
hyperv PCI driver.
Signed-off-by: Thomas Gleixner
Now that the domain can be retrieved through device::msi_domain the domain
search for PCI_MSI[X] is not longer required. Remove it.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/iommu/amd/iommu.c |3 ---
1 file changed, 3 deletions(-)
--- a/drivers/iommu/amd/iommu.c
+++
From: Thomas Gleixner
Nothing except XEN uses the setup/teardown ops. Hide them there.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/x86_init.h |2 --
arch/x86/pci/xen.c | 21 ++---
2 files changed, 14 insertions(+), 9 deletions(-)
---
From: Thomas Gleixner
Move the IOAPIC specific fields into their own struct and reuse the common
devid. Get rid of the #ifdeffery as it does not matter at all whether the
alloc info is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
arch_teardown_msi_irq().
From: Thomas Gleixner
No point in initializing the default PCI/MSI interrupt domain early and no
point to create it when XEN PV/HVM/DOM0 are active.
Move the initialization to pci_arch_init() and convert it to init ops so
that XEN can override it as XEN has it's own PCI/MSI management. The XEN
From: Thomas Gleixner
Convert the interrupt remap drivers to retrieve the pci device from the msi
descriptor and use info::hwirq.
This is the first step to prepare x86 for using the generic MSI domain ops.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |8
On Wed, Aug 26, 2020 at 06:27:52AM -0400, FelixCuioc wrote:
> In the probe_acpi_namespace_devices function,when the physical
> node of the acpi device is NULL,the unlock function is missing.
> Add mutex_unlock(>physical_node_lock).
>
> Reported-by: Dan Carpenter
> Signed-off-by: FelixCuioc
MSI interrupts have some common flags which should be set not only for
PCI/MSI interrupts.
Move the PCI/MSI flag setting into a common function so it can be reused.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/pci/msi.c |7 +--
include/linux/msi.h |1 +
Generic IMS irq chips and irq domain implementations for IMS based devices
in both variants:
- Message store in an array in device memory
- Message store in system RAM (part of queue memory)
Allocation and freeing of interrupts happens via the generic
msi_domain_alloc/free_irqs()
From: Thomas Gleixner
Add device specific MSI domain infrastructure for devices which have their
own resource management and interrupt chip. These devices are not related
to PCI and contrary to platform MSI they do not share a common resource and
interrupt chip. They provide their own domain
Until now interrupt chips which support setting affinity are nit locking
the associated bus lock for two reasons:
- All chips which support affinity setting do not use buslock because they just
can operated directly on the hardware.
- All chips which use buslock do not support affinity
From: Thomas Gleixner
Rename it to x86_msi_prepare() and handle the allocation type setup
depending on the device type.
Add a new arch_msi_prepare define which will be utilized by the upcoming
device MSI support. Define it to NULL if not provided by an architecture in
the generic MSI header.
From: Thomas Gleixner
For devices which don't have a standard storage for MSI messages like the
upcoming IMS (Interrupt Message Storm) it's required to allocate storage
space before allocating interrupts and after freeing them.
This could be achieved with the existing callbacks, but that would
From: Thomas Gleixner
For the upcoming device MSI support it's required to have a default
irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not
need to care.
Signed-off-by: Thomas Gleixner
---
drivers/base/platform-msi.c |2 ++
1 file changed, 2 insertions(+)
---
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on drm-intel/for-linux-next linus/master v5.9-rc2
next-20200826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On 2020-08-26 17:07, Robin Murphy wrote:
On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
Currently the non-strict or lazy mode of TLB invalidation can only be
set
for all or no domains. This works well for development platforms where
setting to non-strict/lazy mode is fine for performance
On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote:
> Add a topology description to the virtio-iommu driver and enable x86
> platforms.
>
> Since [v2] we have made some progress on adding ACPI support for
> virtio-iommu, which is the preferred boot method on x86. It will be a
>
1 - 100 of 137 matches
Mail list logo
