Re: [PATCH v3 03/11] clk: davinci - common clk utilities to init clk driver
On 11/5/2012 8:50 PM, Murali Karicheri wrote:
On 11/03/2012 08:35 AM, Sekhar Nori wrote:
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
This is the common clk driver initialization functions for DaVinci
SoCs and other SoCs that uses similar hardware architecture.
clock.h also defines struct types for clock definitions in a SoC
and clock data type for configuring clk-mux. The initialization
functions are used by clock initialization code in a specific
platform/SoC.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/clk/davinci/clock.c | 112
+++
drivers/clk/davinci/clock.h | 80 +++
2 files changed, 192 insertions(+)
create mode 100644 drivers/clk/davinci/clock.c
create mode 100644 drivers/clk/davinci/clock.h
diff --git a/drivers/clk/davinci/clock.c b/drivers/clk/davinci/clock.c
new file mode 100644
index 000..ad02149
--- /dev/null
+++ b/drivers/clk/davinci/clock.c
@@ -0,0 +1,112 @@
+/*
+ * clock.c - davinci clock initialization functions for various clocks
+ *
+ * Copyright (C) 2006-2012 Texas Instruments.
+ * Copyright (C) 2008-2009 Deep Root Systems, LLC
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/init.h
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/slab.h
+
+#include clk-pll.h
+#include clk-psc.h
+#include clk-div.h
+#include clock.h
+
+static DEFINE_SPINLOCK(_lock);
+
+#ifdefCONFIG_CLK_DAVINCI_PLL
+struct clk *davinci_pll_clk(const char *name, const char *parent,
+u32 phys_pllm, u32 phys_prediv, u32 phys_postdiv,
+struct clk_pll_data *pll_data)
+{
+struct clk *clkp = NULL;
+
+pll_data-reg_pllm = ioremap(phys_pllm, 4);
+if (WARN_ON(!pll_data-reg_pllm))
+return clkp;
I would prefer ERR_PTR(-ENOMEM) here. Same comment applies to other
instances elsewhere in the patch.
diff --git a/drivers/clk/davinci/clock.h b/drivers/clk/davinci/clock.h
new file mode 100644
index 000..73204b8
--- /dev/null
+++ b/drivers/clk/davinci/clock.h
@@ -0,0 +1,80 @@
+/*
+ * TI DaVinci Clock definitions - Contains Macros and Types used for
+ * defining various clocks on a DaVinci SoC
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DAVINCI_CLOCK_H
+#define __DAVINCI_CLOCK_H
+
+#include linux/types.h
+
+/* general flags: */
+#define ALWAYS_ENABLEDBIT(0)
This is not used in this patch. Can you add the define along with its
usage so it is immediately clear why you need it?
This is used on the next patch as this adds a bunch of utilities or
types for the platform specific clock code. Do you want to combine this
patch with 05/11? It will become a bigger patch then? Is that fine.
IMO, this is a logical group that can be a standalone patch than
combining with 05/11.
It is more important to divide patches in logical functional blocks
rather than split it based on files. Reading this patch, I have no idea
what that define is for.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 05/11] clk: davinci - add dm644x clock initialization
On 11/6/2012 4:53 AM, Murali Karicheri wrote:
On 11/03/2012 09:30 AM, Sekhar Nori wrote:
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
This patch adds dm644x clock initialization code that consists of
clocks data for various clocks and clock register callouts to
various clock drivers. It uses following clk drivers for this
1. clk-fixed-rate - for ref clock
2. clk-mux - for mux at the input and output of main pll
3. davinci specific clk-pll for main pll clock
4. davinci specific clk-div for pll divider clock
5. clk-fixed-factor for fixed factor clock such as auxclk
6. davinci specific clk-psc for psc clocks
This patch also moves all of the PLL and PSC register definitions
from clock.h and psc.h under davinci to the clk/davinci folder so
that various soc specific clock initialization code can share these
definitions.
Except this patch does not move the defines, it creates a copy of them
(which is bad since you quickly lose track of which is the correct
copy). Is this done to avoid including mach/ header files here? It will
actually be better to include the mach/ files here as a temporary
solution and then remove the include mach/ files once all the SoCs have
been converted over.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/clk/davinci/dm644x-clock.c | 304
drivers/clk/davinci/pll.h | 83 ++
drivers/clk/davinci/psc.h | 215 +
3 files changed, 602 insertions(+)
create mode 100644 drivers/clk/davinci/dm644x-clock.c
create mode 100644 drivers/clk/davinci/pll.h
create mode 100644 drivers/clk/davinci/psc.h
+/* all clocks available in DM644x SoCs */
+enum dm644x_clk {
+clkin, oscin, ref_clk_mux, pll1, pll1_plldiv_clk_mux, auxclk,
+clk_pll1_sysclk1, clk_pll1_sysclk2, clk_pll1_sysclk3,
clk_pll1_sysclk4,
+clk_pll1_sysclk5, clk_pll1_sysclkbp, pll2, pll2_plldiv_clk_mux,
+clk_pll2_sysclk1, clk_pll2_sysclk2, clk_pll2_sysclkbp, dsp, arm,
vicp,
+vpss_master, vpss_slave, uart0, uart1, uart2, emac, i2c, ide, asp,
+mmcsd, spi, gpio, usb, vlynq, aemif, pwm0, pwm1, pwm2, timer0,
timer1,
+timer2, clk_max
+};
+
+static struct davinci_clk *psc_clocks[] = {
+clk_dsp, clk_arm, clk_vicp, clk_vpss_master, clk_vpss_slave,
+clk_uart0, clk_uart1, clk_uart2, clk_emac, clk_i2c, clk_ide,
+clk_asp0, clk_mmcsd, clk_spi, clk_gpio, clk_usb, clk_vlynq,
+clk_aemif, clk_pwm0, clk_pwm1, clk_pwm2, clk_timer0,
clk_timer1,
+clk_timer2
+};
You rely on perfect order between this array and dm644x_clk enum above.
Can you initialize this array using the enum as the index so that it is
clear. Current method is too error prone.
Are you expecting something like this?
static struct davinci_clk *psc_clocks[] = {
[dsp - dsp]= clk_dsp,
[arm - dsp]= clk_arm,
[vicp - dsp]= clk_vicp,
[vpss_maste - dsp]= clk_vpss_master,
[vpss_slave - dsp]= clk_vpss_slave,
[uart0 - dsp]= clk_uart0,
[uart1 - dsp]= clk_uart1,
Well, sort of! But the '- dsp' is really ugly. You can either define the
array for the full list of clocks (like 'clks') or move the psc clocks
to the beginning of the enum (less preferable to me).
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 06/11] clk: davinci - add build infrastructure for DaVinci clock drivers
On 11/5/2012 9:47 PM, Murali Karicheri wrote: On 11/04/2012 08:34 AM, Sekhar Nori wrote: On 10/25/2012 9:41 PM, Murali Karicheri wrote: This updates clk Makefile and Kconfig to integrate the DaVinci specific clock drivers. Also add new Kconfig and Makefile for these drivers. Signed-off-by: Murali Karicheri m-kariche...@ti.com As mentioned before, this should be folded into previous patches which actually add the particular functionality. Yes. Agreed., --- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |1 + drivers/clk/davinci/Kconfig | 44 ++ drivers/clk/davinci/Makefile |5 + 4 files changed, 52 insertions(+) create mode 100644 drivers/clk/davinci/Kconfig create mode 100644 drivers/clk/davinci/Makefile diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 7f0b5ca..1ad2ab0 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -33,6 +33,8 @@ config COMMON_CLK_DEBUG clk_flags, clk_prepare_count, clk_enable_count clk_notifier_count. +source drivers/clk/davinci/Kconfig + config COMMON_CLK_WM831X tristate Clock driver for WM831x/2x PMICs depends on MFD_WM831X diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 5869ea3..b127b6f 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/ obj-$(CONFIG_PLAT_SPEAR)+= spear/ obj-$(CONFIG_ARCH_U300)+= clk-u300.o obj-$(CONFIG_ARCH_INTEGRATOR)+= versatile/ +obj-$(CONFIG_DAVINCI_CLKS)+= davinci/ # Chip specific obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o diff --git a/drivers/clk/davinci/Kconfig b/drivers/clk/davinci/Kconfig new file mode 100644 index 000..e53bbc3 --- /dev/null +++ b/drivers/clk/davinci/Kconfig @@ -0,0 +1,44 @@ +menu TI DaVinci Clock drivers +depends on COMMON_CLK + +config CLK_DAVINCI_PSC +bool TI DaVici PSC clock driver +default n +---help--- + Selects clock driver for DaVinci PSC clocks. This clock + hardware is found on TI DaVinci SoCs and other SoCs that + uses this hardware IP. This hardware has a local power + sleep control module that gate the clock to the IP. + +config CLK_DAVINCI_PLL +bool DaVici main PLL clock +---help--- + Selects clock driver for DaVinci main PLL. This clock + hardware is found on TI DaVinci SoCs. This typically has + a multiplier, a pre divider and post driver. Some of the + SoCs has the the dividers fixed, and others have it + programmable + +config CLK_DAVINCI_PLLDIV +bool DaVici PLL divider clock +---help--- + Selects clock driver for DaVinci PLL divider. This clock + hardware is found on TI DaVinci SoCs. This typically has + a divider and an enable bit to bypass or enable the + divider. + +config DAVINCI_CLKS +bool TI DaVinci common clocks +default n +select CLK_DAVINCI_PSC +select CLK_DAVINCI_PLLDIV +---help--- + Selects common clock drivers for DaVinci. These clocks + are re-used across many TI SoCs that are based on DaVinci and + Keystone (c6x) families. This config option is used to select + the common clock driver for DaVinci based SoCs. SoCs specific + Kconfig option needs to select the driver for clocks specific + to the SoC. + +endmenu I wonder if all these configurations are really required. For complete clock functionality you anyway require all this functionality so I wonder why anyone would not select any of these. And to differentiate between architecture changes, conditional build based on architecture can be used: I know this is a grey area I need to improve and had a discussion with Mike sometime back. Are you also suggesting including davinci folder unconditionally under drivers/clk/Makefile? I think it will work. And then in clk/davinci/Makefile we can include on a per architecture basis. But I am not sure if calling the folder as davinci make sense and these drivers are used on non DaVinci architectures as well. I had initially named it as ti to include all ti drivers. But Mike had commented that current directory structure use platform/arch name instead of vendor name. Also OMAP is going to move the clk drivers to this folder soon. So for now, davinci may be used to house all of the non OMAP drivers. Later we can re-visit this as needed (wouldn't be that hard to do this within the clk driver folder later). We can keep the davinci folder name and unconditionally include it in clk/Makefile. clk/Makefile add obj-y += davinci/ I am not sure about this unconditional inclusion. Are you sure the following will create problems when DaVinci and keystone are enabled together? obj-$(CONFIG_ARCH_DAVINCI) += davinci/ obj-$(CONFIG_ARCH_KEYSTONE) += davinci/ clk/davinci/Makefile
Re: [PATCH v3 07/11] ARM: davinci - restructure header files for common clock migration
On 11/6/2012 12:41 AM, Murali Karicheri wrote: On 11/04/2012 09:05 AM, Sekhar Nori wrote: On 10/25/2012 9:41 PM, Murali Karicheri wrote: pll.h is added to migrate some of the PLL controller defines for sleep.S. psc.h is modified to keep only PSC modules definitions needed by sleep.S after migrating to common clock. The definitions under ifdef CONFIG_COMMON_CLK will be removed in a subsequent patch. davinci_watchdog_reset prototype is moved to time.h as clock.h is being obsoleted. sleep.S and pm.c is modified to include the new header file replacements. Signed-off-by: Murali Karicheri m-kariche...@ti.com --- arch/arm/mach-davinci/devices.c |2 ++ arch/arm/mach-davinci/include/mach/pll.h | 46 + arch/arm/mach-davinci/include/mach/psc.h |4 +++ arch/arm/mach-davinci/include/mach/time.h |4 ++- arch/arm/mach-davinci/pm.c|4 +++ arch/arm/mach-davinci/sleep.S |4 +++ 6 files changed, 63 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-davinci/include/mach/pll.h With this patch a _third_ copy of PLL definitions is created in kernel sources. The existing PLL definitions in clock.h inside mach-davinci should be moved to mach/pll.h and the pll.h you introduced inside drivers/clk in 5/11 should be removed (this patch should appear before 5/11). The biggest disadvantage of this approach is inclusion of mach/ includes in drivers/clk. But duplicating code is definitely not the fix for this. Anyway, mach/ includes are not uncommon in drivers/clk (they are all probably suffering from the same issue). Sekhar, I have replied to patch 5/11 that also refers to this. The main reason we are not able to do this cleanly is the code in sleep.c and pm.c. That is something related to Power management. Could you take a look and see if you can do some clean up on this code? I believe It is more than just moving the header files. I am not sure what more is required than moving header files? Can you elaborate? Murali $ grep -rl include mach/ drivers/clk/* drivers/clk/clk-u300.c drivers/clk/mmp/clk-pxa168.c drivers/clk/mmp/clk-mmp2.c drivers/clk/mmp/clk-pxa910.c drivers/clk/mxs/clk-imx23.c drivers/clk/mxs/clk-imx28.c drivers/clk/spear/spear6xx_clock.c drivers/clk/spear/spear3xx_clock.c drivers/clk/spear/spear1340_clock.c drivers/clk/spear/spear1310_clock.c drivers/clk/ux500/clk-prcc.c drivers/clk/versatile/clk-integrator.c drivers/clk/versatile/clk-realview.c pll.h can probably be moved to include/linux/clk/ to avoid this. Would like to hear from Mike on this before going ahead. Anyway, instead of just commenting, I though I will be more useful and went ahead and made some of the changes I have been talking about. I fixed the multiple PLL definitions issue, the build infrastructure issue and the commit ordering too. I pushed the patches I fixed to devel-common-clk branch of my git tree. It is build tested using davinci_all_defconfig but its not runtime tested. Can you start from here and provide me incremental changes on top of this? That way we can collaborate to finish this faster. Thanks for offering some help. Yes I can provide you incremental patch. But then could you also help me to squash/rebase and send patches to the list for review? No, no. I want you to own the submissions. Towards this, if it is easier for you to build upon my work in your own tree, by all means, go ahead and do it. Just share the branch/tree details so I can take a look and contribute as well. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 05/11] clk: davinci - add dm644x clock initialization
On 11/5/2012 9:12 PM, Murali Karicheri wrote: On 11/03/2012 09:30 AM, Sekhar Nori wrote: On 10/25/2012 9:41 PM, Murali Karicheri wrote: This patch adds dm644x clock initialization code that consists of clocks data for various clocks and clock register callouts to various clock drivers. It uses following clk drivers for this 1. clk-fixed-rate - for ref clock 2. clk-mux - for mux at the input and output of main pll 3. davinci specific clk-pll for main pll clock 4. davinci specific clk-div for pll divider clock 5. clk-fixed-factor for fixed factor clock such as auxclk 6. davinci specific clk-psc for psc clocks This patch also moves all of the PLL and PSC register definitions from clock.h and psc.h under davinci to the clk/davinci folder so that various soc specific clock initialization code can share these definitions. Except this patch does not move the defines, it creates a copy of them (which is bad since you quickly lose track of which is the correct copy). Is this done to avoid including mach/ header files here? Yes. It will actually be better to include the mach/ files here as a temporary solution and then remove the include mach/ files once all the SoCs have been converted over. I was thinking we are not allowed to include mach/* header files in driver files. But most of the clk drivers such clk-imx28, spear6xx_clock.c. versatile/clk-integrator.c etc are including mach/ headers. One issue is that the definitions in pll.h are re-usable across other machines falling under c6x and Keystone (new device we are working on) as well. Where do we keep includes that can be re-used across different architectures? include/linux/platform_data/ ? In this case, it is not really platform data or even an interface for drivers to use, so I prefer include/linux/clk/davinci-pll.h I see clk-integrator.h, clk-nomadik.h and clk-u300 sitting there. So I suggest moving any header files that defines utility functions, register definitions across different architectures to include/linux/platform_data. Candidate files would be clock.h, pll.h, clk-psc.h, clk-pll.h and clk-div.h. This way these can be used across It is not clear to me why you would move these files outside of drivers/clk/davinci. They are not used by any other code outside of this directory. the above machines that use the above architectures. Can we do this in my next version? This way we don't have to make another move later. All these CLK IPs are re-used across multiple architectures and make perfect sense to me to move to the above folder. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL 1/6] DaVinci fixes for v3.8
On Tue, Oct 30, 2012 at 11:41:36PM +0530, Sekhar Nori wrote: The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git tags/davinci-for-v3.8/fixes Pulled, thanks. -Olof ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 03/11] clk: davinci - common clk utilities to init clk driver
On 11/06/2012 04:31 AM, Sekhar Nori wrote:
On 11/5/2012 8:50 PM, Murali Karicheri wrote:
On 11/03/2012 08:35 AM, Sekhar Nori wrote:
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
This is the common clk driver initialization functions for DaVinci
SoCs and other SoCs that uses similar hardware architecture.
clock.h also defines struct types for clock definitions in a SoC
and clock data type for configuring clk-mux. The initialization
functions are used by clock initialization code in a specific
platform/SoC.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/clk/davinci/clock.c | 112
+++
drivers/clk/davinci/clock.h | 80 +++
2 files changed, 192 insertions(+)
create mode 100644 drivers/clk/davinci/clock.c
create mode 100644 drivers/clk/davinci/clock.h
diff --git a/drivers/clk/davinci/clock.c b/drivers/clk/davinci/clock.c
new file mode 100644
index 000..ad02149
--- /dev/null
+++ b/drivers/clk/davinci/clock.c
@@ -0,0 +1,112 @@
+/*
+ * clock.c - davinci clock initialization functions for various clocks
+ *
+ * Copyright (C) 2006-2012 Texas Instruments.
+ * Copyright (C) 2008-2009 Deep Root Systems, LLC
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/init.h
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/slab.h
+
+#include clk-pll.h
+#include clk-psc.h
+#include clk-div.h
+#include clock.h
+
+static DEFINE_SPINLOCK(_lock);
+
+#ifdefCONFIG_CLK_DAVINCI_PLL
+struct clk *davinci_pll_clk(const char *name, const char *parent,
+u32 phys_pllm, u32 phys_prediv, u32 phys_postdiv,
+struct clk_pll_data *pll_data)
+{
+struct clk *clkp = NULL;
+
+pll_data-reg_pllm = ioremap(phys_pllm, 4);
+if (WARN_ON(!pll_data-reg_pllm))
+return clkp;
I would prefer ERR_PTR(-ENOMEM) here. Same comment applies to other
instances elsewhere in the patch.
diff --git a/drivers/clk/davinci/clock.h b/drivers/clk/davinci/clock.h
new file mode 100644
index 000..73204b8
--- /dev/null
+++ b/drivers/clk/davinci/clock.h
@@ -0,0 +1,80 @@
+/*
+ * TI DaVinci Clock definitions - Contains Macros and Types used for
+ * defining various clocks on a DaVinci SoC
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DAVINCI_CLOCK_H
+#define __DAVINCI_CLOCK_H
+
+#include linux/types.h
+
+/* general flags: */
+#define ALWAYS_ENABLEDBIT(0)
This is not used in this patch. Can you add the define along with its
usage so it is immediately clear why you need it?
This is used on the next patch as this adds a bunch of utilities or
types for the platform specific clock code. Do you want to combine this
patch with 05/11? It will become a bigger patch then? Is that fine.
IMO, this is a logical group that can be a standalone patch than
combining with 05/11.
It is more important to divide patches in logical functional blocks
rather than split it based on files. Reading this patch, I have no idea
what that define is for.
Thanks,
Sekhar
Will combine with 05/11 since utilities are used by the clock init code
in dm644x.
Murali
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC PATCH 1/2] memory: davinci - add aemif controller platform driver
On 11/06/2012 02:44 AM, Sekhar Nori wrote: On 11/6/2012 2:38 AM, Murali Karicheri wrote: On 11/04/2012 08:52 AM, Rob Herring wrote: OMAP GPMC Could you send me a link please? https://www.google.com/search?q=RFC+OMAP+GPMC+DT+bindings The patches series is sent by Daniel Mack. v3 was the last version sent. Thanks, Sekhar One of the question I have on this is what is the final location of the GPMC driver? The patch referred here is located inside the mach-omap2. This will not work for us as AEMIF driver is used across multiple architecture. range is also used in AEMIF bindings to refer the CS memory map. So there is no issue here. I will fix the documentation. Or Am I missing something? Murali ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL 2/6] DaVinci cleanup for v3.8
On Tue, Oct 30, 2012 at 11:41:37PM +0530, Sekhar Nori wrote: The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git tags/davinci-for-v3.8/cleanup Pulled, but would you mind moving your tree to a better git hosting service? It takes _forever_ to do a pull from gitorious. Do you have a signed PGP key so you can get a kernel.org account, per chance? -Olof for you to fetch changes up to baad1b33f4d86d223d665fcefa79b4acc832a269: ARM: davinci: board-dm646x-evm.c: Remove unecessary semicolon (2012-10-26 13:59:01 +0530) These changes make minor clean-ups to remove some unused MUSB defines and an unnecessary semicolon. Constantine Shulyupin (1): ARM: davinci: usb: remove CONFIG_USB_MUSB_HOST etc Peter Senna Tschudin (1): ARM: davinci: board-dm646x-evm.c: Remove unecessary semicolon arch/arm/mach-davinci/board-dm646x-evm.c |2 +- arch/arm/mach-davinci/usb.c |6 -- 2 files changed, 1 insertion(+), 7 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC PATCH 1/2] memory: davinci - add aemif controller platform driver
On 11/04/2012 08:52 AM, Rob Herring wrote:
On 11/02/2012 11:21 AM, Murali Karicheri wrote:
This is a platform driver for asynchronous external memory interface
available on TI SoCs. This driver was previously located inside the
mach-davinci folder. As this DaVinci IP is re-used across multiple
family of devices such as c6x, keystone etc, the driver is moved to drivers.
The driver configures async bus parameters associated with a particular
chip select. For DaVinci controller driver and driver for other async
devices such as NOR flash, ASRAM etc, the bus confuguration is
done by this driver at init time. A set of APIs (set/get) provided to
update the values based on specific driver usage.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/arm/davinci/aemif.txt | 62 +++
drivers/memory/Kconfig | 10 +
drivers/memory/Makefile|1 +
drivers/memory/davinci-aemif.c | 397
include/linux/platform_data/davinci-aemif.h| 47 +++
5 files changed, 517 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt
create mode 100644 drivers/memory/davinci-aemif.c
create mode 100644 include/linux/platform_data/davinci-aemif.h
diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt
b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
new file mode 100644
index 000..7d70d42
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
@@ -0,0 +1,62 @@
+* Texas Instruments Davinci AEMIF bus interface
+
+This file provides information for the davinci-emif chip select
+bindings.
+
+This is a sub device node inside the davinci-emif device node
+to describe a async bus for a specific chip select. For NAND,
+CFI flash device bindings described inside an aemif node,
+etc, a cs sub node is defined to associate the bus parameter
+bindings used by the device.
+
+Required properties:=
+- compatible: ti,davinci-cs;
+- #address-cells = 1;
+- #size-cells = 1;
+- cs - cs used by the device (NAND, CFI flash etc. values in the range: 2-5
No. Use ranges. See the discussion on OMAP GPMC.
Rob
Rob,
I am using ranges to specify the memory map for the cs. I will re-post
the patch with full bindings documentation.
cs nodes are optional nodes to specify the timings. Embedding it inside
nand as done in gpmc will work for NAND. But this is a generic bus that
can interface a number of async devices such as NOR flash, Async SRAM,
FPGA etc. For NOR flash interface (cfi flash drivers) it is not clear to
me how the author of GPMC driver is proposing to specify the bindings
for configuring the GPMC bus. For AEMIF driver, this bindings can be
specified as an cs subnode of aemif that is configured by the aemif
driver for the specific chip select that NOR flash or any other async
device is connected to similar to NAND. I will re-post an updated patch
set for continuing the discussion. I will post this question to the GPMC
driver author as well.
Murali
+
+Optional properties:-
+- asize - asynchronous data bus width (0 - 8bit, 1 - 16 bit)
+ All of the params below in nanoseconds
+
+- ta - Minimum turn around time
+- rhold - read hold width
+- rstobe - read strobe width
+- rsetup - read setup width
+- whold - write hold width
+- wstrobe - write strobe width
+- wsetup - write setup width
+- ss - enable/disable select strobe (0 - disable, 1 - enable)
+- ew - enable/disable extended wait cycles (0 - disable, 1 - enable)
+
+Example for davinci nand chip select
+
+aemif@6000 {
+
+ compatible = ti,davinci-aemif;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ nand_cs:cs2@7000 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ cs = 2;
+ asize = 1;
+ ta = 24;
+ rhold = 48;
+ rstrobe = 390;
+ rsetup = 96;
+ whold = 48;
+ wstrobe = 390;
+ wsetup = 96;
+ };
+
+ nand@2,0 {
+
+
+
+ };
+};
+
+
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 067f311..2636a95 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -40,4 +40,14 @@ config TEGRA30_MC
analysis, especially for IOMMU/SMMU(System Memory Management
Unit) module.
+config TI_DAVINCI_AEMIF
+ bool Texas Instruments DaVinci AEMIF driver
+ help
+ This driver is for the AEMIF module available in Texas Instruments
+ SoCs. AEMIF stands for Asynchronous External Memory Interface and
+ is intended to provide a glue-less interface to a variety of
+ asynchronuous memory devices like ASRAM, NOR and NAND memory. A total
+ of 256M bytes of any of these memories can be accessed at a given
+ time via four chip selects with 64M byte
Re: [RFC PATCH 1/2] memory: davinci - add aemif controller platform driver
On 11/02/2012 03:05 PM, Stephen Warren wrote:
On 11/02/2012 10:21 AM, Murali Karicheri wrote:
This is a platform driver for asynchronous external memory interface
available on TI SoCs. This driver was previously located inside the
mach-davinci folder. As this DaVinci IP is re-used across multiple
family of devices such as c6x, keystone etc, the driver is moved to drivers.
The driver configures async bus parameters associated with a particular
chip select. For DaVinci controller driver and driver for other async
devices such as NOR flash, ASRAM etc, the bus confuguration is
done by this driver at init time. A set of APIs (set/get) provided to
update the values based on specific driver usage.
+++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
If the HW/binding is generic, I'd assume the documentation would be
place somewhere more like
Documentation/devicetree/bindings/memory/davinci-aemif.txt?
Thanks for your comments.
I think this is a generic driver that should be re-usable across
multiple architectures such as arm, c6x and other new SoCs from TI that
uses the AEMIF IP. AEMIF IP can be configured on a per chip select
basis. There will be nand controller, NOR flash and other async devices
on this bus. So cs bindings for each of this device will be a sub node
under thie aemif device. AEMIF driver iterate over the cs sub nodes and
configure the bus.
Let me post the complete bindings in the next revision so that this will
be more clear and we can discuss it based on that. I will also move the
nand documentation to a generic place and refer the bindings inside the
aemif documentation. I will address some of the comments below in my
next revision of the patch, but some of the comments discussion will
have to be deferred to version v2 of the patch.
Murali
@@ -0,0 +1,62 @@
+* Texas Instruments Davinci AEMIF bus interface
+
+This file provides information for the davinci-emif chip select
+bindings.
Shouldn't the binding be for an IP block (the AEMIF bus controller I
assume), rather than for a particular chip-select generated by the
controller?
AEMIF has multiple functions such as it functions as a NAND controller,
it provides interfaces to async devices. The bus is configured using the
CS sub node inside the aemif device node (compatible ti, davinci-emif).
+This is a sub device node inside the davinci-emif device node
+to describe a async bus for a specific chip select. For NAND,
+CFI flash device bindings described inside an aemif node,
+etc, a cs sub node is defined to associate the bus parameter
+bindings used by the device.
Oh, this file only documents part of the controller's node? It seems
unusual to do that; the documentation for an entire node would usually
be in a single file, which seems to be
Documentation/devicetree/bindings/arm/davinci/nand.txt right now. Is
this cs sub-node really something that gets re-used across multiple
different memory controller IPs?
If so, I guess this file should be called something more like
davinci-aemif-cs.txt than davinci-aemif.txt. I'd suggest moving
arm/davinci/nand.txt into a common location too (and renaming it to
davici-nand.txt to better represent the compatible value it documents).
+Required properties:=
+- compatible: ti,davinci-cs;
+- #address-cells = 1;
+- #size-cells = 1;
+- cs - cs used by the device (NAND, CFI flash etc. values in the range: 2-5
+
+Optional properties:-
+- asize - asynchronous data bus width (0 - 8bit, 1 - 16 bit)
+ All of the params below in nanoseconds
+
+- ta - Minimum turn around time
+- rhold - read hold width
+- rstobe - read strobe width
+- rsetup - read setup width
+- whold - write hold width
+- wstrobe - write strobe width
+- wsetup - write setup width
+- ss - enable/disable select strobe (0 - disable, 1 - enable)
+- ew - enable/disable extended wait cycles (0 - disable, 1 - enable)
I assume all of those are pretty custom to this binding, and not
something you'd expect to re-use across multiple vendors' bindings? If
so, shouldn't they have a ti, vendor prefix?
+Example for davinci nand chip select
+
+aemif@6000 {
+
+ compatible = ti,davinci-aemif;
You need a reg property here.
+ #address-cells = 2;
+ #size-cells = 1;
+
+ nand_cs:cs2@7000 {
+ compatible = ti,davinci-cs;
You need a reg property here. The unit address @7000 in the node
name only has one address cell, whereas the parent node sets
#address-cells = 2.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
Hi Prabhakar, Thanks for your consideration, please see my response below... -Original Message- From: Prabhakar Lad [mailto:prabhakar.cse...@gmail.com] Sent: Monday, November 05, 2012 9:02 PM To: Tivy, Robert; Ben Gardiner Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Marek Szyprowski Subject: Re: [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP Hi Robert, On Thu, Nov 1, 2012 at 7:22 PM, Ben Gardiner bengardi...@nanometrics.ca wrote: Hi Rob, On Thu, Oct 25, 2012 at 4:35 PM, Robert Tivy rt...@ti.com wrote: [...] @@ -660,6 +667,99 @@ int __init da850_register_mmcsd1(struct davinci_mmc_config *config) } #endif +static struct platform_device *da8xx_dsp; + +#ifdef CONFIG_CMA + +/* + * The following address range was chosen because the XDC Platform for + * OMAP-L138 DSP has this range as its default code/data placement. + */ +#define DA8XX_RPROC_CMA_BASE (0xc300) [...] +/* + * The following address range was chosen because the XDC Platform for + * OMAP-L138 DSP has this range as its default code/data placement. + * + * System integrators must ensure that Linux does not own this range. + */ +#define DA_CONTIG_BASE (0xc300) +#define DA_CONTIG_SIZE (0x0200) Is there a specific requirement for the dsp dev to have the buffers from this '0xc300' address range only ? If yes then dma_declare_contiguous() is must to ensure contiguous memory so the above macros cant be avoided. If there isn't a requirement of a specific region for dsp device you can use a global CMA instead, so as to ensure you have contiguous memory. The requirement is that the contiguous buffer matches the address range to which the DSP image was linked, including uninitialized sections that don't actually get loaded. I was thinking of making those #defines into Kconfig variables, so that kernel sources don't need to be touched by the end customer. Another alternative is to make them be kernel command line variables, which would prevent the need to even rebuild the kernel. What are your thoughts regarding those alternatives? The above address range was decided upon because it matches the RTSC platform's defined area for OMAP-L138 [1] (although, the customer can end up redefining that range). One of the reasons that range was chosen for the RTSC platform is that it exists on boards with smaller DDR sizes. In other words, for a board with 256MB of DDR, if a range at the top of the DDR address space was chosen then that DSP image wouldn't work with a board with only 128MB. Regards, - Rob [1] http://rtsc.eclipse.org/cdoc-tip/index.html#ti/platforms/evmOMAPL138/Platform.html#per-instance_config_parameters, however, we extended the range an additional 16MB beyond the RTSC platform's range. Regards, --Prabhakar Lad I am concerned with the rigidity of the memory hole as its definition is currently proposed. As you noted DA_CONTIG_BASE and DA_CONTIG_SIZE must describe a range that is not used by Linux. Ideally this hole would not be in the middle of the usuable memory but instead at the top. For L138 boards with larger DDR packages this would mean carrying a patch to this file. I think the same also applies to DA8XX_RPROC_CMA_BASE but I have no hands-on experience yet with CMA. Is there any other means by which the hole's location and size can be specified which does not require patching this file? I imagine KConfig would work, but is this an acceptable use of KConfig? Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[RESEND:PATCH] mtd: davinci-nand: add support for partition binding nodes
Enhance the driver to support partition subnodes inside the nand
device bindings to describe partitions on the nand device.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/arm/davinci/nand.txt |8
drivers/mtd/nand/davinci_nand.c| 13 ++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt
b/Documentation/devicetree/bindings/arm/davinci/nand.txt
index e37241f..4746452 100644
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
@@ -23,6 +23,9 @@ Recommended properties :
- ti,davinci-nand-buswidth: buswidth 8 or 16
- ti,davinci-nand-use-bbt: use flash based bad block table support.
+nand device bindings may contain additional sub-nodes describing
+partitions of the address space. See partition.txt for more detail.
+
Example (enbw_cmc board):
aemif@6000 {
compatible = ti,davinci-aemif;
@@ -47,5 +50,10 @@ aemif@6000 {
ti,davinci-ecc-mode = hw;
ti,davinci-ecc-bits = 4;
ti,davinci-nand-use-bbt;
+
+ partition@18 {
+ label = ubifs;
+ reg = 0x18 0x7e8;
+ };
};
};
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index df1ab7d..321b053 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -821,9 +821,16 @@ syndrome_done:
if (ret 0)
goto err_scan;
- ret = mtd_device_parse_register(info-mtd, NULL, NULL, pdata-parts,
- pdata-nr_parts);
-
+ if (pdata-parts)
+ ret = mtd_device_parse_register(info-mtd, NULL, NULL,
+ pdata-parts, pdata-nr_parts);
+ else {
+ struct mtd_part_parser_data ppdata;
+
+ ppdata.of_node = pdev-dev.of_node;
+ ret = mtd_device_parse_register(info-mtd, NULL, ppdata,
+ NULL, 0);
+ }
if (ret 0)
goto err_scan;
--
1.7.9.5
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[RFC v2 PATCH 1/2] memory: davinci - add aemif controller platform driver
This is a platform driver for asynchronous external memory interface
available on TI SoCs. This driver was previously located inside the
mach-davinci folder. As this DaVinci IP is re-used across multiple
family of devices such as c6x, keystone etc, the driver is moved to drivers.
The driver configures async bus parameters associated with a particular
chip select. For DaVinci NAND controller driver and driver for other async
devices such as NOR flash, ASRAM etc, the bus confuguration is
done by this driver at probe. A set of APIs (set/get) are provided to
update the values based on specific driver usage.
This supports configuration of the bus either through platform_data or
through DT bindings.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/memory/davinci-aemif.txt | 103 +
drivers/memory/Kconfig | 10 +
drivers/memory/Makefile|1 +
drivers/memory/davinci-aemif.c | 479
include/linux/platform_data/davinci-aemif.h| 47 ++
5 files changed, 640 insertions(+)
create mode 100644 Documentation/devicetree/bindings/memory/davinci-aemif.txt
create mode 100644 drivers/memory/davinci-aemif.c
create mode 100644 include/linux/platform_data/davinci-aemif.h
diff --git a/Documentation/devicetree/bindings/memory/davinci-aemif.txt
b/Documentation/devicetree/bindings/memory/davinci-aemif.txt
new file mode 100644
index 000..a79b3ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory/davinci-aemif.txt
@@ -0,0 +1,103 @@
+* Texas Instruments Davinci AEMIF bus interface
+
+This file provides information for the davinci-emif device and
+async bus bindings.
+
+Required properties:=
+- compatible: ti,davinci-aemif;
+- #address-cells : Should be either two or three. The first cell is the
+ chipselect number, and the remaining cells are the
+ offset into the chipselect.
+- #size-cells : Either one or two, depending on how large each chipselect
+can be.
+- reg : contains offset/length value for AEMIF control registers space
+- ranges : Each range corresponds to a single chipselect, and cover
+ the entire access window as configured.
+
+Child device nodes describe the devices connected to IFC such as NOR (e.g.
+cfi-flash) and NAND (ti,davinci-nand, see Documentation/devicetree/bindings/
+mtd/davinci-nand.txt). There might be board specific devices like FPGAs.
+
+In addition, optional child sub nodes contains bindings for the async bus
+interface for a given chip select.
+
+Optional cs node properties:-
+- compatible: ti,davinci-cs
+
+ All of the params below in nanoseconds and are optional
+
+- ti,davinci-cs-asize - asynchronous data bus width (0 - 8bit, 1 - 16 bit)
+- ti,davinci-cs-ta - Minimum turn around time
+- ti,davinci-cs-rhold - read hold width
+- ti,davinci-cs-rstobe - read strobe width
+- ti,davinci-cs-rsetup - read setup width
+- ti,davinci-cs-whold - write hold width
+- ti,davinci-cs-wstrobe - write strobe width
+- ti,davinci-cs-wsetup - write setup width
+- ti,davinci-cs-ss - enable/disable select strobe (0 - disable, 1 - enable)
+- ti,davinci-cs-ew - enable/disable extended wait cycles (0 - disable, 1 -
enable)
+
+if any of the above parameters are absent, hardware register default or that
+set by a boot loader are used.
+
+Example for aemif, davinci nand and nor flash chip select shown below.
+
+aemif@6000 {
+ compatible = ti,davinci-aemif;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0x6800 0x8;
+ ranges = 2 0 0x6000 0x0200
+ 3 0 0x6200 0x0200
+ 4 0 0x6400 0x0200
+ 5 0 0x6600 0x0200
+ 6 0 0x6800 0x0200;
+
+ nand_cs:cs2@6000 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* all timings in nanoseconds */
+ ti,davinci-cs-ta = 0;
+ ti,davinci-cs-rhold = 7;
+ ti,davinci-cs-rstrobe = 42;
+ ti,davinci-cs-rsetup = 14;
+ ti,davinci-cs-whold = 7;
+ ti,davinci-cs-wstrobe = 42;
+ ti,davinci-cs-wsetup = 14;
+ };
+
+ nor_cs:cs3@6200 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* all timings in nanoseconds */
+ ti,davinci-cs-ta = 0;
+ ti,davinci-cs-rhold = 7;
+ ti,davinci-cs-rstrobe = 42;
+ ti,davinci-cs-rsetup = 14;
+ ti,davinci-cs-whold = 7;
+ ti,davinci-cs-wstrobe = 42;
+ ti,davinci-cs-wsetup = 14;
+ ti,davinci-cs-asize = 1;
+ };
+
+ nand@3,0 {
+ compatible = ti,davinci-nand;
+ reg = 3 0x0 0x807ff
+
[RFC v2 PATCH 2/2] mtd: davinci - remove DaVinci architecture depedency
DaVinci NAND driver is a controller driver based on the AEMIF hardware
IP found on TI SoCs. It is also used on SoCs that are not DaVinci based. This
patch removes the driver dependency on DaVinci architecture so that it
can be used on other architectures such as c6x, keystone etc.
Also migrate the driver to use the new AEMIF platform driver API and
moving Documentation to Documentation/devicetree/bindings/mtd/davinci-nand.txt
as this is expected to be used outside of arm/davinci.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/arm/davinci/nand.txt | 59 -
.../devicetree/bindings/mtd/davinci-nand.txt | 59 +
drivers/mtd/nand/Kconfig |6 +-
drivers/mtd/nand/davinci_nand.c| 40 -
include/linux/platform_data/davinci-nand.h | 87
5 files changed, 166 insertions(+), 85 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt
create mode 100644 include/linux/platform_data/davinci-nand.h
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt
b/Documentation/devicetree/bindings/arm/davinci/nand.txt
deleted file mode 100644
index 4746452..000
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-* Texas Instruments Davinci NAND
-
-This file provides information, what the device node for the
-davinci nand interface contain.
-
-Required properties:
-- compatible: ti,davinci-nand;
-- reg : contain 2 offset/length values:
-- offset and length for the access window
-- offset and length for accessing the aemif control registers
-- ti,davinci-chipselect: Indicates on the davinci_nand driver which
- chipselect is used for accessing the nand.
-
-Recommended properties :
-- ti,davinci-mask-ale: mask for ale
-- ti,davinci-mask-cle: mask for cle
-- ti,davinci-mask-chipsel: mask for chipselect
-- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
- - none
- - soft
- - hw
-- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
-- ti,davinci-nand-buswidth: buswidth 8 or 16
-- ti,davinci-nand-use-bbt: use flash based bad block table support.
-
-nand device bindings may contain additional sub-nodes describing
-partitions of the address space. See partition.txt for more detail.
-
-Example (enbw_cmc board):
-aemif@6000 {
- compatible = ti,davinci-aemif;
- #address-cells = 2;
- #size-cells = 1;
- reg = 0x6800 0x8;
- ranges = 2 0 0x6000 0x0200
- 3 0 0x6200 0x0200
- 4 0 0x6400 0x0200
- 5 0 0x6600 0x0200
- 6 0 0x6800 0x0200;
- nand@3,0 {
- compatible = ti,davinci-nand;
- reg = 3 0x0 0x807ff
- 6 0x0 0x8000;
- #address-cells = 1;
- #size-cells = 1;
- ti,davinci-chipselect = 1;
- ti,davinci-mask-ale = 0;
- ti,davinci-mask-cle = 0;
- ti,davinci-mask-chipsel = 0;
- ti,davinci-ecc-mode = hw;
- ti,davinci-ecc-bits = 4;
- ti,davinci-nand-use-bbt;
-
- partition@18 {
- label = ubifs;
- reg = 0x18 0x7e8;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
new file mode 100644
index 000..4746452
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -0,0 +1,59 @@
+* Texas Instruments Davinci NAND
+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: ti,davinci-nand;
+- reg : contain 2 offset/length values:
+- offset and length for the access window
+- offset and length for accessing the aemif control registers
+- ti,davinci-chipselect: Indicates on the davinci_nand driver which
+ chipselect is used for accessing the nand.
+
+Recommended properties :
+- ti,davinci-mask-ale: mask for ale
+- ti,davinci-mask-cle: mask for cle
+- ti,davinci-mask-chipsel: mask for chipselect
+- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
+ - none
+ - soft
+ - hw
+- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
+- ti,davinci-nand-buswidth: buswidth 8 or 16
+- ti,davinci-nand-use-bbt: use flash based bad block table support.
+
+nand device bindings may contain additional sub-nodes describing
+partitions of the address space. See partition.txt for more detail.
+
+Example (enbw_cmc board):
+aemif@6000 {
+ compatible =
[RFC v2 PATCH 0/2]Move AEMIF driver out of DaVinci machine to memory subsystem
Some of the comments addressed in this patch vs initial version are 1. moved the bindings documentation to bindings/memory/davinci-aemif.txt 2. moved the bindings documentation for nand to mtd/ folder 3. renamed cs subnode fields with a ti,davinci-cs prefix. 4. davinci-aemif.txt now has full picture of aemif async bus bindings and that of all of the sub device nodes and sub nodes 5. Made cs node optional so that on platforms that sets the cs parameters in bootloader can ignore the cs binding nodes so that hardware values set by boot loader is used. The DaVinci AEMIF (asynchronous external memory interface) is used on other TI SoCs that are not DaVinci based. So the AEMIF driver is to be moved outside mach-davinci to the drivers folder so that it can be re-used on other TI SoCs. Also migrate the DaVinci NAND driver to use the new aemif API. Some of these code has been borrowed from intial patch from Heiko Schocher h...@denx.de. So I have added his name in the Copyright for davinci-aemif.c This is an RFC to get the intial response so that all the platforms can be migrated to use this driver. Murali Karicheri (2): memory: davinci - add aemif controller platform driver mtd: davinci - remove DaVinci architecture depedency .../devicetree/bindings/arm/davinci/nand.txt | 59 --- .../devicetree/bindings/memory/davinci-aemif.txt | 103 + .../devicetree/bindings/mtd/davinci-nand.txt | 59 +++ drivers/memory/Kconfig | 10 + drivers/memory/Makefile|1 + drivers/memory/davinci-aemif.c | 479 drivers/mtd/nand/Kconfig |6 +- drivers/mtd/nand/davinci_nand.c| 40 +- include/linux/platform_data/davinci-aemif.h| 47 ++ include/linux/platform_data/davinci-nand.h | 87 10 files changed, 806 insertions(+), 85 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt create mode 100644 Documentation/devicetree/bindings/memory/davinci-aemif.txt create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt create mode 100644 drivers/memory/davinci-aemif.c create mode 100644 include/linux/platform_data/davinci-aemif.h create mode 100644 include/linux/platform_data/davinci-nand.h -- 1.7.9.5 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v2 PATCH 1/2] memory: davinci - add aemif controller platform driver
On Tuesday 06 November 2012 03:47 PM, Murali Karicheri wrote:
This is a platform driver for asynchronous external memory interface
available on TI SoCs. This driver was previously located inside the
mach-davinci folder. As this DaVinci IP is re-used across multiple
family of devices such as c6x, keystone etc, the driver is moved to drivers.
The driver configures async bus parameters associated with a particular
chip select. For DaVinci NAND controller driver and driver for other async
devices such as NOR flash, ASRAM etc, the bus confuguration is
done by this driver at probe. A set of APIs (set/get) are provided to
update the values based on specific driver usage.
This supports configuration of the bus either through platform_data or
through DT bindings.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/memory/davinci-aemif.txt | 103 +
drivers/memory/Kconfig | 10 +
drivers/memory/Makefile|1 +
drivers/memory/davinci-aemif.c | 479
include/linux/platform_data/davinci-aemif.h| 47 ++
5 files changed, 640 insertions(+)
create mode 100644 Documentation/devicetree/bindings/memory/davinci-aemif.txt
create mode 100644 drivers/memory/davinci-aemif.c
create mode 100644 include/linux/platform_data/davinci-aemif.h
Please split the DT and drivers/memory/* changes in two seperate
patches.
diff --git a/Documentation/devicetree/bindings/memory/davinci-aemif.txt
b/Documentation/devicetree/bindings/memory/davinci-aemif.txt
new file mode 100644
index 000..a79b3ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory/davinci-aemif.txt
@@ -0,0 +1,103 @@
+* Texas Instruments Davinci AEMIF bus interface
+
+This file provides information for the davinci-emif device and
+async bus bindings.
+
+Required properties:=
+- compatible: ti,davinci-aemif;
+- #address-cells : Should be either two or three. The first cell is the
+ chipselect number, and the remaining cells are the
+ offset into the chipselect.
+- #size-cells : Either one or two, depending on how large each chipselect
+can be.
+- reg : contains offset/length value for AEMIF control registers space
+- ranges : Each range corresponds to a single chipselect, and cover
+ the entire access window as configured.
+
+Child device nodes describe the devices connected to IFC such as NOR (e.g.
+cfi-flash) and NAND (ti,davinci-nand, see Documentation/devicetree/bindings/
+mtd/davinci-nand.txt). There might be board specific devices like FPGAs.
+
+In addition, optional child sub nodes contains bindings for the async bus
+interface for a given chip select.
+
+Optional cs node properties:-
+- compatible: ti,davinci-cs
+
+ All of the params below in nanoseconds and are optional
+
+- ti,davinci-cs-asize - asynchronous data bus width (0 - 8bit, 1 - 16 bit)
+- ti,davinci-cs-ta - Minimum turn around time
+- ti,davinci-cs-rhold - read hold width
+- ti,davinci-cs-rstobe - read strobe width
+- ti,davinci-cs-rsetup - read setup width
+- ti,davinci-cs-whold - write hold width
+- ti,davinci-cs-wstrobe - write strobe width
+- ti,davinci-cs-wsetup - write setup width
+- ti,davinci-cs-ss - enable/disable select strobe (0 - disable, 1 - enable)
+- ti,davinci-cs-ew - enable/disable extended wait cycles (0 - disable, 1 -
enable)
+
+if any of the above parameters are absent, hardware register default or that
+set by a boot loader are used.
+
+Example for aemif, davinci nand and nor flash chip select shown below.
+
+aemif@6000 {
+ compatible = ti,davinci-aemif;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0x6800 0x8;
+ ranges = 2 0 0x6000 0x0200
+ 3 0 0x6200 0x0200
+ 4 0 0x6400 0x0200
+ 5 0 0x6600 0x0200
+ 6 0 0x6800 0x0200;
+
+ nand_cs:cs2@6000 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* all timings in nanoseconds */
+ ti,davinci-cs-ta = 0;
+ ti,davinci-cs-rhold = 7;
+ ti,davinci-cs-rstrobe = 42;
+ ti,davinci-cs-rsetup = 14;
+ ti,davinci-cs-whold = 7;
+ ti,davinci-cs-wstrobe = 42;
+ ti,davinci-cs-wsetup = 14;
+ };
+
+ nor_cs:cs3@6200 {
+ compatible = ti,davinci-cs;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* all timings in nanoseconds */
+ ti,davinci-cs-ta = 0;
+ ti,davinci-cs-rhold = 7;
+ ti,davinci-cs-rstrobe = 42;
+ ti,davinci-cs-rsetup = 14;
+ ti,davinci-cs-whold = 7;
+ ti,davinci-cs-wstrobe = 42;
+ ti,davinci-cs-wsetup = 14;
+
Re: [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
Hi Robert, On Wed, Nov 7, 2012 at 1:03 AM, Tivy, Robert rt...@ti.com wrote: Hi Prabhakar, Thanks for your consideration, please see my response below... -Original Message- From: Prabhakar Lad [mailto:prabhakar.cse...@gmail.com] Sent: Monday, November 05, 2012 9:02 PM To: Tivy, Robert; Ben Gardiner Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Marek Szyprowski Subject: Re: [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP Hi Robert, On Thu, Nov 1, 2012 at 7:22 PM, Ben Gardiner bengardi...@nanometrics.ca wrote: Hi Rob, On Thu, Oct 25, 2012 at 4:35 PM, Robert Tivy rt...@ti.com wrote: [...] @@ -660,6 +667,99 @@ int __init da850_register_mmcsd1(struct davinci_mmc_config *config) } #endif +static struct platform_device *da8xx_dsp; + +#ifdef CONFIG_CMA + +/* + * The following address range was chosen because the XDC Platform for + * OMAP-L138 DSP has this range as its default code/data placement. + */ +#define DA8XX_RPROC_CMA_BASE (0xc300) [...] +/* + * The following address range was chosen because the XDC Platform for + * OMAP-L138 DSP has this range as its default code/data placement. + * + * System integrators must ensure that Linux does not own this range. + */ +#define DA_CONTIG_BASE (0xc300) +#define DA_CONTIG_SIZE (0x0200) Is there a specific requirement for the dsp dev to have the buffers from this '0xc300' address range only ? If yes then dma_declare_contiguous() is must to ensure contiguous memory so the above macros cant be avoided. If there isn't a requirement of a specific region for dsp device you can use a global CMA instead, so as to ensure you have contiguous memory. The requirement is that the contiguous buffer matches the address range to which the DSP image was linked, including uninitialized sections that don't actually get loaded. I was thinking of making those #defines into Kconfig variables, so that kernel sources don't need to be touched by the end customer. Another alternative is to make them be kernel command line variables, which would prevent the need to even rebuild the kernel. What are your thoughts regarding those alternatives? In either cases you still need a value which defaults, if the range was not specified in command line or Kconfig value wasn’t set. In this case you still need a macro with default value. I would prefer passing the range as part of command line as it would avoid rebuilding. Regards, --Prabhakar Lad The above address range was decided upon because it matches the RTSC platform's defined area for OMAP-L138 [1] (although, the customer can end up redefining that range). One of the reasons that range was chosen for the RTSC platform is that it exists on boards with smaller DDR sizes. In other words, for a board with 256MB of DDR, if a range at the top of the DDR address space was chosen then that DSP image wouldn't work with a board with only 128MB. Regards, - Rob [1] http://rtsc.eclipse.org/cdoc-tip/index.html#ti/platforms/evmOMAPL138/Platform.html#per-instance_config_parameters, however, we extended the range an additional 16MB beyond the RTSC platform's range. Regards, --Prabhakar Lad I am concerned with the rigidity of the memory hole as its definition is currently proposed. As you noted DA_CONTIG_BASE and DA_CONTIG_SIZE must describe a range that is not used by Linux. Ideally this hole would not be in the middle of the usuable memory but instead at the top. For L138 boards with larger DDR packages this would mean carrying a patch to this file. I think the same also applies to DA8XX_RPROC_CMA_BASE but I have no hands-on experience yet with CMA. Is there any other means by which the hole's location and size can be specified which does not require patching this file? I imagine KConfig would work, but is this an acceptable use of KConfig? Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
