Now all manual mode configurations are done as part of
IO delay recalibration sequence, remove the hack done for
CPSW.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In addition to the regular mux configuration, certain pins of DRA7
require to have "manual mode" also programmed, when predefined
delay characteristics cannot be used for the interface.
struct iodelay_cfg_entry is introduced for populating
manual mode IO timings.
For configuring manual mode, along with the normal pad
configuration do the following steps:
- Select MODESELECT field of each assocaited PAD.
CTRL_CORE_PAD_XXX[8]:MODESELECT = 1(Enable MANUAL_MODE macro along with mux)
- Populate A_DELAY, G_DELAY values that are specified in DATA MANUAL.
And pass the offset of the CFG_XXX register in iodelay_cfg_entry.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
On DRA7, in addition to the regular muxing of pins, an additional
hardware module called IODelay which is also expected to be
configured. This "IODelay" module has it's own register space that is
independent of the control module.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay recalibration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do muxing as part of IOdelay recalibration.
IODELAY recalibration sequence:
- Complete AVS voltage change on VDD_CORE_L
- Unlock IODLAY config registers.
- Perform IO delay calibration with predefined values.
- Isolate all the IOs
- Update the delay mechanism for each IO with new calibrated values.
- Configure PAD configuration registers
- De-isolate all the IOs.
- Relock IODELAY config registers.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
In addition to the regular mux configuration, certain pins of DRA7
require to have "virtual mode" also programmed.
This allows for predefined delay characteristics to be used by the SoC
to meet timing characterstics needed for the interface.
Provide easy to use macro to do the same.
For configuring virtual mode, along with normal pad configuration add
the following two steps:
- Select MODESELECT field of each assocaited PAD.
CTRL_CORE_PAD_XXX[8]:MODESELECT = 1
- DELAYMODE filed should be configured with value given in DATA Manual.
CTRL_CORE_PAD_XXX[7:4]:DELAYMODE =[0-15] (as given in DATA manual).
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Adopting the pinctrl register definitions from Linux kernel
to be consistent.
Old definitions will be removed once all the pinctrl data
is adapted to new definitions.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
do_set_mux32() is redefined in dra7xx and beagle_x15 boards.
IO delay recalibration sequence also needs this.
Making it generic to avoid duplication.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
A generic is_dra72x cpu check is useful for grouping
all the revisions under that. This is used in the
subsequent patches.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
DRA7 EMIF supports Full leveling for DDR3.
Adding support for the Full leveling sequence.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a hook to allows boards to add their own init to board_init().
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is required in order to avoid instability when running from caches
after the kernel starts.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add IOMUX for the pad used as USB pen. This needs to be driven low for
the Iris and Viola boards where it is pulled up high by default. This is
required for the USB host functionality to work on these boards. Use the
board specific weak initialisation function, to drive the pin low which
would be called on "usb start".
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Inorder to use the pins as GPIO, apart from setting the alt-function,
pinmuxing need to be done, this patch adds pinmux entries of
few GPIOs.
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
This commit adds support to the sunxi SPL to load u-boot from the internal
NAND. Note this only adds support to access the boot partitions to load
u-boot, full NAND support to load the kernel, etc. from the nand data
partition will come later.
Signed-off-by: Roy Spliet <r.spliet@ultimaker.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Make sure definitions for NAND clock and DMA gate bits are the same
across boards.
Signed-off-by: Roy Spliet <r.spliet@ultimaker.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add initial sun9i (A80) support, only uart + mmc are supported for now.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
We should not hardcode MXS_DMA_ALIGNMENT to 32, since we can not guarantee
that socs' cache line size is 32 bytes.
If on chips whose cache line size is 64 bytes, error occurs:
"
NAND: ERROR: v7_dcache_inval_range - start address is not aligned - 0xbdf1d1a0
ERROR: v7_dcache_inval_range - stop address is not aligned - 0xbdf1f4a0
ERROR: v7_dcache_inval_range - start address is not aligned - 0xbdf1d1a0
"
Align MXS_DMA_ALIGNMENT with ARCH_DMA_MINALIGN whose value is same to
CONFIG_SYS_CACHELINE_SIZE if CONFIG_SYS_CACHELINE_SIZE defined.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
ccsr_ddr structure is already defined in fsl_immap.h. Remove
this duplicated define. Move fixed timing into ls1021atwr.h.
Signed-off-by: York Sun <yorksun@freescale.com>
CC: Alison Wang <alison.wang@freescale.com>
Acked-by: Alison Wang <alison.wang@freescale.com>
We've never tested the lvds panel support on sun6i+ SoCs until now, and
unsurprisingly the lvds code needed some fixes to work on my ga10h A33
tablet with lvds panel. This makes the panel on that tablet actually work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Make DRAM_ODT_EN Kconfig setting a bool, add a separate DRAM_ODT_CORRECTION
setting for A23 SoCs and use DRAM_ODT_EN Kconfig everywhere instead of
only in dram_sun4i.c and hardcoding odt_en elsewhere.
Note this commit makes no functional changes for existing boards,
its purpose is to allow changing the odt_en value on future A33 boards.
For sun4i/sun5i/sun7i boards which set DRAM_ODT_EN=y (which no defconfigs
currently do) this patch turns on odt for both the DQ and the DQS lines,
whereas previously it was possibly (but not desirable) to turn odt on only
for one of them by setting the in DRAM_ODT_EN option to 1 or 2 instead of 3.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Add support for UART2 (2-pin version but note that RTS/CTS pins are available
pn that port for possible future use), can be selected in config
by using CONFIG_CONS_INDEX=3
Signed-off-by: Laurent Itti <laurentitti@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The MX6 has a temperature grade defined by OCOTP_MEM0[7:6] which is at 0x480
in the Fusemap Description Table in the reference manual. Return this value
as well as min/max temperature based on the value.
Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
their Fusemap Description Table however Freescale has confirmed that these
eFUSE bits match the description within the IMX6DQRM and that they will
be added to the next revision of the respective reference manuals.
This has been tested with IMX6 Automative and Industrial parts.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
The IMX6 has four different speed grades determined by eFUSE SPEED_GRADING
indicated by OCOTP_CFG3[17:16] which is at 0x440 in the Fusemap Description
Table. Return this frequency so that it can be used elsewhere.
Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
their Fusemap Description Table however Freescale has confirmed that these
eFUSE bits match the description within the IMX6DQRM and that they will
be added to the next revision of the respective reference manuals.
These have been tested with IMX6 Quad/Solo/Dual-light 800Mhz and 1GHz grades.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Enable IOMUX_CONFIG_SION for all I2C pin mux settings, otherwise
we will get erros when doing i2c operations.
error log like the following:
"
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0xb retry=1
"
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Having bit 22 cleared in the PL310 Auxiliary Control register (shared
attribute override enable) has the side effect of transforming Normal
Shared Non-cacheable reads into Cacheable no-allocate reads.
Coherent DMA buffers in Linux always have a Cacheable alias via the
kernel linear mapping and the processor can speculatively load cache
lines into the PL310 controller. With bit 22 cleared, Non-cacheable
reads would unexpectedly hit such cache lines leading to buffer
corruption.
This was inspired by a patch from Catalin Marinas [1] and also from recent
discussions in the linux-arm-kernel list [2] where Russell King and Rob Herring
suggested that bootloaders should initialize the cache.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-November/031810.html
[2] https://lkml.org/lkml/2015/2/20/199
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
1. Introduce a new structure `struct mxc_i2c_bus`, this structure will
used for non-DM and DM.
2. Remove `struct mxc_i2c_regs` structure, but use register offset to access
registers based on `base` entry of `struct mxc_i2c_bus`.
3. Remove most `#ifdef I2C_QUIRK_REG`. Using driver_data to contain platform
flags. A new flag is introduced, I2C_QUIRK_FLAG.
4. Most functions use `struct mxc_i2c_bus` as one of the parameters.
Make most functions common to DM and non-DM, try to avoid duplicated code.
5. Support DM, but pinctrl is not included. Pinmux setting is still set
by setup_i2c, but we do not need bus_i2c_init for DM.
6. struct i2c_parms and struct sram_data are removed.
7. Remove bus_i2c_read bus_i2c_write prototype in header file. The frist
paramter of bus_i2c_init is modified to i2c index. Add new prototype
i2c_idle_bus and force_bus_idle. Since bus_i2c_init is not good for
DM I2C and pinctrl is missed, we use a weak function for i2c_idle_bus.
Board file take the responsibility to implement this function, like this:
"
int i2c_idle_bus(struct mxc_i2c_bus *i2c_bus)
{
if (i2c_bus->index == 0)
force_bus_idle(i2c_pads_info0);
else if (i2c_bus->index == 1)
force_bus_idle(i2c_pads_info1);
else
xxxxxx
}
"
8. Introduce a weak function, enable_i2c_clk
9. Tested on an i.MX7 platform. Log info:
=> dm tree
Class Probed Name
----------------------------------------
root [ + ] root_driver
simple_bus [ ] |-- soc
simple_bus [ ] | |-- aips-bus@30000000
simple_bus [ ] | | |-- anatop@30360000
simple_bus [ ] | | `-- snvs@30370000
simple_bus [ ] | |-- aips-bus@30400000
simple_bus [ ] | `-- aips-bus@30800000
i2c [ ] | |-- i2c@30a20000
i2c [ ] | `-- i2c@30a40000
simple_bus [ ] `-- regulators
=> i2c dev 0
Setting bus to 0
=> i2c probe
Valid chip addresses: 08 50
=> i2c md 8 31
0031: 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>
These GPIO_PORTx macros should be in gpio.h, but not in imx-regs.h.
Also, imx-regs.h and iomux-v3.h has same macro defintion for
GPIO_PORTx, and both of them are included in mxc_i2c.c(include
mxc_i2c.h). This will incur build warnings with macro redefinition.
Since iomux-v3.h is not compatible with mx27, we can not simply
include iomux-v3.h for mx27, so move the GPIO_PORTx to gpio.h to
fix the build warning.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
It is convenient for some boards to implement save_boot_params() in C rather
than assembler. Provide a way to return in this case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
This commit adds support for the OHCI companion controller, which makes
usb-1 devices directly plugged into to usb root port work.
Note for now this switches usb-keyboard support for sunxi back from int-queue
support to the old interrupt polling method. Adding int-queue support to the
ohci code and switching back to int-queue support is in the works.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Make sure to enable the SMMU when booting the kernel in non-secure mode.
This is necessary because some of the SMMU registers are restricted to
TrustZone-secured requestors, hence the kernel wouldn't be able to turn
the SMMU on. At the same time, enable translation for all memory clients
for the same reasons. The kernel will still be able to control SMMU IOVA
translation using the per-SWGROUP enable bits.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
These registers can be used to prevent non-secure world from accessing a
megabyte aligned region of RAM, use them to protect the u-boot secure monitor
code.
At first I tried to do this from s_init(), however this inexplicably causes
u-boot's networking (e.g. DHCP) to fail, while networking under Linux was fine.
So instead I have added a new weak arch function protect_secure_section()
called from relocate_secure_section() and reserved the region there. This is
better overall since it defers the reservation until after the sec vs. non-sec
decision (which can be influenced by an envvar) has been made when booting the
os.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
[Jan: tiny style adjustment]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is based on Thierry Reding's work and uses Ian Campell's
preparatory patches. It comes with full support for CPU_ON/OFF PSCI
services. The algorithm used in this version for turning CPUs on and
off was proposed by Peter De Schrijver and Thierry Reding in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/210881. It
consists of first enabling CPU1..3 via the PMC, just to powergate them
again with the help of the Flow Controller. Once the Flow Controller is
in place, we can leave the PMC alone while processing CPU_ON and CPU_OFF
PSCI requests.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra boards will have to initialize power management for the PSCI
support this way.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Will be used for unpowergating CPUs.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
In this case the secure code lives in RAM, and hence the memory node in
the device tree needs to be adjusted. This avoids that the OS will map
and possibly access the reservation.
Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out
such a region. We only support cutting off memory from the beginning or
the end of a RAM bank as we do not want to increase their number (which
would happen if punching a hole) for simplicity reasons
This will be used in a subsequent patch for Jetson-TK1.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
I will need mc_security_cfg0/1 in a future patch and I added the rest while
debugging, so thought I might as well commit them.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Tested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Tom Warren <twarren@nvidia.com>
