Assign intel_irq_remap_ops to remap_ops only if
intel_irq_remap_ops.prepare() succeeds.
Signed-off-by: Jiang Liu
---
drivers/iommu/irq_remapping.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
From: Joerg Roedel
This allows to get rid of the irq_remapping_supported()
function and all its call-backs into the Intel and AMD
IOMMU drivers.
Signed-off-by: Joerg Roedel
Signed-off-by: Jiang Liu
---
drivers/iommu/amd_iommu_init.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/dr
Simplify irq_remapping code by killing irq_remapping_supported() and
related interfaces.
Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490,
so assume an signed-off from Joerg.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h |
Change variable disable_irq_remap to be static and simplify the code.
Signed-off-by: Jiang Liu
---
drivers/iommu/amd_iommu_init.c |6 +-
drivers/iommu/intel_irq_remapping.c |5 -
drivers/iommu/irq_remapping.c |3 +--
drivers/iommu/irq_remapping.h |2 --
4
Refine code by normailizing the way to detect whether IR is enabled.
Signed-off-by: Jiang Liu
---
drivers/iommu/irq_remapping.c | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remappi
Refine enable_IR_x2apic() and related functions for better readability.
It also changes the way to handle IR in XAPIC mode when enabling X2APIC.
Previously it just skips X2APIC initialization without checking max CPU
APIC ID in system, which may cause problem if system has CPU with APIC
ID bigger
From: Thomas Gleixner
enable_IR_x2apic() calls setup_irq_remapping_ops() which by default
installs the intel dmar remapping ops and then calls the amd iommu irq
remapping prepare callback to figure out whether we are running on an
AMD machine with irq remapping hardware.
Right after that it call
When interrupt remapping hardware is not in X2APIC, CPU X2APIC mode
will be disabled if:
1) Maximum CPU APIC ID is bigger than 255
2) hypervisior doesn't support x2apic mode.
But we should only check whether hypervisor supports X2APIC mode when
hypervisor(CONFIG_HYPERVISOR_GUEST) is enabled, other
Currently if CPU supports X2APIC, IR hardware must work in X2APIC mode
or disabled. Change the code to support IR working in XAPIC mode when
CPU supports X2APIC. Then the CPU APIC driver will decide how to handle
such as configuration by:
1) Disabling X2APIC mode
2) Forcing X2APIC physical mode
Th
Prepare for killing function irq_remapping_supported() by moving code
from intel_irq_remapping_supported() into intel_prepare_irq_remapping().
Combined with patch from Joerg at https://lkml.org/lkml/2014/12/15/487,
so assume an signed-off from Joerg.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg
From: Joerg Roedel
IRQ remapping is only supported when all IOMMUs in the
system support it. So check if all IOMMUs in the system
support IRQ remapping before doing the allocations.
[Jiang]
1) Rebased onto v3.19.
2) Remove redundant check of ecap_ir_support(iommu->ecap) in function
intel_enab
From: Thomas Gleixner
No reason anymore to do GFP_ATOMIC allocations which are not harmful
in the normal bootup case, but matter in the physical hotplug
scenario.
Signed-off-by: Thomas Gleixner
Tested-by: Borislav Petkov
Acked-by: Joerg Roedel
Cc: Jiang Liu
Cc: x...@kernel.org
Link: http://l
X2APIC will be disabled if user specifies "nox2apic" on kernel command
line, even when x2apic_preenabled is true. So correctly detect X2APIC
status by using x2apic_enabled() instead of x2apic_preenabled.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/apic/apic.c |2 +-
1 file changed, 1 insert
From: Thomas Gleixner
The whole iommu setup for irq remapping is a convoluted mess. The
iommu detect function gets called from mem_init() and the prepare
callback gets called from enable_IR_x2apic() for unknown reasons.
Of course AMD and Intel setup differs in nonsensical ways. Intels
prepare ca
Local variable x2apic_enabled has been assigned to but never referred,
so kill it.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/apic/apic.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 9c43899433e3..4a65
When kernel doesn't support X2APIC but BIOS has enabled X2APIC, system
may panic or hang without useful messages. On the other hand, it's
hard to dynamically disable X2APIC when CONFIG_X86_X2APIC is disabled.
So panic with a clear message in such a case.
System panics as below when X2APIC is disab
From: Thomas Gleixner
There is no reason to keep preemption disabled in this function.
We only have two other threads live: kthreadd and idle. Neither of
them is going to preempt. But that preempt_disable forces all the code
inside to do GFP_ATOMIC allocations which is just insane.
Remove it.
When converting x86 to new hierarchy irqdoamin framework, Thomas noticed
that the interrupt remapping initialization flow is a little complex and
has troubles in memory allocation. Then there is a joint force to
simplify IR initialization flow, please refer to related threads at:
https://lkml.org/l
Hi Will,
On Monday 15 December 2014 11:32:52 Will Deacon wrote:
> On Sun, Dec 14, 2014 at 03:51:13PM +, Laurent Pinchart wrote:
> > On Monday 01 December 2014 16:57:12 Will Deacon wrote:
> > > This patch extends of_dma_configure so that it sets up the IOMMU for a
> > > device, as well as the c
Hi Tomasz,
On Tuesday 16 December 2014 11:18:33 Tomasz Figa wrote:
> On Tue, Dec 16, 2014 at 4:53 AM, Laurent Pinchart wrote:
> > On Monday 15 December 2014 11:39:01 Tomasz Figa wrote:
> >> On Sat, Dec 13, 2014 at 5:47 AM, Laurent Pinchart wrote:
> >>> On Friday 12 December 2014 13:15:51 Tomasz Fi
Hi Will,
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
> On Mon, Dec 15, 2014 at 05:16:50PM +, Laurent Pinchart wrote:
> > On Monday 15 December 2014 16:40:41 Will Deacon wrote:
> >> On Sun, Dec 14, 2014 at 03:49:34PM +, Laurent Pinchart wrote:
> >>> On Wednesday 10 December 2014
Hi Arnd,
On Tuesday 16 December 2014 13:10:59 Arnd Bergmann wrote:
> On Tuesday 16 December 2014 14:07:11 Laurent Pinchart wrote:
> > On Tuesday 16 December 2014 12:40:28 Arnd Bergmann wrote:
> > > On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> > > IOMMUs are not as low-level as sys
On Monday 15 December 2014 15:54:42 Mark Brown wrote:
> The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and
> outer_flush_range() functions. This breaks the build on arm64 allmodconfig
> in -next since support has been merged for some Exynos ARMv8 SoCs. Add a
> dependency on ARM to
On Tue, Dec 16, 2014 at 2:44 PM, Laurent Pinchart
wrote:
> Add the six IPMMU instances found in the r8a7790 to DT with a disabled
> status.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots
Hi Geert,
On Tuesday 16 December 2014 14:52:39 Geert Uytterhoeven wrote:
> On Tue, Dec 16, 2014 at 2:44 PM, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> >
>
> Thanks!
>
> Apart from the minor nit below:
> Acked-by: Geert Uytterhoeven
>
> > + ipmmu_mx: mmu@fe951800 {
>
Hi Geert,
On Tuesday 16 December 2014 15:15:43 Geert Uytterhoeven wrote:
> On Tue, Dec 16, 2014 at 2:44 PM, Laurent Pinchart
>
> wrote:
> > Add the seven IPMMU instances found in the r8a7791 to DT with a disabled
> > status.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Acked-by: Geert Uytt
On Tue, Dec 16, 2014 at 2:44 PM, Laurent Pinchart
wrote:
> Add the seven IPMMU instances found in the r8a7791 to DT with a disabled
> status.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lot
Hi Laurent,
On Tue, Dec 16, 2014 at 2:44 PM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
Thanks!
Apart from the minor nit below:
Acked-by: Geert Uytterhoeven
> + ipmmu_mx: mmu@fe951800 {
fe951000
(yes, having to put the same information in two places will cause discrepa
Add the six IPMMU instances found in the r8a7790 to DT with a disabled
status.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790.dtsi | 51 ++
1 file changed, 51 insertions(+)
Changes compared to v1:
- Update to the v2 DT bindings
diff --git
Make platform data optional when the device is instantiated from DT and
look up the micro-TLB number in the bus master DT node.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/ipmmu-vmsa.c | 55 +++---
1 file changed, 47 insertions(+), 8 deletions(-)
Cc
Hello,
This patch fixes several small issues with the Renesas IPMMU-VMSA driver and
then implements DT support.
Patches 01/10 to 04/10 are small bug fixes. Please see the individual patches
for more information.
Patches 05/10 and 06/10 define DT bindings and implement DT support. Patches
07/10 a
When clearing PUD or PMD entries the child page table (if any) is freed
and the PUD or PMD entry is then cleared. This result in a small race
condition window during which a free page table could be accessed by the
IPMMU.
Fix it by clearing and flushing the PUD or PMD entry before freeing the
chil
Devices such as the system DMA controller are connected to multiple
micro TLBs of the same IOMMU. Support this.
Selective enabling of micro TLBs based on runtime device usage isn't
possible at the moment due to lack of support in the IOMMU and DMA
mapping APIs. Support for devices connected to dif
No board file instantiates the IPMMU using platform data. Now that we
have DT support, get rid of platform data.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/ipmmu-vmsa.c | 24
include/linux/platform_data/ipmmu-vmsa.h | 24
2 f
Add the seven IPMMU instances found in the r8a7791 to DT with a disabled
status.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791.dtsi | 60 ++
1 file changed, 60 insertions(+)
Changes compared to v1:
- Update to the v2 DT bindings
diff --g
The TLB must be invalidated after unmapping memory to remove stale TLB
entries. this was supposed to be performed already, but a bug in the
driver prevented the TLB invalidate function from being called. Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/ipmmu-vmsa.c | 4 +---
1 file chan
From: Axel Lin
Signed-off-by: Axel Lin
Signed-off-by: Laurent Pinchart
---
drivers/iommu/ipmmu-vmsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9838d119045d..70bb5ba2aa51 100644
--- a/drivers/iommu/ipmmu-vm
The ARM IOMMU mapping needs to be released when attaching the device
fails. Add arm_iommu_release_mapping() to the error code path. This is
safe to call with a NULL mapping, so no specific check is needed.
Cleanup is also missing when failing to create a mapping. Jump to the
error code path in tha
Signed-off-by: Laurent Pinchart
---
.../bindings/iommu/renesas,ipmmu-vmsa.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
Cc: devicet...@vger.kernel.org
Changes compared to v1:
- Exte
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
> > Using a single domain is a bit of a waste of resources in my case, so an
> > evolution would be to create four domains and assign devices to them based
> > on
> > a policy. The policy could be fixed (round-robin for instance), or
> > co
On Tuesday 16 December 2014 14:07:11 Laurent Pinchart wrote:
> Hi Arnd,
>
> On Tuesday 16 December 2014 12:40:28 Arnd Bergmann wrote:
> > On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> > IOMMUs are not as low-level as system interrupt controllers or
> > system clocks. I'm begin
Hi Arnd,
On Tuesday 16 December 2014 12:40:28 Arnd Bergmann wrote:
> On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> IOMMUs are not as low-level as system interrupt controllers or
> system clocks. I'm beginning to agree with Thierry that they should
> be treated as normal p
Hi Laurent,
On Tue, Dec 16, 2014 at 8:16 AM, Laurent Pinchart
wrote:
> Hi Magnus,
>
> On Tuesday 16 December 2014 07:44:32 Magnus Damm wrote:
>> On Tue, Dec 16, 2014 at 3:44 AM, Laurent Pinchart wrote:
>> > On Monday 15 December 2014 14:07:52 Geert Uytterhoeven wrote:
>> >> On Mon, Dec 15, 2014 a
Hi Geert,
On Tuesday 16 December 2014 11:02:03 Geert Uytterhoeven wrote:
> On Mon, Dec 15, 2014 at 7:44 PM, Laurent Pinchart wrote:
> > On Monday 15 December 2014 14:07:52 Geert Uytterhoeven wrote:
> >> On Mon, Dec 15, 2014 at 1:13 AM, Laurent Pinchart wrote:
> >> > Add the seven IPMMU instances f
On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> > > > IOMMUs are not as low-level as system interrupt controllers or system
> > > > clocks. I'm beginning to agree with Thierry that they should be treated
> > > > as normal platform devices as they're not required earlier than probe
> > > >
Hello,
On 2014-12-15 19:19, Laurent Pinchart wrote:
On Monday 15 December 2014 18:13:23 Will Deacon wrote:
On Mon, Dec 15, 2014 at 05:53:48PM +, Laurent Pinchart wrote:
On Monday 15 December 2014 17:43:02 Will Deacon wrote:
On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
Hi Laurent,
On Mon, Dec 15, 2014 at 7:44 PM, Laurent Pinchart
wrote:
> On Monday 15 December 2014 14:07:52 Geert Uytterhoeven wrote:
>> On Mon, Dec 15, 2014 at 1:13 AM, Laurent Pinchart wrote:
>> > Add the seven IPMMU instances found in the r8a7791 to DT with a disabled
>> > status.
>> >
>> > Sig
On Mon, Dec 15, 2014 at 11:47:23PM +, Mitchel Humpherys wrote:
> From: Matt Wagantall
>
> It is sometimes necessary to poll a memory-mapped register until its value
> satisfies some condition. Introduce a family of convenience macros that do
> this. Tight-looping, sleeping, and timing out can
Hi Paolo,
Could you please have a look at this series? Thanks a lot!
Thanks,
Feng
> -Original Message-
> From: Wu, Feng
> Sent: Friday, December 12, 2014 11:15 PM
> To: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> g...@kernel.org; pbonz...@redhat.com; dw...@in
49 matches
Mail list logo
