iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
525c303049
linux/arch/arm/mach-davinci/devices-da8xx.c

71 lines
2.1 KiB
C
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-27 09:55:01 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
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-04 05:36:54 +04:00
/*
* DA8XX/OMAP L1XX platform device data
*
* Copyright (c) 2007-2009, MontaVista Software, Inc. <source@mvista.com>
* Derived from code that was:
* Copyright (C) 2006 Komal Shah <komal_shah802003@yahoo.com>
*/
davinci: da850: add support for SATA interface Add support for SATA controller on the DA850/OMAP-L138/AM18x devices. The patch adds the necessary clocks, platform resources and a routine to initialize the SATA controller. The PHY configuration in this patch is courtesy the work done by Zegeye Alemu, Swaminathan and Mansoor Ahamed from TI. While testing this patch, enable port multiplier support iff you are actually using one. The reasons of this behaviour are discussed here: http://patchwork.ozlabs.org/patch/78163/ ChangeLog: v3: Removed fields which were being initialized to zero in PHY configuration. Moved SATA base address definition to the top of the file to make it inline with what is done for the rest of the modules. v2: Addressed comments from Sergei. Removed unnecessary braces and removed unnecessary else after goto. Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-07-06 10:01:23 +04:00
#include <linux/ahci_platform.h>
ARM: davinci: da8xx: add new sata_refclk init using common clock framework This adds the new SATA REFCLK clock init in mach-davinci/devices-da8xx.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also, the #includes are sorted since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 19:48:14 +03:00
#include <linux/clk-provider.h>
davinci: da850: add support for SATA interface Add support for SATA controller on the DA850/OMAP-L138/AM18x devices. The patch adds the necessary clocks, platform resources and a routine to initialize the SATA controller. The PHY configuration in this patch is courtesy the work done by Zegeye Alemu, Swaminathan and Mansoor Ahamed from TI. While testing this patch, enable port multiplier support iff you are actually using one. The reasons of this behaviour are discussed here: http://patchwork.ozlabs.org/patch/78163/ ChangeLog: v3: Removed fields which were being initialized to zero in PHY configuration. Moved SATA base address definition to the top of the file to make it inline with what is done for the rest of the modules. v2: Addressed comments from Sergei. Removed unnecessary braces and removed unnecessary else after goto. Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-07-06 10:01:23 +04:00
#include <linux/clk.h>
ARM: davinci: da8xx: add new sata_refclk init using common clock framework This adds the new SATA REFCLK clock init in mach-davinci/devices-da8xx.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also, the #includes are sorted since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 19:48:14 +03:00
#include <linux/clkdev.h>
dma-mapping: merge <linux/dma-contiguous.h> into <linux/dma-map-ops.h> Merge dma-contiguous.h into dma-map-ops.h, after removing the comment describing the contiguous allocator into kernel/dma/contigous.c. Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-09-11 11:56:52 +03:00
#include <linux/dma-map-ops.h>
ARM: davinci: devices-da8xx: Add dma_slave_map to edma Provide the dma_slave_map to edma which will allow us to move the drivers to the new, simpler dmaengine API and we can remove the DMA resources also for the devices. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> [nsekhar@ti.com: fix map for edma1] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-02-02 15:43:13 +03:00
#include <linux/dmaengine.h>
ARM: davinci: da8xx: add new sata_refclk init using common clock framework This adds the new SATA REFCLK clock init in mach-davinci/devices-da8xx.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also, the #includes are sorted since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 19:48:14 +03: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-19 01:20:22 +03:00
#include <linux/io.h>
ARM: davinci: da8xx: add new sata_refclk init using common clock framework This adds the new SATA REFCLK clock init in mach-davinci/devices-da8xx.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also, the #includes are sorted since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 19:48:14 +03:00
#include <linux/platform_device.h>
#include <linux/reboot.h>
#include <linux/serial_8250.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-04 05:36:54 +04:00
ARM: davinci: remove include/mach/ subdirectory The files in include/mach are only used from mach/davinci, so they are no longer needed in the traditional location. Move them to arch/arm/mach-davinci/ and drop the logic for the special include path. The mach/uncompress.h file is not used at all and can just be removed. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-28 10:32:09 +03:00
#include "common.h"
#include "cputype.h"
#include "da8xx.h"
ARM: davinci: make headers more local Some header files are never included outside of a mach-davinci directory and do not need to be made visible in include/mach, so let's just move them all down one level. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sekhar Nori <nsekhar@ti.com>
2015-01-30 12:45:33 +03:00
#include "cpuidle.h"
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 17:52:03 +03:00
#include "irqs.h"
ARM: davinci: make headers more local Some header files are never included outside of a mach-davinci directory and do not need to be made visible in include/mach, so let's just move them all down one level. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sekhar Nori <nsekhar@ti.com>
2015-01-30 12:45:33 +03:00
#include "sram.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-04 05:36:54 +04:00
#define DA8XX_TPCC_BASE 0x01c00000
#define DA8XX_TPTC0_BASE 0x01c08000
#define DA8XX_TPTC1_BASE 0x01c08400
#define DA8XX_WDOG_BASE 0x01c21000 /* DA8XX_TIMER64P1_BASE */
#define DA8XX_I2C0_BASE 0x01c22000
DA8xx: move base address #define's to their proper place Move DA8XX_MMCSD0_BASE, DA8XX_LCD_CNTRL_BASE, and DA8XX_DDR2_CTL_BASE from <mach/da8xx.h> to devices-da8xx.c as the latter file is the only place where these macros are used. While at it, restore sorting the base address macros by address value in devices-da8xx.c... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
2011-04-06 21:29:24 +04:00
#define DA8XX_RTC_BASE 0x01c23000
ARM: davinci: da8xx: add DA850 PRUSS support Adds PRUSS clock support and registration helper for the uio_pruss device. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-10-08 17:53:08 +04:00
#define DA8XX_PRUSS_MEM_BASE 0x01c30000
DA8xx: move base address #define's to their proper place Move DA8XX_MMCSD0_BASE, DA8XX_LCD_CNTRL_BASE, and DA8XX_DDR2_CTL_BASE from <mach/da8xx.h> to devices-da8xx.c as the latter file is the only place where these macros are used. While at it, restore sorting the base address macros by address value in devices-da8xx.c... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
2011-04-06 21:29:24 +04:00
#define DA8XX_MMCSD0_BASE 0x01c40000
#define DA8XX_SPI0_BASE 0x01c41000
#define DA830_SPI1_BASE 0x01e12000
#define DA8XX_LCD_CNTRL_BASE 0x01e13000
davinci: da850: add support for SATA interface Add support for SATA controller on the DA850/OMAP-L138/AM18x devices. The patch adds the necessary clocks, platform resources and a routine to initialize the SATA controller. The PHY configuration in this patch is courtesy the work done by Zegeye Alemu, Swaminathan and Mansoor Ahamed from TI. While testing this patch, enable port multiplier support iff you are actually using one. The reasons of this behaviour are discussed here: http://patchwork.ozlabs.org/patch/78163/ ChangeLog: v3: Removed fields which were being initialized to zero in PHY configuration. Moved SATA base address definition to the top of the file to make it inline with what is done for the rest of the modules. v2: Addressed comments from Sergei. Removed unnecessary braces and removed unnecessary else after goto. Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-07-06 10:01:23 +04:00
#define DA850_SATA_BASE 0x01e18000
DA8xx: move base address #define's to their proper place Move DA8XX_MMCSD0_BASE, DA8XX_LCD_CNTRL_BASE, and DA8XX_DDR2_CTL_BASE from <mach/da8xx.h> to devices-da8xx.c as the latter file is the only place where these macros are used. While at it, restore sorting the base address macros by address value in devices-da8xx.c... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
2011-04-06 21:29:24 +04:00
#define DA850_MMCSD1_BASE 0x01e1b000
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-04 05:36:54 +04:00
#define DA8XX_EMAC_CPPI_PORT_BASE 0x01e20000
#define DA8XX_EMAC_CPGMACSS_BASE 0x01e22000
#define DA8XX_EMAC_CPGMAC_BASE 0x01e23000
#define DA8XX_EMAC_MDIO_BASE 0x01e24000
#define DA8XX_I2C1_BASE 0x01e28000
DA8xx: move base address #define's to their proper place Move DA8XX_MMCSD0_BASE, DA8XX_LCD_CNTRL_BASE, and DA8XX_DDR2_CTL_BASE from <mach/da8xx.h> to devices-da8xx.c as the latter file is the only place where these macros are used. While at it, restore sorting the base address macros by address value in devices-da8xx.c... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
2011-04-06 21:29:24 +04:00
#define DA850_TPCC1_BASE 0x01e30000
#define DA850_TPTC2_BASE 0x01e38000
DA830: fix SPI1 base address Commit 54ce6883d29630ff334bee4256a25e3f8719a181 (davinci: da8xx: add spi resources and registration routine) wrongly assumed that SPI1 is mapped at the same address on DA830/OMAP-L137 and DA850/OMAP-L138; actually, the base address was valid only for the latter SoC. Teach the code to pass the correct SPI1 memory resource for both SoCs... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-04-06 21:17:21 +04:00
#define DA850_SPI1_BASE 0x01f0e000
DA8xx: move base address #define's to their proper place Move DA8XX_MMCSD0_BASE, DA8XX_LCD_CNTRL_BASE, and DA8XX_DDR2_CTL_BASE from <mach/da8xx.h> to devices-da8xx.c as the latter file is the only place where these macros are used. While at it, restore sorting the base address macros by address value in devices-da8xx.c... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
2011-04-06 21:29:24 +04:00
#define DA8XX_DDR2_CTL_BASE 0xb0000000
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-04 05:36:54 +04:00
#define DA8XX_EMAC_CTRL_REG_OFFSET 0x3000
#define DA8XX_EMAC_MOD_REG_OFFSET 0x2000
#define DA8XX_EMAC_RAM_OFFSET 0x0000
#define DA8XX_EMAC_CTRL_RAM_SIZE SZ_8K
davinci: da8xx/omapl1: add support for the second sysconfig module OMAP-L138 adds a second SYSCFG region having useful functionality like deep sleep, pull up/down control and SATA clock stop. This patch makes provision for accessing registers from second SYSCFG region in da8xx code. Note that OMAP-L137 has a single SYSCFG region. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-16 14:51:32 +03:00
void __iomem *da8xx_syscfg0_base;
void __iomem *da8xx_syscfg1_base;
davinci: DA8XX/OMAP-L1XX: Avoid use of IO_ADDRESS for SYSCFG module Avoid use of IO_ADDRESS() for SYSCFG module by doing an ioremap() instead. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-31 14:17:59 +04:00
davinci: cpuidle: move mapping of DDR2 controller registers out of driver When suspend is supported, both cpuidle and suspend code need to work on DDR2 registers. Instead of mapping the DDR2 registers twice, do it once outside of cpuidle driver and let cpuidle driver get the virtual base address of DDR2 registers. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-16 14:51:37 +03:00
static void __iomem *da8xx_ddr2_ctlr_base;
void __iomem * __init da8xx_get_mem_ctlr(void)
{
if (da8xx_ddr2_ctlr_base)
return da8xx_ddr2_ctlr_base;
da8xx_ddr2_ctlr_base = ioremap(DA8XX_DDR2_CTL_BASE, SZ_32K);
if (!da8xx_ddr2_ctlr_base)
ARM: davinci: devices-da8xx.c: change pr_warning() to pr_warn() Changed all pr_warning() calls to pr_warn(), as advised by checkpatch.pl. Signed-off-by: Robert Tivy <rtivy@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-01-11 04:23:20 +04:00
pr_warn("%s: Unable to map DDR2 controller", __func__);
davinci: cpuidle: move mapping of DDR2 controller registers out of driver When suspend is supported, both cpuidle and suspend code need to work on DDR2 registers. Instead of mapping the DDR2 registers twice, do it once outside of cpuidle driver and let cpuidle driver get the virtual base address of DDR2 registers. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-16 14:51:37 +03:00
return da8xx_ddr2_ctlr_base;
}
Reference in New Issue Copy Permalink