summaryrefslogtreecommitdiff
path: root/arch/arm/mach-davinci/common.c
AgeCommit message (Collapse)Author
2016-11-16ARM: davinci: PM: rework init, remove platform deviceKevin Hilman
Remove fake platform device used for PM init. Move pdata values which are common across all current platforms into pm.c. Also, since PM is only used on da8xx, remove davinci_pm_init() from common init code, and only use in da850/omapl138 board files that are currently creating the fake platform_device. Suggested-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> [nsekhar@ti.com: subject line adjustment] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-05-18Merge tag 'armsoc-soc' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC platform updates from Arnd Bergmann: "We get support for three new 32-bit SoC platforms this time. The amount of changes in arch/arm for any of them is miniscule, as all the interesting code is in device driver subsystems (irqchip, clk, pinctrl, ...) these days. I'm listing them here, as the addition of the Kconfig statement is the main relevant milestone for a new platform. In each case, some drivers are are shared with existing platforms, while other drivers are added for v4.7 as well, or come in a later release. - The Aspeed platform is probably the most interesting one, this is what most whitebox servers use as their baseboard management controller. We get support for the very common ast2400 and ast2500 SoCs. The OpenBMC project focuses on this chip, and the LWN article about their ELC 2016 presentation at https://lwn.net/Articles/683320/ triggered the submission, but the code comes from IBM's OpenPOWER team rather than the team at Facebook. There are still a lot more drivers that need to get added over time, and I hope both teams can work together on that. - OXNAS is an old platform for Network Attached Storage devices from Oxford Semiconductor. There are models with ARM10 (!) and ARM11MPCore cores, but for now, we only support the original ARM9 based versions. The product lineup was subsequently part of PLX, Avago and now the new Broadcom Ltd. https://wiki.openwrt.org/doc/hardware/soc/soc.oxnas has some more information. - V2M-MPS2 is a prototyping platform from ARM for their Cortex-M cores and is related to the existing Realview / Versatile Express lineup, but without MMU. We now support various NOMMU platforms, so adding a new one is fairly straightforward. http://infocenter.arm.com/help/topic/com.arm.doc.100112_0100_03_en/ has detailed information about the platform. Other noteworthy updates: - Work on LPC32xx has resumed, and Vladimir Zapolskiy and Sylvain Lemieux are now maintaining the platform. This is an older ARM9 based platform from NXP (not Freescale), but it remains in use in embedded markets. - Kevin Hilman is now co-maintaining the Amlogic Meson platform for both 32-bit and 64-bit ARM, and started contributing some patches. - As is often the case, work on the OMAP platforms makes up the bulk of the actual SoC code changes in arch/arm, but there isn't a lot of that either" * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (42 commits) MAINTAINERS: ARM/Amlogic: add co-maintainer, misc. updates MAINTAINERS: add ARM/NXP LPC32XX SoC specific drivers to the section MAINTAINERS: add new maintainers of NXP LPC32xx SoC MAINTAINERS: move ARM/NXP LPC32xx record to ARM section arm: Add Aspeed machine ARM: lpc32xx: remove duplicate const on lpc32xx_auxdata_lookup ARM: lpc32xx: remove leftovers of legacy clock source and provider drivers ARM: lpc32xx: remove reboot header file ARM: dove: Remove CLK_IS_ROOT ARM: orion5x: Remove CLK_IS_ROOT ARM: mv78xx0: Remove CLK_IS_ROOT ARM: davinci: da850: use clk->set_parent for async3 ARM: davinci: Move clock init after ioremap. MAINTAINERS: Update ARM Versatile Express platform entry ARM: vexpress/mps2: introduce MPS2 platform MAINTAINERS: add maintainer entry for ARM/OXNAS platform ARM: Add new mach-oxnas irqchip: versatile-fpga: add new compatible for OX810SE SoC ARM: uniphier: correct the call order of of_node_put() MAINTAINERS: fix stale TI DaVinci entries ...
2016-04-29ARM: davinci: only use NVMEM when availableArnd Bergmann
The davinci platform contains code that calls into the nvmem subsystem, but that might be a loadable module, causing a link error: arch/arm/mach-davinci/built-in.o: In function `davinci_get_mac_addr': :(.text+0x1088): undefined reference to `nvmem_device_read' arch/arm/mach-davinci/built-in.o: In function `read_factory_config': :(.text+0x214c): undefined reference to `nvmem_device_read' Also, when NVMEM is completely disabled, the functions fail with nonobvious error messages. This ensures we only call the API functions when the code is actually reachable from the board file, and otherwise prints a unique log message. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: bec3c11bad0e ("misc: at24: replace memory_accessor with nvmem_device_read") Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2016-04-27ARM: davinci: Move clock init after ioremap.David Lechner
Some clocks (such as the USB PHY clocks in DA8xx) will need to use iomem. The davinci_common_init() function must be called before the ioremap, so the clock init is now split out as separate function. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-03-01misc: at24: replace memory_accessor with nvmem_device_readAndrew Lunn
Now that the AT24 uses the NVMEM framework, replace the memory_accessor in the setup() callback with nvmem API calls. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-13ARM: davinci: remove obsoleted init_consistent_dma_size()Marek Szyprowski
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> CC: Sekhar Nori <nsekhar@ti.com> CC: Kevin Hilman <khilman@ti.com>
2012-05-05ARM: davinci: use machine specific hook for late initShawn Guo
Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Sekhar Nori <nsekhar@ti.com>
2012-01-05ARM: 7190/1: restart: davinci: use new restart hookSekhar Nori
Rather than using DaVinci specific davinci_soc_info based restart hook, use the restart hook available in the machine descriptor instead. Tested on DM365 and AM18x EVMs. v2: Changed to use restart hook in machine descriptor per Russell's comment. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-08-22ARM: mach-davinci: Setup consistent dma size at boot timeJon Medhurst
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk> CC: Sekhar Nori <nsekhar@ti.com> CC: Kevin Hilman <khilman@ti.com>
2010-05-13Davinci: aintc/cpintc - use ioremap()Cyril Chemparathy
This patch implements the following: - interrupt initialization uses ioremap() instead of passing a virtual address via davinci_soc_info. - machine definitions directly point to cp_intc_init() or davinci_irq_init() - davinci_intc_type and davinci_intc_base now get initialized in controller specific init functions instead of davinci_common_init() - minor fix in davinci_irq_init() to use intc_irq_num instead of DAVINCI_N_AINTC_IRQ Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-13Davinci: jtag_id - use ioremap()Cyril Chemparathy
This patch replaces the jtag id base info in davinci_soc_info with a physical address which is then ioremap()ed within common code. This patch (in combination with a similar change for PSC) will allow us to eliminate the SYSCFG nastiness in DA8xx code. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-06Davinci: watchdog reset separation across socsCyril Chemparathy
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-02-04TI Davinci EMAC : Re-use driver for other platforms.Sriramakrishnan
The davinci EMAC peripheral is also available on other TI platforms -notably TI AM3517 SoC. This patch modifies the config option and the platform structure header files so that the driver can be reused on non-davinci platforms as well. Signed-off-by: Sriramakrishnan <srk@ti.com> Acked-by: Chaithrika U S <chaithrika@ti.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-25davinci: make it easier to identify SoC init failuresSekhar Nori
This patch makes it easier to identify SoC init failures by panicing when SoC init fails. Without successful SoC init, the kernel eventually fails when attempt is made to access the clocks. Also, an error is printed when JTAG ID match fails to make it easier to identify failures due to SoC rev changes. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Integrate cp_intc support into low-level irq codeMark A. Greer
Integrate the Common Platform Interrupt Controller (cp_intc) support into the low-level irq handling for davinci and similar platforms. Do it such that support for cp_intc and the original aintc can coexist in the same kernel binary. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Factor out emac mac address handlingMark A. Greer
Factor out the code to extract that mac address from i2c eeprom. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Move interrupt ctlr info to SoC infrastructureMark A. Greer
Use the SoC infrastructure to hold the interrupt controller information (i.e., base address, default priorities, interrupt controller type, and the number of IRQs). The interrupt controller base, although initially put in the soc_info structure's intc_base field, is eventually put in the global 'davinci_intc_base' so the low-level interrupt code can access it without a dereference. These changes enable the SoC default irq priorities to be put in the SoC-specific files, and the interrupt controller to be at any base address. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Add clock init call to common init routineMark A. Greer
All of the davinci SoCs need to call davinci_clk_init() so put the call in the common init routine. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Support JTAG ID register at any addressMark A. Greer
The Davinci cpu_is_davinci_*() macros use the SoC part number and variant retrieved from the JTAG ID register to determine the type of cpu that the kernel is running on. Currently, the code to read the JTAG ID register assumes that the register is always at the same base address. This isn't true on some newer SoCs. To solve this, have the SoC-specific code set the JTAG ID register base address in soc_info structure and add a 'cpu_id' member to it. 'cpu_id' will be used by the cpu_is_davinci_*() macros to match the cpu id. Also move the info used to identify the cpu type into the SoC-specific code to keep all SoC-specific code together. The common code will read the JTAG ID register, search through an array of davinci_id structures to identify the cpu type. Once identified, it will set the 'cpu_id' member of the soc_info structure to the proper value and the cpu_is_davinci_*() macros will now work. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: Encapsulate SoC-specific data in a structureMark A. Greer
Create a structure to encapsulate SoC-specific information. This will assist in generalizing code so it can be used by different SoCs that have similar hardware but with minor differences such as having a different base address. The idea is that the code for each SoC fills out a structure with the correct information. The board-specific code then calls the SoC init routine which in turn will call a common init routine that makes a copy of the structure, maps in I/O regions, etc. After initialization, code can get a pointer to the structure by calling davinci_get_soc_info(). Eventually, the common init routine will make a copy of all of the data pointed to by the structure so the original data can be made __init_data. That way the data for SoC's that aren't being used won't consume memory for the entire life of the kernel. The structure will be extended in subsequent patches but initially, it holds the map_desc structure for any I/O regions the SoC/board wants statically mapped. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>