[RFT v3] drm: use late_initcall() for amdkfd and radeon

[Luis R. Rodriguez]

To get KFD support in radeon we need the following
initialization to happen in this order, their
respective driver file that has its init routine
listed next to it:

0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c
2. AMD KFD:drivers/gpu/drm/amd/amdkfd/kfd_module.c
3. AMD Radeon: drivers/gpu/drm/radeon/radeon_drv.c

Order is rather implicit, but these drivers can currently
only do so much given the amount of leg room available.
Below are the respective init routines and how they are
initialized:

arch/x86/kernel/pci-dma.c   rootfs_initcall(pci_iommu_init);
drivers/iommu/amd_iommu_v2.cmodule_init(amd_iommu_v2_init);
drivers/gpu/drm/amd/amdkfd/kfd_module.c module_init(kfd_module_init);
drivers/gpu/drm/radeon/radeon_drv.c module_init(radeon_init);

When a driver is built-in module_init() folds to use
device_initcall(), and we have the following possible
orders:

#define pure_initcall(fn)__define_initcall(fn, 0)
#define core_initcall(fn)__define_initcall(fn, 1)
#define postcore_initcall(fn)__define_initcall(fn, 2)
#define arch_initcall(fn)__define_initcall(fn, 3)
#define subsys_initcall(fn)  __define_initcall(fn, 4)
#define fs_initcall(fn)  __define_initcall(fn, 5)
-
#define rootfs_initcall(fn)  __define_initcall(fn, rootfs)
#define device_initcall(fn)  __define_initcall(fn, 6)
#define late_initcall(fn)__define_initcall(fn, 7)

Since we start off from rootfs_initcall(), it gives us 3 more
levels of leg room to play with for order semantics, this isn't
enough to address all required levels of dependencies, this
is specially true given that AMD-KFD needs to be loaded before
the radeon driver -- -but this it not enforced by symbols.
If the AMD-KFD driver is not loaded prior to the radeon driver
because otherwise the radeon driver will not initialize the
AMD-KFD driver and you get no KFD functionality in userspace.

Commit 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in
Makefile") works around some of the possibe races between
the AMD IOMMU v2 and GPU drivers by changing the link order.
This is fragile, however its the bets we can do, given that
making the GPU drivers use late_initcall() would also implicate
a similar race between them. That possible race is fortunatley
addressed given that the drm Makefile currently has amdkfd
linked prior to radeon:

drivers/gpu/drm/Makefile
...
obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
obj-$(CONFIG_DRM_RADEON)+= radeon/
...

Changing amdkfd and radeon to late_initcall() however is
still the right call in orde to annotate explicitly a
delayed dependency requirement between the GPU drivers
and the IOMMUs.

We can't address the fragile nature of the link order
right now, but in the future that might be possible.

Signed-off-by: Luis R. Rodriguez 
---

Please note, the changes to drivers/Makefile are just
for the sake of forcing the possible race to occur,
if this works well the actual [PATCH] submission will
skip those changes as its pointless to remove those
work arounds as it stands, due to the limited nature
of the levels available for addressing requirements.

Also, if you are aware of further dependency hell
things like these -- please do let me know as I am
interested in looking at addressing them.

 drivers/Makefile| 6 ++
 drivers/gpu/drm/amd/amdkfd/kfd_module.c | 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 0b6f3d60193d..0fbe3982041f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,10 +50,7 @@ obj-$(CONFIG_RESET_CONTROLLER)   += reset/
 obj-y  += tty/
 obj-y  += char/
 
-# iommu/ comes before gpu as gpu are using iommu controllers
-obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
-
-# gpu/ comes after char for AGP vs DRM startup and after iommu
+# gpu/ comes after char for AGP vs DRM startup
 obj-y  += gpu/
 
 obj-$(CONFIG_CONNECTOR)+= connector/
@@ -147,6 +144,7 @@ obj-y   += clk/
 
 obj-$(CONFIG_MAILBOX)  += mailbox/
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock/
+obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
 obj-$(CONFIG_REMOTEPROC)   += remoteproc/
 obj-$(CONFIG_RPMSG)+= rpmsg/
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 850a5623661f..3d1dab8a31c7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -141,7 +141,7 @@ static void __exit kfd_module_exit(void)
dev_info(kfd_device, "Removed module\n");
 }
 
-module_init(kfd_module_init);
+late_initcall(kfd_module_init);
 module_exit(kfd_module_exit);
 
 

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

[Luis R. Rodriguez]

On Mon, Apr 25, 2016 at 12:23:51PM +0200, Joerg Roedel wrote:
> On Mon, Apr 18, 2016 at 02:03:50PM +0200, Luis R. Rodriguez wrote:
> > You said that with my patch you saw AMD IOMMUv2 kick off first,
> > that was intentional as I thought that's what you needed. Can
> > someone please describe the requirements?
> > 
> > Also what does drm use that you say has a conflict already? What
> > drm code are we talking about exactly ?
> 
> The required order is:
> 
>   1. AMD IOMMUv1 (in-kernel only, initialized at boot time after PCI)
>   2. AMD IOMMUv2 (in-kernel or as module, provides demand paging
>   and uses v1 interfaces to talk to the IOMMU)
>   3. AMD-KFD (Implements compute offloading to the GPU and
>   uses AMD IOMMUv2 functionality, also provides a
>   symbol for the radeon driver)
>   4. DRM with(Checks if the symbol provided by AMD-KFD is
>  Radeon   available at init time and does the KFD
>   initialization from there, because the GPU needs
>   to be up first)
> 
> So AMD IOMMUv2 does not initialize (but it does load to have the symbols
> available for drivers that optionally use its functionality) without the
> AMD IOMMUv1 driver, as it can't access the IOMMU hardware then.
> 
> AMD-KFD does not load without AMD IOMMUv2 being loaded, as it depends on
> its symbols. AMD-KFD on the other hand needs to be loaded before the
> radeon driver (but this it not enforced by symbols), because otherwise
> the radeon driver will not initialize the AMD-KFD driver.
> 
> When AMD-KFD is loaded and you load radeon then, you get the KFD
> functionality in the kernel. Then you can move on to the fun getting the
> userspace running and actually execute anything on the GPU. But thats
> another story.
> 
> I know what you think, and I agree: It's a big mess :)

Its no concern for me that its a mess, frankly most drivers are. This however
illustrates a semantic gap in the driver core when you have more than 3
dependencies after a rootfs_initcall(), given that the buck stops at
late_initcall(), only 3 levels above. With 4 dependencies you run out
of semantics to specify explicit requirements.

Ties can be disputed through link order though, but this is obviously fragile,
and the dependencies are then left implicit. Nothing vets for correctness,
either in software or through static analysers.

To summarize the specific code in question is (and order required):

AMD IOMMUv1:arch/x86/kernel/pci-dma.c   
rootfs_initcall(pci_iommu_init);
AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c
module_init(amd_iommu_v2_init); (device_initcall())
AMD KFD:drivers/gpu/drm/amd/amdkfd/kfd_module.c 
module_init(kfd_module_init); (device_initcall())
AMD Radeon: drivers/gpu/drm/radeon/radeon_drv.c 
module_init(radeon_init); (device_initcall())

Commit 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in Makefile") 
resolved
the race between IOMMU and GPU drivers this way, however an alternative is to 
make
the dependencies in levels explicit by making the amdkfd and radeon drivers both
use late_initcall(), this however is technically still racy specially since you
note that the amdkfd driver is not loaded prior to radeon through symbol
dependencies, if happens to be loaded it then you get KFD functionality,
otherwise you don't.

Making both amdkfd and radeon use late_initcall() would actually work now though
but that's only because the link order also happens to match the dependency
requirements:

drivers/gpu/drm/Makefile
...
obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
obj-$(CONFIG_DRM_RADEON)+= radeon/  
...

Since we currently lack proper semantics to define clear dependencies for all
this reverting 1bacc894c227fad8a7 after using late_initcall() on both amdkfd
and radeon would not be useful other than to just test the race fix, given that
such work around would still be present also on drivers/gpu/drm/Makefile to
account for the race between amdkfd and radeon. Reverting 1bacc894c227fad8a7
after using late_initcall() on both amdkfd and radeon would just bump the
race work around another level.

Modifying both amdkfd and radeon to use late_initcall() however seems well
justified for now, and given the current state of affairs with link order
one should be able to then correctly build all these things as built-in
and it should work correctly.

I'm still not satisfied with the issues on semantics here though. A fix
for that, if desired, should be possible using linker-tables, currently
in RFCv2 [0] stage. Linker tables offer practically infinite number (as
long as a valid ELF section name, as the order level is part of the
section name) of order levels. It also would offer the opportunity
to build dependencies outside of the driver core layer, so you can
customize the dependency map per subsystem as you see fit.

So -- for now I'll 

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

[Luis R. Rodriguez]

On Tue, Apr 19, 2016 at 10:02:52AM +0800, Wan Zongshun wrote:
> 
> You have to take carefully to arrange the calling sequence for
> iommuv1, iommuv2, kfd module, and drm like the following sequence :
> v1 ->v2->kfd, drm.
> 
> iommuv1 -- rootfs_initcall(fn)
> IOMMUV2 -- device_initcall(fn)
> kfd module -- late_initcall(fn)
> drm -- late_initcall(fn)

Thanks, it turns out this is not exactly enough, given as 
Joerg notes:

--
AMD-KFD on the other hand needs to be loaded before the 
 
radeon driver (but this it not enforced by symbols), because otherwise  
  
the radeon driver will not initialize the AMD-KFD driver. 
---

We have a theoretical race still possible between the kfd module
and the drm driver. I'll reply to Joerg's e-mail with more feedback.

  Luis
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[GIT PULL] Intel IOMMU improvements for 4.7

[David Woodhouse]

Linus, please pull from
git://git.infradead.org/intel-iommu.git

This patchset improves the scalability of the Intel IOMMU code by
resolving two spinlock bottlenecks and eliminating the linearity of
the IOVA allocator, yielding up to ~5x performance improvement and
approaching iommu=off performance.

Omer Peleg (8):
  iommu/vt-d: refactoring of deferred flush entries
  iommu/vt-d: per-cpu deferred invalidation queues
  iommu/vt-d: correct flush_unmaps pfn usage
  iommu/vt-d: only unmap mapped entries
  iommu/vt-d: avoid dev iotlb logic for domains with no dev iotlbs
  iommu/vt-d: change intel-iommu to use IOVA frame numbers
  iommu/iova: introduce per-cpu caching to iova allocation
  iommu/vt-d: Use per-cpu IOVA caching

 drivers/iommu/intel-iommu.c | 318 
+++
 drivers/iommu/iova.c| 417 
-
 include/linux/iova.h|  23 -
 3 files changed, 638 insertions(+), 120 deletions(-)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

[Wei Yang]

On Thu, May 26, 2016 at 11:11:51AM +0100, Robin Murphy wrote:
>On 25/05/16 22:43, Wei Yang wrote:
>>On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote:
>>>On 25/05/16 00:06, Wei Yang wrote:
Hi, Joerg

Not sure whether you think this calculation is correct.

If I missed something for this " + 1" in your formula, I am glad to hear 
your
explanation. So that I could learn something from you :-)
>>>
>>>I'm not familiar enough with this aspect of the driver to confirm whether the
>>>change is appropriate or not, but it does seem worth noting that using
>>>DIV_ROUND_UP would be an even neater approach.
>>>
>>
>>Hi, Robin,
>>
>>Thanks for your comment.
>>
>>Yes, I agree DIV_ROUND_UP would make the code more easy to read.
>>
>>I have thought about using DIV_ROUND_UP, while from the definition
>>DIV_ROUND_UP use operation "/", and ALIGN use bit operation. So the change in
>>my patch chooses the second one and tries to keep the efficiency.
>
>The efficiency of what, though?
>
>It's an unsigned division by a constant power of two, which GCC implements
>with a shift instruction regardless of optimisation - and at -O1 and above
>the machine code generated for either form of expression is completely
>identical (try it and see!).
>

Thanks.

Looks my knowledge of the compiler is an ancient one :-)

I haven't thought about to compare the generated code. This is really a good
test before making the decision. Next time I would try this before choosing
one.

>On the other hand, the small amount of time and cognitive effort it took to
>parse "ALIGN(x, 256) >> 8" as "divide by 256, rounding up" compared to simply
>seeing "DIV_ROUND_UP(x, 256)" and knowing instantly what's intended,
>certainly makes it less efficient to _maintain_; thus it's exactly the kind
>of thing to which Dijkstra's famous quotation applies.
>
>Does that count towards learning something? ;)
>

Really~

I am really happy to see your comments which help me to be more mature on the
solution. I owe you a favor :-) If you would come to Shanghai, I would like to
take you around~

>Robin.
>
Have a good day~

On Sat, May 21, 2016 at 02:41:51AM +, Wei Yang wrote:
>In commit <8bf478163e69> ("iommu/vt-d: Split up iommu->domains array"), it
>it splits iommu->domains in two levels. Each first level contains 256
>entries of second level. In case of the ndomains is exact a multiple of
>256, it would have one more extra first level entry for current
>implementation.
>
>This patch refines this calculation to reduce the extra first level entry.
>
>Signed-off-by: Wei Yang 
>---
>drivers/iommu/intel-iommu.c |4 ++--
>1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>index e3061d3..2204ca4 100644
>--- a/drivers/iommu/intel-iommu.c
>+++ b/drivers/iommu/intel-iommu.c
>@@ -1634,7 +1634,7 @@ static int iommu_init_domains(struct intel_iommu 
>*iommu)
>   return -ENOMEM;
>   }
>
>-  size = ((ndomains >> 8) + 1) * sizeof(struct dmar_domain **);
>+  size = (ALIGN(ndomains, 256) >> 8) * sizeof(struct dmar_domain **);
>   iommu->domains = kzalloc(size, GFP_KERNEL);
>
>   if (iommu->domains) {
>@@ -1699,7 +1699,7 @@ static void disable_dmar_iommu(struct intel_iommu 
>*iommu)
>static void free_dmar_iommu(struct intel_iommu *iommu)
>{
>   if ((iommu->domains) && (iommu->domain_ids)) {
>-  int elems = (cap_ndoms(iommu->cap) >> 8) + 1;
>+  int elems = ALIGN(cap_ndoms(iommu->cap), 256) >> 8;
>   int i;
>
>   for (i = 0; i < elems; i++)
>--
>1.7.9.5

>>

-- 
Wei Yang
Help you, Help me
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

[Tom Lendacky]

On 05/25/2016 02:30 PM, Matt Fleming wrote:
> On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote:
>>
>> I looked into this and this would be a large change also to parse tables
>> and build lists.  It occurred to me that this could all be taken care of
>> if the early_memremap calls were changed to early_ioremap calls. Looking
>> in the git log I see that they were originally early_ioremap calls but
>> were changed to early_memremap calls with this commit:
>>
>> commit abc93f8eb6e4 ("efi: Use early_mem*() instead of early_io*()")
>>
>> Looking at the early_memremap code and the early_ioremap code they both
>> call __early_ioremap so I don't see how this change makes any
>> difference (especially since FIXMAP_PAGE_NORMAL and FIXMAP_PAGE_IO are
>> identical in this case).
>>
>> Is it safe to change these back to early_ioremap calls (at least on
>> x86)?
> 
> I really don't want to begin mixing early_ioremap() calls and
> early_memremap() calls for any of the EFI code if it can be avoided.

I definitely wouldn't mix them, it would be all or nothing.

> 
> There is slow but steady progress to move more and more of the
> architecture specific EFI code out into generic code. Swapping
> early_memremap() for early_ioremap() would be a step backwards,
> because FIXMAP_PAGE_NORMAL and FIXMAP_PAGE_IO are not identical on
> ARM/arm64.

Maybe adding something similar to __acpi_map_table would be more
appropriate?

> 
> Could you point me at the patch that in this series that fixes up
> early_ioremap() to work with mem encrypt/decrypt? I took another
> (quick) look through but couldn't find it.

The patch in question is patch 6/18 where PAGE_KERNEL is changed to
include the _PAGE_ENC attribute (the encryption mask). This now
makes FIXMAP_PAGE_NORMAL contain the encryption mask while
FIXMAP_PAGE_IO does not. In this way, anything mapped using the
early_ioremap call won't be mapped encrypted.

Thanks,
Tom

> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: How to keep PCI-e endpoints and RCs in distinct IOMMU groups?

[Robin Murphy]

Hey Mitch,

On 26/05/16 01:26, Mitchel Humpherys wrote:

Hey there,

We're experiencing an issue with IOMMU groups and PCI-e devices.  The
system in question has a WLAN DMA master behind a PCI-e root complex
which is, in turn, behind an IOMMU.  There are no there devices behind
the RC.  This is on an ARM platform using the arm-smmu and pci-msm
drivers (pci-msm is in the MSM vendor tree, sorry...).

What we're observing is that the WLAN endpoint device is being added to
the same IOMMU group as the root complex device itself.  I don't think
they should be in the same group though, since they each have different
BDFs, which, in our system, are translated to different SMMU Stream IDs,
so their traffic is split onto separate SMMU context banks.  Since their
traffic is isolated from one other I don't think they need to be in the
same IOMMU group (as I understand IOMMU groups).

The result is that when the WLAN driver tries to attach to their IOMMU
it errors out due to the following check in iommu_attach_device:

 if (iommu_group_device_count(group) != 1)
 goto out_unlock;

I've come up with a few hacky workarounds:

   - Forcing PCI-e ACS to be "enabled" unconditionally (even though our
 platform doesn't actually support it).


If the _only_ use of the IOMMU is to allow 32-bit devices to get at 
physically higher RAM without DAC addressing, then perhaps. If system 
integrity matters, though, you're opening up the big hole that Alex 
mentions. I'm reminded of Rob Clark's awesome Fire TV hack for some of 
the dangers of letting DMA-capable devices play together without careful 
supervision...



   - Call iommu_attach_group instead of iommu_attach_device in the arm64
 DMA IOMMU mapping layer (yuck).


That's not yuck, that would be correct, except for the arm64 DMA mapping 
code relying on default domains from the IOMMU core and not calling 
iommu_attach anything :/


If you've not picked 921b1f52c942 into the MSM kernel, please do so and 
fix the fallout in whatever other modifications you have. That dodgy 
workaround was only necessary for the brief window between the DMA 
mapping code and the IOMMU core group rework both landing in 4.4, and 
then hung around unused for far too long, frankly.



   - Don't use the pci_device_group helper at all from the arm-smmu
 driver.  Just allocate a new group for all PCI-e devices.


See point #1.


It seems like the proper solution would be to somehow make these devices
end up in separate IOMMU groups using the existing pci_device_group
helper, since that might be doing useful stuff for other configurations
(like detecting the DMA aliasing quirks).

Looking at pci_device_group, though, I'm not sure how we could tell that
these two devices are supposed to get separated.  I know very little
about PCI-e so maybe I'm just missing something simple.  The match
happens in the following loop where we walk up the PCI-e topology:

 /*
  * Continue upstream from the point of minimum IOMMU granularity
  * due to aliases to the point where devices are protected from
  * peer-to-peer DMA by PCI ACS.  Again, if we find an existing
  * group, use it.
  */
 for (bus = pdev->bus; !pci_is_root_bus(bus); bus = bus->parent) {
 if (!bus->self)
 continue;

 if (pci_acs_path_enabled(bus->self, NULL, REQ_ACS_FLAGS))
 break;

 pdev = bus->self;

 group = iommu_group_get(>dev);
 if (group)
 return group;
 }

Why do we do that?  If the devices have different BDFs can't we safely
say that they're protected from peer-to-peer DMA (assuming no DMA
aliasing quirks)?  Even as I write that out it seems wrong though since
the RC can probably do whatever it wants...


Quite ;)


Maybe the IOMMU framework can't actually know whether the devices should
be kept in separate groups and we just need to do something custom in
the arm-smmu driver?


From my perspective, things are to the contrary - the IOMMU core 
assumes devices should be in separate groups unless it _does_ know 
otherwise, and the ARM SMMU driver is severely lacking in the cases 
where devices do need grouping in ways the core can't discover - I guess 
you've not had the pleasure of watching multiple platform devices on the 
same stream ID blowing up.


I am of course addressing this in my SMMU generic bindings patches (v2 
coming real soon now) - having said which I'm now doing a double-take 
because until that series there are no IOMMU DMA ops for PCI devices and 
no real DMA mapping support for the SMMU, so... how... this would appear 
to be a problem entirely belonging to out-of-tree code :P


Robin.


Sorry for the novel!  Thanks for any pointers.


-Mitch



___
iommu mailing list
iommu@lists.linux-foundation.org

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

[Robin Murphy]

On 25/05/16 22:43, Wei Yang wrote:

On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote:

On 25/05/16 00:06, Wei Yang wrote:

Hi, Joerg

Not sure whether you think this calculation is correct.

If I missed something for this " + 1" in your formula, I am glad to hear your
explanation. So that I could learn something from you :-)


I'm not familiar enough with this aspect of the driver to confirm whether the
change is appropriate or not, but it does seem worth noting that using
DIV_ROUND_UP would be an even neater approach.



Hi, Robin,

Thanks for your comment.

Yes, I agree DIV_ROUND_UP would make the code more easy to read.

I have thought about using DIV_ROUND_UP, while from the definition
DIV_ROUND_UP use operation "/", and ALIGN use bit operation. So the change in
my patch chooses the second one and tries to keep the efficiency.


The efficiency of what, though?

It's an unsigned division by a constant power of two, which GCC 
implements with a shift instruction regardless of optimisation - and at 
-O1 and above the machine code generated for either form of expression 
is completely identical (try it and see!).


On the other hand, the small amount of time and cognitive effort it took 
to parse "ALIGN(x, 256) >> 8" as "divide by 256, rounding up" compared 
to simply seeing "DIV_ROUND_UP(x, 256)" and knowing instantly what's 
intended, certainly makes it less efficient to _maintain_; thus it's 
exactly the kind of thing to which Dijkstra's famous quotation applies.


Does that count towards learning something? ;)

Robin.


Have a good day~

On Sat, May 21, 2016 at 02:41:51AM +, Wei Yang wrote:

In commit <8bf478163e69> ("iommu/vt-d: Split up iommu->domains array"), it
it splits iommu->domains in two levels. Each first level contains 256
entries of second level. In case of the ndomains is exact a multiple of
256, it would have one more extra first level entry for current
implementation.

This patch refines this calculation to reduce the extra first level entry.

Signed-off-by: Wei Yang 
---
drivers/iommu/intel-iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index e3061d3..2204ca4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1634,7 +1634,7 @@ static int iommu_init_domains(struct intel_iommu *iommu)
return -ENOMEM;
}

-   size = ((ndomains >> 8) + 1) * sizeof(struct dmar_domain **);
+   size = (ALIGN(ndomains, 256) >> 8) * sizeof(struct dmar_domain **);
iommu->domains = kzalloc(size, GFP_KERNEL);

if (iommu->domains) {
@@ -1699,7 +1699,7 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
static void free_dmar_iommu(struct intel_iommu *iommu)
{
if ((iommu->domains) && (iommu->domain_ids)) {
-   int elems = (cap_ndoms(iommu->cap) >> 8) + 1;
+   int elems = ALIGN(cap_ndoms(iommu->cap), 256) >> 8;
int i;

for (i = 0; i < elems; i++)
--
1.7.9.5






___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

[Ulf Hansson]

On 26 May 2016 at 06:05, Yangbo Lu  wrote:
> Hi Uffe,
>
> Could we merge this patchset? ...
> It has been a long time to wait for Arnd's response...
>
> Thanks a lot.
>
>

As we are still in the merge window I won't queue anything but fixes.
Let's give Arnd another week or so to respond.

Kind regards
Uffe

> Best regards,
> Yangbo Lu
>
>
>> -Original Message-
>> From: Yangbo Lu
>> Sent: Friday, May 20, 2016 2:06 PM
>> To: 'Scott Wood'; Arnd Bergmann; linux-arm-ker...@lists.infradead.org
>> Cc: linuxppc-...@lists.ozlabs.org; Mark Rutland;
>> devicet...@vger.kernel.org; ulf.hans...@linaro.org; Russell King; Bhupesh
>> Sharma; net...@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
>> m...@vger.kernel.org; linux-ker...@vger.kernel.org; Yang-Leo Li;
>> iommu@lists.linux-foundation.org; Rob Herring; linux-...@vger.kernel.org;
>> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-...@vger.kernel.org;
>> Qiang Zhao
>> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> Hi Arnd,
>>
>> Any comments?
>> Please reply when you see the email since we want this eSDHC issue to be
>> fixed soon.
>>
>> All the patches are Freescale-specific and is to fix the eSDHC driver.
>> Could we let them merged first if you were talking about a new way of
>> abstracting getting SoC version.
>>
>>
>> Thanks :)
>>
>>
>> Best regards,
>> Yangbo Lu
>>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu