clk: tegra: Implement memory-controller clock
Subsystems (11)
PATCH v3 1/12 clk: tegra: Implement memory-controller clock
From: Thierry Reding <[email protected]>
The memory controller clock runs either at half or the same frequency as the EMC clock.
---
Changes in v3:
- split registration into a separate function that can be reused for all SoC generations, but pass in the name and parent parameters for clarity as well as the register address (in case it ever changes) and the EMC spin-lock since it isn't globally available
drivers/clk/tegra/clk-divider.c | 13 +++++++++++++ drivers/clk/tegra/clk-tegra114.c | 7 ++++++- drivers/clk/tegra/clk-tegra124.c | 7 ++++++- drivers/clk/tegra/clk-tegra20.c | 8 +++++++- drivers/clk/tegra/clk-tegra30.c | 7 ++++++- drivers/clk/tegra/clk.h | 2 ++ include/dt-bindings/clock/tegra114-car.h | 2 +- include/dt-bindings/clock/tegra124-car.h | 2 +- include/dt-bindings/clock/tegra20-car.h | 2 +- 9 files changed, 43 insertions(+), 7 deletions(-)
drivers/clk/tegra/clk-divider.c +13 -0
@@ -185,3 +185,16 @@ struct clk *tegra_clk_register_divider(const char *name,return clk; } + +static const struct clk_div_table mc_div_table[] = { + { .val =0 , .div =2 }, + { .val =1 , .div =1 }, + { .val =0 , .div =0 }, +}; + +struct clk *tegra_clk_register_mc (const char *name,const char *parent_name, +void __iomem *reg,spinlock_t *lock) +{ +return clk_register_divider_table (NULL ,"mc" ,"emc_mux" ,0 , reg, +16 ,1 ,0 , mc_div_table, lock); +}
drivers/clk/tegra/clk-tegra114.c +6 -1
@@ -173,6 +173,7 @@ static DEFINE_SPINLOCK(pll_d_lock);static DEFINE_SPINLOCK (pll_d2_lock);static DEFINE_SPINLOCK (pll_u_lock);static DEFINE_SPINLOCK (pll_re_lock); +static DEFINE_SPINLOCK (emc_lock);static struct div_nmp pllxc_nmp = { .divm_shift =0 ,
@@ -1228,7 +1229,11 @@ static __init void tegra114_periph_clk_init(void __iomem *clk_base,ARRAY_SIZE (mux_pllmcp_clkm),CLK_SET_RATE_NO_REPARENT , clk_base +CLK_SOURCE_EMC , - 29, 3, 0, NULL); + 29, 3, 0, &emc_lock); + + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA114_CLK_MC ] = clk;for (i =0 ; i <ARRAY_SIZE (tegra_periph_clk_list); i++) { data = &tegra_periph_clk_list[i];
drivers/clk/tegra/clk-tegra124.c +6 -1
@@ -132,6 +132,7 @@ static DEFINE_SPINLOCK(pll_d2_lock);static DEFINE_SPINLOCK (pll_e_lock);static DEFINE_SPINLOCK (pll_re_lock);static DEFINE_SPINLOCK (pll_u_lock); +static DEFINE_SPINLOCK (emc_lock);/* possible OSC frequencies in Hz */ static unsigned long tegra124_input_freq[] = {
@@ -1127,7 +1128,11 @@ static __init void tegra124_periph_clk_init(void __iomem *clk_base, clk =clk_register_mux (NULL ,"emc_mux" , mux_pllmcp_clkm,ARRAY_SIZE (mux_pllmcp_clkm),0 , clk_base +CLK_SOURCE_EMC , -29 ,3 ,0 ,NULL ); +29 ,3 ,0 , &emc_lock); + + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA124_CLK_MC ] = clk;/* cml0 */ clk = clk_register_gate(NULL, "cml0", "pll_e", 0, clk_base + PLLE_AUX,
drivers/clk/tegra/clk-tegra20.c +7 -1
@@ -140,6 +140,8 @@ static struct cpu_clk_suspend_context {static void __iomem *clk_base;static void __iomem *pmc_base; +static DEFINE_SPINLOCK (emc_lock); +#define TEGRA_INIT_DATA_MUX (_name, _parents, _offset, \ _clk_num, _gate_flags, _clk_id) \ TEGRA_INIT_DATA(_name, NULL, NULL, _parents, _offset, \
@@ -819,11 +821,15 @@ static void __init tegra20_periph_clk_init(void)ARRAY_SIZE (mux_pllmcp_clkm),CLK_SET_RATE_NO_REPARENT , clk_base +CLK_SOURCE_EMC , - 30, 2, 0, NULL); + 30, 2, 0, &emc_lock); clk =tegra_clk_register_periph_gate ("emc" ,"emc_mux" ,0 , clk_base,0 ,57 , periph_clk_enb_refcnt); clks[TEGRA20_CLK_EMC ] = clk; + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA20_CLK_MC ] = clk; +/* dsi */ clk =tegra_clk_register_periph_gate ("dsi" ,"pll_d" ,0 , clk_base,0 ,48 , periph_clk_enb_refcnt);
drivers/clk/tegra/clk-tegra30.c +6 -1
@@ -177,6 +177,7 @@ static unsigned long input_freq;static DEFINE_SPINLOCK (cml_lock);static DEFINE_SPINLOCK (pll_d_lock); +static DEFINE_SPINLOCK (emc_lock);#define TEGRA_INIT_DATA_MUX (_name, _parents, _offset, \ _clk_num, _gate_flags, _clk_id) \
@@ -1157,11 +1158,15 @@ static void __init tegra30_periph_clk_init(void)ARRAY_SIZE (mux_pllmcp_clkm),CLK_SET_RATE_NO_REPARENT , clk_base +CLK_SOURCE_EMC , - 30, 2, 0, NULL); + 30, 2, 0, &emc_lock); clk =tegra_clk_register_periph_gate ("emc" ,"emc_mux" ,0 , clk_base,0 ,57 , periph_clk_enb_refcnt); clks[TEGRA30_CLK_EMC ] = clk; + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA30_CLK_MC ] = clk; +/* cml0 */ clk =clk_register_gate (NULL ,"cml0" ,"pll_e" ,0 , clk_base +PLLE_AUX ,0 ,0 , &cml_lock);
drivers/clk/tegra/clk.h +2 -0
@@ -86,6 +86,8 @@ struct clk *tegra_clk_register_divider(const char *name, const char *parent_name, void __iomem *reg, unsigned long flags, u8 clk_divider_flags, u8 shift, u8 width, u8 frac_width, spinlock_t *lock); +struct clk *tegra_clk_register_mc (const char *name,const char *parent_name, +void __iomem *reg,spinlock_t *lock);/* * Tegra PLL:
include/dt-bindings/clock/tegra114-car.h +1 -1
@@ -49,7 +49,7 @@#define TEGRA114_CLK_I2S0 30/* 31 */ -/* 32 */ +#define TEGRA114_CLK_MC 32/* 33 */ #define TEGRA114_CLK_APBDMA 34/* 35 */
include/dt-bindings/clock/tegra124-car.h +1 -1
@@ -48,7 +48,7 @@#define TEGRA124_CLK_I2S0 30/* 31 */ -/* 32 */ +#define TEGRA124_CLK_MC 32/* 33 */ #define TEGRA124_CLK_APBDMA 34/* 35 */
include/dt-bindings/clock/tegra20-car.h +1 -1
@@ -49,7 +49,7 @@/* 30 */ #define TEGRA20_CLK_CACHE2 31 -#define TEGRA20_CLK_MEM 32 +#define TEGRA20_CLK_MC 32#define TEGRA20_CLK_AHBDMA 33#define TEGRA20_CLK_APBDMA 34/* 35 */
Signature · 1 line
2.1.2
PATCH 2/12 amba: Add Kconfig file
From: Thierry Reding <[email protected]>
Rather than duplicate the ARM_AMBA Kconfig symbol in both 32-bit and 64-bit ARM architectures, move the common definition to drivers/amba where dependent drivers will be located.
--- arch/arm/Kconfig | 3 --- arch/arm64/Kconfig | 3 --- drivers/amba/Kconfig | 2 ++ 3 files changed, 2 insertions(+), 6 deletions(-) create mode 100644 drivers/amba/Kconfig
arch/arm/Kconfig +0 -3
@@ -1259,9 +1259,6 @@ source "arch/arm/common/Kconfig" menu "Bus support" -config ARM_AMBA - bool - config ISA bool help
arch/arm64/Kconfig +0 -3
@@ -165,9 +165,6 @@ endmenu menu "Bus support" -config ARM_AMBA - bool - config PCI bool "PCI support" help
drivers/amba/Kconfig new file +2 -0
@@ -0,0 +1,2 @@ +config ARM_AMBA + bool
Signature · 1 line
2.1.2
PATCH v4 3/12 ARM: tegra: Move AHB Kconfig to drivers/amba
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
This will allow the Kconfig option to be shared among 32-bit and 64-bit ARM.
---
Changes in v4:
- add precursory patch introducing drivers/amba/Kconfig, rebase on top
Changes in v3:
- select ARM_AMBA from ARCH_TEGRA to enable the TEGRA_AHB driver
arch/arm/mach-tegra/Kconfig | 9 +-------- drivers/Kconfig | 2 ++ drivers/amba/Kconfig | 12 ++++++++++++ 3 files changed, 15 insertions(+), 8 deletions(-)
arch/arm/mach-tegra/Kconfig +1 -8
@@ -2,6 +2,7 @@ menuconfig ARCH_TEGRA bool "NVIDIA Tegra" if ARCH_MULTI_V7 select ARCH_REQUIRE_GPIOLIB select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS + select ARM_AMBA select ARM_GIC select CLKSRC_MMIO select HAVE_ARM_SCU if SMP
@@ -59,12 +60,4 @@ config ARCH_TEGRA_124_SOC Support for NVIDIA Tegra T124 processor family, based on the ARM CortexA15MP CPU -config TEGRA_AHB - bool "Enable AHB driver for NVIDIA Tegra SoCs" - default y - help - Adds AHB configuration functionality for NVIDIA Tegra SoCs, - which controls AHB bus master arbitration and some - performance parameters(priority, prefech size). - endif
drivers/Kconfig +2 -0
@@ -1,5 +1,7 @@ menu "Device Drivers" +source "drivers/amba/Kconfig" + source "drivers/base/Kconfig" source "drivers/bus/Kconfig"
drivers/amba/Kconfig +12 -0
@@ -1,2 +1,14 @@ config ARM_AMBA bool + +if ARM_AMBA + +config TEGRA_AHB + bool "Enable AHB driver for NVIDIA Tegra SoCs" + default y if ARCH_TEGRA + help + Adds AHB configuration functionality for NVIDIA Tegra SoCs, + which controls AHB bus master arbitration and some performance + parameters (priority, prefetch size). + +endif
Signature · 1 line
2.1.2
PATCH 4/12 of: Add NVIDIA Tegra memory controller binding
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
The memory controller on NVIDIA Tegra 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 addresses for clients. This is useful for scatter-gather operation on devices that don't support it natively and for virtualization or process separation.
---
Changes in v3:
- add missing clocks and clock-names properties
- add example
.../memory-controllers/nvidia,tegra-mc.txt | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra-mc.txt
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra-mc.txt new file +36 -0
@@ -0,0 +1,36 @@ +NVIDIA Tegra Memory Controller device tree bindings +=================================================== + +Required properties: +- compatible: Should be "nvidia,tegra<chip>-mc" +- reg: Physical base address and length of the controller's registers. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - mc: the module's clock input +- interrupts: The interrupt outputs from the controller. +- #iommu-cells: Should be 1. The single cell of the IOMMU specifier defines + the SWGROUP of the master. + +This device implements an IOMMU that complies with the generic IOMMU binding. +See ../iommu/iommu.txt for details. + +Example: +-------- + + mc: memory-controller at 0,70019000 { + compatible = "nvidia,tegra124-mc"; + reg = <0x0 0x70019000 0x0 0x1000>; + clocks = <&tegra_car TEGRA124_CLK_MC>; + clock-names = "mc"; + + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; + + #iommu-cells = <1>; + }; + + sdhci at 0,700b0000 { + compatible = "nvidia,tegra124-sdhci"; + ... + iommus = <&mc TEGRA_SWGROUP_SDMMC1A>; + };
Signature · 1 line
2.1.2
A message that is not in the archive (sent off-list or not yet received): 1413196434-5292-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
From: Thierry Reding <[email protected]>
The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it.
Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements.
This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead.
---
Changes in v4:
- remove DMA/IOMMU integration glue
- don't initialize linear SMMU mapping
- fail attachment for non-masters
- free empty page tables
Changes in v3:
- drop changes related to probe ordering that were rejected
- remove old SMMU driver
drivers/iommu/Makefile | 1 - drivers/iommu/tegra-smmu.c | 1295 ------------------------------ drivers/memory/Makefile | 3 +- drivers/memory/tegra/Makefile | 5 + drivers/memory/tegra/tegra-mc.c | 1061 ++++++++++++++++++++++++ drivers/memory/tegra/tegra-mc.h | 90 +++ drivers/memory/tegra/tegra114-mc.c | 948 ++++++++++++++++++++++ drivers/memory/tegra/tegra124-mc.c | 1028 ++++++++++++++++++++++++ drivers/memory/tegra/tegra30-mc.c | 970 ++++++++++++++++++++++ drivers/memory/tegra30-mc.c | 378 --------- include/dt-bindings/memory/tegra114-mc.h | 25 + include/dt-bindings/memory/tegra124-mc.h | 31 + include/dt-bindings/memory/tegra30-mc.h | 24 + 13 files changed, 4184 insertions(+), 1675 deletions(-) delete mode 100644 drivers/iommu/tegra-smmu.c create mode 100644 drivers/memory/tegra/Makefile create mode 100644 drivers/memory/tegra/tegra-mc.c create mode 100644 drivers/memory/tegra/tegra-mc.h create mode 100644 drivers/memory/tegra/tegra114-mc.c create mode 100644 drivers/memory/tegra/tegra124-mc.c create mode 100644 drivers/memory/tegra/tegra30-mc.c delete mode 100644 drivers/memory/tegra30-mc.c create mode 100644 include/dt-bindings/memory/tegra114-mc.h create mode 100644 include/dt-bindings/memory/tegra124-mc.h create mode 100644 include/dt-bindings/memory/tegra30-mc.h
drivers/iommu/Makefile +0 -1
@@ -14,7 +14,6 @@ obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o -obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o
drivers/iommu/tegra-smmu.c deleted +0 -1295
1,295 lines not on this page · raw message
drivers/memory/Makefile +2 -1
@@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/
drivers/memory/tegra/Makefile new file +5 -0
@@ -0,0 +1,5 @@ +obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.o
drivers/memory/tegra/tegra-mc.c new file +1061 -0
1,061 lines not on this page · raw message
drivers/memory/tegra/tegra-mc.h new file +90 -0
90 lines not on this page · raw message
drivers/memory/tegra/tegra114-mc.c new file +948 -0
536 lines not on this page · raw message
drivers/memory/tegra/tegra124-mc.c new file +1028 -0
1,028 lines not on this page · raw message
drivers/memory/tegra/tegra30-mc.c new file +970 -0
970 lines not on this page · raw message
drivers/memory/tegra30-mc.c deleted +0 -378
378 lines not on this page · raw message
include/dt-bindings/memory/tegra114-mc.h new file +25 -0
Lines of this file are not shown. View the raw message.
include/dt-bindings/memory/tegra124-mc.h new file +31 -0
Lines of this file are not shown. View the raw message.
include/dt-bindings/memory/tegra30-mc.h new file +24 -0
Lines of this file are not shown. View the raw message.
The rest of this diff is not shown. View the raw message.
Signature · 1 line
2.1.2
Part of the diff is not shown here. View the raw message.
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Hi,
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
<[email protected]> wrote:
[...]
Quoted 10 lines
drivers/memory/tegra/tegra-mc.c new file +4
-0@@ -0,0 +1,1061 @@ +/* +* Copyright (C) 2014 NVIDIA CORPORATION. All rights reserved. +* +* This program is free software; you can redistribute it and/or modify
drivers/memory/tegra/tegra-mc.c line 14
Quoted 10 lines
drivers/memory/tegra/tegra-mc.c new file +10
-0+* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +*/ + +#include <linux/clk.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/iommu.h> +#include <linux/kernel.h> +#include <linux/module.h>
You need a linux/mm.h in here (on 64-bit).
Quoted 4 lines
drivers/memory/tegra/tegra-mc.c new file +4
-0+#include <linux/of.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> +#include <linux/slab.h>
[...]
Quoted 5 lines
drivers/memory/tegra/tegra124-mc.c new file +0
-0
[...]
Quoted 28 lines
drivers/memory/tegra/tegra124-mc.c new file +27
-0@@ -0,0 +1,1028 @@ +/* +* Copyright (C) 2014 NVIDIA CORPORATION. All rights reserved. +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +*/ + +#include <linux/of.h> +#include <linux/mm.h> + +#include <asm/cacheflush.h> + +#include <dt-bindings/memory/tegra124-mc.h> + +#include "tegra-mc.h" + +static const struct tegra_mc_client tegra124_mc_clients[] = { + { + .id =0x00 , + .name ="ptcr" , + .swgroup =TEGRA_SWGROUP_PTC , + }, { + .id =0x01 , + .name ="display0a" , + .swgroup =TEGRA_SWGROUP_DC , + .smmu = {
drivers/memory/tegra/tegra124-mc.c line 37
Quoted 10 lines
drivers/memory/tegra/tegra124-mc.c new file +10
-0+ .reg = 0x228, + .bit = 1, + }, + .latency = { + .reg = 0x2e8, + .shift = 0, + .mask = 0xff, + .def = 0xc2, + }, + }, {
These are very verbose tables. Having a macro for the initializers could help density a lot.
Quoted 24 lines
drivers/memory/tegra/tegra124-mc.c new file +24
-0+#ifdef CONFIG_ARCH_TEGRA_132_SOC +static void tegra132_flush_dcache (struct page *page,unsigned long offset, +size_t size) +{ +void *virt =page_address (page) + offset; + +__flush_dcache_area (virt, size); +} + +static const struct tegra_smmu_ops tegra132_smmu_ops = { + .flush_dcache = tegra132_flush_dcache, +}; + +static const struct tegra_smmu_soc tegra132_smmu_soc = { + .groups = tegra124_smmu_groups, + .num_groups =ARRAY_SIZE (tegra124_smmu_groups), + .clients = tegra124_mc_clients, + .num_clients =ARRAY_SIZE (tegra124_mc_clients), + .swgroups = tegra124_swgroups, + .num_swgroups =ARRAY_SIZE (tegra124_swgroups), + .supports_round_robin_arbitration = true, + .supports_request_limit = true, + .num_address_bits =34 , + .num_asids = 128,
drivers/memory/tegra/tegra124-mc.c line 1028
Quoted 10 lines
drivers/memory/tegra/tegra124-mc.c new file +10
-0+ .ops = &tegra132_smmu_ops, +}; + +const struct tegra_mc_soc tegra132_mc_soc = { + .clients = tegra124_mc_clients, + .num_clients =ARRAY_SIZE (tegra124_mc_clients), + .atom_size =32 , + .smmu = &tegra132_smmu_soc, +}; +#endif /* CONFIG_ARCH_TEGRA_132_SOC */
This won't compile -- several of the tegra132_smmu_soc members are no longer valid. In particular:
groupsnum_groupssupports_round_robin_arbitrationsupports_request_limit
-Olof
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 19 lines · Olof Johansson
Hi,
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
<[email protected]> wrote:
[...]Quoted 14 lines
drivers/memory/tegra/tegra-mc.c new file +8
-0@@ -0,0 +1,1061 @@ +/* +* Copyright (C) 2014 NVIDIA CORPORATION. All rights reserved. +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +*/ +
Quoted 8 lines
drivers/memory/tegra/tegra-mc.c line 14
Quoted 6 lines
drivers/memory/tegra/tegra-mc.c new file +6
-0+#include <linux/clk.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/iommu.h> +#include <linux/kernel.h> +#include <linux/module.h> You need a
linux/mm.hin here (on 64-bit).
Can you show what build error this fixes? I don't see any build failures (after fixing up the obvious ones you pointed out below).
Quoted 42 lines
Quoted 5 lines
drivers/memory/tegra/tegra124-mc.c new file +0
-0[...]
Quoted 33 lines
drivers/memory/tegra/tegra124-mc.c new file +32
-0@@ -0,0 +1,1028 @@ +/* +* Copyright (C) 2014 NVIDIA CORPORATION. All rights reserved. +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +*/ + +#include <linux/of.h> +#include <linux/mm.h> + +#include <asm/cacheflush.h> + +#include <dt-bindings/memory/tegra124-mc.h> + +#include "tegra-mc.h" + +static const struct tegra_mc_client tegra124_mc_clients[] = { + { + .id =0x00 , + .name ="ptcr" , + .swgroup =TEGRA_SWGROUP_PTC , + }, { + .id =0x01 , + .name ="display0a" , + .swgroup =TEGRA_SWGROUP_DC , + .smmu = { + .reg =0x228 , + .bit =1 , + }, + .latency = { + .reg =0x2e8 ,
Quoted 8 lines
drivers/memory/tegra/tegra124-mc.c line 37
Quoted 5 lines
drivers/memory/tegra/tegra124-mc.c new file +5
-0+ .shift = 0, + .mask = 0xff, + .def = 0xc2, + }, + }, {These are very verbose tables. Having a macro for the initializers could help density a lot.
I've tried to use macros here, but I find that it hurts readability:
...
}, {
TEGRA_MC_CLIENT(0x01, "display0a", TEGRA_SWGROUP_DC),
TEGRA_MC_SMMU_ENABLE(0x228, 1),
TEGRA_MC_LATENCY(0x2e8, 0, 0xff, 0xc2),
}, {
...The original is more readable because it immediately gives you the context, whereas with the macros you need to look up what the parameters refer to.
Quoted 39 lines
Quoted 24 lines
drivers/memory/tegra/tegra124-mc.c new file +24
-0+#ifdef CONFIG_ARCH_TEGRA_132_SOC +static void tegra132_flush_dcache (struct page *page,unsigned long offset, +size_t size) +{ +void *virt =page_address (page) + offset; + +__flush_dcache_area (virt, size); +} + +static const struct tegra_smmu_ops tegra132_smmu_ops = { + .flush_dcache = tegra132_flush_dcache, +}; + +static const struct tegra_smmu_soc tegra132_smmu_soc = { + .groups = tegra124_smmu_groups, + .num_groups =ARRAY_SIZE (tegra124_smmu_groups), + .clients = tegra124_mc_clients, + .num_clients =ARRAY_SIZE (tegra124_mc_clients), + .swgroups = tegra124_swgroups, + .num_swgroups =ARRAY_SIZE (tegra124_swgroups), + .supports_round_robin_arbitration = true, + .supports_request_limit = true, + .num_address_bits =34 , + .num_asids = 128,drivers/memory/tegra/tegra124-mc.c line 1028
Quoted 10 lines
drivers/memory/tegra/tegra124-mc.c new file +10
-0+ .ops = &tegra132_smmu_ops, +}; + +const struct tegra_mc_soc tegra132_mc_soc = { + .clients = tegra124_mc_clients, + .num_clients =ARRAY_SIZE (tegra124_mc_clients), + .atom_size =32 , + .smmu = &tegra132_smmu_soc, +}; +#endif /* CONFIG_ARCH_TEGRA_132_SOC */ This won't compile -- several of the
tegra132_smmu_socmembers are no longer valid. In particular:
Quoted 2 lines
groups
num_groups
Fixed.
Quoted 2 lines
supports_round_robin_arbitrationsupports_request_limit
In the version that I have these are still part of the tegra_smmu_soc structure.
I've been thinking of extracting the Tegra132 changes into a separate patch that can be applied once we have basic Tegra132 SoC support. It feels wrong to merge Tegra132 SMMU support if there's no support in arch/arm64 for the SoC yet. Though if nobody else thinks that's a problem that's fine with me too.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141030/cd26dcf3/attachment-0001.sig>
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
In reply to Thierry RedingHi,
Oh, a few more comments:
Quoted 17 lines · Thierry Reding
drivers/memory/Makefile +2
-1@@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/drivers/memory/tegra/Makefile new file +0
-0
drivers/memory/tegra/Makefile line 5
Quoted 5 lines
drivers/memory/tegra/Makefile new file +5
-0@@ -0,0 +1,5 @@ +obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.o
You'll need a Kconfig and not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular).
Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash).
I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though.
-Olof
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 24 lines · Olof Johansson
Hi,
Oh, a few more comments:
Quoted 17 lines · Thierry Reding
drivers/memory/Makefile +2
-1@@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/drivers/memory/tegra/Makefile new file +0
-0@@ -0,0 +1,5 @@
Quoted 8 lines
drivers/memory/tegra/Makefile line 5
Quoted 5 lines
drivers/memory/tegra/Makefile new file +5
-0+obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.oYou'll need a
Kconfigand not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular).
This is handled within the tegra-mc driver by only setting up the IOMMU when TEGRA_IOMMU_SMMU is enabled. That config option remains in place.
Quoted 6 lines
Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash).
I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though.
I don't think I ever got back to you on this. We discussed this internally and it seems like there's no way to detect this properly, so the best suggestion so far was to make it a requirement on the secure firmware to enable IOMMU or not. Since there's no way for the kernel to detect whether IOMMU was enabled or not, I think the firmware would equally have to adjust the SMMU's device tree node's status property appropriately.
Stephen, does that accurately reflect what we had discussed?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141030/0ed5e355/attachment.sig>
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 44 lines · Thierry Reding
Quoted 24 lines · Olof Johansson
Hi,
Oh, a few more comments:
Quoted 17 lines · Thierry Reding
drivers/memory/Makefile +2
-1@@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/drivers/memory/tegra/Makefile new file +0
-0@@ -0,0 +1,5 @@Quoted 8 lines
drivers/memory/tegra/Makefile line 5
Quoted 5 lines
drivers/memory/tegra/Makefile new file +5
-0+obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.oYou'll need a
Kconfigand not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular).This is handled within the tegra-mc driver by only setting up the IOMMU when
TEGRA_IOMMU_SMMUis enabled. That config option remains in place.Quoted 6 lines
Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash).
I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though.
Quoted 7 lines
I don't think I ever got back to you on this. We discussed this internally and it seems like there's no way to detect this properly, so the best suggestion so far was to make it a requirement on the secure firmware to enable IOMMU or not. Since there's no way for the kernel to detect whether IOMMU was enabled or not, I think the firmware would equally have to adjust the SMMU's device tree node's status property appropriately.
The other option would be for the firmware not to touch the SMMU device tree node and the kernel simply assuming that if it's running in non- secure mode then there must be secure firmware and it has enabled the SMMU. Enabling the SMMU would become part of the contract between firmware and kernel, much like locking the VPR is required to get the GPU to work.
Those are really the only two choices we have.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141031/a42133d3/attachment-0001.sig>
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 53 lines · Thierry Reding
Quoted 44 lines · Thierry Reding
Quoted 24 lines · Olof Johansson
Hi,
Oh, a few more comments:
Quoted 17 lines · Thierry Reding
drivers/memory/Makefile +2
-1@@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/drivers/memory/tegra/Makefile new file +0
-0@@ -0,0 +1,5 @@Quoted 8 lines
drivers/memory/tegra/Makefile line 5
Quoted 5 lines
drivers/memory/tegra/Makefile new file +5
-0+obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.oYou'll need a
Kconfigand not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular).This is handled within the tegra-mc driver by only setting up the IOMMU when
TEGRA_IOMMU_SMMUis enabled. That config option remains in place.Quoted 6 lines
Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash).
I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though.
Quoted 7 lines
I don't think I ever got back to you on this. We discussed this internally and it seems like there's no way to detect this properly, so the best suggestion so far was to make it a requirement on the secure firmware to enable IOMMU or not. Since there's no way for the kernel to detect whether IOMMU was enabled or not, I think the firmware would equally have to adjust the SMMU's device tree node's status property appropriately.
Quoted 8 lines
The other option would be for the firmware not to touch the SMMU device tree node and the kernel simply assuming that if it's running in non- secure mode then there must be secure firmware and it has enabled the SMMU. Enabling the SMMU would become part of the contract between firmware and kernel, much like locking the VPR is required to get the GPU to work.
Those are really the only two choices we have.
We got the exact same problem with GPU and VPR registers, and it seems like the approach we will be taking here is to have the firmware/bootloader do whatever is needed to get the GPU working and enable the DT node once it did. IOW, the kernel will never touch protected registers, and will not freeze if the hardware is not properly set up.
It would be nice for consistency if the same approach can be taken with the IOMMU. OTOH we will need to make sure that all these initialization contracts are clearly documented somewhere. Maybe a comment in the DTS to explain what is expected from the firmware to enable such nodes would be a good idea, too.
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 62 lines · Alexandre Courbot
Quoted 60 lines · Thierry Reding
Quoted 44 lines · Thierry Reding
Quoted 24 lines · Olof Johansson
Hi,
Oh, a few more comments:
Quoted 17 lines · Thierry Reding
drivers/memory/Makefile +2
-1@@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/drivers/memory/tegra/Makefile new file +0
-0@@ -0,0 +1,5 @@Quoted 8 lines
drivers/memory/tegra/Makefile line 5
Quoted 5 lines
drivers/memory/tegra/Makefile new file +5
-0+obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.oYou'll need a
Kconfigand not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular).This is handled within the tegra-mc driver by only setting up the IOMMU when
TEGRA_IOMMU_SMMUis enabled. That config option remains in place.Quoted 6 lines
Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash).
I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though.
Quoted 7 lines
I don't think I ever got back to you on this. We discussed this internally and it seems like there's no way to detect this properly, so the best suggestion so far was to make it a requirement on the secure firmware to enable IOMMU or not. Since there's no way for the kernel to detect whether IOMMU was enabled or not, I think the firmware would equally have to adjust the SMMU's device tree node's status property appropriately.
The other option would be for the firmware not to touch the SMMU device tree node and the kernel simply assuming that if it's running in non- secure mode then there must be secure firmware and it has enabled the SMMU. Enabling the SMMU would become part of the contract between firmware and kernel, much like locking the VPR is required to get the GPU to work.
Quoted 8 lines
Quoted 1 line
Those are really the only two choices we have.
We got the exact same problem with GPU and VPR registers, and it seems like the approach we will be taking here is to have the
firmware/bootloaderdo whatever is needed to get the GPU working and enable the DT node once it did. IOW, the kernel will never touch protected registers, and will not freeze if the hardware is not properly set up.
I think the situation is slightly different. For the SMMU we still have the option to enable translations when running in secure mode with code that's pretty trivial to have in the IOMMU driver (it's just a single bit that gets written to a register). And when the IOMMU driver does that everything will work just fine.
So I'm thinking that a workable alternative to what we've done for VPR would be to just always enable translations in the SMMU driver (that operation will simply be discarded in non-secure mode) and assume that it'll work. So the contract would be that running in secure mode the kernel sets everything up and when running in non-secure mode the kernel will assume that firmware set everything up already.
Requiring firmware to change the device node's status to "okay" seems rather restrictive since it would have to do that even if it boots the kernel in secure mode.
Quoted 5 lines
It would be nice for consistency if the same approach can be taken with the IOMMU. OTOH we will need to make sure that all these initialization contracts are clearly documented somewhere. Maybe a comment in the DTS to explain what is expected from the firmware to enable such nodes would be a good idea, too.
The device tree binding seems like a good place to document this.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141103/163c6cc3/attachment-0001.sig>
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 85 lines · Thierry Reding
Quoted 62 lines · Alexandre Courbot
Quoted 60 lines · Thierry Reding
Quoted 44 lines · Thierry Reding
Quoted 24 lines · Olof Johansson
Hi,
Oh, a few more comments:
Quoted 17 lines · Thierry Reding
drivers/memory/Makefile +2
-1@@ -12,4 +12,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o + +obj-$(CONFIG_ARCH_TEGRA) += tegra/drivers/memory/tegra/Makefile new file +0
-0@@ -0,0 +1,5 @@Quoted 8 lines
drivers/memory/tegra/Makefile line 5
Quoted 5 lines
drivers/memory/tegra/Makefile new file +5
-0+obj-y = tegra-mc.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30-mc.o +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.oYou'll need a
Kconfigand not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular).This is handled within the tegra-mc driver by only setting up the IOMMU when
TEGRA_IOMMU_SMMUis enabled. That config option remains in place.Quoted 6 lines
Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash).
I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though.
Quoted 7 lines
I don't think I ever got back to you on this. We discussed this internally and it seems like there's no way to detect this properly, so the best suggestion so far was to make it a requirement on the secure firmware to enable IOMMU or not. Since there's no way for the kernel to detect whether IOMMU was enabled or not, I think the firmware would equally have to adjust the SMMU's device tree node's status property appropriately.
The other option would be for the firmware not to touch the SMMU device tree node and the kernel simply assuming that if it's running in non- secure mode then there must be secure firmware and it has enabled the SMMU. Enabling the SMMU would become part of the contract between firmware and kernel, much like locking the VPR is required to get the GPU to work.
Quoted 8 lines
Quoted 1 line
Those are really the only two choices we have.
We got the exact same problem with GPU and VPR registers, and it seems like the approach we will be taking here is to have the
firmware/bootloaderdo whatever is needed to get the GPU working and enable the DT node once it did. IOW, the kernel will never touch protected registers, and will not freeze if the hardware is not properly set up.I think the situation is slightly different. For the SMMU we still have the option to enable translations when running in secure mode with code that's pretty trivial to have in the IOMMU driver (it's just a single bit that gets written to a register). And when the IOMMU driver does that everything will work just fine.
So I'm thinking that a workable alternative to what we've done for VPR would be to just always enable translations in the SMMU driver (that operation will simply be discarded in non-secure mode) and assume that it'll work. So the contract would be that running in secure mode the kernel sets everything up and when running in non-secure mode the kernel will assume that firmware set everything up already.
Quoted 3 lines
Requiring firmware to change the device node's status to "okay" seems rather restrictive since it would have to do that even if it boots the kernel in secure mode.
Sounds good to me, as long as the kernel can always run using the same code in both modes.
Quoted 8 lines
Quoted 6 lines
It would be nice for consistency if the same approach can be taken with the IOMMU. OTOH we will need to make sure that all these initialization contracts are clearly documented somewhere. Maybe a comment in the DTS to explain what is expected from the firmware to enable such nodes would be a good idea, too.
The device tree binding seems like a good place to document this.
Indeed.
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
In reply to Thierry RedingQuoted 1 line
drivers/memory/tegra/tegra124-mc.c +0
-0
...
Quoted 8 lines
drivers/memory/tegra/tegra124-mc.c +8
-0+static const struct tegra_smmu_swgroup tegra124_swgroups[] = { + { .swgroup =TEGRA_SWGROUP_DC , .reg =0x240 }, + { .swgroup =TEGRA_SWGROUP_DCB , .reg =0x244 }, + { .swgroup =TEGRA_SWGROUP_AFI , .reg =0x238 }, + { .swgroup =TEGRA_SWGROUP_AVPC , .reg =0x23c }, + { .swgroup =TEGRA_SWGROUP_HDA , .reg =0x254 }, + { .swgroup =TEGRA_SWGROUP_HC , .reg =0x250 }, + { .swgroup =TEGRA_SWGROUP_MSENC , .reg =0x264 },
drivers/memory/tegra/tegra124-mc.c line 953
Quoted 10 lines
drivers/memory/tegra/tegra124-mc.c +10
-0+ { .swgroup = TEGRA_SWGROUP_PPCS, .reg = 0x270 }, + { .swgroup = TEGRA_SWGROUP_SATA, .reg = 0x274 }, + { .swgroup = TEGRA_SWGROUP_VDE, .reg = 0x27c }, + { .swgroup = TEGRA_SWGROUP_ISP2, .reg = 0x258 }, + { .swgroup = TEGRA_SWGROUP_XUSB_HOST, .reg = 0x288 }, + { .swgroup = TEGRA_SWGROUP_XUSB_DEV, .reg = 0x28c }, + { .swgroup = TEGRA_SWGROUP_ISP2B, .reg = 0xaa4 }, + { .swgroup = TEGRA_SWGROUP_TSEC, .reg = 0x294 }, + { .swgroup = TEGRA_SWGROUP_A9AVP, .reg = 0x290 }, + { .swgroup = TEGRA_SWGROUP_GPU, .reg = 0xaa8 },
I had to change the .reg of TEGRA_SWGROUP_GPU to 0xaac to get the IOMMU to work with GK20A. The reason is still not completely clear to me, but if you look at the TRM you see that 0xaa8 is basically constant, with the SMMU translation bit hardcoded to DISABLE (and the ASID field being meaningless in that case). However right after that register you have a functional one named GPUB instead of GPU, and this one is fully writeable (and has the expected effect).
I will try to get more information about the why of this, but for now this setting is what works for me.
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 7 lines · Alexandre Courbot
I had to change the .reg of
TEGRA_SWGROUP_GPUto0xaacto get the IOMMU to work with GK20A. The reason is still not completely clear to me, but if you look at the TRM you see that0xaa8is basically constant, with the SMMU translation bit hardcoded to DISABLE (and the ASID field being meaningless in that case). However right after that register you have a functional one named GPUB instead of GPU, and this one is fully writeable (and has the expected effect).
GPU has two SW group IDs, because it accesses memory both with and without translation. The bit 34 in addresses in f.ex. PTE chooses between the two.
GPU is hard-wired to disable translation. For GPUB translation can be enabled.
Terje
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 9 lines · Terje Bergstr?m
Quoted 7 lines · Alexandre Courbot
I had to change the .reg of
TEGRA_SWGROUP_GPUto0xaacto get the IOMMU to work with GK20A. The reason is still not completely clear to me, but if you look at the TRM you see that0xaa8is basically constant, with the SMMU translation bit hardcoded to DISABLE (and the ASID field being meaningless in that case). However right after that register you have a functional one named GPUB instead of GPU, and this one is fully writeable (and has the expected effect).
Quoted 3 lines
GPU has two SW group IDs, because it accesses memory both with and without translation. The bit 34 in addresses in f.ex. PTE chooses between the two.
Indeed, to enable SMMU translation I have to program 0xaac correctly *and* set the bit 34 of every address that needs to go through the SMMU.
Quoted 2 lines
GPU is hard-wired to disable translation. For GPUB translation can be enabled.
So should I understand that the GPU group is for addresses without bit 34 set (hence forcibly disabled) while GPUB is used when that bit is set? Or is it something else?
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 3 lines · Alexandre Courbot
So should I understand that the GPU group is for addresses without bit 34 set (hence forcibly disabled) while GPUB is used when that bit is set? Or is it something else?
That's exactly correct. And only GPUB can be programmed to be SMMU translated.
Terje
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 7 lines · Terje Bergstr?m
Quoted 3 lines · Alexandre Courbot
So should I understand that the GPU group is for addresses without bit 34 set (hence forcibly disabled) while GPUB is used when that bit is set? Or is it something else?
That's exactly correct. And only GPUB can be programmed to be SMMU translated.
Great, thanks for confirming!
Thierry, how do you want to address this? We could change the register for the GPU group, or (maybe preferable if we want to reflect the actual hardware state) add the GPUB group. I don't know if that would be easy though since we would have the problem of the gpusrd and gpuswr clients ownership (seems like they would belong to both groups?)
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 7 lines · Alexandre Courbot
Great, thanks for confirming!
Thierry, how do you want to address this? We could change the register for the GPU group, or (maybe preferable if we want to reflect the actual hardware state) add the GPUB group. I don't know if that would be easy though since we would have the problem of the gpusrd and gpuswr clients ownership (seems like they would belong to both groups?)
gpusrd and gpuswr are client IDs for GPU reads and writes on MC. GPU and GPUB are SW group IDs for SMMU. There's no 1:1 or hierarchical mapping.
Terje
PATCH v4 5/12 memory: Add NVIDIA Tegra memory controller support
Quoted 11 lines · Terje Bergstr?m
Quoted 7 lines · Alexandre Courbot
Great, thanks for confirming!
Thierry, how do you want to address this? We could change the register for the GPU group, or (maybe preferable if we want to reflect the actual hardware state) add the GPUB group. I don't know if that would be easy though since we would have the problem of the gpusrd and gpuswr clients ownership (seems like they would belong to both groups?)
gpusrd and gpuswr are client IDs for GPU reads and writes on MC. GPU and GPUB are SW group IDs for SMMU. There's no 1:1 or hierarchical mapping.
Since the GPU client ID is effectively useless for purposes of IOMMU translation I'd lean towards just keeping the existing TEGRA_SWGROUP_GPU and update the register to point to MC_SMMU_GPUB_ASID_0.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141030/3318166e/attachment.sig>
PATCH 6/12 ARM: tegra: Add memory controller support for Tegra20
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Collapses the old memory-controller and IOMMU device tree nodes into a single node to more accurately describe the hardware.
Note that this is an incompatible change, but while a GART driver has existed for a few years it has never been used to do any translations.
--- arch/arm/boot/dts/tegra20.dtsi | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)
arch/arm/boot/dts/tegra20.dtsi +6 -7
@@ -538,15 +538,14 @@ memory-controller at 7000f000 { compatible = "nvidia,tegra20-mc"; - reg = <0x7000f000 0x024 - 0x7000f03c 0x3c4>; + reg = <0x7000f000 0x00000400 /* controller registers */ + 0x58000000 0x02000000>; /* GART aperture */ + clocks = <&tegra_car TEGRA20_CLK_MC>; + clock-names = "mc"; + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; - }; - iommu at 7000f024 { - compatible = "nvidia,tegra20-gart"; - reg = <0x7000f024 0x00000018 /* controller registers */ - 0x58000000 0x02000000>; /* GART aperture */ + #iommu-cells = <1>; }; memory-controller at 7000f400 {
Signature · 1 line
2.1.2
PATCH 6/12 ARM: tegra: Add memory controller support for Tegra20
Hi Thierry,
Quoted 18 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Collapses the old memory-controller and IOMMU device tree nodes into a single node to more accurately describe the hardware.
Note that this is an incompatible change, but while a GART driver has existed for a few years it has never been used to do any translations.
Signed-off-by Thierry Reding <[email protected]>--- arch/arm/boot/dts/tegra20.dtsi | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)arch/arm/boot/dts/tegra20.dtsi +0
-0
arch/arm/boot/dts/tegra20.dtsi line 542
Quoted 7 lines
arch/arm/boot/dts/tegra20.dtsi +2
-2@@ -538,15 +538,14 @@ memory-controller at 7000f000 { compatible = "nvidia,tegra20-mc"; - reg = <0x7000f000 0x024 - 0x7000f03c 0x3c4>; + reg = <0x7000f000 0x00000400 /* controller registers */ + 0x58000000 0x02000000>; /* GART aperture */
Aren't these bindings supposed to be stable? The tegra20-mc driver isn't modified.
Quoted 17 lines
arch/arm/boot/dts/tegra20.dtsi +4
-6+ clocks = <&tegra_car TEGRA20_CLK_MC>; + clock-names = "mc"; + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; - }; - iommu at 7000f024 { - compatible = "nvidia,tegra20-gart"; - reg = <0x7000f024 0x00000018 /* controller registers */ - 0x58000000 0x02000000>; /* GART aperture */ + #iommu-cells = <1>; }; memory-controller at 7000f400 { --2.1.2
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dave
PATCH 6/12 ARM: tegra: Add memory controller support for Tegra20
Quoted 23 lines · David Riley
Hi Thierry,
Quoted 19 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Collapses the old memory-controller and IOMMU device tree nodes into a single node to more accurately describe the hardware.
Note that this is an incompatible change, but while a GART driver has existed for a few years it has never been used to do any translations.
Signed-off-by Thierry Reding <[email protected]>--- arch/arm/boot/dts/tegra20.dtsi | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)arch/arm/boot/dts/tegra20.dtsi +0
-0@@ -538,15 +538,14 @@
Quoted 9 lines
arch/arm/boot/dts/tegra20.dtsi line 542
Quoted 6 lines
arch/arm/boot/dts/tegra20.dtsi +2
-2memory-controller at 7000f000 { compatible = "nvidia,tegra20-mc"; - reg = <0x7000f000 0x024 - 0x7000f03c 0x3c4>; + reg = <0x7000f000 0x00000400 /* controller registers */ + 0x58000000 0x02000000>; /* GART aperture */Aren't these bindings supposed to be stable? The tegra20-mc driver isn't modified.
You're right in that this particular patch should be deferred until the Tegra20 driver has been updated.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141030/99dc4245/attachment.sig>
PATCH 7/12 ARM: tegra: Add memory controller support for Tegra30
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Collapses the old memory-controller and IOMMU device tree nodes into a single node to more accurately describe the hardware.
While this is an incompatible change there are no users of the IOMMU on Tegra, even though a driver has existed for some time.
--- arch/arm/boot/dts/tegra30.dtsi | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-)
arch/arm/boot/dts/tegra30.dtsi +6 -14
@@ -623,23 +623,15 @@ clock-names = "pclk", "clk32k_in"; }; - memory-controller at 7000f000 { + mc: memory-controller at 7000f000 { compatible = "nvidia,tegra30-mc"; - reg = <0x7000f000 0x010 - 0x7000f03c 0x1b4 - 0x7000f200 0x028 - 0x7000f284 0x17c>; + reg = <0x7000f000 0x400>; + clocks = <&tegra_car TEGRA30_CLK_MC>; + clock-names = "mc"; + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; - }; - iommu at 7000f010 { - compatible = "nvidia,tegra30-smmu"; - reg = <0x7000f010 0x02c - 0x7000f1f0 0x010 - 0x7000f228 0x05c>; - nvidia,#asids = <4>; /* # of ASIDs */ - dma-window = <0 0x40000000>; /* IOVA start & length */ - nvidia,ahb = <&ahb>; + #iommu-cells = <1>; }; fuse at 7000f800 {
Signature · 1 line
2.1.2
PATCH 8/12 ARM: tegra: Add memory controller support for Tegra114
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Add the device tree node for the memory controller found on Tegra114 SoCs. The memory controller integrates an IOMMU (called SMMU) as well as various knobs to tweak memory accesses by the various clients.
The old IOMMU device tree node is collapsed into the memory controller node to more accurately describe the hardware. While this change is incompatible, the IOMMU driver has never had any users so the change is not going to cause any breakage.
--- arch/arm/boot/dts/tegra114.dtsi | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
arch/arm/boot/dts/tegra114.dtsi +9 -9
@@ -505,15 +505,15 @@ reset-names = "fuse"; }; - iommu at 70019010 { - compatible = "nvidia,tegra114-smmu", "nvidia,tegra30-smmu"; - reg = <0x70019010 0x02c - 0x700191f0 0x010 - 0x70019228 0x074>; - nvidia,#asids = <4>; - dma-window = <0 0x40000000>; - nvidia,swgroups = <0x18659fe>; - nvidia,ahb = <&ahb>; + mc: memory-controller at 70019000 { + compatible = "nvidia,tegra114-mc"; + reg = <0x70019000 0x1000>; + clocks = <&tegra_car TEGRA114_CLK_MC>; + clock-names = "mc"; + + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; + + #iommu-cells = <1>; }; ahub at 70080000 {
Signature · 1 line
2.1.2
PATCH 9/12 ARM: tegra: Add memory controller support for Tegra124
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Add the memory controller and wire up the interrupt that is used to report errors. Provide a reference to the memory controller clock and mark the device as being an IOMMU by adding an #iommu-cells property.
--- arch/arm/boot/dts/tegra124.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+)
arch/arm/boot/dts/tegra124.dtsi +11 -0
@@ -551,6 +551,17 @@ reset-names = "fuse"; }; + mc: memory-controller at 0,70019000 { + compatible = "nvidia,tegra124-mc"; + reg = <0x0 0x70019000 0x0 0x1000>; + clocks = <&tegra_car TEGRA124_CLK_MC>; + clock-names = "mc"; + + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; + + #iommu-cells = <1>; + }; + sata at 0,70020000 { compatible = "nvidia,tegra124-ahci";
Signature · 1 line
2.1.2
PATCH 10/12 ARM: tegra: Enable IOMMU for display controllers on Tegra30
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Add iommus properties to the device tree nodes for the two display controllers found on Tegra30. This will allow the display controllers to map physically non-contiguous buffers to I/O virtual contiguous address spaces so that they can be used for scan-out.
--- arch/arm/boot/dts/tegra30.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/boot/dts/tegra30.dtsi +5 -0
@@ -1,5 +1,6 @@ #include <dt-bindings/clock/tegra30-car.h> #include <dt-bindings/gpio/tegra-gpio.h> +#include <dt-bindings/memory/tegra30-mc.h> #include <dt-bindings/pinctrl/pinctrl-tegra.h> #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -174,6 +175,8 @@ resets = <&tegra_car 27>; reset-names = "dc"; + iommus = <&mc TEGRA_SWGROUP_DC>; + nvidia,head = <0>; rgb {
@@ -191,6 +194,8 @@ resets = <&tegra_car 26>; reset-names = "dc"; + iommus = <&mc TEGRA_SWGROUP_DCB>; + nvidia,head = <1>; rgb {
Signature · 1 line
2.1.2
PATCH 11/12 ARM: tegra: Enable IOMMU for display controllers on Tegra114
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Add iommus properties to the device tree nodes for the two display controllers found on Tegra114. This will allow the display controllers to map physically non-contiguous buffers to I/O virtual contiguous address spaces so that they can be used for scan-out.
--- arch/arm/boot/dts/tegra114.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/boot/dts/tegra114.dtsi +5 -0
@@ -1,5 +1,6 @@ #include <dt-bindings/clock/tegra114-car.h> #include <dt-bindings/gpio/tegra-gpio.h> +#include <dt-bindings/memory/tegra114-mc.h> #include <dt-bindings/pinctrl/pinctrl-tegra.h> #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -57,6 +58,8 @@ resets = <&tegra_car 27>; reset-names = "dc"; + iommus = <&mc TEGRA_SWGROUP_DC>; + nvidia,head = <0>; rgb {
@@ -74,6 +77,8 @@ resets = <&tegra_car 26>; reset-names = "dc"; + iommus = <&mc TEGRA_SWGROUP_DCB>; + nvidia,head = <1>; rgb {
Signature · 1 line
2.1.2
PATCH 12/12 ARM: tegra: Enable IOMMU for display controllers on Tegra124
In reply to Thierry RedingFrom: Thierry Reding <[email protected]>
Add iommus properties to the device tree nodes for the two display controllers found on Tegra124. This will allow the display controllers to map physically non-contiguous buffers to I/O virtual contiguous address spaces so that they can be used for scan-out.
--- arch/arm/boot/dts/tegra124.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/boot/dts/tegra124.dtsi +5 -0
@@ -1,5 +1,6 @@ #include <dt-bindings/clock/tegra124-car.h> #include <dt-bindings/gpio/tegra-gpio.h> +#include <dt-bindings/memory/tegra124-mc.h> #include <dt-bindings/pinctrl/pinctrl-tegra.h> #include <dt-bindings/pinctrl/pinctrl-tegra-xusb.h> #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -102,6 +103,8 @@ resets = <&tegra_car 27>; reset-names = "dc"; + iommus = <&mc TEGRA_SWGROUP_DC>; + nvidia,head = <0>; };
@@ -115,6 +118,8 @@ resets = <&tegra_car 26>; reset-names = "dc"; + iommus = <&mc TEGRA_SWGROUP_DCB>; + nvidia,head = <1>; };
Signature · 1 line
2.1.2
PATCH v3 1/12 clk: tegra: Implement memory-controller clock
In reply to Thierry RedingQuoted 33 lines · Thierry Reding
From: Thierry Reding <[email protected]>
The memory controller clock runs either at half or the same frequency as the EMC clock.
Signed-off-by Thierry Reding <[email protected]>---
Changes in v3:
- split registration into a separate function that can be reused for all SoC generations, but pass in the name and parent parameters for clarity as well as the register address (in case it ever changes) and the EMC spin-lock since it isn't globally availabledrivers/clk/tegra/clk-divider.c | 13 +++++++++++++ drivers/clk/tegra/clk-tegra114.c | 7 ++++++- drivers/clk/tegra/clk-tegra124.c | 7 ++++++- drivers/clk/tegra/clk-tegra20.c | 8 +++++++- drivers/clk/tegra/clk-tegra30.c | 7 ++++++- drivers/clk/tegra/clk.h | 2 ++ include/dt-bindings/clock/tegra114-car.h | 2 +- include/dt-bindings/clock/tegra124-car.h | 2 +- include/dt-bindings/clock/tegra20-car.h | 2 +- 9 files changed, 43 insertions(+), 7 deletions(-)drivers/clk/tegra/clk-divider.c +1
-0@@ -185,3 +185,16 @@ struct clk *tegra_clk_register_divider(const char *name,return clk; } +
drivers/clk/tegra/clk-divider.c struct clk *tegra_clk_register_divider(const char *name, · line 198
Quoted 10 lines
drivers/clk/tegra/clk-divider.c +10
-0+static const struct clk_div_table mc_div_table[] = { + { .val =0 , .div =2 }, + { .val =1 , .div =1 }, + { .val =0 , .div =0 }, +}; + +struct clk *tegra_clk_register_mc (const char *name,const char *parent_name, +void __iomem *reg,spinlock_t *lock) +{ + return clk_register_divider_table(NULL, "mc", "emc_mux", 0, reg,
Should take name and parent_name from the passed args?
With that change:
Cheers,
Tomeu
Quoted 170 lines
drivers/clk/tegra/clk-divider.c +2
-0+ 16, 1, 0, mc_div_table, lock); +}drivers/clk/tegra/clk-tegra114.c +6
-1@@ -173,6 +173,7 @@ static DEFINE_SPINLOCK(pll_d_lock);static DEFINE_SPINLOCK (pll_d2_lock);static DEFINE_SPINLOCK (pll_u_lock);static DEFINE_SPINLOCK (pll_re_lock); +static DEFINE_SPINLOCK (emc_lock);static struct div_nmp pllxc_nmp = { .divm_shift =0 ,@@ -1228,7 +1229,11 @@ static __init void tegra114_periph_clk_init(void __iomem *clk_base,ARRAY_SIZE (mux_pllmcp_clkm),CLK_SET_RATE_NO_REPARENT , clk_base +CLK_SOURCE_EMC , - 29, 3, 0, NULL); + 29, 3, 0, &emc_lock); + + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA114_CLK_MC ] = clk;for (i =0 ; i <ARRAY_SIZE (tegra_periph_clk_list); i++) { data = &tegra_periph_clk_list[i];drivers/clk/tegra/clk-tegra124.c +6
-1@@ -132,6 +132,7 @@ static DEFINE_SPINLOCK(pll_d2_lock);static DEFINE_SPINLOCK (pll_e_lock);static DEFINE_SPINLOCK (pll_re_lock);static DEFINE_SPINLOCK (pll_u_lock); +static DEFINE_SPINLOCK (emc_lock);/* possible OSC frequencies in Hz */ static unsigned long tegra124_input_freq[] = {@@ -1127,7 +1128,11 @@ static __init void tegra124_periph_clk_init(void __iomem *clk_base, clk =clk_register_mux (NULL ,"emc_mux" , mux_pllmcp_clkm,ARRAY_SIZE (mux_pllmcp_clkm),0 , clk_base +CLK_SOURCE_EMC , -29 ,3 ,0 ,NULL ); +29 ,3 ,0 , &emc_lock); + + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA124_CLK_MC ] = clk;/* cml0 */ clk = clk_register_gate(NULL, "cml0", "pll_e", 0, clk_base + PLLE_AUX,drivers/clk/tegra/clk-tegra20.c +7
-1@@ -140,6 +140,8 @@ static struct cpu_clk_suspend_context {static void __iomem *clk_base;static void __iomem *pmc_base; +static DEFINE_SPINLOCK (emc_lock); +#define TEGRA_INIT_DATA_MUX (_name, _parents, _offset, \ _clk_num, _gate_flags, _clk_id) \ TEGRA_INIT_DATA(_name, NULL, NULL, _parents, _offset, \@@ -819,11 +821,15 @@ static void __init tegra20_periph_clk_init(void)ARRAY_SIZE (mux_pllmcp_clkm),CLK_SET_RATE_NO_REPARENT , clk_base +CLK_SOURCE_EMC , - 30, 2, 0, NULL); + 30, 2, 0, &emc_lock); clk =tegra_clk_register_periph_gate ("emc" ,"emc_mux" ,0 , clk_base,0 ,57 , periph_clk_enb_refcnt); clks[TEGRA20_CLK_EMC ] = clk; + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA20_CLK_MC ] = clk; +/* dsi */ clk =tegra_clk_register_periph_gate ("dsi" ,"pll_d" ,0 , clk_base,0 ,48 , periph_clk_enb_refcnt);drivers/clk/tegra/clk-tegra30.c +6
-1@@ -177,6 +177,7 @@ static unsigned long input_freq;static DEFINE_SPINLOCK (cml_lock);static DEFINE_SPINLOCK (pll_d_lock); +static DEFINE_SPINLOCK (emc_lock);#define TEGRA_INIT_DATA_MUX (_name, _parents, _offset, \ _clk_num, _gate_flags, _clk_id) \@@ -1157,11 +1158,15 @@ static void __init tegra30_periph_clk_init(void)ARRAY_SIZE (mux_pllmcp_clkm),CLK_SET_RATE_NO_REPARENT , clk_base +CLK_SOURCE_EMC , - 30, 2, 0, NULL); + 30, 2, 0, &emc_lock); clk =tegra_clk_register_periph_gate ("emc" ,"emc_mux" ,0 , clk_base,0 ,57 , periph_clk_enb_refcnt); clks[TEGRA30_CLK_EMC ] = clk; + clk =tegra_clk_register_mc ("mc" ,"emc_mux" , clk_base +CLK_SOURCE_EMC , + &emc_lock); + clks[TEGRA30_CLK_MC ] = clk; +/* cml0 */ clk =clk_register_gate (NULL ,"cml0" ,"pll_e" ,0 , clk_base +PLLE_AUX ,0 ,0 , &cml_lock);drivers/clk/tegra/clk.h +2
-0@@ -86,6 +86,8 @@ struct clk *tegra_clk_register_divider(const char *name, const char *parent_name, void __iomem *reg, unsigned long flags, u8 clk_divider_flags, u8 shift, u8 width, u8 frac_width, spinlock_t *lock); +struct clk *tegra_clk_register_mc (const char *name,const char *parent_name, +void __iomem *reg,spinlock_t *lock);/* * Tegra PLL: include/dt-bindings/clock/tegra114-car.h +1
-1@@ -49,7 +49,7 @@#define TEGRA114_CLK_I2S0 30/* 31 */ -/* 32 */ +#define TEGRA114_CLK_MC 32/* 33 */ #define TEGRA114_CLK_APBDMA 34/* 35 */ include/dt-bindings/clock/tegra124-car.h +1
-1@@ -48,7 +48,7 @@#define TEGRA124_CLK_I2S0 30/* 31 */ -/* 32 */ +#define TEGRA124_CLK_MC 32/* 33 */ #define TEGRA124_CLK_APBDMA 34/* 35 */ include/dt-bindings/clock/tegra20-car.h +1
-2@@ -49,7 +49,7 @@/* 30 */ #define TEGRA20_CLK_CACHE2 31 -#define TEGRA20_CLK_MEM 32 +#define TEGRA20_CLK_MC 32#define TEGRA20_CLK_AHBDMA 33#define TEGRA20_CLK_APBDMA 34/* 35 */ --2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v3 1/12 clk: tegra: Implement memory-controller clock
Quoted 1 line · Tomeu Vizoso
On 13 October 2014 12:33, Thierry Reding <[email protected]> wrote:
[...]
Quoted 10 lines
drivers/clk/tegra/clk-divider.c struct clk *tegra_clk_register_divider(const char *name, · line 198
Quoted 4 lines
drivers/clk/tegra/clk-divider.c +4
-0+struct clk *tegra_clk_register_mc (const char *name,const char *parent_name, +void __iomem *reg,spinlock_t *lock) +{ + return clk_register_divider_table(NULL, "mc", "emc_mux", 0, reg,Should take name and
parent_namefrom the passed args?With that change:
Reviewed-by Tomeu Vizoso <[email protected]>
Good catch.
Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141030/89e7ccae/attachment.sig>