brain-hackers_pepepper-mirror/linux-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/linux-brain.git synced 2024-06-09 23:36:23 +09:00
Code Issues Projects Releases Wiki Activity
2874c5fd28
linux-brain/arch/arm/mach-davinci/devices-da8xx.c

1161 lines
28 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 15:55:01 +09: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 10:36:54 +09: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 15:01:23 +09: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-19 01:48:14 +09: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 15:01:23 +09: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-19 01:48:14 +09:00
#include <linux/clkdev.h>
#include <linux/dma-contiguous.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 21:43:13 +09: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-19 01:48:14 +09: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 07:20:22 +09: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-19 01:48:14 +09: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 10:36:54 +09:00
#include <mach/common.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-19 01:48:14 +09: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-04 10:36:54 +09:00
#include <mach/da8xx.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-19 01:48:14 +09:00
#include <mach/time.h>
#include "asp.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 18:45:33 +09: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 23:52:03 +09: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 18:45:33 +09: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 10:36:54 +09: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-07 02:29:24 +09: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 22:53:08 +09: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-07 02:29:24 +09: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 15:01:23 +09: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-07 02:29:24 +09: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 10:36:54 +09: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-07 02:29:24 +09: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-07 02:17:21 +09: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-07 02:29:24 +09: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 10:36:54 +09: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 20:51:32 +09: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 19:17:59 +09:00
ARM: davinci: uart: move to devid based clk_get For modules having single clock, clk_get should be done with dev_id. But current davinci implementation handles multiple instances of the UART devices with single platform_device_register. Hence clk_get is based on con_id rather than dev_id, this is not correct. Do platform_device_register for each instance and clk_get on dev_id. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> [nsekhar@ti.com: actually stop using con_id in clk_get(), squash the patch adding OF aux data into this one] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-19 18:15:38 +09:00
static struct plat_serial8250_port da8xx_serial0_pdata[] = {
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 10:36:54 +09:00
{
.mapbase = DA8XX_UART0_BASE,
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.irq = DAVINCI_INTC_IRQ(IRQ_DA8XX_UARTINT0),
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 10:36:54 +09:00
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
UPF_IOREMAP,
.iotype = UPIO_MEM,
.regshift = 2,
},
ARM: davinci: uart: move to devid based clk_get For modules having single clock, clk_get should be done with dev_id. But current davinci implementation handles multiple instances of the UART devices with single platform_device_register. Hence clk_get is based on con_id rather than dev_id, this is not correct. Do platform_device_register for each instance and clk_get on dev_id. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> [nsekhar@ti.com: actually stop using con_id in clk_get(), squash the patch adding OF aux data into this one] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-19 18:15:38 +09:00
{
.flags = 0,
}
};
static struct plat_serial8250_port da8xx_serial1_pdata[] = {
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 10:36:54 +09:00
{
.mapbase = DA8XX_UART1_BASE,
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.irq = DAVINCI_INTC_IRQ(IRQ_DA8XX_UARTINT1),
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 10:36:54 +09:00
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
UPF_IOREMAP,
.iotype = UPIO_MEM,
.regshift = 2,
},
ARM: davinci: uart: move to devid based clk_get For modules having single clock, clk_get should be done with dev_id. But current davinci implementation handles multiple instances of the UART devices with single platform_device_register. Hence clk_get is based on con_id rather than dev_id, this is not correct. Do platform_device_register for each instance and clk_get on dev_id. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> [nsekhar@ti.com: actually stop using con_id in clk_get(), squash the patch adding OF aux data into this one] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-19 18:15:38 +09:00
{
.flags = 0,
}
};
static struct plat_serial8250_port da8xx_serial2_pdata[] = {
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 10:36:54 +09:00
{
.mapbase = DA8XX_UART2_BASE,
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.irq = DAVINCI_INTC_IRQ(IRQ_DA8XX_UARTINT2),
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 10:36:54 +09:00
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
UPF_IOREMAP,
.iotype = UPIO_MEM,
.regshift = 2,
},
{
.flags = 0,
ARM: davinci: uart: move to devid based clk_get For modules having single clock, clk_get should be done with dev_id. But current davinci implementation handles multiple instances of the UART devices with single platform_device_register. Hence clk_get is based on con_id rather than dev_id, this is not correct. Do platform_device_register for each instance and clk_get on dev_id. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> [nsekhar@ti.com: actually stop using con_id in clk_get(), squash the patch adding OF aux data into this one] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-19 18:15:38 +09:00
}
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 10:36:54 +09:00
};
ARM: davinci: uart: move to devid based clk_get For modules having single clock, clk_get should be done with dev_id. But current davinci implementation handles multiple instances of the UART devices with single platform_device_register. Hence clk_get is based on con_id rather than dev_id, this is not correct. Do platform_device_register for each instance and clk_get on dev_id. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> [nsekhar@ti.com: actually stop using con_id in clk_get(), squash the patch adding OF aux data into this one] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-19 18:15:38 +09:00
struct platform_device da8xx_serial_device[] = {
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = {
.platform_data = da8xx_serial0_pdata,
}
},
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM1,
.dev = {
.platform_data = da8xx_serial1_pdata,
}
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 10:36:54 +09:00
},
ARM: davinci: uart: move to devid based clk_get For modules having single clock, clk_get should be done with dev_id. But current davinci implementation handles multiple instances of the UART devices with single platform_device_register. Hence clk_get is based on con_id rather than dev_id, this is not correct. Do platform_device_register for each instance and clk_get on dev_id. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> [nsekhar@ti.com: actually stop using con_id in clk_get(), squash the patch adding OF aux data into this one] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-19 18:15:38 +09:00
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM2,
.dev = {
.platform_data = da8xx_serial2_pdata,
}
},
{
}
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 10:36:54 +09:00
};
ARM: edma: Add DT and runtime PM support to the private EDMA API Adds support for parsing the TI EDMA DT data into the required EDMA private API platform data. Enables runtime PM support to initialize the EDMA hwmod. Enables build on OMAP. Changes by Joel: * Setup default one-to-one mapping for queue_priority and queue_tc mapping as discussed in [1]. * Split out xbar stuff to separate patch. [1] * Dropped unused DT helper to convert to array * Fixed dangling pointer issue with Sekhar's changes [1] https://patchwork.kernel.org/patch/2226761/ Signed-off-by: Matt Porter <mporter@ti.com> [nsekhar@ti.com: fix checkpatch errors, build breakages. Introduce edma_setup_info_from_dt() as part of that effort] Signed-off-by: Joel A Fernandes <joelagnel@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-21 06:06:38 +09:00
static s8 da8xx_queue_priority_mapping[][2] = {
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 10:36:54 +09:00
/* {event queue no, Priority} */
{0, 3},
{1, 7},
{-1, -1}
};
ARM: edma: Add DT and runtime PM support to the private EDMA API Adds support for parsing the TI EDMA DT data into the required EDMA private API platform data. Enables runtime PM support to initialize the EDMA hwmod. Enables build on OMAP. Changes by Joel: * Setup default one-to-one mapping for queue_priority and queue_tc mapping as discussed in [1]. * Split out xbar stuff to separate patch. [1] * Dropped unused DT helper to convert to array * Fixed dangling pointer issue with Sekhar's changes [1] https://patchwork.kernel.org/patch/2226761/ Signed-off-by: Matt Porter <mporter@ti.com> [nsekhar@ti.com: fix checkpatch errors, build breakages. Introduce edma_setup_info_from_dt() as part of that effort] Signed-off-by: Joel A Fernandes <joelagnel@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-21 06:06:38 +09:00
static s8 da850_queue_priority_mapping[][2] = {
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
/* {event queue no, Priority} */
{0, 3},
{-1, -1}
};
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
static struct edma_soc_info da8xx_edma0_pdata = {
davinci: edma: provide ability to detect insufficient CC info data This patch modifies the EDMA driver to expect the channel controller (CC) infomation passed on by the platform as a fixed size (EDMA_MAX_CC) array of pointers to structures. Doing so helps catch errors of the sort where the resource structure has information for more channel controllers than the number channel controller info structures defined. Such insufficient platform data would lead to illegal memory accesses. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-06-29 15:05:12 +09:00
.queue_priority_mapping = da8xx_queue_priority_mapping,
ARM: davinci: Explicitly set channel controllers' default queues Davinci platforms may define a default queue for each channel controller. If one is not defined, the default queue is set to EVENTQ_1. However, there's no way to distinguish between an unset default queue to one that is set to EVENTQ_0, as EVENTQ_0 = 0. Explicitly specify the default queue for all channel controllers on all Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe function. One exception is the DA850 board, for which EVENTQ_1 is not a valid option for its second channel controller. Use EVENTQ_0 instead for that channel controller. Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-07-10 22:14:35 +09:00
.default_queue = EVENTQ_1,
davinci: edma: provide ability to detect insufficient CC info data This patch modifies the EDMA driver to expect the channel controller (CC) infomation passed on by the platform as a fixed size (EDMA_MAX_CC) array of pointers to structures. Doing so helps catch errors of the sort where the resource structure has information for more channel controllers than the number channel controller info structures defined. Such insufficient platform data would lead to illegal memory accesses. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-06-29 15:05:12 +09:00
};
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
static struct edma_soc_info da850_edma1_pdata = {
.queue_priority_mapping = da850_queue_priority_mapping,
.default_queue = EVENTQ_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-04 10:36:54 +09:00
};
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
static struct resource da8xx_edma0_resources[] = {
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_cc",
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 10:36:54 +09:00
.start = DA8XX_TPCC_BASE,
.end = DA8XX_TPCC_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_tc0",
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 10:36:54 +09:00
.start = DA8XX_TPTC0_BASE,
.end = DA8XX_TPTC0_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_tc1",
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 10:36:54 +09:00
.start = DA8XX_TPTC1_BASE,
.end = DA8XX_TPTC1_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_ccint",
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_CCINT0),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_ccerrint",
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_CCERRINT),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
};
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
static struct resource da850_edma1_resources[] = {
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_cc",
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
.start = DA850_TPCC1_BASE,
.end = DA850_TPCC1_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_tc0",
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
.start = DA850_TPTC2_BASE,
.end = DA850_TPTC2_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_ccint",
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA850_CCINT1),
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.name = "edma3_ccerrint",
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA850_CCERRINT1),
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
.flags = IORESOURCE_IRQ,
},
};
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
static const struct platform_device_info da8xx_edma0_device __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-04 10:36:54 +09:00
.name = "edma",
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.id = 0,
ARM: davinci: Add dma_mask to eDMA devices The upcoming change to merge the arch/arm/common/edma.c into drivers/dma/edma.c will need this change when booting daVinci devices in no DT mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:52 +09:00
.dma_mask = DMA_BIT_MASK(32),
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
.res = da8xx_edma0_resources,
.num_res = ARRAY_SIZE(da8xx_edma0_resources),
.data = &da8xx_edma0_pdata,
.size_data = sizeof(da8xx_edma0_pdata),
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
};
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
static const struct platform_device_info da850_edma1_device __initconst = {
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
.name = "edma",
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
.id = 1,
ARM: davinci: Add dma_mask to eDMA devices The upcoming change to merge the arch/arm/common/edma.c into drivers/dma/edma.c will need this change when booting daVinci devices in no DT mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:52 +09:00
.dma_mask = DMA_BIT_MASK(32),
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
.res = da850_edma1_resources,
.num_res = ARRAY_SIZE(da850_edma1_resources),
.data = &da850_edma1_pdata,
.size_data = sizeof(da850_edma1_pdata),
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 10:36:54 +09:00
};
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 21:43:13 +09:00
static const struct dma_slave_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};
davinci: da8xx/omapl EVM: Specify reserved channels/slots The drivers on da8xx/omapl EVMs do not utilize all the channels and slots provided by EDMA. Some of these are better utilitzed by the DSP on the SoC for speeding up codec operations. Reserve these channels/slots for the DSP. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-06-29 15:05:14 +09:00
int __init da830_register_edma(struct edma_rsv_info *rsv)
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 10:36:54 +09:00
{
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
struct platform_device *edma_pdev;
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
da8xx_edma0_pdata.rsv = rsv;
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
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 21:43:13 +09:00
da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
edma_pdev = platform_device_register_full(&da8xx_edma0_device);
ARM: davinci: Use PTR_ERR_OR_ZERO() Fix ptr_ret.cocci warnings: arch/arm/mach-davinci/devices-da8xx.c:255:8-14: WARNING: PTR_ERR_OR_ZERO can be used arch/arm/mach-davinci/devices-da8xx.c:300:8-14: WARNING: PTR_ERR_OR_ZERO can be used arch/arm/mach-davinci/dm646x.c:952:8-14: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-11-28 08:03:33 +09:00
return PTR_ERR_OR_ZERO(edma_pdev);
davinci: da8xx/omapl EVM: Specify reserved channels/slots The drivers on da8xx/omapl EVMs do not utilize all the channels and slots provided by EDMA. Some of these are better utilitzed by the DSP on the SoC for speeding up codec operations. Reserve these channels/slots for the DSP. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-06-29 15:05:14 +09:00
}
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 21:43:13 +09:00
static const struct dma_slave_map da850_edma0_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcbsp.1", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcbsp.1", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};
static const struct dma_slave_map da850_edma1_map[] = {
{ "da830-mmc.1", "rx", EDMA_FILTER_PARAM(1, 28) },
{ "da830-mmc.1", "tx", EDMA_FILTER_PARAM(1, 29) },
};
davinci: da8xx/omapl EVM: Specify reserved channels/slots The drivers on da8xx/omapl EVMs do not utilize all the channels and slots provided by EDMA. Some of these are better utilitzed by the DSP on the SoC for speeding up codec operations. Reserve these channels/slots for the DSP. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-06-29 15:05:14 +09:00
int __init da850_register_edma(struct edma_rsv_info *rsv[2])
{
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
struct platform_device *edma_pdev;
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
davinci: da8xx/omapl EVM: Specify reserved channels/slots The drivers on da8xx/omapl EVMs do not utilize all the channels and slots provided by EDMA. Some of these are better utilitzed by the DSP on the SoC for speeding up codec operations. Reserve these channels/slots for the DSP. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-06-29 15:05:14 +09:00
if (rsv) {
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
da8xx_edma0_pdata.rsv = rsv[0];
da850_edma1_pdata.rsv = rsv[1];
davinci: da8xx/omapl EVM: Specify reserved channels/slots The drivers on da8xx/omapl EVMs do not utilize all the channels and slots provided by EDMA. Some of these are better utilitzed by the DSP on the SoC for speeding up codec operations. Reserve these channels/slots for the DSP. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-06-29 15:05:14 +09:00
}
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 Currently da850/omap-l138 supports only one channel controller instance of EDMA though EDMA driver as such supports multiple channel controller instances. This patch adds platform data for the 2nd EDMA channel controller. As, the platform data differ between da830/omap-l137 and da850/omap-l138, existing code has been re-shuffled to accommodate this. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-01-06 21:00:06 +09:00
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 21:43:13 +09:00
da8xx_edma0_pdata.slave_map = da850_edma0_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da850_edma0_map);
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
edma_pdev = platform_device_register_full(&da8xx_edma0_device);
if (IS_ERR(edma_pdev)) {
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
pr_warn("%s: Failed to register eDMA0\n", __func__);
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
return PTR_ERR(edma_pdev);
ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver Currently we have one device created to handle all (maximum 2) eDMAs in the system. With this change all eDMA instance will have it's own device/driver. This change is needed for further cleanups in the eDMA driver stack since the one device/driver to handle all eDMAs in the system was not flexible enough and prevents the upcoming work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:46 +09:00
}
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 21:43:13 +09:00
da850_edma1_pdata.slave_map = da850_edma1_map;
da850_edma1_pdata.slavecnt = ARRAY_SIZE(da850_edma1_map);
ARM: davinci: Use platform_device_register_full() to create pdev for eDMA Convert the eDMA platform device creation to use struct platform_device_info XXXXXX __initconst and platform_device_register_full() This will allow us to cleanly specify the dma_mask for the devices in an upcoming patch. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-10-14 20:42:51 +09:00
edma_pdev = platform_device_register_full(&da850_edma1_device);
ARM: davinci: Use PTR_ERR_OR_ZERO() Fix ptr_ret.cocci warnings: arch/arm/mach-davinci/devices-da8xx.c:255:8-14: WARNING: PTR_ERR_OR_ZERO can be used arch/arm/mach-davinci/devices-da8xx.c:300:8-14: WARNING: PTR_ERR_OR_ZERO can be used arch/arm/mach-davinci/dm646x.c:952:8-14: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-11-28 08:03:33 +09:00
return PTR_ERR_OR_ZERO(edma_pdev);
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 10:36:54 +09:00
}
static struct resource da8xx_i2c_resources0[] = {
{
.start = DA8XX_I2C0_BASE,
.end = DA8XX_I2C0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_I2CINT0),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_I2CINT0),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da8xx_i2c_device0 = {
.name = "i2c_davinci",
.id = 1,
.num_resources = ARRAY_SIZE(da8xx_i2c_resources0),
.resource = da8xx_i2c_resources0,
};
static struct resource da8xx_i2c_resources1[] = {
{
.start = DA8XX_I2C1_BASE,
.end = DA8XX_I2C1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_I2CINT1),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_I2CINT1),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da8xx_i2c_device1 = {
.name = "i2c_davinci",
.id = 2,
.num_resources = ARRAY_SIZE(da8xx_i2c_resources1),
.resource = da8xx_i2c_resources1,
};
int __init da8xx_register_i2c(int instance,
struct davinci_i2c_platform_data *pdata)
{
struct platform_device *pdev;
if (instance == 0)
pdev = &da8xx_i2c_device0;
else if (instance == 1)
pdev = &da8xx_i2c_device1;
else
return -EINVAL;
pdev->dev.platform_data = pdata;
return platform_device_register(pdev);
}
static struct resource da8xx_watchdog_resources[] = {
{
.start = DA8XX_WDOG_BASE,
.end = DA8XX_WDOG_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
};
ARM: davinci: da850 DT: add support for machine reboot Update the da8xx_restart() function to support machine reboot when booting using DT. Have the function search for the watchdog platform device instead of always using "da8xx_wdt_device" which is never registered in DT case. While at it, also make da8xx_wdt_device static since there is no need for it to be globally visible. Tested machine reboot with both DT and non-DT boot on DA850 EVM. Signed-off-by: Kumar, Anil <anilkumar.v@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-02-06 13:00:04 +09:00
static struct platform_device da8xx_wdt_device = {
watchdog: davinci: rename platform driver to davinci-wdt As we switch to use the watchdog core which permits more than one active watchdog in the system, rename platform driver to "davinci-wdt" to be identifiable. Acked-by: Wim Van Sebroeck <wim@iguana.be> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-11-27 22:31:53 +09:00
.name = "davinci-wdt",
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 10:36:54 +09:00
.id = -1,
.num_resources = ARRAY_SIZE(da8xx_watchdog_resources),
.resource = da8xx_watchdog_resources,
};
int __init da8xx_register_watchdog(void)
{
Davinci: watchdog reset separation across socs The earlier watchdog reset mechanism had a couple of limitations. First, it embedded a reference to "davinci_wdt_device" inside common code. This forced all derived platforms (da8xx and tnetv107x) to define such a device. This also would have caused problems in including multiple socs in a single build due to symbol redefinition. With this patch, davinci_watchdog_reset() now takes the platform device as an argument. The davinci_soc_info struct has been extended to include a reset function and a watchdog platform_device. arch_reset() then uses these elements to reset the system in a SoC specific fashion. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Tested-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-02 07:38:28 +09:00
return platform_device_register(&da8xx_wdt_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-04 10:36:54 +09:00
}
static struct resource da8xx_emac_resources[] = {
{
.start = DA8XX_EMAC_CPPI_PORT_BASE,
davinci: add mdio platform devices This patch adds mdio platform devices on SoCs that have the necessary hardware. Clock lookup entries (aliases) have also been added, so that the MDIO and EMAC drivers can independently enable/disable a shared underlying clock. Further, the EMAC MMR region has been split down into separate MDIO and EMAC regions. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Michael Williamson <michael.williamson@criticallink.com> Tested-by: Caglar Akyuz <caglarakyuz@gmail.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-09-15 23:11:22 +09:00
.end = DA8XX_EMAC_CPPI_PORT_BASE + SZ_16K - 1,
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 10:36:54 +09:00
.flags = IORESOURCE_MEM,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_RX_THRESH_PULSE),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_RX_THRESH_PULSE),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_RX_PULSE),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_RX_PULSE),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_TX_PULSE),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_TX_PULSE),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_MISC_PULSE),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_C0_MISC_PULSE),
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 10:36:54 +09:00
.flags = IORESOURCE_IRQ,
},
};
struct emac_platform_data da8xx_emac_pdata = {
.ctrl_reg_offset = DA8XX_EMAC_CTRL_REG_OFFSET,
.ctrl_mod_reg_offset = DA8XX_EMAC_MOD_REG_OFFSET,
.ctrl_ram_offset = DA8XX_EMAC_RAM_OFFSET,
.ctrl_ram_size = DA8XX_EMAC_CTRL_RAM_SIZE,
.version = EMAC_VERSION_2,
};
static struct platform_device da8xx_emac_device = {
.name = "davinci_emac",
.id = 1,
.dev = {
.platform_data = &da8xx_emac_pdata,
},
.num_resources = ARRAY_SIZE(da8xx_emac_resources),
.resource = da8xx_emac_resources,
};
davinci: add mdio platform devices This patch adds mdio platform devices on SoCs that have the necessary hardware. Clock lookup entries (aliases) have also been added, so that the MDIO and EMAC drivers can independently enable/disable a shared underlying clock. Further, the EMAC MMR region has been split down into separate MDIO and EMAC regions. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Michael Williamson <michael.williamson@criticallink.com> Tested-by: Caglar Akyuz <caglarakyuz@gmail.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-09-15 23:11:22 +09:00
static struct resource da8xx_mdio_resources[] = {
{
.start = DA8XX_EMAC_MDIO_BASE,
.end = DA8XX_EMAC_MDIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device da8xx_mdio_device = {
.name = "davinci_mdio",
.id = 0,
.num_resources = ARRAY_SIZE(da8xx_mdio_resources),
.resource = da8xx_mdio_resources,
};
davinci: Move DA8xx/OMAP-L13x emac register routine Some mcasp code was inserted between the emac resource setup and the related register routine that registers the emac. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-29 07:02:54 +09:00
int __init da8xx_register_emac(void)
{
davinci: add mdio platform devices This patch adds mdio platform devices on SoCs that have the necessary hardware. Clock lookup entries (aliases) have also been added, so that the MDIO and EMAC drivers can independently enable/disable a shared underlying clock. Further, the EMAC MMR region has been split down into separate MDIO and EMAC regions. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Michael Williamson <michael.williamson@criticallink.com> Tested-by: Caglar Akyuz <caglarakyuz@gmail.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-09-15 23:11:22 +09:00
int ret;
ret = platform_device_register(&da8xx_mdio_device);
if (ret < 0)
return ret;
ARM: davinci: fix clock lookup for mdio device This patch removes the clock alias for mdio device and adds a entry in clock lookup table, this entry can now be used by both DT and non-DT case. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-08-15 15:01:33 +09:00
return platform_device_register(&da8xx_emac_device);
davinci: Move DA8xx/OMAP-L13x emac register routine Some mcasp code was inserted between the emac resource setup and the related register routine that registers the emac. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-29 07:02:54 +09:00
}
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
static struct resource da830_mcasp1_resources[] = {
{
ARM: davinci: Fix McASP mem resource names The ASoC McASP driver looks for the mem resources by name "mpu" and "dat" regions. Change/add the needed name for the mem resources so the driver can pick the correct resource. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-11-13 23:48:17 +09:00
.name = "mpu",
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
.start = DAVINCI_DA830_MCASP1_REG_BASE,
.end = DAVINCI_DA830_MCASP1_REG_BASE + (SZ_1K * 12) - 1,
.flags = IORESOURCE_MEM,
},
/* TX event */
{
ARM: davinci: devices-da8xx: Add resource name for the McASP DMA request Add "tx" or "rx" as resource name for the DMA resources. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:25 +09:00
.name = "tx",
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
.start = DAVINCI_DA830_DMA_MCASP1_AXEVT,
.end = DAVINCI_DA830_DMA_MCASP1_AXEVT,
.flags = IORESOURCE_DMA,
},
/* RX event */
{
ARM: davinci: devices-da8xx: Add resource name for the McASP DMA request Add "tx" or "rx" as resource name for the DMA resources. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:25 +09:00
.name = "rx",
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
.start = DAVINCI_DA830_DMA_MCASP1_AREVT,
.end = DAVINCI_DA830_DMA_MCASP1_AREVT,
.flags = IORESOURCE_DMA,
},
ARM: davinci: devices-da8xx: Add interrupt resource to McASP structs On da8xx McASP TX/RX interrupt requests are combined. The interrupt can be used for error recovery. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:26 +09:00
{
.name = "common",
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_MCASPINT),
ARM: davinci: devices-da8xx: Add interrupt resource to McASP structs On da8xx McASP TX/RX interrupt requests are combined. The interrupt can be used for error recovery. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:26 +09:00
.flags = IORESOURCE_IRQ,
},
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
};
static struct platform_device da830_mcasp1_device = {
.name = "davinci-mcasp",
.id = 1,
.num_resources = ARRAY_SIZE(da830_mcasp1_resources),
.resource = da830_mcasp1_resources,
};
ARM: davinci: devices-da8xx: Add support for McASP2 on da830 da830 has three McASP blocks. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:28 +09:00
static struct resource da830_mcasp2_resources[] = {
{
.name = "mpu",
.start = DAVINCI_DA830_MCASP2_REG_BASE,
.end = DAVINCI_DA830_MCASP2_REG_BASE + (SZ_1K * 12) - 1,
.flags = IORESOURCE_MEM,
},
/* TX event */
{
.name = "tx",
.start = DAVINCI_DA830_DMA_MCASP2_AXEVT,
.end = DAVINCI_DA830_DMA_MCASP2_AXEVT,
.flags = IORESOURCE_DMA,
},
/* RX event */
{
.name = "rx",
.start = DAVINCI_DA830_DMA_MCASP2_AREVT,
.end = DAVINCI_DA830_DMA_MCASP2_AREVT,
.flags = IORESOURCE_DMA,
},
{
.name = "common",
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_MCASPINT),
ARM: davinci: devices-da8xx: Add support for McASP2 on da830 da830 has three McASP blocks. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:28 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da830_mcasp2_device = {
.name = "davinci-mcasp",
.id = 2,
.num_resources = ARRAY_SIZE(da830_mcasp2_resources),
.resource = da830_mcasp2_resources,
};
davinci: Audio support for DA850/OMAP-L138 EVM Define resources for McASP used on DA850/OMAP-L138 EVM, add platform device defintion and Pin Mux configurations. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:03:25 +09:00
static struct resource da850_mcasp_resources[] = {
{
ARM: davinci: Fix McASP mem resource names The ASoC McASP driver looks for the mem resources by name "mpu" and "dat" regions. Change/add the needed name for the mem resources so the driver can pick the correct resource. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-11-13 23:48:17 +09:00
.name = "mpu",
davinci: Audio support for DA850/OMAP-L138 EVM Define resources for McASP used on DA850/OMAP-L138 EVM, add platform device defintion and Pin Mux configurations. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:03:25 +09:00
.start = DAVINCI_DA8XX_MCASP0_REG_BASE,
.end = DAVINCI_DA8XX_MCASP0_REG_BASE + (SZ_1K * 12) - 1,
.flags = IORESOURCE_MEM,
},
/* TX event */
{
ARM: davinci: devices-da8xx: Add resource name for the McASP DMA request Add "tx" or "rx" as resource name for the DMA resources. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:25 +09:00
.name = "tx",
davinci: Audio support for DA850/OMAP-L138 EVM Define resources for McASP used on DA850/OMAP-L138 EVM, add platform device defintion and Pin Mux configurations. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:03:25 +09:00
.start = DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
.end = DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
.flags = IORESOURCE_DMA,
},
/* RX event */
{
ARM: davinci: devices-da8xx: Add resource name for the McASP DMA request Add "tx" or "rx" as resource name for the DMA resources. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:25 +09:00
.name = "rx",
davinci: Audio support for DA850/OMAP-L138 EVM Define resources for McASP used on DA850/OMAP-L138 EVM, add platform device defintion and Pin Mux configurations. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:03:25 +09:00
.start = DAVINCI_DA8XX_DMA_MCASP0_AREVT,
.end = DAVINCI_DA8XX_DMA_MCASP0_AREVT,
.flags = IORESOURCE_DMA,
},
ARM: davinci: devices-da8xx: Add interrupt resource to McASP structs On da8xx McASP TX/RX interrupt requests are combined. The interrupt can be used for error recovery. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:26 +09:00
{
.name = "common",
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_MCASPINT),
ARM: davinci: devices-da8xx: Add interrupt resource to McASP structs On da8xx McASP TX/RX interrupt requests are combined. The interrupt can be used for error recovery. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:26 +09:00
.flags = IORESOURCE_IRQ,
},
davinci: Audio support for DA850/OMAP-L138 EVM Define resources for McASP used on DA850/OMAP-L138 EVM, add platform device defintion and Pin Mux configurations. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:03:25 +09:00
};
static struct platform_device da850_mcasp_device = {
.name = "davinci-mcasp",
.id = 0,
.num_resources = ARRAY_SIZE(da850_mcasp_resources),
.resource = da850_mcasp_resources,
};
davinci: Change DA8xx/OMAP-L13x McASP registration routine name For consistency with existing code, change the name of da8xx_init_mcasp() to da8xx_register_mcasp(). Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-29 07:05:02 +09:00
void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
{
ARM: davinci: devices-da8xx: Clean up and correct the McASP device creation Both DA830 and DA850 has McASP0 module, so do not restrict the use of McASP0 for da850 only. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:27 +09:00
struct platform_device *pdev;
switch (id) {
case 0:
/* Valid for DA830/OMAP-L137 or DA850/OMAP-L138 */
pdev = &da850_mcasp_device;
break;
case 1:
/* Valid for DA830/OMAP-L137 only */
if (!cpu_is_davinci_da830())
return;
pdev = &da830_mcasp1_device;
break;
ARM: davinci: devices-da8xx: Add support for McASP2 on da830 da830 has three McASP blocks. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:28 +09:00
case 2:
/* Valid for DA830/OMAP-L137 only */
if (!cpu_is_davinci_da830())
return;
pdev = &da830_mcasp2_device;
break;
ARM: davinci: devices-da8xx: Clean up and correct the McASP device creation Both DA830 and DA850 has McASP0 module, so do not restrict the use of McASP0 for da850 only. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:27 +09:00
default:
return;
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
}
ARM: davinci: devices-da8xx: Clean up and correct the McASP device creation Both DA830 and DA850 has McASP0 module, so do not restrict the use of McASP0 for da850 only. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2015-03-12 17:06:27 +09:00
pdev->dev.platform_data = pdata;
platform_device_register(pdev);
davinci: Audio support for DA830 EVM Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform device defintion, initialization function. Additionally, this patch also adds version and FIFO related members to platform data structure. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-12 06:01:59 +09:00
}
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
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 22:53:08 +09:00
static struct resource da8xx_pruss_resources[] = {
{
.start = DA8XX_PRUSS_MEM_BASE,
.end = DA8XX_PRUSS_MEM_BASE + 0xFFFF,
.flags = IORESOURCE_MEM,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT0),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT0),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT1),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT1),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT2),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT2),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT3),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT3),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT4),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT4),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT5),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT5),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT6),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT6),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT7),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_EVTOUT7),
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 22:53:08 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct uio_pruss_pdata da8xx_uio_pruss_pdata = {
.pintc_base = 0x4000,
};
static struct platform_device da8xx_uio_pruss_dev = {
.name = "pruss_uio",
.id = -1,
.num_resources = ARRAY_SIZE(da8xx_pruss_resources),
.resource = da8xx_pruss_resources,
.dev = {
.coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &da8xx_uio_pruss_pdata,
}
};
int __init da8xx_register_uio_pruss(void)
{
da8xx_uio_pruss_pdata.sram_pool = sram_get_gen_pool();
return platform_device_register(&da8xx_uio_pruss_dev);
}
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
static struct lcd_ctrl_config lcd_cfg = {
da8xx-fb: cleanup LCDC configurations Configure below LCDC configurations to optimal values, also have an option configure these optional parameters for platform. 1) AC bias configuration: Required only for passive panels 2) Dma_burst_size: 3) FIFO_DMA_DELAY: 4) FIFO threshold: Does not apply for da830 LCDC. Patch is verified for 16bpp and 24bpp configurations on da830, da850 and am335x EVMs. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-10-16 13:53:16 +09:00
.panel_shade = COLOR_ACTIVE,
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
.bpp = 16,
};
davinci: Add support for Sharp LCD035Q3DG01 graphical LCD Add support for the Sharp LCD035Q3DG01 graphical LCD. This requires a minor interface change to da8xx_register_lcdc() so that the board code can pass in the platform_data which describes the lcd controller that's to be used. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:14:19 +09:00
struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata = {
.manu_name = "sharp",
.controller_data = &lcd_cfg,
.type = "Sharp_LCD035Q3DG01",
};
struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata = {
.manu_name = "sharp",
.controller_data = &lcd_cfg,
.type = "Sharp_LK043T1DG01",
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
};
static struct resource da8xx_lcdc_resources[] = {
[0] = { /* registers */
.start = DA8XX_LCD_CNTRL_BASE,
.end = DA8XX_LCD_CNTRL_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
[1] = { /* interrupt */
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_LCDINT),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_LCDINT),
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
.flags = IORESOURCE_IRQ,
},
};
davinci: Add support for Sharp LCD035Q3DG01 graphical LCD Add support for the Sharp LCD035Q3DG01 graphical LCD. This requires a minor interface change to da8xx_register_lcdc() so that the board code can pass in the platform_data which describes the lcd controller that's to be used. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:14:19 +09:00
static struct platform_device da8xx_lcdc_device = {
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
.name = "da8xx_lcdc",
.id = 0,
.num_resources = ARRAY_SIZE(da8xx_lcdc_resources),
.resource = da8xx_lcdc_resources,
};
davinci: Add support for Sharp LCD035Q3DG01 graphical LCD Add support for the Sharp LCD035Q3DG01 graphical LCD. This requires a minor interface change to da8xx_register_lcdc() so that the board code can pass in the platform_data which describes the lcd controller that's to be used. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:14:19 +09:00
int __init da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata)
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
{
davinci: Add support for Sharp LCD035Q3DG01 graphical LCD Add support for the Sharp LCD035Q3DG01 graphical LCD. This requires a minor interface change to da8xx_register_lcdc() so that the board code can pass in the platform_data which describes the lcd controller that's to be used. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:14:19 +09:00
da8xx_lcdc_device.dev.platform_data = pdata;
return platform_device_register(&da8xx_lcdc_device);
davinci: Add platform support for da850/omap-l138 GLCD This patch adds platform support for the graphic display (Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 03:33:14 +09:00
}
davinci: Add MMC/SD support for da850/omap-l138 There are two instances of MMC/SD on da850/omap-l138. Connector for the first instance is available on the EVM. This patch adds support for this instance. This patch also adds support for card detect and write protect switches on da850/omap-l138 EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 04:16:23 +09: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-18 14:18:59 +09:00
static struct resource da8xx_gpio_resources[] = {
{ /* registers */
.start = DA8XX_GPIO_BASE,
.end = DA8XX_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{ /* interrupt */
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO0),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO0),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO1),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO1),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO2),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO2),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO3),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO3),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO4),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO4),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO5),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO5),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO6),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO6),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO7),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO7),
ARM: davinci: da8xx: define gpio interrupts as separate resources Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 18:35:12 +09:00
.flags = IORESOURCE_IRQ,
},
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO8),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_GPIO8),
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-18 14:18:59 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da8xx_gpio_device = {
.name = "davinci_gpio",
.id = -1,
.num_resources = ARRAY_SIZE(da8xx_gpio_resources),
.resource = da8xx_gpio_resources,
};
int __init da8xx_register_gpio(void *pdata)
{
da8xx_gpio_device.dev.platform_data = pdata;
return platform_device_register(&da8xx_gpio_device);
}
davinci: Add MMC/SD support for da850/omap-l138 There are two instances of MMC/SD on da850/omap-l138. Connector for the first instance is available on the EVM. This patch adds support for this instance. This patch also adds support for card detect and write protect switches on da850/omap-l138 EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 04:16:23 +09:00
static struct resource da8xx_mmcsd0_resources[] = {
{ /* registers */
.start = DA8XX_MMCSD0_BASE,
.end = DA8XX_MMCSD0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{ /* interrupt */
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_MMCSDINT0),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_MMCSDINT0),
davinci: Add MMC/SD support for da850/omap-l138 There are two instances of MMC/SD on da850/omap-l138. Connector for the first instance is available on the EVM. This patch adds support for this instance. This patch also adds support for card detect and write protect switches on da850/omap-l138 EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 04:16:23 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da8xx_mmcsd0_device = {
ARM: davinci: mmc: derive version information from device name Remove specifying mmc controller IP version information via platform data, instead specify device name so that driver derives it from platform_device_id table. Also change the clock node name to match the changed dev_id. Tested on da850-evm to make sure driver loads without clk_get failures. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Chris Ball <cjb@laptop.org> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-28 22:11:59 +09:00
.name = "da830-mmc",
davinci: Add MMC/SD support for da850/omap-l138 There are two instances of MMC/SD on da850/omap-l138. Connector for the first instance is available on the EVM. This patch adds support for this instance. This patch also adds support for card detect and write protect switches on da850/omap-l138 EVM. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-14 04:16:23 +09:00
.id = 0,
.num_resources = ARRAY_SIZE(da8xx_mmcsd0_resources),
.resource = da8xx_mmcsd0_resources,
};
int __init da8xx_register_mmcsd0(struct davinci_mmc_config *config)
{
da8xx_mmcsd0_device.dev.platform_data = config;
return platform_device_register(&da8xx_mmcsd0_device);
}
davinci: Add RTC support for DA8xx/OMAP-L13x SoC's Add RTC support for the da830/omap-l137 and da850/omap-l138 SoC's by leveraging existing the rtc-omap driver. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:15:54 +09:00
DA850: Add MMCSD1 resources, platform device and convenience registration function Add resources, platform device and convenience registration function for DA850's second MMC/SD controller (MMCSD1). Signed-off-by: Juha Kuikka <juha.kuikka@elektrobit.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-08-27 04:40:47 +09:00
#ifdef CONFIG_ARCH_DAVINCI_DA850
static struct resource da850_mmcsd1_resources[] = {
{ /* registers */
.start = DA850_MMCSD1_BASE,
.end = DA850_MMCSD1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{ /* interrupt */
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA850_MMCSDINT0_1),
.end = DAVINCI_INTC_IRQ(IRQ_DA850_MMCSDINT0_1),
DA850: Add MMCSD1 resources, platform device and convenience registration function Add resources, platform device and convenience registration function for DA850's second MMC/SD controller (MMCSD1). Signed-off-by: Juha Kuikka <juha.kuikka@elektrobit.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-08-27 04:40:47 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da850_mmcsd1_device = {
ARM: davinci: mmc: derive version information from device name Remove specifying mmc controller IP version information via platform data, instead specify device name so that driver derives it from platform_device_id table. Also change the clock node name to match the changed dev_id. Tested on da850-evm to make sure driver loads without clk_get failures. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Chris Ball <cjb@laptop.org> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-28 22:11:59 +09:00
.name = "da830-mmc",
DA850: Add MMCSD1 resources, platform device and convenience registration function Add resources, platform device and convenience registration function for DA850's second MMC/SD controller (MMCSD1). Signed-off-by: Juha Kuikka <juha.kuikka@elektrobit.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-08-27 04:40:47 +09:00
.id = 1,
.num_resources = ARRAY_SIZE(da850_mmcsd1_resources),
.resource = da850_mmcsd1_resources,
};
int __init da850_register_mmcsd1(struct davinci_mmc_config *config)
{
da850_mmcsd1_device.dev.platform_data = config;
return platform_device_register(&da850_mmcsd1_device);
}
#endif
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
static struct resource da8xx_rproc_resources[] = {
{ /* DSP boot address */
ARM: davinci: da8xx: Add names to DSP IOMEM resources Add names to the IOMEM resources for the DSP device present on DA8xx SoCs. This will facilitate the driver to use the names and be agnostic of the resource order, and facilitate scalable DT support in follow-up patches. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-05-17 07:13:46 +09:00
.name = "host1cfg",
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
.start = DA8XX_SYSCFG0_BASE + DA8XX_HOST1CFG_REG,
.end = DA8XX_SYSCFG0_BASE + DA8XX_HOST1CFG_REG + 3,
.flags = IORESOURCE_MEM,
},
{ /* DSP interrupt registers */
ARM: davinci: da8xx: Add names to DSP IOMEM resources Add names to the IOMEM resources for the DSP device present on DA8xx SoCs. This will facilitate the driver to use the names and be agnostic of the resource order, and facilitate scalable DT support in follow-up patches. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-05-17 07:13:46 +09:00
.name = "chipsig",
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
.start = DA8XX_SYSCFG0_BASE + DA8XX_CHIPSIG_REG,
.end = DA8XX_SYSCFG0_BASE + DA8XX_CHIPSIG_REG + 7,
.flags = IORESOURCE_MEM,
},
ARM: davinci: da8xx: Add DSP internal RAM memories as IOMEM resources The DSP subsystem on DA8xx has various internal RAM memories that can accessed from the ARM side. These memories can be configured to be used as either RAM or Cache. Add these memories as IOMEM resources to the DSP device so that the driver can support loading of images into internal memories. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-05-17 07:13:47 +09:00
{ /* DSP L2 RAM */
.name = "l2sram",
.start = DA8XX_DSP_L2_RAM_BASE,
.end = DA8XX_DSP_L2_RAM_BASE + SZ_256K - 1,
.flags = IORESOURCE_MEM,
},
{ /* DSP L1P RAM */
.name = "l1pram",
.start = DA8XX_DSP_L1P_RAM_BASE,
.end = DA8XX_DSP_L1P_RAM_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
{ /* DSP L1D RAM */
.name = "l1dram",
.start = DA8XX_DSP_L1D_RAM_BASE,
.end = DA8XX_DSP_L1D_RAM_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
{ /* dsp irq */
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_CHIPINT0),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_CHIPINT0),
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da8xx_dsp = {
.name = "davinci-rproc",
.dev = {
.coherent_dma_mask = DMA_BIT_MASK(32),
},
.num_resources = ARRAY_SIZE(da8xx_rproc_resources),
.resource = da8xx_rproc_resources,
};
ARM: davinci: da8xx: Create DSP device only when assigned memory The DSP device on Davinci platforms does not have an MMU and requires specific DDR memory to boot. This memory is reserved using the rproc_mem kernel boot parameter and is assigned to the device on non-DT boots. The remoteproc core uses the DMA API and so will fall back to assigning random memory if this memory is not assigned to the device, but the DSP remote processor boot will not be successful in such cases. So, check that memory has been reserved and assigned to the device specifically before even creating the DSP device. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-05-17 07:13:45 +09:00
static bool rproc_mem_inited __initdata;
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
#if IS_ENABLED(CONFIG_DA8XX_REMOTEPROC)
static phys_addr_t rproc_base __initdata;
static unsigned long rproc_size __initdata;
static int __init early_rproc_mem(char *p)
{
char *endp;
if (p == NULL)
return 0;
rproc_size = memparse(p, &endp);
if (*endp == '@')
rproc_base = memparse(endp + 1, NULL);
return 0;
}
early_param("rproc_mem", early_rproc_mem);
void __init da8xx_rproc_reserve_cma(void)
{
int ret;
if (!rproc_base || !rproc_size) {
pr_err("%s: 'rproc_mem=nn@address' badly specified\n"
" 'nn' and 'address' must both be non-zero\n",
__func__);
return;
}
pr_info("%s: reserving 0x%lx @ 0x%lx...\n",
__func__, rproc_size, (unsigned long)rproc_base);
ret = dma_declare_contiguous(&da8xx_dsp.dev, rproc_size, rproc_base, 0);
if (ret)
pr_err("%s: dma_declare_contiguous failed %d\n", __func__, ret);
ARM: davinci: da8xx: Create DSP device only when assigned memory The DSP device on Davinci platforms does not have an MMU and requires specific DDR memory to boot. This memory is reserved using the rproc_mem kernel boot parameter and is assigned to the device on non-DT boots. The remoteproc core uses the DMA API and so will fall back to assigning random memory if this memory is not assigned to the device, but the DSP remote processor boot will not be successful in such cases. So, check that memory has been reserved and assigned to the device specifically before even creating the DSP device. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-05-17 07:13:45 +09:00
else
rproc_mem_inited = true;
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
}
#else
void __init da8xx_rproc_reserve_cma(void)
{
}
#endif
int __init da8xx_register_rproc(void)
{
int ret;
ARM: davinci: da8xx: Create DSP device only when assigned memory The DSP device on Davinci platforms does not have an MMU and requires specific DDR memory to boot. This memory is reserved using the rproc_mem kernel boot parameter and is assigned to the device on non-DT boots. The remoteproc core uses the DMA API and so will fall back to assigning random memory if this memory is not assigned to the device, but the DSP remote processor boot will not be successful in such cases. So, check that memory has been reserved and assigned to the device specifically before even creating the DSP device. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-05-17 07:13:45 +09:00
if (!rproc_mem_inited) {
pr_warn("%s: memory not reserved for DSP, not registering DSP device\n",
__func__);
return -ENOMEM;
}
ARM: davinci: da8xx: add remoteproc support Add remoteproc platform device for controlling the DSP on da8xx. The patch uses CMA-based reservation of physical memory block for DSP use. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. Signed-off-by: Robert Tivy <rtivy@ti.com> [nsekhar@ti.com: edit commit message for readability and style improvements] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-29 10:41:46 +09:00
ret = platform_device_register(&da8xx_dsp);
if (ret)
pr_err("%s: can't register DSP device: %d\n", __func__, ret);
return ret;
};
davinci: Add RTC support for DA8xx/OMAP-L13x SoC's Add RTC support for the da830/omap-l137 and da850/omap-l138 SoC's by leveraging existing the rtc-omap driver. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:15:54 +09:00
static struct resource da8xx_rtc_resources[] = {
{
.start = DA8XX_RTC_BASE,
.end = DA8XX_RTC_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{ /* timer irq */
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_RTC),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_RTC),
davinci: Add RTC support for DA8xx/OMAP-L13x SoC's Add RTC support for the da830/omap-l137 and da850/omap-l138 SoC's by leveraging existing the rtc-omap driver. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:15:54 +09:00
.flags = IORESOURCE_IRQ,
},
{ /* alarm irq */
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_RTC),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_RTC),
davinci: Add RTC support for DA8xx/OMAP-L13x SoC's Add RTC support for the da830/omap-l137 and da850/omap-l138 SoC's by leveraging existing the rtc-omap driver. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:15:54 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device da8xx_rtc_device = {
ARM: davinci: remove rtc kicker release rtc-omap driver is now capable of handling kicker mechanism, hence remove kicker handling at platform level, instead provide proper device name so that driver can handle kicker mechanism by itself Signed-off-by: Afzal Mohammed <afzal@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Daniel Mack <zonque@gmail.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-18 09:02:13 +09:00
.name = "da830-rtc",
davinci: Add RTC support for DA8xx/OMAP-L13x SoC's Add RTC support for the da830/omap-l137 and da850/omap-l138 SoC's by leveraging existing the rtc-omap driver. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:15:54 +09:00
.id = -1,
.num_resources = ARRAY_SIZE(da8xx_rtc_resources),
.resource = da8xx_rtc_resources,
};
int da8xx_register_rtc(void)
{
ARM: davinci: da8xx: remove hard coding of rtc device wakeup Since now rtc-omap driver itself calls deice_init_wakeup(dev, true), duplicate call from the rtc device registration can be removed. This is basically a partial revert of the prev commit commit 75c99bb0006ee065b4e2995078d779418b0fab54 Author: Sekhar Nori <nsekhar@ti.com> davinci: da8xx/omap-l1: mark RTC as a wakeup source Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com> Acked-by: Kevin Hilman <khilman@linaro.org> Acked-by: Sekhar Nori <nsekhar@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-07-03 17:47:03 +09:00
return platform_device_register(&da8xx_rtc_device);
davinci: Add RTC support for DA8xx/OMAP-L13x SoC's Add RTC support for the da830/omap-l137 and da850/omap-l138 SoC's by leveraging existing the rtc-omap driver. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 10:15:54 +09:00
}
davinci: DA8XX/OMAP-L1XX: add support for cpuidle driver register This patch provides a function to help register cpuidle driver on da8xx/omap-l1xx platforms. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-10-22 18:42:14 +09: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 20:51:37 +09: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 09:23:20 +09: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 20:51:37 +09:00
return da8xx_ddr2_ctlr_base;
}
davinci: DA8XX/OMAP-L1XX: add support for cpuidle driver register This patch provides a function to help register cpuidle driver on da8xx/omap-l1xx platforms. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-10-22 18:42:14 +09:00
static struct resource da8xx_cpuidle_resources[] = {
{
.start = DA8XX_DDR2_CTL_BASE,
.end = DA8XX_DDR2_CTL_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
};
/* DA8XX devices support DDR2 power down */
static struct davinci_cpuidle_config da8xx_cpuidle_pdata = {
.ddr2_pdown = 1,
};
static struct platform_device da8xx_cpuidle_device = {
.name = "cpuidle-davinci",
.num_resources = ARRAY_SIZE(da8xx_cpuidle_resources),
.resource = da8xx_cpuidle_resources,
.dev = {
.platform_data = &da8xx_cpuidle_pdata,
},
};
int __init da8xx_register_cpuidle(void)
{
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 20:51:37 +09:00
da8xx_cpuidle_pdata.ddr2_ctlr_base = da8xx_get_mem_ctlr();
davinci: DA8XX/OMAP-L1XX: add support for cpuidle driver register This patch provides a function to help register cpuidle driver on da8xx/omap-l1xx platforms. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-10-22 18:42:14 +09:00
return platform_device_register(&da8xx_cpuidle_device);
}
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
static struct resource da8xx_spi0_resources[] = {
[0] = {
.start = DA8XX_SPI0_BASE,
.end = DA8XX_SPI0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_SPINT0),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_SPINT0),
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
.flags = IORESOURCE_IRQ,
},
};
static struct resource da8xx_spi1_resources[] = {
[0] = {
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-07 02:17:21 +09:00
.start = DA830_SPI1_BASE,
.end = DA830_SPI1_BASE + SZ_4K - 1,
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
.flags = IORESOURCE_MEM,
},
[1] = {
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA8XX_SPINT1),
.end = DAVINCI_INTC_IRQ(IRQ_DA8XX_SPINT1),
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
.flags = IORESOURCE_IRQ,
},
};
ARM: davinci: da8xx_register_spi() should not register SPI board info Without this patch, da8xx_register_spi() registers the SPI board info, the SPI controller, and sets its number of chipselect to the size of the static spi_board_info array. This is bad because a SPI board info may declare devices for different SPI buses, and because other code can also call spi_register_board_info() (e.g. a daughter board might provide additional SPI devices). This patch removes the spi_register_board_info() call from da8xx_register_spi(), renames this last one to da8xx_register_spi_bus() to be more explicit, takes the number of chipselect as a function parameter, and updates the impacted board-da8{3,5}0-evm.c, and board-mityomapl138.c files accordingly. It also sets the SPI platform data static, as it doesn't need to be exported. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> [nsekhar@ti.com: fixed conflicts with v3.7-rc7, converted to use pr_warn(), modified print messages to use __func__] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-09-11 09:29:13 +09:00
static struct davinci_spi_platform_data da8xx_spi_pdata[] = {
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
[0] = {
.version = SPI_VERSION_2,
.intr_line = 1,
.dma_event_q = EVENTQ_0,
ARM: davinci: Set proper SPI prescale limit value SPI Davinci driver has been updated to allow SOCs to specify their minimum prescale value. Update the various SOCs board files that use this driver with their proper prescaler limit. Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12 22:26:19 +09:00
.prescaler_limit = 2,
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
},
[1] = {
.version = SPI_VERSION_2,
.intr_line = 1,
.dma_event_q = EVENTQ_0,
ARM: davinci: Set proper SPI prescale limit value SPI Davinci driver has been updated to allow SOCs to specify their minimum prescale value. Update the various SOCs board files that use this driver with their proper prescaler limit. Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12 22:26:19 +09:00
.prescaler_limit = 2,
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
},
};
static struct platform_device da8xx_spi_device[] = {
[0] = {
.name = "spi_davinci",
.id = 0,
.num_resources = ARRAY_SIZE(da8xx_spi0_resources),
.resource = da8xx_spi0_resources,
.dev = {
.platform_data = &da8xx_spi_pdata[0],
},
},
[1] = {
.name = "spi_davinci",
.id = 1,
.num_resources = ARRAY_SIZE(da8xx_spi1_resources),
.resource = da8xx_spi1_resources,
.dev = {
.platform_data = &da8xx_spi_pdata[1],
},
},
};
ARM: davinci: da8xx_register_spi() should not register SPI board info Without this patch, da8xx_register_spi() registers the SPI board info, the SPI controller, and sets its number of chipselect to the size of the static spi_board_info array. This is bad because a SPI board info may declare devices for different SPI buses, and because other code can also call spi_register_board_info() (e.g. a daughter board might provide additional SPI devices). This patch removes the spi_register_board_info() call from da8xx_register_spi(), renames this last one to da8xx_register_spi_bus() to be more explicit, takes the number of chipselect as a function parameter, and updates the impacted board-da8{3,5}0-evm.c, and board-mityomapl138.c files accordingly. It also sets the SPI platform data static, as it doesn't need to be exported. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> [nsekhar@ti.com: fixed conflicts with v3.7-rc7, converted to use pr_warn(), modified print messages to use __func__] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-09-11 09:29:13 +09:00
int __init da8xx_register_spi_bus(int instance, unsigned num_chipselect)
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
{
if (instance < 0 || instance > 1)
return -EINVAL;
ARM: davinci: da8xx_register_spi() should not register SPI board info Without this patch, da8xx_register_spi() registers the SPI board info, the SPI controller, and sets its number of chipselect to the size of the static spi_board_info array. This is bad because a SPI board info may declare devices for different SPI buses, and because other code can also call spi_register_board_info() (e.g. a daughter board might provide additional SPI devices). This patch removes the spi_register_board_info() call from da8xx_register_spi(), renames this last one to da8xx_register_spi_bus() to be more explicit, takes the number of chipselect as a function parameter, and updates the impacted board-da8{3,5}0-evm.c, and board-mityomapl138.c files accordingly. It also sets the SPI platform data static, as it doesn't need to be exported. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> [nsekhar@ti.com: fixed conflicts with v3.7-rc7, converted to use pr_warn(), modified print messages to use __func__] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-09-11 09:29:13 +09:00
da8xx_spi_pdata[instance].num_chipselect = num_chipselect;
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
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-07 02:17:21 +09:00
if (instance == 1 && cpu_is_davinci_da850()) {
da8xx_spi1_resources[0].start = DA850_SPI1_BASE;
da8xx_spi1_resources[0].end = DA850_SPI1_BASE + SZ_4K - 1;
}
davinci: da8xx: add spi resources and registration routine Add IO resource structures, platform data, and a registration routine in order to support spi device on DA850/OMAP-L138/AM18x and DA830/OMAP-L137/AM17x platforms. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-24 13:48:28 +09:00
return platform_device_register(&da8xx_spi_device[instance]);
}
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 15:01:23 +09:00
#ifdef CONFIG_ARCH_DAVINCI_DA850
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-19 01:48:14 +09:00
int __init da850_register_sata_refclk(int rate)
{
struct clk *clk;
clk = clk_register_fixed_rate(NULL, "sata_refclk", NULL, 0, rate);
if (IS_ERR(clk))
return PTR_ERR(clk);
return clk_register_clkdev(clk, "refclk", "ahci_da850");
}
ARM: davinci: da850: model the SATA refclk Register a fixed rate clock modelling the external SATA oscillator for da850 (both DT and board file mode). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-01-30 19:02:03 +09:00
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 15:01:23 +09:00
static struct resource da850_sata_resources[] = {
{
.start = DA850_SATA_BASE,
.end = DA850_SATA_BASE + 0x1fff,
.flags = IORESOURCE_MEM,
},
ARM: davinci: da850: update SATA AHCI support Update SATA AHCI support to make use of the new ahci_da850 host driver (instead of the generic ahci_platform one) and remove deprecated ahci_platform_data code. Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-26 03:51:41 +09:00
{
.start = DA8XX_SYSCFG1_BASE + DA8XX_PWRDN_REG,
.end = DA8XX_SYSCFG1_BASE + DA8XX_PWRDN_REG + 0x3,
.flags = IORESOURCE_MEM,
},
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 15:01:23 +09:00
{
ARM: davinci: wrap HW interrupt numbers with a macro Once we select SPARSE_IRQ, the interrupt numbers defined in mach/irqs.h will only signify the hardware interrupt offsets, not the interrupt numbers seen by linux. Introduce a wrapper macro that translates the hwirq number to virtual numbers. For now it's just a dummy. Use that macro when specifying the interrupts in resources for platform devices. 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 23:52:01 +09:00
.start = DAVINCI_INTC_IRQ(IRQ_DA850_SATAINT),
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 15:01:23 +09:00
.flags = IORESOURCE_IRQ,
},
};
static u64 da850_sata_dmamask = DMA_BIT_MASK(32);
static struct platform_device da850_sata_device = {
ARM: davinci: da850: update SATA AHCI support Update SATA AHCI support to make use of the new ahci_da850 host driver (instead of the generic ahci_platform one) and remove deprecated ahci_platform_data code. Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-26 03:51:41 +09:00
.name = "ahci_da850",
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 15:01:23 +09:00
.id = -1,
.dev = {
.dma_mask = &da850_sata_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
.num_resources = ARRAY_SIZE(da850_sata_resources),
.resource = da850_sata_resources,
};
int __init da850_register_sata(unsigned long refclkpn)
{
ARM: davinci: da850: model the SATA refclk Register a fixed rate clock modelling the external SATA oscillator for da850 (both DT and board file mode). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-01-30 19:02:03 +09:00
int ret;
ret = da850_register_sata_refclk(refclkpn);
if (ret)
return ret;
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 15:01:23 +09:00
return platform_device_register(&da850_sata_device);
}
#endif
ARM: davinci: da8xx: Add CFGCHIP syscon platform device The CFGCHIP registers are used by a number of devices, so use a syscon device to share them. The first consumer of this will be the phy-da8xx-usb driver. Add the syscon device and register it. Signed-off-by: David Lechner <david@lechnology.com> [nsekhar@ti.com: minor commit message fixes] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-10-26 12:06:48 +09:00
ARM: da8xx: use platform data for CFGCHIP syscon regmap This converts from using a platform device for the CFGCHIP syscon regmap to using platform data to pass the regmap to consumers. A lazy getter function is used so that the regmap will only be created if it is actually used. This function will also be used in the clock init when we convert to the common clock framework. The USB PHY driver is currently the only consumer. This driver is updated to use platform data to get the CFGCHIP regmap instead of syscon_regmap_lookup_by_pdevname(). Signed-off-by: David Lechner <david@lechnology.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-02-18 12:22:24 +09:00
static struct regmap *da8xx_cfgchip;
ARM: davinci: da8xx: Add CFGCHIP syscon platform device The CFGCHIP registers are used by a number of devices, so use a syscon device to share them. The first consumer of this will be the phy-da8xx-usb driver. Add the syscon device and register it. Signed-off-by: David Lechner <david@lechnology.com> [nsekhar@ti.com: minor commit message fixes] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-10-26 12:06:48 +09:00
ARM: da8xx: use platform data for CFGCHIP syscon regmap This converts from using a platform device for the CFGCHIP syscon regmap to using platform data to pass the regmap to consumers. A lazy getter function is used so that the regmap will only be created if it is actually used. This function will also be used in the clock init when we convert to the common clock framework. The USB PHY driver is currently the only consumer. This driver is updated to use platform data to get the CFGCHIP regmap instead of syscon_regmap_lookup_by_pdevname(). Signed-off-by: David Lechner <david@lechnology.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-02-18 12:22:24 +09:00
static const struct regmap_config da8xx_cfgchip_config __initconst = {
ARM: davinci: da8xx: simplify CFGCHIP regmap_config Since commit 8253bb3f8255 ("regmap: potentially duplicate the name string stored in regmap"), the name field of struct regmap_config is copied in __regmap_init(), so we no longer need to worry about keeping our own copy of the name. Just use a string literal in the initialization of da8xx_cfgchip_config instead of creating a separate variable for the name. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-03-16 03:13:41 +09:00
.name = "cfgchip",
ARM: da8xx: use platform data for CFGCHIP syscon regmap This converts from using a platform device for the CFGCHIP syscon regmap to using platform data to pass the regmap to consumers. A lazy getter function is used so that the regmap will only be created if it is actually used. This function will also be used in the clock init when we convert to the common clock framework. The USB PHY driver is currently the only consumer. This driver is updated to use platform data to get the CFGCHIP regmap instead of syscon_regmap_lookup_by_pdevname(). Signed-off-by: David Lechner <david@lechnology.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-02-18 12:22:24 +09:00
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
.max_register = DA8XX_CFGCHIP4_REG - DA8XX_CFGCHIP0_REG,
ARM: davinci: da8xx: Add CFGCHIP syscon platform device The CFGCHIP registers are used by a number of devices, so use a syscon device to share them. The first consumer of this will be the phy-da8xx-usb driver. Add the syscon device and register it. Signed-off-by: David Lechner <david@lechnology.com> [nsekhar@ti.com: minor commit message fixes] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-10-26 12:06:48 +09:00
};
ARM: da8xx: use platform data for CFGCHIP syscon regmap This converts from using a platform device for the CFGCHIP syscon regmap to using platform data to pass the regmap to consumers. A lazy getter function is used so that the regmap will only be created if it is actually used. This function will also be used in the clock init when we convert to the common clock framework. The USB PHY driver is currently the only consumer. This driver is updated to use platform data to get the CFGCHIP regmap instead of syscon_regmap_lookup_by_pdevname(). Signed-off-by: David Lechner <david@lechnology.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-02-18 12:22:24 +09:00
/**
* da8xx_get_cfgchip - Lazy gets CFGCHIP as regmap
*
* This is for use on non-DT boards only. For DT boards, use
* syscon_regmap_lookup_by_compatible("ti,da830-cfgchip")
*
* Returns: Pointer to the CFGCHIP regmap or negative error code.
*/
struct regmap * __init da8xx_get_cfgchip(void)
ARM: davinci: da8xx: Add CFGCHIP syscon platform device The CFGCHIP registers are used by a number of devices, so use a syscon device to share them. The first consumer of this will be the phy-da8xx-usb driver. Add the syscon device and register it. Signed-off-by: David Lechner <david@lechnology.com> [nsekhar@ti.com: minor commit message fixes] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-10-26 12:06:48 +09:00
{
ARM: da8xx: use platform data for CFGCHIP syscon regmap This converts from using a platform device for the CFGCHIP syscon regmap to using platform data to pass the regmap to consumers. A lazy getter function is used so that the regmap will only be created if it is actually used. This function will also be used in the clock init when we convert to the common clock framework. The USB PHY driver is currently the only consumer. This driver is updated to use platform data to get the CFGCHIP regmap instead of syscon_regmap_lookup_by_pdevname(). Signed-off-by: David Lechner <david@lechnology.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-02-18 12:22:24 +09:00
if (IS_ERR_OR_NULL(da8xx_cfgchip))
da8xx_cfgchip = regmap_init_mmio(NULL,
DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP0_REG),
&da8xx_cfgchip_config);
return da8xx_cfgchip;
ARM: davinci: da8xx: Add CFGCHIP syscon platform device The CFGCHIP registers are used by a number of devices, so use a syscon device to share them. The first consumer of this will be the phy-da8xx-usb driver. Add the syscon device and register it. Signed-off-by: David Lechner <david@lechnology.com> [nsekhar@ti.com: minor commit message fixes] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-10-26 12:06:48 +09:00
}
Reference in New Issue Copy Permalink