| 4657a2d4 | 19-Sep-2015 |
Vitaly Andrianov <vitalya@ti.com> |
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 And
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>
show more ...
|
| e165b1d3 | 22-Oct-2014 |
Khoronzhuk, Ivan <ivan.khoronzhuk@ti.com> |
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 inc
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>
show more ...
|
| 3fe93623 | 17-Oct-2014 |
Khoronzhuk, Ivan <ivan.khoronzhuk@ti.com> |
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.
Start
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>
show more ...
|
| a43febde | 22-Oct-2014 |
Khoronzhuk, Ivan <ivan.khoronzhuk@ti.com> |
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 driv
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>
show more ...
|
| f0772266 | 29-Sep-2014 |
Vitaly Andrianov <vitalya@ti.com> |
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. W
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>
show more ...
|
| 9ea9021a | 05-Sep-2014 |
Khoronzhuk, Ivan <ivan.khoronzhuk@ti.com> |
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 th
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>
show more ...
|