date:20121129

Re: [PATCH 1/1] ARM: tegra: bus_notifier registers IOMMU devices(was: How to specify IOMMU'able devices in DT)

2012-11-29 Thread Thierry Reding

On Wed, Nov 28, 2012 at 02:48:32PM +0100, Hiroshi Doyu wrote:
[...]
 From: Hiroshi Doyu hd...@nvidia.com
 Date: Wed, 28 Nov 2012 14:47:04 +0200
 Subject: [PATCH 1/1] ARM: tegra: bus_notifier registers IOMMU devices
 
 platform_bus notifier registers IOMMU devices if dma-window is
 specified.
 
 Its format is:
   dma-window = start size;
 ex)
   dma-window = 0x12345000 0x8000;
 
 Signed-off-by: Hiroshi Doyu hd...@nvidia.com
 ---
  arch/arm/mach-tegra/board-dt-tegra30.c |   40 
 
  1 file changed, 40 insertions(+)
 
 diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c 
 b/arch/arm/mach-tegra/board-dt-tegra30.c
 index a2b6cf1..570d718 100644
 --- a/arch/arm/mach-tegra/board-dt-tegra30.c
 +++ b/arch/arm/mach-tegra/board-dt-tegra30.c
 @@ -30,9 +30,11 @@
  #include linux/of_fdt.h
  #include linux/of_irq.h
  #include linux/of_platform.h
 +#include linux/of_iommu.h
  
  #include asm/mach/arch.h
  #include asm/hardware/gic.h
 +#include asm/dma-iommu.h
  
  #include board.h
  #include clock.h
 @@ -86,10 +88,48 @@ static __initdata struct tegra_clk_init_table 
 tegra_dt_clk_init_table[] = {
   { NULL, NULL,   0,  0},
  };
  
 +#ifdef CONFIG_ARM_DMA_USE_IOMMU
 +static int tegra_iommu_device_notifier(struct notifier_block *nb,
 +unsigned long event, void *_dev)
 +{
 + struct dma_iommu_mapping *map = NULL;
 + struct device *dev = _dev;
 + dma_addr_t base;
 + size_t size;
 + int err;
 +
 + switch (event) {
 + case BUS_NOTIFY_ADD_DEVICE:
 + err = of_get_dma_window(dev-of_node, NULL, 0, NULL, base,
 + size);
 + if (!err)
 + map = arm_iommu_create_mapping(platform_bus_type,
 +base, size, 0);
 + if (IS_ERR_OR_NULL(map))
 + break;
 + if (arm_iommu_attach_device(dev, map))
 + dev_err(dev, Failed to attach %s\n, dev_name(dev));
 + dev_dbg(dev, Attached %s to map %p\n, dev_name(dev), map);
 + break;
 + }
 + return NOTIFY_DONE;
 +}
 +#else
 +#define tegra_iommu_device_notifier NULL
 +#endif
 +
 +static struct notifier_block tegra_iommu_device_nb = {
 + .notifier_call = tegra_iommu_device_notifier,
 +};

You don't need this extra protection since you use IS_ENABLED below and
these are all static variables. The whole point of IS_ENABLED is to
allow full compile coverage while leaving it up to the compiler to
eliminate dead code.

Thierry


pgpo3hiq1gK94.pgp
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH v4 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

2012-11-29 Thread Cho KyongHo

 -Original Message-
 From: Cho KyongHo [mailto:pullip@samsung.com]
 Sent: Monday, November 26, 2012 10:54 AM
  -Original Message-
  From: Cho KyongHo [mailto:pullip@samsung.com]
  Sent: Monday, November 26, 2012 10:28 AM

   -Original Message-
   From: Kukjin Kim [mailto:kgene@samsung.com]
   Sent: Friday, November 23, 2012 5:08 PM
   Subject: RE: [PATCH v4 00/12] iommu/exynos: Fixes and Enhancements of 
   System MMU driver with DT

   Cho KyongHo wrote:

The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is 
disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because A System MMU is resides in 
the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.

This set of changes solves the above problem with setting each System 
MMUs
as the parent of the device which owns the System MMU to recieve the
information when the device is turned off or turned on.

Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt

In addition, this patchset also includes several bug fixes and
enhancements
of the current driver.

Change log:
v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
  Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to
client
  device if the client device has multiple System MMUs.
  Thanks to Rahul Sharma.

v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
  Thanks to Prathyush.

v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction

Patch summary:
[PATCH v4 01/12] ARM: EXYNOS: Add clk_ops for gating clocks of System 
MMU
[PATCH v4 02/12] ARM: EXYNOS: add System MMU definition to DT
[PATCH v4 03/12] ARM: EXYNOS: remove system mmu initialization from 
exynos
tree
[PATCH v4 04/12] iommu/exynos: support for device tree
[PATCH v4 05/12] iommu/exynos: pass version information from DT
[PATCH v4 06/12] iommu/exynos: allocate lv2 page table from own slab
[PATCH v4 07/12] iommu/exynos: change rwlock to spinlock
[PATCH v4 08/12] iommu/exynos: set System MMU as the parent of client
device
[PATCH v4 09/12] iommu/exynos: add support for runtime pm and
suspend/resume
[PATCH v4 10/12] iommu/exynos: add support for System MMU 3.2 and 3.3
[PATCH v4 11/12] iommu/exynos: add literal name of System MMU for
debugging
[PATCH v4 12/12] iommu/exynos: add debugfs entries for System MMU

Diffstats:
 .../devicetree/bindings/arm/exynos/system-mmu.txt  |   86 ++
 arch/arm/boot/dts/exynos4210.dtsi  |   96 ++
 arch/arm/boot/dts/exynos4x12.dtsi  |  124 ++
 arch/arm/boot/dts/exynos5250.dtsi  |  147 +-
 arch/arm/mach-exynos/Kconfig   |5 -
 arch/arm/mach-exynos/Makefile  |1 -
 arch/arm/mach-exynos/clock-exynos4.c   |   41 +-
 arch/arm/mach-exynos/clock-exynos4210.c|9 +-
 arch/arm/mach-exynos/clock-exynos4212.c|   23 +-
 arch/arm/mach-exynos/clock-exynos5.c   |   86 +-
 arch/arm/mach-exynos/dev-sysmmu.c  |  274 
 arch/arm/mach-exynos/include/mach/sysmmu.h |   66 -
 arch/arm/mach-exynos/mach-exynos4-dt.c |   34 +
 arch/arm/mach-exynos/mach-exynos5-dt.c |   30 +
 drivers/iommu/Kconfig  |2 +-
 drivers/iommu/exynos-iommu.c   | 1428
   +++-
 16 files changed, 1720 insertions(+), 732 deletions(-)

   Looks good to me 1st~3rd patches. After quick review, I think, 1st and 2nd
   patches can go to upstream for v3.8 without any dependency. So I will.

   The 3rd patch has a dependency with other driver changes (4th ~ 12th), so 
   it
   should be sent to upstream with others.

   BTW since the 3rd patch touches many Samsung stuff in arch/arm/ so I'd
   prefer to take it in Samsung tree. If Joerg is ok on iommu/exynos driver
   changes for v3.8...

   Joerg, please let me know about iommu/exynos stuff so that I can decide to
   take 3rd patch or not for v3.8.

  Hi, Kukjin Kim.

  I found that control bit fields of clock gating of System MMU of MFC L/R is 
  inversed.
  That is reported by Prathyush Kalashwaram.

  I will

Re: [PATCH] iommu: exynos: add support for dt based instantiation for iommu devices

2012-11-29 Thread Rahul Sharma

Thanks Mr. Joerg,

I want to request you to abandon the above patches submitted by me.
The exynos-iommu drivers
patches, submitted by Mr. Kyongho Cho, also contains DT changes along
with other things.

It is been already applied to arm/exynos branch.

regards,
Rahul Sharma.


On Sun, Nov 18, 2012 at 3:07 AM, Joerg Roedel j...@8bytes.org wrote:
 On Mon, Nov 05, 2012 at 03:18:15PM +0530, Rahul Sharma wrote:
  drivers/iommu/exynos-iommu.c |   28 +---
  2 files changed, 26 insertions(+), 4 deletions(-)

 I added the following build-fix to the arm/exynos branch too:

 From e706d84c9fecd7855191eab2f9e2e0234a0f8e05 Mon Sep 17 00:00:00 2001
 From: Joerg Roedel j...@8bytes.org
 Date: Sat, 17 Nov 2012 22:29:32 +0100
 Subject: [PATCH] iommu/exynos: Fix build error in exynos_sysmmu_probe

 Fix the following build error:

   CC  drivers/iommu/exynos-iommu.o
 /data/repos/linux/drivers/iommu/exynos-iommu.c: In function 
 'exynos_sysmmu_probe':
 /data/repos/linux/drivers/iommu/exynos-iommu.c:647:43: error: dereferencing 
 pointer to incomplete type
 make[3]: *** [drivers/iommu/exynos-iommu.o] Error 1

 Signed-off-by: Joerg Roedel j...@8bytes.org
 ---
  drivers/iommu/exynos-iommu.c |1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
 index 9079f71..da1975d 100644
 --- a/drivers/iommu/exynos-iommu.c
 +++ b/drivers/iommu/exynos-iommu.c
 @@ -26,6 +26,7 @@
  #include linux/memblock.h
  #include linux/export.h
  #include linux/of_platform.h
 +#include linux/of.h

  #include asm/cacheflush.h
  #include asm/pgtable.h
 --
 1.7.9.5


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

Re: [PATCH v4 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

2012-11-29 Thread Rahul Sharma

Hi Mr. Cho,

We have verified the above patchset for following usecases on exynos5.

1) MFC decoding using Sysmmu_L and R. (with the bit Inversion fix)
2) GSC operations.
3) FIMD and MIXER (HDMI) as displays.

Thanks for your effort.

regards,
Rahul Sharma.

On Thu, Nov 29, 2012 at 4:25 PM, Cho KyongHo pullip@samsung.com wrote:
 -Original Message-
 From: Cho KyongHo [mailto:pullip@samsung.com]
 Sent: Monday, November 26, 2012 10:54 AM
  -Original Message-
  From: Cho KyongHo [mailto:pullip@samsung.com]
  Sent: Monday, November 26, 2012 10:28 AM
 
   -Original Message-
   From: Kukjin Kim [mailto:kgene@samsung.com]
   Sent: Friday, November 23, 2012 5:08 PM
   Subject: RE: [PATCH v4 00/12] iommu/exynos: Fixes and Enhancements of 
   System MMU driver with DT
  
   Cho KyongHo wrote:
   
The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is 
disabled
before MFC block is power-down not to invalidate IOTLB in the System 
MMU
when I/O memory mapping is changed. Because A System MMU is resides in 
the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.
   
This set of changes solves the above problem with setting each System 
MMUs
as the parent of the device which owns the System MMU to recieve the
information when the device is turned off or turned on.
   
Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
   
In addition, this patchset also includes several bug fixes and
enhancements
of the current driver.
   
Change log:
v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
  Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to
client
  device if the client device has multiple System MMUs.
  Thanks to Rahul Sharma.
   
v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
  Thanks to Prathyush.
   
v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction
   
Patch summary:
[PATCH v4 01/12] ARM: EXYNOS: Add clk_ops for gating clocks of System 
MMU
[PATCH v4 02/12] ARM: EXYNOS: add System MMU definition to DT
[PATCH v4 03/12] ARM: EXYNOS: remove system mmu initialization from 
exynos
tree
[PATCH v4 04/12] iommu/exynos: support for device tree
[PATCH v4 05/12] iommu/exynos: pass version information from DT
[PATCH v4 06/12] iommu/exynos: allocate lv2 page table from own slab
[PATCH v4 07/12] iommu/exynos: change rwlock to spinlock
[PATCH v4 08/12] iommu/exynos: set System MMU as the parent of client
device
[PATCH v4 09/12] iommu/exynos: add support for runtime pm and
suspend/resume
[PATCH v4 10/12] iommu/exynos: add support for System MMU 3.2 and 3.3
[PATCH v4 11/12] iommu/exynos: add literal name of System MMU for
debugging
[PATCH v4 12/12] iommu/exynos: add debugfs entries for System MMU
   
Diffstats:
 .../devicetree/bindings/arm/exynos/system-mmu.txt  |   86 ++
 arch/arm/boot/dts/exynos4210.dtsi  |   96 ++
 arch/arm/boot/dts/exynos4x12.dtsi  |  124 ++
 arch/arm/boot/dts/exynos5250.dtsi  |  147 +-
 arch/arm/mach-exynos/Kconfig   |5 -
 arch/arm/mach-exynos/Makefile  |1 -
 arch/arm/mach-exynos/clock-exynos4.c   |   41 +-
 arch/arm/mach-exynos/clock-exynos4210.c|9 +-
 arch/arm/mach-exynos/clock-exynos4212.c|   23 +-
 arch/arm/mach-exynos/clock-exynos5.c   |   86 +-
 arch/arm/mach-exynos/dev-sysmmu.c  |  274 
 arch/arm/mach-exynos/include/mach/sysmmu.h |   66 -
 arch/arm/mach-exynos/mach-exynos4-dt.c |   34 +
 arch/arm/mach-exynos/mach-exynos5-dt.c |   30 +
 drivers/iommu/Kconfig  |2 +-
 drivers/iommu/exynos-iommu.c   | 1428
   +++-
 16 files changed, 1720 insertions(+), 732 deletions(-)
  
   Looks good to me 1st~3rd patches. After quick review, I think, 1st and 
   2nd
   patches can go to upstream for v3.8 without any dependency. So I will.
  
   The 3rd patch has a dependency with other driver changes (4th ~ 12th), 
   so it
   should be sent to upstream with others.
  
   BTW since the 3rd patch touches many Samsung stuff in arch/arm/ so I'd
   prefer to take it in Samsung tree. If Joerg

Re: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer in archdata.

2012-11-29 Thread Kumar Gala


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 varun.se...@freescale.com
 ---
 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: Supermicro X9SRL-F - channel enumeration error ACPI/firmware bug question

2012-11-29 Thread Bjorn Helgaas

[+cc Jeff, linux-ide, David, Joerg, iommu]

On Thu, Nov 29, 2012 at 7:39 PM, Robert Hancock hancock...@gmail.com wrote:
 On Thu, Nov 29, 2012 at 12:16 PM, Bjorn Helgaas bhelg...@google.com wrote:
 On Thu, Nov 29, 2012 at 1:55 AM, Justin Piszcz jpis...@lucidpixels.com 
 wrote:


 -Original Message-
 From: Robert Hancock [mailto:hancock...@gmail.com]
 Sent: Wednesday, November 28, 2012 7:55 PM
 To: Justin Piszcz
 Cc: Bjorn Helgaas; Bruno Prémont; supp...@supermicro.com;
 linux-ker...@vger.kernel.org; Dan Williams
 Subject: Re: Supermicro X9SRL-F - channel enumeration error  ACPI/firmware
 bug question

 On Wed, Nov 28, 2012 at 6:49 PM, Justin Piszcz jpis...@lucidpixels.com
 wrote:


 -Original Message-
 From: Robert Hancock [mailto:hancock...@gmail.com]
 Sent: Wednesday, November 28, 2012 7:35 PM
 To: Justin Piszcz
 Cc: 'Bjorn Helgaas'; 'Bruno Prémont'; supp...@supermicro.com;
 linux-ker...@vger.kernel.org; 'Dan Williams'
 Subject: Re: Supermicro X9SRL-F - channel enumeration error 
 ACPI/firmware
 bug question


 What does lspci -vv show on that controller? Not sure what actual
 chipset that controller is, but there's a known issue with some Marvell
 6Gbps SATA controllers with DMAR enabled - it seems the device issues
 memory read/write requests from the wrong PCI function ID and the IOMMU
 rightly denies access as the function listed in the requests doesn't
 have any mapping to that memory. I don't think there's presently a
 workaround other than disabling DMAR. We could (and likely should) be
 detecting that device and adding some kind of quirk for it.

 That sounds likely...
 It is shown below:

 Card name: HighPoint Rocket 620 Dual Port SATA 6 Gbps PCI Express 2.0 Host
 Adapter

 lspci -vv output:

 84:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA
 6.0 Gb/s controller (rev 11) (prog-if 01 [AHCI 1.0])
   Subsystem: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s
 controller

 Yeah, that's one of those controllers I think. But I can't tell from
 the bit of the dmesg you posted exactly what's going on. Can you post
 a full boot log from having the card installed and some drive attached
 (by putting the boot drive on another controller for example)?

 == Further issues with the X9SRL-F -- does this board support ASPM or is
 this a Linux/ASPM implementation issue?
 [0.632170]  pci:ff: ACPI _OSC support notification failed,
 disabling
 PCIe ASPM
 [0.632239]  pci:ff: Unable to request _OSC control (_OSC support
 mask: 0x08)

 What's the full dmesg from this machine (or is it already posted
 somewhere)?

 It is now available here:
 http://home.comcast.net/~jpiszcz/20121128/dmesg.txt

 Is that the same boot log? It doesn't have this error in it.

 Yes, the error is here: (its towards the bottom)

  [7.973015] ata14.00: qc timeout (cmd 0xa1)
 [8.472120] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 [9.275922] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 [   19.260667] ata14.00: qc timeout (cmd 0xa1)
 [   19.759828] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 [   19.760451] ata14: limiting SATA link speed to 1.5 Gbps
 [   20.566598] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 [   50.521078] ata14.00: qc timeout (cmd 0xa1)
 [   51.020880] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
 [   51.824664] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 [   51.824682] dmar: DRHD: handling fault status reg 502
 [   51.824686] dmar: DMAR:[DMA Read] Request device [04:00.0] fault addr 0
 [   51.824686] DMAR:[fault reason 06] PTE Read access is not set

 You have these devices:

 pci :04:00.0: [10de:01d3] type 00 class 0x03 nVidia G72
 pci :84:00.0: [1b4b:9123] type 00 class 0x010601 Marvell 88SE9123 
 SATA
 pci :84:00.1: [1b4b:91a4] type 00 class 0x01018f Marvell 88SE9128 IDE

 I think the 04:00.0 DMAR errors are symptoms of nouveau driver issues,
 and if you get rid of that driver, they'll probably go away.

 But this 84:00.1 DMAR error:

 dmar: DMAR:[DMA Read] Request device [84:00.1] fault addr fff0
 DMAR:[fault reason 02] Present bit in context entry is clear

 looks like the probable cause of the Marvell issue.  It looks similar
 to https://bugzilla.kernel.org/show_bug.cgi?id=42679, although the
 reports there show a bb:dd.0 device (but no bb:dd.1 device), and the
 DMAR rejects DMA that appears to be from bb:dd.1.

 Another report that's even more similar is
 https://bugzilla.redhat.com/show_bug.cgi?id=757166 .  In that case,
 both bb:dd.0 and bb:dd.1 exist (as in your system), and the DMAR fault
 is exactly like what you're seeing.

 So you're not alone, but unfortunately, nobody seems to be working on
 either bug report.  I took the liberty to add you to the cc: list of
 both.

 I don't really know what else to do at this point.  Maybe a SATA
 expert with some Marvell docs could figure out why we're seeing DMA
 from the IDE controller,

Re: [PATCH 1/1] ARM: tegra: bus_notifier registers IOMMU devices(was: How to specify IOMMU'able devices in DT)

RE: [PATCH v4 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

Re: [PATCH] iommu: exynos: add support for dt based instantiation for iommu devices

Re: [PATCH v4 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

Re: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer in archdata.

Re: Supermicro X9SRL-F - channel enumeration error ACPI/firmware bug question

6 matches

Site Navigation

Mail list logo

Footer information