| Message ID | 0680EC522D0CC943BC586913CF3768C003790C62AD@dbde02.ent.ti.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | Tony Lindgren |
| Headers | show |
"S, Venkatraman" <svenkatr@ti.com> writes: > The hardware feature is available on OMAP4430 and also expected to be > in OMAP3630. Hence the feature flag will control the inclusion of the additional functions. > > Addition of omap kconfig option CONFIG_OMAP_DMA_DESCRIPTOR_LOAD. Short version: (a.k.a caveman version) - Compile-time option: bad. - Run-time option: good. Long version: Without looking at the docs, I would hope that the some revision reg or similar would report whether this feature is available or not. The user configuring the kernel should not have to know whether his SoC has this feature or not. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin, On Thu, Aug 13, 2009 at 5:09 AM, Kevin Hilman<khilman@deeprootsystems.com> wrote: > "S, Venkatraman" <svenkatr@ti.com> writes: > >> The hardware feature is available on OMAP4430 and also expected to be >> in OMAP3630. Hence the feature flag will control the inclusion of the additional functions. >> >> Addition of omap kconfig option CONFIG_OMAP_DMA_DESCRIPTOR_LOAD. > > Short version: (a.k.a caveman version) > > - Compile-time option: bad. > - Run-time option: good. > > Long version: > > Without looking at the docs, I would hope that the some revision reg > or similar would report whether this feature is available or not. Â The > user configuring the kernel should not have to know whether his SoC > has this feature or not. > > Kevin > -- Thanks for your comments. Yes, the DMA_CAPS_0 register contains flags for linked list capability and it can be checked. Obviously, I intended this (compile time flag) for code space saving for all older platforms. Not only in this file, but all client drivers those that would eventually start using this capability. I am preparing a patch with the runtime check (+ other changes you'd suggested), but I am curious to know what's the general threshold at which compile time flag (and it's associated code savings) is considered a valid trade off? Thanks and regards, Venkat. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 23e43ea..bea9dcb 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -182,6 +182,7 @@ CONFIG_ARCH_OMAP4=y # # OMAP Feature Selections # +CONFIG_OMAP_DMA_DESCRIPTOR_LOAD=y # CONFIG_OMAP_RESET_CLOCKS is not set # CONFIG_OMAP_MUX is not set # CONFIG_OMAP_MCBSP is not set diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index efe85d0..885b8b8 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -53,6 +53,13 @@ config OMAP_DEBUG_POWERDOMAIN for every powerdomain register write. However, the extra detail costs some memory. +config OMAP_DMA_DESCRIPTOR_LOAD + bool "sDMA descriptor loading feature" + depends on ARCH_OMAP4 + help + Say Y here if you want to include the DMA descriptor + autoloading feature. Supported only in OMAP4 + config OMAP_DEBUG_CLOCKDOMAIN bool "Emit debug messages from clockdomain layer" depends on ARCH_OMAP2 || ARCH_OMAP3
The hardware feature is available on OMAP4430 and also expected to be in OMAP3630. Hence the feature flag will control the inclusion of the additional functions. Addition of omap kconfig option CONFIG_OMAP_DMA_DESCRIPTOR_LOAD. Signed-off-by: Venkatraman S <svenkatr@ti.com> --- arch/arm/configs/omap_4430sdp_defconfig | 1 + arch/arm/plat-omap/Kconfig | 7 +++++++ 2 files changed, 8 insertions(+), 0 deletions(-) ---- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html