> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, December 16, 2016 10:50 AM
> To: Stuart Yoder ; Mark Rutland
> Cc: will.dea...@arm.com; robh...@kernel.org; Bharat Bhushan
> ; Nipun Gupta
> ; Diana Madalina Craciun ;
> de
> >>> The existing iommu-map binding did not account for the situation where
> >>> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
> >>> of the IOMMU specifier being the SMR mask. The existing binding defines
> >>> the mapping as:
> >>>Any RID r in the interval [rid-base
> -Original Message-
> From: Bharat Bhushan
> Sent: Thursday, December 15, 2016 9:46 PM
> To: Stuart Yoder ; Mark Rutland ;
> robin.mur...@arm.com;
> will.dea...@arm.com
> Cc: robh...@kernel.org; Nipun Gupta ; Diana Madalina
> Craciun
> ; devicet..
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Friday, December 16, 2016 5:39 AM
> To: Stuart Yoder
> Cc: robin.mur...@arm.com; will.dea...@arm.com; robh...@kernel.org; Bharat
> Bhushan
> ; Nipun Gupta ; Diana Madalina
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Friday, December 16, 2016 5:33 AM
> To: Stuart Yoder
> Cc: robh...@kernel.org; devicet...@vger.kernel.org;
> linux-ker...@vger.kernel.org; j...@8bytes.org;
> iommu@lists.linux-fou
For context, please see the thread:
https://www.spinics.net/lists/arm-kernel/msg539066.html
The existing iommu-map binding did not account for the situation where
#iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
of the IOMMU specifier being the SMR mask. The existing binding
references to iommu-specifier to
"IOMMU specifier" so we are 100% consistent everywhere with terminology
and capitalization.
Signed-off-by: Stuart Yoder
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 10 +-
Documentation/devicetree/bindings/pci/pci-iommu.txt |
> -Original Message-
> From: Nipun Gupta [mailto:nipun.gu...@nxp.com]
> Sent: Thursday, November 03, 2016 7:27 PM
> To: robin.mur...@arm.com; will.dea...@arm.com;
> linux-arm-ker...@lists.infradead.org; iommu@lists.linux-
> foundation.org
> Cc: Stuart Yoder ; N
> -Original Message-
> From: Stuart Yoder
> Sent: Friday, October 28, 2016 12:12 PM
> To: 'Robin Murphy' ; Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org; Will Deacon ;
> Diana Madalina Craciun
> ; Nipun Gupta ;
> iommu@lists.linux-foundat
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, October 28, 2016 11:17 AM
> To: Stuart Yoder ; Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org; Will Deacon ;
> Diana Madalina Craciun
> ; Nipun Gupta ;
> iommu@li
Hi Robin,
A question about how the SMR masking defined in the arm,smmu binding
relates to the PCI iommu-map.
The #iommu-cells property defines the number of cells an "IOMMU specifier"
takes and 2 is specified to be:
SMMUs with stream matching support and complex masters
may use a value of
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, July 01, 2016 12:40 PM
> To: Stuart Yoder
> Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC 1/2] iommu/dma: Restrict IOVAs to phys
> -Original Message-
> From: Robin Murphy
> Date: Tue, Jun 28, 2016 at 11:18 AM
> Subject: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout
> To: iommu@lists.linux-foundation.org, linux-arm-ker...@lists.infradead.org
>
>
> Certain peripherals may be bestowed with knowledge
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Tuesday, June 21, 2016 4:43 AM
> To: Robin Murphy
> Cc: Stuart Yoder ;
> linux-arm-ker...@lists.infradead.org; iommu@lists.linux-
> foundation.org; Nipun Gupta ; Bharat Bhushan
> ; Br
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Monday, June 20, 2016 11:09 AM
> To: Stuart Yoder ; Will Deacon
> Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-foundation.org;
> Nipun Gupta
> ; Bharat Bhushan ; Brian
Robin/Will,
Right now the SMMU driver is hardcoded to configure 'stall' mode for
context faults:
/* SCTLR */
reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
We are running into an issue with a device where it seems behave sanely
when SCTLR_CFCFG=0 ...i.e. 'ter
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Thursday, February 18, 2016 10:22 AM
> To: Stuart Yoder
> Cc: j...@8bytes.org; robin.mur...@arm.com; iommu@lists.linux-foundation.org;
> linux-arm-
> ker...@lists.infradead.org; Varun S
Hi Joerg and Will,
We are implementing support for some specialized NXP SoC network
devices and have the desire to extend the mapping attributes beyond
those currently in iommu.h. (I see there is a recent proposal to
add an IOMMU_MMIO flag)
What we have right now in Linux is a least-common-denomi
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Monday, September 07, 2015 1:05 PM
> To: David Daney
> Cc: Marc Zyngier; tirumalesh.chalama...@caviumnetworks.com; Richter, Robert;
> Chintakuntla, Radha;
> devicet...@vger.kernel.org; linux-ker...@vger.kernel
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Thursday, August 06, 2015 1:15 PM
> To: Yoder Stuart-B08248; Marc Zyngier; Will Deacon
> Cc: devicet...@vger.kernel.org; Lorenzo Pieralisi; a...@arndb.de;
> linux-ker...@vger.kernel.org;
> dda...@caviumnetwor
> From: Mark Rutland
> Date: Thu, Jul 23, 2015 at 11:52 AM
[cut]
> diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt
> b/Documentation/devicetree/bindings/pci/pci-msi.txt
> new file mode 100644
> index 000..9b3cc81
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pc
On Fri, May 8, 2015 at 10:49 AM, Will Deacon wrote:
> Hi Stuart,
>
> On Thu, May 07, 2015 at 06:49:32PM +0100, Stuart Yoder wrote:
>> On Tue, Mar 24, 2015 at 10:50 AM, Mark Rutland wrote:
>> > Hi all,
>> >
>> > For some devices, identification of pa
On Tue, Mar 24, 2015 at 10:50 AM, Mark Rutland wrote:
> Hi all,
>
> For some devices, identification of particular masters is critical to
> their operation (e.g. IOMMUs, MSI controllers). The identity of masters
> is determined from sideband signals on the bus, and it may or may not be
> possible
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Wednesday, April 15, 2015 11:18 AM
> To: Sethi Varun-B16395
> Cc: Baptiste Reynal; Linux IOMMU; Yoder Stuart-B08248
> Subject: Re: SMMU 2-stage support
>
> On Tue, Apr 14, 2015 at 02:32:26PM +0100, Varun Sethi
> -Original Message-
> From: Sethi Varun-B16395
> Sent: Tuesday, June 17, 2014 6:22 AM
> To: Will Deacon
> Cc: Mark Rutland; devicet...@vger.kernel.org; linux-samsung-
> s...@vger.kernel.org; Arnd Bergmann; Pawel Moll; Ian Campbell; Grant
> Grundler; Stephen Warren; Yoder Stuart-B08248; R
ker...@vger.kernel.org; Marc Zyngier; Linux IOMMU; Rob
> Herring;
> > > Kumar Gala; linux-te...@vger.kernel.org; Cho KyongHo; Dave P Martin;
> > > linux-arm- ker...@lists.infradead.org
> > > Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree
> > > bi
ee: Add generic IOMMU device tree
> bindings
>
> Hi Stuart,
>
> On Mon, Jun 16, 2014 at 05:56:32PM +0100, Stuart Yoder wrote:
> > > Do you have use-cases where you really need to change these mappings
> > > dynamically?
> >
> > Yes. In the case of a PCI
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Monday, June 16, 2014 10:28 AM
> To: Sethi Varun-B16395
> Cc: Thierry Reding; Mark Rutland; devicet...@vger.kernel.org; linux-
> samsung-...@vger.kernel.org; Pawel Moll; Arnd Bergmann; Ian Campbell;
> Grant Grun
d-off-by: Kim Phillips
> ---
> changes in v2 patch of v5 of this patchseries:
> - rebased onto today's Linus' ToT
> - added kfree to match PCI counterpart fix, as Alex Williamson
> just posted a v3 of the patch (thanks Christoffer for the
> notification)
> - in the commit
> Another advantage to this approach is that we can specify a driver
> override to force a specific binding or prevent any binding. For
> instance when an IOMMU group is exposed to userspace through VFIO
> we require that all devices within that group are owned by VFIO.
> However, devices can be h
ci-introduce-new-
> device-binding-path-using-pci_dev-driver_override.html
>
> Suggested-by: Alex Williamson
> Signed-off-by: Kim Phillips
> ---
Reviewed-by: Stuart Yoder
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
uot;) or perhaps have it automatically bind to vfio-pci.
> With driver_override it's a simple matter for this field to be set
> internally when the device is first discovered to prevent driver
> matches.
>
> Signed-off-by: Alex Williamson
> ---
Reviewed-by: Stuart Yoder
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
linux-foundation.org; Joe Perches;
> christoffer.d...@linaro.org
> Subject: Re: mechanism to allow a driver to bind to any device
>
> On Mon, Mar 31, 2014 at 06:47:51PM +, Stuart Yoder wrote:
> > I also, was at the point where I thought we should perhaps just
> > go with
; > > > Am 26.03.2014 um 22:40 schrieb Konrad Rzeszutek Wilk
> :
> > > >
> > > >> On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote:
> > > >> Hi Greg,
> > > >>
> > > >> We (Linaro, Freescale, Virtual Open Systems) are trying
lk
> :
> > >
> > >> On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote:
> > >> Hi Greg,
> > >>
> > >> We (Linaro, Freescale, Virtual Open Systems) are trying get an issue
> > >> closed that has been per
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, March 28, 2014 2:00 AM
> To: Antonios Motakis
> Cc: Yoder Stuart-B08248; alex.william...@redhat.com;
> kvm...@lists.cs.columbia.edu; iommu@lists.linux-foundation.org; linux-
> ker...@vger.kernel.org;
> The other option for this is to having some sort of priority on the
> device probing with hotplugging.
>
> That is you can could do the following:
>
> 1) add the device vendor/model in vfio
> 2) unbind the BDF from the original driver.
> 3) hotplug happens - any new device that has the devic
> foundation.org; Joe Perches; christoffer.d...@linaro.org
> Subject: Re: mechanism to allow a driver to bind to any device
>
> On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote:
> > Hi Greg,
> >
> > We (Linaro, Freescale, Virtual Open Systems) are trying g
Hi Greg,
We (Linaro, Freescale, Virtual Open Systems) are trying get an issue
closed that has been perculating for a while around creating a mechanism
that will allow kernel drivers like vfio can bind to devices of any type.
This thread with you:
http://www.spinics.net/lists/kvm-arm/msg08370.html
a...@arm.com; Tejun Heo; Rafael J. Wysocki; Guenter Roeck;
> Toshi Kani; Joe Perches; Dmitry Kasatkin; Michal Hocko; Bjorn Helgaas
> Subject: Re: [RFC PATCH v4 01/10] driver core: export
> driver_probe_device()
>
> On Thu, Feb 20, 2014 at 10:34:35PM +, Stuart Yoder wrote:
> >
i; Guenter
> Roeck;
> > Toshi Kani; Joe Perches; Dmitry Kasatkin; Michal Hocko; Bjorn Helgaas
> > Subject: Re: [RFC PATCH v4 01/10] driver core: export
> > driver_probe_device()
> >
> > On Sat, Feb 15, 2014 at 04:33:44PM +, Stuart Yoder wrote:
a...@arm.com; Tejun Heo; Rafael J. Wysocki; Guenter Roeck;
> Toshi Kani; Joe Perches; Dmitry Kasatkin; Michal Hocko; Bjorn Helgaas
> Subject: Re: [RFC PATCH v4 01/10] driver core: export
> driver_probe_device()
>
> On Sat, Feb 15, 2014 at 04:33:44PM +, Stuart Yoder wrote:
> &
> > Why? driver_probe_device() allows a driver to explicitly bind
> > to a specific device. What is conceptually wrong with allowing
> > that?
>
> Because that's not how a bus should work, and the fact that no other
> subsystem in the kernel does that might be a hint you are trying to do
> some
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, February 14, 2014 4:27 PM
> To: Antonios Motakis
> Cc: alex.william...@redhat.com; kvm...@lists.cs.columbia.edu;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> t...@virtualopensys
>>> I will look into this. However, can we rely to have access to all
>>> device resources through platform abstractions, for every type of
>>> platform device
>>
>> The only resources we care about in vfio are mappable regions
>> and irqs. So, yes I think we can rely on access to those
>> resourc
On Wed, Apr 3, 2013 at 2:18 PM, Scott Wood wrote:
> On 04/03/2013 02:09:45 PM, Stuart Yoder wrote:
>>
>> > Would is be possible for userspace to simply leave room for MSI bank
>> > mapping (how much room could be determined by something like
>> > VFIO_IOMMU_G
> Would is be possible for userspace to simply leave room for MSI bank
> mapping (how much room could be determined by something like
> VFIO_IOMMU_GET_MSI_BANK_COUNT) then document the API that userspace can
> DMA_MAP starting at the 0x0 address of the aperture, growing up, and
> VFIO will map bank
On Tue, Apr 2, 2013 at 5:50 PM, Scott Wood wrote:
> On 04/02/2013 04:38:45 PM, Alex Williamson wrote:
>>
>> On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
>> > On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
>> > wrote:
>> > >> >C. Expli
>> > Type1 is arbitrary. It might as well be named "brown" and this one
>> > can be
>> > "blue".
>>
>> The difference is that "type1" seems to refer to hardware that can do
>> arbitrary 4K page mappings, possibly constrained by an aperture but
>> nothing else. More than one IOMMU can reasonably
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood wrote:
>> This could also be done as another "type2" ioctl extension.
>
>
> Again, what is "type2", specifically? If someone else is adding their own
> IOMMU that is kind of, sort of like PAMU, how would they know if it's close
> enough? What assumption
On Tue, Apr 2, 2013 at 3:47 PM, Scott Wood wrote:
> On 04/02/2013 03:38:42 PM, Stuart Yoder wrote:
>>
>> On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood
>> wrote:
>> > On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
>> >>
>> >> Alex,
>
On Tue, Apr 2, 2013 at 3:32 PM, Alex Williamson
wrote:
>> 2. MSI window mappings
>>
>>The more problematic question is how to deal with MSIs. We need to
>>create mappings for up to 3 MSI banks that a device may need to target
>>to generate interrupts. The Linux MSI driver can alloc
On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood wrote:
> On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
>>
>> Alex,
>>
>> We are in the process of implementing vfio-pci support for the Freescale
>> IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite different
>> than x86, and will i
On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi wrote:
[cut]
> +static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain, unsigned
> long iova)
> +{
> + u32 win_cnt = dma_domain->win_cnt;
> + struct dma_window *win_ptr =
> + &dma_domain->win_arr[0]
Some more comments...
On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi wrote:
> +/* Handling access violations */
> +#define make64(high, low) (((u64)(high) << 32) | (low))
> +
> +struct pamu_isr_data {
> + void __iomem *pamu_reg_base;/* Base address of PAMU regs*/
> + unsigned int co
Have not got through the entire file, but have a few comments...
+/*
+ * Set the PAACE type as primary and set the coherency required domain
+ * attribute
+ */
+static void pamu_setup_default_xfer_to_host_ppaace(struct paace *ppaace)
+{
+ set_bf(ppaace->addr_bitfields, PAACE_AF_PT, PAACE_PT_
This patch was submitted separately to linuxppc-dev (and was already
applied). You don't need it in this patch set, right?
Stuart
On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi wrote:
> The pci controller structure has a provision to store the device strcuture
> pointer of the corresponding platf
Joerg,
The attributes you have defined look good and are mechanisms we need
to determine if iommu is aperture based, get max # of windows, set
actual number of windows, etc.
However, there are a couple of other attributes we need:
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index
On Mon, Feb 4, 2013 at 12:56 PM, Joerg Roedel wrote:
> On Mon, Feb 04, 2013 at 12:10:51PM -0600, Stuart Yoder wrote:
>> On Mon, Feb 4, 2013 at 7:18 AM, Joerg Roedel wrote:
>> > +static inline int iommu_domain_window_enable(struct io
On Mon, Feb 4, 2013 at 7:18 AM, Joerg Roedel wrote:
> Add the iommu_domain_window_enable() and iommu_domain_window_disable()
> functions to the IOMMU-API. These functions will be used to setup
> domains that are based on subwindows and not on paging.
>
> Signed-off-by: Joerg Roedel
> ---
> drive
60 matches
Mail list logo
