| ed5ddebe | 27-Feb-2016 |
Paul Kocialkowski <contact@paulk.fr> |
omap4: Export jedec sdram timings
Individual boards might provide their own emif_get_device_timings function and
use the jedec timings in their own way, hence those have to be exported.
Signed-off-
omap4: Export jedec sdram timings
Individual boards might provide their own emif_get_device_timings function and
use the jedec timings in their own way, hence those have to be exported.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
show more ...
|
| 96703acd | 27-Feb-2016 |
Paul Kocialkowski <contact@paulk.fr> |
omap4: Export elpidia sdram timings
Individual boards might provide their own emif_get_device_timings function and
use the elpidia timings in their own way, hence those have to be exported.
Signed-
omap4: Export elpidia sdram timings
Individual boards might provide their own emif_get_device_timings function and
use the elpidia timings in their own way, hence those have to be exported.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
show more ...
|
| 90ca5dfe | 27-Feb-2016 |
Paul Kocialkowski <contact@paulk.fr> |
omap3: Use a define for reboot reason offset
This introduces a define for the offset to the reboot reason, rather than
hardcoding it.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by
omap3: Use a define for reboot reason offset
This introduces a define for the offset to the reboot reason, rather than
hardcoding it.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
show more ...
|
| c5412b08 | 27-Feb-2016 |
Paul Kocialkowski <contact@paulk.fr> |
omap3: String-based reboot mode handling
This switches reboot mode handling to a string-based interface, that allows more
flexibility to set a common interface with the next generations of OMAP devi
omap3: String-based reboot mode handling
This switches reboot mode handling to a string-based interface, that allows more
flexibility to set a common interface with the next generations of OMAP devices.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
show more ...
|
| 29c20ba2 | 05-Mar-2016 |
Lokesh Vutla <lokeshvutla@ti.com> |
ARM: DRA7: emif: Enable interleaving for higher address space
Given that DRA7/OMAP5 SoCs can support more than 2GB of memory,
enable interleaving for this higher memory to increase performance.
Sig
ARM: DRA7: emif: Enable interleaving for higher address space
Given that DRA7/OMAP5 SoCs can support more than 2GB of memory,
enable interleaving for this higher memory to increase performance.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
show more ...
|
| d88d6c8c | 24-Feb-2016 |
Kipisz, Steven <s-kipisz2@ti.com> |
ARM: OMAP4/5: Add generic board detection hook
Many TI EVMs have capability to store relevant board information
such as DDR description in EEPROM. Further many pad configuration
variations can occur
ARM: OMAP4/5: Add generic board detection hook
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>
show more ...
|
| 0bea813d | 24-Feb-2016 |
Lokesh Vutla <lokeshvutla@ti.com> |
ARM: omap-common: Add standard access for board description EEPROM
Several TI EVMs have EEPROM that can contain board description information
such as revision, DDR definition, serial number, etc. In
ARM: omap-common: Add standard access for board description EEPROM
Several TI EVMs have EEPROM that can contain board description information
such as revision, DDR definition, serial number, etc. In just about all
cases, these EEPROM are on the I2C bus and provides us the opportunity
to centralize the generic operations involved.
The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM,
AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format.
However, DRA-7* EVMs, OMAP4SDP use a modified format.
We hence introduce logic which is generic between these platforms
without enforcing any specific format. This allows the boards to use the
relevant format for operations that they might choose.
This module will compile for all TI SoC based boards when
CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for
platforms that require this support.
It is important to note that this logic is fundamental to the board
configuration process such as DDR configuration which is needed in
SPL, hence cannot be part of the standard u-boot driver model (which
is available later in the process). Hence, to aid efficiency, the
eeprom contents are copied over to SRAM scratchpad memory area at the
first invocation to retrieve data.
To prevent churn with cases such as DRA7, where eeprom format maybe
incompatible, we introduce a generic common format in eeprom which
is made available over accessor functions for usage.
Special handling for BBG1 EEPROM had to be introduced thanks to the
weird eeprom rev contents used.
The follow on patches introduce the use of this library for AM335x,
AM437x, and AM57xx.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
show more ...
|
| 725700dc | 24-Feb-2016 |
Kipisz, Steven <s-kipisz2@ti.com> |
ARM: OMAP4/5: Centralize gpi2c_init
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
ARM: OMAP4/5: Centralize gpi2c_init
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>
show more ...
|
| 93e6253d | 24-Feb-2016 |
Kipisz, Steven <s-kipisz2@ti.com> |
ARM: OMAP4/5: Centralize early clock initialization
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 i
ARM: OMAP4/5: Centralize early clock initialization
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>
show more ...
|
| 85307835 | 14-Mar-2016 |
Jacob Chen <jacob-chen@iotwrt.com> |
rockchip: video: Add LVDS support in vop driver
LVDS have a different display out mode, add code to get right flag.
The vop_ip decide display device and the remote_vop_id decide which
vop was being
rockchip: video: Add LVDS support in vop driver
LVDS have a different display out mode, add code to get right flag.
The vop_ip decide display device and the remote_vop_id decide which
vop was being used. So we should use the remote_vop_id to set DCLK_VOP.
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Acked-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 09959ba3 | 11-Feb-2016 |
Vikas Manocha <vikas.manocha@st.com> |
gpio: stm32_gpio: move base addresses to the soc file
Base addresses for GPIOs could be different for different socs, this
patch moves the base addresses from driver to the soc specific location.
S
gpio: stm32_gpio: move base addresses to the soc file
Base addresses for GPIOs could be different for different socs, this
patch moves the base addresses from driver to the soc specific location.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
show more ...
|
| 14cec061 | 11-Feb-2016 |
Vikas Manocha <vikas.manocha@st.com> |
gpio: stm32_gpio: move clock config from driver to board
This patch removes the gpio clock enable from gpio driver & move it in the
board code, making it possible to use the gpio driver with other s
gpio: stm32_gpio: move clock config from driver to board
This patch removes the gpio clock enable from gpio driver & move it in the
board code, making it possible to use the gpio driver with other socs.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
show more ...
|