The ability to read a character from the console constitutes an attack
vector into TF-A, as it gives attackers a means to inject arbitrary
data into TF-A. It is dangerous to keep that feature enabled if not
strictly necessary, especially in production firmware builds.
Thus, we need a way to disable this feature. Moreover, when it is
disabled, all related code should be eliminated from the firmware
binaries, such that no remnant/dead getc() code remains in memory,
which could otherwise be used as a gadget as part of a bigger security
attack.
This patch disables getc() feature by default. For legitimate getc()
use cases [1], it can be explicitly enabled by building TF-A with
ENABLE_CONSOLE_GETC=1.
The following changes are introduced when getc() is disabled:
- The multi-console framework no longer provides the console_getc()
function.
- If the console driver selected by the platform attempts to register
a getc() callback into the multi-console framework then TF-A will
now fail to build.
If registered through the assembly function finish_console_register():
- On AArch64, you'll get:
Error: undefined symbol CONSOLE_T_GETC used as an immediate value.
- On AArch32, you'll get:
Error: internal_relocation (type: OFFSET_IMM) not fixed up
If registered through the C function console_register(), this requires
populating a struct console with a getc field, which will trigger:
error: 'console_t' {aka 'struct console'} has no member named 'getc'
- All console drivers which previously registered a getc() callback
have been modified to do so only when ENABLE_CONSOLE_GETC=1.
[1] Example of such use cases would be:
- Firmware recovery: retrieving a golden BL2 image over the console in
order to repair a broken firmware on a bricked board.
- Factory CLI tool: Drive some soak tests through the console.
Discussed on TF-A mailing list here:
https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/YS7F6RCNTWBTEOBLAXIRTXWIOYINVRW7/
Change-Id: Icb412304cd23dbdd7662df7cf8992267b7975cc5
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
The constants BUNDLE_PERIOD_SCALE and PLL_READY_DLY refer to two
multi-bit registers within the Clock Source Low register. These
constants are used as masks for those registers (and values are not
defined since we are writing zeros to them).
Give them the _MASK suffix.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Id469d0ab4c755d2d6a0150a1ade33dd9d0293667
The register at offset 0x1C3 is called Clock Source Low in functional
specification, but we use constant name GLOB_CLK_SRC_LO. Rename it to
RST_CLK_CTRL instead.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: If7ca460cb166f3828678e1e09c4e6caf5bb77770
The register at offset 0x1C1 is called Reset and Clock Control in
functional specification, but we use constant name GLOB_PHY_CTRL0.
Rename it to RST_CLK_CTRL instead.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I5dac8913bd0686d4f5bd74b91cb7d07ba06df72b
Rename the Lane Status 1 register constants from LANE_STATUS1 to
LANE_STAT1, to use an abbreviation similar to that for Lane
Configuration registers (where we use LANE_CFGx instead of LANE_CONFIGx
or LANE_CONFIGURATIONx).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ie329d5a93615efe261802a2f027475b602a5c840
Rename the Miscellaneous Control register constants from MISC_REGx to
MISC_CTRLx.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I4d43bbda44b090de4ecf2d52cfc468f9683cc3b5
According to the functional specification, the register at offset 0x48
is called Idle Sync Enable, not Unit Control or some such.
Rename the constants.
Only bit 12 of this register is defined, all other bits are reserved.
But for some reason the code needs the default value of the other bits,
so we also rename constant UNIT_CTRL_DEFAULT_VALUE to
IDLE_SYNC_EN_DEFAULT_VALUE.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ia4f80f945a8f31c190cd9a1875d50d892e72825f
Generation Settings registers have the same layout for different
generations and same setting (i.e. Generation 2 Settings 2 register has
the same layout as Generation 3 Settings 2).
So it does not make sense to prefix the constants for Settings 2 with
G3.
Instead change the prefixes to GSx_ for settings register x.
For Settings 2 of Gen 2 and Gen 3 we have some definitions in the first
and some in the second. Move them all to the first defined register (in
this case Gen 2, since the constant for Gen 1 is not defined because it
is not used).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I15c337eb58aa37fd99fe388fd59373aa325a3a92
Sometimes we call the constants GENx_SET_y, sometimes GENx_SETTINGS_y,
and sometimes GENx_SETTING_y.
Unify this into GENx_SETy.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I3810fb52b2897fe6730ef6e58d434c47cfef14a9
COMPHY register addresses are defined twice
- once for indirect access, where the constants are of the form
COMPHY_<register_name>
- once for direct access, with constants of the form
<register_name>_ADDR
But sometimes the first case also has this _ADDR suffix (and other times
not).
Drop it from those places to unify how we define these registers.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ibf95be8ade231d0e42258f40614a5f0974d280bd
Some register constants are defined with _REG suffix or REG_ prefix, but
others are not. Unify this by dropping these prefixes / suffixes.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I1ba331c0a4686093ee250bcaf3297349956ac9a8
The COMPHY_RESERVED_REG (offset 0x0E) is currently defined between
COMPHY_KVCO_CAL_CTRL (0x02) and COMPHY_DIG_LOOPBACK_EN (0x23).
But this register does not come from PHY lane register space. The
address 0x0E is not relative to PHY lane registers base address.
It only exists in the indirect register space, before PHY lane 2
registers (which start at address 0x200).
Move its definition in the header and add a comment.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ie726384b980ace83d8ea327df09d928db74c2ab7
Move the definitions for the Miscellaneous Control 0 register (offset 0x4F),
to leave the registers sorted according to their offsets.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I9864be5bd00181d21c9334219be4f89c4f032c8b
The register name for the value PHY_GEN_USB3_5G is PHY_GEN_MAX. We
already define the mask constant as PHY_GEN_MAX_MASK. Thus also the
value name should be prefixed with PHY_GEN_MAX_.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ibf72a66d2e65e240ed2cdbc3a301dbd793e2cb34
The register at offset 0x23 is called Digital Loopback Enable, but the
constant is COMPHY_LOOPBACK_REG0, as if there were some LOOPBACK_REG1
register or something, which there is not.
Rename the constant to COMPHY_DIG_LOOPBACK_EN.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ie88bdd864e2c9ab7e8de70ed7f3a13ee8f08ff79
Currently reg_set() and reg_set16() are implemented via
mmio_clrsetbits_32(), meaning that first bits from mask are cleared,
then data bits are set.
But these function are used everywhere according to update semantics,
where only those bits that are in mask are allowed to be changed.
Example from phy-comphy-cp110.c
mask = HPIPE_RST_CLK_CTRL_PIPE_RST_MASK;
data = 0x1 << HPIPE_RST_CLK_CTRL_PIPE_RST_OFFSET;
/* Set PHY datapath width mode for V0 */
mask |= HPIPE_RST_CLK_CTRL_FIXED_PCLK_MASK;
data |= 0x0 << HPIPE_RST_CLK_CTRL_FIXED_PCLK_OFFSET;
/* Set Data bus width USB mode for V0 */
mask |= HPIPE_RST_CLK_CTRL_PIPE_WIDTH_MASK;
data |= 0x0 << HPIPE_RST_CLK_CTRL_PIPE_WIDTH_OFFSET;
/* Set CORE_CLK output frequency for 250Mhz */
mask |= HPIPE_RST_CLK_CTRL_CORE_FREQ_SEL_MASK;
data |= 0x0 << HPIPE_RST_CLK_CTRL_CORE_FREQ_SEL_OFFSET;
reg_set(hpipe_addr + HPIPE_RST_CLK_CTRL_REG, data, mask);
Change the implementation to update semantics by anding data with mask.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ic72a8f64916274e08baef0b3f4c44a4fa07c1a6c
Currently reg_set() and reg_set16() are almost everywhere (both in
phy-comphy-3700.c and phy-comphy-cp110.c) used as if the semantics were
that of register update function (only bits that are set in mask are
updated):
reg_set(addr, data, mask) {
*addr = (*addr & ~mask) | (data & mask);
}
This comes both from names of arguments (data and mask), and from usage.
But both functions are in fact implemented via mmio_clrsetbits_32(), so
they actually first clear bits from mask and then set bits from data:
reg_set(addr, data, mask) {
*addr = (*addr & ~mask) | data;
}
There are only two places where this is leveraged (where some bits are
put into data argument but they are not put into the mask argument).
Fix those two usages to allow to convert the implementation from
clrsetbits semantics to update semantics.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Ib29a1dd7edcdee7a39c4752dbc9dfcd600d8cb5c
The comments about selector register values are wrong.
Bit 0 configures only lane 1, bit 4 only lane 0, and bit 8 lanes 0 and
2.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Iffe42374f92654ebe570557e0d462204439cfa31
Fix comment about COMPHY status register. PCIe/GbE0 PHY is on lane 1,
while USB3/GbE1 on lane 0.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I24734a61727d56f6eab2ed1c366d7a1810dbe19d
The current definitions of reference clock speed register values
#define PCIE_REF_CLOCK_SPEED_25M REF_CLOCK_SPEED_30M
#define USB3_REF_CLOCK_SPEED_25M REF_CLOCK_SPEED_30M
is ambiguous. The name of the constant implies 25 MHz, but the value
implies 30 MHz, which may make the reader think that the setting has
something to do with both values.
In reality, the values have different tables for SerDes and PCIe/USB3
PHY mode. The value for 25 MHz for PCIe/USB3 mode (0x2) is the value
for 30 MHz for SerDes mode.
Instead of defining the PCIe/USB3 constants relative to SerDes
constants, define them with absolute values, thus making it a little bit
more obvious that different modes have different value tables.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I50c66c6bbe22b9a9bec4685600cb8560524a643c
The MODE_REFDIV constant is only used as mask of the MODE_REFDIV
register, but we already have MODE_REFDIV_MASK constant for that.
Drop MODE_REFDIV.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: Icabb32189a7ca1a857dcf86cf0846bd0335f75d0
Constants SD_SPEED_1_25_G and SD_SPEED_2_5_G refer to SerDes frequency,
which is 1.25x that of data rate, since 1000base-x and 2500base-x use
the 8b/10b encoding:
mode frequency data rate
1000base-x 1.25 GHz 1 Gbps
2500base-x 3.125 GHz 2.5 Gbps
But the first constant refers to the frequency, while the second to the
data rate, which does not make sense.
Since the values in the specification refer to frequency, change the
name of the constant SD_SPEED_2_5_G to SD_SPEED_3_125_G to also refer to
the frequency, as SD_SPEED_1_25_G does.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I7670b45fa685aff93b3cafd84cf30d93620d8da1
According to Functional Specification, the common PHY register at offset
0x3f is actually Generation 3 Setting 2, while the register at offset
0x112 is Generation 2 Setting 3.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I4626672cbee2d08da1da7839a3cf3f90e78fa101
According to Functional Specification, the register at bit 1 of PHY
Configuration 1 is called PIN_PU_IVREF, not PIN_PU_IVEREF. Fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Change-Id: I912fa4a1956bf0b1b35a24925db03e3dbbe1adf3
Sometimes when changing UART clock from TBG to XTAL, UART HW enters into
some broken state. It does not transit characters from TX FIFO anymore
and TX FIFO stays always empty. TX FIFO reset does not recover UART HW
from this broken state.
Experiments show that external reset can fix UART HW from this broken
state.
TF-A fatal error handler calls console_a3700_core_init() function to
initialize UART HW. This handler may be called anytime during CPU
runtime, also when kernel is running.
U-Boot or Linux kernel may change UART clock to TBG to achieve higher
baudrates. During initialization, console_a3700_core_init() resets UART
configuration to default settings, which means that it also changes
UART clock from TBG to XTAL.
Do an external reset of UART via North Bridge Peripheral reset register
to prevent this UART hangup.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I8990bce24d1a6fd8ccc47a2cd0a5ff932fcfcf14
If TX FIFO is not empty, do not touch UART settings and let UART HW
transmit remaining bytes from TX FIFO. New UART settings are then set
only after TX FIFO is reset.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I2976c0a4fbb841d3a79d42ef67c06e70174afc3b
Followup changes will need function arguments in registers x0, x1 and
x2. Do not modify x1 and x2 registers and instead use scratch x3 and x4
registers for storing local variables.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I8551a802995f39128d2f4a8f8076b5bf463d0db0
Use long instead of long long on aarch64 for 64_t stdint types.
Introduce inttypes.h to properly support printf format specifiers for
fixed width types for such change.
Change-Id: I0bca594687a996fde0a9702d7a383055b99f10a1
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
The mvebu_a3700_comphy_pcie_power_on() function does not configure the
PHY selector explicitly, it relies on the register default value.
Configure the PHY selector just in case someone changed the default
value.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I54048b4bb7a5eced36f7fe6592ebe108f978fff0
Function polling_with_timeout() returns last value from polled register
on failure and zero on success. So set "ret" variable to error code
-ETIMEDOUT on error like it is done in other functions.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I16cac81bbcbe2113e139722dc0e8fc2b85428d1b
Subroutines in power functions may fail. So propagate failures from
subroutines back to the caller of power function with appropriate error
code in return value.
Function polling_with_timeout() returns last value from polled register
on failure and zero on success. So return -ETIMEDOUT on error from power
functions like it is doing Marvell comphy-cp110 driver.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I6c709c0c9616ab26829616a42a85b713f314b201
Physical address has to be stored in 64-bit data type as Armada 3720 is
64-bit platform. Driver already uses uintptr_t type for this purpise.
Change type of 'offset' variables in mvebu_a3700_comphy_usb3_power_on()
and mvebu_a3700_comphy_sgmii_power_on() / off() functions to uintptr_t
as in this variable is stored physical address of registers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I69581714f8899d21cc1a27005747708f0f1cd933
Parameter 'comphy_index' is not used and parameter 'mode' is used only
to check if speed is 1 Gbps or not.
Remove parameter 'comphy_index' and instead of 32-bit variable 'mode',
pass only boolean value which represents 1 Gbps speed.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I018d158f689ddf7d1f57003717d709c00d988fba
For code cleanup add two helper functions comphy_sata_set_indirect() and
comphy_usb_set_indirect() for SATA and USB 3.0 modes and remove additional
'mode' argument which is not needed anymore.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I23146f569db318dbaed5d411d7d175abf6efff85
Function mvebu_a3700_comphy_sata_power_off() uses comphy_mode parameter
only for extracting mode bits. Mode is always COMPHY_SATA_MODE, so
there is no need to pass comphy_mode parameter to this function. Use
directly COMPHY_SATA_MODE in mvebu_a3700_comphy_sata_power_off().
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: Ib6b7c2bf62c1ef4d8a6af240c08696d5cd506b14
There is no support for 2.5/3.125G SGMII. This 3.125G SerDes mode is not
SGMII. It is just plain 1000Base-X (as defined in IEEE 802.3z standard)
but upclocked 2.5x. This mode is commonly known under name 2500Base-X.
So remove incorrect SGMII keyword from names and comments and replace it
by more adequate 2500Base-X keyword.
There is no functional change in code, just renaming macros and updating
comments.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: If79aec16cc233f4896aafd75bfbbebb3f172a197
The UART code for the A3K platform assumes that UART parent clock rate
is always 25 MHz. This is incorrect, because the xtal clock can also run
at 40 MHz (this is board specific).
The frequency of the xtal clock is determined by a value on a strapping
pin during SOC reset. The code to determine this frequency is already in
A3K's comphy driver.
Move the get_ref_clk() function from the comphy driver to a separate
file and use it for UART parent clock rate determination.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I8bb18a2d020ef18fe65aa06ffa4ab205c71be92e
when comphy is in pcie mode, correct reference clock need be
selected according to SAR register that reflect the CPx_MPP boot
strapping pins. Either from external or from internal
Signed-off-by: Guo Yi <yguo@cavium.com>
Reviewed-by: Kostya Porotchkin <kostap@marvell.com>
Change-Id: I99ed64a141e85174cc0f8e9dab5886ab2506efa1
When configuring the UART_BAUD_REG register, the function
console_a3700_core_init() currently only changes the baud divisor field,
leaving other fields to their previous value.
This is incorrect, because the baud divisor is computed with the
assumption that the parent clock rate is 25 MHz, and since the other
fields in this register configure the parent clock, which could have
been changed by U-Boot or Linux.
Fix this function to also configure the other fields so that the UART
parent clock is selected to be the xtal clock.
For example without this change TF-A prints only
ERROR: a3700_system_off needs to be implemented
followed by garbage after plat_crash_console_init() is called.
After applying this change instead of garbage it also print crash info:
PANIC at PC : 0x0000000004023800
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I72f338355cc60d939b8bb978d9c7fdd576416b81
UART parent clock is by default the platform's xtal clock, which is
25 MHz.
The value defined in the driver, though, is 25.8048 MHz. This is a hack
for the suboptimal divisor calculation
Divisor = UART clock / (16 * baudrate)
which does not use rounding division, resulting in a suboptimal value
for divisor if the correct parent clock rate was used.
Change the code for divisor calculation to
Divisor = Round(UART clock / (16 * baudrate))
and change the parent clock rate value to 25 MHz.
The final UART divisor for default baudrate 115200 is not affected by
this change.
(Note that the parent clock rate should not be defined via a macro,
since the xtal clock can also be 40 MHz. This is outside of the scope of
this fix, though.)
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: Iaa401173df87aec94f2dd1b38a90fb6ed0bf0ec6
Some Marvell SoCs may have crypto engine disabled in the HW.
This patch checks the AP LD0 efuse for crypto engine/TRNG
presence before initializing the driver.
Change-Id: I441e7c69a137106bd36302b028b04c0b31896dbd
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/c/IP/SW/boot/atf/+/47314
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Yi Guo <yi.guo@cavium.com>
This patch forces rx training on 10G ports
as part of comphy_smc call from Linux.
Signed-off-by: Alex Evraev <alexev@marvell.com>
Change-Id: Iebe6ea7c8b21cbdce5c466c8a69b92e9d7c8a8ca
Reviewed-on: https://sj1git1.cavium.com/c/IP/SW/boot/atf/+/30763
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Stefan Chulski <stefanc@marvell.com>
Reviewed-by: Nadav Haklai <nadavh@marvell.com>
Setting MSS_SUPPORT to 0 also removes requirement for SCP_BL2
definition.
Images build with MSS_SUPPORT=0 will not include service CPUs
FW and will not support PM, FC and other features implemented
in these FW images.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Change-Id: Idf301ebd218ce65a60f277f3876d0aeb6c72f105
Reviewed-on: https://sj1git1.cavium.com/c/IP/SW/boot/atf/+/37769
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Stefan Chulski <stefanc@marvell.com>
Reviewed-by: Ofer Heifetz <oferh@marvell.com>
Reviewed-by: Nadav Haklai <nadavh@marvell.com>
Linux cpu clk driver requires access to some dfx registers. By adding
these registers to the white list, we enable access to them from
non-secure world.
Change-Id: Ic05c96b375121c025bfb41c2ac9474a530720155
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-on: https://sj1git1.cavium.com/25187
Tested-by: Kostya Porotchkin <kostap@marvell.com>
Reviewed-by: Kostya Porotchkin <kostap@marvell.com>
Since the dfx register set is going to be marked as secure expose dfx
secure read and write function via SiP services. In introduced misc_dfx
driver some registers are white-listed so non-secure software can still
access them.
This will allow non-secure word drivers access some white-listed
registers related to e.g.: Sample at reset, efuses, SoC type and
revision ID accesses.
Change-Id: If9ae2da51ab2e6ca62b9a2c940819259bf25edc0
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-on: https://sj1git1.cavium.com/25055
Tested-by: Kostya Porotchkin <kostap@marvell.com>
Reviewed-by: Kostya Porotchkin <kostap@marvell.com>
Since more drivers which uses dfx register set need to be handled with
use of SiP services, use dedicated and more meaningful name for thermal
SiP services.
Change-Id: Ic2ac27535a4902477df8edc4c86df3e34cb2344f
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-on: https://sj1git1.cavium.com/25054
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Kostya Porotchkin <kostap@marvell.com>
Since the dfx register set is going to be marked as secure (in order to
protect efuse registers for non secure access), accessing thermal
registers which are part of dfx register set, will not be possible from
lower exception levels. Due to above expose thermal driver as a SiP
service. This will allow Linux and U-Boot thermal driver to initialise
and perform various operations on thermal sensor.
The thermal sensor driver is based on Linux
drivers/thermal/armada_thermal.c.
Change-Id: I4763a3bf5c43750c724c86b1dcadad3cb729e93e
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-on: https://sj1git1.cavium.com/20581
Reviewed-by: Kostya Porotchkin <kostap@marvell.com>
Tested-by: Kostya Porotchkin <kostap@marvell.com>
Marvell Armada 3700 Functional Specifications, section 52.2 PCIe Link
Initialization says that TXDCLK_2X_SEL bit needs to be enabled for PCIe
Root Complex mode. Both U-Boot and Linux kernel support only Root Complex
mode. Set this bit.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: Id2a538c379b911b62597f9463b4842b7b5c24df7
Sandrine Bailleux
Elyes Haouas
Marek Behún
Pali Rohár
Scott Branden
Guo Yi
Konstantin Porotchkin
Alex Evraev
Grzegorz Jaszczyk
Alex Leibovich