AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-28 11:18:45 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
8fb843d179
linux_dsm_epyc7002/arch/arm/mach-davinci/dm644x.c

762 lines
18 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 23:30:11 +07: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.
*/
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07:00
#include <linux/clk-provider.h>
#include <linux/clk/davinci.h>
#include <linux/clkdev.h>
ARM: davinci: dm644x: 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: typo fixes in code] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-02-02 19:43:16 +07:00
#include <linux/dmaengine.h>
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07: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 05:20:22 +07:00
#include <linux/io.h>
ARM: davinci: aintc: use the new irqchip config structure in dm* SoCs Add the new-style config structures for dm* SoCs. They will be used once we make the aintc driver stop using davinci_soc_info. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 21:52:10 +07:00
#include <linux/irqchip/irq-davinci-aintc.h>
ARM: davinci: move private EDMA API to arm/common Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. Signed-off-by: Matt Porter <mporter@ti.com> Acked-by: Chris Ball <cjb@laptop.org> # davinci_mmc.c Acked-by: Mark Brown <broonie@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> [nsekhar@ti.com: dropped davinci sffsdr changes] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-03-06 23:15:31 +07:00
#include <linux/platform_data/edma.h>
ARM: davinci: support gpio platform device DaVinci GPIO driver now uses platform device model. Add a GPIO platform register API to convert the traditional DaVinci SoCs to use the new model. While at it, also group related include files together wherever that was not the case. Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> [nsekhar@ti.com: move function declaration to local header, simplify commit message, merge SoC specific portions from other patches into this patch] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-08-18 12:19:00 +07:00
#include <linux/platform_data/gpio-davinci.h>
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07:00
#include <linux/platform_device.h>
#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 23:30:11 +07: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-16 02:38:58 +07:00
#include <asm/mach/map.h>
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07: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 23:30:11 +07:00
#include <mach/cputype.h>
#include <mach/mux.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-19 00:36:08 +07:00
#include <mach/serial.h>
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07:00
#include <mach/time.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 23:30:11 +07:00
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07:00
#include "asp.h"
ARM: davinci: create new common platform header for davinci Remove individual platform header files for dm365, dm355, dm644x and dm646x and consolidate it into a single and common header file davinci.h placed in arch/arm/mach-davinci. This reduces the pollution in the include/mach and is consistent with Russell's suggestions as part of his "pet peaves" mail. (See #4 in: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/071516.html) While at it, fix the forward declaration of spi_board_info, and include the right header file instead. The further patches in the series take advantage of this consolidation for easy implementation of IO_ADDRESS elimination. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> [nsekhar@ti.com: make davinci.h the first local include file, fix forward declaration of spi_board_info and add back Deep Root Systems, LLC copyright] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:35 +07:00
#include "davinci.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 21:52:03 +07:00
#include "irqs.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 23:30:11 +07:00
#include "mux.h"
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07: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 23:30:11 +07:00
/*
* Device specific clocks
*/
#define DM644X_REF_FREQ 27000000
ARM: davinci: dm644x: move private definitions to C file Move register base addresses and offsets used only by dm644x.c from arch/arm/mach-davinci/include/mach/dm644x.h to the C file as these definitions are used only there. This helps reduce code in arch/arm/mach-davinci/include/mach which is not really needed by rest of the kernel. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-15 19:11:51 +07:00
#define DM644X_EMAC_BASE 0x01c80000
#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000)
#define DM644X_EMAC_CNTRL_OFFSET 0x0000
#define DM644X_EMAC_CNTRL_MOD_OFFSET 0x1000
#define DM644X_EMAC_CNTRL_RAM_OFFSET 0x2000
#define DM644X_EMAC_CNTRL_RAM_SIZE 0x2000
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-16 02:40:56 +07: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,
.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 23:30:11 +07:00
static struct resource dm644x_emac_resources[] = {
{
.start = DM644X_EMAC_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 21:11:22 +07:00
.end = DM644X_EMAC_BASE + SZ_16K - 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 23:30:11 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_EMACINT),
.end = DAVINCI_INTC_IRQ(IRQ_EMACINT),
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 23:30:11 +07:00
.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-16 02:40:56 +07: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 23:30:11 +07:00
.num_resources = ARRAY_SIZE(dm644x_emac_resources),
.resource = dm644x_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 21:11:22 +07:00
static struct resource dm644x_mdio_resources[] = {
{
.start = DM644X_EMAC_MDIO_BASE,
.end = DM644X_EMAC_MDIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device dm644x_mdio_device = {
.name = "davinci_mdio",
.id = 0,
.num_resources = ARRAY_SIZE(dm644x_mdio_resources),
.resource = dm644x_mdio_resources,
};
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 23:30:11 +07:00
/*
* 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-16 02:39:48 +07: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 23:30:11 +07: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)
davinci: Initial support for Neuros OSD2 platform. The Neuros OSD 2.0 is the hardware component of the Neuros Open Internet Television Platform. Hardware is very close to Ti DM644X-EVM board. It has: DM6446M02 module with 256MB NAND, 256MB RAM, TLV320AIC32 AIC, USB, Ethernet, SD/MMC, UART, THS8200, TVP7000 for video. Additionaly realtime clock, IR remote control receiver, IR Blaster based on MSP430 (firmware although is different from used in DM644X-EVM), internal ATA-6 3.5” HDD drive with PATA interface, two muxed red-green leds. For more information please refer to http://wiki.neurostechnology.com/index.php/OSD_2.0_HD Signed-off-by: Andrey Porodko <panda@chelcom.ru> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-13 21:16:51 +07:00
MUX_CFG(DM644X, AEAW0, 0, 0, 1, 0, true)
MUX_CFG(DM644X, AEAW1, 0, 1, 1, 0, true)
MUX_CFG(DM644X, AEAW2, 0, 2, 1, 0, true)
MUX_CFG(DM644X, AEAW3, 0, 3, 1, 0, true)
MUX_CFG(DM644X, AEAW4, 0, 4, 1, 0, true)
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 23:30:11 +07:00
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-16 02:39:48 +07: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 23:30:11 +07: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-16 02:40:00 +07: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 23:30:11 +07: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 18:42:46 +07:00
static s8 queue_priority_mapping[][2] = {
davinci: EDMA: multiple CCs, channel mapping and API changes - restructure to support multiple channel controllers by using additional struct resources for each CC - interface changes visible to EDMA clients Introduce macros to build IDs from controller and channel number, and to extract them. Modify the edma_alloc_slot function to take an extra argument for the controller. Also update ASoC drivers to use API. ASoC changes Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> - Move queue related mappings to dm<soc>.c EDMA in DM355 and DM644x has two transfer controllers while DM646x has four transfer controllers. Moving the queue to tc mapping and queue priority mapping to dm<soc>.c will be helpful to probe these mappings from platform device so that the machine_is_* testing will be avoided. - add channel mapping logic Channel mapping logic is introduced in dm646x EDMA. This implies that there is no fixed association for a channel number to a parameter entry number. In other words, using the DMA channel mapping registers (DCHMAPn), a PaRAM entry can be mapped to any channel. While in the case of dm644x and dm355 there is a fixed mapping between the EDMA channel and Param entry number. Signed-off-by: Naresh Medisetty <naresh@ti.com> Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Reviewed-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-21 18:41:35 +07:00
/* {event queue no, Priority} */
{0, 3},
{1, 7},
{-1, -1},
};
ARM: davinci: dm644x: 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: typo fixes in code] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-02-02 19:43:16 +07:00
static const struct dma_slave_map dm644x_edma_map[] = {
{ "davinci-mcbsp", "tx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcbsp", "rx", EDMA_FILTER_PARAM(0, 3) },
{ "spi_davinci", "tx", EDMA_FILTER_PARAM(0, 16) },
{ "spi_davinci", "rx", EDMA_FILTER_PARAM(0, 17) },
{ "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
{ "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
};
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 18:42:46 +07:00
static struct edma_soc_info dm644x_edma_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 13:05:12 +07:00
.queue_priority_mapping = 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 20:14:35 +07:00
.default_queue = EVENTQ_1,
ARM: davinci: dm644x: 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: typo fixes in code] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-02-02 19:43:16 +07:00
.slave_map = dm644x_edma_map,
.slavecnt = ARRAY_SIZE(dm644x_edma_map),
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 13:05:12 +07: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 23:30:11 +07:00
static struct resource edma_resources[] = {
{
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 18:42:46 +07:00
.name = "edma3_cc",
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 23:30:11 +07:00
.start = 0x01c00000,
.end = 0x01c00000 + SZ_64K - 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 18:42:46 +07:00
.name = "edma3_tc0",
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 23:30:11 +07:00
.start = 0x01c10000,
.end = 0x01c10000 + 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 18:42:46 +07:00
.name = "edma3_tc1",
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 23:30:11 +07:00
.start = 0x01c10400,
.end = 0x01c10400 + 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 18:42:46 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_CCINT0),
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 23:30:11 +07: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 18:42:46 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_CCERRINT),
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 23:30:11 +07:00
.flags = IORESOURCE_IRQ,
},
/* not using TC*_ERR */
};
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 18:42:51 +07:00
static const struct platform_device_info dm644x_edma_device __initconst = {
.name = "edma",
.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 18:42:52 +07: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 18:42:51 +07:00
.res = edma_resources,
.num_res = ARRAY_SIZE(edma_resources),
.data = &dm644x_edma_pdata,
.size_data = sizeof(dm644x_edma_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 23:30:11 +07:00
};
davinci: ASoC: Add the platform devices for ASP 1) Registers the platform devices for ASP on dm355, dm644x and dm646x so that the machine driver can probe to get ASP related platform data. 2) Move towards definition of the asp clocks using physical name(for dm355 and dm644x) 3) Add platform data to board specific files. Signed-off-by: Naresh Medisetty <naresh@ti.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-05 17:28:08 +07:00
/* DM6446 EVM uses ASP0; line-out is a pair of RCA jacks */
static struct resource dm644x_asp_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 21:48:17 +07:00
.name = "mpu",
davinci: ASoC: Add the platform devices for ASP 1) Registers the platform devices for ASP on dm355, dm644x and dm646x so that the machine driver can probe to get ASP related platform data. 2) Move towards definition of the asp clocks using physical name(for dm355 and dm644x) 3) Add platform data to board specific files. Signed-off-by: Naresh Medisetty <naresh@ti.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-05 17:28:08 +07:00
.start = DAVINCI_ASP0_BASE,
.end = DAVINCI_ASP0_BASE + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
{
.start = DAVINCI_DMA_ASP0_TX,
.end = DAVINCI_DMA_ASP0_TX,
.flags = IORESOURCE_DMA,
},
{
.start = DAVINCI_DMA_ASP0_RX,
.end = DAVINCI_DMA_ASP0_RX,
.flags = IORESOURCE_DMA,
},
};
static struct platform_device dm644x_asp_device = {
ASoC: davinci: fixes for multi-component Multi-component commit f0fba2ad broke a few things which this patch should fix. Tested on the DM355 EVM. I've been as careful as I can, but it would be good if those with access to other Davinci boards could test. -- The multi-component commit put the initialisation of snd_soc_dai.[capture|playback]_dma_data into snd_soc_dai_ops.hw_params of the McBSP, McASP & VCIF drivers (davinci-i2s.c, davinci-mcasp.c & davinci-vcif.c). The initialisation had to be moved from the probe function in these drivers because davinci_*_dai changed from snd_soc_dai to snd_soc_dai_driver. Unfortunately, the DMA params pointer is needed by davinci_pcm_open (in davinci-pcm.c) before hw_params is called. I have moved the initialisation to a new snd_soc_dai_ops.startup function in each of these drivers. This fix indicates that all platforms that use davinci-pcm must have been broken and need to test with this fix. -- The multi-component commit also changed the McBSP driver name from "davinci-asp" to "davinci-i2s" in davinci-i2s.c without updating the board level references to the driver name. This change is understandable, as there is a similarly named "davinci-mcasp" driver in davinci-mcasp.c. There is probably no 'correct' name for this driver. The DM6446 datasheet calls it the "ASP" and describes it as a "specialised McBSP". The DM355 datasheet calls it the "ASP" and describes it as a "specialised ASP". The DM365 datasheet calls it the "McBSP". Rather than fix this problem by reverting to "davinci-asp", I've elected to avoid future confusion with the "davinci-mcasp" driver by changing it to "davinci-mcbsp", which is also consistent with the names of the functions in the driver. There are other fixes required, so it was never going to be as simple as a revert anyway. -- The DM365 only has one McBSP port (of the McBSP platforms, only the DM355 has 2 ports), so I've changed the the id of the platform_device from 0 to -1. -- In davinci-evm.c, the DM6446 EVM can no longer share a snd_soc_dai_link structure with the DM355 EVM as they use different cpu DAI names (the DM355 has 2 ports and the EVM uses the second port, but the DM6446 only has 1 port). This also means that the 2 boards need different snd_soc_card structures. -- The codec_name entries in davinci-evm.c didn't match the i2c ids in the board files. I have only checked and fixed the details of the names used for the McBSP based platforms. Someone with a McASP based platform (eg DA8xx) should check the others. Signed-off-by: Chris Paulson-Ellis <chris@edesix.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2010-11-16 19:27:09 +07:00
.name = "davinci-mcbsp",
davinci: ASoC: Add the platform devices for ASP 1) Registers the platform devices for ASP on dm355, dm644x and dm646x so that the machine driver can probe to get ASP related platform data. 2) Move towards definition of the asp clocks using physical name(for dm355 and dm644x) 3) Add platform data to board specific files. Signed-off-by: Naresh Medisetty <naresh@ti.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-05 17:28:08 +07:00
.id = -1,
.num_resources = ARRAY_SIZE(dm644x_asp_resources),
.resource = dm644x_asp_resources,
};
ARM: davinci: dm644x: improve readability using macro Replace the VPSS base address "magic number" with the define "DM644X_VPSS_BASE" to improve readability. While at it, fix the indentation done using spaces in this part of code. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:37 +07:00
#define DM644X_VPSS_BASE 0x01c73400
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07:00
static struct resource dm644x_vpss_resources[] = {
{
/* VPSS Base address */
.name = "vpss",
ARM: davinci: dm644x: improve readability using macro Replace the VPSS base address "magic number" with the define "DM644X_VPSS_BASE" to improve readability. While at it, fix the indentation done using spaces in this part of code. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:37 +07:00
.start = DM644X_VPSS_BASE,
.end = DM644X_VPSS_BASE + 0xff,
.flags = IORESOURCE_MEM,
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07:00
},
};
static struct platform_device dm644x_vpss_device = {
.name = "vpss",
.id = -1,
.dev.platform_data = "dm644x_vpss",
.num_resources = ARRAY_SIZE(dm644x_vpss_resources),
.resource = dm644x_vpss_resources,
};
ARM: davinci: dm644x: fix inconsistent variable naming Add dm644x_ prefix to names of v4l2 variables in dm644x.c Add dm644xevm_ prefix to names of v4l2 variables in board-dm644x-evm.c. This makes the code consistent with rest of these files. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:38 +07:00
static struct resource dm644x_vpfe_resources[] = {
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_VDINT0),
.end = DAVINCI_INTC_IRQ(IRQ_VDINT0),
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_VDINT1),
.end = DAVINCI_INTC_IRQ(IRQ_VDINT1),
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07:00
.flags = IORESOURCE_IRQ,
},
V4L/DVB: vpfe-capture: converting ccdc drivers to platform-drivers This adds platform code for ccdc driver on DM355 and DM6446. 1) new ccdc platform devices added 2) added clock aliases master and slave for CCDC clocks 3) added dm355_ccdc_setup_pinmux() pin-mux setup hook in dm355 ccdc driver platform data Reviewed-by: Vaibhav Hiremath <hvaibhav@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-01-14 06:27:08 +07:00
};
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
static u64 dm644x_video_dma_mask = DMA_BIT_MASK(32);
V4L/DVB: vpfe-capture: converting ccdc drivers to platform-drivers This adds platform code for ccdc driver on DM355 and DM6446. 1) new ccdc platform devices added 2) added clock aliases master and slave for CCDC clocks 3) added dm355_ccdc_setup_pinmux() pin-mux setup hook in dm355 ccdc driver platform data Reviewed-by: Vaibhav Hiremath <hvaibhav@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-01-14 06:27:08 +07:00
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07:00
{
.start = 0x01c70400,
.end = 0x01c70400 + 0xff,
.flags = IORESOURCE_MEM,
},
};
V4L/DVB: vpfe-capture: converting ccdc drivers to platform-drivers This adds platform code for ccdc driver on DM355 and DM6446. 1) new ccdc platform devices added 2) added clock aliases master and slave for CCDC clocks 3) added dm355_ccdc_setup_pinmux() pin-mux setup hook in dm355 ccdc driver platform data Reviewed-by: Vaibhav Hiremath <hvaibhav@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-01-14 06:27:08 +07:00
static struct platform_device dm644x_ccdc_dev = {
.name = "dm644x_ccdc",
.id = -1,
.num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
.resource = dm644x_ccdc_resource,
.dev = {
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
.dma_mask = &dm644x_video_dma_mask,
V4L/DVB: vpfe-capture: converting ccdc drivers to platform-drivers This adds platform code for ccdc driver on DM355 and DM6446. 1) new ccdc platform devices added 2) added clock aliases master and slave for CCDC clocks 3) added dm355_ccdc_setup_pinmux() pin-mux setup hook in dm355 ccdc driver platform data Reviewed-by: Vaibhav Hiremath <hvaibhav@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2010-01-14 06:27:08 +07:00
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
ARM: davinci: dm644x: fix inconsistent variable naming Add dm644x_ prefix to names of v4l2 variables in dm644x.c Add dm644xevm_ prefix to names of v4l2 variables in board-dm644x-evm.c. This makes the code consistent with rest of these files. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:38 +07:00
static struct platform_device dm644x_vpfe_dev = {
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07:00
.name = CAPTURE_DRV_NAME,
.id = -1,
ARM: davinci: dm644x: fix inconsistent variable naming Add dm644x_ prefix to names of v4l2 variables in dm644x.c Add dm644xevm_ prefix to names of v4l2 variables in board-dm644x-evm.c. This makes the code consistent with rest of these files. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:38 +07:00
.num_resources = ARRAY_SIZE(dm644x_vpfe_resources),
.resource = dm644x_vpfe_resources,
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07:00
.dev = {
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
.dma_mask = &dm644x_video_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
#define DM644X_OSD_BASE 0x01c72600
static struct resource dm644x_osd_resources[] = {
{
.start = DM644X_OSD_BASE,
.end = DM644X_OSD_BASE + 0x1ff,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device dm644x_osd_dev = {
[media] davinci: vpbe: pass different platform names to handle different ip's The vpbe driver can handle different platforms DM644X, DM36X and DM355. To differentiate between this platforms venc_type/vpbe_type was passed as part of platform data which was incorrect. The correct way to differentiate to handle this case is by passing different platform names. This patch creates platform_device_id[] array supporting different platforms and assigns id_table to the platform driver, and finally in the probe gets the actual device by using platform_get_device_id() and gets the appropriate driver data for that platform. Taking this approach will also make the DT transition easier. Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-11-20 17:30:36 +07:00
.name = DM644X_VPBE_OSD_SUBDEV_NAME,
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
.id = -1,
.num_resources = ARRAY_SIZE(dm644x_osd_resources),
.resource = dm644x_osd_resources,
.dev = {
.dma_mask = &dm644x_video_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
#define DM644X_VENC_BASE 0x01c72400
static struct resource dm644x_venc_resources[] = {
{
.start = DM644X_VENC_BASE,
.end = DM644X_VENC_BASE + 0x17f,
.flags = IORESOURCE_MEM,
},
};
#define DM644X_VPSS_MUXSEL_PLL2_MODE BIT(0)
#define DM644X_VPSS_MUXSEL_VPBECLK_MODE BIT(1)
#define DM644X_VPSS_VENCLKEN BIT(3)
#define DM644X_VPSS_DACCLKEN BIT(4)
static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
[media] dm644x: replace the obsolete preset API by the timings API This patch replaces the preset API by the timings API, and appropriate changes in board file. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-01 21:39:46 +07:00
unsigned int pclock)
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
{
int ret = 0;
u32 v = DM644X_VPSS_VENCLKEN;
switch (type) {
case VPBE_ENC_STD:
v |= DM644X_VPSS_DACCLKEN;
writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
break;
[media] davinci: remove VPBE_ENC_DV_PRESET and rename VPBE_ENC_CUSTOM_TIMINGS Remove VPBE_ENC_DV_PRESET (the DV_PRESET API is no longer supported) and VPBE_ENC_CUSTOM_TIMINGS is renamed to VPBE_ENC_DV_TIMINGS since the old "CUSTOM_TIMINGS" name is deprecated in favor of "DV_TIMINGS". Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Lad, Prabhakar <prabhakar.lad@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-02-16 01:06:28 +07:00
case VPBE_ENC_DV_TIMINGS:
[media] dm644x: replace the obsolete preset API by the timings API This patch replaces the preset API by the timings API, and appropriate changes in board file. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-01 21:39:46 +07:00
if (pclock <= 27000000) {
ARM: davinci: dm644x: fix out range signal for ED Fix the video clock setting when custom timings are used with pclock <= 27MHz. Existing video clock selection uses PLL2 mode which results in a 54MHz clock whereas using the MXI mode results in a 27MHz clock (which is the one actually desired). This bug affects the Enhanced Definition (ED) support on DM644x. Without this patch, out-range signals errors are were observed on the TV when viewing ED. An out-of-range signal is often caused when the field rate is above the rate that the television will handle. Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Cc: Sekhar Nori <nsekhar@ti.com> [nsekhar@ti.com: reword commit message based on on-list discussion] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-10-03 13:35:00 +07:00
v |= DM644X_VPSS_DACCLKEN;
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
[media] dm644x: replace the obsolete preset API by the timings API This patch replaces the preset API by the timings API, and appropriate changes in board file. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-10-01 21:39:46 +07:00
} else {
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
/*
* For HD, use external clock source since
* HD requires higher clock rate
*/
v |= DM644X_VPSS_MUXSEL_VPBECLK_MODE;
writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
}
break;
default:
ret = -EINVAL;
}
return ret;
}
static struct resource dm644x_v4l2_disp_resources[] = {
{
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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_VENCINT),
.end = DAVINCI_INTC_IRQ(IRQ_VENCINT),
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device dm644x_vpbe_display = {
.name = "vpbe-v4l2",
.id = -1,
.num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
.resource = dm644x_v4l2_disp_resources,
.dev = {
.dma_mask = &dm644x_video_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
static struct venc_platform_data dm644x_venc_pdata = {
.setup_clock = dm644x_venc_setup_clock,
};
static struct platform_device dm644x_venc_dev = {
[media] davinci: vpbe: pass different platform names to handle different ip's The vpbe driver can handle different platforms DM644X, DM36X and DM355. To differentiate between this platforms venc_type/vpbe_type was passed as part of platform data which was incorrect. The correct way to differentiate to handle this case is by passing different platform names. This patch creates platform_device_id[] array supporting different platforms and assigns id_table to the platform driver, and finally in the probe gets the actual device by using platform_get_device_id() and gets the appropriate driver data for that platform. Taking this approach will also make the DT transition easier. Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-11-20 17:30:36 +07:00
.name = DM644X_VPBE_VENC_SUBDEV_NAME,
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
.id = -1,
.num_resources = ARRAY_SIZE(dm644x_venc_resources),
.resource = dm644x_venc_resources,
.dev = {
.dma_mask = &dm644x_video_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &dm644x_venc_pdata,
},
};
static struct platform_device dm644x_vpbe_dev = {
.name = "vpbe_controller",
.id = -1,
.dev = {
.dma_mask = &dm644x_video_dma_mask,
davinci: DM644x platform changes for vpfe capture DM644x platform and board setup This adds platform and board setup changes required to support vpfe capture driver on DM644x Tested video capture on DM6446 with tvp514x driver Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be> Reviewed-by: David Brownell <david-b@pacbell.net> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-09-16 22:53:18 +07:00
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
ARM: davinci: support gpio platform device DaVinci GPIO driver now uses platform device model. Add a GPIO platform register API to convert the traditional DaVinci SoCs to use the new model. While at it, also group related include files together wherever that was not the case. Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> [nsekhar@ti.com: move function declaration to local header, simplify commit message, merge SoC specific portions from other patches into this patch] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-08-18 12:19:00 +07:00
static struct resource dm644_gpio_resources[] = {
{ /* registers */
.start = DAVINCI_GPIO_BASE,
.end = DAVINCI_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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_GPIOBNK0),
.end = DAVINCI_INTC_IRQ(IRQ_GPIOBNK0),
ARM: davinci: dm644x: 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 16:35:16 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_GPIOBNK1),
.end = DAVINCI_INTC_IRQ(IRQ_GPIOBNK1),
ARM: davinci: dm644x: 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 16:35:16 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_GPIOBNK2),
.end = DAVINCI_INTC_IRQ(IRQ_GPIOBNK2),
ARM: davinci: dm644x: 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 16:35:16 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_GPIOBNK3),
.end = DAVINCI_INTC_IRQ(IRQ_GPIOBNK3),
ARM: davinci: dm644x: 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 16:35:16 +07: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 21:52:01 +07:00
.start = DAVINCI_INTC_IRQ(IRQ_GPIOBNK4),
.end = DAVINCI_INTC_IRQ(IRQ_GPIOBNK4),
ARM: davinci: support gpio platform device DaVinci GPIO driver now uses platform device model. Add a GPIO platform register API to convert the traditional DaVinci SoCs to use the new model. While at it, also group related include files together wherever that was not the case. Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> [nsekhar@ti.com: move function declaration to local header, simplify commit message, merge SoC specific portions from other patches into this patch] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-08-18 12:19:00 +07:00
.flags = IORESOURCE_IRQ,
},
};
static struct davinci_gpio_platform_data dm644_gpio_platform_data = {
ARM: davinci: dm644x: set the GPIO base to 0 Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection") broke the GPIO support on DaVinci boards in legacy mode by allowing gpiolib to set the GPIO base automatically. DaVinci board files use the legacy GPIO API with hard-coded GPIO line numbers. Use the new fields in struct davinci_gpio_platform_data to manually set the GPIO base to 0. Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-11-21 16:35:23 +07:00
.no_auto_base = true,
.base = 0,
ARM: davinci: support gpio platform device DaVinci GPIO driver now uses platform device model. Add a GPIO platform register API to convert the traditional DaVinci SoCs to use the new model. While at it, also group related include files together wherever that was not the case. Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> [nsekhar@ti.com: move function declaration to local header, simplify commit message, merge SoC specific portions from other patches into this patch] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-08-18 12:19:00 +07:00
.ngpio = 71,
};
int __init dm644x_gpio_register(void)
{
return davinci_gpio_register(dm644_gpio_resources,
ARM: davinci: fix number of resources passed to davinci_gpio_register() The davinci_gpio_register() function expects the number of resources as the second parameter, but sizeof() resources was passed to it due to which it was causing unexpected behaviour. This patch fixes the same by passing the ARRAY_SIZE() of resources. Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-11-08 13:45:56 +07:00
ARRAY_SIZE(dm644_gpio_resources),
ARM: davinci: support gpio platform device DaVinci GPIO driver now uses platform device model. Add a GPIO platform register API to convert the traditional DaVinci SoCs to use the new model. While at it, also group related include files together wherever that was not the case. Signed-off-by: Philip Avinash <avinashphilip@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> [nsekhar@ti.com: move function declaration to local header, simplify commit message, merge SoC specific portions from other patches into this patch] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-08-18 12:19:00 +07:00
&dm644_gpio_platform_data);
}
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 23:30:11 +07:00
/*----------------------------------------------------------------------*/
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 20:19:40 +07: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-16 02:38:58 +07: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-16 02:39:09 +07: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: dm644x: Support for dm644x silicon revision 2.1 JTAG ID for DM644x silicon revision 2.1 has changed. An entry for the new silicon revision needs to be added to the davinci_id structure. Without this addition, EVMs with new silicon revision fail to boot the kernel. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-02 17:48:43 +07:00
{
.variant = 0x1,
.part_no = 0xb700,
.manufacturer = 0x017,
.cpu_id = DAVINCI_CPU_ID_DM6446,
.name = "dm6446a",
},
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-16 02:39:09 +07:00
};
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-16 02:40:11 +07: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>
*/
davinci: misc cleanups from sparse - Convert data/functions to static - include headers for missing declarations - pointer cleanups: struct foo *__iomem f --> struct foo __iomem *f; Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-26 06:36:38 +07:00
static struct davinci_timer_info dm644x_timer_info = {
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-16 02:40:11 +07:00
.timers = davinci_timer_instance,
.clockevent_id = T0_BOT,
.clocksource_id = T0_TOP,
};
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 16:15:38 +07:00
static struct plat_serial8250_port dm644x_serial0_platform_data[] = {
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-19 00:36:08 +07:00
{
.mapbase = DAVINCI_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 21:52:01 +07:00
.irq = DAVINCI_INTC_IRQ(IRQ_UARTINT0),
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-19 00:36:08 +07: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 16:15:38 +07:00
{
.flags = 0,
}
};
static struct plat_serial8250_port dm644x_serial1_platform_data[] = {
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-19 00:36:08 +07:00
{
.mapbase = DAVINCI_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 21:52:01 +07:00
.irq = DAVINCI_INTC_IRQ(IRQ_UARTINT1),
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-19 00:36:08 +07: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 16:15:38 +07:00
{
.flags = 0,
}
};
static struct plat_serial8250_port dm644x_serial2_platform_data[] = {
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-19 00:36:08 +07:00
{
.mapbase = DAVINCI_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 21:52:01 +07:00
.irq = DAVINCI_INTC_IRQ(IRQ_UARTINT2),
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-19 00:36:08 +07: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 16:15:38 +07:00
.flags = 0,
}
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-19 00:36:08 +07:00
};
ARM: davinci: serial: get rid of davinci_uart_config "struct davinci_uart_config" was introduced to specify UART ports brought out or enabled on the board. But none of the boards use it for that purpose and we are not going to add anymore board files, so remove the structure. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Suggested-by: Sekhar Nori <nsekhar@ti.com> [nsekhar@ti.com: split patch to remove davinci_serial_setup_clk() changes.] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-06-19 16:15:42 +07:00
struct platform_device dm644x_serial_device[] = {
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 16:15:38 +07:00
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = {
.platform_data = dm644x_serial0_platform_data,
}
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-19 00:36:08 +07: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 16:15:38 +07:00
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM1,
.dev = {
.platform_data = dm644x_serial1_platform_data,
}
},
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM2,
.dev = {
.platform_data = dm644x_serial2_platform_data,
}
},
{
}
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-19 00:36:08 +07:00
};
ARM: davinci: make davinci_soc_info structures const Make davinci_soc_info structures const as they are either passed to the function davinci_common_init having the argument as const or their field cpu_clks of type struct clk_lookup * is passed to the function davinci_clk_init. So, the fields are never modified and the structures can be const. Done using Coccinelle. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> [nsekhar@ti.com: minor commit message adjustment] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2017-10-16 17:08:24 +07:00
static const struct davinci_soc_info davinci_soc_info_dm644x = {
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-16 02:38:58 +07:00
.io_desc = dm644x_io_desc,
.io_desc_num = ARRAY_SIZE(dm644x_io_desc),
Davinci: jtag_id - use ioremap() This patch replaces the jtag id base info in davinci_soc_info with a physical address which is then ioremap()ed within common code. This patch (in combination with a similar change for PSC) will allow us to eliminate the SYSCFG nastiness in DA8xx code. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-08 04:06:34 +07:00
.jtag_id_reg = 0x01c40028,
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-16 02:39:09 +07:00
.ids = dm644x_ids,
.ids_num = ARRAY_SIZE(dm644x_ids),
Davinci: pinmux - use ioremap() This patch modifies the pinmux implementation so as to ioremap() the pinmux register area on first use. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-08 04:06:38 +07:00
.pinmux_base = DAVINCI_SYSTEM_MODULE_BASE,
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-16 02:39:48 +07:00
.pinmux_pins = dm644x_pins,
.pinmux_pins_num = ARRAY_SIZE(dm644x_pins),
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-16 02:40:11 +07:00
.timer_info = &dm644x_timer_info,
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-16 02:40:56 +07:00
.emac_pdata = &dm644x_emac_pdata,
davinci: soc-specific SRAM setup Package on-chip SRAM. It's always accessible from the ARM, so set up a standardized virtual address mapping into a 128 KiB area that's reserved for platform use. In some cases (dm6467) the physical addresses used for EDMA are not the same as the ones used by the ARM ... so record that info separately in the SOC data, for chips (unlike the OMAP-L137) where SRAM may be used with EDMA. Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM, may be unused/available on some system. They are ignored here. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-01 07:35:48 +07:00
.sram_dma = 0x00008000,
.sram_len = SZ_16K,
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-16 02:38:58 +07:00
};
ARM: davinci: remove unused davinci-i2s pdata The davinci-i2s driver ("davinci-mcbsp") does not use platform data any longer. Remove the dummy pdata provided by the board drivers dm355, dm365, dm644x and neuros-osd2. Signed-off-by: Petr Kulhavy <petr@barix.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2016-05-09 20:59:48 +07:00
void __init dm644x_init_asp(void)
davinci: ASoC: Add the platform devices for ASP 1) Registers the platform devices for ASP on dm355, dm644x and dm646x so that the machine driver can probe to get ASP related platform data. 2) Move towards definition of the asp clocks using physical name(for dm355 and dm644x) 3) Add platform data to board specific files. Signed-off-by: Naresh Medisetty <naresh@ti.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-06-05 17:28:08 +07:00
{
davinci_cfg_reg(DM644X_MCBSP);
platform_device_register(&dm644x_asp_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 23:30:11 +07: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-16 02:38:58 +07:00
davinci_common_init(&davinci_soc_info_dm644x);
ARM: davinci: streamline sysmod access There are instances of IO_ADDRESS() being used for system module (sysmod) register access. Eliminate this in favor of a ioremap() based access. ioremap() the entire sysmod address space once during boot-up and provide a helper macro to access specific register offsets within the address space. With this, also eliminate ioremap() of specific sysmodule registers related to VPIF happening in DM646x EVM code. While at it, also eliminate some duplicate sysmod register offset macros defined in code and place offset definitions at one place in davinci.h Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Acked-by: Arnd Bergmann <arnd@arndb.de> [nsekhar@ti.com: removed the addition of ifndef __ASSEMBLER__ in davinci.h, eliminate IO_ADDRESS() usage left out in dm646x.c, cleanup VPIF sysmodule register access as part of this patch and keep all sysmod offsets in davinci.h Also, convert the WARN_ON() on failure to setup sysmod base to BUG_ON()] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:36 +07:00
davinci_map_sysmod();
ARM: davinci: move davinci_clk_init() to init_time This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. dm646x is a special case because we need to handle different ref_clk rates depending on which board is being used. The clock init in this case is modified to set the rate before registering the clocks instead of using davinci_set_refclk_rate() to recalculate the entire clock tree after all of the clocks are registered. Also, the cpu_clks field is removed from struct davinci_soc_info since it is no longer needed. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-01-20 10:20:22 +07:00
}
void __init dm644x_init_time(void)
{
ARM: davinci: dm644x: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm644x.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also clean up the #includes since we are adding some here. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-05-18 23:48:11 +07:00
void __iomem *pll1, *psc;
struct clk *clk;
clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DM644X_REF_FREQ);
pll1 = ioremap(DAVINCI_PLL1_BASE, SZ_1K);
dm644x_pll1_init(NULL, pll1, NULL);
psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K);
dm644x_psc_init(NULL, psc);
clk = clk_get(NULL, "timer0");
davinci_timer_init(clk);
}
static struct resource dm644x_pll2_resources[] = {
{
.start = DAVINCI_PLL2_BASE,
.end = DAVINCI_PLL2_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device dm644x_pll2_device = {
.name = "dm644x-pll2",
.id = -1,
.resource = dm644x_pll2_resources,
.num_resources = ARRAY_SIZE(dm644x_pll2_resources),
};
void __init dm644x_register_clocks(void)
{
/* PLL1 and PSC are registered in dm644x_init_time() */
platform_device_register(&dm644x_pll2_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 23:30:11 +07:00
}
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
int __init dm644x_init_video(struct vpfe_config *vpfe_cfg,
struct vpbe_config *vpbe_cfg)
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 23:30:11 +07:00
{
ARM: davinci: dm644x: add support for v4l2 video display Add functions to register various video devices like venc, osd, vpbe and the v4l2 display driver for dm644x. Change dm644x_init_video() to make room for display related configuration. Register the vpfe or vpbe devices only if valid display configuration is provided to make sure boards without video support dont erroneously register video devices. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-02-23 16:47:45 +07:00
if (vpfe_cfg || vpbe_cfg)
platform_device_register(&dm644x_vpss_device);
if (vpfe_cfg) {
dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
platform_device_register(&dm644x_ccdc_dev);
platform_device_register(&dm644x_vpfe_dev);
}
if (vpbe_cfg) {
dm644x_vpbe_dev.dev.platform_data = vpbe_cfg;
platform_device_register(&dm644x_osd_dev);
platform_device_register(&dm644x_venc_dev);
platform_device_register(&dm644x_vpbe_dev);
platform_device_register(&dm644x_vpbe_display);
}
ARM: davinci: dm644x: don't force vpfe registeration on all boards Move all vpfe platform device registrations to the board specific file. This removes registration of vpfe platform devices on boards which do not use vpfe. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:39 +07:00
return 0;
}
ARM: davinci: aintc: use the new irqchip config structure in dm* SoCs Add the new-style config structures for dm* SoCs. They will be used once we make the aintc driver stop using davinci_soc_info. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 21:52:10 +07:00
static const struct davinci_aintc_config dm644x_aintc_config = {
.reg = {
.start = DAVINCI_ARM_INTC_BASE,
.end = DAVINCI_ARM_INTC_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
.num_irqs = 64,
.prios = dm644x_default_priorities,
};
ARM: davinci: aintc: wrap davinci_irq_init() with a helper We're going to extend the davinci_irq_init() function with a config structure so we can drop the intc-related fields from davinci_soc_info. Once we do it, we won't be able to use this routine directly as the init_irq callback. Wrap the calls in additional helpers that don't take parameters and can be assigned to init_irq. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 21:52:05 +07:00
void __init dm644x_init_irq(void)
{
ARM: davinci: aintc: use the new config structure Modify the aintc driver to take all its configuration from the new config structure. Stop referencing davinci_soc_info in any way. Move the declaration for davinci_aintc_init() to irq-davinci-aintc.h and make it take the new config structure as parameter. Convert all users to the new version. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 21:52:11 +07:00
davinci_aintc_init(&dm644x_aintc_config);
ARM: davinci: aintc: wrap davinci_irq_init() with a helper We're going to extend the davinci_irq_init() function with a config structure so we can drop the intc-related fields from davinci_soc_info. Once we do it, we won't be able to use this routine directly as the init_irq callback. Wrap the calls in additional helpers that don't take parameters and can be assigned to init_irq. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-02-14 21:52:05 +07:00
}
ARM: davinci: dm644x: remove unnecessary postcore_initcall() dm644x_init_devices() is unnecessarily implemented as a postcore_initcall(). This does not cause any issues now, but creates issues when converting to common clock framework where clocks themselves become platform devices and are initialized later. Because of this, device clock acquisition and runtime PM on that device fails. Move the call to .init_machine() callback along with rest of platform device's registration. While at it, convert it to return void since return value is ignored by caller anyway. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-04-06 19:38:20 +07:00
void __init dm644x_init_devices(void)
ARM: davinci: dm644x: don't force vpfe registeration on all boards Move all vpfe platform device registrations to the board specific file. This removes registration of vpfe platform devices on boards which do not use vpfe. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:39 +07: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 18:42:51 +07:00
struct platform_device *edma_pdev;
ARM: davinci: dm644x: remove unnecessary postcore_initcall() dm644x_init_devices() is unnecessarily implemented as a postcore_initcall(). This does not cause any issues now, but creates issues when converting to common clock framework where clocks themselves become platform devices and are initialized later. Because of this, device clock acquisition and runtime PM on that device fails. Move the call to .init_machine() callback along with rest of platform device's registration. While at it, convert it to return void since return value is ignored by caller anyway. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-04-06 19:38:20 +07:00
int ret;
ARM: davinci: dm644x: don't force vpfe registeration on all boards Move all vpfe platform device registrations to the board specific file. This removes registration of vpfe platform devices on boards which do not use vpfe. Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-21 20:43:39 +07: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 18:42:51 +07:00
edma_pdev = platform_device_register_full(&dm644x_edma_device);
ARM: davinci: dm644x: remove unnecessary postcore_initcall() dm644x_init_devices() is unnecessarily implemented as a postcore_initcall(). This does not cause any issues now, but creates issues when converting to common clock framework where clocks themselves become platform devices and are initialized later. Because of this, device clock acquisition and runtime PM on that device fails. Move the call to .init_machine() callback along with rest of platform device's registration. While at it, convert it to return void since return value is ignored by caller anyway. Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2018-04-06 19:38:20 +07:00
if (IS_ERR(edma_pdev))
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 18:42:51 +07:00
pr_warn("%s: Failed to register eDMA\n", __func__);
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 21:11:22 +07:00
platform_device_register(&dm644x_mdio_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-16 02:40:56 +07:00
platform_device_register(&dm644x_emac_device);
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 21:11:22 +07:00
ARM: davinci: da8xx: fix multiple watchdog device registration Fix multiple watchdog device registration on da8xx devices due to davinci_init_devices blindly registering watchdog device. Fix this by getting rid of the initcall and instead registering watchdog for each soc. Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2014-02-26 11:59:43 +07:00
ret = davinci_init_wdt();
if (ret)
pr_warn("%s: watchdog init failed: %d\n", __func__, ret);
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 23:30:11 +07:00
}
Reference in New Issue Copy Permalink