Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-01 09:41:44 +00:00
Code Issues Packages Projects Releases Wiki Activity
3abd5acfff
linux/arch/arm/mach-davinci/dm644x.c

646 lines
14 KiB
C
Raw Normal View History

davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
/*
* TI DaVinci DM644x chip specific setup
*
* Author: Kevin Hilman, Deep Root Systems, LLC
*
* 2007 (c) Deep Root Systems, LLC. This file is licensed under
* the terms of the GNU General Public License version 2. This program
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/clk.h>
davinci: Move serial platform_device into SoC-specific files Currently, there is one set of platform_device and platform_data structures for all DaVinci SoCs. The differences in the data between the various SoCs is handled by davinci_serial_init() by checking the SoC type. However, as new SoCs appear, this routine will become more & more cluttered. To clean up the routine and make it easier to add support for new SoCs, move the platform_device and platform_data structures into the SoC-specific code and use the SoC infrastructure to provide access to the data. In the process, fix a bug where the wrong irq is used for uart2 of the dm646x. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-03-18 17:36:08 +00:00
#include <linux/serial_8250.h>
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
#include <linux/platform_device.h>
davinci: Make GPIO code more generic The current gpio code needs to know the number of gpio irqs there are and what the bank irq number is. To determine those values, it checks the SoC type. It also assumes that the base address and the number of irqs the interrupt controller uses is fixed. To clean up the SoC checks and make it support different base addresses and interrupt controllers, have the SoC-specific code set those values in the soc_info structure and have the gpio code reference them there. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:35 +00:00
#include <linux/gpio.h>
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
davinci: Encapsulate SoC-specific data in a structure 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>
2009-04-15 19:38:58 +00:00
#include <asm/mach/map.h>
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
#include <mach/dm644x.h>
#include <mach/clock.h>
#include <mach/cputype.h>
#include <mach/edma.h>
#include <mach/irqs.h>
#include <mach/psc.h>
#include <mach/mux.h>
davinci: Add base address and timer flexibility The davinci timer code currently hardcodes the timer register base addresses, the timer irq numbers, and the timers to use for clock events and clocksource. This won't work for some a new SoC so put those values into the soc_info structure and set them up in the SoC-specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:11 +00:00
#include <mach/time.h>
davinci: Move serial platform_device into SoC-specific files Currently, there is one set of platform_device and platform_data structures for all DaVinci SoCs. The differences in the data between the various SoCs is handled by davinci_serial_init() by checking the SoC type. However, as new SoCs appear, this routine will become more & more cluttered. To clean up the routine and make it easier to add support for new SoCs, move the platform_device and platform_data structures into the SoC-specific code and use the SoC infrastructure to provide access to the data. In the process, fix a bug where the wrong irq is used for uart2 of the dm646x. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-03-18 17:36:08 +00:00
#include <mach/serial.h>
davinci: Encapsulate SoC-specific data in a structure 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>
2009-04-15 19:38:58 +00:00
#include <mach/common.h>
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
#include "clock.h"
#include "mux.h"
/*
* Device specific clocks
*/
#define DM644X_REF_FREQ 27000000
static struct pll_data pll1_data = {
.num = 1,
.phys_base = DAVINCI_PLL1_BASE,
};
static struct pll_data pll2_data = {
.num = 2,
.phys_base = DAVINCI_PLL2_BASE,
};
static struct clk ref_clk = {
.name = "ref_clk",
.rate = DM644X_REF_FREQ,
};
static struct clk pll1_clk = {
.name = "pll1",
.parent = &ref_clk,
.pll_data = &pll1_data,
.flags = CLK_PLL,
};
static struct clk pll1_sysclk1 = {
.name = "pll1_sysclk1",
.parent = &pll1_clk,
.flags = CLK_PLL,
.div_reg = PLLDIV1,
};
static struct clk pll1_sysclk2 = {
.name = "pll1_sysclk2",
.parent = &pll1_clk,
.flags = CLK_PLL,
.div_reg = PLLDIV2,
};
static struct clk pll1_sysclk3 = {
.name = "pll1_sysclk3",
.parent = &pll1_clk,
.flags = CLK_PLL,
.div_reg = PLLDIV3,
};
static struct clk pll1_sysclk5 = {
.name = "pll1_sysclk5",
.parent = &pll1_clk,
.flags = CLK_PLL,
.div_reg = PLLDIV5,
};
static struct clk pll1_aux_clk = {
.name = "pll1_aux_clk",
.parent = &pll1_clk,
.flags = CLK_PLL | PRE_PLL,
};
static struct clk pll1_sysclkbp = {
.name = "pll1_sysclkbp",
.parent = &pll1_clk,
.flags = CLK_PLL | PRE_PLL,
.div_reg = BPDIV
};
static struct clk pll2_clk = {
.name = "pll2",
.parent = &ref_clk,
.pll_data = &pll2_data,
.flags = CLK_PLL,
};
static struct clk pll2_sysclk1 = {
.name = "pll2_sysclk1",
.parent = &pll2_clk,
.flags = CLK_PLL,
.div_reg = PLLDIV1,
};
static struct clk pll2_sysclk2 = {
.name = "pll2_sysclk2",
.parent = &pll2_clk,
.flags = CLK_PLL,
.div_reg = PLLDIV2,
};
static struct clk pll2_sysclkbp = {
.name = "pll2_sysclkbp",
.parent = &pll2_clk,
.flags = CLK_PLL | PRE_PLL,
.div_reg = BPDIV
};
static struct clk dsp_clk = {
.name = "dsp",
.parent = &pll1_sysclk1,
.lpsc = DAVINCI_LPSC_GEM,
.flags = PSC_DSP,
.usecount = 1, /* REVISIT how to disable? */
};
static struct clk arm_clk = {
.name = "arm",
.parent = &pll1_sysclk2,
.lpsc = DAVINCI_LPSC_ARM,
.flags = ALWAYS_ENABLED,
};
static struct clk vicp_clk = {
.name = "vicp",
.parent = &pll1_sysclk2,
.lpsc = DAVINCI_LPSC_IMCOP,
.flags = PSC_DSP,
.usecount = 1, /* REVISIT how to disable? */
};
static struct clk vpss_master_clk = {
.name = "vpss_master",
.parent = &pll1_sysclk3,
.lpsc = DAVINCI_LPSC_VPSSMSTR,
.flags = CLK_PSC,
};
static struct clk vpss_slave_clk = {
.name = "vpss_slave",
.parent = &pll1_sysclk3,
.lpsc = DAVINCI_LPSC_VPSSSLV,
};
static struct clk uart0_clk = {
.name = "uart0",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_UART0,
};
static struct clk uart1_clk = {
.name = "uart1",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_UART1,
};
static struct clk uart2_clk = {
.name = "uart2",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_UART2,
};
static struct clk emac_clk = {
.name = "emac",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_EMAC_WRAPPER,
};
static struct clk i2c_clk = {
.name = "i2c",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_I2C,
};
static struct clk ide_clk = {
.name = "ide",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_ATA,
};
static struct clk asp_clk = {
.name = "asp0",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_McBSP,
};
static struct clk mmcsd_clk = {
.name = "mmcsd",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_MMC_SD,
};
static struct clk spi_clk = {
.name = "spi",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_SPI,
};
static struct clk gpio_clk = {
.name = "gpio",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_GPIO,
};
static struct clk usb_clk = {
.name = "usb",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_USB,
};
static struct clk vlynq_clk = {
.name = "vlynq",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_VLYNQ,
};
static struct clk aemif_clk = {
.name = "aemif",
.parent = &pll1_sysclk5,
.lpsc = DAVINCI_LPSC_AEMIF,
};
static struct clk pwm0_clk = {
.name = "pwm0",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_PWM0,
};
static struct clk pwm1_clk = {
.name = "pwm1",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_PWM1,
};
static struct clk pwm2_clk = {
.name = "pwm2",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_PWM2,
};
static struct clk timer0_clk = {
.name = "timer0",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_TIMER0,
};
static struct clk timer1_clk = {
.name = "timer1",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_TIMER1,
};
static struct clk timer2_clk = {
.name = "timer2",
.parent = &pll1_aux_clk,
.lpsc = DAVINCI_LPSC_TIMER2,
.usecount = 1, /* REVISIT: why cant' this be disabled? */
};
struct davinci_clk dm644x_clks[] = {
CLK(NULL, "ref", &ref_clk),
CLK(NULL, "pll1", &pll1_clk),
CLK(NULL, "pll1_sysclk1", &pll1_sysclk1),
CLK(NULL, "pll1_sysclk2", &pll1_sysclk2),
CLK(NULL, "pll1_sysclk3", &pll1_sysclk3),
CLK(NULL, "pll1_sysclk5", &pll1_sysclk5),
CLK(NULL, "pll1_aux", &pll1_aux_clk),
CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp),
CLK(NULL, "pll2", &pll2_clk),
CLK(NULL, "pll2_sysclk1", &pll2_sysclk1),
CLK(NULL, "pll2_sysclk2", &pll2_sysclk2),
CLK(NULL, "pll2_sysclkbp", &pll2_sysclkbp),
CLK(NULL, "dsp", &dsp_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "vicp", &vicp_clk),
CLK(NULL, "vpss_master", &vpss_master_clk),
CLK(NULL, "vpss_slave", &vpss_slave_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "uart0", &uart0_clk),
CLK(NULL, "uart1", &uart1_clk),
CLK(NULL, "uart2", &uart2_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
CLK("i2c_davinci.1", NULL, &i2c_clk),
CLK("palm_bk3710", NULL, &ide_clk),
CLK("soc-audio.0", NULL, &asp_clk),
CLK("davinci_mmc.0", NULL, &mmcsd_clk),
CLK(NULL, "spi", &spi_clk),
CLK(NULL, "gpio", &gpio_clk),
CLK(NULL, "usb", &usb_clk),
CLK(NULL, "vlynq", &vlynq_clk),
CLK(NULL, "aemif", &aemif_clk),
CLK(NULL, "pwm0", &pwm0_clk),
CLK(NULL, "pwm1", &pwm1_clk),
CLK(NULL, "pwm2", &pwm2_clk),
CLK(NULL, "timer0", &timer0_clk),
CLK(NULL, "timer1", &timer1_clk),
CLK("watchdog", NULL, &timer2_clk),
CLK(NULL, NULL, NULL),
};
davinci: Move emac platform_data to SoC-specific files Since most of the emac platform_data is really SoC specific and not board specific, move it to the SoC-specific files. Put a pointer to the platform_data in the soc_info structure so the board-specific code can set some of the platform_data if it needs to. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:56 +00:00
static struct emac_platform_data dm644x_emac_pdata = {
.ctrl_reg_offset = DM644X_EMAC_CNTRL_OFFSET,
.ctrl_mod_reg_offset = DM644X_EMAC_CNTRL_MOD_OFFSET,
.ctrl_ram_offset = DM644X_EMAC_CNTRL_RAM_OFFSET,
.mdio_reg_offset = DM644X_EMAC_MDIO_OFFSET,
.ctrl_ram_size = DM644X_EMAC_CNTRL_RAM_SIZE,
.version = EMAC_VERSION_1,
};
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
static struct resource dm644x_emac_resources[] = {
{
.start = DM644X_EMAC_BASE,
.end = DM644X_EMAC_BASE + 0x47ff,
.flags = IORESOURCE_MEM,
},
{
.start = IRQ_EMACINT,
.end = IRQ_EMACINT,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device dm644x_emac_device = {
.name = "davinci_emac",
.id = 1,
davinci: Move emac platform_data to SoC-specific files Since most of the emac platform_data is really SoC specific and not board specific, move it to the SoC-specific files. Put a pointer to the platform_data in the soc_info structure so the board-specific code can set some of the platform_data if it needs to. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:56 +00:00
.dev = {
.platform_data = &dm644x_emac_pdata,
},
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
.num_resources = ARRAY_SIZE(dm644x_emac_resources),
.resource = dm644x_emac_resources,
};
/*
* Device specific mux setup
*
* soc description mux mode mode mux dbg
* reg offset mask mode
*/
static const struct mux_config dm644x_pins[] = {
davinci: Move pinmux setup info to SoC infrastructure The pinmux register base and setup can be different for different SoCs so move the pinmux reg base, pinmux table (and its size) to the SoC infrastructure. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:39:48 +00:00
#ifdef CONFIG_DAVINCI_MUX
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
MUX_CFG(DM644X, HDIREN, 0, 16, 1, 1, true)
MUX_CFG(DM644X, ATAEN, 0, 17, 1, 1, true)
MUX_CFG(DM644X, ATAEN_DISABLE, 0, 17, 1, 0, true)
MUX_CFG(DM644X, HPIEN_DISABLE, 0, 29, 1, 0, true)
MUX_CFG(DM644X, AEAW, 0, 0, 31, 31, true)
MUX_CFG(DM644X, MSTK, 1, 9, 1, 0, false)
MUX_CFG(DM644X, I2C, 1, 7, 1, 1, false)
MUX_CFG(DM644X, MCBSP, 1, 10, 1, 1, false)
MUX_CFG(DM644X, UART1, 1, 1, 1, 1, true)
MUX_CFG(DM644X, UART2, 1, 2, 1, 1, true)
MUX_CFG(DM644X, PWM0, 1, 4, 1, 1, false)
MUX_CFG(DM644X, PWM1, 1, 5, 1, 1, false)
MUX_CFG(DM644X, PWM2, 1, 6, 1, 1, false)
MUX_CFG(DM644X, VLYNQEN, 0, 15, 1, 1, false)
MUX_CFG(DM644X, VLSCREN, 0, 14, 1, 1, false)
MUX_CFG(DM644X, VLYNQWD, 0, 12, 3, 3, false)
MUX_CFG(DM644X, EMACEN, 0, 31, 1, 1, true)
MUX_CFG(DM644X, GPIO3V, 0, 31, 1, 0, true)
MUX_CFG(DM644X, GPIO0, 0, 24, 1, 0, true)
MUX_CFG(DM644X, GPIO3, 0, 25, 1, 0, false)
MUX_CFG(DM644X, GPIO43_44, 1, 7, 1, 0, false)
MUX_CFG(DM644X, GPIO46_47, 0, 22, 1, 0, true)
MUX_CFG(DM644X, RGB666, 0, 22, 1, 1, true)
MUX_CFG(DM644X, LOEEN, 0, 24, 1, 1, true)
MUX_CFG(DM644X, LFLDEN, 0, 25, 1, 1, false)
davinci: Move pinmux setup info to SoC infrastructure The pinmux register base and setup can be different for different SoCs so move the pinmux reg base, pinmux table (and its size) to the SoC infrastructure. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:39:48 +00:00
#endif
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
};
davinci: Move interrupt ctlr info to SoC infrastructure 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-04-15 19:40:00 +00:00
/* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */
static u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_VDINT0] = 2,
[IRQ_VDINT1] = 6,
[IRQ_VDINT2] = 6,
[IRQ_HISTINT] = 6,
[IRQ_H3AINT] = 6,
[IRQ_PRVUINT] = 6,
[IRQ_RSZINT] = 6,
[7] = 7,
[IRQ_VENCINT] = 6,
[IRQ_ASQINT] = 6,
[IRQ_IMXINT] = 6,
[IRQ_VLCDINT] = 6,
[IRQ_USBINT] = 4,
[IRQ_EMACINT] = 4,
[14] = 7,
[15] = 7,
[IRQ_CCINT0] = 5, /* dma */
[IRQ_CCERRINT] = 5, /* dma */
[IRQ_TCERRINT0] = 5, /* dma */
[IRQ_TCERRINT] = 5, /* dma */
[IRQ_PSCIN] = 7,
[21] = 7,
[IRQ_IDE] = 4,
[23] = 7,
[IRQ_MBXINT] = 7,
[IRQ_MBRINT] = 7,
[IRQ_MMCINT] = 7,
[IRQ_SDIOINT] = 7,
[28] = 7,
[IRQ_DDRINT] = 7,
[IRQ_AEMIFINT] = 7,
[IRQ_VLQINT] = 4,
[IRQ_TINT0_TINT12] = 2, /* clockevent */
[IRQ_TINT0_TINT34] = 2, /* clocksource */
[IRQ_TINT1_TINT12] = 7, /* DSP timer */
[IRQ_TINT1_TINT34] = 7, /* system tick */
[IRQ_PWMINT0] = 7,
[IRQ_PWMINT1] = 7,
[IRQ_PWMINT2] = 7,
[IRQ_I2C] = 3,
[IRQ_UARTINT0] = 3,
[IRQ_UARTINT1] = 3,
[IRQ_UARTINT2] = 3,
[IRQ_SPINT0] = 3,
[IRQ_SPINT1] = 3,
[45] = 7,
[IRQ_DSP2ARM0] = 4,
[IRQ_DSP2ARM1] = 4,
[IRQ_GPIO0] = 7,
[IRQ_GPIO1] = 7,
[IRQ_GPIO2] = 7,
[IRQ_GPIO3] = 7,
[IRQ_GPIO4] = 7,
[IRQ_GPIO5] = 7,
[IRQ_GPIO6] = 7,
[IRQ_GPIO7] = 7,
[IRQ_GPIOBNK0] = 7,
[IRQ_GPIOBNK1] = 7,
[IRQ_GPIOBNK2] = 7,
[IRQ_GPIOBNK3] = 7,
[IRQ_GPIOBNK4] = 7,
[IRQ_COMMTX] = 7,
[IRQ_COMMRX] = 7,
[IRQ_EMUINT] = 7,
};
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
/*----------------------------------------------------------------------*/
static const s8 dma_chan_dm644x_no_event[] = {
0, 1, 12, 13, 14,
15, 25, 30, 31, 45,
46, 47, 55, 56, 57,
58, 59, 60, 61, 62,
63,
-1
};
static struct edma_soc_info dm644x_edma_info = {
.n_channel = 64,
.n_region = 4,
.n_slot = 128,
.n_tc = 2,
.noevent = dma_chan_dm644x_no_event,
};
static struct resource edma_resources[] = {
{
.name = "edma_cc",
.start = 0x01c00000,
.end = 0x01c00000 + SZ_64K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = "edma_tc0",
.start = 0x01c10000,
.end = 0x01c10000 + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = "edma_tc1",
.start = 0x01c10400,
.end = 0x01c10400 + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
.start = IRQ_CCINT0,
.flags = IORESOURCE_IRQ,
},
{
.start = IRQ_CCERRINT,
.flags = IORESOURCE_IRQ,
},
/* not using TC*_ERR */
};
static struct platform_device dm644x_edma_device = {
.name = "edma",
.id = -1,
.dev.platform_data = &dm644x_edma_info,
.num_resources = ARRAY_SIZE(edma_resources),
.resource = edma_resources,
};
/*----------------------------------------------------------------------*/
davinci: EMAC platform support Add SoC and platform-specific data and init for DaVinci EMAC network driver. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-07 13:19:40 +00:00
davinci: Encapsulate SoC-specific data in a structure 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>
2009-04-15 19:38:58 +00:00
static struct map_desc dm644x_io_desc[] = {
{
.virtual = IO_VIRT,
.pfn = __phys_to_pfn(IO_PHYS),
.length = IO_SIZE,
.type = MT_DEVICE
},
};
davinci: Support JTAG ID register at any address 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-04-15 19:39:09 +00:00
/* Contents of JTAG ID register used to identify exact cpu type */
static struct davinci_id dm644x_ids[] = {
{
.variant = 0x0,
.part_no = 0xb700,
.manufacturer = 0x017,
.cpu_id = DAVINCI_CPU_ID_DM6446,
.name = "dm6446",
},
};
davinci: Add support for multiple PSCs The current code to support the DaVinci Power and Sleep Controller (PSC) assumes that there is only one controller. This assumption is no longer valid so expand the support to allow greater than one PSC. To accomplish this, put the base addresses for the PSCs in the SoC infrastructure so it can be referenced by the PSC code. This also requires adding an extra parameter to davinci_psc_config() to specify the PSC that is to be enabled/disabled. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:39:33 +00:00
static void __iomem *dm644x_psc_bases[] = {
IO_ADDRESS(DAVINCI_PWR_SLEEP_CNTRL_BASE),
};
davinci: Add base address and timer flexibility The davinci timer code currently hardcodes the timer register base addresses, the timer irq numbers, and the timers to use for clock events and clocksource. This won't work for some a new SoC so put those values into the soc_info structure and set them up in the SoC-specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:11 +00:00
/*
* T0_BOT: Timer 0, bottom: clockevent source for hrtimers
* T0_TOP: Timer 0, top : clocksource for generic timekeeping
* T1_BOT: Timer 1, bottom: (used by DSP in TI DSPLink code)
* T1_TOP: Timer 1, top : <unused>
*/
struct davinci_timer_info dm644x_timer_info = {
.timers = davinci_timer_instance,
.clockevent_id = T0_BOT,
.clocksource_id = T0_TOP,
};
davinci: Move serial platform_device into SoC-specific files Currently, there is one set of platform_device and platform_data structures for all DaVinci SoCs. The differences in the data between the various SoCs is handled by davinci_serial_init() by checking the SoC type. However, as new SoCs appear, this routine will become more & more cluttered. To clean up the routine and make it easier to add support for new SoCs, move the platform_device and platform_data structures into the SoC-specific code and use the SoC infrastructure to provide access to the data. In the process, fix a bug where the wrong irq is used for uart2 of the dm646x. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-03-18 17:36:08 +00:00
static struct plat_serial8250_port dm644x_serial_platform_data[] = {
{
.mapbase = DAVINCI_UART0_BASE,
.irq = IRQ_UARTINT0,
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
UPF_IOREMAP,
.iotype = UPIO_MEM,
.regshift = 2,
},
{
.mapbase = DAVINCI_UART1_BASE,
.irq = IRQ_UARTINT1,
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
UPF_IOREMAP,
.iotype = UPIO_MEM,
.regshift = 2,
},
{
.mapbase = DAVINCI_UART2_BASE,
.irq = IRQ_UARTINT2,
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
UPF_IOREMAP,
.iotype = UPIO_MEM,
.regshift = 2,
},
{
.flags = 0
},
};
static struct platform_device dm644x_serial_device = {
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = {
.platform_data = dm644x_serial_platform_data,
},
};
davinci: Encapsulate SoC-specific data in a structure 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>
2009-04-15 19:38:58 +00:00
static struct davinci_soc_info davinci_soc_info_dm644x = {
.io_desc = dm644x_io_desc,
.io_desc_num = ARRAY_SIZE(dm644x_io_desc),
davinci: Support JTAG ID register at any address 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-04-15 19:39:09 +00:00
.jtag_id_base = IO_ADDRESS(0x01c40028),
.ids = dm644x_ids,
.ids_num = ARRAY_SIZE(dm644x_ids),
davinci: Add clock init call to common init routine 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-04-15 19:39:23 +00:00
.cpu_clks = dm644x_clks,
davinci: Add support for multiple PSCs The current code to support the DaVinci Power and Sleep Controller (PSC) assumes that there is only one controller. This assumption is no longer valid so expand the support to allow greater than one PSC. To accomplish this, put the base addresses for the PSCs in the SoC infrastructure so it can be referenced by the PSC code. This also requires adding an extra parameter to davinci_psc_config() to specify the PSC that is to be enabled/disabled. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:39:33 +00:00
.psc_bases = dm644x_psc_bases,
.psc_bases_num = ARRAY_SIZE(dm644x_psc_bases),
davinci: Move pinmux setup info to SoC infrastructure The pinmux register base and setup can be different for different SoCs so move the pinmux reg base, pinmux table (and its size) to the SoC infrastructure. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:39:48 +00:00
.pinmux_base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE),
.pinmux_pins = dm644x_pins,
.pinmux_pins_num = ARRAY_SIZE(dm644x_pins),
davinci: Move interrupt ctlr info to SoC infrastructure 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-04-15 19:40:00 +00:00
.intc_base = IO_ADDRESS(DAVINCI_ARM_INTC_BASE),
.intc_type = DAVINCI_INTC_TYPE_AINTC,
.intc_irq_prios = dm644x_default_priorities,
.intc_irq_num = DAVINCI_N_AINTC_IRQ,
davinci: Add base address and timer flexibility The davinci timer code currently hardcodes the timer register base addresses, the timer irq numbers, and the timers to use for clock events and clocksource. This won't work for some a new SoC so put those values into the soc_info structure and set them up in the SoC-specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:11 +00:00
.timer_info = &dm644x_timer_info,
davinci: Add watchdog base address flexibility The watchdog code currently hardcodes the base address of the timer its using. To support new SoCs, make it support timers at any address. Use the soc_info structure to do this. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:21 +00:00
.wdt_base = IO_ADDRESS(DAVINCI_WDOG_BASE),
davinci: Make GPIO code more generic The current gpio code needs to know the number of gpio irqs there are and what the bank irq number is. To determine those values, it checks the SoC type. It also assumes that the base address and the number of irqs the interrupt controller uses is fixed. To clean up the SoC checks and make it support different base addresses and interrupt controllers, have the SoC-specific code set those values in the soc_info structure and have the gpio code reference them there. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:35 +00:00
.gpio_base = IO_ADDRESS(DAVINCI_GPIO_BASE),
.gpio_num = 71,
.gpio_irq = IRQ_GPIOBNK0,
davinci: Move serial platform_device into SoC-specific files Currently, there is one set of platform_device and platform_data structures for all DaVinci SoCs. The differences in the data between the various SoCs is handled by davinci_serial_init() by checking the SoC type. However, as new SoCs appear, this routine will become more & more cluttered. To clean up the routine and make it easier to add support for new SoCs, move the platform_device and platform_data structures into the SoC-specific code and use the SoC infrastructure to provide access to the data. In the process, fix a bug where the wrong irq is used for uart2 of the dm646x. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-03-18 17:36:08 +00:00
.serial_dev = &dm644x_serial_device,
davinci: Move emac platform_data to SoC-specific files Since most of the emac platform_data is really SoC specific and not board specific, move it to the SoC-specific files. Put a pointer to the platform_data in the soc_info structure so the board-specific code can set some of the platform_data if it needs to. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:56 +00:00
.emac_pdata = &dm644x_emac_pdata,
davinci: Encapsulate SoC-specific data in a structure 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>
2009-04-15 19:38:58 +00:00
};
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
void __init dm644x_init(void)
{
davinci: Encapsulate SoC-specific data in a structure 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>
2009-04-15 19:38:58 +00:00
davinci_common_init(&davinci_soc_info_dm644x);
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
}
static int __init dm644x_init_devices(void)
{
if (!cpu_is_davinci_dm644x())
return 0;
platform_device_register(&dm644x_edma_device);
davinci: Move emac platform_data to SoC-specific files Since most of the emac platform_data is really SoC specific and not board specific, move it to the SoC-specific files. Put a pointer to the platform_data in the soc_info structure so the board-specific code can set some of the platform_data if it needs to. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 19:40:56 +00:00
platform_device_register(&dm644x_emac_device);
davinci: update DM644x support in preparation for more SoCs Rework DM644x code into SoC specific and board specific parts. This is also to generalize the structure a bit so it's easier to add support for new SoCs in the DaVinci family. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-14 16:30:11 +00:00
return 0;
}
postcore_initcall(dm644x_init_devices);
Reference in New Issue Copy Permalink