Commit graph

20 commits

Author SHA1 Message Date
Lukasz Majewski
d7ebbe9dc4 ti: wdt: common: Make the wdt IP defines common for the TI platform
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
2017-04-08 21:32:48 -04:00
Tom Rini
187f9dc3f7 TI: Remove CONFIG_OMAP_COMMON in favor of CONFIG_ARCH_OMAP2
With the move to arch/arm/mach-omap2 there are now very few uses of
CONFIG_OMAP_COMMON and further they can all be replaced with
CONFIG_ARCH_OMAP2, so do so.

Signed-off-by: Tom Rini <trini@konsulko.com>
2016-11-21 14:07:29 -05:00
Masahiro Yamada
43ebbfc39f ARM: keystone: rename clk_get_rate() to ks_clk_get_rate()
The KeyStone platform has its own clk_get_rate() but its prototype
is different from that of the common-clk (clk-uclass) framework.

Prefix the KeyStone specific implementation with ks_ in order to
avoid name-space conflict.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-08 09:33:13 -04:00
Peter Howard
c165994299 Fix to davinci_nand.h to place CEnCFG registers at correct
Signed-off-by: Peter Howard <phoward@gme.net.au>
2016-06-06 13:39:12 -04:00
Vitaly Andrianov
4657a2d44e driver: net: keystone_net: add support for rgmii phy
In K2G, Ethernet doesn't support SGMII instead it support RGMII,
adding support to the driver to connect to RGMII phy.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2015-10-22 14:22:23 -04:00
Mugunthan V N
bf7bd4e725 driver: net: keystone_net: fix phy mode configuration
Phy mode is a board property and it can be different between
multiple board and ports, so it should not be hardcoded in
driver to one specific mode. So adding a field in eth_priv_t
structure to pass phy mode to driver.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2015-10-22 14:22:22 -04:00
Vitaly Andrianov
e6d71e1ca5 ARM: k2g: Add clock information
Add clock information for Galileo

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
2015-10-22 14:22:16 -04:00
Vignesh R
664ab2c992 dma: ti-edma3: Add helper function to support edma3 transfer
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
2015-08-17 23:29:15 +05:30
Paul Kocialkowski
60c7c30aa0 omap-common: Common boot code OMAP3 support and cleanup
This introduces OMAP3 support for the common omap boot code, as well as a
major cleanup of the common omap boot code.

First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's coding style to use structures for mapping such kind of
data (in the sense that it is similar to registers). It is correct to assume
that romcode structure encoding is the same as U-Boot, given the description
of these structures in the TRMs.

The original address provided by the bootrom is passed to the U-Boot binary
instead of a duplicate of the structure stored in global data. This allows to
have only the relevant (boot device and mode) information stored in global data.
It is also expected that the address where the bootrom stores that information
is not overridden by the U-Boot SPL or U-Boot.

The save_omap_boot_params is expected to handle all special cases where the data
provided by the bootrom cannot be used as-is, so that spl_boot_device and
spl_boot_mode only return the data from global data.

All of this is only relevant when the U-Boot SPL is used. In cases it is not,
save_boot_params should fallback to its weak (or board-specific) definition.
save_omap_boot_params should not be called in that context either.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2015-07-27 15:02:03 -04:00
Khoronzhuk, Ivan
e165b1d34c dma: ti-edma3: introduce edma3 driver
The EDMA3 controller’s primary purpose is to service data transfers
that you program between two memory-mapped slave endpoints on the device.

Typical usage includes, but is not limited to the following:
- Servicing software-driven paging transfers (e.g., transfers from external
  memory, such as SDRAM to internal device memory, such as DSP L2 SRAM)
- Servicing event-driven peripherals, such as a serial port
- Performing sorting or sub-frame extraction of various data structures
- Offloading data transfers from the main device DSP(s)
- See the device-specific data manual for specific peripherals that are
  accessible via the EDMA3 controller

Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:29 -04:00
Khoronzhuk, Ivan
3fe93623cc net: keystone_net: register eth PHYs on MDIO bus
As MDIO bus has been added we can register PHYs with it.
After registration, the PHY driver will be probed according to the
hardware on board.

Startup PHY at the ethernet open.

Use phy_startup() instead of keystone_get_link_status() when eth open,
as it verifies PHY link inside and SGMII link is checked before.

For K2HK evm PHY configuration at init was absent, so don't enable
phy config at init for k2hk evm.

Acked-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:28 -04:00
Hao Zhang
92a16c81f5 soc: keystone_serdes: generalize to be used by other sub systems
SerDes driver is used by other sub systems like PCI, sRIO etc.
So modify it to be more general. The SerDes driver provides common
API's that can also be extended for other peripherals SerDes
configurations.

Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:28 -04:00
Khoronzhuk, Ivan
a43febde44 soc: keystone_serdes: create a separate SGMII SerDes driver
This patch split the Keystone II SGMII SerDes related code from
Ethernet driver and create a separate SGMII SerDes driver.
The SerDes driver can be used by others keystone subsystems
like PCI, sRIO, so move it to driver/soc/keystone directory.

Add soc specific drivers directory like in the Linux kernel.
It is going to be used by keysotone soc specific drivers.

Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:28 -04:00
Vitaly Andrianov
f077226610 net: keystone_net: increase MDIO clock frequency
With MAC_PHY sgmii configuration, u-boot checks PHY link status before
sending each packet. Increasing MDIO frequency increases overall tftp
speed. We set it to maximum 2.5MHz.

Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:05 -04:00
Khoronzhuk, Ivan
0935cac685 net: keystone_net: move header file from arch to ti-common
The header file for the driver should be in correct place.
So move it to "arch/arm/include/asm/ti-common/keystone_net.h"
and correct driver's external dependencies. At the same time
align and correct some definitions.

Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:05 -04:00
Khoronzhuk, Ivan
9ea9021ac4 dma: keystone_nav: generalize driver usage
The keystone_nav driver is general driver intended to be used for
working with queue manager and pktdma for different IPs like NETCP,
AIF, FFTC, etc. So the it's API shouldn't be named like it works only
with one of them, it should be general names. The names with prefix
like netcp_* rather do for drivers/net/keystone_net.c driver. So it's
good to generalize this driver to be used for different IP's and
delete confusion with real NETCP driver.

The current netcp_* functions of keystone navigator can be used for
other settings of pktdma, not only for NETCP. The API of this driver
is used by the keystone_net driver to work with NETCP, so net driver
also should be corrected. For convenience collect pkdma
configurations in drivers/dma/keystone_nav_cfg.c.

Acked-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:04 -04:00
Khoronzhuk, Ivan
ef4547176d dma: keystone_nav: move keystone_nav driver to driver/dma/
The keystone_nav is used by drivers/net/keystone_net.c driver to
send and receive packets, but currently it's placed at keystone
arch sources. So it should be in the drivers directory also.
It's separate driver that can be used for sending and receiving
pktdma packets by others drivers also.

This patch just move this driver to appropriate directory and
doesn't add any functional changes.

Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:04 -04:00
Khoronzhuk, Ivan
909ea9aa26 ARM: keystone: aemif: move aemif driver to drivers/memory/ti-aemif.c
Move AEMIF driver to drivers/memory/ti-aemif.c along with AEMIF
definitions collected in arch/arm/include/asm/ti-common/ti-aemif.h

Acked-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-06-19 17:53:58 -04:00
Khoronzhuk, Ivan
3e01ed00da mtd: nand: davinci: add header file for driver definitions
The definitions inside emif_defs.h concern davinci nand driver and
should be in it's header. So create header file for davinci nand
driver and move definitions from emif_defs.h and nand_defs.h to it.

Acked-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
[trini: Fixup more davinci breakage]
Signed-off-by: Tom Rini <trini@ti.com>
2014-06-19 17:53:58 -04:00
Tom Rini
939911a64b armv7:TI: Add <asm/ti-common/sys_proto.h> and migrate omap_hw_init_context
The omap_hw_init_context function (and assorted helpers) is the same for
all OMAP-derived parts as when CHSETTINGS are used, that's the same and
our DDR base is also always the same.  In order to make this common we
simply need to update the names of the define for DDR address space
which is also common.

Cc: Sricharan R. <r.sricharan@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2014-05-23 19:40:05 -04:00