summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2017-04-04Merge git://www.denx.de/git/u-boot-marvellTom Rini
This includes Marvell mvpp2 patches with the ethernet support for the ARMv8 Armada 7k/8k platforms. The ethernet patches are all acked by Joe and he is okay with me pushing them via the Marvell tree.
2017-04-04Merge git://git.denx.de/u-boot-fsl-qoriqTom Rini
2017-04-04Merge branch 'master' of git://git.denx.de/u-boot-i2cTom Rini
2017-03-29net: mvpp2: Remove unreferenced in_use_thresh from struct mvpp2_bm_poolStefan Roese
As pointed out by Stefan Chulski, this variable is unused and should be removed. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Configure SMI PHY address needed for PHY pollingStefan Roese
On PPv2.2 we enable PHY polling, so we also need to configure the PHY address in the specific PHY address rgisters. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Enable PHY polling mode on PPv2.2Stefan Roese
Testing shows, that PHY polling needs to be enabled on Armada 7k/8k. Otherwise ethernet transfers will not work correctly. PHY polling is enabled per default after reset, so we do not need to specifically enable it, but this makes it clearer. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add missing PHY_INTERFACE_MODE_RGMII_IDStefan Roese
Add a missing occurrance of PHY_INTERFACE_MODE_RGMII_ID, which should be handled identical to PHY_INTERFACE_MODE_RGMII. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add GoP and NetC support for port 0 (SFI)Stefan Roese
This patch adds the GoP (Group of Ports) and NetC (Net Complex) setup to the Marvell mvpp2 ethernet driver for the missing port 0. This code is mostly copied from the Marvell U-Boot version and was written by Stefan Chulski. Please note that only SFI support have been added, as this is the only interface that this code has been tested with. XAUI and RXAUI support might follow at a later stage. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add GoP and NetC support for ports 2 & 3 (RGMII & SGMII)Stefan Roese
This patch adds the GoP (Group of Ports) and NetC (Net Complex) setup to the Marvell mvpp2 ethernet driver. This code is mostly copied from the Marvell U-Boot version and was written by Stefan Chulski. Please note that only RGMII and SGMII support have been added, as these are the only interfaces that this code has been tested with. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Read phy-speed from DT to select between 1GB and 2.5GB SGMIIStefan Roese
Read the "phy-speed" DT property to differentiate between 1 and 2.5GB SGMII operations. Please note that its unclear right now, if this DT property will be accepted in mainline Linux. If not, we need to revisit this code and change it to use the accepted property. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Restructure probe / init functionsStefan Roese
This patch does a bit of restructuring of the probe / init functions, mainly to allow earlier register access as it is needed for the upcoming GoP (Group of Ports) and NetC (Net Complex) code. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add RX and TX FIFO configuration for PPv2.2Stefan Roese
This patch adds the PPv2.2 specific FIFO configuration to the mvpp2 driver. The RX FIFO packet data size is changed to the recommended FIFO sizes. The TX FIFO configuration is newly added. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Handle eth device naming in multi-CP case correctlyStefan Roese
Currently, the naming of the ethernet ports is not handled correctly in the multi-CP (Communication Processor) case. On Armada 8k, the slave-CP also instantiates an ethernet controller with the same device ID's. This patch now takes this into account and adds the required base-id so that the slave-CP ethernet devices will be named "mvpp2-3 ...". This patch also updates my Copyright notice to include 2017 as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Stefan Chulski <stefanc@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Enable compilation for Armada 7K/8K platformsStefan Roese
Since Armada 7K/8K is also equipped with a newer version of the MVPP2 ethernet controller, lets enable compilation of this driver for these platforms. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2.c: Clear all buffer / descriptor areas before usageStefan Roese
This fixes problems noticed with the PPv2.2 A7k/8k port, when not all elements of the descriptors had been cleared before use. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Move probe function from MISC to ETH DM driverStefan Roese
This patch moves the base_probe function mvpp2_base_probe() from the MISC driver to the ETH driver. When integrated in the MISC driver, probe is called too early before the U-Boot ethernet infrastructure (especially the MDIO / PHY interface) has been initialized. Resulting in errors in mdio_register(). Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Add MDIO support for PPv2.2Stefan Roese
In U-Boot the MDIO / SMI support is integrated in the mvpp2 driver, currently only supporting the 32bit platforms (Armada 37x). This patch now adds the A7k/8k PPv2.2 MDIO support to that the phy / mii IF can be used as well on these platforms. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: finally add the PPv2.2 compatible stringThomas Petazzoni
Now that the mvpp2 driver has been modified to accommodate the support for PPv2.2, we can finally advertise this support by adding the appropriate compatible string. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: adapt rxq distribution to PPv2.2Thomas Petazzoni
In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4 RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7 to the second port, 8->11 to the third port, etc. In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate RXQs from the range of 32 RXQs available for each port. So port 0 must use RXQs in the range 0->31, port 1 in the range 32->63, etc. This commit adapts the mvpp2 to this difference between PPv2.1 and PPv2.2: - The constant definition MVPP2_MAX_RXQ is replaced by a new field 'max_port_rxqs' in 'struct mvpp2', which stores the maximum number of RXQs per port. This field is initialized during ->probe() depending on the IP version. - MVPP2_RXQ_TOTAL_NUM is removed, and instead we calculate the total number of RXQs by multiplying the number of ports by the maximum of RXQs per port. This was anyway used in only one place. - In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted to cope with the different allocation strategy between PPv2.1 and PPv2.2. Due to this change, the 'next_first_rxq' argument of this function is no longer needed and is removed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: rework RXQ interrupt group initialization for PPv2.2Thomas Petazzoni
This commit adjusts how the MVPP2_ISR_RXQ_GROUP_REG register is configured, since it changed between PPv2.1 and PPv2.2. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: add AXI bridge initialization for PPv2.2Thomas Petazzoni
The PPv2.2 unit is connected to an AXI bus on Armada 7K/8K, so this commit adds the necessary initialization of the AXI bridge. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: handle misc PPv2.1/PPv2.2 differencesThomas Petazzoni
This commit handles a few miscellaneous differences between PPv2.1 and PPv2.2 in different areas, where code done for PPv2.1 doesn't apply for PPv2.2 or needs to be adjusted (getting the MAC address, disabling PHY polling, etc.). Changed by Stefan for U-Boot: Since mvpp2_port_power_up() has multiple callers in U-Boot, the U-Boot version of this patch does not remove this function but simply adds the check for MVPP21 before the mvpp2_port_fc_adv_enable() call. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: handle register mapping and access for PPv2.2Thomas Petazzoni
This commit adjusts the mvpp2 driver register mapping and access logic to support PPv2.2, to handle a number of differences. Due to how the registers are laid out in memory, the Device Tree binding for the "reg" property is different: - On PPv2.1, we had a first area for the common registers, and then one area per port. - On PPv2.2, we have a first area for the common registers, and a second area for all the per-ports registers. In addition, on PPv2.2, the area for the common registers is split into so-called "address spaces" of 64 KB each. They allow to access the same registers, but from different CPUs. Hence the introduction of cpu_base[] in 'struct mvpp2', and the modification of the mvpp2_write() and mvpp2_read() register accessors. For PPv2.1, the compatibility is preserved by using an "address space" size of 0. Changed by Stefan for U-Boot: Since we don't support multiple CPUs in U-Boot, I've removed all the code, macros and variables introduced in the Linux patch version for this. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: adjust mvpp2_{rxq,txq}_init for PPv2.2Thomas Petazzoni
In PPv2.2, the MVPP2_RXQ_DESC_ADDR_REG and MVPP2_TXQ_DESC_ADDR_REG registers have a slightly different layout, because they need to contain a 64-bit address for the RX and TX descriptor arrays. This commit adjusts those functions accordingly. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: adapt mvpp2_defaults_set() to PPv2.2Thomas Petazzoni
This commit modifies the mvpp2_defaults_set() function to not do the loopback and FIFO threshold initialization, which are not needed for PPv2.2. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: adapt the mvpp2_rxq_*_pool_set functions to PPv2.2Thomas Petazzoni
The MVPP2_RXQ_CONFIG_REG register has a slightly different layout between PPv2.1 and PPv2.2, so this commit adapts the functions modifying this register to accommodate for both the PPv2.1 and PPv2.2 cases. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: adjust the allocation/free of BM pools for PPv2.2Thomas Petazzoni
This commit adjusts the allocation and freeing of BM pools to support PPv2.2. This involves: - Checking that the number of buffer pointers is a multiple of 16, as required by the hardware. - Adjusting the size of the DMA coherent area allocated for buffer pointers. Indeed, PPv2.2 needs space for 2 pointers of 64-bits per buffer, as opposed to 2 pointers of 32-bits per buffer in PPv2.1. The size in bytes is now stored in a new field of the mvpp2_bm_pool structure. - On PPv2.2, getting the physical and virtual address of each buffer requires reading the MVPP2_BM_ADDR_HIGH_ALLOC to get the high order bits of those addresses. A new utility function mvpp2_bm_bufs_get_addrs() is introduced to handle this. - On PPv2.2, releasing a buffer requires writing the high order 32 bits of the physical address to MVPP2_BM_PHY_VIRT_HIGH_RLS_REG. We no longer need to write the virtual address to MVPP2_BM_VIRT_RLS_REG. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessorsThomas Petazzoni
This commit adds the definition of the PPv2.2 HW descriptors, adjusts the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts the accessors to work on both PPv2.1 and PPv2.2. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: introduce an intermediate union for the TX/RX descriptorsThomas Petazzoni
Since the format of the HW descriptors is different between PPv2.1 and PPv2.2, this commit introduces an intermediate union, with for now only the PPv2.1 descriptors. The bulk of the driver code only manipulates opaque mvpp2_tx_desc and mvpp2_rx_desc pointers, and the descriptors can only be accessed and modified through the accessor functions. A follow-up commit will add the descriptor definitions for PPv2.2. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: add hw_version field in "struct mvpp2"Thomas Petazzoni
In preparation to the introduction for the support of PPv2.2 in the mvpp2 driver, this commit adds a hw_version field to the struct mvpp2, and uses the .data field of the DT match table to fill it in. Having the MVPP21 and MVPP22 definitions available will allow to start adding the necessary conditional code to support PPv2.2. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: add and use accessors for TX/RX descriptorsThomas Petazzoni
The PPv2.2 IP has a different TX and RX descriptor layout compared to PPv2.1. In order to prepare for the introduction of PPv2.2 support in mvpp2, this commit adds accessors for the different fields of the TX and RX descriptors, and changes the code to use them. For now, the mvpp2_port argument passed to the accessors is not used, but it will be used in follow-up to update the descriptor according to the version of the IP being used. Apart from the mechanical changes to use the newly introduced accessors, a few other changes, needed to use the accessors, are made: - The mvpp2_txq_inc_put() function now takes a mvpp2_port as first argument, as it is needed to use the accessors. - Similarly, the mvpp2_bm_cookie_build() gains a mvpp2_port first argument, for the same reason. - In mvpp2_rx_error(), instead of accessing the RX descriptor in each case of the switch, we introduce a local variable to store the packet size. - Similarly, in mvpp2_buff_hdr_rx(), we introduce a local "cookie" variable to store the RX descriptor cookie, rather than accessing it from the descriptor each time. - In mvpp2_tx_frag_process() and mvpp2_tx() instead of accessing the packet size from the TX descriptor, we use the actual value available in the function, which is used to set the TX descriptor packet size a few lines before. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: store physical address of buffer in rx_desc->buf_cookieThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: remove support for buffer headerThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: use "dma" instead of "phys" where appropriateThomas Petazzoni
As indicated by Russell King, the mvpp2 driver currently uses a lot "phys" or "phys_addr" to store what really is a DMA address. This commit clarifies this by using "dma" or "dma_addr" where appropriate. This is especially important as we are going to introduce more changes where the distinction between physical address and DMA address will be key. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: enable building on 64-bit platforms (more U-Boot specific)Stefan Roese
Some more U-Boot specific 64bit support changes, mostly changing u32 to unsigned long. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: enable building on 64-bit platformsThomas Petazzoni
The mvpp2 is going to be extended to support the Marvell Armada 7K/8K platform, which is ARM64. As a preparation to this work, this commit enables building the mvpp2 driver on ARM64, by: - Adjusting the Kconfig dependency - Fixing the types used in the driver so that they are 32/64-bits compliant. We use dma_addr_t for DMA addresses, and unsigned long for virtual addresses. It is worth mentioning that after this commit, the driver is for now still only used on 32-bits platforms, and will only work on 32-bits platforms. Changed by Stefan for U-Boot: Removed the Kconfig change as it does not apply to U-Boot this way. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: simplify MVPP2_PRS_RI_* definitionsThomas Petazzoni
Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which doesn't compile nicely on 64-bit. Moreover, those definitions are in fact unneeded, since they are always used in combination with a bit mask that ensures only the appropriate bits are modified. Therefore, such definitions should just be set to 0x0. In addition, as suggested by Russell King, we change the _MASK definitions to also use the BIT() macro so that it is clear they are related to the values defined afterwards. For example: #define MVPP2_PRS_RI_L2_CAST_MASK 0x600 #define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10)) #define MVPP2_PRS_RI_L2_MCAST BIT(9) #define MVPP2_PRS_RI_L2_BCAST BIT(10) becomes #define MVPP2_PRS_RI_L2_CAST_MASK (BIT(9) | BIT(10)) #define MVPP2_PRS_RI_L2_UCAST 0x0 #define MVPP2_PRS_RI_L2_MCAST BIT(9) #define MVPP2_PRS_RI_L2_BCAST BIT(10) Because the values (MVPP2_PRS_RI_L2_UCAST, MVPP2_PRS_RI_L2_MCAST and MVPP2_PRS_RI_L2_BCAST) are always applied with MVPP2_PRS_RI_L2_CAST_MASK, and therefore there is no need for MVPP2_PRS_RI_L2_UCAST to be defined as ~(BIT(9) | BIT(10)). It fixes the following warnings when building the driver on a 64-bit platform (which is not possible as of this commit, but will be enabled in a follow-up commit): drivers/net/ethernet/marvell/mvpp2.c: In function ‘mvpp2_prs_mac_promisc_set’: drivers/net/ethernet/marvell/mvpp2.c:524:33: warning: large integer implicitly truncated to unsigned type [-Woverflow] #define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10)) ^ drivers/net/ethernet/marvell/mvpp2.c:1459:33: note: in expansion of macro ‘MVPP2_PRS_RI_L2_UCAST’ mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L2_UCAST, Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: fix indentation of MVPP2_EXT_GLOBAL_CTRL_DEFAULTThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: remove unused register definitionsThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: simplify mvpp2_bm_bufs_add()Thomas Petazzoni
The mvpp2_bm_bufs_add() currently creates a fake cookie by calling mvpp2_bm_cookie_pool_set(), just to be able to call mvpp2_pool_refill(). But all what mvpp2_pool_refill() does is extract the pool ID from the cookie, and call mvpp2_bm_pool_put() with this ID. Instead of doing this convoluted thing, just call mvpp2_bm_pool_put() directly, since we have the BM pool ID. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29net: mvpp2: Round up top tx buffer boundaries for dcache opsStefan Roese
check_cache_range() warns that the top boundaries are not properly aligned when flushing or invalidating the buffers and make these operations fail. This gets rid of the warnings: CACHE: Misaligned operation at range ... Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29drivers: timer: Introduce ARC timer driverVlad Zakharov
This commit introduces timer driver for ARC. ARC timers are configured via ARC AUX registers so we use special functions to access timer control registers. This driver allows utilization of either timer0 or timer1 depending on which one is available in real hardware. Essentially only existing timers should be mentioned in board's Device Tree description. Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-03-29mvebu: neta: a37xx: Add fixed link support to neta driverKonstantin Porotchkin
Add support for fixed link to NETA driver. This feature requreed for proper support of SFP modules and onboard connected devices like Ethernet switches Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Terry Zhou <bjzhou@marvell.com> Cc: Stefan Roese <sr@denx.de> Cc: Igal Liberman <igall@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
2017-03-29mvebu: neta: Add support for board init functionKonstantin Porotchkin
Add ability to use board-specific initialization flow to NETA driver (for instance Ethernet switch bring-up) Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Cc: Stefan Roese <sr@denx.de> Cc: Igal Liberman <igall@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
2017-03-29mvebu: usb: xhci: Add VBUS regulator supply to the host driverKonstantin Porotchkin
The USB device should linked to VBUS regulator through "vbus-supply" DTS property. This patch adds handling for "vbus-supply" property inside the USB device entry for turning on the VBUS regulator upon the host adapter probe. Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Cc: Stefan Roese <sr@denx.de> Cc: Marek Vasut <marex@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Neta Zur Hershkovits <neta@marvell.com> Cc: Igal Liberman <igall@marvell.com> Cc: Haim Boot <hayim@marvell.com> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
2017-03-29mvebu: pcie: Add support for GPIO reset for PCIe deviceKonstantin Porotchkin
Add support for "marvell,reset-gpio" property to mvebu DW PCIe driver. This option is valid when CONFIG_DM_GPIO=y Change-Id: Ic17c500449050c2fbb700731f1a9ca8b83298986 Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com> Cc: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Neta Zur Hershkovits <neta@marvell.com> Cc: Igal Liberman <igall@marvell.com> Cc: Haim Boot <hayim@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de>
2017-03-29drivers: ti_qspi: use syscon to get the address ctrl_mod_mmap registerJean-Jacques Hiblot
We used to get the address of the optionnal ctrl_mod_mmap register as the third memory range of the "reg" property. the linux driver moved to use a syscon instead. In order to keep the DTS as close as possible to that of linux, we move to using a syscon as well. If SYSCON is not supported, the driver reverts to the old way of getting the address from the 3rd memory range Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2017-03-29regmap: use fdt address translationJean-Jacques Hiblot
In the DTS, the addresses are defined relative to the parent bus. We need to translate them to get the address as seen by the CPU core. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
2017-03-29dm: core: Fix Handling of global_data moving in SPLLokesh Vutla
commit 2f11cd9121658 ("dm: core: Handle global_data moving in SPL") handles relocation of GD in SPL if spl_init() is called before board_init_r(). So, uclass_root.next need not be initialized always and accessing uclass_root.next->prev gives an abort. Update the uclass_root only if it is available. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-03-29mmc: xenon_sdhci: Add missing host->max_clk to Xenon SDHCI driverStefan Roese
The Xenon SDHCI driver just missed the integration of this patch: git ID 6d0e34bf mmc: sdhci: Distinguish between base clock and maximum peripheral frequency With this patch applied, the SDHCI subsystem complains now with this warning while probing: sdhci_setup_cfg: Hardware doesn't specify base clock frequency This patch fixes this issue, by providing the missing host->max_clk variable to the SDHCI subsystem. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Hu Ziji <huziji@marvell.com> Cc: Victor Gu <xigu@marvell.com> Cc: Konstantin Porotchkin <kostap@marvell.com> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Cc: Jaehoon Chung <jh80.chung@samsung.com>