Re: [PATCH 2/2] ARM: Exynos4: update SYSMMU setup code for gen_pd power domain driver
On Wed, Apr 11, 2012 at 11:34 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: SYSMMU platform devices must be registered before setting up power domains to let power domain driver to correctly register also SYSMMU controller devices. This patch also registers SYSMMU controller devices to respective power domains. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/dev-sysmmu.c | 6 +- arch/arm/mach-exynos/pm_domains.c | 13 + 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/dev-sysmmu.c b/arch/arm/mach-exynos/dev-sysmmu.c index c5b1ea3..3544638 100644 --- a/arch/arm/mach-exynos/dev-sysmmu.c +++ b/arch/arm/mach-exynos/dev-sysmmu.c @@ -271,4 +271,8 @@ static int __init init_sysmmu_platform_device(void) return 0; } -arch_initcall(init_sysmmu_platform_device); +/* + * SYSMMU platform devices must be registered before power domains + * see pm_domain.c, which use arch_initcall() + */ +core_initcall(init_sysmmu_platform_device); I don't understand why init_sysmmu_platform_device() must be called before exynos4_pm_init_power_domain()? Other devices also added by an arch_initcall() function which calls mdesc-init_machine(). I also was unable to find any reason to add devices before registering the devices to pm domain. Regards, KyongHo. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/2] ARM: Exynos4: update SYSMMU setup code for gen_pd power domain driver
Hi, On Monday, April 16, 2012 12:10 PM KyongHo Cho wrote: On Wed, Apr 11, 2012 at 11:34 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: SYSMMU platform devices must be registered before setting up power domains to let power domain driver to correctly register also SYSMMU controller devices. This patch also registers SYSMMU controller devices to respective power domains. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/dev-sysmmu.c | 6 +- arch/arm/mach-exynos/pm_domains.c | 13 + 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/dev-sysmmu.c b/arch/arm/mach-exynos/dev-sysmmu.c index c5b1ea3..3544638 100644 --- a/arch/arm/mach-exynos/dev-sysmmu.c +++ b/arch/arm/mach-exynos/dev-sysmmu.c @@ -271,4 +271,8 @@ static int __init init_sysmmu_platform_device(void) return 0; } -arch_initcall(init_sysmmu_platform_device); +/* + * SYSMMU platform devices must be registered before power domains + * see pm_domain.c, which use arch_initcall() + */ +core_initcall(init_sysmmu_platform_device); I don't understand why init_sysmmu_platform_device() must be called before exynos4_pm_init_power_domain()? Other devices also added by an arch_initcall() function which calls mdesc-init_machine(). I also was unable to find any reason to add devices before registering the devices to pm domain. mdesc-init_machine is called before exynos4_pm_init_power_domain() from arch/arm/mach-exynos/pm_domain.c, although both are started from arch_initcall. In this case the order of linking defines the order of calls. exynos4_pm_init_power_domain() calls exynos_pm_add_dev_to_genpd() which in turn checks for pdev-dev.bus. All devices which have not been registered yet on the bus are simply skipped. Best regards -- Marek Szyprowski Samsung Poland RD Center ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/tegra: smmu: Print device name correctly
On Fri, Apr 13, 2012 at 12:18:30PM +0200, Hiroshi Doyu wrote: From: Hiroshi DOYU hd...@nvidia.com Print an attached device name correctly. Signed-off-by: Hiroshi DOYU hd...@nvidia.com --- drivers/iommu/tegra-smmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c index f4d859f..bf33c03 100644 --- a/drivers/iommu/tegra-smmu.c +++ b/drivers/iommu/tegra-smmu.c @@ -734,7 +734,7 @@ static int smmu_iommu_attach_dev(struct iommu_domain *domain, pr_info(Reserve \page zero\ for AVP vectors using a common dummy\n); } - dev_dbg(smmu-dev, %s is attached\n, dev_name(c-dev)); + dev_dbg(smmu-dev, %s is attached\n, dev_name(dev)); return 0; err_client: Applied, thanks. -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] arm/dts: Tegra30: Add device tree support for SMMU
From: Stephen Warren swar...@wwwdotorg.org
Subject: Re: [PATCH 1/1] arm/dts: Tegra30: Add device tree support for SMMU
Date: Fri, 13 Apr 2012 21:25:20 +0200
Message-ID: 4f887da0.8030...@wwwdotorg.org
On 04/13/2012 06:15 AM, Thierry Reding wrote:
* Hiroshi Doyu wrote:
Thierry Reding wrote:
* Hiroshi Doyu wrote:
+smmu: smmu@7000f000 {
+compatible = nvidia,tegra30-smmu;
+reg = 0x7000f000 0x400/* controller registers
*/
+0x6000c000 0x150/* AHB Arbitration
registers */
+0x1000 0x3000 ;/* Virtual address
space range
+ * Exclude the 1st
last page
+ */
+interrupts = 0 13 0x40 ;
+};
};
Why is the virtual address space range limited to 1 GiB? What is the
reason
for the exclusion of the first and last pages?
It's because physical RAM is located 2-4GB, and we may want to use
those area 1-1(V==P) mapping in some cases. This could be extended
with larger RAM without 1-1 mapping theoretically. So far 1GB seems to
be enough.
I'm thinking that this would be better off in a separate property so that
it's easier for boards to override it.
Yes, and for another reason: The entries in the reg property are
supposed to be within the bus address space that contains the device,
whereas here this 3rd reg entry is being used to define something about
an entirely unrelated address space - the virtual address space seen by
SMMU clients.
What about using dma-window property to specify IOVA range in dtsi as below?
arch/powerpc/platforms/cell/iommu.c:
698 static int __init cell_iommu_get_window(struct device_node *np,
699 unsigned long *base,
700 unsigned long *size)
701 {
702 const void *dma_window;
703 unsigned long index;
704
705 /* Use ibm,dma-window if available, else, hard code ! */
706 dma_window = of_get_property(np, ibm,dma-window, NULL);
707 if (dma_window == NULL) { ^^
708 *base = 0;
709 *size = 0x8000u;
710 return -ENODEV;
711 }
712
713 of_parse_dma_window(np, dma_window, index, base, size);
714 return 0;
715 }
The 1st page for AVP vector, and the last one is required by another
H/W entity.
I would expect such peculiarities to be handled by the driver internally.
That way users wouldn't have to know or care about these kind of details.
If it can't be handled by the driver then at least it should be mentioned
explicitly in the binding documentation.
I agree, but:
Why do those pages even need special handling? Doesn't the AVP get its
own address space ID, and then can set it up however it wants?
This sounds better than dealing with prefixed mappings at booting. At
least we need to pass # of ASIDs, and client should claim one of them.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] iommu: tegra/gart: use correct gart_device
Applied patches 1 and 2. Should I also queue up patch 3 after the objections have been fixed? The patch doesn't touch drivers/iommu... Joerg On Fri, Apr 13, 2012 at 03:08:07PM +0200, Thierry Reding wrote: 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 hd...@nvidia.com --- drivers/iommu/tegra-gart.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c index 779306e..f6bc1e6 100644 --- a/drivers/iommu/tegra-gart.c +++ b/drivers/iommu/tegra-gart.c @@ -158,7 +158,7 @@ static int gart_iommu_attach_dev(struct iommu_domain *domain, struct gart_client *client, *c; int err = 0; - gart = dev_get_drvdata(dev-parent); + gart = gart_handle; if (!gart) return -EINVAL; domain-priv = gart; -- 1.7.10 -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/2] Exynos: fix SYSMMU driver to work with power domains
Hello Marek, I have tested these patches on origen 3.4-rc2 with sysmmu_v12, and they work great ! Thank you for sharing them. Regards, Subash On 04/11/2012 08:04 PM, Marek Szyprowski wrote: Hi! These two patches fixes operation of the SYSMMU driver (v12 version [1]) with the new power domain driver based on generic power domains and runtime pw, which has been merged to Linux kernel v3.4-rc1. [1] https://lkml.org/lkml/2012/3/15/51 Best regards Marek Szyprowski Samsung Poland RD Center Patch summary: Marek Szyprowski (2): iommu/exynos: fix runtime pm support ARM: Exynos4: update SYSMMU setup code for gen_pd power domain driver arch/arm/mach-exynos/dev-sysmmu.c |6 +- arch/arm/mach-exynos/pm_domains.c | 13 + drivers/iommu/exynos-iommu.c | 20 ++-- 3 files changed, 36 insertions(+), 3 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] ARM: dt: tegra20: Add GART device
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 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 55b28fd..cf3ff41 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -212,5 +212,11 @@
interrupts = 0 97 0x04 ;
phy_type = utmi;
};
+
+ gart: gart@7000f000 {
+ compatible = nvidia,tegra20-gart;
+ reg = 0x7000f000 0x0100/* controller registers */
+ 0x5800 0x0200 ; /* GART aperture */
+ };
};
--
1.7.10
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On 04/15/2012 02:39 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 04/13/2012 03:14 AM, Thierry Reding wrote:
display-controllers = disp1 disp2;
outputs = lvds hdmi tvo dsi;
I don't think you need both the child nodes and those two properties.
In other words, I think you either want:
graphics@5400 {
... a bunch of child nodes
};
or you want:
disp1 : dc@5420 {
...
};
disp2 : dc@5424 {
...
};
... all the other graphics nodes
graphics@5400 {
display-controllers = disp1 disp2;
outputs = lvds hdmi tvo dsi;
};
In the former case, presumably the drivers for the child nodes would
make some API call into the parent node and just register themselves
directly as a certain type of driver, so avoiding the
display-controllers/outputs properties.
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 ensure that the
DRM driver can setup the CRTC and output registries before the other devices
call back into the DRM to register themselves.
Yes, with the first way, the DRM driver will have to call
of_platform_populate() recursively to make this work.
The thing here is that the device tree should model hardware, not be
designed purely to match the device registration needs of the DRM
driver. I'm not sure that it's correct to model all those devices as
children of the top-level graphics object; I /think/ all the devices are
flat on a single bus, and hence not children of each-other. That all
said, I guess having the nodes as children isn't too far off how the HW
is designed (even if the register accesses aren't on a child bus, the
modules at least logically are grouped together in an umbrella
situation), so I wouldn't push back on the first option above that you
prefer.
/* initial configuration */
configuration {
lvds {
display-controller = disp1;
output = lvds;
};
hdmi {
display-controller = disp2;
output = hdmi;
};
};
};
I added an additional node for the initial configuration so that the driver
knows which mapping to setup at boot.
Isn't that kind of thing usually set up by the video= KMS-related kernel
command-line option? See Documentation/fb/modedb.txt. Again here, I
think the actual display controllers would be allocated to whichever
outputs get used on a first-come first-serve based, so no need for the
display-controller property above either way.
Boards should still be able to boot and display a console on the standard
output even if the user doesn't provide a video= option. Shouldn't there be a
way for a board DTS to specify what the default (or even allowed) connections
are?
Why wouldn't the default be to light up all outputs that have an
attached display, or an algorithm something like:
* If internal LCD is present, use that
* Else, if HDMI display plugged in, use that
...
Evaluation hardware like the Harmony might have LVDS, HDMI and VGA connectors
to provide for a wide range of use cases. The Plutux for instance has only an
HDMI connector and the Medcom has only LVDS. For the Medcom it would be quite
confusing for people to suddenly see an HDMI-1 connector pop up f.e. in
xrandr. It would be equally useless for the Plutux to show up as supporting
an LVDS or VGA connector.
So the device tree for those devices would disable (or not include) the
connectors that were not present on the board.
...
I see. Maybe this could be used for board-specific configuration? For
example, the Plutux could have something like this:
connectors {
hdmi {
output = hdmi;
ddc = i2c2;
};
};
The Medcom could have:
connectors {
lvds {
output = lvds;
edid = edid;
};
};
While Harmony could be more generic and provide more outputs:
connectors {
lvds {
output = lvds;
ddc = i2c1;
};
vga {
/* which output is used for VGA? */
output = ...;
ddc = i2c2;
hdmi {
output = hdmi;
ddc = i2c3;
};
};
That looks like a reasonable start.
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
Re: [PATCH 1/3] iommu: tegra/gart: use correct gart_device
On 04/16/2012 05:59 AM, Joerg Roedel wrote: Applied patches 1 and 2. Should I also queue up patch 3 after the objections have been fixed? The patch doesn't touch drivers/iommu... I expect I'd take that through the Tegra tree to minimize conflicts. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] ARM: dt: tegra20: Add GART device
On 04/16/2012 09:04 AM, Thierry Reding wrote: 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 Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* 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 ensure that the DRM driver can setup the CRTC and output registries before the other devices call back into the DRM to register themselves. Yes, with the first way, the DRM driver will have to call of_platform_populate() recursively to make this work. The thing here is that the device tree should model hardware, not be designed purely to match the device registration needs of the DRM driver. I'm not sure that it's correct to model all those devices as children of the top-level graphics object; I /think/ all the devices are flat on a single bus, and hence not children of each-other. That all said, I guess having the nodes as children isn't too far off how the HW is designed (even if the register accesses aren't on a child bus, the modules at least logically are grouped together in an umbrella situation), so I wouldn't push back on the first option above that you prefer. After trying to implement this I'm not so sure anymore that this is the best approach. I think I'll have to play around with this some more to see what fits best. Boards should still be able to boot and display a console on the standard output even if the user doesn't provide a video= option. Shouldn't there be a way for a board DTS to specify what the default (or even allowed) connections are? Why wouldn't the default be to light up all outputs that have an attached display, or an algorithm something like: * If internal LCD is present, use that * Else, if HDMI display plugged in, use that ... That sounds doable. Evaluation hardware like the Harmony might have LVDS, HDMI and VGA connectors to provide for a wide range of use cases. The Plutux for instance has only an HDMI connector and the Medcom has only LVDS. For the Medcom it would be quite confusing for people to suddenly see an HDMI-1 connector pop up f.e. in xrandr. It would be equally useless for the Plutux to show up as supporting an LVDS or VGA connector. So the device tree for those devices would disable (or not include) the connectors that were not present on the board. Okay, makes sense. 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 sense - that's the exact same format it'd have if read over the DDC I2C bus. DTC has /incbin/ for that. Is arch/arm/boot/dts still the correct place for EDID blobs? I could add tegra-medcom.edid if that's okay. Thierry pgpHj7Wa0zx4D.pgp Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
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 sense - that's the exact same format it'd have if read over the DDC I2C bus. DTC has /incbin/ for that. Is arch/arm/boot/dts still the correct place for EDID blobs? I could add tegra-medcom.edid if that's okay. As far as I know, yes. Perhaps we'll want to start putting stuff in SoC-specific sub-directories given the number of files we'll end up with here (irrespective of EDID etc.), but I haven't seen any move towards that yet. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* 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 sense - that's the exact same format it'd have if read over the DDC I2C bus. DTC has /incbin/ for that. Is arch/arm/boot/dts still the correct place for EDID blobs? I could add tegra-medcom.edid if that's okay. As far as I know, yes. Perhaps we'll want to start putting stuff in SoC-specific sub-directories given the number of files we'll end up with here (irrespective of EDID etc.), but I haven't seen any move towards that yet. Yes, especially as more machines are moving to DT that directory will soon become quite cluttered. I suppose a tegra subdirectory wouldn't hurt. I've been looking about for tools to generate EDID data but didn't find anything useful. Does anyone know of any tool that's more convenient than manually filling a struct edid and writing that to a file? Thierry pgpF139gJ4WaT.pgp Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
