redonkable/alistair23-linux
redonkable/alistair23-linux
1
0
Fork 0
Code Releases Activity
alistair23-linux/arch/arm/mach-davinci/da830.c

785 lines
29 KiB
C
Raw Normal View History

davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
/*
* TI DA830/OMAP L137 chip specific setup
*
* Author: Mark A. Greer <mgreer@mvista.com>
*
* 2009 (c) MontaVista Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
ARM: davinci: da830: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/da830.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 10:48:07 -06:00
#include <linux/clk-provider.h>
#include <linux/clk/davinci.h>
ARM: gpio: convert includes of mach/gpio.h and asm/gpio.h to linux/gpio.h Convert arch/arm includes of mach/gpio.h and asm/gpio.h to linux/gpio.h before we start consolidating the individual platform implementations of the gpio header files. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-26 03:53:52 -06:00
#include <linux/gpio.h>
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
#include <linux/init.h>
clk: Remove io.h from clk-provider.h Now that we've gotten rid of clk_readl() we can remove io.h from the clk-provider header and push out the io.h include to any code that isn't already including the io.h header but using things like readl/writel, etc. Found with this grep: git grep -l clk-provider.h | grep '.c$' | xargs git grep -L 'linux/io.h' | \ xargs git grep -l \ -e '\<__iowrite32_copy\>' --or \ -e '\<__ioread32_copy\>' --or \ -e '\<__iowrite64_copy\>' --or \ -e '\<ioremap_page_range\>' --or \ -e '\<ioremap_huge_init\>' --or \ -e '\<arch_ioremap_pud_supported\>' --or \ -e '\<arch_ioremap_pmd_supported\>' --or \ -e '\<devm_ioport_map\>' --or \ -e '\<devm_ioport_unmap\>' --or \ -e '\<IOMEM_ERR_PTR\>' --or \ -e '\<devm_ioremap\>' --or \ -e '\<devm_ioremap_nocache\>' --or \ -e '\<devm_ioremap_wc\>' --or \ -e '\<devm_iounmap\>' --or \ -e '\<devm_ioremap_release\>' --or \ -e '\<devm_memremap\>' --or \ -e '\<devm_memunmap\>' --or \ -e '\<__devm_memremap_pages\>' --or \ -e '\<pci_remap_cfgspace\>' --or \ -e '\<arch_has_dev_port\>' --or \ -e '\<arch_phys_wc_add\>' --or \ -e '\<arch_phys_wc_del\>' --or \ -e '\<memremap\>' --or \ -e '\<memunmap\>' --or \ -e '\<arch_io_reserve_memtype_wc\>' --or \ -e '\<arch_io_free_memtype_wc\>' --or \ -e '\<__io_aw\>' --or \ -e '\<__io_pbw\>' --or \ -e '\<__io_paw\>' --or \ -e '\<__io_pbr\>' --or \ -e '\<__io_par\>' --or \ -e '\<__raw_readb\>' --or \ -e '\<__raw_readw\>' --or \ -e '\<__raw_readl\>' --or \ -e '\<__raw_readq\>' --or \ -e '\<__raw_writeb\>' --or \ -e '\<__raw_writew\>' --or \ -e '\<__raw_writel\>' --or \ -e '\<__raw_writeq\>' --or \ -e '\<readb\>' --or \ -e '\<readw\>' --or \ -e '\<readl\>' --or \ -e '\<readq\>' --or \ -e '\<writeb\>' --or \ -e '\<writew\>' --or \ -e '\<writel\>' --or \ -e '\<writeq\>' --or \ -e '\<readb_relaxed\>' --or \ -e '\<readw_relaxed\>' --or \ -e '\<readl_relaxed\>' --or \ -e '\<readq_relaxed\>' --or \ -e '\<writeb_relaxed\>' --or \ -e '\<writew_relaxed\>' --or \ -e '\<writel_relaxed\>' --or \ -e '\<writeq_relaxed\>' --or \ -e '\<readsb\>' --or \ -e '\<readsw\>' --or \ -e '\<readsl\>' --or \ -e '\<readsq\>' --or \ -e '\<writesb\>' --or \ -e '\<writesw\>' --or \ -e '\<writesl\>' --or \ -e '\<writesq\>' --or \ -e '\<inb\>' --or \ -e '\<inw\>' --or \ -e '\<inl\>' --or \ -e '\<outb\>' --or \ -e '\<outw\>' --or \ -e '\<outl\>' --or \ -e '\<inb_p\>' --or \ -e '\<inw_p\>' --or \ -e '\<inl_p\>' --or \ -e '\<outb_p\>' --or \ -e '\<outw_p\>' --or \ -e '\<outl_p\>' --or \ -e '\<insb\>' --or \ -e '\<insw\>' --or \ -e '\<insl\>' --or \ -e '\<outsb\>' --or \ -e '\<outsw\>' --or \ -e '\<outsl\>' --or \ -e '\<insb_p\>' --or \ -e '\<insw_p\>' --or \ -e '\<insl_p\>' --or \ -e '\<outsb_p\>' --or \ -e '\<outsw_p\>' --or \ -e '\<outsl_p\>' --or \ -e '\<ioread8\>' --or \ -e '\<ioread16\>' --or \ -e '\<ioread32\>' --or \ -e '\<ioread64\>' --or \ -e '\<iowrite8\>' --or \ -e '\<iowrite16\>' --or \ -e '\<iowrite32\>' --or \ -e '\<iowrite64\>' --or \ -e '\<ioread16be\>' --or \ -e '\<ioread32be\>' --or \ -e '\<ioread64be\>' --or \ -e '\<iowrite16be\>' --or \ -e '\<iowrite32be\>' --or \ -e '\<iowrite64be\>' --or \ -e '\<ioread8_rep\>' --or \ -e '\<ioread16_rep\>' --or \ -e '\<ioread32_rep\>' --or \ -e '\<ioread64_rep\>' --or \ -e '\<iowrite8_rep\>' --or \ -e '\<iowrite16_rep\>' --or \ -e '\<iowrite32_rep\>' --or \ -e '\<iowrite64_rep\>' --or \ -e '\<__io_virt\>' --or \ -e '\<pci_iounmap\>' --or \ -e '\<virt_to_phys\>' --or \ -e '\<phys_to_virt\>' --or \ -e '\<ioremap_uc\>' --or \ -e '\<ioremap\>' --or \ -e '\<__ioremap\>' --or \ -e '\<iounmap\>' --or \ -e '\<ioremap\>' --or \ -e '\<ioremap_nocache\>' --or \ -e '\<ioremap_uc\>' --or \ -e '\<ioremap_wc\>' --or \ -e '\<ioremap_wc\>' --or \ -e '\<ioremap_wt\>' --or \ -e '\<ioport_map\>' --or \ -e '\<ioport_unmap\>' --or \ -e '\<ioport_map\>' --or \ -e '\<ioport_unmap\>' --or \ -e '\<xlate_dev_kmem_ptr\>' --or \ -e '\<xlate_dev_mem_ptr\>' --or \ -e '\<unxlate_dev_mem_ptr\>' --or \ -e '\<virt_to_bus\>' --or \ -e '\<bus_to_virt\>' --or \ -e '\<memset_io\>' --or \ -e '\<memcpy_fromio\>' --or \ -e '\<memcpy_toio\>' I also reordered a couple includes when they weren't alphabetical and removed clk.h from kona, replacing it with clk-provider.h because that driver doesn't use clk consumer APIs. Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Tero Kristo <t-kristo@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Cc: Chris Zankel <chris@zankel.net> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: John Crispin <john@phrozen.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-04-18 16:20:22 -06:00
#include <linux/io.h>
ARM: davinci: cp-intc: add the new config structures for da8xx SoCs Add the new-style config structures for da8xx SoCs. They will be used once we make the cp-intc driver stop using davinci_soc_info. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 07:52:20 -07:00
#include <linux/irqchip/irq-davinci-cp-intc.h>
ARM: davinci: da8xx: support gpio platform device DaVinci GPIO driver now uses platform device model. Convert DA8XX SoC code to use the new model. Add da8xx_register_gpio() to create platform device for da8xx platforms. Signed-off-by: KV Sujith <sujithkv@ti.com> Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> [nsekhar@ti.com: simplify commit message] Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
2013-08-17 23:18:59 -06:00
#include <linux/platform_data/gpio-davinci.h>
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
#include <asm/mach/map.h>
#include <mach/common.h>
ARM: davinci: da830: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/da830.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 10:48:07 -06:00
#include <mach/cputype.h>
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
#include <mach/da8xx.h>
ARM: davinci: da830: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the da830 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 07:17:42 -06:00
#include <clocksource/timer-davinci.h>
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
ARM: davinci: make irqs.h a local header The existence of irqs.h in mach-davinci/include/mach only makes sense without SPARSE_IRQ as it's then expected to define NR_IRQS and is included from asm/irq.h. As we now support SPARSE_IRQ, this header can be moved to mach-davinci and used as the source of HW interrupt numbers. While updating the includes in various files - also rearrange the headers by directory (linux/asm/mach). Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 07:52:03 -07:00
#include "irqs.h"
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
#include "mux.h"
/* Offsets of the 8 compare registers on the da830 */
#define DA830_CMP12_0 0x60
#define DA830_CMP12_1 0x64
#define DA830_CMP12_2 0x68
#define DA830_CMP12_3 0x6c
#define DA830_CMP12_4 0x70
#define DA830_CMP12_5 0x74
#define DA830_CMP12_6 0x78
#define DA830_CMP12_7 0x7c
#define DA830_REF_FREQ 24000000
/*
* Device specific mux setup
*
* soc description mux mode mode mux dbg
* reg offset mask mode
*/
static const struct mux_config da830_pins[] = {
#ifdef CONFIG_DAVINCI_MUX
MUX_CFG(DA830, GPIO7_14, 0, 0, 0xf, 1, false)
MUX_CFG(DA830, RTCK, 0, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_15, 0, 4, 0xf, 1, false)
MUX_CFG(DA830, EMU_0, 0, 4, 0xf, 8, false)
MUX_CFG(DA830, EMB_SDCKE, 0, 8, 0xf, 1, false)
MUX_CFG(DA830, EMB_CLK_GLUE, 0, 12, 0xf, 1, false)
MUX_CFG(DA830, EMB_CLK, 0, 12, 0xf, 2, false)
MUX_CFG(DA830, NEMB_CS_0, 0, 16, 0xf, 1, false)
MUX_CFG(DA830, NEMB_CAS, 0, 20, 0xf, 1, false)
MUX_CFG(DA830, NEMB_RAS, 0, 24, 0xf, 1, false)
MUX_CFG(DA830, NEMB_WE, 0, 28, 0xf, 1, false)
MUX_CFG(DA830, EMB_BA_1, 1, 0, 0xf, 1, false)
MUX_CFG(DA830, EMB_BA_0, 1, 4, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_0, 1, 8, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_1, 1, 12, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_2, 1, 16, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_3, 1, 20, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_4, 1, 24, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_5, 1, 28, 0xf, 1, false)
MUX_CFG(DA830, GPIO7_0, 1, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_1, 1, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_2, 1, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_3, 1, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_4, 1, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_5, 1, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_6, 1, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_7, 1, 28, 0xf, 8, false)
MUX_CFG(DA830, EMB_A_6, 2, 0, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_7, 2, 4, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_8, 2, 8, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_9, 2, 12, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_10, 2, 16, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_11, 2, 20, 0xf, 1, false)
MUX_CFG(DA830, EMB_A_12, 2, 24, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_31, 2, 28, 0xf, 1, false)
MUX_CFG(DA830, GPIO7_8, 2, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_9, 2, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_10, 2, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_11, 2, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_12, 2, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO7_13, 2, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_13, 2, 24, 0xf, 8, false)
MUX_CFG(DA830, EMB_D_30, 3, 0, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_29, 3, 4, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_28, 3, 8, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_27, 3, 12, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_26, 3, 16, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_25, 3, 20, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_24, 3, 24, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_23, 3, 28, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_22, 4, 0, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_21, 4, 4, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_20, 4, 8, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_19, 4, 12, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_18, 4, 16, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_17, 4, 20, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_16, 4, 24, 0xf, 1, false)
MUX_CFG(DA830, NEMB_WE_DQM_3, 4, 28, 0xf, 1, false)
MUX_CFG(DA830, NEMB_WE_DQM_2, 5, 0, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_0, 5, 4, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_1, 5, 8, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_2, 5, 12, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_3, 5, 16, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_4, 5, 20, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_5, 5, 24, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_6, 5, 28, 0xf, 1, false)
MUX_CFG(DA830, GPIO6_0, 5, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_1, 5, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_2, 5, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_3, 5, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_4, 5, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_5, 5, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_6, 5, 28, 0xf, 8, false)
MUX_CFG(DA830, EMB_D_7, 6, 0, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_8, 6, 4, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_9, 6, 8, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_10, 6, 12, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_11, 6, 16, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_12, 6, 20, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_13, 6, 24, 0xf, 1, false)
MUX_CFG(DA830, EMB_D_14, 6, 28, 0xf, 1, false)
MUX_CFG(DA830, GPIO6_7, 6, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_8, 6, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_9, 6, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_10, 6, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_11, 6, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_12, 6, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_13, 6, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO6_14, 6, 28, 0xf, 8, false)
MUX_CFG(DA830, EMB_D_15, 7, 0, 0xf, 1, false)
MUX_CFG(DA830, NEMB_WE_DQM_1, 7, 4, 0xf, 1, false)
MUX_CFG(DA830, NEMB_WE_DQM_0, 7, 8, 0xf, 1, false)
MUX_CFG(DA830, SPI0_SOMI_0, 7, 12, 0xf, 1, false)
MUX_CFG(DA830, SPI0_SIMO_0, 7, 16, 0xf, 1, false)
MUX_CFG(DA830, SPI0_CLK, 7, 20, 0xf, 1, false)
MUX_CFG(DA830, NSPI0_ENA, 7, 24, 0xf, 1, false)
MUX_CFG(DA830, NSPI0_SCS_0, 7, 28, 0xf, 1, false)
MUX_CFG(DA830, EQEP0I, 7, 12, 0xf, 2, false)
MUX_CFG(DA830, EQEP0S, 7, 16, 0xf, 2, false)
MUX_CFG(DA830, EQEP1I, 7, 20, 0xf, 2, false)
MUX_CFG(DA830, NUART0_CTS, 7, 24, 0xf, 2, false)
MUX_CFG(DA830, NUART0_RTS, 7, 28, 0xf, 2, false)
MUX_CFG(DA830, EQEP0A, 7, 24, 0xf, 4, false)
MUX_CFG(DA830, EQEP0B, 7, 28, 0xf, 4, false)
MUX_CFG(DA830, GPIO6_15, 7, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_14, 7, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_15, 7, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_0, 7, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_1, 7, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_2, 7, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_3, 7, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_4, 7, 28, 0xf, 8, false)
MUX_CFG(DA830, SPI1_SOMI_0, 8, 0, 0xf, 1, false)
MUX_CFG(DA830, SPI1_SIMO_0, 8, 4, 0xf, 1, false)
MUX_CFG(DA830, SPI1_CLK, 8, 8, 0xf, 1, false)
MUX_CFG(DA830, UART0_RXD, 8, 12, 0xf, 1, false)
MUX_CFG(DA830, UART0_TXD, 8, 16, 0xf, 1, false)
MUX_CFG(DA830, AXR1_10, 8, 20, 0xf, 1, false)
MUX_CFG(DA830, AXR1_11, 8, 24, 0xf, 1, false)
MUX_CFG(DA830, NSPI1_ENA, 8, 28, 0xf, 1, false)
MUX_CFG(DA830, I2C1_SCL, 8, 0, 0xf, 2, false)
MUX_CFG(DA830, I2C1_SDA, 8, 4, 0xf, 2, false)
MUX_CFG(DA830, EQEP1S, 8, 8, 0xf, 2, false)
MUX_CFG(DA830, I2C0_SDA, 8, 12, 0xf, 2, false)
MUX_CFG(DA830, I2C0_SCL, 8, 16, 0xf, 2, false)
MUX_CFG(DA830, UART2_RXD, 8, 28, 0xf, 2, false)
MUX_CFG(DA830, TM64P0_IN12, 8, 12, 0xf, 4, false)
MUX_CFG(DA830, TM64P0_OUT12, 8, 16, 0xf, 4, false)
MUX_CFG(DA830, GPIO5_5, 8, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_6, 8, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_7, 8, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_8, 8, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_9, 8, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_10, 8, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_11, 8, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO5_12, 8, 28, 0xf, 8, false)
MUX_CFG(DA830, NSPI1_SCS_0, 9, 0, 0xf, 1, false)
MUX_CFG(DA830, USB0_DRVVBUS, 9, 4, 0xf, 1, false)
MUX_CFG(DA830, AHCLKX0, 9, 8, 0xf, 1, false)
MUX_CFG(DA830, ACLKX0, 9, 12, 0xf, 1, false)
MUX_CFG(DA830, AFSX0, 9, 16, 0xf, 1, false)
MUX_CFG(DA830, AHCLKR0, 9, 20, 0xf, 1, false)
MUX_CFG(DA830, ACLKR0, 9, 24, 0xf, 1, false)
MUX_CFG(DA830, AFSR0, 9, 28, 0xf, 1, false)
MUX_CFG(DA830, UART2_TXD, 9, 0, 0xf, 2, false)
MUX_CFG(DA830, AHCLKX2, 9, 8, 0xf, 2, false)
MUX_CFG(DA830, ECAP0_APWM0, 9, 12, 0xf, 2, false)
MUX_CFG(DA830, RMII_MHZ_50_CLK, 9, 20, 0xf, 2, false)
MUX_CFG(DA830, ECAP1_APWM1, 9, 24, 0xf, 2, false)
MUX_CFG(DA830, USB_REFCLKIN, 9, 8, 0xf, 4, false)
MUX_CFG(DA830, GPIO5_13, 9, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_15, 9, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_11, 9, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_12, 9, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_13, 9, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_14, 9, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_15, 9, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_12, 9, 28, 0xf, 8, false)
MUX_CFG(DA830, AMUTE0, 10, 0, 0xf, 1, false)
MUX_CFG(DA830, AXR0_0, 10, 4, 0xf, 1, false)
MUX_CFG(DA830, AXR0_1, 10, 8, 0xf, 1, false)
MUX_CFG(DA830, AXR0_2, 10, 12, 0xf, 1, false)
MUX_CFG(DA830, AXR0_3, 10, 16, 0xf, 1, false)
MUX_CFG(DA830, AXR0_4, 10, 20, 0xf, 1, false)
MUX_CFG(DA830, AXR0_5, 10, 24, 0xf, 1, false)
MUX_CFG(DA830, AXR0_6, 10, 28, 0xf, 1, false)
MUX_CFG(DA830, RMII_TXD_0, 10, 4, 0xf, 2, false)
MUX_CFG(DA830, RMII_TXD_1, 10, 8, 0xf, 2, false)
MUX_CFG(DA830, RMII_TXEN, 10, 12, 0xf, 2, false)
MUX_CFG(DA830, RMII_CRS_DV, 10, 16, 0xf, 2, false)
MUX_CFG(DA830, RMII_RXD_0, 10, 20, 0xf, 2, false)
MUX_CFG(DA830, RMII_RXD_1, 10, 24, 0xf, 2, false)
MUX_CFG(DA830, RMII_RXER, 10, 28, 0xf, 2, false)
MUX_CFG(DA830, AFSR2, 10, 4, 0xf, 4, false)
MUX_CFG(DA830, ACLKX2, 10, 8, 0xf, 4, false)
MUX_CFG(DA830, AXR2_3, 10, 12, 0xf, 4, false)
MUX_CFG(DA830, AXR2_2, 10, 16, 0xf, 4, false)
MUX_CFG(DA830, AXR2_1, 10, 20, 0xf, 4, false)
MUX_CFG(DA830, AFSX2, 10, 24, 0xf, 4, false)
MUX_CFG(DA830, ACLKR2, 10, 28, 0xf, 4, false)
MUX_CFG(DA830, NRESETOUT, 10, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_0, 10, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_1, 10, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_2, 10, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_3, 10, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_4, 10, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_5, 10, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_6, 10, 28, 0xf, 8, false)
MUX_CFG(DA830, AXR0_7, 11, 0, 0xf, 1, false)
MUX_CFG(DA830, AXR0_8, 11, 4, 0xf, 1, false)
MUX_CFG(DA830, UART1_RXD, 11, 8, 0xf, 1, false)
MUX_CFG(DA830, UART1_TXD, 11, 12, 0xf, 1, false)
MUX_CFG(DA830, AXR0_11, 11, 16, 0xf, 1, false)
MUX_CFG(DA830, AHCLKX1, 11, 20, 0xf, 1, false)
MUX_CFG(DA830, ACLKX1, 11, 24, 0xf, 1, false)
MUX_CFG(DA830, AFSX1, 11, 28, 0xf, 1, false)
MUX_CFG(DA830, MDIO_CLK, 11, 0, 0xf, 2, false)
MUX_CFG(DA830, MDIO_D, 11, 4, 0xf, 2, false)
MUX_CFG(DA830, AXR0_9, 11, 8, 0xf, 2, false)
MUX_CFG(DA830, AXR0_10, 11, 12, 0xf, 2, false)
MUX_CFG(DA830, EPWM0B, 11, 20, 0xf, 2, false)
MUX_CFG(DA830, EPWM0A, 11, 24, 0xf, 2, false)
MUX_CFG(DA830, EPWMSYNCI, 11, 28, 0xf, 2, false)
MUX_CFG(DA830, AXR2_0, 11, 16, 0xf, 4, false)
MUX_CFG(DA830, EPWMSYNC0, 11, 28, 0xf, 4, false)
MUX_CFG(DA830, GPIO3_7, 11, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_8, 11, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_9, 11, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_10, 11, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_11, 11, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_14, 11, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO3_15, 11, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_10, 11, 28, 0xf, 8, false)
MUX_CFG(DA830, AHCLKR1, 12, 0, 0xf, 1, false)
MUX_CFG(DA830, ACLKR1, 12, 4, 0xf, 1, false)
MUX_CFG(DA830, AFSR1, 12, 8, 0xf, 1, false)
MUX_CFG(DA830, AMUTE1, 12, 12, 0xf, 1, false)
MUX_CFG(DA830, AXR1_0, 12, 16, 0xf, 1, false)
MUX_CFG(DA830, AXR1_1, 12, 20, 0xf, 1, false)
MUX_CFG(DA830, AXR1_2, 12, 24, 0xf, 1, false)
MUX_CFG(DA830, AXR1_3, 12, 28, 0xf, 1, false)
MUX_CFG(DA830, ECAP2_APWM2, 12, 4, 0xf, 2, false)
MUX_CFG(DA830, EHRPWMGLUETZ, 12, 12, 0xf, 2, false)
MUX_CFG(DA830, EQEP1A, 12, 28, 0xf, 2, false)
MUX_CFG(DA830, GPIO4_11, 12, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_12, 12, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_13, 12, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_14, 12, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_0, 12, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_1, 12, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_2, 12, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_3, 12, 28, 0xf, 8, false)
MUX_CFG(DA830, AXR1_4, 13, 0, 0xf, 1, false)
MUX_CFG(DA830, AXR1_5, 13, 4, 0xf, 1, false)
MUX_CFG(DA830, AXR1_6, 13, 8, 0xf, 1, false)
MUX_CFG(DA830, AXR1_7, 13, 12, 0xf, 1, false)
MUX_CFG(DA830, AXR1_8, 13, 16, 0xf, 1, false)
MUX_CFG(DA830, AXR1_9, 13, 20, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_0, 13, 24, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_1, 13, 28, 0xf, 1, false)
MUX_CFG(DA830, EQEP1B, 13, 0, 0xf, 2, false)
MUX_CFG(DA830, EPWM2B, 13, 4, 0xf, 2, false)
MUX_CFG(DA830, EPWM2A, 13, 8, 0xf, 2, false)
MUX_CFG(DA830, EPWM1B, 13, 12, 0xf, 2, false)
MUX_CFG(DA830, EPWM1A, 13, 16, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_DAT_0, 13, 24, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_DAT_1, 13, 28, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_0, 13, 24, 0xf, 4, false)
MUX_CFG(DA830, UHPI_HD_1, 13, 28, 0xf, 4, false)
MUX_CFG(DA830, GPIO4_4, 13, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_5, 13, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_6, 13, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_7, 13, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_8, 13, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO4_9, 13, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_0, 13, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_1, 13, 28, 0xf, 8, false)
MUX_CFG(DA830, EMA_D_2, 14, 0, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_3, 14, 4, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_4, 14, 8, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_5, 14, 12, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_6, 14, 16, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_7, 14, 20, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_8, 14, 24, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_9, 14, 28, 0xf, 1, false)
MUX_CFG(DA830, MMCSD_DAT_2, 14, 0, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_DAT_3, 14, 4, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_DAT_4, 14, 8, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_DAT_5, 14, 12, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_DAT_6, 14, 16, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_DAT_7, 14, 20, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_8, 14, 24, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_9, 14, 28, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_2, 14, 0, 0xf, 4, false)
MUX_CFG(DA830, UHPI_HD_3, 14, 4, 0xf, 4, false)
MUX_CFG(DA830, UHPI_HD_4, 14, 8, 0xf, 4, false)
MUX_CFG(DA830, UHPI_HD_5, 14, 12, 0xf, 4, false)
MUX_CFG(DA830, UHPI_HD_6, 14, 16, 0xf, 4, false)
MUX_CFG(DA830, UHPI_HD_7, 14, 20, 0xf, 4, false)
MUX_CFG(DA830, LCD_D_8, 14, 24, 0xf, 4, false)
MUX_CFG(DA830, LCD_D_9, 14, 28, 0xf, 4, false)
MUX_CFG(DA830, GPIO0_2, 14, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_3, 14, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_4, 14, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_5, 14, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_6, 14, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_7, 14, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_8, 14, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_9, 14, 28, 0xf, 8, false)
MUX_CFG(DA830, EMA_D_10, 15, 0, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_11, 15, 4, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_12, 15, 8, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_13, 15, 12, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_14, 15, 16, 0xf, 1, false)
MUX_CFG(DA830, EMA_D_15, 15, 20, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_0, 15, 24, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_1, 15, 28, 0xf, 1, false)
MUX_CFG(DA830, UHPI_HD_10, 15, 0, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_11, 15, 4, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_12, 15, 8, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_13, 15, 12, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_14, 15, 16, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HD_15, 15, 20, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_7, 15, 24, 0xf, 2, false)
MUX_CFG(DA830, MMCSD_CLK, 15, 28, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_10, 15, 0, 0xf, 4, false)
MUX_CFG(DA830, LCD_D_11, 15, 4, 0xf, 4, false)
MUX_CFG(DA830, LCD_D_12, 15, 8, 0xf, 4, false)
MUX_CFG(DA830, LCD_D_13, 15, 12, 0xf, 4, false)
MUX_CFG(DA830, LCD_D_14, 15, 16, 0xf, 4, false)
MUX_CFG(DA830, LCD_D_15, 15, 20, 0xf, 4, false)
MUX_CFG(DA830, UHPI_HCNTL0, 15, 28, 0xf, 4, false)
MUX_CFG(DA830, GPIO0_10, 15, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_11, 15, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_12, 15, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_13, 15, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_14, 15, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO0_15, 15, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_0, 15, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_1, 15, 28, 0xf, 8, false)
MUX_CFG(DA830, EMA_A_2, 16, 0, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_3, 16, 4, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_4, 16, 8, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_5, 16, 12, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_6, 16, 16, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_7, 16, 20, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_8, 16, 24, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_9, 16, 28, 0xf, 1, false)
MUX_CFG(DA830, MMCSD_CMD, 16, 0, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_6, 16, 4, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_3, 16, 8, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_2, 16, 12, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_1, 16, 16, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_0, 16, 20, 0xf, 2, false)
MUX_CFG(DA830, LCD_PCLK, 16, 24, 0xf, 2, false)
MUX_CFG(DA830, LCD_HSYNC, 16, 28, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HCNTL1, 16, 0, 0xf, 4, false)
MUX_CFG(DA830, GPIO1_2, 16, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_3, 16, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_4, 16, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_5, 16, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_6, 16, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_7, 16, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_8, 16, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_9, 16, 28, 0xf, 8, false)
MUX_CFG(DA830, EMA_A_10, 17, 0, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_11, 17, 4, 0xf, 1, false)
MUX_CFG(DA830, EMA_A_12, 17, 8, 0xf, 1, false)
MUX_CFG(DA830, EMA_BA_1, 17, 12, 0xf, 1, false)
MUX_CFG(DA830, EMA_BA_0, 17, 16, 0xf, 1, false)
MUX_CFG(DA830, EMA_CLK, 17, 20, 0xf, 1, false)
MUX_CFG(DA830, EMA_SDCKE, 17, 24, 0xf, 1, false)
MUX_CFG(DA830, NEMA_CAS, 17, 28, 0xf, 1, false)
MUX_CFG(DA830, LCD_VSYNC, 17, 0, 0xf, 2, false)
MUX_CFG(DA830, NLCD_AC_ENB_CS, 17, 4, 0xf, 2, false)
MUX_CFG(DA830, LCD_MCLK, 17, 8, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_5, 17, 12, 0xf, 2, false)
MUX_CFG(DA830, LCD_D_4, 17, 16, 0xf, 2, false)
MUX_CFG(DA830, OBSCLK, 17, 20, 0xf, 2, false)
MUX_CFG(DA830, NEMA_CS_4, 17, 28, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HHWIL, 17, 12, 0xf, 4, false)
MUX_CFG(DA830, AHCLKR2, 17, 20, 0xf, 4, false)
MUX_CFG(DA830, GPIO1_10, 17, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_11, 17, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_12, 17, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_13, 17, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_14, 17, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO1_15, 17, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_0, 17, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_1, 17, 28, 0xf, 8, false)
MUX_CFG(DA830, NEMA_RAS, 18, 0, 0xf, 1, false)
MUX_CFG(DA830, NEMA_WE, 18, 4, 0xf, 1, false)
MUX_CFG(DA830, NEMA_CS_0, 18, 8, 0xf, 1, false)
MUX_CFG(DA830, NEMA_CS_2, 18, 12, 0xf, 1, false)
MUX_CFG(DA830, NEMA_CS_3, 18, 16, 0xf, 1, false)
MUX_CFG(DA830, NEMA_OE, 18, 20, 0xf, 1, false)
MUX_CFG(DA830, NEMA_WE_DQM_1, 18, 24, 0xf, 1, false)
MUX_CFG(DA830, NEMA_WE_DQM_0, 18, 28, 0xf, 1, false)
MUX_CFG(DA830, NEMA_CS_5, 18, 0, 0xf, 2, false)
MUX_CFG(DA830, UHPI_HRNW, 18, 4, 0xf, 2, false)
MUX_CFG(DA830, NUHPI_HAS, 18, 8, 0xf, 2, false)
MUX_CFG(DA830, NUHPI_HCS, 18, 12, 0xf, 2, false)
MUX_CFG(DA830, NUHPI_HDS1, 18, 20, 0xf, 2, false)
MUX_CFG(DA830, NUHPI_HDS2, 18, 24, 0xf, 2, false)
MUX_CFG(DA830, NUHPI_HINT, 18, 28, 0xf, 2, false)
MUX_CFG(DA830, AXR0_12, 18, 4, 0xf, 4, false)
MUX_CFG(DA830, AMUTE2, 18, 16, 0xf, 4, false)
MUX_CFG(DA830, AXR0_13, 18, 20, 0xf, 4, false)
MUX_CFG(DA830, AXR0_14, 18, 24, 0xf, 4, false)
MUX_CFG(DA830, AXR0_15, 18, 28, 0xf, 4, false)
MUX_CFG(DA830, GPIO2_2, 18, 0, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_3, 18, 4, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_4, 18, 8, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_5, 18, 12, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_6, 18, 16, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_7, 18, 20, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_8, 18, 24, 0xf, 8, false)
MUX_CFG(DA830, GPIO2_9, 18, 28, 0xf, 8, false)
MUX_CFG(DA830, EMA_WAIT_0, 19, 0, 0xf, 1, false)
MUX_CFG(DA830, NUHPI_HRDY, 19, 0, 0xf, 2, false)
MUX_CFG(DA830, GPIO2_10, 19, 0, 0xf, 8, false)
#endif
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_emif25_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_EMA_D_0, DA830_EMA_D_1, DA830_EMA_D_2, DA830_EMA_D_3,
DA830_EMA_D_4, DA830_EMA_D_5, DA830_EMA_D_6, DA830_EMA_D_7,
DA830_EMA_D_8, DA830_EMA_D_9, DA830_EMA_D_10, DA830_EMA_D_11,
DA830_EMA_D_12, DA830_EMA_D_13, DA830_EMA_D_14, DA830_EMA_D_15,
DA830_EMA_A_0, DA830_EMA_A_1, DA830_EMA_A_2, DA830_EMA_A_3,
DA830_EMA_A_4, DA830_EMA_A_5, DA830_EMA_A_6, DA830_EMA_A_7,
DA830_EMA_A_8, DA830_EMA_A_9, DA830_EMA_A_10, DA830_EMA_A_11,
DA830_EMA_A_12, DA830_EMA_BA_0, DA830_EMA_BA_1, DA830_EMA_CLK,
DA830_EMA_SDCKE, DA830_NEMA_CS_4, DA830_NEMA_CS_5, DA830_NEMA_WE,
DA830_NEMA_CS_0, DA830_NEMA_CS_2, DA830_NEMA_CS_3, DA830_NEMA_OE,
DA830_NEMA_WE_DQM_1, DA830_NEMA_WE_DQM_0, DA830_EMA_WAIT_0,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_spi0_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_SPI0_SOMI_0, DA830_SPI0_SIMO_0, DA830_SPI0_CLK, DA830_NSPI0_ENA,
DA830_NSPI0_SCS_0,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_spi1_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_SPI1_SOMI_0, DA830_SPI1_SIMO_0, DA830_SPI1_CLK, DA830_NSPI1_ENA,
DA830_NSPI1_SCS_0,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_mmc_sd_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_MMCSD_DAT_0, DA830_MMCSD_DAT_1, DA830_MMCSD_DAT_2,
DA830_MMCSD_DAT_3, DA830_MMCSD_DAT_4, DA830_MMCSD_DAT_5,
DA830_MMCSD_DAT_6, DA830_MMCSD_DAT_7, DA830_MMCSD_CLK,
DA830_MMCSD_CMD,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_uart0_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_NUART0_CTS, DA830_NUART0_RTS, DA830_UART0_RXD, DA830_UART0_TXD,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_uart1_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_UART1_RXD, DA830_UART1_TXD,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_uart2_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_UART2_RXD, DA830_UART2_TXD,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_usb20_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_USB0_DRVVBUS, DA830_USB_REFCLKIN,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_usb11_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_USB_REFCLKIN,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_uhpi_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_UHPI_HD_0, DA830_UHPI_HD_1, DA830_UHPI_HD_2, DA830_UHPI_HD_3,
DA830_UHPI_HD_4, DA830_UHPI_HD_5, DA830_UHPI_HD_6, DA830_UHPI_HD_7,
DA830_UHPI_HD_8, DA830_UHPI_HD_9, DA830_UHPI_HD_10, DA830_UHPI_HD_11,
DA830_UHPI_HD_12, DA830_UHPI_HD_13, DA830_UHPI_HD_14, DA830_UHPI_HD_15,
DA830_UHPI_HCNTL0, DA830_UHPI_HCNTL1, DA830_UHPI_HHWIL, DA830_UHPI_HRNW,
DA830_NUHPI_HAS, DA830_NUHPI_HCS, DA830_NUHPI_HDS1, DA830_NUHPI_HDS2,
DA830_NUHPI_HINT, DA830_NUHPI_HRDY,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_cpgmac_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_RMII_TXD_0, DA830_RMII_TXD_1, DA830_RMII_TXEN, DA830_RMII_CRS_DV,
DA830_RMII_RXD_0, DA830_RMII_RXD_1, DA830_RMII_RXER, DA830_MDIO_CLK,
DA830_MDIO_D,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_emif3c_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_EMB_SDCKE, DA830_EMB_CLK_GLUE, DA830_EMB_CLK, DA830_NEMB_CS_0,
DA830_NEMB_CAS, DA830_NEMB_RAS, DA830_NEMB_WE, DA830_EMB_BA_1,
DA830_EMB_BA_0, DA830_EMB_A_0, DA830_EMB_A_1, DA830_EMB_A_2,
DA830_EMB_A_3, DA830_EMB_A_4, DA830_EMB_A_5, DA830_EMB_A_6,
DA830_EMB_A_7, DA830_EMB_A_8, DA830_EMB_A_9, DA830_EMB_A_10,
DA830_EMB_A_11, DA830_EMB_A_12, DA830_NEMB_WE_DQM_3,
DA830_NEMB_WE_DQM_2, DA830_EMB_D_0, DA830_EMB_D_1, DA830_EMB_D_2,
DA830_EMB_D_3, DA830_EMB_D_4, DA830_EMB_D_5, DA830_EMB_D_6,
DA830_EMB_D_7, DA830_EMB_D_8, DA830_EMB_D_9, DA830_EMB_D_10,
DA830_EMB_D_11, DA830_EMB_D_12, DA830_EMB_D_13, DA830_EMB_D_14,
DA830_EMB_D_15, DA830_EMB_D_16, DA830_EMB_D_17, DA830_EMB_D_18,
DA830_EMB_D_19, DA830_EMB_D_20, DA830_EMB_D_21, DA830_EMB_D_22,
DA830_EMB_D_23, DA830_EMB_D_24, DA830_EMB_D_25, DA830_EMB_D_26,
DA830_EMB_D_27, DA830_EMB_D_28, DA830_EMB_D_29, DA830_EMB_D_30,
DA830_EMB_D_31, DA830_NEMB_WE_DQM_1, DA830_NEMB_WE_DQM_0,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_mcasp0_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_AHCLKX0, DA830_ACLKX0, DA830_AFSX0,
DA830_AHCLKR0, DA830_ACLKR0, DA830_AFSR0, DA830_AMUTE0,
DA830_AXR0_0, DA830_AXR0_1, DA830_AXR0_2, DA830_AXR0_3,
DA830_AXR0_4, DA830_AXR0_5, DA830_AXR0_6, DA830_AXR0_7,
DA830_AXR0_8, DA830_AXR0_9, DA830_AXR0_10, DA830_AXR0_11,
DA830_AXR0_12, DA830_AXR0_13, DA830_AXR0_14, DA830_AXR0_15,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_mcasp1_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_AHCLKX1, DA830_ACLKX1, DA830_AFSX1,
DA830_AHCLKR1, DA830_ACLKR1, DA830_AFSR1, DA830_AMUTE1,
DA830_AXR1_0, DA830_AXR1_1, DA830_AXR1_2, DA830_AXR1_3,
DA830_AXR1_4, DA830_AXR1_5, DA830_AXR1_6, DA830_AXR1_7,
DA830_AXR1_8, DA830_AXR1_9, DA830_AXR1_10, DA830_AXR1_11,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_mcasp2_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_AHCLKX2, DA830_ACLKX2, DA830_AFSX2,
DA830_AHCLKR2, DA830_ACLKR2, DA830_AFSR2, DA830_AMUTE2,
DA830_AXR2_0, DA830_AXR2_1, DA830_AXR2_2, DA830_AXR2_3,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_i2c0_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_I2C0_SDA, DA830_I2C0_SCL,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_i2c1_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_I2C1_SCL, DA830_I2C1_SDA,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_lcdcntl_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_LCD_D_0, DA830_LCD_D_1, DA830_LCD_D_2, DA830_LCD_D_3,
DA830_LCD_D_4, DA830_LCD_D_5, DA830_LCD_D_6, DA830_LCD_D_7,
DA830_LCD_D_8, DA830_LCD_D_9, DA830_LCD_D_10, DA830_LCD_D_11,
DA830_LCD_D_12, DA830_LCD_D_13, DA830_LCD_D_14, DA830_LCD_D_15,
DA830_LCD_PCLK, DA830_LCD_HSYNC, DA830_LCD_VSYNC, DA830_NLCD_AC_ENB_CS,
DA830_LCD_MCLK,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_pwm_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_ECAP0_APWM0, DA830_ECAP1_APWM1, DA830_EPWM0B, DA830_EPWM0A,
DA830_EPWMSYNCI, DA830_EPWMSYNC0, DA830_ECAP2_APWM2, DA830_EHRPWMGLUETZ,
DA830_EPWM2B, DA830_EPWM2A, DA830_EPWM1B, DA830_EPWM1A,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_ecap0_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_ECAP0_APWM0,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_ecap1_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_ECAP1_APWM1,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_ecap2_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_ECAP2_APWM2,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_eqep0_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_EQEP0I, DA830_EQEP0S, DA830_EQEP0A, DA830_EQEP0B,
-1
};
sections: fix section conflicts in arch/arm/ Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-04 18:11:28 -06:00
const short da830_eqep1_pins[] __initconst = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
DA830_EQEP1I, DA830_EQEP1S, DA830_EQEP1A, DA830_EQEP1B,
-1
};
static struct map_desc da830_io_desc[] = {
{
.virtual = IO_VIRT,
.pfn = __phys_to_pfn(IO_PHYS),
.length = IO_SIZE,
.type = MT_DEVICE
},
{
.virtual = DA8XX_CP_INTC_VIRT,
.pfn = __phys_to_pfn(DA8XX_CP_INTC_BASE),
.length = DA8XX_CP_INTC_SIZE,
.type = MT_DEVICE
},
};
/* Contents of JTAG ID register used to identify exact cpu type */
static struct davinci_id da830_ids[] = {
{
.variant = 0x0,
.part_no = 0xb7df,
.manufacturer = 0x017, /* 0x02f >> 1 */
.cpu_id = DAVINCI_CPU_ID_DA830,
davinci: da830: add support for new silicon revisions Newer revs of da830 silicon have different 'variant' field of the JTAG id register. Current code only supports rev 1.0 silicon. This patch adds support for rev1.1 and rev2.0 silicon and updates the 'name' strings to add a '-' between 'omap' & 'l137' to have consistent naming with da850/omap-l138. From Mark Grosen <mgrosen@ti.com>: "There are currently three silicon revisions for OMAPL137. The JTAG IDs (DEVIDR register contents) for each silicon revision are shown below: 0x0B7D F02F for silicon revision 1.0 0x8B7D F02F for silicon revision 1.1 0x9B7D F02F for silicon revision 2.0 Corresponding errata documentation will be available in the next few weeks on the ti.com website." Reported-by: Nick Thompson <Nick.Thompson@gefanuc.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-29 12:09:21 -06:00
.name = "da830/omap-l137 rev1.0",
},
{
.variant = 0x8,
.part_no = 0xb7df,
.manufacturer = 0x017,
.cpu_id = DAVINCI_CPU_ID_DA830,
.name = "da830/omap-l137 rev1.1",
},
{
.variant = 0x9,
.part_no = 0xb7df,
.manufacturer = 0x017,
.cpu_id = DAVINCI_CPU_ID_DA830,
.name = "da830/omap-l137 rev2.0",
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
},
};
ARM: davinci: da8xx: support gpio platform device DaVinci GPIO driver now uses platform device model. Convert DA8XX SoC code to use the new model. Add da8xx_register_gpio() to create platform device for da8xx platforms. Signed-off-by: KV Sujith <sujithkv@ti.com> Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> [nsekhar@ti.com: simplify commit message] Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
2013-08-17 23:18:59 -06:00
static struct davinci_gpio_platform_data da830_gpio_platform_data = {
ARM: davinci: da830: set the GPIO base to 0 Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection") broke the GPIO support on DaVinci boards in legacy mode by allowing gpiolib to set the GPIO base automatically. DaVinci board files use the legacy GPIO API with hard-coded GPIO line numbers. Use the new fields in struct davinci_gpio_platform_data to manually set the GPIO base to 0. Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 02:35:22 -07:00
.no_auto_base = true,
.base = 0,
.ngpio = 128,
ARM: davinci: da8xx: support gpio platform device DaVinci GPIO driver now uses platform device model. Convert DA8XX SoC code to use the new model. Add da8xx_register_gpio() to create platform device for da8xx platforms. Signed-off-by: KV Sujith <sujithkv@ti.com> Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> [nsekhar@ti.com: simplify commit message] Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
2013-08-17 23:18:59 -06:00
};
int __init da830_register_gpio(void)
{
return da8xx_register_gpio(&da830_gpio_platform_data);
}
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
/*
ARM: davinci: da830: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the da830 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 07:17:42 -06:00
* Bottom half of timer0 is used both for clock even and clocksource.
* Top half is used by DSP.
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
*/
ARM: davinci: da830: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the da830 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 07:17:42 -06:00
static const struct davinci_timer_cfg da830_timer_cfg = {
.reg = DEFINE_RES_IO(DA8XX_TIMER64P0_BASE, SZ_4K),
.irq = {
DEFINE_RES_IRQ(DAVINCI_INTC_IRQ(IRQ_DA830_T12CMPINT0_0)),
DEFINE_RES_IRQ(DAVINCI_INTC_IRQ(IRQ_DA8XX_TINT12_0)),
},
.cmp_off = DA830_CMP12_0,
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
};
ARM: davinci: make davinci_soc_info structures const Make davinci_soc_info structures const as they are either passed to the function davinci_common_init having the argument as const or their field cpu_clks of type struct clk_lookup * is passed to the function davinci_clk_init. So, the fields are never modified and the structures can be const. Done using Coccinelle. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> [nsekhar@ti.com: minor commit message adjustment] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-10-16 04:08:24 -06:00
static const struct davinci_soc_info davinci_soc_info_da830 = {
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
.io_desc = da830_io_desc,
.io_desc_num = ARRAY_SIZE(da830_io_desc),
Davinci: jtag_id - use ioremap() This patch replaces the jtag id base info in davinci_soc_info with a physical address which is then ioremap()ed within common code. This patch (in combination with a similar change for PSC) will allow us to eliminate the SYSCFG nastiness in DA8xx code. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-07 15:06:34 -06:00
.jtag_id_reg = DA8XX_SYSCFG0_BASE + DA8XX_JTAG_ID_REG,
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
.ids = da830_ids,
.ids_num = ARRAY_SIZE(da830_ids),
Davinci: pinmux - use ioremap() This patch modifies the pinmux implementation so as to ioremap() the pinmux register area on first use. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-07 15:06:38 -06:00
.pinmux_base = DA8XX_SYSCFG0_BASE + 0x120,
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
.pinmux_pins = da830_pins,
.pinmux_pins_num = ARRAY_SIZE(da830_pins),
.emac_pdata = &da8xx_emac_pdata,
};
void __init da830_init(void)
{
davinci_common_init(&davinci_soc_info_da830);
Davinci: iotable based ioremap() interception This patch allows for a more flexible ioremap() interception based on iotable contents. With this patch, the ioremap() interception code can properly translate addresses only after davinci_soc_info has been initialized. Consequently, in soc-specific init functions, davinci_common_init() has to happen before any ioremap() attempts. The da8xx init sequence has been suitably modified to meet this restriction. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-07 15:06:39 -06:00
da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
WARN(!da8xx_syscfg0_base, "Unable to map syscfg0 module");
ARM: davinci: move davinci_clk_init() to init_time This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. dm646x is a special case because we need to handle different ref_clk rates depending on which board is being used. The clock init in this case is modified to set the rate before registering the clocks instead of using davinci_set_refclk_rate() to recalculate the entire clock tree after all of the clocks are registered. Also, the cpu_clks field is removed from struct davinci_soc_info since it is no longer needed. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-01-19 20:20:22 -07:00
}
ARM: davinci: Move clock init after ioremap. Some clocks (such as the USB PHY clocks in DA8xx) will need to use iomem. The davinci_common_init() function must be called before the ioremap, so the clock init is now split out as separate function. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-04-14 13:13:35 -06:00
ARM: davinci: cp-intc: add the new config structures for da8xx SoCs Add the new-style config structures for da8xx SoCs. They will be used once we make the cp-intc driver stop using davinci_soc_info. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 07:52:20 -07:00
static const struct davinci_cp_intc_config da830_cp_intc_config = {
.reg = {
.start = DA8XX_CP_INTC_BASE,
.end = DA8XX_CP_INTC_BASE + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
.num_irqs = DA830_N_CP_INTC_IRQ,
};
ARM: davinci: cp-intc: add a wrapper around cp_intc_init() We're going to extend the cp_intc_init() function with a config structure so we can drop the intc-related fields from davinci_soc_info. Once we do it, we won't be able to use this routine directly as the init_irq callback. Wrap the calls in additional helpers that don't take parameters and can be assigned to init_irq. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 07:52:18 -07:00
void __init da830_init_irq(void)
{
ARM: davinci: cp-intc: use the new-style config structure Modify the cp-intc driver to take all its configuration from the new config structure. Stop referencing davinci_soc_info in any way. Move the declaration for davinci_cp_intc_init() to irq-davinci-cp-intc.h and make it take the new config structure as parameter. Convert all users to the new version. Also: since the two da8xx SoCs default all irq priorities to 7, just drop the priority configuration at all and hardcode the channels to 7. It will simplify the driver code and make our lives easier when it comes to device-tree support. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 07:52:23 -07:00
davinci_cp_intc_init(&da830_cp_intc_config);
ARM: davinci: cp-intc: add a wrapper around cp_intc_init() We're going to extend the cp_intc_init() function with a config structure so we can drop the intc-related fields from davinci_soc_info. Once we do it, we won't be able to use this routine directly as the init_irq callback. Wrap the calls in additional helpers that don't take parameters and can be assigned to init_irq. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 07:52:18 -07:00
}
ARM: davinci: move davinci_clk_init() to init_time This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. dm646x is a special case because we need to handle different ref_clk rates depending on which board is being used. The clock init in this case is modified to set the rate before registering the clocks instead of using davinci_set_refclk_rate() to recalculate the entire clock tree after all of the clocks are registered. Also, the cpu_clks field is removed from struct davinci_soc_info since it is no longer needed. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-01-19 20:20:22 -07:00
void __init da830_init_time(void)
{
ARM: davinci: da830: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/da830.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 10:48:07 -06:00
void __iomem *pll;
struct clk *clk;
ARM: davinci: da830: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the da830 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 07:17:42 -06:00
int rv;
ARM: davinci: da830: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/da830.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 10:48:07 -06:00
clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DA830_REF_FREQ);
pll = ioremap(DA8XX_PLL0_BASE, SZ_4K);
da830_pll_init(NULL, pll, NULL);
clk = clk_get(NULL, "timer0");
ARM: davinci: WARN_ON() if clk_get() fails Currently the timer code checks if the clock pointer passed to it is good (!IS_ERR(clk)). The new clocksource driver expects the clock to be functional and doesn't perform any checks so emit a warning if clk_get() fails. Apply this to all davinci platforms. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 07:17:40 -06:00
if (WARN_ON(IS_ERR(clk))) {
pr_err("Unable to get the timer clock\n");
return;
}
ARM: davinci: da830: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/da830.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 10:48:07 -06:00
ARM: davinci: da830: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the da830 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 07:17:42 -06:00
rv = davinci_timer_register(clk, &da830_timer_cfg);
WARN(rv, "Unable to register the timer: %d\n", rv);
ARM: davinci: da830: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/da830.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 10:48:07 -06:00
}
static struct resource da830_psc0_resources[] = {
{
.start = DA8XX_PSC0_BASE,
.end = DA8XX_PSC0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device da830_psc0_device = {
.name = "da830-psc0",
.id = -1,
.resource = da830_psc0_resources,
.num_resources = ARRAY_SIZE(da830_psc0_resources),
};
static struct resource da830_psc1_resources[] = {
{
.start = DA8XX_PSC1_BASE,
.end = DA8XX_PSC1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device da830_psc1_device = {
.name = "da830-psc1",
.id = -1,
.resource = da830_psc1_resources,
.num_resources = ARRAY_SIZE(da830_psc1_resources),
};
void __init da830_register_clocks(void)
{
/* PLL is registered in da830_init_time() */
platform_device_register(&da830_psc0_device);
platform_device_register(&da830_psc1_device);
davinci: da8xx: Add base DA830/OMAP-L137 SoC support The da830/omap l137 is a new SoC from TI that is similar to the davinci line. Since its so similar to davinci, put the support for the da830 in the same directory as the davinci code. There are differences, however. Some of those differences prevent support for davinci and da830 platforms to work in the same kernel binary. Those differences are: 1) Different physical address for RAM. This is relevant to Makefile.boot addresses and PHYS_OFFSET. The Makefile.boot issue isn't truly a kernel issue but it means u-boot won't work with a uImage including both architectures. The PHYS_OFFSET issue is addressed by the "Allow for runtime-determined PHYS_OFFSET" patch by Lennert Buytenhek but it hasn't been accepted yet. 2) Different uart addresses. This is only an issue for the 'addruart' assembly macro when CONFIG_DEBUG_LL is enabled. Since the code in that macro is called so early (e.g., by _error_p in kernel/head.S when the processor lookup fails), we can't determine what platform the kernel is running on at runtime to use the correct uart address. These areas have compile errors intentionally inserted to indicate to the builder they're doing something wrong. A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added to distinguish between a true davinci architecture and the da830 architecture. Note that the da830 currently has an issue with writeback data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be enabled when building a da830 kernel. Additional generalizations for future SoCs in the da8xx family done by Sudhakar Rajashekhara and Sekhar Nori. Signed-off-by: Steve Chen <schen@mvista.com> Signed-off-by: Mikhail Cherkashin <mcherkashin@ru.mvista.com> Signed-off-by: Mark A. Greer <mgreer@mvista.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-03 19:36:54 -06:00
}
Copy permalink