RE: [PATCHv8 04/10] ARM: dma-mapping: remove offset parameter to prepare for generic dma_ops
Hi Arnd, On Tuesday, April 10, 2012 1:43 PM Arnd Bergmann wrote: On Tuesday 10 April 2012, Marek Szyprowski wrote: This patch removes the need for offset parameter in dma bounce functions. This is required to let dma-mapping framework on ARM architecture use common, generic dma-mapping helpers. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com This one worries me a little. I always thought that the range sync functions were specifically needed for the dmabounce code. At the very least, I would expect the changeset comment to have an explanation of why this was initially done this way and why it's now safe to do do it otherwise. Well, range sync functions are available from the early days of the dma mapping api (at least that's what I've found reading the change log and old patches). They are the correct way of doing a partial syncs on the buffer (usually used by the network device drivers). This patch changes only the internal implementation of the dma bounce functions to let them tunnel through dma_map_ops structure. The driver api stays unchanged, so driver are obliged to call dma_*_range_* functions to keep code clean and easy to understand. The only drawback I can see from this patch is reduced detection of the dma api abuse. Let us consider the following code: dma_addr = dma_map_single(dev, ptr, 64, DMA_TO_DEVICE); dma_sync_single_range_for_cpu(dev, dma_addr+16, 0, 32, DMA_TO_DEVICE); Without the patch such code fails, because dma bounce code is unable to find the bounce buffer for the given dma_address. After the patch the sync call will be equivalent to: dma_sync_single_range_for_cpu(dev, dma_addr, 16, 32, DMA_TO_DEVICE); which succeeds. I don't consider this as a real problem. DMA API abuse should be caught by debug_dma_* function family, so we can simplify the internal low-level implementation without losing anything. Best regards -- Marek Szyprowski Samsung Poland RD Center ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCHv8 05/10] ARM: dma-mapping: use asm-generic/dma-mapping-common.h
Hi Arnd, On Tuesday, April 10, 2012 1:47 PM Arnd Bergmann wrote: On Tuesday 10 April 2012, Marek Szyprowski wrote: This patch modifies dma-mapping implementation on ARM architecture to use common dma_map_ops structure and asm-generic/dma-mapping-common.h helpers. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/Kconfig |1 + arch/arm/include/asm/device.h |1 + arch/arm/include/asm/dma-mapping.h | 196 +--- arch/arm/mm/dma-mapping.c | 148 --- 4 files changed, 115 insertions(+), 231 deletions(-) Looks good in principle. One question: Now that many of the functions are only used in the dma_map_ops, can you make them 'static' instead? Some of these non static functions (mainly arm_dma_*_sg_* family) are also used by dma bounce code introduced in the next patch, that's why I left them without static attribute. Best regards -- Marek Szyprowski Samsung Poland RD Center ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 3/4] drm: fixed: Add dfixed_frac() macro
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 4a08a66..0ead502 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -37,6 +37,7 @@ typedef union dfixed {
#define dfixed_init(A) { .full = dfixed_const((A)) }
#define dfixed_init_half(A) { .full = dfixed_const_half((A)) }
#define dfixed_trunc(A) ((A).full 12)
+#define dfixed_frac(A) ((A).full ((1 12) - 1))
static inline u32 dfixed_floor(fixed20_12 A)
{
--
1.7.10
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 2/4] iommu: tegra/gart: Add device tree support
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 | 10 ++
3 files changed, 17 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 */
+ };
};
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
b/arch/arm/mach-tegra/board-dt-tegra20.c
index 57745e6..bffba1b 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -66,6 +66,7 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(nvidia,tegra20-ehci, TEGRA_USB3_BASE, tegra-ehci.2,
tegra_ehci3_pdata),
OF_DEV_AUXDATA(nvidia,tegra20-pwm, TEGRA_PWFM_BASE, tegra-pwm,
NULL),
+ OF_DEV_AUXDATA(nvidia,tegra20-gart, TEGRA_MC_BASE, tegra-gart,
NULL),
{}
};
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index f6bc1e6..4a571b7 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -29,6 +29,7 @@
#include linux/device.h
#include linux/io.h
#include linux/iommu.h
+#include linux/of.h
#include asm/cacheflush.h
@@ -422,6 +423,13 @@ const struct dev_pm_ops tegra_gart_pm_ops = {
.resume = tegra_gart_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id tegra_gart_of_match[] __devinitdata = {
+ { .compatible = nvidia,tegra20-gart, },
+ { },
+};
+#endif
+
static struct platform_driver tegra_gart_driver = {
.probe = tegra_gart_probe,
.remove = tegra_gart_remove,
@@ -429,6 +437,7 @@ static struct platform_driver tegra_gart_driver = {
.owner = THIS_MODULE,
.name = tegra-gart,
.pm = tegra_gart_pm_ops,
+ .of_match_table = of_match_ptr(tegra_gart_of_match),
},
};
@@ -448,4 +457,5 @@ module_exit(tegra_gart_exit);
MODULE_DESCRIPTION(IOMMU API for GART in Tegra20);
MODULE_AUTHOR(Hiroshi DOYU hd...@nvidia.com);
+MODULE_ALIAS(platform:tegra-gart);
MODULE_LICENSE(GPL v2);
--
1.7.10
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 1/4] iommu: tegra/gart: use correct gart_device
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCHv8 04/10] ARM: dma-mapping: remove offset parameter to prepare for generic dma_ops
Hi Arnd, On Wednesday, April 11, 2012 2:19 PM Arnd Bergmann wrote: On Wednesday 11 April 2012, Marek Szyprowski wrote: Well, range sync functions are available from the early days of the dma mapping api (at least that's what I've found reading the change log and old patches). They are the correct way of doing a partial syncs on the buffer (usually used by the network device drivers). This patch changes only the internal implementation of the dma bounce functions to let them tunnel through dma_map_ops structure. The driver api stays unchanged, so driver are obliged to call dma_*_range_* functions to keep code clean and easy to understand. The only drawback I can see from this patch is reduced detection of the dma api abuse. Let us consider the following code: dma_addr = dma_map_single(dev, ptr, 64, DMA_TO_DEVICE); dma_sync_single_range_for_cpu(dev, dma_addr+16, 0, 32, DMA_TO_DEVICE); Without the patch such code fails, because dma bounce code is unable to find the bounce buffer for the given dma_address. After the patch the sync call will be equivalent to: dma_sync_single_range_for_cpu(dev, dma_addr, 16, 32, DMA_TO_DEVICE); which succeeds. I don't consider this as a real problem. DMA API abuse should be caught by debug_dma_* function family, so we can simplify the internal low-level implementation without losing anything. Ok, fair enough. Can you put the above text into the changelog? Yes, I will update it in the next release. Best regards -- Marek Szyprowski Samsung Poland RD Center ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/4] Add NVIDIA Tegra DRM support
* 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 I guess that the following 2 patches can be merged now, independet of the rest of drm patches. [RFC 1/4] iommu: tegra/gart: use correct gart_device [RFC 2/4] iommu: tegra/gart: Add device tree support Yes, I can probably post those separately so they can be applied independently. Should they go in via the IOMMU tree or the Tegra tree? Thierry pgpT7xc0RiJOr.pgp Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/4] Add NVIDIA Tegra DRM support
* 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 and the xf86-video-modesetting driver. The code uses the Tegra's IOMMU/GART to remap non-contiguous memory. This means that currently video memory is limited to 32 MB, the size of the GART aperture. You should only need continguous memory with GEM for the framebuffer / console bits via /dev/fb. In theory the fb layer can be taught to hanndle non linear framebuffers but nobody has yet done so. (Now there's a GSOC project ... ;)) What we do on GMA500 is to allocate the kernel framebuffer from linearly mapped memory but the normal GEM objects from anywhere as the GEM mapping into userspace will deal with presenting it to user space as a virtually linear buffer. That's actually what the driver does as well. It uses the shmfs-backed memory provided by GEM and only maps it through the GART to provide a linear view for the display controller which cannot do scatter-gather I/O. Neither the kernel nor the user-space mapping go through the GART. You are right that for anything but the framebuffer objects it probably doesn't matter. It's a little hard to tell because I don't have any documentation for either the 2D nor 3D engines. Eventually a better option might be to use stolen memory instead of remapping it through the GART. Thierry pgpn0gy1X7Mqj.pgp Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/2] Exynos: fix SYSMMU driver to work with power domains
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(-) -- 1.7.1.569.g6f426 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/2] iommu/exynos: fix runtime pm support
Fix registration to runtime pw and add missing resume callback.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iommu/exynos-iommu.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index b8daf7c..eef924d 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -651,8 +651,7 @@ static int exynos_sysmmu_probe(struct platform_device *pdev)
__set_fault_handler(data, default_fault_handler);
- if (dev-parent)
- pm_runtime_enable(dev);
+ pm_runtime_enable(dev);
dev_dbg(dev, (%s) Initialized\n, data-dbgname);
return 0;
@@ -674,11 +673,28 @@ err_alloc:
return ret;
}
+static int exynos_pm_resume(struct device *dev)
+{
+ struct sysmmu_drvdata *data;
+
+ data = dev_get_drvdata(dev);
+
+ if (is_sysmmu_active(data))
+ __exynos_sysmmu_enable(data, data-pgtable, NULL);
+
+ return 0;
+}
+
+const struct dev_pm_ops exynos_pm_ops = {
+ .resume = exynos_pm_resume,
+};
+
static struct platform_driver exynos_sysmmu_driver = {
.probe = exynos_sysmmu_probe,
.driver = {
.owner = THIS_MODULE,
.name = exynos-sysmmu,
+ .pm = exynos_pm_ops,
}
};
--
1.7.1.569.g6f426
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/2] ARM: Exynos4: update SYSMMU setup code for gen_pd power domain driver
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); diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c index 13b3068..51a028d 100644 --- a/arch/arm/mach-exynos/pm_domains.c +++ b/arch/arm/mach-exynos/pm_domains.c @@ -21,6 +21,7 @@ #include linux/of_address.h #include mach/regs-pmu.h +#include mach/sysmmu.h #include plat/devs.h /* @@ -155,6 +156,18 @@ static __init int exynos4_pm_init_power_domain(void) pm_genpd_init(exynos4_pm_domains[idx]-pd, NULL, exynos4_pm_domains[idx]-is_off); +#ifdef CONFIG_EXYNOS_DEV_SYSMMU + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(fimc0), exynos4_pd_cam); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(fimc1), exynos4_pd_cam); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(fimc2), exynos4_pd_cam); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(fimc3), exynos4_pd_cam); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(jpeg), exynos4_pd_cam); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(mfc_l), exynos4_pd_mfc); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(mfc_r), exynos4_pd_mfc); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(fimd0), exynos4_pd_lcd0); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(rot), exynos4_pd_lcd0); + exynos_pm_add_dev_to_genpd(SYSMMU_PLATDEV(tv), exynos4_pd_tv); +#endif #ifdef CONFIG_S5P_DEV_FIMD0 exynos_pm_add_dev_to_genpd(s5p_device_fimd0, exynos4_pd_lcd0); #endif -- 1.7.1.569.g6f426 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH/RFC] ARM: Exynos4: Integrate IOMMU aware DMA-mapping
Hi! This is an example of the IOMMU aware DMA-mapping implementation usage on a Samsung Exynos4 based NURI board. The ARM DMA-mapping IOMMU aware implementation is available in the [1] thread: This patch essentially registers DMA-mmaping/IOMMU support for FIMC and MFC devices and performs some tweaks in clocks hierarchy to get SYSMMU driver working correctly. The drivers have been tested with mainline V4L2 drivers for FIMC and MFC hardware. For easier testing I've created a separate kernel branch with all required prerequisite patches. It is based on lastest kgene/for-next branch and is available on my git repository: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git 3.4-rc2-arm-dma-v8-samsung This patch requires the following items: 1. ARM DMA-mapping patches [1] 2. Exynos SYSMMU driver v12 [2] 3. Exynos SYSMMU driver runtime pm fixes 4. Exynos4 gen_pd power domain driver fixes Runtime pm and power domain patches are required on Samsung Nuri board, but might be optional on boards where bootloader doesn't disable all devices on boot. [1] http://www.spinics.net/lists/linux-arch/msg17331.html [2] https://lkml.org/lkml/2012/3/15/51 Best regards Marek Szyprowski Samsung Poland RD Center Patch summary: Marek Szyprowski (1): ARM: Exynos4: integrate SYSMMU driver with DMA-mapping interface arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/clock-exynos4.c | 64 +++- arch/arm/mach-exynos/dev-sysmmu.c | 44 +++ arch/arm/mach-exynos/include/mach/sysmmu.h |3 + drivers/iommu/Kconfig |1 + 5 files changed, 84 insertions(+), 29 deletions(-) -- 1.7.1.569.g6f426 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] ARM: Exynos4: integrate SYSMMU driver with DMA-mapping interface
This patch provides an provides setup code which assigns IOMMU controllers
to FIMC and MFC devices and enables IOMMU aware DMA-mapping for them.
It has been tested on Samsung Exynos4 platform, NURI board.
Most of the work is done in the s5p_sysmmu_late_init() function, which
first assigns SYSMMU controller to respective client device and then
creates IO address space mapping structures. In this example 128 MiB of
address space is created at 0x2000 for most of the devices. IO address
allocation precision is set to 2^4 pages, so all small allocations will be
aligned to 64 pages. This reduces the size of the io address space bitmap
to 4 KiB.
To solve the clock dependency issues, parent clocks have been added to each
SYSMMU controller bus clock. This models the true hardware behavior,
because client's device bus clock also gates the respective sysmmu bus
clock.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/clock-exynos4.c | 64 +++-
arch/arm/mach-exynos/dev-sysmmu.c | 44 +++
arch/arm/mach-exynos/include/mach/sysmmu.h |3 +
drivers/iommu/Kconfig |1 +
5 files changed, 84 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 801c738..25b9ba5 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -288,6 +288,7 @@ config MACH_NURI
select S5P_DEV_USB_EHCI
select S5P_SETUP_MIPIPHY
select EXYNOS4_DEV_DMA
+ select EXYNOS_DEV_SYSMMU
select EXYNOS4_SETUP_FIMC
select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index 29ae4df..fe459a3 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -497,29 +497,6 @@ static struct clk *exynos4_gate_clocks[] = {
static struct clk exynos4_init_clocks_off[] = {
{
- .name = timers,
- .parent = exynos4_clk_aclk_100.clk,
- .enable = exynos4_clk_ip_peril_ctrl,
- .ctrlbit= (124),
- }, {
- .name = csis,
- .devname= s5p-mipi-csis.0,
- .enable = exynos4_clk_ip_cam_ctrl,
- .ctrlbit= (1 4),
- .parent = exynos4_clk_gate_cam,
- }, {
- .name = csis,
- .devname= s5p-mipi-csis.1,
- .enable = exynos4_clk_ip_cam_ctrl,
- .ctrlbit= (1 5),
- .parent = exynos4_clk_gate_cam,
- }, {
- .name = jpeg,
- .id = 0,
- .enable = exynos4_clk_ip_cam_ctrl,
- .ctrlbit= (1 6),
- .parent = exynos4_clk_gate_cam,
- }, {
.name = fimc,
.devname= exynos4-fimc.0,
.enable = exynos4_clk_ip_cam_ctrl,
@@ -544,6 +521,35 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit= (1 3),
.parent = exynos4_clk_gate_cam,
}, {
+ .name = mfc,
+ .devname= s5p-mfc,
+ .enable = exynos4_clk_ip_mfc_ctrl,
+ .ctrlbit= (1 0),
+ .parent = exynos4_clk_gate_mfc,
+ }, {
+ .name = timers,
+ .parent = exynos4_clk_aclk_100.clk,
+ .enable = exynos4_clk_ip_peril_ctrl,
+ .ctrlbit= (124),
+ }, {
+ .name = csis,
+ .devname= s5p-mipi-csis.0,
+ .enable = exynos4_clk_ip_cam_ctrl,
+ .ctrlbit= (1 4),
+ .parent = exynos4_clk_gate_cam,
+ }, {
+ .name = csis,
+ .devname= s5p-mipi-csis.1,
+ .enable = exynos4_clk_ip_cam_ctrl,
+ .ctrlbit= (1 5),
+ .parent = exynos4_clk_gate_cam,
+ }, {
+ .name = jpeg,
+ .id = 0,
+ .enable = exynos4_clk_ip_cam_ctrl,
+ .ctrlbit= (1 6),
+ .parent = exynos4_clk_gate_cam,
+ }, {
.name = hsmmc,
.devname= exynos4-sdhci.0,
.parent = exynos4_clk_aclk_133.clk,
@@ -674,12 +680,6 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit= (1 0),
.parent = exynos4_clk_gate_lcd0,
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
Hm, in that case it looks like your iommu works more like the gtt on intel chips Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU side access of the GTT map (ie you can't use it to linearise pages for CPU view) and the 3600 is even stranger Alan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* 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 a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? I'm not sure I know what you are referring to. Looking for all users of iommu_map() doesn't turn up anything related to dma_map. Can you point me in the right direction? 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, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. 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. Hm, in that case it looks like your iommu works more like the gtt on intel chips and less like the iommu on intel platforms (which we access through the dma_map api). Yes, it's very much like the GTT on Intel chips. In fact I've been using the gma500 driver as a source for inspiration. Wikipedia confirms that GTT and GART are synonymous. I wonder whether that will end up in some layering fun together with dma_buf, which conceptually is at the same level as the dma api, which usually uses an underlying iommu exposed with the iommu api you're using. That's odd. The only users of the IOMMU API that I can find in the kernel tree are in drivers/remoteproc and drivers/media/video/omap3isp. And omap3isp doesn't do any actual mapping at a quick glance. Can you point me to where this is hooked up with the Intel IOMMU? Thierry pgp6tBMalmVXB.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
* 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 needs a physically contiguous map for the console devices. Well you could vmap them but that is pretty hideous on a 32bit platform with 32bit 1080p display plugged into it! Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it is hideous? I'll have to investigate what an appropriate alternative would look like. Thierry pgp4S1plaNGPQ.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
Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it is hideous? On x86 we don't have a vast amount of address space available for virtual remappings and the framebuffer then eats over 8MB of it. The ideal case is that the fb layer can be taught to do page/offset addressing nicely. At that point we'd be able to attach the text consoles to arbitary GEM objects.. which means we can do really cool stuff. Alan ___ 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 Wednesday 11 April 2012, 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 a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? I'm not sure I know what you are referring to. Looking for all users of iommu_map() doesn't turn up anything related to dma_map. Can you point me in the right direction? 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, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. dma_map_sg is certainly the right interface to use, and Marek Szyprowski has patches to make that work on ARM, hopefully going into v3.5, so you could use those. Arnd ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Intel IOMMU PATCH] Re-evaluate RMRR info for devices removed from si domain (Thomas Mingarelli)
Has this patch has been accepted? Is there anything else we must do?
Thanks and regards
Tony Camuso
--
Message: 1
Date: Thu, 29 Mar 2012 13:19:58 +
From: Mingarelli, Thomas thomas.mingare...@hp.com
To: iommu@lists.linux-foundation.org
iommu@lists.linux-foundation.org
Cc: Camuso, Tony tony.cam...@hp.com
Subject: RE: [Intel IOMMU PATCH] Re-evaluate RMRR info for devices
removed from si domain
Message-ID:
9774516974af5f4c8a2c3c69cd3412332037d...@g9w0755.americas.hpqcorp.net
Content-Type: text/plain; charset=us-ascii
This patch is being submitted to handle the case where a pci device is placed
into the si domain, when booting in iommu passthrough mode, then removed. The
RMRR information for such devices need to be re-processed to avoid DMA Read
errors due to the Present Bit being cleared in the device's context entry.
Signed-off-by: Thomas Mingarelli thomas.mingare...@hp.com
Tested-by: Tony Camuso tony.cam...@hp.com
Details of testing performed (per Mr. Camuso):
I think I was able to prove that your patch works with si domain devices.
I was able to Device Assign the two Patsburg USB controllers on the DL360G8 to
your RH6 VM.
When I did that, I saw them on the VM guest, but they did not appear on the
host. This is exactly the behavior you expect for Device-Assigned devices.
Guest ..
[root@rh6 ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device
001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID
8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID
0627:0001 Adomax Technology Co., Ltd Bus 002 Device 003: ID : Bus 001
Device 003: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse
Host ...
[root@dl380g8 ~]# lsusb
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device
002: ID 03f0:7029 Hewlett-Packard
[root@dl380g8 ~]#
When I powered-down the guest, the USB controllers appeared on the host system
again.
[root@dl380g8 ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device
001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID
03f0:7029 Hewlett-Packard Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0
root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching
Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse Bus
002 Device 003: ID 0424:2660 Standard Microsystems Corp.
Bus 002 Device 004: ID 03f0:3207 Hewlett-Packard 4 GB flash drive
[root@dl380g8 ~]#
Then, I powered-up the guest again, the usb controllers were there on the guest
system again.
[root@localhost ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device
001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID
8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID
0627:0001 Adomax Technology Co., Ltd Bus 002 Device 003: ID : Bus 001
Device 003: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse
[root@localhost ~]#
And they had vanished from the host system.
[root@dl380g8 ~]# lsusb
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device
002: ID 03f0:7029 Hewlett-Packard
[root@dl380g8 ~]#
I believe this proves that your patch works correctly with si domain devices.
PATCH FOLLOWS...
diff -up linux-3.2.4/drivers/iommu/intel-iommu.c.ORIG
linux-3.2.4/drivers/iommu/intel-iommu.c
--- linux-3.2.4/drivers/iommu/intel-iommu.c.ORIG2012-02-22
16:10:07.105254130 -0600
+++ linux-3.2.4/drivers/iommu/intel-iommu.c 2012-02-28 12:49:38.537694065
-0600
@@ -2676,7 +2676,8 @@ static int iommu_dummy(struct pci_dev *p static int
iommu_no_mapping(struct device *dev) {
struct pci_dev *pdev;
- int found;
+ struct dmar_rmrr_unit *rmrr;
+ int i, ret, found;
if (unlikely(dev-bus != pci_bus_type))
return 1;
@@ -2699,7 +2700,24 @@ static int iommu_no_mapping(struct devic
*/
domain_remove_one_dev_info(si_domain, pdev);
printk(KERN_INFO 32bit %s uses non-identity mapping\n,
- pci_name(pdev));
+ pci_name(pdev));
+ printk(KERN_INFO IOMMU: Re-processing RMRR information
for device %s:\n,
+ pci_name(pdev));
+ for_each_rmrr_units(rmrr) {
+ for (i = 0; i rmrr-devices_cnt; i++) {
+ /*
+* Here we are just concerned with
finding the
+* one device that was removed from the
+* si_domain and re-evaluating its
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote: This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ 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 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 a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? I'm not sure I know what you are referring to. Looking for all users of iommu_map() doesn't turn up anything related to dma_map. Can you point me in the right direction? 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, but there are quite a few variants around. I'm just wondering why this you've choosen this. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ 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 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 a very basic DRM driver for NVIDIA Tegra SoCs. It currently has rudimentary GEM support and can run a console on the framebuffer as well as X using the xf86-video-modesetting driver. Only the RGB output is supported. Quite a lot of things still need to be worked out and there is a lot of room for cleanup. Indeed, after a quick look there are tons of functions that are just stubs ;-) One thing I wonder though is why you directly use the iommu api and not wrap it up into dma_map? Is arm infrastructure just not there yet or do you plan to tightly integrate the tegra drm with the iommu (e.g. for process space switching or similarly funky stuff)? I'm not sure I know what you are referring to. Looking for all users of iommu_map() doesn't turn up anything related to dma_map. Can you point me in the right direction? 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, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. 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. Hm, in that case it looks like your iommu works more like the gtt on intel chips and less like the iommu on intel platforms (which we access through the dma_map api). I wonder whether that will end up in some layering fun together with dma_buf, which conceptually is at the same level as the dma api, which usually uses an underlying iommu exposed with the iommu api you're using. Perhaps I'm being dense? Doesn't sound like that over here ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ 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 Wed, Apr 11, 2012 at 03:43:09PM +0100, Alan Cox wrote: Hm, in that case it looks like your iommu works more like the gtt on intel chips Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU side access of the GTT map (ie you can't use it to linearise pages for CPU view) and the 3600 is even stranger Sorry, I really try to totally ignore everything related to gma500 ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] iommu/exynos: fix runtime pm support
Hello.
Marek Szyprowski wrote:
Fix registration to runtime pw and add missing resume callback.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iommu/exynos-iommu.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index b8daf7c..eef924d 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
[...]
@@ -674,11 +673,28 @@ err_alloc:
return ret;
}
+static int exynos_pm_resume(struct device *dev)
+{
+ struct sysmmu_drvdata *data;
+
+ data = dev_get_drvdata(dev);
Why not do it right in the initializer?
WBR, Sergei
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 2/4] iommu: tegra/gart: Add device tree support
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 ++ arch/arm/mach-tegra/board-dt-tegra20.c |1 + drivers/iommu/tegra-gart.c | 10 ++ 3 files changed, 17 insertions(+) I think I'd prefer at least the tegra20.dtsi change split out into a separate patch so I can queue it in a dt topic branch in the Tegra repo. It might be a good idea to split this into two on an arch/arm vs. drivers/iommu boundary. Looking at Olof's branches for 3.4, that split is what happened there. Finally, there should be a binding documentation file in Documentation/devicetree/bindings in order to specify the number of reg property entries needed, and their meaning, since there's more than 1 (even though you did comment it nicely in the .dtsi file) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 3/4] drm: fixed: Add dfixed_frac() macro
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. ___ 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/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is supported. Quite a lot of things still need
to be worked out and there is a lot of room for cleanup.
I'll let Jon Mayo comment on the actual driver implementation, since
he's a lot more familiar with Tegra's display hardware. However, I have
some general comments below.
.../devicetree/bindings/gpu/drm/tegra.txt | 24 +
arch/arm/mach-tegra/board-dt-tegra20.c |3 +
arch/arm/mach-tegra/tegra2_clocks.c|8 +-
drivers/gpu/drm/Kconfig|2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/tegra/Kconfig | 10 +
drivers/gpu/drm/tegra/Makefile |5 +
drivers/gpu/drm/tegra/tegra_drv.c | 2241
drivers/gpu/drm/tegra/tegra_drv.h | 184 ++
include/drm/tegra_drm.h| 44 +
Splitting this patch into two, between arch/arm and drivers/gpu would be
a good idea.
diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt
b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
+ drm@5420 {
+ compatible = nvidia,tegra20-drm;
This doesn't seem right; there isn't a DRM hardware module on Tegra,
since DRM is a Linux/software-specific term.
I'd at least expect to see this compatible flag be renamed to something
more like nvidia,tegra20-dc (dc==display controller).
Since Tegra has two display controller modules (I believe identical?),
and numerous other independent(?) blocks, I'd expect to see multiple
nodes in device tree, one per hardware block, such that each block gets
its own device and driver. That said, I'm not familiar enough with
Tegra's display and graphics HW to know if this makes sense. Jon, what's
your take here? The clock change below, and in particular the original
code there that we use downstream, lends weight to my argument.
+ reg = 0x5420 0x0004/* display A */
+ 0x5424 0x0004/* display B */
+ 0x5800 0x0200 ; /* GART aperture */
+ interrupts = 0 73 0x04/* display A */
+0 74 0x04 ; /* display B */
+
+ lvds {
+ type = rgb;
These sub-nodes probably want a compatible property rather than a
type property.
+ size = 345 194;
+
+ default-mode {
+ pixel-clock = 61715000;
+ vertical-refresh = 50;
+ resolution = 1366 768;
+ bits-per-pixel = 16;
+ horizontal-timings = 4 136 2 36;
+ vertical-timings = 2 4 21 10;
+ };
+ };
I imagine that quite a bit of thought needs to be put into the output
part of the binding in order to:
* Model the outputs/connectors separately from display controllers.
* Make sure that the basic infra-structure for representing an output is
general enough to be extensible to all the kinds of outputs we support,
not just the LVDS output.
* We were wondering about putting an EDID into the DT to represent the
display modes, so that all outputs had EDIDs rather than real monitors
having EDIDs, and fixed internal displays having some other
representation of capabilities.
I'm hoping that Jon will drive this.
diff --git a/arch/arm/mach-tegra/tegra2_clocks.c
b/arch/arm/mach-tegra/tegra2_clocks.c
- PERIPH_CLK(disp1, tegradc.0,NULL, 27, 0x138,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
- PERIPH_CLK(disp2, tegradc.1,NULL, 26, 0x13c,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
+ PERIPH_CLK(disp1, tegra-drm,NULL, 27, 0x138,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
+ PERIPH_CLK(disp2, tegra-drm,NULL, 26, 0x13c,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
This doesn't seem right, and couples back to my assertion above that the
two display controller modules probably deserve separate device objects,
named e.g. tegradc.*.
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
new file mode 100644
index 000..f3382c9
--- /dev/null
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -0,0 +1,10 @@
+config DRM_TEGRA
+ tristate NVIDIA Tegra
+ depends on DRM ARCH_TEGRA
Jon, do you think we'll end up eventually having a unified
