According to AM572x DM SPRS953A, QSPI maximum bus speed can be 76.8MHz.
Therefore, increase the spi-max-frequency value of QSPI node to 76.8MHz
for DRA74 and DRA72 evm. This improves flash raw read speed by ~2MB/s.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Rename the tag of the 3.3 V regulator used in the DRA72 EVM in
order to have a consistent tag name with the DRA7 EVM. This
is useful when the regulator needs to be referenced in common
dtsi files (i.e. for common companion boards like JAMR3 [1]).
[1] http://www.ti.com.cn/cn/lit/ug/sprui52/sprui52.pdf
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on
DRA74(rev 1.1+)/DRA72 EVM can support up to 64MHz in MODE-0, whereas
MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better
throughput.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
DRA7 family of processors from Texas Instruments, have a hardware module
called IODELAYCONFIG Module which is expected to be configured. This
block allows very specific custom fine tuning for electrical
characteristics of IO pins that are necessary for functionality and
device lifetime requirements. IODelay module has it's own register space
with registers to configure various pins.
According to AM572x TRM SPRUHZ6E October 2014–Revised January 2016[1]
section 18.4.6.1 Pad Configuration, in addition to pinmuxing(MUXMODE),
when operating a pad in certain mode, Virtual/Manual IO Timing Mode must
also be configured to ensure that IO timings are met (DELAYMODE and
MODESELECT fields of pad's IODELAYCONFIG module register). According to
section 18.4.6.1.7 Isolation Requirements of above TRM, when
reprogramming MUXMODE, DELAYMODE, and MODESELECT fields, there is a
potential for a significant glitch on the corresponding IO. It is hence
recommended to do this with I/O isolation (which can only be done in
initial stages of bootloader). QSPI is one such module that requires
IODELAY configuration. So, this patch removes the pinmux for
QSPI for DRA74/DRA72 EVM as it needs to be done in bootloader (U-Boot)
and cannot be done in kernel.
Users should migrate to U-Boot v2016.05-rc1 or higher.
[1] http://www.ti.com/lit/ug/spruhz6e/spruhz6e.pdf
Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The boards use a TI variant of the PCF8575 so specify that
in the compatible string.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
As per the data sheet starting from SPRUHQ0H (Nov 2015 - Latest[1]),
VDD_CORE can vary from 0.85v to 1.15v for AVS class0. VDD GPU/DSP
et.al. can range from 0.85v to 1.25V with AVS class0
Since dynamic voltage scaling is disabled for DRA7/AM57xx SoCs for
all SoC rails other than MPU, the bootloader is responsible for
setting up the AVS class0 voltage, however, with wrong voltage machine
constraints in dtb, regulator framework will lower the voltage below
the required voltage levels for certain samples in production flow.
This can cause catastrophic failures which can be pretty hard to
identify.
Update board files which don't match required specification.
[1] http://www.ti.com/product/AM5728/datasheet/specifications#SPRT637-7340
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
DRA72-EVM now has an upgrade to Rev C with SR2.0 silicon. As part of
this change, a few updates were factored in that were software
incompatible with previous board in few areas:
- We now use DP83867 ethernet phy instead of older DP838865 which fails
in certain use cases.
- Two Ethernet ports now instead of the single one in rev B.
- polarities changed for certain pcf gpios
- Due to SoC phy current requirements, VDDA supplies are split between
ldo3 and ldo2 (ldo2 was previously unused). NOTE: DSS (VDDA_VIDEO) is
still supplied by ldo5, HDMI is now supplied by LDO2 instead of using
LDO3.
NOTE: It does not make much sense to spin off a new board compatible
flag since there is no real benefit for the same.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
