Reparenting a platform device

2012-04-05 Thread Thierry Reding
Hi, I have a device tree where I have a GART device and a DRM device which uses the GART. The GART is implemented by an IOMMU driver (tegra-gart) and requires the user device to be a child of the GART device (it explicitly checks for this when the user device is attached). I've tried two

Re: Reparenting a platform device

2012-04-05 Thread Thierry Reding
* Thierry Reding wrote: * Stephen Warren wrote: On 04/05/2012 02:42 AM, Thierry Reding wrote: Hi, I have a device tree where I have a GART device and a DRM device which uses the GART. The GART is implemented by an IOMMU driver (tegra-gart) and requires the user device

Re: Reparenting a platform device

2012-04-06 Thread Thierry Reding
* Stephen Warren wrote: I must admit I'm not at all familiar with the IOMMU APIs, but isn't the IOMMU driver/subsystem itself what is managing all the allocations and handing them out to clients? And client drivers do things like asking for N pages of memory mapped into their aperture? If that

Re: Reparenting a platform device

2012-04-07 Thread Thierry Reding
* Grant Likely wrote: On Thu, 5 Apr 2012 10:42:58 +0200, Thierry Reding thierry.red...@avionic-design.de wrote: Hi, I have a device tree where I have a GART device and a DRM device which uses the GART. The GART is implemented by an IOMMU driver (tegra-gart) and requires the user

Re: Reparenting a platform device

2012-04-08 Thread Thierry Reding
* Stephen Warren wrote: On 04/06/2012 01:20 AM, Thierry Reding wrote: * Stephen Warren wrote: I must admit I'm not at all familiar with the IOMMU APIs, but isn't the IOMMU driver/subsystem itself what is managing all the allocations and handing them out to clients? And client drivers do

[RFC 3/4] drm: fixed: Add dfixed_frac() macro

2012-04-11 Thread Thierry Reding
This commit is taken from the Chromium tree and was originally written by Robert Morell. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- include/drm/drm_fixed.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h index

[RFC 2/4] iommu: tegra/gart: Add device tree support

2012-04-11 Thread Thierry Reding
This commit adds device tree support for the GART hardware available on NVIDIA Tegra 20 SoCs. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/boot/dts/tegra20.dtsi |6 ++ arch/arm/mach-tegra/board-dt-tegra20.c |1 + drivers/iommu/tegra-gart.c

[RFC 1/4] iommu: tegra/gart: use correct gart_device

2012-04-11 Thread Thierry Reding
From: Vandana Salve vsa...@nvidia.com Pass the correct gart device pointer. Reviewed-by: Vandana Salve vsa...@nvidia.com Tested-by: Vandana Salve vsa...@nvidia.com Reviewed-by: Hiroshi Doyu hd...@nvidia.com Reviewed-by: Bharat Nihalani bnihal...@nvidia.com Signed-off-by: Hiroshi DOYU

[RFC 0/4] Add NVIDIA Tegra DRM support

2012-04-11 Thread Thierry Reding
. Thierry Thierry Reding (3): iommu: tegra/gart: Add device tree support drm: fixed: Add dfixed_frac() macro drm: Add NVIDIA Tegra support Vandana Salve (1): iommu: tegra/gart: use correct gart_device .../devicetree/bindings/gpu/drm/tegra.txt | 24 + arch/arm/boot/dts/tegra20

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

2012-04-11 Thread Thierry Reding
* Hiroshi Doyu wrote: From: Thierry Reding thierry.red...@avionic-design.de [...] Thierry Reding (3): iommu: tegra/gart: Add device tree support drm: fixed: Add dfixed_frac() macro drm: Add NVIDIA Tegra support Vandana Salve (1): iommu: tegra/gart: use correct gart_device

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

2012-04-11 Thread Thierry Reding
* Alan Cox wrote: On Wed, 11 Apr 2012 14:10:26 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It currently only supports the RGB output and I've successfully tested it against the fbcon kernel module

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-11 Thread Thierry Reding
* Daniel Vetter wrote: On Wed, Apr 11, 2012 at 04:11:08PM +0200, Thierry Reding wrote: * Daniel Vetter wrote: On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote: * Daniel Vetter wrote: On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote: This commit adds

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-11 Thread Thierry Reding
* Alan Cox wrote: Maybe your question is answered by my reply to Alan's comment. The mapping is actually done to get a linear view for the display controller which doesn't support SG transfers. The kernel and user-space already have virtual linear buffers. The framebuffer currently

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-12 Thread Thierry Reding
* Arnd Bergmann wrote: On Wednesday 11 April 2012, Thierry Reding wrote: Daniel Vetter wrote: Well, you use the iommu api to map/unmap memory into the iommu for tegra, whereas usually device drivers just use the dma api to do that. The usual interface is dma_map_sg/dma_unmap_sg

Re: [RFC 3/4] drm: fixed: Add dfixed_frac() macro

2012-04-12 Thread Thierry Reding
* Stephen Warren wrote: On 04/11/2012 06:10 AM, Thierry Reding wrote: This commit is taken from the Chromium tree and was originally written by Robert Morell. Maybe just cherry-pick it from there? That way, the git authorship will show up as Robert. I can do that. Though I'll have

Re: [RFC 2/4] iommu: tegra/gart: Add device tree support

2012-04-12 Thread Thierry Reding
* Stephen Warren wrote: On 04/11/2012 06:10 AM, Thierry Reding wrote: This commit adds device tree support for the GART hardware available on NVIDIA Tegra 20 SoCs. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/boot/dts/tegra20.dtsi |6

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-12 Thread Thierry Reding
* Sascha Hauer wrote: You might want to have a look at the sdrm patches I recently posted to dri-devel and arm Linux Kernel. Among other things they allow to register crtcs/connectors/encoders seperately so that each of them can have its own representation in the devicetree. I haven't looked

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-12 Thread Thierry Reding
* Marek Szyprowski wrote: [...] We already have dma_map_page() and dma_map_single() which are very similar. Maybe adding dma_map_pages() won't be such a bad idea? If not maybe we should provide some kind of helper functions which converts page array to scatterlist and then maps them.

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-12 Thread Thierry Reding
* Stephen Warren wrote: On 04/12/2012 12:50 AM, Thierry Reding wrote: drm { compatible = nvidia,tegra20-drm; I'm don't think having an explicit drm node is the right approach; drm is after all a SW term and the DT should be describing HW. Having some kind of top-level

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-13 Thread Thierry Reding
* Stephen Warren wrote: On 04/12/2012 11:44 AM, Thierry Reding wrote: [...] And given that, I don't think we should name the node after some OS-specific software concept. Device tree is intended to model hardware. [...] Maybe one solution would be to have a top-level DRM device

Re: [PATCH 1/1] iommu/tegra: smmu: Print device name correctly

2012-04-13 Thread Thierry Reding
* Hiroshi Doyu wrote: From: Hiroshi DOYU hd...@nvidia.com Print an attached device name correctly. Signed-off-by: Hiroshi DOYU hd...@nvidia.com Reviewed-by: Thierry Reding thierry.red...@avionic-design.de pgplzIzg1ZxMI.pgp Description: PGP signature

Re: [PATCH 1/1] iommu/tegra: Add device tree support for SMMU

2012-04-13 Thread Thierry Reding
* Hiroshi Doyu wrote: From: Hiroshi DOYU hd...@nvidia.com Add device tree support for Tegra30 IOMMU(SMMU). Signed-off-by: Hiroshi DOYU hd...@nvidia.com --- drivers/iommu/tegra-smmu.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) I would expect the binding

[PATCH 3/3] ARM: dt: tegra20: Add GART device

2012-04-13 Thread Thierry Reding
This commit adds the device node required to probe NVIDIA Tegra 20 GART hardware from the device tree. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/boot/dts/tegra20.dtsi |6 ++ arch/arm/mach-tegra/board-dt-tegra20.c |1 + 2 files changed, 7

[PATCH 1/3] iommu: tegra/gart: use correct gart_device

2012-04-13 Thread Thierry Reding
From: Vandana Salve vsa...@nvidia.com Pass the correct gart device pointer. Reviewed-by: Vandana Salve vsa...@nvidia.com Tested-by: Vandana Salve vsa...@nvidia.com Reviewed-by: Hiroshi Doyu hd...@nvidia.com Reviewed-by: Bharat Nihalani bnihal...@nvidia.com Signed-off-by: Hiroshi DOYU

[PATCH 2/3] iommu: tegra/gart: Add device tree support

2012-04-13 Thread Thierry Reding
This commit adds device tree support for the GART hardware available on NVIDIA Tegra 20 SoCs. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- .../devicetree/bindings/iommu/nvidia,tegra20-gart.txt| 14 ++ drivers/iommu/tegra-gart.c

Re: [PATCH 3/3] ARM: dt: tegra20: Add GART device

2012-04-14 Thread Thierry Reding
* Stephen Warren wrote: On 04/13/2012 07:08 AM, Thierry Reding wrote: This commit adds the device node required to probe NVIDIA Tegra 20 GART hardware from the device tree. diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c b/arch/arm/mach-tegra/board-dt-tegra20.c

[PATCH v2] ARM: dt: tegra20: Add GART device

2012-04-16 Thread Thierry Reding
This commit adds the device node required to probe NVIDIA Tegra 20 GART hardware from the device tree. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Changes in v2: - drop unneeded of_dev_auxdata entry arch/arm/boot/dts/tegra20.dtsi |6 ++ 1 file changed, 6

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-16 Thread Thierry Reding
* Stephen Warren wrote: On 04/15/2012 02:39 AM, Thierry Reding wrote: I think I like the former better. The way I understand it the children of the graphics node will have to be registered explicitly by the DRM driver because of_platform_populate() doesn't work recursively. That would

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

2012-04-16 Thread Thierry Reding
* Stephen Warren wrote: On 04/16/2012 12:48 PM, Thierry Reding wrote: * Stephen Warren wrote: ... Has there been any discussion as to how EDID data would best be represented in DT? Should it just be a binary blob or rather some textual representation? I think a binary blob makes

Re: [PATCH 1/1] arm/dts: Tegra30: Add device tree support for SMMU

2012-04-18 Thread Thierry Reding
* Hiroshi Doyu wrote: diff --git a/drivers/of/of_dma.c b/drivers/of/of_dma.c new file mode 100644 index 000..1db1ccd --- /dev/null +++ b/drivers/of/of_dma.c @@ -0,0 +1,35 @@ +/* + * Stealed from: Stolen from + * arch/microblaze/kernel/prom_parse.c + *

Re: [PATCH 1/1] dt: Add general DMA window parser

2012-04-18 Thread Thierry Reding
* Hiroshi Doyu wrote: diff --git a/drivers/of/of_dma.c b/drivers/of/of_dma.c new file mode 100644 index 000..45c9e88 --- /dev/null +++ b/drivers/of/of_dma.c @@ -0,0 +1,35 @@ +/* + * Stolen from: + * arch/microblaze/kernel/prom_parse.c + * arch/powerpc/kernel/prom_parse.c + */ +

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

2012-04-19 Thread Thierry Reding
* Dave Airlie wrote: On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Before posting the next round of patches I wanted to clarify whether we need to take the Tegra driver through staging. Lucas brought this up referring to previous experience

Re: [RFC v2 2/5] tps6586x: Add device tree support

2012-04-25 Thread Thierry Reding
* Thierry Reding wrote: * Mark Brown wrote: On Wed, Apr 25, 2012 at 11:44:59AM +0200, Thierry Reding wrote: This commit adds device tree support for the TPS6586x regulator. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de This looks basically good from a quick scan

Re: [RFC v2 3/5] i2c: Add of_i2c_get_adapter() function

2012-04-25 Thread Thierry Reding
* Stephen Warren wrote: On 04/25/2012 03:45 AM, Thierry Reding wrote: This function resolves an OF device node to an I2C adapter registered with the I2C core. I think this is doing the same thing as a patch I posted recently: http://www.spinics.net/lists/linux-i2c/msg07808.html I wasn't

Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support

2012-05-21 Thread Thierry Reding
* Terje Bergström wrote: On 21.05.2012 14:05, Thierry Reding wrote: I agree. It's really just a simple-bus kind of bus. Except that it'll need another compatible value to make the host1x driver bind to it. But we should be able to make it work without creating a completely new bus. I

Re: Tegra DRM device tree bindings

2012-06-26 Thread Thierry Reding
On Tue, Jun 26, 2012 at 04:02:24PM +0300, Hiroshi Doyu wrote: Hi Thierry, On Tue, 26 Jun 2012 12:55:13 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: * PGP Signed by an unknown key Hi, while I haven't got much time to work on the actual code right now, I think

Re: Tegra DRM device tree bindings

2012-06-26 Thread Thierry Reding
On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote: On 06/26/2012 08:32 PM, Mark Zhang wrote: On 06/26/2012 07:46 PM, Mark Zhang wrote: On Tue, 26 Jun 2012 12:55:13 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: ... I'm not sure I understand how information

Re: Tegra DRM device tree bindings

2012-06-27 Thread Thierry Reding
On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote: On Wed, 27 Jun 2012 07:14:18 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: * PGP Signed by an unknown key On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote: On 06/26/2012 08:32 PM, Mark Zhang

Re: Tegra DRM device tree bindings

2012-06-27 Thread Thierry Reding
On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote: On Wed, 27 Jun 2012 16:08:10 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: * PGP Signed by an unknown key On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote: On Wed, 27 Jun 2012 07:14:18 +0200

Re: Tegra DRM device tree bindings

2012-06-28 Thread Thierry Reding
On Wed, Jun 27, 2012 at 12:02:46PM -0600, Stephen Warren wrote: On 06/27/2012 06:44 AM, Hiroshi Doyu wrote: ... I think that there are 2 cases: (1) discontiguous memory with IOMMU (2) contiguous memory without IOMMU(called carveout in general?) ... For (2), although memory is

Re: Tegra DRM device tree bindings

2012-06-28 Thread Thierry Reding
On Thu, Jun 28, 2012 at 11:33:56AM -0600, Stephen Warren wrote: On 06/28/2012 11:19 AM, Lucas Stach wrote: ... CMA is just a way of providing large contiguous address space blocks in a dynamic fashion. ... TTM though solves more advanced matters, like buffer synchronisation between 3D

Re: Tegra DRM device tree bindings

2012-06-30 Thread Thierry Reding
On Fri, Jun 29, 2012 at 04:20:31PM +0300, Terje Bergström wrote: On 28.06.2012 20:19, Lucas Stach wrote: TTM though solves more advanced matters, like buffer synchronisation between 3D and 2D block of hardware or syncing buffer access between GPU and CPU. One of the most interesting

Re: Tegra DRM device tree bindings

2012-06-30 Thread Thierry Reding
On Thu, Jun 28, 2012 at 10:46:58AM -0600, Stephen Warren wrote: On 06/28/2012 12:18 AM, Hiroshi Doyu wrote: On Wed, 27 Jun 2012 16:44:14 +0200 Thierry Reding thierry.red...@avionic-design.de wrote: I think that coherent_pool can be used only when the amount of contiguous memory

[PATCH 1/2] iommu: Include linux/types.h

2012-07-25 Thread Thierry Reding
The linux/iommu.h header uses types defined in linux/types.h but doesn't include it. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- include/linux/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index a71df92..9cbcc6a

[PATCH 2/2] iommu: Include linux/notifier.h

2012-07-25 Thread Thierry Reding
The linux/iommu.h header uses types defined in linux/notifier.h but doesn't include it. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- include/linux/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 9cbcc6a

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.

[PATCH 13/33] iommu: Convert to devm_ioremap_resource()

2013-01-21 Thread Thierry Reding
Convert all uses of devm_request_and_ioremap() to the newly introduced devm_ioremap_resource() which provides more consistent error handling. devm_ioremap_resource() provides its own error messages so all explicit error messages can be removed from the failure code paths. Signed-off-by: Thierry

Re: [PATCH 03/23] ARM: dt: tegra30: iommu: Add nvidia,memory-clients

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote: Add nvidia,memory-clients to identify which swgroup ID a device belongs to. Why not call the property nvidia,swgid instead? That seems a lot more intuitive. Thierry pgpsrF4R4_pOe.pgp Description: PGP signature

Re: [PATCH 01/23] ARM: tegra: Create a DT header defining swgroups ID

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:04PM +0300, Hiroshi Doyu wrote: [...] +#define SWGID_AFI 0 +#define SWGID_AVPC 1 +#define SWGID_DC 2 +#define SWGID_DCB 3 +#define SWGID_EPP 4 +#define SWGID_G2 5 +#define SWGID_HC 6 +#define SWGID_HDA 7 +#define SWGID_ISP 8 +#define SWGID_ISP2 SWGID_ISP

Re: [PATCH 18/23] iommu/tegra: smmu: Workaround PCIe IOMMU'able

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 01:09:06PM +0200, Hiroshi Doyu wrote: Thierry Reding thierry.red...@gmail.com wrote @ Wed, 26 Jun 2013 13:06:27 +0200: * PGP Signed by an unknown key On Wed, Jun 26, 2013 at 12:28:21PM +0300, Hiroshi Doyu wrote: Make PCIe work as it is. IOMMU support can

Re: [PATCH 19/23] iommu/tegra: smmu: Unfied driver for Tegra SoCs

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:22PM +0300, Hiroshi Doyu wrote: Support multiple generation of Tegra SoCs with this unified SMMU driver. Necessary info is expected to be passed from DT. Signed-off-by: Hiroshi Doyu hd...@nvidia.com --- drivers/iommu/tegra-smmu.c | 80

Re: [PATCH 11/23] iommu/tegra: smmu: Add of_mach_id for T114

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:14PM +0300, Hiroshi Doyu wrote: Add of_mach_id for T114 I don't think of_mach_id is the right word. Why not use a subject such as iommu/tegra: smmu: Add Tegra114 support. And instead of duplicating the subject in the commit message, perhaps you can say instead that

Re: [PATCH 18/23] iommu/tegra: smmu: Workaround PCIe IOMMU'able

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:21PM +0300, Hiroshi Doyu wrote: Make PCIe work as it is. IOMMU support can be implemented later. Signed-off-by: Hiroshi Doyu hd...@nvidia.com --- drivers/iommu/tegra-smmu.c | 3 +++ 1 file changed, 3 insertions(+) Can you provide more information about what

Re: [PATCH 03/23] ARM: dt: tegra30: iommu: Add nvidia,memory-clients

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote: [...] diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt [...] @@ -23,3 +24,13 @@ Example: nvidia,swgroups = 0x

Re: [PATCH 17/23] iommu/tegra: smmu: Use swgroups instead of pdata

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:20PM +0300, Hiroshi Doyu wrote: Instead of using platfrom data, DT passes nvidia,swgroups. Signed-off-by: Hiroshi Doyu hd...@nvidia.com --- drivers/iommu/tegra-smmu.c | 24 +++- 1 file changed, 7 insertions(+), 17 deletions(-) Could this

Re: [PATCH 03/23] ARM: dt: tegra30: iommu: Add nvidia,memory-clients

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:18:17PM +0200, Thierry Reding wrote: On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote: [...] diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt

Re: [PATCH 21/23] iommu/tegra: smmu: Get swgroup ID from DT

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:24PM +0300, Hiroshi Doyu wrote: Get swgroup ID from DT. nvidia,swgroups indicates which swgroup IDs a device belongs to. Signed-off-by: Hiroshi Doyu hd...@nvidia.com --- arch/arm/boot/dts/tegra30.dtsi | 1 - drivers/iommu/tegra-smmu.c | 20

Re: [PATCH 02/23] ARM: dt: tegra30: iommu: Add nvidia,swgroups

2013-06-27 Thread Thierry Reding
On Wed, Jun 26, 2013 at 12:28:05PM +0300, Hiroshi Doyu wrote: This is a bitmap that indicates which HardWare Accelerators(HWA) are supported on Tegra30 SoC. Signed-off-by: Hiroshi Doyu hd...@nvidia.com --- Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt | 6 +-

Re: [PATCH v2 01/22] [HACK] of: dev_node has struct device pointer

2013-07-16 Thread Thierry Reding
On Tue, Jul 16, 2013 at 04:57:03PM -0600, Stephen Warren wrote: On 07/05/2013 04:44 AM, Hiroshi Doyu wrote: To prevent of_platform_populate() from trying to populate duplicate devices if a device has been already populated. You need to send drivers/of patches to the DT maintainer and

Re: [PATCH v2 06/22] ARM: dt: tegra114: iommu: Fix IOMMU register address

2013-07-16 Thread Thierry Reding
On Tue, Jul 16, 2013 at 05:18:29PM -0600, Stephen Warren wrote: On 07/05/2013 04:44 AM, Hiroshi Doyu wrote: Fix IOMMU register address. Oh dear, how serious is this? That incorrect node got added in v3.9 - a long time ago. Does the SMMU driver touch registers during probe() or under any

[PATCH] iommu/tegra: Print phys_addr_t using %pa

2013-09-17 Thread Thierry Reding
When enabling LPAE on ARM, phys_addr_t becomes 64 bits wide and printing a variable of that type using a simple %x format specifier causes the compiler to complain. Change the format specifier to %pa, which is used specifically for variables of type phys_addr_t. Signed-off-by: Thierry Reding tred

Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

2013-10-25 Thread Thierry Reding
On Fri, Oct 25, 2013 at 01:10:38AM +0100, Grant Likely wrote: On Thu, 24 Oct 2013 11:21:15 +0200, Hiroshi Doyu hd...@nvidia.com wrote: Hi Grant, Grant Likely grant.lik...@linaro.org wrote @ Thu, 24 Oct 2013 10:55:31 +0200: diff --git a/include/linux/of.h b/include/linux/of.h

Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

2013-10-25 Thread Thierry Reding
On Fri, Oct 25, 2013 at 10:25:49AM +0200, Hiroshi Doyu wrote: Thierry Reding thierry.red...@gmail.com wrote @ Fri, 25 Oct 2013 09:56:55 +0200: This patch is a part of HACK to control device instanciation order. We have an IOMMU device(platform) which needs to be instanciated earlier

Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

2013-10-25 Thread Thierry Reding
On Fri, Oct 25, 2013 at 11:49:05AM +0200, Hiroshi Doyu wrote: Thierry Reding thierry.red...@gmail.com wrote @ Fri, 25 Oct 2013 11:11:05 +0200: This is actually the other problem that I'm aware of that could benefit from [interrupt resolution at probe time]. My idea was that once we

Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

2013-10-25 Thread Thierry Reding
On Fri, Oct 25, 2013 at 02:20:51PM +0100, Will Deacon wrote: On Fri, Oct 25, 2013 at 09:22:02AM +0100, Hiroshi Doyu wrote: Thierry Reding thierry.red...@gmail.com wrote @ Fri, 25 Oct 2013 09:56:55 +0200: I suspect that there will be enough differences between the various IOMMU

Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

2013-11-01 Thread Thierry Reding
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 swar...@wwwdotorg.org wrote @ Thu, 31 Oct 2013 17:35:24 +0100: ... ... and for the driver to explicitly parse that property, and wait until the driver for

Re: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs

2013-11-19 Thread Thierry Reding
On Tue, Nov 19, 2013 at 11:33:06AM +0200, Hiroshi Doyu wrote: IOMMU devices on the bus need to be poplulated first, then iommu master devices are done later. With CONFIG_OF_IOMMU, iommus= DT binding would be used to identify whether a device can be an iommu msater or not. If a device can,

Re: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs

2013-11-20 Thread Thierry Reding
On Wed, Nov 20, 2013 at 04:17:08AM +0100, Hiroshi Doyu wrote: Stephen Warren swar...@wwwdotorg.org wrote @ Tue, 19 Nov 2013 22:22:47 +0100: On 11/19/2013 05:03 AM, Hiroshi Doyu wrote: Hi Thierry, Thierry Reding thierry.red...@gmail.com wrote @ Tue, 19 Nov 2013 11:25:07 +0100

Re: Report from 2013 ARM kernel summit

2013-11-20 Thread Thierry Reding
On Wed, Nov 20, 2013 at 10:31:11AM +, Will Deacon wrote: On Tue, Nov 19, 2013 at 08:45:02PM +, Rob Herring wrote: On 11/19/2013 11:35 AM, Will Deacon wrote: Adding Andreas and Rob for input on potential binding additions to the SMMU. The above proposal would be an

Re: [PATCHv7 04/12] driver/core: populate devices in order for IOMMUs

2013-12-14 Thread Thierry Reding
On Thu, Dec 12, 2013 at 06:14:02PM -0800, Greg KH wrote: On Thu, Dec 12, 2013 at 11:39:20AM +, Grant Likely wrote: On Thu, 12 Dec 2013 09:57:05 +0200, Hiroshi Doyu hd...@nvidia.com wrote: IOMMU devices on the bus need to be poplulated first, then iommu master devices are done later.

Re: [PATCHv7 06/12] ARM: tegra: create a DT header defining SWGROUP ID

2013-12-20 Thread Thierry Reding
On Wed, Dec 18, 2013 at 09:27:29AM -0700, Stephen Warren wrote: On 12/18/2013 01:02 AM, Mark Zhang wrote: On 12/12/2013 03:57 PM, Hiroshi Doyu wrote: Create a header file to define the swgroup IDs used by the IOMMU(SMMU) binding. swgroup is a group of H/W clients which a Tegra SoC

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

2014-04-28 Thread Thierry Reding
On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote: On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote: +- mmu-masters: A phandle to device nodes representing the master for which + the System MMU can provide a translation. Any additional values +

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

2014-04-28 Thread Thierry Reding
On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote: On Monday 28 April 2014 12:39:20 Thierry Reding wrote: On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote: On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote: +- mmu-masters: A phandle to device nodes

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

2014-04-28 Thread Thierry Reding
On Mon, Apr 28, 2014 at 02:05:30PM +0200, Arnd Bergmann wrote: On Monday 28 April 2014 13:18:03 Thierry Reding wrote: On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote: On Monday 28 April 2014 12:39:20 Thierry Reding wrote: And possibly with a iommu-names property to go along

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

2014-05-15 Thread Thierry Reding
On Mon, Apr 28, 2014 at 02:05:30PM +0200, Arnd Bergmann wrote: [...] let me clarify by example: iommu@1 { compatible = some,simple-iommu; reg = 1; #iommu-cells = 0; /* supports only one master */ }; iommu@2 {

[PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-16 Thread Thierry Reding
From: Thierry Reding tred...@nvidia.com 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 SMMU as discussed here: https://lkml.org/lkml/2014

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-17 Thread Thierry Reding
On Sat, May 17, 2014 at 05:04:55PM +0900, Cho KyongHo wrote: On Fri, 16 May 2014 14:23:18 +0200, Thierry Reding wrote: [...] +Examples: += + +Single-master IOMMU: + + + iommu { + #iommu-cells = 0; + }; + + master

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-19 Thread Thierry Reding
On Mon, May 19, 2014 at 12:26:35PM +0200, Arnd Bergmann wrote: On Friday 16 May 2014 14:23:18 Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com This commit introduces a generic device tree binding for IOMMU devices. Only a very minimal subset is described here

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-19 Thread Thierry Reding
On Mon, May 19, 2014 at 06:22:31PM +0100, Dave Martin wrote: On Mon, May 19, 2014 at 01:53:37PM +0100, Thierry Reding wrote: [...] My understanding here is mostly based on the OpenFirmware working group proposal for the dma-ranges property[0]. I'll give another example to try and clarify

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-19 Thread Thierry Reding
On Mon, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann wrote: On Monday 19 May 2014 14:53:37 Thierry Reding wrote: On Mon, May 19, 2014 at 12:26:35PM +0200, Arnd Bergmann wrote: On Friday 16 May 2014 14:23:18 Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-20 Thread Thierry Reding
On Tue, May 20, 2014 at 01:15:48PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 13:05:37 Thierry Reding wrote: On Tue, May 20, 2014 at 12:04:54PM +0200, Arnd Bergmann wrote: On Monday 19 May 2014 22:59:46 Thierry Reding wrote: On Mon, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-20 Thread Thierry Reding
On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote: [...] Couldn't a single-master IOMMU be windowed? Ah, yes. That would actually be like an IBM pSeries, which has a windowed IOMMU but uses one window per virtual machine

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-20 Thread Thierry Reding
On Tue, May 20, 2014 at 03:34:46PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 15:17:43 Thierry Reding wrote: On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote: [...] Couldn't a single-master IOMMU be windowed

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-21 Thread Thierry Reding
On Tue, May 20, 2014 at 10:31:29PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 16:00:02 Thierry Reding wrote: On Tue, May 20, 2014 at 03:34:46PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 15:17:43 Thierry Reding wrote: On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-21 Thread Thierry Reding
On Tue, May 20, 2014 at 10:26:12PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 16:24:59 Dave Martin wrote: On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote: [...] Multiple-master IOMMU

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-21 Thread Thierry Reding
On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote: On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote: On Tue, May 20, 2014 at 10:26:12PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 16:24:59 Dave Martin wrote: On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-21 Thread Thierry Reding
On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote: On Wednesday 21 May 2014 10:16:09 Thierry Reding wrote: On Tue, May 20, 2014 at 10:31:29PM +0200, Arnd Bergmann wrote: On Tuesday 20 May 2014 16:00:02 Thierry Reding wrote: On Tue, May 20, 2014 at 03:34:46PM +0200, Arnd

Re: [PATCH] devicetree: Add generic IOMMU device tree bindings

2014-05-21 Thread Thierry Reding
On Wed, May 21, 2014 at 11:36:32AM +0200, Arnd Bergmann wrote: On Wednesday 21 May 2014 11:00:38 Thierry Reding wrote: On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote: On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote: For determining dma masks, it is the output

[PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-05-23 Thread Thierry Reding
From: Thierry Reding tred...@nvidia.com 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 SMMU as discussed here: https://lkml.org/lkml/2014

[PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-05-23 Thread Thierry Reding
From: Thierry Reding tred...@nvidia.com 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 SMMU as discussed here: https://lkml.org/lkml/2014

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-06-04 Thread Thierry Reding
On Sun, Jun 01, 2014 at 10:55:46AM +0100, Will Deacon wrote: On Fri, May 30, 2014 at 08:54:37PM +0100, Arnd Bergmann wrote: On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote: Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64 bit) to afford 64 stream IDs so that a

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-06-04 Thread Thierry Reding
On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote: On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote: IIUC the original problem, a master with 8 streamIDs means something like below, where some devices have multiple IDs but some have a single. A sinle #address-cells cannot

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-06-04 Thread Thierry Reding
On Fri, May 30, 2014 at 09:01:19PM +0200, Arnd Bergmann wrote: On Friday 30 May 2014 12:22:32 Dave Martin wrote: + +Examples: += + +Single-master IOMMU: + + + iommu { + #address-cells = 0; + #size-cells = 0; + }; +

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-06-09 Thread Thierry Reding
On Sat, Jun 07, 2014 at 03:22:13PM +0200, Arnd Bergmann wrote: On Saturday 07 June 2014 00:45:45 Thierry Reding wrote: This is somewhat off-topic, but given the various concepts discussed in this thread I'm beginning to wonder how they will be implemented. I think it's good you raised

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-06-17 Thread Thierry Reding
On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote: On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote: On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote: On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote: [...] Arnd, can you take another

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

2014-06-17 Thread Thierry Reding
On Tue, Jun 17, 2014 at 01:18:11PM +0100, Will Deacon wrote: On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote: On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote: On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote: It can easily be argued

[PATCH] iommu: Constify struct iommu_ops

2014-06-26 Thread Thierry Reding
From: Thierry Reding tred...@nvidia.com This structure is read-only data and should never be modified. Signed-off-by: Thierry Reding tred...@nvidia.com --- drivers/iommu/amd_iommu.c | 4 ++-- drivers/iommu/arm-smmu.c| 2 +- drivers/iommu/exynos-iommu.c| 2 +- drivers/iommu

[RFC 05/10] ARM: tegra: Add memory controller on Tegra124

2014-06-26 Thread Thierry Reding
From: Thierry Reding tred...@nvidia.com Add the memory controller and wire up the interrupt that is used to report errors. Also add an #iommu-cells property to make the device as an IOMMU. Signed-off-by: Thierry Reding tred...@nvidia.com --- arch/arm/boot/dts/tegra124.dtsi | 9 + 1 file

[RFC 01/10] iommu: Add IOMMU device registry

2014-06-26 Thread Thierry Reding
From: Thierry Reding tred...@nvidia.com Add an IOMMU device registry for drivers to register with and implement a method for users of the IOMMU API to attach to an IOMMU device. This allows to support deferred probing and gives the IOMMU API a convenient hook to perform early initialization

[RFC 03/10] of: Add NVIDIA Tegra124 memory controller binding

2014-06-26 Thread Thierry Reding
From: Thierry Reding tred...@nvidia.com The memory controller on NVIDIA Tegra124 exposes various knobs that can be used to tune the behaviour of the clients attached to it. In addition, the memory controller implements an SMMU (IOMMU) which can translate I/O virtual addresses to physical

  1   2   3   4   5   6   >