summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-04-04rockchip: configs: correct mmc env dev for rk3288 based boardsJacob Chen
we are using mmc alias , so mmc index have been changed. now mmc dev 0 is emmc and mmc dev 1 is sdmmc. Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
2017-04-04Prepare v2017.05-rc1Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-04-04Merge git://git.denx.de/u-boot-tegraTom Rini
2017-04-04Merge git://git.denx.de/u-boot-arcTom Rini
In this patch-set we add support of new AXS103 firmware as well as troubleshoot unexpected execution by multiple cores simultaneously.
2017-04-04Merge git://git.denx.de/u-boot-mmcTom Rini
2017-04-04Merge git://git.denx.de/u-boot-dmTom Rini
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-04-01apalis-tk1: disable external clock loopback on SDMMC3Marcel Ziswiler
Actually make use of that shiny new CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2017-04-01mmc: tegra: allow disabling external clock loopbackMarcel Ziswiler
Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the external clock loopback and use the internal one on SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1 bits being set to 0xfffd according to the TRM. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2017-04-01arm: tegra: initial support for apalis tk1Marcel Ziswiler
This patch adds board support for the Toradex Apalis TK1 a computer on module which can be used on different carrier boards. The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L RAM, a bunch of level shifters, an eMMC, a TMP451 temperature sensor chip, an I210 gigabit Ethernet controller and a SGTL5000 audio codec. Furthermore, there is a Kinetis MK20DN512 companion micro controller for analogue, CAN and resistive touch functionality. For the sake of ease of use we do not distinguish between different carrier boards for now as the base module features are deemed sufficient enough for regular booting. The following functionality is working so far: - eMMC boot, environment storage and Toradex factory config block - Gigabit Ethernet - MMC/SD cards (both MMC1 as well as SD1 slot) - USB client/host (dual role OTG port as client e.g. for DFU/UMS or host, other two ports as host) Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
2017-03-31arcv2: Halt non-master coresAlexey Brodkin
Even though we expect only master core to execute U-Boot code let's make sure even if for some reason slave cores attempt to execute U-Boot in parallel with master they get halted very early. If platform wants it may kick-start slave cores before passing control to say Linux kernel or any other application that want to see all cores of SMP SoC up and running. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-31axs103: Support slave core kick-start on axs103 v1.1 firmwareAlexey Brodkin
In axs103 v1.1 procedure to kick-start slave cores has changed quite a bit compared t previous implementation. In particular: * We used to have a generic START bit for all cores selected by CORE_SEL mask. But now we don't touch CORE_SEL at all because we have a dedicated START bit for each core: bit 0: Core 0 (master) bit 1: Core 1 (slave) * Now there's no need to select "manual" mode of core start Additional challenge for us is how to tell which axs103 firmware we're dealing with. For now we'll rely on ARC core version which was bumped from 2.1c to 3.0. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-31axs103: Clean-up smp_kick_all_cpus()Alexey Brodkin
* Rely on default pulse polarity value * Don't mess with "multicore" value as it doesn't affect execution In essence we now do a bare minimal stuff: 1) Select HS38x2_1 with CORE_SEL=1 bits 2) Select "manual" core start (via CREG) with START_MODE=0 3) Generate cpu_start pulse with START=1 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-30mmc: omap_hsmmc: add support for CONFIG_BLKJean-Jacques Hiblot
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-30mmc: omap_hsmmc: move the mmc_config to platdata when DM_MMC is usedJean-Jacques Hiblot
This is a preparation work for the support of CONFIG_BLK. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-30mmc: omap_hsmmc: use mmc_get_blk_desc() to get the block device descJean-Jacques Hiblot
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-30mmc: omap_hsmmc: use an accessor to get the private dataJean-Jacques Hiblot
For consistency, use an accessor to access the private data. Also for the same reason, rename all priv_data to priv. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-03-29arm64: mvebu: Enable CONFIG_PHY_MARVELL in Armada7k/8k-DB defconfigStefan Roese
The Marvell PHY support is needed espescially for the A7040-DB with the SGMII port (port 2). As without the marvell PHY driver configuration for SGMII, ethernet won't work. 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-29arm64: mvebu: armada-7040-db.dts: Change eth1 speed from 2.5G to 1GStefan Roese
The default configuration for the COMPHY-0 port should be 1G, as its used as 1G SGMII connection. This change is necessary to get the MAC2 port (SGMII) working on this DB. 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: 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: include/phy.h: Add new PHY interface modesStefan Roese
This patch adds the new PHY interface modes XAUI, RXAUI and SFI that will be used by the PPv2.2 support in the Marvell mvpp2 ethernet driver. 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 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-29arm64: mvebu: armada-7k/8k: Enable MVPP2 ethernet driverStefan Roese
Since we've now integrated the A7k/8k support in the mvpp2 ethernet driver, lets enable the support for both Marvell developments boards. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-03-29arm64: marvell: dts: add PPv2.2 description to Armada 7K/8KThomas Petazzoni
This commit adds the description of the PPv2.2 hardware block for the Marvell Armada 7K and Armada 8K processors, and their corresponding Armada 7040 and 8040 Development boards. 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 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>