On Wed, Jul 9, 2014 at 8:03 PM, Olav Haugan wrote:
> On 7/8/2014 4:49 PM, Rob Clark wrote:
>> On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan wrote:
>>> Hi Hiroshi,
>>>
>>> On 7/3/2014 9:29 PM, Hiroshi Doyu wrote:
Hi Olav,
Olav Haugan writes:
> Mapping and unmapping are more
On 5/15/2014 7:40 PM, Laurent Pinchart wrote:
> Cache the micro-TLB number in archdata allocated in the .add_device
> handler instead of looking it up when the deviced is attached and
> detached. This simplifies the .attach_dev and .detach_dev operations and
> prepares for DT support.
[snip]
> Sign
On 7/8/2014 4:49 PM, Rob Clark wrote:
> On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan wrote:
>> Hi Hiroshi,
>>
>> On 7/3/2014 9:29 PM, Hiroshi Doyu wrote:
>>> Hi Olav,
>>>
>>> Olav Haugan writes:
>>>
Mapping and unmapping are more often than not in the critical path.
map_range and unmap_r
Hi Laurent,
Thanks for your explanation.
I'm fine with current situation.
I have also checked other drivers and they did the same.
As you said, let's improve this driver when the time comes.
Thanks.
Best regards,
KHIEM Nguyen
On 6/4/2014 2:39 AM, Laurent Pinchart wrote:
> Hi,
>
> On Tuesday
On Wed, 2014-07-09 at 19:28 +0100, Will Deacon wrote:
> Hello,
>
> This is v2 of the RFC I originally posted here:
>
> RFCv1: http://permalink.gmane.org/gmane.linux.kernel.iommu/5552
>
> It's changed significantly since then, based on helpful feedback from
> Alex. In particular, I no longer but
Hello,
This is v2 of the RFC I originally posted here:
RFCv1: http://permalink.gmane.org/gmane.linux.kernel.iommu/5552
It's changed significantly since then, based on helpful feedback from
Alex. In particular, I no longer butcher the IOMMU API, instead making
use of a new iommu_attr to indicate
When domains are set with the DOMAIN_ATTR_NESTING flag, we must ensure
that we allocate them to stage-2 context banks if the hardware permits
it.
This patch adds support for the attribute to the ARM SMMU driver, with
the actual stage being determined depending on the features supported
by the hard
Some IOMMUs, such as the ARM SMMU, support two stages of translation.
The idea behind such a scheme is to allow a guest operating system to
use the IOMMU for DMA mappings in the first stage of translation, with
the hypervisor then installing mappings in the second stage to provide
isolation of the
VFIO allows devices to be safely handed off to userspace by putting
them behind an IOMMU configured to ensure DMA and interrupt isolation.
This enables userspace KVM clients, such as kvmtool and qemu, to further
map the device into a virtual machine.
With IOMMUs such as the ARM SMMU, it is then po
Hi Thierry,
On Wed, Jul 09, 2014 at 03:21:27PM +0100, Thierry Reding wrote:
> On Wed, Jul 09, 2014 at 02:40:50PM +0100, Will Deacon wrote:
> > I would like to move the ARM SMMU driver over to this for 3.18, if possible.
> > One use-case there is the ability to describe groups of masters behind a
>
On Wed, Jul 09, 2014 at 03:13:04PM +0100, Alex Williamson wrote:
> On Wed, 2014-07-09 at 14:26 +0100, Will Deacon wrote:
> > [Adding Alex; question below]
> >
> > On Thu, Jul 03, 2014 at 03:22:37PM +0100, Varun Sethi wrote:
> > > > +static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias
On Tue, Jul 8, 2014 at 6:26 AM, Alexander Gordeev wrote:
> On Mon, Jul 07, 2014 at 01:40:48PM -0600, Bjorn Helgaas wrote:
>> >> Can you quantify the benefit of this? Can't a device already use
>> >> MSI-X to request exactly the number of vectors it can use? (I know
>> >
>> > A Intel AHCI chipset
On Wed, Jul 09, 2014 at 02:40:50PM +0100, Will Deacon wrote:
> On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This commit introduces a generic device tree binding for IOMMU devices.
> > Only a very minimal subset is described here, but it is enoug
Hi Will,
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Wednesday, July 09, 2014 6:57 PM
> To: Sethi Varun-B16395; alex.william...@redhat.com
> Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-
> foundation.org; thierry.red...@gmail.com; a...@arndb
On Wed, 2014-07-09 at 14:26 +0100, Will Deacon wrote:
> [Adding Alex; question below]
>
> On Thu, Jul 03, 2014 at 03:22:37PM +0100, Varun Sethi wrote:
> > > +static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void
> > > +*data) {
> > > + *((u16 *)data) = alias;
> > > + retu
On Tue, Jul 08, 2014 at 05:30:16PM +0300, Oded Gabbay wrote:
> From: Alexey Skidanov
>
> The pasid wasn't properly initialized before caling to invalid PPR calback
>
> Signed-off-by: Alexey Skidanov
> Signed-off-by: Oded Gabbay
> ---
> drivers/iommu/amd_iommu_v2.c | 1 +
> 1 file changed, 1 i
On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra S
[Adding Alex; question below]
On Thu, Jul 03, 2014 at 03:22:37PM +0100, Varun Sethi wrote:
> > +static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void
> > +*data) {
> > + *((u16 *)data) = alias;
> > + return 0; /* Continue walking */
> > +}
[...]
> > @@ -1598,15 +1642,36
On Wed, Jul 09, 2014 at 02:07:38AM +0100, Olav Haugan wrote:
> On 6/30/2014 2:52 AM, Will Deacon wrote:
> > On Fri, Jun 27, 2014 at 11:23:27PM +0100, Olav Haugan wrote:
> >> Lets say I have an IOMMU with 2 masters and 2 SMRn slots with the
> >> following stream IDs coming from the masters:
> >>
> >
On Tue, Jul 08, 2014 at 05:52:18PM +0100, Mitchel Humpherys wrote:
> Fix some issues reported by checkpatch.pl. Mostly whitespace, but also
> includes min=>min_t, kzalloc=>kcalloc, and kmalloc=>kmalloc_array.
Cheers, applied. I dropped the big list of things you fixed and just kept
the one you lef
20 matches
Mail list logo
