Re: [PATCH] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
On 04/03/2014 04:49 PM, Nishanth Menon wrote: On 04/03/2014 05:52 AM, Peter Ujfalusi wrote: [...] .../devicetree/bindings/clock/clk-palmas.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h Only complaint i have is based on : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 Oh, I see. I'll wait for comments and resend as a series. Probably it is going to be better if I rename the documentation file as well to bindings/clock/ti,palmas-clk.txt I think having two separate document for the two clock is overkill. you may want to split the new binding off to a separate patch. Otherwise, personally, I think it is an good evolution, thanks for doing it. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] ARM: OMAP2+: AM437x: L2 cache support
This patch series adds L2 cache support for AM437x and does some clean-ups for existing OMAP4 support along the way. Tested on OMAP4 Panda and AM437x EPOS EVMs. It is based on RMK's 75 patch series titled l2c series. Sekhar Nori (3): ARM: OMAP2+: L2 cache: allow different aux ctrl settings ARM: OMAP2+: L2 cache: get rid of init call ARM: OMAP2+: AM43x: L2 cache support arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/common.h |2 ++ arch/arm/mach-omap2/io.c |2 ++ arch/arm/mach-omap2/omap4-common.c | 45 +++- 4 files changed, 29 insertions(+), 21 deletions(-) -- 1.7.10.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: OMAP2+: L2 cache: get rid of init call
Get rid of init call to initialize L2 cache.
Instead use the init_early machine hook. This
helps in using the initialization routine across
SoCs without the need of ugly cpu_is_*() checks.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap4-common.c | 10 +-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index d88aff7..c64d5f5 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -91,6 +91,7 @@ extern void omap3_sync32k_timer_init(void);
extern void omap3_secure_sync32k_timer_init(void);
extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
+int omap4_l2_cache_init(void);
extern void omap5_realtime_timer_init(void);
void omap2420_init_early(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index f14f9ac..81bc89c 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -640,6 +640,7 @@ void __init omap4430_init_early(void)
omap44xx_clockdomains_init();
omap44xx_hwmod_init();
omap_hwmod_init_postsetup();
+ omap4_l2_cache_init();
omap_clk_soc_init = omap4xxx_dt_clk_init;
}
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 0a2e4f0..f8b8dac 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -198,13 +198,6 @@ static void omap4_l2c310_write_sec(unsigned long val,
unsigned reg)
static int __init omap_l2_cache_init(u32 aux_ctrl, u32 aux_flags)
{
- /*
-* To avoid code running on other OMAPs in
-* multi-omap builds
-*/
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
/* Static mapping, never released */
l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
if (WARN_ON(!l2cache_base))
@@ -219,7 +212,7 @@ static int __init omap_l2_cache_init(u32 aux_ctrl, u32
aux_flags)
return 0;
}
-static int __init omap4_l2_cache_init(void)
+int __init omap4_l2_cache_init(void)
{
/* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
u32 aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
@@ -231,7 +224,6 @@ static int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
-omap_early_initcall(omap4_l2_cache_init);
#endif
void __iomem *omap4_get_sar_ram_base(void)
--
1.7.10.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: OMAP2+: L2 cache: allow different aux ctrl settings
Different SoCs likely need different L2 cache aux ctrl
settings based on use cases and optimizations required.
For example, if CMA is always used for coherent memory allocations,
there is no need for sharable attribute override bit to be set.
Pass aux control settings as argument to the L2 cache initialization
function to allow for this.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/omap4-common.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 06c6a18..0a2e4f0 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -196,10 +196,8 @@ static void omap4_l2c310_write_sec(unsigned long val,
unsigned reg)
omap_smc1(smc_op, val);
}
-static int __init omap_l2_cache_init(void)
+static int __init omap_l2_cache_init(u32 aux_ctrl, u32 aux_flags)
{
- u32 aux_ctrl;
-
/*
* To avoid code running on other OMAPs in
* multi-omap builds
@@ -212,23 +210,28 @@ static int __init omap_l2_cache_init(void)
if (WARN_ON(!l2cache_base))
return -ENOMEM;
- /* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
- aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
- L310_AUX_CTRL_NS_LOCKDOWN |
- L310_AUX_CTRL_NS_INT_CTRL |
- L2C_AUX_CTRL_SHARED_OVERRIDE |
- L310_AUX_CTRL_DATA_PREFETCH |
- L310_AUX_CTRL_INSTR_PREFETCH;
-
outer_cache.write_sec = omap4_l2c310_write_sec;
if (of_have_populated_dt())
- l2x0_of_init(aux_ctrl, 0xc19f);
+ l2x0_of_init(aux_ctrl, aux_flags);
else
- l2x0_init(l2cache_base, aux_ctrl, 0xc19f);
+ l2x0_init(l2cache_base, aux_ctrl, aux_flags);
return 0;
}
-omap_early_initcall(omap_l2_cache_init);
+
+static int __init omap4_l2_cache_init(void)
+{
+ /* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
+ u32 aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
+ L310_AUX_CTRL_NS_LOCKDOWN |
+ L310_AUX_CTRL_NS_INT_CTRL |
+ L2C_AUX_CTRL_SHARED_OVERRIDE |
+ L310_AUX_CTRL_DATA_PREFETCH |
+ L310_AUX_CTRL_INSTR_PREFETCH;
+
+ return omap_l2_cache_init(aux_ctrl, 0xc19f);
+}
+omap_early_initcall(omap4_l2_cache_init);
#endif
void __iomem *omap4_get_sar_ram_base(void)
--
1.7.10.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
Add support for L2 cache controller (PL310) on
AM437x SoC.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap4-common.c |8
4 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1124155..1fd34d2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -65,6 +65,7 @@ config SOC_AM43XX
select ARCH_HAS_OPP
select ARM_GIC
select MACH_OMAP_GENERIC
+ select MIGHT_HAVE_CACHE_L2X0
config SOC_DRA7XX
bool TI DRA7XX
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index c64d5f5..fc59b49 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -93,6 +93,7 @@ extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
int omap4_l2_cache_init(void);
extern void omap5_realtime_timer_init(void);
+int am43xx_l2_cache_init(void);
void omap2420_init_early(void);
void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 81bc89c..131c207 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -609,6 +609,7 @@ void __init am43xx_init_early(void)
am43xx_clockdomains_init();
am43xx_hwmod_init();
omap_hwmod_init_postsetup();
+ am43xx_l2_cache_init();
omap_clk_soc_init = am43xx_dt_clk_init;
}
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
+
+int __init am43xx_l2_cache_init(void)
+{
+ u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
+ L310_AUX_CTRL_INSTR_PREFETCH;
+
+ return omap_l2_cache_init(aux_ctrl, 0xcfff);
+}
#endif
void __iomem *omap4_get_sar_ram_base(void)
--
1.7.10.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
+
+int __init am43xx_l2_cache_init(void)
+{
+ u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
+L310_AUX_CTRL_INSTR_PREFETCH;
It would be good to documenting the difference between this and OMAP4,
and why you have chosen different values.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. These two levels exist in the form of the DMA-API and the IOMMU-API. In fact, the IOMMU-API was created to provide a way to drivers to specifiy the IOVA-PHYS mappings on its own. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed ? The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA-API anymore then). Joerg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hello, I'm sorry for a delay, I've got back from my holidays and I'm still busy trying to get thought all the emails. On 2014-03-17 23:44, Laurent Pinchart wrote: Hi Suman and Sakari, On Monday 17 March 2014 14:58:24 Suman Anna wrote: On 03/16/2014 04:54 PM, Sakari Ailus wrote: On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Hi Suman, (CC'ing Joerg Roedel and Marek Szyprowski for the core IOMMU discussion) On Thursday 13 March 2014 21:33:37 Suman Anna wrote: On 03/07/2014 06:46 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 5/5, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I'd like to take this as an opportunity to discuss OMAP IOMMU integration with the ARM DMA mapping implementation. The idea is to hide the IOMMU completely behind the DMA mapping API, making it completely transparent to drivers. Thanks for starting the discussion. A drivers will only need to allocate memory with dma_alloc_*, and behind the scene the ARM DMA mapping implementation will find out that the device is behind an IOMMU and will map the buffers through the IOMMU, returning an I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to the IOMMU core should be necessary anymore. To use the IOMMU the ARM DMA implementation requires a VA mapping to be created with a call to arm_iommu_create_mapping() and to then be attached to the device with arm_iommu_attach_device(). This is currently not performed by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP driver for now. I believe this to still be an improvement compared to the current situation, as it allows getting rid of custom memory allocation code in the OMAP3 ISP driver and custom I/O VA space management in omap-iovmm. However, that code should ideally be removed from the driver. The question is, where should it be moved to ? One possible solution would be to add the code to the OMAP IOMMU driver. However, this would require all OMAP IOMMU users to be converted to the ARM DMA API. I assume there would be issues that I don't foresee though. Yeah, I think this will pose some problems for the other main user of IOMMUs - the remoteproc devices (DSP, Dual-Cortex M3/M4 processors in OMAP4 and beyond). A remoteproc device also needs to map memory at specific addresses for its code and data sections, and not rely on a I/O VA address being given to it. The firmware sections are already linked at specific addresses, and so remoteproc needs to allocate memory, load the firmware and map into appropriate device addresses. We are doing this currently usage a combination of CMA memory to get contiguous memory (there are some restrictions for certain sections) and iommu_map/unmap API to program the MMU with these pages. This usage is different from what is expected from exchanging buffers, which can be allocated from a predefined mapping range. Even that one is tricky if we need to support different cache properties/attributes as the cache configuration is in general local to these processors. Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. Actually, I think there is one another use case, even with remoteprocs which is to runtime map buffers. This is different from the firmware management. The memory for buffers could have been allocated from other subsystems, but remoteproc would need just to manage the VA space and map. Right, although you might not always have to manage the VA space in that case. Anyway, if your driver needs to manage the VA space for the firmware, it should be able to manage the VA space for the buffers using the same IOMMU API. I've already seen some use cases which require to give a client device limited access to DMA mapping IOMMU related structures. If we agree on API, I see no problems to add such calls to dma-mapping. However in the most common case I would like to hide the presence of IOMMU from the client device at all. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed? Can this be done through iommu_domain_set_attr? But that means the
