iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
39ec7e9b69
linux/arch/arm/mach-davinci/dm355.c

837 lines
21 KiB
C
Raw Normal View History

davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
/*
* TI DaVinci DM355 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: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
#include <linux/clk-provider.h>
#include <linux/clk/davinci.h>
#include <linux/clkdev.h>
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
#include <linux/dma-mapping.h>
ARM: davinci: dm355: 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 15:43:14 +03:00
#include <linux/dmaengine.h>
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
#include <linux/init.h>
clk: Remove io.h from clk-provider.h Now that we've gotten rid of clk_readl() we can remove io.h from the clk-provider header and push out the io.h include to any code that isn't already including the io.h header but using things like readl/writel, etc. Found with this grep: git grep -l clk-provider.h | grep '.c$' | xargs git grep -L 'linux/io.h' | \ xargs git grep -l \ -e '\<__iowrite32_copy\>' --or \ -e '\<__ioread32_copy\>' --or \ -e '\<__iowrite64_copy\>' --or \ -e '\<ioremap_page_range\>' --or \ -e '\<ioremap_huge_init\>' --or \ -e '\<arch_ioremap_pud_supported\>' --or \ -e '\<arch_ioremap_pmd_supported\>' --or \ -e '\<devm_ioport_map\>' --or \ -e '\<devm_ioport_unmap\>' --or \ -e '\<IOMEM_ERR_PTR\>' --or \ -e '\<devm_ioremap\>' --or \ -e '\<devm_ioremap_nocache\>' --or \ -e '\<devm_ioremap_wc\>' --or \ -e '\<devm_iounmap\>' --or \ -e '\<devm_ioremap_release\>' --or \ -e '\<devm_memremap\>' --or \ -e '\<devm_memunmap\>' --or \ -e '\<__devm_memremap_pages\>' --or \ -e '\<pci_remap_cfgspace\>' --or \ -e '\<arch_has_dev_port\>' --or \ -e '\<arch_phys_wc_add\>' --or \ -e '\<arch_phys_wc_del\>' --or \ -e '\<memremap\>' --or \ -e '\<memunmap\>' --or \ -e '\<arch_io_reserve_memtype_wc\>' --or \ -e '\<arch_io_free_memtype_wc\>' --or \ -e '\<__io_aw\>' --or \ -e '\<__io_pbw\>' --or \ -e '\<__io_paw\>' --or \ -e '\<__io_pbr\>' --or \ -e '\<__io_par\>' --or \ -e '\<__raw_readb\>' --or \ -e '\<__raw_readw\>' --or \ -e '\<__raw_readl\>' --or \ -e '\<__raw_readq\>' --or \ -e '\<__raw_writeb\>' --or \ -e '\<__raw_writew\>' --or \ -e '\<__raw_writel\>' --or \ -e '\<__raw_writeq\>' --or \ -e '\<readb\>' --or \ -e '\<readw\>' --or \ -e '\<readl\>' --or \ -e '\<readq\>' --or \ -e '\<writeb\>' --or \ -e '\<writew\>' --or \ -e '\<writel\>' --or \ -e '\<writeq\>' --or \ -e '\<readb_relaxed\>' --or \ -e '\<readw_relaxed\>' --or \ -e '\<readl_relaxed\>' --or \ -e '\<readq_relaxed\>' --or \ -e '\<writeb_relaxed\>' --or \ -e '\<writew_relaxed\>' --or \ -e '\<writel_relaxed\>' --or \ -e '\<writeq_relaxed\>' --or \ -e '\<readsb\>' --or \ -e '\<readsw\>' --or \ -e '\<readsl\>' --or \ -e '\<readsq\>' --or \ -e '\<writesb\>' --or \ -e '\<writesw\>' --or \ -e '\<writesl\>' --or \ -e '\<writesq\>' --or \ -e '\<inb\>' --or \ -e '\<inw\>' --or \ -e '\<inl\>' --or \ -e '\<outb\>' --or \ -e '\<outw\>' --or \ -e '\<outl\>' --or \ -e '\<inb_p\>' --or \ -e '\<inw_p\>' --or \ -e '\<inl_p\>' --or \ -e '\<outb_p\>' --or \ -e '\<outw_p\>' --or \ -e '\<outl_p\>' --or \ -e '\<insb\>' --or \ -e '\<insw\>' --or \ -e '\<insl\>' --or \ -e '\<outsb\>' --or \ -e '\<outsw\>' --or \ -e '\<outsl\>' --or \ -e '\<insb_p\>' --or \ -e '\<insw_p\>' --or \ -e '\<insl_p\>' --or \ -e '\<outsb_p\>' --or \ -e '\<outsw_p\>' --or \ -e '\<outsl_p\>' --or \ -e '\<ioread8\>' --or \ -e '\<ioread16\>' --or \ -e '\<ioread32\>' --or \ -e '\<ioread64\>' --or \ -e '\<iowrite8\>' --or \ -e '\<iowrite16\>' --or \ -e '\<iowrite32\>' --or \ -e '\<iowrite64\>' --or \ -e '\<ioread16be\>' --or \ -e '\<ioread32be\>' --or \ -e '\<ioread64be\>' --or \ -e '\<iowrite16be\>' --or \ -e '\<iowrite32be\>' --or \ -e '\<iowrite64be\>' --or \ -e '\<ioread8_rep\>' --or \ -e '\<ioread16_rep\>' --or \ -e '\<ioread32_rep\>' --or \ -e '\<ioread64_rep\>' --or \ -e '\<iowrite8_rep\>' --or \ -e '\<iowrite16_rep\>' --or \ -e '\<iowrite32_rep\>' --or \ -e '\<iowrite64_rep\>' --or \ -e '\<__io_virt\>' --or \ -e '\<pci_iounmap\>' --or \ -e '\<virt_to_phys\>' --or \ -e '\<phys_to_virt\>' --or \ -e '\<ioremap_uc\>' --or \ -e '\<ioremap\>' --or \ -e '\<__ioremap\>' --or \ -e '\<iounmap\>' --or \ -e '\<ioremap\>' --or \ -e '\<ioremap_nocache\>' --or \ -e '\<ioremap_uc\>' --or \ -e '\<ioremap_wc\>' --or \ -e '\<ioremap_wc\>' --or \ -e '\<ioremap_wt\>' --or \ -e '\<ioport_map\>' --or \ -e '\<ioport_unmap\>' --or \ -e '\<ioport_map\>' --or \ -e '\<ioport_unmap\>' --or \ -e '\<xlate_dev_kmem_ptr\>' --or \ -e '\<xlate_dev_mem_ptr\>' --or \ -e '\<unxlate_dev_mem_ptr\>' --or \ -e '\<virt_to_bus\>' --or \ -e '\<bus_to_virt\>' --or \ -e '\<memset_io\>' --or \ -e '\<memcpy_fromio\>' --or \ -e '\<memcpy_toio\>' I also reordered a couple includes when they weren't alphabetical and removed clk.h from kona, replacing it with clk-provider.h because that driver doesn't use clk consumer APIs. Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Tero Kristo <t-kristo@ti.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Cc: Chris Zankel <chris@zankel.net> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: John Crispin <john@phrozen.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-04-19 01:20:22 +03:00
#include <linux/io.h>
ARM: davinci: 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 17:52:10 +03:00
#include <linux/irqchip/irq-davinci-aintc.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 09:19:00 +04:00
#include <linux/platform_data/edma.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/platform_data/spi-davinci.h>
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
#include <linux/platform_device.h>
#include <linux/serial_8250.h>
#include <linux/spi/spi.h>
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
davinci: Encapsulate SoC-specific data in a structure Create a structure to encapsulate SoC-specific information. This will assist in generalizing code so it can be used by different SoCs that have similar hardware but with minor differences such as having a different base address. The idea is that the code for each SoC fills out a structure with the correct information. The board-specific code then calls the SoC init routine which in turn will call a common init routine that makes a copy of the structure, maps in I/O regions, etc. After initialization, code can get a pointer to the structure by calling davinci_get_soc_info(). Eventually, the common init routine will make a copy of all of the data pointed to by the structure so the original data can be made __init_data. That way the data for SoC's that aren't being used won't consume memory for the entire life of the kernel. The structure will be extended in subsequent patches but initially, it holds the map_desc structure for any I/O regions the SoC/board wants statically mapped. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:38:58 +04:00
#include <asm/mach/map.h>
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
#include <mach/common.h>
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
#include <mach/cputype.h>
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
#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-18 20:36:08 +03:00
#include <mach/serial.h>
ARM: davinci: dm355: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the dm355 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 16:17:44 +03:00
#include <clocksource/timer-davinci.h>
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03: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 17:43:35 +04: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 17:52:03 +03:00
#include "irqs.h"
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
#include "mux.h"
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
davinci: cleanup: move dm355 UART2 define to dm355.c Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-30 22:20:24 +04:00
#define DM355_UART2_BASE (IO_PHYS + 0x206000)
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
#define DM355_OSD_BASE (IO_PHYS + 0x70200)
#define DM355_VENC_BASE (IO_PHYS + 0x70400)
davinci: cleanup: move dm355 UART2 define to dm355.c Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-30 22:20:24 +04:00
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
/*
* Device specific clocks
*/
#define DM355_REF_FREQ 24000000 /* 24 or 36 MHz */
static u64 dm355_spi0_dma_mask = DMA_BIT_MASK(32);
static struct resource dm355_spi0_resources[] = {
{
.start = 0x01c66000,
.end = 0x01c667ff,
.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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_SPINT0_0),
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
.flags = IORESOURCE_IRQ,
},
};
DaVinci DM355: Modifications to DM355 SPI support This patch does the following 1) Minor change to the SPI clocks making it similar to DM365. 2) Changing the interrupt used by SPI0 3) Adding EDMA resources that can be used by SPI0 4) Adding platform specific data. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-01 17:51:15 +03:00
static struct davinci_spi_platform_data dm355_spi0_pdata = {
.version = SPI_VERSION_1,
.num_chipselect = 2,
spi: davinci: always start transmit DMA Due to the full duplex nature of the SPI bus, the SPI master on DaVinci needs transmit to be active even if the tranfer is only meant to collect receive data. The current code achieves this by using a temporary zeroed buffer to provide DMA data in case the transfer does not have a transmit buffer provided. However, the transmit DMA is started only if transmit buffer is provided rendering the temporary buffer unused. Instead the code relies on a write to SPIDAT1 register to trigger transmit operation. This however only sends two bytes of data. Fix this by starting transmit DMA always. This changes exposes a bug on DM355 where the CSHOLD bit in SPIDAT1 needs to be written to in between transfers. Handle that by introducing a "cshold_bug" platform data which is set to true for DM355. Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com> Tested-By: Michael Williamson <michael.williamson@criticallink.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2010-09-28 12:29:26 +04:00
.cshold_bug = true,
davinci: spi: move event queue parameter to platform data For DMA operation, the davinci spi driver needs an event queue number. Currently, this number is passed as a IORESOURCE_DMA. This is not correct, as the event queue is not a DMA channel. Pass the event queue via the platform data structure instead. On dm355 and dm365, move the eventq assignment for spi0 out of resources array and into platform data. Signed-off-by: Michael Williamson <michael.williamson@criticallink.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-02-08 15:59:55 +03:00
.dma_event_q = EVENTQ_1,
ARM: davinci: Set proper SPI prescale limit value SPI Davinci driver has been updated to allow SOCs to specify their minimum prescale value. Update the various SOCs board files that use this driver with their proper prescaler limit. Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12 16:26:19 +03:00
.prescaler_limit = 1,
DaVinci DM355: Modifications to DM355 SPI support This patch does the following 1) Minor change to the SPI clocks making it similar to DM365. 2) Changing the interrupt used by SPI0 3) Adding EDMA resources that can be used by SPI0 4) Adding platform specific data. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-01 17:51:15 +03:00
};
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
static struct platform_device dm355_spi0_device = {
.name = "spi_davinci",
.id = 0,
.dev = {
.dma_mask = &dm355_spi0_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
DaVinci DM355: Modifications to DM355 SPI support This patch does the following 1) Minor change to the SPI clocks making it similar to DM365. 2) Changing the interrupt used by SPI0 3) Adding EDMA resources that can be used by SPI0 4) Adding platform specific data. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-01 17:51:15 +03:00
.platform_data = &dm355_spi0_pdata,
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
},
.num_resources = ARRAY_SIZE(dm355_spi0_resources),
.resource = dm355_spi0_resources,
};
void __init dm355_init_spi0(unsigned chipselect_mask,
ARM: davinci: mark spi_board_info arguments as const spi_board_info is not modified in any of the spi registeration functions and passed along as-is to the generic SPI layer. Mark spi_board_info arguments as const to signal this. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [nsekhar@ti.com: extended for dm365 and dm355] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2012-03-31 00:13:53 +04:00
const struct spi_board_info *info, unsigned len)
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
{
/* for now, assume we need MISO */
davinci_cfg_reg(DM355_SPI0_SDI);
/* not all slaves will be wired up */
if (chipselect_mask & BIT(0))
davinci_cfg_reg(DM355_SPI0_SDENA0);
if (chipselect_mask & BIT(1))
davinci_cfg_reg(DM355_SPI0_SDENA1);
spi_register_board_info(info, len);
platform_device_register(&dm355_spi0_device);
}
/*----------------------------------------------------------------------*/
davinci: Move PINMUX defines to SoC files Different SoC have different numbers of pinmux registers and other resources that overlap with each other. To clean up the code and eliminate defines that overlap with each other, move the PINMUX defines to the SoC specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:42:06 +04:00
#define INTMUX 0x18
#define EVTMUX 0x1c
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
/*
* Device specific mux setup
*
* soc description mux mode mode mux dbg
* reg offset mask mode
*/
static const struct mux_config dm355_pins[] = {
davinci: Move pinmux setup info to SoC infrastructure The pinmux register base and setup can be different for different SoCs so move the pinmux reg base, pinmux table (and its size) to the SoC infrastructure. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:39:48 +04:00
#ifdef CONFIG_DAVINCI_MUX
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
MUX_CFG(DM355, MMCSD0, 4, 2, 1, 0, false)
MUX_CFG(DM355, SD1_CLK, 3, 6, 1, 1, false)
MUX_CFG(DM355, SD1_CMD, 3, 7, 1, 1, false)
MUX_CFG(DM355, SD1_DATA3, 3, 8, 3, 1, false)
MUX_CFG(DM355, SD1_DATA2, 3, 10, 3, 1, false)
MUX_CFG(DM355, SD1_DATA1, 3, 12, 3, 1, false)
MUX_CFG(DM355, SD1_DATA0, 3, 14, 3, 1, false)
MUX_CFG(DM355, I2C_SDA, 3, 19, 1, 1, false)
MUX_CFG(DM355, I2C_SCL, 3, 20, 1, 1, false)
MUX_CFG(DM355, MCBSP0_BDX, 3, 0, 1, 1, false)
MUX_CFG(DM355, MCBSP0_X, 3, 1, 1, 1, false)
MUX_CFG(DM355, MCBSP0_BFSX, 3, 2, 1, 1, false)
MUX_CFG(DM355, MCBSP0_BDR, 3, 3, 1, 1, false)
MUX_CFG(DM355, MCBSP0_R, 3, 4, 1, 1, false)
MUX_CFG(DM355, MCBSP0_BFSR, 3, 5, 1, 1, false)
MUX_CFG(DM355, SPI0_SDI, 4, 1, 1, 0, false)
MUX_CFG(DM355, SPI0_SDENA0, 4, 0, 1, 0, false)
MUX_CFG(DM355, SPI0_SDENA1, 3, 28, 1, 1, false)
INT_CFG(DM355, INT_EDMA_CC, 2, 1, 1, false)
INT_CFG(DM355, INT_EDMA_TC0_ERR, 3, 1, 1, false)
INT_CFG(DM355, INT_EDMA_TC1_ERR, 4, 1, 1, false)
EVT_CFG(DM355, EVT8_ASP1_TX, 0, 1, 0, false)
EVT_CFG(DM355, EVT9_ASP1_RX, 1, 1, 0, false)
EVT_CFG(DM355, EVT26_MMC0_RX, 2, 1, 0, false)
DaVinci: DM355: Adding PINMUX entries for DM355 Display This patch adds PINMUX entries for DM355 Display. These will be used by the DM355 display driver. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-21 20:38:11 +04:00
MUX_CFG(DM355, VOUT_FIELD, 1, 18, 3, 1, false)
MUX_CFG(DM355, VOUT_FIELD_G70, 1, 18, 3, 0, false)
MUX_CFG(DM355, VOUT_HVSYNC, 1, 16, 1, 0, false)
MUX_CFG(DM355, VOUT_COUTL_EN, 1, 0, 0xff, 0x55, false)
MUX_CFG(DM355, VOUT_COUTH_EN, 1, 8, 0xff, 0x55, false)
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04:00
MUX_CFG(DM355, VIN_PCLK, 0, 14, 1, 1, false)
MUX_CFG(DM355, VIN_CAM_WEN, 0, 13, 1, 1, false)
MUX_CFG(DM355, VIN_CAM_VD, 0, 12, 1, 1, false)
MUX_CFG(DM355, VIN_CAM_HD, 0, 11, 1, 1, false)
MUX_CFG(DM355, VIN_YIN_EN, 0, 10, 1, 1, false)
MUX_CFG(DM355, VIN_CINL_EN, 0, 0, 0xff, 0x55, false)
MUX_CFG(DM355, VIN_CINH_EN, 0, 8, 3, 3, false)
davinci: Move pinmux setup info to SoC infrastructure The pinmux register base and setup can be different for different SoCs so move the pinmux reg base, pinmux table (and its size) to the SoC infrastructure. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:39:48 +04:00
#endif
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
};
davinci: Move interrupt ctlr info to SoC infrastructure Use the SoC infrastructure to hold the interrupt controller information (i.e., base address, default priorities, interrupt controller type, and the number of IRQs). The interrupt controller base, although initially put in the soc_info structure's intc_base field, is eventually put in the global 'davinci_intc_base' so the low-level interrupt code can access it without a dereference. These changes enable the SoC default irq priorities to be put in the SoC-specific files, and the interrupt controller to be at any base address. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:40:00 +04:00
static u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_DM355_CCDC_VDINT0] = 2,
[IRQ_DM355_CCDC_VDINT1] = 6,
[IRQ_DM355_CCDC_VDINT2] = 6,
[IRQ_DM355_IPIPE_HST] = 6,
[IRQ_DM355_H3AINT] = 6,
[IRQ_DM355_IPIPE_SDR] = 6,
[IRQ_DM355_IPIPEIFINT] = 6,
[IRQ_DM355_OSDINT] = 7,
[IRQ_DM355_VENCINT] = 6,
[IRQ_ASQINT] = 6,
[IRQ_IMXINT] = 6,
[IRQ_USBINT] = 4,
[IRQ_DM355_RTOINT] = 4,
[IRQ_DM355_UARTINT2] = 7,
[IRQ_DM355_TINT6] = 7,
[IRQ_CCINT0] = 5, /* dma */
[IRQ_CCERRINT] = 5, /* dma */
[IRQ_TCERRINT0] = 5, /* dma */
[IRQ_TCERRINT] = 5, /* dma */
[IRQ_DM355_SPINT2_1] = 7,
[IRQ_DM355_TINT7] = 4,
[IRQ_DM355_SDIOINT0] = 7,
[IRQ_MBXINT] = 7,
[IRQ_MBRINT] = 7,
[IRQ_MMCINT] = 7,
[IRQ_DM355_MMCINT1] = 7,
[IRQ_DM355_PWMINT3] = 7,
[IRQ_DDRINT] = 7,
[IRQ_AEMIFINT] = 7,
[IRQ_DM355_SDIOINT1] = 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_DM355_SPINT0_0] = 3,
[IRQ_DM355_SPINT0_1] = 3,
[IRQ_DM355_GPIO0] = 3,
[IRQ_DM355_GPIO1] = 7,
[IRQ_DM355_GPIO2] = 4,
[IRQ_DM355_GPIO3] = 4,
[IRQ_DM355_GPIO4] = 7,
[IRQ_DM355_GPIO5] = 7,
[IRQ_DM355_GPIO6] = 7,
[IRQ_DM355_GPIO7] = 7,
[IRQ_DM355_GPIO8] = 7,
[IRQ_DM355_GPIO9] = 7,
[IRQ_DM355_GPIOBNK0] = 7,
[IRQ_DM355_GPIOBNK1] = 7,
[IRQ_DM355_GPIOBNK2] = 7,
[IRQ_DM355_GPIOBNK3] = 7,
[IRQ_DM355_GPIOBNK4] = 7,
[IRQ_DM355_GPIOBNK5] = 7,
[IRQ_DM355_GPIOBNK6] = 7,
[IRQ_COMMTX] = 7,
[IRQ_COMMRX] = 7,
[IRQ_EMUINT] = 7,
};
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04: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 14:42:46 +03: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 15:41:35 +04:00
/* {event queue no, Priority} */
{0, 3},
{1, 7},
{-1, -1},
};
ARM: davinci: dm355: 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 15:43:14 +03:00
static const struct dma_slave_map dm355_edma_map[] = {
{ "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcbsp.1", "tx", EDMA_FILTER_PARAM(0, 8) },
{ "davinci-mcbsp.1", "rx", EDMA_FILTER_PARAM(0, 9) },
{ "spi_davinci.2", "tx", EDMA_FILTER_PARAM(0, 10) },
{ "spi_davinci.2", "rx", EDMA_FILTER_PARAM(0, 11) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 15) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 16) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 17) },
{ "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
{ "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
{ "dm6441-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
{ "dm6441-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
};
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 14:42:46 +03:00
static struct edma_soc_info dm355_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 10:05:12 +04: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 17:14:35 +04:00
.default_queue = EVENTQ_1,
ARM: davinci: dm355: 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 15:43:14 +03:00
.slave_map = dm355_edma_map,
.slavecnt = ARRAY_SIZE(dm355_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 10:05:12 +04:00
};
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04: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 14:42:46 +03:00
.name = "edma3_cc",
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04: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 14:42:46 +03:00
.name = "edma3_tc0",
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04: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 14:42:46 +03:00
.name = "edma3_tc1",
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04: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 14:42:46 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_CCINT0),
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04: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 14:42:46 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_CCERRINT),
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
.flags = IORESOURCE_IRQ,
},
/* not using (or muxing) 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 14:42:51 +03:00
static const struct platform_device_info dm355_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 14:42:52 +03: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 14:42:51 +03:00
.res = edma_resources,
.num_res = ARRAY_SIZE(edma_resources),
.data = &dm355_edma_pdata,
.size_data = sizeof(dm355_edma_pdata),
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04: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 14:28:08 +04:00
static struct resource dm355_asp1_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 18:48:17 +04: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 14:28:08 +04:00
.start = DAVINCI_ASP1_BASE,
.end = DAVINCI_ASP1_BASE + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
{
.start = DAVINCI_DMA_ASP1_TX,
.end = DAVINCI_DMA_ASP1_TX,
.flags = IORESOURCE_DMA,
},
{
.start = DAVINCI_DMA_ASP1_RX,
.end = DAVINCI_DMA_ASP1_RX,
.flags = IORESOURCE_DMA,
},
};
static struct platform_device dm355_asp1_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 15:27:09 +03:00
.name = "davinci-mcbsp",
davinci: audio clocks: use struct device instead of clock names There is no need to pass clock name strings in platform_data. Instead, setup clkdev nodes to have correct ASoC device names. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-07-15 19:47:48 +04:00
.id = 1,
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 14:28:08 +04:00
.num_resources = ARRAY_SIZE(dm355_asp1_resources),
.resource = dm355_asp1_resources,
};
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 02:27:08 +03:00
static void dm355_ccdc_setup_pinmux(void)
{
davinci_cfg_reg(DM355_VIN_PCLK);
davinci_cfg_reg(DM355_VIN_CAM_WEN);
davinci_cfg_reg(DM355_VIN_CAM_VD);
davinci_cfg_reg(DM355_VIN_CAM_HD);
davinci_cfg_reg(DM355_VIN_YIN_EN);
davinci_cfg_reg(DM355_VIN_CINL_EN);
davinci_cfg_reg(DM355_VIN_CINH_EN);
}
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04:00
static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
.name = "vpss",
.start = 0x01c70800,
.end = 0x01c70800 + 0xff,
.flags = IORESOURCE_MEM,
},
{
/* VPSS CLK Base address */
.name = "vpss",
.start = 0x01c70000,
.end = 0x01c70000 + 0xf,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device dm355_vpss_device = {
.name = "vpss",
.id = -1,
.dev.platform_data = "dm355_vpss",
.num_resources = ARRAY_SIZE(dm355_vpss_resources),
.resource = dm355_vpss_resources,
};
static struct resource vpfe_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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_VDINT0),
.end = DAVINCI_INTC_IRQ(IRQ_VDINT0),
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_VDINT1),
.end = DAVINCI_INTC_IRQ(IRQ_VDINT1),
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04: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 02:27:08 +03:00
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct resource dm355_ccdc_resource[] = {
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04:00
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
.start = 0x01c70600,
.end = 0x01c70600 + 0x1ff,
},
};
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 02:27:08 +03:00
static struct platform_device dm355_ccdc_dev = {
.name = "dm355_ccdc",
.id = -1,
.num_resources = ARRAY_SIZE(dm355_ccdc_resource),
.resource = dm355_ccdc_resource,
.dev = {
.dma_mask = &vpfe_capture_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = dm355_ccdc_setup_pinmux,
},
};
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04:00
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
.num_resources = ARRAY_SIZE(vpfe_resources),
.resource = vpfe_resources,
.dev = {
.dma_mask = &vpfe_capture_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
static struct resource dm355_osd_resources[] = {
{
.start = DM355_OSD_BASE,
.end = DM355_OSD_BASE + 0x17f,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device dm355_osd_dev = {
.name = DM355_VPBE_OSD_SUBDEV_NAME,
.id = -1,
.num_resources = ARRAY_SIZE(dm355_osd_resources),
.resource = dm355_osd_resources,
.dev = {
.dma_mask = &vpfe_capture_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
static struct resource dm355_venc_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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_VENCINT),
.end = DAVINCI_INTC_IRQ(IRQ_VENCINT),
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
.flags = IORESOURCE_IRQ,
},
/* venc registers io space */
{
.start = DM355_VENC_BASE,
.end = DM355_VENC_BASE + 0x17f,
.flags = IORESOURCE_MEM,
},
/* VDAC config register io space */
{
.start = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
.end = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
.flags = IORESOURCE_MEM,
},
};
static struct resource dm355_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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_VENCINT),
.end = DAVINCI_INTC_IRQ(IRQ_VENCINT),
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
.flags = IORESOURCE_IRQ,
},
/* venc registers io space */
{
.start = DM355_VENC_BASE,
.end = DM355_VENC_BASE + 0x17f,
.flags = IORESOURCE_MEM,
},
};
[media] platform: Make use of media_bus_format enum In order to have subsytem agnostic media bus format definitions we've moved media bus definition to include/uapi/linux/media-bus-format.h and prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT. Reference new definitions in all platform drivers. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-11-10 20:28:31 +03:00
static int dm355_vpbe_setup_pinmux(u32 if_type, int field)
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
{
switch (if_type) {
[media] platform: Make use of media_bus_format enum In order to have subsytem agnostic media bus format definitions we've moved media bus definition to include/uapi/linux/media-bus-format.h and prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT. Reference new definitions in all platform drivers. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-11-10 20:28:31 +03:00
case MEDIA_BUS_FMT_SGRBG8_1X8:
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
davinci_cfg_reg(DM355_VOUT_FIELD_G70);
break;
[media] platform: Make use of media_bus_format enum In order to have subsytem agnostic media bus format definitions we've moved media bus definition to include/uapi/linux/media-bus-format.h and prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT. Reference new definitions in all platform drivers. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-11-10 20:28:31 +03:00
case MEDIA_BUS_FMT_YUYV10_1X20:
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
if (field)
davinci_cfg_reg(DM355_VOUT_FIELD);
else
davinci_cfg_reg(DM355_VOUT_FIELD_G70);
break;
default:
return -EINVAL;
}
davinci_cfg_reg(DM355_VOUT_COUTL_EN);
davinci_cfg_reg(DM355_VOUT_COUTH_EN);
return 0;
}
static int dm355_venc_setup_clock(enum vpbe_enc_timings_type type,
unsigned int pclock)
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04:00
{
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
void __iomem *vpss_clk_ctrl_reg;
vpss_clk_ctrl_reg = DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL);
switch (type) {
case VPBE_ENC_STD:
writel(VPSS_DACCLKEN_ENABLE | VPSS_VENCCLKEN_ENABLE,
vpss_clk_ctrl_reg);
break;
case VPBE_ENC_DV_TIMINGS:
if (pclock > 27000000)
/*
* For HD, use external clock source since we cannot
* support HD mode with internal clocks.
*/
writel(VPSS_MUXSEL_EXTCLK_ENABLE, vpss_clk_ctrl_reg);
break;
default:
return -EINVAL;
}
return 0;
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04:00
}
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
static struct platform_device dm355_vpbe_display = {
.name = "vpbe-v4l2",
.id = -1,
.num_resources = ARRAY_SIZE(dm355_v4l2_disp_resources),
.resource = dm355_v4l2_disp_resources,
.dev = {
.dma_mask = &vpfe_capture_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
ARM: davinci: make file local variables static Make file local variables static in mach-davinci. This fixes sparse warnings of the form: arch/arm/mach-davinci/dm355.c:863:27: warning: symbol 'dm355_venc_pdata' was not declared. Should it be static? Cc: Prabhakar Lad <prabhakar.csengg@gmail.com> Acked-by: Prabhakar Lad <prabhakar.csengg@gmail.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2013-07-12 13:49:03 +04:00
static struct venc_platform_data dm355_venc_pdata = {
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
.setup_pinmux = dm355_vpbe_setup_pinmux,
.setup_clock = dm355_venc_setup_clock,
};
static struct platform_device dm355_venc_dev = {
.name = DM355_VPBE_VENC_SUBDEV_NAME,
.id = -1,
.num_resources = ARRAY_SIZE(dm355_venc_resources),
.resource = dm355_venc_resources,
.dev = {
.dma_mask = &vpfe_capture_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = (void *)&dm355_venc_pdata,
},
};
static struct platform_device dm355_vpbe_dev = {
.name = "vpbe_controller",
.id = -1,
.dev = {
.dma_mask = &vpfe_capture_dma_mask,
.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 09:19:00 +04:00
static struct resource dm355_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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK0),
.end = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK0),
ARM: davinci: dm355: 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 12:35:15 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK1),
.end = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK1),
ARM: davinci: dm355: 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 12:35:15 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK2),
.end = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK2),
ARM: davinci: dm355: 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 12:35:15 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK3),
.end = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK3),
ARM: davinci: dm355: 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 12:35:15 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK4),
.end = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK4),
ARM: davinci: dm355: 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 12:35:15 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK5),
.end = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK5),
ARM: davinci: dm355: 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 12:35:15 +03: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 17:52:01 +03:00
.start = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK6),
.end = DAVINCI_INTC_IRQ(IRQ_DM355_GPIOBNK6),
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 09:19:00 +04:00
.flags = IORESOURCE_IRQ,
},
};
static struct davinci_gpio_platform_data dm355_gpio_platform_data = {
ARM: davinci: dm355: 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 12:35:21 +03: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 09:19:00 +04:00
.ngpio = 104,
};
int __init dm355_gpio_register(void)
{
return davinci_gpio_register(dm355_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 10:45:56 +04:00
ARRAY_SIZE(dm355_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 09:19:00 +04:00
&dm355_gpio_platform_data);
}
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
/*----------------------------------------------------------------------*/
davinci: Encapsulate SoC-specific data in a structure Create a structure to encapsulate SoC-specific information. This will assist in generalizing code so it can be used by different SoCs that have similar hardware but with minor differences such as having a different base address. The idea is that the code for each SoC fills out a structure with the correct information. The board-specific code then calls the SoC init routine which in turn will call a common init routine that makes a copy of the structure, maps in I/O regions, etc. After initialization, code can get a pointer to the structure by calling davinci_get_soc_info(). Eventually, the common init routine will make a copy of all of the data pointed to by the structure so the original data can be made __init_data. That way the data for SoC's that aren't being used won't consume memory for the entire life of the kernel. The structure will be extended in subsequent patches but initially, it holds the map_desc structure for any I/O regions the SoC/board wants statically mapped. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:38:58 +04:00
static struct map_desc dm355_io_desc[] = {
{
.virtual = IO_VIRT,
.pfn = __phys_to_pfn(IO_PHYS),
.length = IO_SIZE,
.type = MT_DEVICE
},
};
davinci: Support JTAG ID register at any address The Davinci cpu_is_davinci_*() macros use the SoC part number and variant retrieved from the JTAG ID register to determine the type of cpu that the kernel is running on. Currently, the code to read the JTAG ID register assumes that the register is always at the same base address. This isn't true on some newer SoCs. To solve this, have the SoC-specific code set the JTAG ID register base address in soc_info structure and add a 'cpu_id' member to it. 'cpu_id' will be used by the cpu_is_davinci_*() macros to match the cpu id. Also move the info used to identify the cpu type into the SoC-specific code to keep all SoC-specific code together. The common code will read the JTAG ID register, search through an array of davinci_id structures to identify the cpu type. Once identified, it will set the 'cpu_id' member of the soc_info structure to the proper value and the cpu_is_davinci_*() macros will now work. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:39:09 +04:00
/* Contents of JTAG ID register used to identify exact cpu type */
static struct davinci_id dm355_ids[] = {
{
.variant = 0x0,
.part_no = 0xb73b,
.manufacturer = 0x00f,
.cpu_id = DAVINCI_CPU_ID_DM355,
.name = "dm355",
},
};
davinci: Add base address and timer flexibility The davinci timer code currently hardcodes the timer register base addresses, the timer irq numbers, and the timers to use for clock events and clocksource. This won't work for some a new SoC so put those values into the soc_info structure and set them up in the SoC-specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:40:11 +04:00
/*
ARM: davinci: dm355: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the dm355 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 16:17:44 +03:00
* Bottom half of timer0 is used for clockevent, top half is used for
* clocksource.
davinci: Add base address and timer flexibility The davinci timer code currently hardcodes the timer register base addresses, the timer irq numbers, and the timers to use for clock events and clocksource. This won't work for some a new SoC so put those values into the soc_info structure and set them up in the SoC-specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:40:11 +04:00
*/
ARM: davinci: dm355: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the dm355 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 16:17:44 +03:00
static const struct davinci_timer_cfg dm355_timer_cfg = {
.reg = DEFINE_RES_IO(DAVINCI_TIMER0_BASE, SZ_4K),
.irq = {
DEFINE_RES_IRQ(DAVINCI_INTC_IRQ(IRQ_TINT0_TINT12)),
DEFINE_RES_IRQ(DAVINCI_INTC_IRQ(IRQ_TINT0_TINT34)),
},
davinci: Add base address and timer flexibility The davinci timer code currently hardcodes the timer register base addresses, the timer irq numbers, and the timers to use for clock events and clocksource. This won't work for some a new SoC so put those values into the soc_info structure and set them up in the SoC-specific files. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:40:11 +04: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 13:15:38 +04:00
static struct plat_serial8250_port dm355_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-18 20:36:08 +03: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 17:52:01 +03: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-18 20:36:08 +03: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 13:15:38 +04:00
{
.flags = 0,
}
};
static struct plat_serial8250_port dm355_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-18 20:36:08 +03: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 17:52:01 +03: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-18 20:36:08 +03: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 13:15:38 +04:00
{
.flags = 0,
}
};
static struct plat_serial8250_port dm355_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-18 20:36:08 +03:00
{
.mapbase = DM355_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 17:52:01 +03:00
.irq = DAVINCI_INTC_IRQ(IRQ_DM355_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-18 20:36:08 +03: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 13:15:38 +04: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-18 20:36:08 +03: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 13:15:42 +04:00
struct platform_device dm355_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 13:15:38 +04:00
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = {
.platform_data = dm355_serial0_platform_data,
}
},
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM1,
.dev = {
.platform_data = dm355_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-18 20:36:08 +03: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 13:15:38 +04:00
{
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM2,
.dev = {
.platform_data = dm355_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-18 20:36:08 +03: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 13:08:24 +03:00
static const struct davinci_soc_info davinci_soc_info_dm355 = {
davinci: Encapsulate SoC-specific data in a structure Create a structure to encapsulate SoC-specific information. This will assist in generalizing code so it can be used by different SoCs that have similar hardware but with minor differences such as having a different base address. The idea is that the code for each SoC fills out a structure with the correct information. The board-specific code then calls the SoC init routine which in turn will call a common init routine that makes a copy of the structure, maps in I/O regions, etc. After initialization, code can get a pointer to the structure by calling davinci_get_soc_info(). Eventually, the common init routine will make a copy of all of the data pointed to by the structure so the original data can be made __init_data. That way the data for SoC's that aren't being used won't consume memory for the entire life of the kernel. The structure will be extended in subsequent patches but initially, it holds the map_desc structure for any I/O regions the SoC/board wants statically mapped. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:38:58 +04:00
.io_desc = dm355_io_desc,
.io_desc_num = ARRAY_SIZE(dm355_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 01:06:34 +04: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-15 23:39:09 +04:00
.ids = dm355_ids,
.ids_num = ARRAY_SIZE(dm355_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 01:06:38 +04: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-15 23:39:48 +04:00
.pinmux_pins = dm355_pins,
.pinmux_pins_num = ARRAY_SIZE(dm355_pins),
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 04:35:48 +04:00
.sram_dma = 0x00010000,
.sram_len = SZ_32K,
davinci: Encapsulate SoC-specific data in a structure Create a structure to encapsulate SoC-specific information. This will assist in generalizing code so it can be used by different SoCs that have similar hardware but with minor differences such as having a different base address. The idea is that the code for each SoC fills out a structure with the correct information. The board-specific code then calls the SoC init routine which in turn will call a common init routine that makes a copy of the structure, maps in I/O regions, etc. After initialization, code can get a pointer to the structure by calling davinci_get_soc_info(). Eventually, the common init routine will make a copy of all of the data pointed to by the structure so the original data can be made __init_data. That way the data for SoC's that aren't being used won't consume memory for the entire life of the kernel. The structure will be extended in subsequent patches but initially, it holds the map_desc structure for any I/O regions the SoC/board wants statically mapped. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:38:58 +04: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 16:59:48 +03:00
void __init dm355_init_asp1(u32 evt_enable)
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 14:28:08 +04:00
{
/* we don't use ASP1 IRQs, or we'd need to mux them ... */
if (evt_enable & ASP1_TX_EVT_EN)
davinci_cfg_reg(DM355_EVT8_ASP1_TX);
if (evt_enable & ASP1_RX_EVT_EN)
davinci_cfg_reg(DM355_EVT9_ASP1_RX);
platform_device_register(&dm355_asp1_device);
}
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
void __init dm355_init(void)
{
davinci: Encapsulate SoC-specific data in a structure Create a structure to encapsulate SoC-specific information. This will assist in generalizing code so it can be used by different SoCs that have similar hardware but with minor differences such as having a different base address. The idea is that the code for each SoC fills out a structure with the correct information. The board-specific code then calls the SoC init routine which in turn will call a common init routine that makes a copy of the structure, maps in I/O regions, etc. After initialization, code can get a pointer to the structure by calling davinci_get_soc_info(). Eventually, the common init routine will make a copy of all of the data pointed to by the structure so the original data can be made __init_data. That way the data for SoC's that aren't being used won't consume memory for the entire life of the kernel. The structure will be extended in subsequent patches but initially, it holds the map_desc structure for any I/O regions the SoC/board wants statically mapped. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-15 23:38:58 +04:00
davinci_common_init(&davinci_soc_info_dm355);
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 17:43:36 +04: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 06:20:22 +03:00
}
void __init dm355_init_time(void)
{
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
void __iomem *pll1, *psc;
struct clk *clk;
ARM: davinci: dm355: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the dm355 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 16:17:44 +03:00
int rv;
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
clk_register_fixed_rate(NULL, "ref_clk", NULL, 0, DM355_REF_FREQ);
pll1 = ioremap(DAVINCI_PLL1_BASE, SZ_1K);
dm355_pll1_init(NULL, pll1, NULL);
psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K);
dm355_psc_init(NULL, psc);
clk = clk_get(NULL, "timer0");
ARM: davinci: WARN_ON() if clk_get() fails Currently the timer code checks if the clock pointer passed to it is good (!IS_ERR(clk)). The new clocksource driver expects the clock to be functional and doesn't perform any checks so emit a warning if clk_get() fails. Apply this to all davinci platforms. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 16:17:40 +03:00
if (WARN_ON(IS_ERR(clk))) {
pr_err("Unable to get the timer clock\n");
return;
}
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
ARM: davinci: dm355: switch to using the clocksource driver We now have a proper clocksource driver for davinci. Switch the dm355 platform to using it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-07-22 16:17:44 +03:00
rv = davinci_timer_register(clk, &dm355_timer_cfg);
WARN(rv, "Unable to register the timer: %d\n", rv);
ARM: davinci: dm355: add new clock init using common clock framework This adds the new board-specific clock init in mach-davinci/dm355.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 19:48:09 +03:00
}
static struct resource dm355_pll2_resources[] = {
{
.start = DAVINCI_PLL2_BASE,
.end = DAVINCI_PLL2_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device dm355_pll2_device = {
.name = "dm355-pll2",
.id = -1,
.resource = dm355_pll2_resources,
.num_resources = ARRAY_SIZE(dm355_pll2_resources),
};
void __init dm355_register_clocks(void)
{
/* PLL1 and PSC are registered in dm355_init_time() */
platform_device_register(&dm355_pll2_device);
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
}
[media] ARM: davinci: dm355: add support for v4l2 video display Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm355. Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2013-04-09 17:35:05 +04:00
int __init dm355_init_video(struct vpfe_config *vpfe_cfg,
struct vpbe_config *vpbe_cfg)
{
if (vpfe_cfg || vpbe_cfg)
platform_device_register(&dm355_vpss_device);
if (vpfe_cfg) {
vpfe_capture_dev.dev.platform_data = vpfe_cfg;
platform_device_register(&dm355_ccdc_dev);
platform_device_register(&vpfe_capture_dev);
}
if (vpbe_cfg) {
dm355_vpbe_dev.dev.platform_data = vpbe_cfg;
platform_device_register(&dm355_osd_dev);
platform_device_register(&dm355_venc_dev);
platform_device_register(&dm355_vpbe_dev);
platform_device_register(&dm355_vpbe_display);
}
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 17:52:10 +03:00
static const struct davinci_aintc_config dm355_aintc_config = {
.reg = {
.start = DAVINCI_ARM_INTC_BASE,
.end = DAVINCI_ARM_INTC_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
.num_irqs = 64,
.prios = dm355_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 17:52:05 +03:00
void __init dm355_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 17:52:11 +03:00
davinci_aintc_init(&dm355_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 17:52:05 +03:00
}
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
static int __init dm355_init_devices(void)
{
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 14:42:51 +03:00
struct platform_device *edma_pdev;
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 08:59:43 +04:00
int ret = 0;
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
if (!cpu_is_davinci_dm355())
return 0;
davinci_cfg_reg(DM355_INT_EDMA_CC);
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 14:42:51 +03:00
edma_pdev = platform_device_register_full(&dm355_edma_device);
if (IS_ERR(edma_pdev)) {
pr_warn("%s: Failed to register eDMA\n", __func__);
return PTR_ERR(edma_pdev);
}
davinci: DM355 - platform changes for vpfe capture DM355 platform and board setup This has platform and board setup changes to support vpfe capture driver for DM355 EVMs. Tested video capture on DM355 using tvp514x 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 20:02:50 +04: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 08:59:43 +04:00
ret = davinci_init_wdt();
if (ret)
pr_warn("%s: watchdog init failed: %d\n", __func__, ret);
return ret;
davinci: DM355: add base SoC and board support In addition, add board support for the DM355 Evaluation Module (EVM) and the DM355 Leopard board. Original DM355 EVM support done by Sandeep Paulraj, with significant updates and improvements by David Brownell. DM355 Leopord support done by Koen Kooi. Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Koen Kooi <koen@beagleboard.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-04-29 23:10:55 +04:00
}
postcore_initcall(dm355_init_devices);
Reference in New Issue Copy Permalink