Mark Rutland wrote @ Thu, 31 Oct 2013 18:31:33 +0100:
> > Assuming "swgroup" is "memory client ID", why can't the driver just
> > create a list/... of known swgroups at runtime, based on the swgroup
> > values that each device uses, which would presumably be either
> > hard-coded in the client de
> > The ARM SMMU refers to these as "stream IDs", as that's the architected name
> > that appears in all the hardware documentation. If "swgroup" is the term
> > used
> > in the hardware documentation I think it makes sense to stick with it, as
> > long
> > as there's a description in the binding
On Thu, 31 Oct 2013 18:40:29 +0100
Mark Rutland wrote:
> For the ARM SMMU binding, each device has a #stream-id-cells property
> describing how many IDs it has, and then the SMMU node has a phandle+args
> linkage to each of the devices attached to it, describing their stream IDs.
> While this doe
On Thu, 31 Oct 2013 20:16:18 +0100
Stephen Warren wrote:
> Hmm. That's interesting. I see that the ARM SMMU has a list of the
> clients it affects, whereas this Tegra series puts information into each
> client device about the SMMU(s) that affect it. Is it better to flip the
> Tegra binding aroun
On Thu, 31 Oct 2013 20:39:41 +0100
Will Deacon wrote:
> On Thu, Oct 31, 2013 at 07:25:25PM +, Stephen Warren wrote:
> > On 10/31/2013 01:16 PM, Stephen Warren wrote:
> > > Hmm. That's interesting. I see that the ARM SMMU has a list of the
> > > clients it affects, whereas this Tegra series pu
On Thu, 31 Oct 2013 18:46:06 +0100
Mark Rutland wrote:
> On Thu, Oct 31, 2013 at 08:19:42AM +, Hiroshi Doyu wrote:
> > Stephen Warren wrote @ Wed, 30 Oct 2013 23:48:38
> > +0100:
> >
> > > On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> > > > Create a header file to define the swgroup IDs us
On Thu, Oct 31, 2013 at 11:53:22AM -0600, Stephen Warren wrote:
> On 10/31/2013 10:46 AM, Hiroshi Doyu wrote:
> > Stephen Warren wrote @ Thu, 31 Oct 2013 17:35:24
> > +0100:
> >
> > ...
> ... and for the driver to explicitly parse that property, and wait
> until the driver for iommu_ph
On Fri, Nov 01, 2013 at 08:49:09AM +0200, Hiroshi Doyu wrote:
> On Thu, 31 Oct 2013 18:53:22 +0100
> Stephen Warren wrote:
> ...
> > We're talking about memory-mapped on-SoC devices here, that generally
> > only exist inside Tegra SoCs.
> >
> > Even ignoring that (i.e. expanding the argument to a
On Thu, Oct 31, 2013 at 10:37:40AM -0600, Stephen Warren wrote:
> On 10/31/2013 02:14 AM, Hiroshi Doyu wrote:
> > Thierry Reding wrote @ Wed, 30 Oct 2013 23:41:09
> > +0100:
> >
> >> My earlier proposal for deferred interrupt reference resolution actually
> >> tries to solve that problem within
Thierry Reding wrote @ Fri, 1 Nov 2013 10:46:45
+0100:
> * PGP Signed by an unknown key
>
> On Thu, Oct 31, 2013 at 11:53:22AM -0600, Stephen Warren wrote:
> > On 10/31/2013 10:46 AM, Hiroshi Doyu wrote:
> > > Stephen Warren wrote @ Thu, 31 Oct 2013 17:35:24
> > > +0100:
> > >
> > > ...
> >
Thierry Reding wrote @ Fri, 1 Nov 2013 10:52:24
+0100:
> * PGP Signed by an unknown key
>
> On Fri, Nov 01, 2013 at 08:49:09AM +0200, Hiroshi Doyu wrote:
> > On Thu, 31 Oct 2013 18:53:22 +0100
> > Stephen Warren wrote:
> > ...
> > > We're talking about memory-mapped on-SoC devices here, that g
Thierry Reding wrote @ Fri, 1 Nov 2013 10:53:50
+0100:
> * PGP Signed by an unknown key
>
> On Thu, Oct 31, 2013 at 10:37:40AM -0600, Stephen Warren wrote:
> > On 10/31/2013 02:14 AM, Hiroshi Doyu wrote:
> > > Thierry Reding wrote @ Wed, 30 Oct 2013
> > > 23:41:09 +0100:
> > >
> > >> My earl
Hi Will,
On Thu, Oct 31, 2013 at 12:59:02AM +, Will Deacon wrote:
> Could you pull this please, Joerg? It would be good to have this in next
> before the merge window...
Just pulled. Sorry for the long delay.
Joerg
___
iommu mailing list
On Mon, Oct 07, 2013 at 10:52:12AM +0900, Cho KyongHo wrote:
> Patch summary:
> [PATCH 01/20] iommu/exynos: do not include removed header
> [PATCH 02/20] iommu/exynos: add missing cache flush for removed page table
> entries
> [PATCH 03/20] iommu/exynos: change error handling when page table updat
On Wed, Oct 09, 2013 at 10:03:52AM +0200, Julian Stecklina wrote:
> The BUG_ON in drivers/iommu/intel-iommu.c:785 can be triggered from userspace
> via
> VFIO by calling the VFIO_IOMMU_MAP_DMA ioctl on a vfio device with any address
> beyond the addressing capabilities of the IOMMU. The problem is
On Fri, 01 Nov 2013 12:42:24 +0100, Joerg Roedel wrote:
> On Mon, Oct 07, 2013 at 10:52:12AM +0900, Cho KyongHo wrote:
> > Patch summary:
> > [PATCH 01/20] iommu/exynos: do not include removed header
> > [PATCH 02/20] iommu/exynos: add missing cache flush for removed page table
> > entries
> > [PA
Hi Peter,
On Fri, Nov 01, 2013 at 01:37:36PM +0100, Peter Senna Tschudin wrote:
> I have one notebook that is failing to resume after suspend to ram.
> I've filled a bug report back on the 2.6.41 days:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=787299
>
> The issue is that trying to resume
Hi Cho,
On Fri, Nov 01, 2013 at 09:37:45PM +0900, Cho KyongHo wrote:
> I am preparing next patches to apply Alex Williamson's comment that
> description of IOMMU's masters must be aligned with ARM SMMU.
>
> It is delayed due to my jobs in the office.
>
> I will post the next patche series in two
On Thu, Oct 31, 2013 at 05:25:16PM +0800, Yijing Wang wrote:
> Use for_each_drhd_unit() instead of list_for_each_entry for
> better readability.
>
> Signed-off-by: Yijing Wang
Applied both, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.
On Tue, Oct 08, 2013 at 04:21:03PM +0530, Sachin Kamat wrote:
> 'tegra_gart_pm_ops' is local to this file. Make it static.
>
> Signed-off-by: Sachin Kamat
Applied both, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.lin
On Fri, 01 Nov 2013 14:10:47 +0100, Joerg Roedel wrote:
> Hi Cho,
>
> On Fri, Nov 01, 2013 at 09:37:45PM +0900, Cho KyongHo wrote:
> > I am preparing next patches to apply Alex Williamson's comment that
> > description of IOMMU's masters must be aligned with ARM SMMU.
> >
> > It is delayed due to
On Tue, Oct 29, 2013 at 11:37:40PM +0100, Laurent Pinchart wrote:
> Renesas ARM platforms are transitioning from single-platform to
> multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
> driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
> and ARCH_SHMOBILE_MUL
On Fri, Nov 01, 2013 at 02:21:07PM +0100, Peter Senna Tschudin wrote:
> On Fri, Nov 1, 2013 at 2:07 PM, Joerg Roedel wrote:
> > Which kernels have you tried? Does it happen with all of them or is
> > there a kernel-version where this started?
>
> I'm using 3.11.6-200.fc19.x86_64. I always had VT-
On Fri, Nov 01, 2013 at 04:47:47PM +0100, Peter Senna Tschudin wrote:
> Only serial ports over USB:
> usb 2-1.3.2: pl2303 converter now attached to ttyUSB0
>
> The issue with no_console_suspend is that the monitor is powered off
> on suspend and never resume after that. The external monitor enters
On 11/01/2013 02:06 AM, Hiroshi Doyu wrote:
> On Thu, 31 Oct 2013 18:46:06 +0100
> Mark Rutland wrote:
>
>> On Thu, Oct 31, 2013 at 08:19:42AM +, Hiroshi Doyu wrote:
>>> Stephen Warren wrote @ Wed, 30 Oct 2013 23:48:38
>>> +0100:
>>>
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Cr
On 10/31/2013 01:39 PM, Will Deacon wrote:
> On Thu, Oct 31, 2013 at 07:25:25PM +, Stephen Warren wrote:
>> On 10/31/2013 01:16 PM, Stephen Warren wrote:
>>> Hmm. That's interesting. I see that the ARM SMMU has a list of the
>>> clients it affects, whereas this Tegra series puts information int
When determining the page size we could use to map with the IOMMU, the
page size should be aligned with the hva, not the gfn. The gfn may not
reflect the real alignment within the hugetlbfs file.
Most of the time, this works fine. However, if the hugetlbfs file is
backed by non-contiguous huge p
On Fri, Nov 01, 2013 at 04:08:52PM +, Stephen Warren wrote:
> On 10/31/2013 01:39 PM, Will Deacon wrote:
> > On Thu, Oct 31, 2013 at 07:25:25PM +, Stephen Warren wrote:
> >> On 10/31/2013 01:16 PM, Stephen Warren wrote:
> >>> Hmm. That's interesting. I see that the ARM SMMU has a list of th
On 10/31/2013 02:17 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 23:33:32
> +0100:
...
> Right.
> "memory client ID" is used to find out MC_SMMU__ASID_0
> register. This register is used to associate to address
> space(AS). == H/W. can be attached to any AS.
>
>> Is "swgr
On 10/31/2013 02:16 AM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 23:15:00
> +0100:
>
>> On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
>>> SMMU expects ARM_DMA_USE_IOMMU to be enabled to use DMA mapping API by
>>> default.
>>
>> Is the select required for the driver to be usefu
On 11/01/2013 10:34 AM, Will Deacon wrote:
> On Fri, Nov 01, 2013 at 04:08:52PM +, Stephen Warren wrote:
>> On 10/31/2013 01:39 PM, Will Deacon wrote:
>>> On Thu, Oct 31, 2013 at 07:25:25PM +, Stephen Warren wrote:
On 10/31/2013 01:16 PM, Stephen Warren wrote:
> Hmm. That's interes
On 11/01/2013 10:34 AM, Will Deacon wrote:
> On Fri, Nov 01, 2013 at 04:08:52PM +, Stephen Warren wrote:
>> On 10/31/2013 01:39 PM, Will Deacon wrote:
>>> On Thu, Oct 31, 2013 at 07:25:25PM +, Stephen Warren wrote:
On 10/31/2013 01:16 PM, Stephen Warren wrote:
> Hmm. That's interes
On Tue, Oct 29, 2013 at 05:19:43PM -0600, Greg Edwards wrote:
> On Mon, Oct 28, 2013 at 12:37:56PM -0700, Greg Edwards wrote:
> > Using KVM PCI assignment with 1 GiB huge pages trips a BUG in 3.12.0-rc7,
> > e.g.
> >
> > # qemu-system-x86_64 \
> > -m 8192 \
> > -mem-path /var/lib/hugetlbfs
On Fri, Nov 01, 2013 at 10:47:35AM -0700, Marcelo Tosatti wrote:
> On Tue, Oct 29, 2013 at 05:19:43PM -0600, Greg Edwards wrote:
>> On Mon, Oct 28, 2013 at 12:37:56PM -0700, Greg Edwards wrote:
>>> Using KVM PCI assignment with 1 GiB huge pages trips a BUG in 3.12.0-rc7,
>>> e.g.
>>>
>>> # qemu-sy
On 11/01/2013 12:49 AM, Hiroshi Doyu wrote:
> On Thu, 31 Oct 2013 18:53:22 +0100
> Stephen Warren wrote:
> ...
>> We're talking about memory-mapped on-SoC devices here, that generally
>> only exist inside Tegra SoCs.
>>
>> Even ignoring that (i.e. expanding the argument to arbitrary modules),
>> h
On 11/01/2013 03:59 AM, Hiroshi Doyu wrote:
...
> One idea is that, rather than inserting a hook(function) per
> subsystems in driver core, if we invent a new /special section/ which
> collects all hooks in sequence like initcalls, the subsystem just
> would declare a hook function for that special
On Fri, Nov 01, 2013 at 10:08:55AM -0600, Greg Edwards wrote:
> When determining the page size we could use to map with the IOMMU, the
> page size should be aligned with the hva, not the gfn. The gfn may not
> reflect the real alignment within the hugetlbfs file.
>
> Most of the time, this works
On Fri, Nov 01, 2013 at 12:01:26PM -0600, Greg Edwards wrote:
> >> Is it expected the same pages might be mapped in multiple memslots? I
> >> noticed the gfn overlap check in __kvm_set_memory_region().
> >>
> >> It appears pfn_to_dma_pte() is behaving as expected, given half the huge
> >> page is
intel_iommu_iova_to_phys returns incorrect physical address
when iova is translated by large pte.
Fill in bits from iova when creating the physical address.
Signed-off-by: Marcelo Tosatti
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 15e9b57..f8f2988 100644
---
39 matches
Mail list logo
