Re: [PATCHv4 5/7] iommu/tegra: smmu: Support "mmu-masters" binding
On Nov 11, 2013, at 2:31 AM, Hiroshi Doyu wrote:
> Follow arm,smmu's "mmu-masters" binding.
>
> Signed-off-by: Hiroshi Doyu
> ---
> Update:
> Newly added for v4. In v3, I used "nvidia,swgroups" and
> "nvidia,memory-clients" bindings.
> ---
> .../bindings/iommu/nvidia,tegra30-smmu.txt | 28 -
> drivers/iommu/tegra-smmu.c | 138 +
> 2 files changed, 141 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> index 89fb543..51884e9 100644
> --- a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> @@ -8,9 +8,16 @@ Required properties:
> - nvidia,#asids : # of ASIDs
> - dma-window : IOVA start address and length.
> - nvidia,ahb : phandle to the ahb bus connected to SMMU.
> +- mmu-masters : A list of phandles to device nodes representing bus
> + masters for which the SMMU can provide a translation
> + and their corresponding StreamIDs (see example below).
> + Each device node linked from this list must have a
> + "#stream-id-cells" property, indicating the number of
> + StreamIDs(swgroup ID) associated with it, which is defined
> + in "include/dt-bindings/memory/tegra-swgroup.h".
>
> Example:
> - smmu {
> + iommu {
> compatible = "nvidia,tegra30-smmu";
> reg = <0x7000f010 0x02c
> 0x7000f1f0 0x010
> @@ -18,4 +25,23 @@ Example:
> nvidia,#asids = <4>;/* # of ASIDs */
> dma-window = <0 0x4000>;/* IOVA start & length */
> nvidia,ahb = <&ahb>;
> +
> + mmu-masters = <&host1x TEGRA_SWGROUP_HC>,
> + <&mpe TEGRA_SWGROUP_MPE>,
> + <&vi TEGRA_SWGROUP_VI>,
> + <&epp TEGRA_SWGROUP_EPP>,
> + <&isp TEGRA_SWGROUP_ISP>,
> + <&gr2d TEGRA_SWGROUP_G2>,
> + <&gr3d TEGRA_SWGROUP_NV TEGRA_SWGROUP_NV2>,
> + <&dc TEGRA_SWGROUP_DC>,
> + <&dcb TEGRA_SWGROUP_DCB>,
> + <&uarta TEGRA_SWGROUP_PPCS>,
> + <&uartb TEGRA_SWGROUP_PPCS>,
> + <&uartc TEGRA_SWGROUP_PPCS>,
> + <&uartd TEGRA_SWGROUP_PPCS>,
> + <&uarte TEGRA_SWGROUP_PPCS>,
> + <&sdhci0 TEGRA_SWGROUP_PPCS>,
> + <&sdhci1 TEGRA_SWGROUP_PPCS>,
> + <&sdhci2 TEGRA_SWGROUP_PPCS>,
> + <&sdhci3 TEGRA_SWGROUP_PPCS>;
> };
At first glance this seems backward from all other cases we have in which we
usually have the device have a property that points back, like interrupt-parent.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer
On Oct 24, 2013, at 4:21 AM, Hiroshi Doyu wrote:
> Hi Grant,
>
> Grant Likely wrote @ Thu, 24 Oct 2013 10:55:31
> +0200:
>
>>> diff --git a/include/linux/of.h b/include/linux/of.h
>>> index f95aee3..638a88a 100644
>>> --- a/include/linux/of.h
>>> +++ b/include/linux/of.h
>>> @@ -60,6 +60,7 @@ struct device_node {
>>> struct kref kref;
>>> unsigned long _flags;
>>> void*data;
>>> + struct device *dev; /* Set only after populated */
>>
>> Is this being used merely to indicate that a device has been processed
>> by of_platform_device_create()? Or do you intend to dereference this
>> pointer? I've avoided putting the struct device in to the device_node
>> structure up to this point simply becuase there aren't any good clues
>> for what /kind/ of device it actually points to. I worry that bad
>> assumptions will get made when other subsystems try to use the
>> same pointer. ie. if one subsystem creates its own device and sets this
>> pointer, and then of_platform_device_create() comes along behind, sees
>> that it is already created, and then returns a platform_device pointer
>> *for something that isn't a struct platform_device*. This is very bad.
>>
>> Instead of using a pointer to the struct device, would a flag be
>> sufficient for your purposes? Would it be fine to return NULL if the
>> device has already been created?
>
> Yes, a flag would be enough for this purpose.
>
> This patch is a part of HACK to control device instanciation order. We
> have an IOMMU device(platform) which needs to be instanciated earlier
> than other (platform)devices so that IOMMU driver would configure them
> as IOMMU'able device.
>
> Is there any better way to control device instanciation order from DT?
I was also thinking being able to call of_platform_populate multiple times and
have explicit lists to control device init order might be a workable solution.
So might be worth continuing down this path to make device nodes that have
already be created.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
On Mar 28, 2013, at 2:53 PM, Varun Sethi wrote: > Add an iommu domain pointer to device (powerpc) archdata. Devices > are attached to iommu domains and this pointer provides a mechanism > to correlate between a device and the associated iommu domain. This > field is set when a device is attached to a domain. > > Signed-off-by: Varun Sethi > --- > - no change in v11. > - no change in v10. > - Added CONFIG_IOMMU_API in v9. > arch/powerpc/include/asm/device.h |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) Acked-by: Kumar Gala - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Mar 18, 2013, at 9:59 AM, Kumar Gala wrote: > > On Mar 17, 2013, at 10:48 AM, Sethi Varun-B16395 wrote: > >>>> >>>> + guts_node = of_find_compatible_node(NULL, NULL, >>>> + "fsl,qoriq-device-config-1.0"); >>> >>> This doesn't work for T4 or B4 device trees. >>> >> [Sethi Varun-B16395]hmm I need to use the dcfg space for this. > > Let's see with the SoC arch's if something like "fsl,qoriq-device-config-2.0" > makes sense for T4 & B4. Based on discuss, I've sent patch for T4 dts to use "fsl,qoriq-device-config-2.0", so please update PAMU code to use that string. - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Mar 17, 2013, at 10:48 AM, Sethi Varun-B16395 wrote: >>> >>> + guts_node = of_find_compatible_node(NULL, NULL, >>> + "fsl,qoriq-device-config-1.0"); >> >> This doesn't work for T4 or B4 device trees. >> > [Sethi Varun-B16395]hmm I need to use the dcfg space for this. Let's see with the SoC arch's if something like "fsl,qoriq-device-config-2.0" makes sense for T4 & B4. - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Mar 14, 2013, at 3:20 PM, Kumar Gala wrote:
>
> On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
>
>> +/*
>> + * Table of SVRs and the corresponding PORT_ID values.
>> + *
>> + * All future CoreNet-enabled SOCs will have this erratum fixed, so this
>> table
>> + * should never need to be updated. SVRs are guaranteed to be unique, so
>> + * there is no worry that a future SOC will inadvertently have one of these
>> + * values.
>> + */
>
> Maybe add to the comment about what port_id represents
also, add reference to the erratum #/id/name
>
>> +static const struct {
>> +u32 svr;
>> +u32 port_id;
>> +} port_id_map[] = {
>> +{0x82100010, 0xFF00}, /* P2040 1.0 */
>> +{0x82100011, 0xFF00}, /* P2040 1.1 */
>> +{0x82100110, 0xFF00}, /* P2041 1.0 */
>> +{0x82100111, 0xFF00}, /* P2041 1.1 */
>> +{0x82110310, 0xFF00}, /* P3041 1.0 */
>> +{0x82110311, 0xFF00}, /* P3041 1.1 */
>> +{0x82010020, 0xFFF8}, /* P4040 2.0 */
>> +{0x8220, 0xFFF8}, /* P4080 2.0 */
>> +{0x82210010, 0xFC00}, /* P5010 1.0 */
>> +{0x82210020, 0xFC00}, /* P5010 2.0 */
>> +{0x82200010, 0xFC00}, /* P5020 1.0 */
>> +{0x82050010, 0xFF80}, /* P5021 1.0 */
>> +{0x82040010, 0xFF80}, /* P5040 1.0 */
>> +};
>> +
>> +#define SVR_SECURITY0x8 /* The Security (E) bit */
>> +
>> +static int __init fsl_pamu_probe(struct platform_device *pdev)
>> +{
>> +void __iomem *pamu_regs = NULL;
>> +struct ccsr_guts __iomem *guts_regs = NULL;
>> +u32 pamubypenr, pamu_counter;
>> +unsigned long pamu_reg_off;
>> +unsigned long pamu_reg_base;
>> +struct pamu_isr_data *data;
>> +struct device_node *guts_node;
>> +u64 size;
>> +struct page *p;
>> +int ret = 0;
>> +int irq;
>> +phys_addr_t ppaact_phys;
>> +phys_addr_t spaact_phys;
>> +phys_addr_t omt_phys;
>> +size_t mem_size = 0;
>> +unsigned int order = 0;
>> +u32 csd_port_id = 0;
>> +unsigned i;
>> +/*
>> + * enumerate all PAMUs and allocate and setup PAMU tables
>> + * for each of them,
>> + * NOTE : All PAMUs share the same LIODN tables.
>> + */
>> +
>> +pamu_regs = of_iomap(pdev->dev.of_node, 0);
>> +if (!pamu_regs) {
>> +dev_err(&pdev->dev, "ioremap of PAMU node failed\n");
>> +return -ENOMEM;
>> +}
>> +of_get_address(pdev->dev.of_node, 0, &size, NULL);
>> +
>> +irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
>> +if (irq == NO_IRQ) {
>> +dev_warn(&pdev->dev, "no interrupts listed in PAMU node\n");
>> +goto error;
>> +}
>> +
>> +data = kzalloc(sizeof(struct pamu_isr_data), GFP_KERNEL);
>> +if (!data) {
>> +iounmap(pamu_regs);
>> +return -ENOMEM;
>> +}
>> +data->pamu_reg_base = pamu_regs;
>> +data->count = size / PAMU_OFFSET;
>> +
>> +/* The ISR needs access to the regs, so we won't iounmap them */
>> +ret = request_irq(irq, pamu_av_isr, 0, "pamu", data);
>> +if (ret < 0) {
>> +dev_err(&pdev->dev, "error %i installing ISR for irq %i\n",
>> +ret, irq);
>> +goto error;
>> +}
>> +
>> +guts_node = of_find_compatible_node(NULL, NULL,
>> +"fsl,qoriq-device-config-1.0");
>
> This doesn't work for T4 or B4 device trees.
>
>> +if (!guts_node) {
>> +dev_err(&pdev->dev, "could not find GUTS node %s\n",
>> +pdev->dev.of_node->full_name);
>> +ret = -ENODEV;
>> +goto error;
>> +}
>> +
>> +guts_regs = of_iomap(guts_node, 0);
>> +of_node_put(guts_node);
>> +if (!guts_regs) {
>> +dev_err(&pdev->dev, "ioremap of GUTS node failed\n");
>> +ret = -ENODEV;
>> +goto error;
>> +}
>> +
>> +/* read in the PAMU capability registers */
>> +get_pamu_cap_values((unsigned long)pamu_regs);
>> +/*
>> + * To simplify the allocation of a coherency domain, we allocate the
>> + * PAACT and the OMT in
Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
> +/*
> + * Table of SVRs and the corresponding PORT_ID values.
> + *
> + * All future CoreNet-enabled SOCs will have this erratum fixed, so this
> table
> + * should never need to be updated. SVRs are guaranteed to be unique, so
> + * there is no worry that a future SOC will inadvertently have one of these
> + * values.
> + */
Maybe add to the comment about what port_id represents
> +static const struct {
> + u32 svr;
> + u32 port_id;
> +} port_id_map[] = {
> + {0x82100010, 0xFF00}, /* P2040 1.0 */
> + {0x82100011, 0xFF00}, /* P2040 1.1 */
> + {0x82100110, 0xFF00}, /* P2041 1.0 */
> + {0x82100111, 0xFF00}, /* P2041 1.1 */
> + {0x82110310, 0xFF00}, /* P3041 1.0 */
> + {0x82110311, 0xFF00}, /* P3041 1.1 */
> + {0x82010020, 0xFFF8}, /* P4040 2.0 */
> + {0x8220, 0xFFF8}, /* P4080 2.0 */
> + {0x82210010, 0xFC00}, /* P5010 1.0 */
> + {0x82210020, 0xFC00}, /* P5010 2.0 */
> + {0x82200010, 0xFC00}, /* P5020 1.0 */
> + {0x82050010, 0xFF80}, /* P5021 1.0 */
> + {0x82040010, 0xFF80}, /* P5040 1.0 */
> +};
> +
> +#define SVR_SECURITY 0x8 /* The Security (E) bit */
> +
> +static int __init fsl_pamu_probe(struct platform_device *pdev)
> +{
> + void __iomem *pamu_regs = NULL;
> + struct ccsr_guts __iomem *guts_regs = NULL;
> + u32 pamubypenr, pamu_counter;
> + unsigned long pamu_reg_off;
> + unsigned long pamu_reg_base;
> + struct pamu_isr_data *data;
> + struct device_node *guts_node;
> + u64 size;
> + struct page *p;
> + int ret = 0;
> + int irq;
> + phys_addr_t ppaact_phys;
> + phys_addr_t spaact_phys;
> + phys_addr_t omt_phys;
> + size_t mem_size = 0;
> + unsigned int order = 0;
> + u32 csd_port_id = 0;
> + unsigned i;
> + /*
> + * enumerate all PAMUs and allocate and setup PAMU tables
> + * for each of them,
> + * NOTE : All PAMUs share the same LIODN tables.
> + */
> +
> + pamu_regs = of_iomap(pdev->dev.of_node, 0);
> + if (!pamu_regs) {
> + dev_err(&pdev->dev, "ioremap of PAMU node failed\n");
> + return -ENOMEM;
> + }
> + of_get_address(pdev->dev.of_node, 0, &size, NULL);
> +
> + irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + if (irq == NO_IRQ) {
> + dev_warn(&pdev->dev, "no interrupts listed in PAMU node\n");
> + goto error;
> + }
> +
> + data = kzalloc(sizeof(struct pamu_isr_data), GFP_KERNEL);
> + if (!data) {
> + iounmap(pamu_regs);
> + return -ENOMEM;
> + }
> + data->pamu_reg_base = pamu_regs;
> + data->count = size / PAMU_OFFSET;
> +
> + /* The ISR needs access to the regs, so we won't iounmap them */
> + ret = request_irq(irq, pamu_av_isr, 0, "pamu", data);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "error %i installing ISR for irq %i\n",
> + ret, irq);
> + goto error;
> + }
> +
> + guts_node = of_find_compatible_node(NULL, NULL,
> + "fsl,qoriq-device-config-1.0");
This doesn't work for T4 or B4 device trees.
> + if (!guts_node) {
> + dev_err(&pdev->dev, "could not find GUTS node %s\n",
> + pdev->dev.of_node->full_name);
> + ret = -ENODEV;
> + goto error;
> + }
> +
> + guts_regs = of_iomap(guts_node, 0);
> + of_node_put(guts_node);
> + if (!guts_regs) {
> + dev_err(&pdev->dev, "ioremap of GUTS node failed\n");
> + ret = -ENODEV;
> + goto error;
> + }
> +
> + /* read in the PAMU capability registers */
> + get_pamu_cap_values((unsigned long)pamu_regs);
> + /*
> + * To simplify the allocation of a coherency domain, we allocate the
> + * PAACT and the OMT in the same memory buffer. Unfortunately, this
> + * wastes more memory compared to allocating the buffers separately.
> + */
> + /* Determine how much memory we need */
> + mem_size = (PAGE_SIZE << get_order(PAACT_SIZE)) +
> + (PAGE_SIZE << get_order(SPAACT_SIZE)) +
> + (PAGE_SIZE << get_order(OMT_SIZE));
> + order = get_order(mem_size);
> +
> + p = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
> + if (!p) {
> + dev_err(&pdev->dev, "unable to allocate PAACT/SPAACT/OMT
> block\n");
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + ppaact = page_address(p);
> + ppaact_phys = page_to_phys(p);
> +
> + /* Make sure the memory is naturally aligned */
> + if (ppaact_phys & ((PAGE_SIZE << order) - 1)) {
> + dev_err(&pdev->dev, "PAACT/OMT block is unaligned\n");
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + spaact = (void *)p
Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
On Feb 27, 2013, at 4:56 AM, Sethi Varun-B16395 wrote: > This patch is present in the "next branch" of linux ppc tree maintained by > Kumar Gala. > Following is the commit id: > 52c5affc545053d37c0b05224bbf70f5336caa20 > > I am not sure if this would be part of 3.9-rc1. > > Regards > varun This is now in Linus's tree so will be in 3.9-rc1 - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/6] powerpc/fsl_pci: Added defines for the FSL PCI controller BRR1 register.
On Feb 27, 2013, at 5:33 AM, Joerg Roedel wrote: > On Mon, Feb 18, 2013 at 06:22:16PM +0530, Varun Sethi wrote: >> Macros for checking FSL PCI controller version. >> >> Signed-off-by: Varun Sethi >> --- >> arch/powerpc/include/asm/pci-bridge.h |4 >> 1 files changed, 4 insertions(+), 0 deletions(-) >> >> diff --git a/arch/powerpc/include/asm/pci-bridge.h >> b/arch/powerpc/include/asm/pci-bridge.h >> index 025a130..c12ed78 100644 >> --- a/arch/powerpc/include/asm/pci-bridge.h >> +++ b/arch/powerpc/include/asm/pci-bridge.h >> @@ -14,6 +14,10 @@ >> >> struct device_node; >> >> +/* FSL PCI controller BRR1 register */ >> +#define PCI_FSL_BRR1 0xbf8 >> +#define PCI_FSL_BRR1_VER 0x >> + > > > Please merge this patch with the one where you actually make use of > these defines for the first time. > > > Joerg This also seems an odd place for these defines. - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
On Feb 27, 2013, at 6:04 AM, Sethi Varun-B16395 wrote:
> Hi Kumar,Ben,
> I am implementing the Freescale PAMU (IOMMU) driver using the Linux IOMMU
> API. In this particular patch, I have added a new field to dev_archdata
> structure to store the dma domain information.
> This field is updated whenever we attach a device to an iommu domain.
>
> Regards
> Varun
Would be good to see if this overlaps with Alexey's work for IOMMU driver for
powernv.
- k
>
>> -Original Message-
>> From: Joerg Roedel [mailto:j...@8bytes.org]
>> Sent: Wednesday, February 27, 2013 5:01 PM
>> To: Sethi Varun-B16395
>> Cc: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org;
>> linux-ker...@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
>> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
>> pointer in archdata.
>>
>> On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
>>> Add a new field in the device (powerpc) archdata structure for storing
>>> iommu domain information pointer. This pointer is stored when the
>>> device is attached to a particular domain.
>>>
>>>
>>> Signed-off-by: Varun Sethi
>>> ---
>>> - no change.
>>> arch/powerpc/include/asm/device.h |4
>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/device.h
>>> b/arch/powerpc/include/asm/device.h
>>> index 77e97dd..6dc79fe 100644
>>> --- a/arch/powerpc/include/asm/device.h
>>> +++ b/arch/powerpc/include/asm/device.h
>>> @@ -28,6 +28,10 @@ struct dev_archdata {
>>> void*iommu_table_base;
>>> } dma_data;
>>>
>>> + /* IOMMU domain information pointer. This would be set
>>> +* when this device is attached to an iommu_domain.
>>> +*/
>>> + void*iommu_domain;
>>
>> Please Cc the PowerPC Maintainers on this, so that they can have a look
>> at it. This also must be put this into an #ifdef CONFIG_IOMMU_API.
>>
>>
>> Joerg
>>
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer in archdata.
On Nov 25, 2012, at 11:33 PM, Sethi Varun-B16395 wrote:
> Hi Kumar,
> Can you please apply this patch.
>
> Regards
> Varun
Was waiting on the others to apply this all together. (ie getting an Ack from
Joerg, and follow comments from Timur to be resolved)
- k
>
>> -Original Message-
>> From: Sethi Varun-B16395
>> Sent: Tuesday, November 20, 2012 7:25 PM
>> To: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc-
>> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421;
>> Tabi Timur-B04825
>> Cc: Sethi Varun-B16395
>> Subject: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer
>> in archdata.
>>
>> Add a new field in the device (powerpc) archdata structure for storing
>> iommu domain information pointer. This pointer is stored when the device
>> is attached to a particular domain.
>>
>> Signed-off-by: Varun Sethi
>> ---
>> arch/powerpc/include/asm/device.h |4
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/device.h
>> b/arch/powerpc/include/asm/device.h
>> index 77e97dd..6dc79fe 100644
>> --- a/arch/powerpc/include/asm/device.h
>> +++ b/arch/powerpc/include/asm/device.h
>> @@ -28,6 +28,10 @@ struct dev_archdata {
>> void*iommu_table_base;
>> } dma_data;
>>
>> +/* IOMMU domain information pointer. This would be set
>> + * when this device is attached to an iommu_domain.
>> + */
>> +void*iommu_domain;
>> #ifdef CONFIG_SWIOTLB
>> dma_addr_t max_direct_dma_addr;
>> #endif
>> --
>> 1.7.4.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/4] iommu/fsl: Add PAMU bypass enable register to ccsr_guts structure.
On Nov 20, 2012, at 7:54 AM, Varun Sethi wrote: > PAMU bypass enable register added to the ccsr_guts structure. > > Signed-off-by: Timur Tabi > Signed-off-by: Varun Sethi > --- > arch/powerpc/include/asm/fsl_guts.h |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) applied to next - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3 v2] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
On Oct 4, 2012, at 6:56 AM, wrote: > From: Varun Sethi > > Following is a brief description of the PAMU hardware: > PAMU determines what action to take and whether to authorize the action on > the basis > of the memory address, a Logical IO Device Number (LIODN), and PAACT table > (logically) > indexed by LIODN and address. Hardware devices which need to access memory > must provide > an LIODN in addition to the memory address. > > Peripheral Access Authorization and Control Tables (PAACTs) are the primary > data structures > used by PAMU. A PAACT is a table of peripheral access authorization and > control entries (PAACE). > Each PAACE defines the range of I/O bus address space that is accessible by > the LIOD and the > associated access capabilities. > > There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT > (SPAACT). A given physical > I/O device may be able to act as one or more independent logical I/O devices > (LIODs). Each such > logical I/O device is assigned an identifier called logical I/O device number > (LIODN). A LIOD is > allocated a contiguous portion of the I/O bus address space called the DSA > window for performing > DSA operations. The DSA window may optionally be divided into multiple > sub-windows, each of which > may be used to map to a region in system storage space. The first sub-window > is referred to > as the primary sub-window and the remaining are called secondary sub-windows. > > This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU > API implementation > (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c) has been derived > from the work done > by Ashish Kalra and Timur Tabi (ti...@freescale.com). > > Signed-off-by: Varun Sethi > --- I'm not seeing any of the comments I made addressed. What changed in this version? - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3 v2] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
On Oct 4, 2012, at 6:56 AM, wrote:
> From: Varun Sethi
>
> Added the following domain attributes required by FSL PAMU driver:
> 1. Subwindows field added to the iommu domain geometry attribute.
> 2. Added new iommu stash attribute, which allows setting of the
> LIODN specific stash id parameter through IOMMU API.
> 3. Added an attribute for enabling/disabling DMA to a particular
> memory window.
>
> Signed-off-by: Varun Sethi
> ---
> include/linux/iommu.h | 35 +++
> 1 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index f3b99e1..62e22f0 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -44,6 +44,33 @@ struct iommu_domain_geometry {
> dma_addr_t aperture_start; /* First address that can be mapped*/
> dma_addr_t aperture_end; /* Last address that can be mapped */
> bool force_aperture; /* DMA only allowed in mappable range? */
> +
> + /* The subwindows field indicates number of DMA subwindows supported
> + * by the geometry. Following is the interpretation of
> + * values for this field:
> + * 0 : This implies that the supported geometry size is 1 MB
> + * with each subwindow size being 4KB. Thus number of subwindows
> + * being = 1MB/4KB = 256.
> + * 1 : Only one DMA window i.e. no subwindows.
> + * value other than 0 or 1 would indicate actual number of subwindows.
> + */
> + u32 subwindows;
> +};
> +
> +/* cache stash targets */
> +#define L1_CACHE 1
> +#define L2_CACHE 2
> +#define L3_CACHE 3
These names are way to generic for being exposed to user space
> +
> +/* This attribute corresponds to IOMMUs capable of generating
> + * a stash transaction. A stash transaction is typically a
> + * hardware initiated prefetch of data from memory to cache.
> + * This attribute allows configuring stashig specific parameters
> + * in the IOMMU hardware.
> + */
> +struct iommu_stash_attribute {
> + u32 cpu;/* cpu number */
> + u32 cache; /* cache to stash to: L1,L2,L3 */
> };
>
> struct iommu_domain {
> @@ -60,6 +87,14 @@ struct iommu_domain {
> enum iommu_attr {
> DOMAIN_ATTR_MAX,
> DOMAIN_ATTR_GEOMETRY,
> + /* Set the IOMMU hardware stashing
> + * parameters.
> + */
> + DOMAIN_ATTR_STASH,
> + /* Explicity enable/disable DMA for a
> + * particular memory window.
> + */
> + DOMAIN_ATTR_ENABLE,
> };
>
> #ifdef CONFIG_IOMMU_API
> --
> 1.7.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
On Sep 20, 2012, at 4:46 AM, Sethi Varun-B16395 wrote:
>
>
>> -Original Message-
>> From: Wood Scott-B07421
>> Sent: Thursday, September 20, 2012 5:42 AM
>> To: Kumar Gala
>> Cc: Sethi Varun-B16395; joerg.roe...@amd.com; iommu@lists.linux-
>> foundation.org; linuxppc-...@lists.ozlabs.org; linux-
>> ker...@vger.kernel.org; Sethi Varun-B16395
>> Subject: Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes
>> required by fsl PAMU driver.
>>
>> On 09/19/2012 08:52:27 AM, Kumar Gala wrote:
>>>
>>> On Sep 19, 2012, at 8:17 AM,
>>> wrote:
>>>
>>>> From: Varun Sethi
>>>>
>>>> Added the following domain attributes required by FSL PAMU driver:
>>>> 1. Subwindows field added to the iommu domain geometry attribute.
>>>> 2. Added new iommu stash attribute, which allows setting of the
>>>> LIODN specific stash id parameter through IOMMU API.
>>>> 3. Added an attribute for enabling/disabling DMA to a particular
>>>> memory window.
>>>>
>>>> Signed-off-by: Varun Sethi
>>>> ---
>>>> include/linux/iommu.h | 30 ++
>>>> 1 files changed, 30 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
>>>> 7e83370..eaa40c6 100644
>>>> --- a/include/linux/iommu.h
>>>> +++ b/include/linux/iommu.h
>>>> @@ -44,6 +44,28 @@ struct iommu_domain_geometry {
>>>>dma_addr_t aperture_start; /* First address that can be
>>> mapped*/
>>>>dma_addr_t aperture_end; /* Last address that can be
>>> mapped */
>>>>bool force_aperture; /* DMA only allowed in mappable
>>> range? */
>>>> +
>>>> + /* The subwindows field indicates number of DMA subwindows
>>> supported
>>>> + * by the geometry. Following is the interpretation of
>>>> + * values for this field:
>>>> + * 0 : This implies that the supported geometry size is 1 MB
>>>> + * with each subwindow size being 4KB. Thus number of
>>> subwindows
>>>> + * being = 1MB/4KB = 256.
>>>> + * 1 : Only one DMA window i.e. no subwindows.
>>>> + * value other than 0 or 1 would indicate actual number of
>>> subwindows.
>>>> + */
>>>> + u32 subwindows;
>>>> +};
>>>> +
>>>> +/* This attribute corresponds to IOMMUs capable of generating
>>>> + * a stash transaction. A stash transaction is typically a
>>>> + * hardware initiated prefetch of data from memory to cache.
>>>> + * This attribute allows configuring stashig specific parameters
>>>> + * in the IOMMU hardware.
>>>> + */
>>>> +struct iommu_stash_attribute {
>>>> + u32 cpu;/* cpu number */
>>>> + u32 cache; /* cache to stash to: L1,L2,L3 */
>>>
>>> seems like this should be enum instead of u32 for cache
>>>
>>> With enum being something like:
>>>
>>> enum iommu_attr_stash_cache {
>>> IOMMU_ATTR_CACHE_L1,
>>> IOMMU_ATTR_CACHE_L2,
>>> IOMMU_ATTR_CACHE_L3,
>>> };
>>
>> Don't we want these structs to be usable via some VFIO ioctl? In that
>> case they need to use fixed size types.
>>
> Yes, this would be usable via vfio ioctl. But, then the caller should be
> aware of supported stash targets. May be I should add an interface for the
> caller,
> to query supported stash targets.
Guess the caller probably knows, but thinking we should move the #defines for
valid values into this file out of pamu specific files.
- k
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 1/3] iommu/fsl: Store iommu domain information pointer in archdata.
On Sep 19, 2012, at 8:17 AM,
wrote:
> From: Varun Sethi
>
> Add a new field in the device (powerpc) archdata structure for storing iommu
> domain
> information pointer. This pointer is stored when the device is attached to a
> particular
> domain.
>
> Signed-off-by: Varun Sethi
> ---
> arch/powerpc/include/asm/device.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
Not too familiar, but what does the IBM Server IOMMU do for iommu_domain?
>
> diff --git a/arch/powerpc/include/asm/device.h
> b/arch/powerpc/include/asm/device.h
> index 77e97dd..6dc79fe 100644
> --- a/arch/powerpc/include/asm/device.h
> +++ b/arch/powerpc/include/asm/device.h
> @@ -28,6 +28,10 @@ struct dev_archdata {
> void*iommu_table_base;
> } dma_data;
>
> + /* IOMMU domain information pointer. This would be set
> + * when this device is attached to an iommu_domain.
> + */
> + void*iommu_domain;
> #ifdef CONFIG_SWIOTLB
> dma_addr_t max_direct_dma_addr;
> #endif
> --
> 1.7.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
On Sep 19, 2012, at 8:17 AM,
wrote:
> From: Varun Sethi
>
> Added the following domain attributes required by FSL PAMU driver:
> 1. Subwindows field added to the iommu domain geometry attribute.
> 2. Added new iommu stash attribute, which allows setting of the
> LIODN specific stash id parameter through IOMMU API.
> 3. Added an attribute for enabling/disabling DMA to a particular
> memory window.
>
> Signed-off-by: Varun Sethi
> ---
> include/linux/iommu.h | 30 ++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 7e83370..eaa40c6 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -44,6 +44,28 @@ struct iommu_domain_geometry {
> dma_addr_t aperture_start; /* First address that can be mapped*/
> dma_addr_t aperture_end; /* Last address that can be mapped */
> bool force_aperture; /* DMA only allowed in mappable range? */
> +
> + /* The subwindows field indicates number of DMA subwindows supported
> + * by the geometry. Following is the interpretation of
> + * values for this field:
> + * 0 : This implies that the supported geometry size is 1 MB
> + * with each subwindow size being 4KB. Thus number of subwindows
> + * being = 1MB/4KB = 256.
> + * 1 : Only one DMA window i.e. no subwindows.
> + * value other than 0 or 1 would indicate actual number of subwindows.
> + */
> + u32 subwindows;
> +};
> +
> +/* This attribute corresponds to IOMMUs capable of generating
> + * a stash transaction. A stash transaction is typically a
> + * hardware initiated prefetch of data from memory to cache.
> + * This attribute allows configuring stashig specific parameters
> + * in the IOMMU hardware.
> + */
> +struct iommu_stash_attribute {
> + u32 cpu;/* cpu number */
> + u32 cache; /* cache to stash to: L1,L2,L3 */
seems like this should be enum instead of u32 for cache
With enum being something like:
enum iommu_attr_stash_cache {
IOMMU_ATTR_CACHE_L1,
IOMMU_ATTR_CACHE_L2,
IOMMU_ATTR_CACHE_L3,
};
> };
>
> struct iommu_domain {
> @@ -60,6 +82,14 @@ struct iommu_domain {
> enum iommu_attr {
> DOMAIN_ATTR_MAX,
> DOMAIN_ATTR_GEOMETRY,
> + /* Set the IOMMU hardware stashing
> + * parameters.
> + */
> + DOMAIN_ATTR_STASH,
> + /* Explicity enable/disable DMA for a
> + * particular memory window.
> + */
> + DOMAIN_ATTR_ENABLE,
> };
>
> #ifdef CONFIG_IOMMU_API
> --
> 1.7.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
On Sep 19, 2012, at 8:17 AM, wrote: > From: Varun Sethi > > This patchset provides the Freescale PAMU (Peripheral Access Management Unit) > driver > and the corresponding IOMMU API implementation. PAMU is the IOMMU present on > Freescale > QorIQ platforms. PAMU can authorize memory access, remap the memory address, > and remap > the I/O transaction type. > > This set consists of the following patches: > 1. Addition of new field in the device (powerpc) archdata structure for > storing iommu domain information > pointer. This pointer is stored when the device is attached to a particular > iommu domain. > 2. Addition of domain attributes required by the PAMU driver IOMMU API. > 3. PAMU driver and IOMMU API implementation. > > Varun Sethi (3): > Store iommu domain information pointer in archdata. > Add iommu domain attributes required by fsl PAMU driver. > FSL PAMU driver and IOMMU API implementation. > > arch/powerpc/include/asm/device.h |4 + > drivers/iommu/Kconfig |7 + > drivers/iommu/Makefile|1 + > drivers/iommu/fsl_pamu.c | 1033 + > drivers/iommu/fsl_pamu.h | 377 ++ > drivers/iommu/fsl_pamu_domain.c | 990 +++ > drivers/iommu/fsl_pamu_domain.h | 94 > drivers/iommu/fsl_pamu_proto.h| 49 ++ > include/linux/iommu.h | 30 ++ > 9 files changed, 2585 insertions(+), 0 deletions(-) > create mode 100644 drivers/iommu/fsl_pamu.c > create mode 100644 drivers/iommu/fsl_pamu.h > create mode 100644 drivers/iommu/fsl_pamu_domain.c > create mode 100644 drivers/iommu/fsl_pamu_domain.h > create mode 100644 drivers/iommu/fsl_pamu_proto.h I assume that another patch series will add device tree binding spec and update device trees for SoCs with PAMU? - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
