| Age | Commit message (Collapse) | Author |
|---|
|
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Now that omap_hsmmc has support for hs200 mode, change the clock
frequency to 192MHz. Also change the REFERENCE CLOCK frequency to
192MHz based on which the internal mmc clock divider is calculated.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
|
|
different hw revisions
AM572x SR1.1 requires different IODelay values to be used than that used
in AM572x SR2.0. These values are populated in device tree. Add
capability in omap_hsmmc driver to extract IOdelay values for different
silicon revision. The maximum frequency is also reduced when using a ES1.1.
To keep the ability to boot both revsions with the same dtb, those values
can be provided by the platform code.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
|
|
Add a new API to perform iodelay recalibration without isolate
io to be used in uboot.
The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met. The MMC driver can use the new API to
set the IO delay values depending on the MMC mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
|
|
DRA762 comes in two packages:
- ABZ: Pin compatible package with DRA742 with DDR@1333MHz
- ACD: High performance(OPP_PLUS) package with new IPs
Both the above packages uses the same IDCODE hence needs to
differentiate using package information in DIE_ID_2.
Add support for the same. Also update clock, ddr, emif information.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
MCAN can be accessed via DCAN1 or DCAN2. Determining which DCAN instance
to use if any at all is done through
CTRL_CORE_CONTROL_SPARE_RW.SEL_ALT_MCAN. Since general pinmuxing is
handled in U-boot. Handle this additional pinmuxing requirement in U-boot
to ensure that MCAN is used by default via the DCAN1 pins.
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
[fcooper@ti.com: Update commit message and use DCAN1 not DCAN2 for MCAN]
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
|
|
Align the base address defined in header files with the base address used
in the DTS. This will facilitate the introduction of the DMA support.
Of all HSMMC users, only omap3 doesn't have the 0x100 reserved region at
the top. This region will be used to determine if the controller supports
DMA transfers
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Commit 6ae4c3efbd62 ("ARM: DRA7: Add pinctrl register definitions")
has added new macros for pinmux configuration in line with the kernel
definitions. Cleanup the old pinctrl macros from the common header
file so that they are not used by any new boards.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
DRA71x processors are reduced pin and software compatible
derivative of DRA72 processors. Add support for detection
of SR2.1 version of DRA71x family of processors.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
dra76-evm uses lp8736 and tps65917 pmic for powering on
various peripherals. Add data for these pmics and register
for dra76-evm.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
dra76 family is a high-performance, infotainment application
device, based on OMAP architecture on a 28-nm technology.
This contains most of the subsystems, peripherals that are
available on dra74, dra72 family. This SoC mainly features
Subsystems:
- 2 x Cortex-A15 with max speed of 1.8GHz
- 2 X DSP
- 2 X Cortex-M4 IPU
- ISS
- CAL
- DSS
- VPE
- VIP
Connectivity peripherals:
- 1 USB3.0 and 3 USB2.0 subsystems
- 1 x SATA
- 2 x PCI Express Gen2
- 3-port Gigabit ethernet switch
- 2 x CAN
- MCAN
Adding CPU detection support for the dra76 ES1.0 soc
and update prcm, control module, dplls data.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
This converts the following to Kconfig:
CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
[trini: Fix AM43XX drop AM44XX]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
For consistency with other platforms and in preparation of Kconfig
migration, let's change Several TI platforms that use I2C_BUS_MAX
to CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <aford173@gmail.com>
|
|
OMAP5432 did go into production with AVS class0 registers which were
mutually exclusive from AVS Class 1.5 registers.
Most OMAP5-uEVM boards use the pre-production Class1.5 which has
production efuse registers set to 0. However on production devices,
these are set to valid data.
scale_vcore logic is already smart enough to detect this and use the
"Nominal voltage" on devices that do not have efuse registers populated.
On a test production device populated as follows:
MPU OPP_NOM:
=> md.l 0x04A0021C4 1
4a0021c4: 03a003e9 ....
(0x3e9 = 1.01v) vs nom voltage of 1.06v
MPU OPP_HIGH:
=> md.l 0x04A0021C8 1
4a0021c8: 03400485 ..@.
MM OPP_NOM:
=> md.l 0x04A0021A4 1
4a0021a4: 038003d4 ....
(0x3d4 = 980mV) vs nom voltage of 1.025v
MM OPP_OD:
=> md.l 0x04A0021A8 1
4a0021a8: 03600403 ..`.
CORE OPP_NOM:
=> md.l 0x04A0021D8 1
4a0021d8: 000003cf ....
(0x3cf = 975mV) vs nom voltage of 1.040v
Since the efuse values are'nt currently used, we do not regress on
existing pre-production samples (they continue to use nominal voltage).
But on boards that do have production samples populated, we can leverage
the optimal voltages necessary for proper operation.
Tested on:
a) 720-2644-001 OMAP5UEVM with production sample.
b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.
Data based on OMAP5432 Technical reference Manual SWPU282AF (May
2012-Revised Aug 2016)
NOTE: All collaterals on OMAP5432 silicon itself seems to have been
removed from ti.com, though EVM details are still available:
http://www.ti.com/tool/OMAP5432-EVM
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
ES2.0 descopes OPP_LOW definition. So remove it from macros defined.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
Refactor OMAP3/4/5 code so that we have only one get_device_type()
function for all platforms.
Details:
- Add ctrl variable for AM33xx and OMAP3 platforms (like it's done for
OMAP4/5), so we can obtain status register in common way
- For now ctrl structure for AM33xx/OMAP3 contains only status register
address
- Run hw_data_init() in order to assign ctrl to proper structure
- Remove DEVICE_MASK and DEVICE_GP definitions as they are not used
(DEVICE_TYPE_MASK and GP_DEVICE are used instead)
- Guard structs in omap_common.h with #ifdefs, because otherwise
including omap_common.h on non-omap4/5 board files breaks compilation
Buildman script was run for all OMAP boards. Result output:
arm: (for 38/616 boards)
all +352.5
bss -1.4
data +3.5
rodata +300.0
spl/u-boot-spl:all +284.7
spl/u-boot-spl:data +2.2
spl/u-boot-spl:rodata +252.0
spl/u-boot-spl:text +30.5
text +50.4
(no errors to report)
Tested on AM57x EVM and BeagleBoard xM.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
[trini: Rework the guards as to not break TI81xx]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
While in theory this value could be used in places outside of "omap5"
(such as OMAP4), we only make use of it today in OMAP5, so place the
Kconfig entry there. Given that Kconfig lets us provide a default, we
drop CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC entirely. The contents of
doc/README.omap-reset-time make a good help entry, so adjust them
slightly and delete the file. Move the comment about range to where we
use the value now, and have Kconfig enforce the upper bound.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
GPIO_TO_PIN(bank, bank_gpio) returns the GPIO index
from the GPIO bank number and bank's GPIO offset number.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
When using early malloc the allocated memory can overflow into the SRAM
scratch space, move NON_SECURE_SRAM_IMG_END down a bit to allow more
dynamic allocation at the expense of a slightly smaller maximum image
size.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_gp_evm_A3a_sr2p0 that were autogenerated on
19th October, 2016 by "Ahmad Rashed<a-rashed@ti.com>".
[1] https://dev.ti.com/pinmux/app.html#/default/
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add the pmic_data for LP873x PMIC which is used to power
up dra71x-evm.
Note: As per the DM[1] DRA71x supports only OP_NOM. So, updating
the efuse registers only to use OPP_NOM irrespective of any
CONFIG_DRA7_<VOLT>_OPP_{NOM,od,high} is defined.
[1] http://www.ti.com/product/DRA718/technicaldocuments
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Redefine the macros used to define the voltage values and the
efuse register offsets based on OPP for all the voltage domains.
This is done using Kconfig macros that can be set in a defconfig
or selected during a config step. This allows a voltage domain
to be configured/set to a corresponding voltage value depending
on the OPP selection choice.
The Kconfig choices have been added for MPU, DSPEVE, IVA and GPU
voltage domains, with the MPU domain restricted to OPP_NOM. The
OPP_OD and OPP_HIGH options will be added when the support for
configuring the MPU clock frequency is added. The clock
configuration for other voltage domains is out of scope in
u-boot code.
The CORE voltage domain does not have separate voltage values
and efuse register offset at different OPPs, while the MPU
voltage domain only has different efuse register offsets for
different OPPs, but uses the same voltage value. Any different
choices of OPPs for voltage domains on common ganged-rails
is automatically taken care to select the corresponding
highest OPP voltage value.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
CONFIG_AM57XX is just an unnecessary macro that is redundant given So,
remove the same instead of spreading through out the u-boot source
code and getting in the way to maintain common code for DRA7x family.
Acked-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
This patch enables the DFU boot mode support
for dra7x platform.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
On all TI platforms the ROM defines a "downloaded image" area at or near
the start of SRAM which is followed by a reserved area. As it is at
best bad form and at worst possibly harmful in corner cases to write in
this reserved area, we stop doing that by adding in the define
NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
At current we define the end of scratch space at 0x228 bytes past the
start of scratch space this this gives us a lot of room to grow. As
these scratch uses are non-optional today, all targets are modified to
respect this boundary.
Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Nagendra T S <nagendra@mistralsolutions.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Paul Kocialkowski <contact@paulk.fr>
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Adam Ford <aford173@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Thomas Weber <weber@corscience.de>
Cc: Hannes Schmelzer <oe5hpm@oevsv.at>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Samuel Egli <samuel.egli@siemens.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Cc: Ben Whitten <ben.whitten@gmail.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: "B, Ravi" <ravibabu@ti.com>
Cc: "Matwey V. Kornilov" <matwey.kornilov@gmail.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Ash Charles <ashcharles@gmail.com>
Cc: "Kipisz, Steven" <s-kipisz2@ti.com>
Cc: Daniel Allred <d-allred@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Ladislav Michl <ladis@linux-mips.org>
|
|
The register offset of i2c_sysc offset is not correct as per
omap5[1]/dra7[2] TRM, correct the offsets as per the
documentation.
[1] - http://www.ti.com/lit/pdf/swpu249
[2] - http://www.ti.com/lit/pdf/spruhz6
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
The pmic registers for variants of am57xx boards are different
hence we need to assign them carefully based on the board type.
Add a function to assign omap_vcores after the board detection.
Signed-off-by: Keerthy <j-keerthy@ti.com>
|
|
Define specific macros for the voltage values for all voltage
domains for all applicable OPPs - OPP_NOM, OPP_OD and OPP_HIGH.
No separate macros are defined for VD_MPU and VD_CORE at OPP_OD
and OPP_HIGH as these use the same values as OPP_NOM.
The current macros will be used as common macros that can be
redefined appropriately based on a selected OPP configuration
at build time.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
The voltage values for each voltage domain at an OPP is identical
across all the SoCs in the DRA7 family. The current code defines
one set of macros for DRA75x/DRA74x SoCs and another set for DRA72x
macros. Consolidate both these sets into a single set.
This is done so as to minimize the number of macros used when voltage
values will be added for other OPPs as well.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
Define a set of common macros for the efuse register offsets
(different for each OPP) that are used to get the AVS Class 0
voltage values and ABB configuration values. Assign these
common macros to the register offsets for OPP_NOM by default
for all voltage domains. These common macros can then be
redefined properly to point to the OPP specific efuse register
offset based on the desired OPP to program a specific voltage
domain.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
The current OPP_NOM voltage values defined for the MPU and CORE
voltage domains are based on the initial DRA75x_74x_SR1.1_DM data
manual. As per this DM, the PMIC boot voltage can be set to either
1.10V or 1.15V for VD_MPU, and either 1.06V or 1.15V for VD_CORE.
While the current values are correct, the latter set of values
are the values that are common across all DRA75x, DRA72x SoCs and
for all current Silicon revisions. So, update both the MPU and CORE
OPP_NOM voltages to 1.15V.
The macros are also slightly reorganized so that both the MPU and
CORE voltage domain values are defined together.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
|
|
Add platforms specific phy mode configuration bits to be used
to configure phy mode in control module.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
ABB should be initialized for all required domains voltage domain
for DRA7: IVA, GPU, EVE in addition to the existing MPU domain. If
we do not do this, kernel configuring just the frequency using the
default boot loader configured voltage can fail on many corner lot
units and has been hard to debug. This specifically is a concern with
DRA7 generation of SoCs since other than VDD_MPU, all other domains
are only permitted to setup the voltages to required OPP only at boot.
Reported-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Since we setup the voltage and frequency for the MM domain, we *must*
setup the ABB configuration needed for the domain as well. If we do not
do this, kernel configuring just the frequency using the default boot
loader configured voltage can fail on many corner lot units.
Reported-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
do_set_iodelay can now be used from board files based on needs of the
platforms variation they have.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Since many platforms may need different pad configuration required
depending on variation of the platform with minor deltas, it is
easier to maintain a sub step based approach to allow for pin mux
and iodelay configuration which may depend on the platform variations
and need to be done in IO isolation.
While we retain the older __recalibrate_iodelay function which provides
a ready sequencing, __recalibrate_iodelay_start and
__recalibrate_iodelay_end may be alternatively used now and the callers
will be responsible for the correct sequencing of operations.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add support for detection of SR2.0 version of DRA72x family of
processors.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
There is no distinction between essential and non-essential mux configuration,
so it doesn't make sense to have an "essential" prefix.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
Many TI EVMs have capability to store relevant board information
such as DDR description in EEPROM. Further many pad configuration
variations can occur as part of revision changes in the platform.
In-order to support these at runtime, we for a board detection hook
which is available for override from board files that may desire to do
so.
NOTE: All TI EVMs are capable of detecting board information based on
early clocks that are configured. However, in case of additional needs
this can be achieved within the override logic from within the board
file.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Centralize gpi2c_init into omap_common from the sys_proto header so
that the information can be reused across SoCs.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Early clock initialization is currently done in two stages for OMAP4/5
SoCs. The first stage is the initialization of console clocks and
then we initialize basic clocks for functionality necessary for SoC
initialization and basic board functionality.
By splitting up prcm_init and centralizing this clock initialization,
we setup the code for follow on patches that can do board specific
initialization such as board detection which will depend on these
basic clocks.
As part of this change, since the early clock initialization
is centralized, we no longer need to expose the console clock
initialization.
NOTE: we change the sequence slightly by initializing console clocks
timer after the io settings are complete, but this is not expected
to have any functioanlity impact since we setup the basic IO drive
strength initialization as part of do_io_settings.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
introduce BIT() definition, used in at91_udc gadget
driver.
Signed-off-by: Heiko Schocher <hs@denx.de>
[remove all other occurrences of BIT(x) definition]
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
|
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in omap5 board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in beagle_x15 board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Enabled clocks for the second dwc3 controller and second USB PHY present in
DRA7.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
DP83865 ethernet phy used on DRA74x-evm is quirky and the datasheet
provided IODELAY values for standard RGMII phys do not work.
Silicon Revision(SR) 2.0 provides an alternative bit configuration
that allows us to do a "gross adjustment" to launch the data off a
different internal clock edge. Manual IO Delay overrides are still
necessary to fine tune the clock-to-data delays. This is a necessary
workaround for the quirky ethernet Phy we have on the platform.
NOTE: SMA registers are spare "kitchen sink" registers that does
contain bits for other workaround as necessary as well. Hence the
control for the same is introduced in a generic SoC specific, board
generic location.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add support for detection of ES2.0 version of DRA7 family of
processors. ES2.0 is an incremental revision with various fixes
including the following:
- reset logic fixes
- few assymetric aging logic fixes
- MMC clock rate fixes
- Ethernet speed fixes
- edma fixes for mcasp
[ravibabu@ti.com: posted internal for an older bootloader]
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
