Reduce the lcd_display_bitmap #ifdef complexity by extracting Atmel-specific
code for setting cmap for bitmap images into a new function lcd_set_cmap().
A default version is implemented with the remainder of the code.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
Reduce the bitmap_plot #ifdef complexity by extracting MPC823-specific code for
setting cmap into its own implementation of lcd_logo_set_cmap(), implemented in
mpc8xx_lcd.c. In the MPC823 implementation, ARRAY_SIZE(bmp_logo_palette) is
switched for BMP_LOGO_COLORS to avoid having to include bmp_logo_data.h, which
would cause a compilation error because the logo data and palette arrays would
be defined twice.
This is a step towards cleaning bitmap_plot() of platform-specific code.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
Reduce the bitmap_plot #ifdef complexity by extracting Atmel-specific code for
setting cmap into a new function lcd_logo_set_cmap(), which is implemented in
atmel_lcdfb driver and defined as part of common/lcd.c api with a weak dummy
version. In the Atmel implementation, ARRAY_SIZE(bmp_logo_palette) is
switched for BMP_LOGO_COLORS to avoid having to include bmp_logo_data.h, which
would cause a compilation error because the logo data and palette arrays would
be defined twice.
This is a step towards cleaning bitmap_plot() of platform-specific code.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
Reduce the amount of platform-specific code in common/lcd.c by moving MPC823
implementation of fb_put_byte() to mpc8xx_lcd.c. Since we must also have a
default implementation for everybody else, make the remainder of the code
into a weak function.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
Reduce the amount of platform-specific code in common/lcd.c by moving Atmel
implementation of fb_put_word() to atmel_lcdfb.c. Since we must also have a
default implementation for everybody else, make the remainder of the code
into a weak function.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
configuration_get_cmap() is multiple platform-specific functions stuffed into
one function. Split it into multiple versions, and move each version to the
appropriate driver to reduce the #ifdef complexity.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Anatolij Gustschin <agust@denx.de>
As the PMECC hardware has different version. In SAMA5D4 chip, the PMECC ip
can generate 0xff pmecc ECC value for all 0xff sector.
According to this, add PMECC version check, if it's SAMA5D4 then we always
let PMECC hardware to correct it.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>
As the at91cap9adk board is removed by commit: b5508344
(ARM: remove broken "at91cap9adk" board), so the at91cap9
code is not used anymore, and also the document for
at91cap9 can not be found on www.atmel.com, so remove the
at91cap9 related code.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>
The Quark SoC contains a legacy SPI controller in the legacy bridge
which is ICH7 compatible. Like Tunnel Creek and BayTrail, the BIOS
control register offset in the ICH SPI driver is wrong for the Quark
SoC too, unprotect_spi_flash() is added to enable the flash write.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
The base address is found in a different way and the protection bit is also
in a different place. Otherwise it is very similar.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Since these board functions seem to be the same for all boards which use
FSP, move them into a common file. We can adjust this later if future FSPs
need more flexibility.
This creates a generic PCI MMC device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
This patch adds the DDR3 setup and training code taken from the Marvell
U-Boot repository. This code used to be included as a binary (bin_hdr)
into the AXP boot image. Not linked with the main U-Boot. With this code
addition and the following serdes/PHY setup code, the Armada-XP support
in mainline U-Boot is finally self-contained. So the complete image
for booting can be built from mainline U-Boot. Without any additional
external inclusion. Hopefully other MVEBU SoC's will follow here.
Support for some SoC's has been removed in this version. This is:
MV_MSYS:
The code referred to by the MV_MSYS define is currently unused. And its
not really planned to support this in mainline. So lets remove it to
make the code clearer and increase the readability.
MV88F68XX (A38x):
The code referred to by the MV88F68XX define (A38x) is currently unused.
And its partial and not sufficient for this device in this stage.
So lets remove it to make the code clearer and increase the readability.
MV88F66XX (ALP):
The code referred to by the MV88F66XX define is currently unused. And its
not really planned to support this in mainline. So lets remove it to
make the code clearer and increase the readability.
MV88F78X60_Z1:
The code referred to by the MV88F78X60_Z1 define is currently unused. As the
Z1 revision of the AXP is not supported in mainline anymore.
So lets remove it to make the code clearer and increase the readability.
Remove support for Z1 & A0 AXP revisions (steppings). The current stepping
is B0 and this is the only one that is actively supported in this code
version.
Tested on AXP using a SPD DIMM setup on the Marvell DB-MV784MP-GP board and
on a custom fixed DDR configuration board (maxbcm).
Note:
This code has undergone many hours of coding-style cleanup and refactoring.
It still is not checkpatch clean though, I'm afraid. As the factoring of the
code has so many levels of indentation that many lines are longer than 80
chars. This might be some task to tackly later on.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
Since we must run a PCI BIOS ROM, and this can take a calamitous amount of
time, measure it using bootstage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If the BIOS emulator is not available, allow use of native execution if
available, and vice versa. This can be controlled by the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver which locates the available XHCI controllers on the PCI bus
and makes them available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There is an existing function prototype in the header file but it is not
implemented. Implement something similar.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This results in a much more readable callgraph, because now they
can't be confused with the function having exactly the same name
in the generic mmc code.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On both my A13-OLinuxIno and my A13-OLinuxIno-Micro, the vga output gives an
unstable image when active low v or hsync is used.
The problem seems to be specific to the OLinuxIno A13 (normal & micro)
boards. I've just looked up the schematics and they use an opendrain driver
for the vga sync lines, and with sync pulses it is the logical high->low
edge of the pulse which counts for the timing, which with an active low
sync is being driven by the pull-up, and that simply seems to not drive
it hard enough to get a stable image.
So force v and hsync active high on these boards. independent of what the
modeline says. This fixes the unstable image.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
It turns out that the device_mode_data is rsb specific, rather then slave
specific, so integrate the rsb_set_device_mode() call into rsb_init().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
If for some reason DMA module fails to reset user oserves only this:
--->---
# dhcp
Trying dwmac.e0018000
FAIL
--->---
This message makes not much sense.
With proposed change error message will be more helpful:
--->---
# dhcp
Trying dwmac.e0018000
DMA reset timeout
FAIL
--->---
For example user may do power toggle to recover board functionality.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Chin Liang See <clsee@altera.com>
Cc: Dinh Nguyen <dinguyen@altera.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Pavel Machek <pavel@denx.de>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@ti.com>
Acked-by: Pavel Machek <pavel@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
This patch adds a phy driver for the Micrel KSZ8895 switch. As the SoC MAC
is directly connected to the switch MAC the link to the switch is always up.
But the KSZ8895 switch can be hardwired in three configuration modes :
- not configurable with eventually an eeprom-stored configuration
- configurable by the mdio/mdc connection (SMI protocol)
- configurable by a SPI connection.
In not configurable mode, the switch starts automatically, but in the
other modes, it must be started programmatically, by writing 1 in
configuration register 1.
We only support the not configurable and mdio/mdc (aka SMI) modes here.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
If the PHY is not recognized don't access phydev (NULL)
and return 0 to signal failure.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Fix this:
drivers/pci/pci_rom.c:95:15: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
rom_header = (struct pci_rom_header *)rom_address;
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
These functions are useful in case the board calls them. Also fix a missing
parameter caused by applying the wrong patch (actually I failed to send v2
and applied v1 by mistake).
Signed-off-by: Simon Glass <sjg@chromium.org>
Since U-Boot can support different offset lengths (0-4 bytes), add a device
tree property to specify this. This avoids hard-coding it in the driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
This commit adjusts the s3c24x0 driver to new i2c api
based on driver-model. The driver supports standard
and high-speed i2c as previous.
Tested on Trats2, Odroid U3, Arndale, Odroid XU3
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Tested-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
This patch fixes build error for CONFIG_DM_I2C_COMPAT.
In i2c_get_chip_for_busnum() call, one of argument was missed,
which was offset_len. Now it is set to 'alen' as previous.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Add a new rsa uclass for performing modular exponentiation and implement
the software driver basing on this uclass.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
I2C is now deprecated on ARM platforms and there are no devices that use it
with the v3 protocol. We can't require v3 support if we want to support I2C.
Adjust the error handling to suit.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't want to bind devices which should never be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
At present we go through various contortions to store the I2C's chip
address in its private data. This only exists when the chip is active so
must be set up when it is probed. Until the device is probed we don't
actually record what address it will appear on.
However, now that we can support per-child platform data, we can use that
instead. This allows us to set up the address when the child is bound,
and avoid the messy contortions.
Unfortunately this is a fairly large change and it seems to be difficult to
break it down further.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
At present we go through various contortions to store the SPI slave's chip
select in its private data. This only exists when the slave is active so
must be set up when it is probed. Until the device is probed we don't
actually know what chip select it will appear on.
However, now that we can support per-child platform data, we can use that
instead. This allows us to set up the chip select when the child is bound,
and avoid the messy contortions.
Unfortunately this is a fairly large change and it seems to be difficult to
break it down further.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we use struct spi_slave as our device pointer in a lot of places
to avoid changing the old SPI API. At some point this will go away.
But for now, it is better if the SPI uclass sets up this pointer, rather
than relying on passing it into the device when it is probed. We can use the
new uclass child_pre_probe() method to do this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some buses need to set up their devices before they can be used. This setup
may well be common to all buses in a particular uclass. Support a common
pre-probe method for the uclass, called before any bus devices are probed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
For buses, after a child is bound, allow the uclass to perform some
processing. This can be used to figure out the address of the child (e.g.
the chip select for SPI slaves) so that it is ready to be probed.
This avoids bus drivers having to repeat the same process, which really
should be done by the uclass, since it is common.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This is common to all SPI drivers and specifies a structure used by the
uclass. It makes more sense to define it in the uclass.
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
In many cases the per-child private data for a device's children is defined
by the uclass rather than the individual driver. For example, a SPI bus
needs to store information about each of its children, but all SPI drivers
store the same information. It makes sense to allow the uclass to define
this data.
If the driver provides a size value for its per-child private data, then use
it. Failng that, fall back to that provided by the uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
At present we try to use the 'reg' property and device tree aliases to give
devices a sequence number. The 'reg' property is often actually a memory
address, so the sequence numbers thus-obtained are not useful. It would be
better if the devices were just sequentially numbered in that case. In fact
neither I2C nor SPI use this feature, so drop it.
Some devices need us to look up an alias to number them within the uclass.
Add a flag to control this, so it is not done unless it is needed.
Adjust the tests to test this new behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This is useful to check which uclass a device is in.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Allow parent drivers to be called when a new child is bound to them. This
allows a bus to set up information it needs for that child.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
In many cases the child platform data for a device's children is defined by
the uclass rather than the individual devices. For example, a SPI bus needs
to know the chip select and speed for each of its children. It makes sense
to allow this information to be defined the SPI uclass rather than each
individual driver.
If the device provides a size value for its child platdata, then use it.
Failng that, fall back to that provided by the uclass.
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
For buses it is common for parents to need to know the address of the child
on the bus, the bus speed to use for that child, and other information. This
can be provided in platform data attached to each child.
Add driver model support for this, including auto-allocation which can be
requested using a new property to specify the size of the data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
When using allocated platform data, allocate it when we bind the device.
This makes it possible to fill in this information before the device is
probed.
This fits with the platform data model (when not using device tree),
since platform data exists at bind-time.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Make the error handling more standard to make it easier to build on top of
it. Also correct a bug in the error path where there is no parent.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
The root device corresponds to the root device tree node, so set this up.
Also add a few notes to the documentation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than assuming that the chip offset length is 1, allow it to be
provided. This allows chips that don't use the default offset length to
be used (at present they are only supported by the command line 'i2c'
command which sets the offset length explicitly).
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
For boards which use multiple I2C devices, or for SOCs which support
multiple boards, we might want to convert these to driver model at different
times. At present this is difficult because we need to either use
CONFIG_DM_I2C for a board or not.
Add a compatibility layer which implements the old API, thus allowing a
board to move to driver model for I2C without requiring that everything it
uses is moved in the same commit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a dm_ prefix to driver model I2C functions so that we can keep the old
ones around.
This is a little unfortunate, but on reflection it is too difficult to
change the API. We can undo this rename when most boards and drivers are
converted to use driver model for I2C.
Signed-off-by: Simon Glass <sjg@chromium.org>
This deals with the polarity bit. It also changes the GPIO devices so that
the correct device tree node is linked to each one. This allows us to use
the new uclass phandle functionality to implement a proper GPIO binding.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new 'demo light' command which uses GPIOs to control imaginary lights.
Each light is assigned a bit number in the overall value. This provides an
example driver for using the new GPIO API.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present U-Boot sort-of supports the standard way of reading GPIOs from
device tree nodes, but the support is incomplete, a bit clunky and only
works for GPIO bindings where #gpio-cells is 2.
Add new functions to request GPIOs, taking full account of the device
tree binding. These permit requesting a GPIO with a simple call like:
gpio_request_by_name(dev, "cd-gpios", 0, &desc, GPIOD_IS_IN);
This will request the GPIO, looking at the device's node which might be
this, for example:
cd-gpios = <&gpio TEGRA_GPIO(B, 3) GPIO_ACTIVE_LOW>;
The GPIO will be set to input mode in this case and polarity will be
honoured by the GPIO calls.
It is also possible to request and free a list of GPIOs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Only the GPIO driver knows about the full GPIO device tree binding used by
a device. Add a method to allow the driver to provide this information to the
uclass, including the GPIO offset within the device and flags such as the
polarity.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far driver model's GPIO uclass just implements the existing GPIO API.
This has some limitations:
- it requires manual device tree munging to support GPIOs in device tree
(fdtdec_get_gpio() and friends)
- it does not understand polarity
- it is somewhat slower since we must scan for the GPIO device each time
- Global GPIO numbering can change if other GPIO drivers are probed
- it requires extra steps to set the GPIO direction and value
The new functions have a dm_ prefix where necessary to avoid name conflicts
but we can remove that when it is no-longer needed. The new struct gpio_desc
holds all required information about the GPIO. For now this is intended to
be stored by the client requesting the GPIO, but in future it might be
brought into the uclass in some way.
With these changes the old GPIO API still works, and uses the driver model
API underneath.
Signed-off-by: Simon Glass <sjg@chromium.org>
This commit adds on-chip I2C driver used on newer SoCs of Panasonic
UniPhier platform.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
This commit adds on-chip I2C driver used on some old Panasonic
UniPhier SoCs.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
Each board with defines it's own set of values. If we do not define
CONFIG_MVGBE_PORTS we will hit following error:
mvgbe.c: In function 'mvgbe_initialize':
mvgbe.c:700:34: error: 'CONFIG_MVGBE_PORTS' undeclared (first use in this function)
u8 used_ports[MAX_MVGBE_DEVS] = CONFIG_MVGBE_PORTS;
This patch fixes above described problem.
Signed-off-by: Luka Perkov <luka@openwrt.org>
Acked-by: Prafulla Wadaskar <prafulla@marvell.com>
As a temporary measure before the ICH driver moves over to driver model,
add device tree support to the driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
On x86 we use CMOS RAM to read and write some settings. Add basic support
for this, including access to registers 128-255.
Signed-off-by: Simon Glass <sjg@chromium.org>
Era property is added in the crypto node in device tree.
Move the code to do so from arch/powerpc/mpc8xxx/fdt.c to
drivers/sec/sec.c so that it can be used across arm and
powerpc platforms having crypto node.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
[York Sun: Fix commit message indentation]
Reviewed-by: York Sun <yorksun@freescale.com>
Internal memory controller counters can reach a bad state after
training in DDR4 mode if accumulated ECC or DBI mode is eanbled.
Signed-off-by: York Sun <yorksun@freescale.com>
commit a62e84d7b1 incorrectly changed the tegra pci code to the
new fdtdec pci helpers. To get the device index of the root port, the
"reg" property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Some machines are very slow to scroll their displays. To cope with this,
support the CONFIG_CONSOLE_SCROLL_LINES option. Setting this to 5 allows
the display to operate at an acceptable speed by scrolling 5 lines at
a time.
This same option is available for LCDs so when these systems are unified
this code can be unified also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Each time U-Boot boots on Intel Crown Bay board, the displayed hard
drive information is wrong. It could be either wrong capacity or just
a 'Capacity: not available' message. After enabling the debug switch,
we can see the scsi inquiry command did not execute successfully.
However, doing a 'scsi scan' in the U-Boot shell does not expose
this issue.
SCSI: Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
ahci_device_data_io: 0 byte transferred. <--- scsi inquiry fails
ahci_device_data_io: 512 byte transferred.
ahci_device_data_io: 512 byte transferred.
ahci_device_data_io: 512 byte transferred.
Device 0: (0:0) Vendor: ATA Prod.: Rev: ?8
Type: Hard Disk
Capacity: 912968.3 MB = 891.5 GB (1869759264 x 512)
Found 1 device(s).
So uninitialized contents on the stack were passed to dev_print() to
display those wrong information.
The symptom were observed on two hard drives (one is Seagate, the
other one is Western Digital). The fix is to make sure the AHCI
interface is not busy by checking the error and status information
from task file register after enabling the port in ahci_port_start()
before proceeding other operations like scsi_scan().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we have a full VESA driver we may as well use that. We need to
support the VESA layer being set up by early start-up code or by
running a VGA ROM.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a driver intended to cope with any VESA-compatible x86 graphics
adapter. It will not support ROMs which use OpenFirmware (Forth) since
there is no support for that in U-Boot. This means that MAC OS cards
will not work.
Signed-off-by: Simon Glass <sjg@chromium.org>
These are quite common and we may as well press on and not be so picky.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We shouldn't assume that the VGA ROM can always be loaded at c0000. This
is only true on x86 machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code is too x86-dependent at present. Correct it so that it can run on
big-endian machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These boards are still non-generic boards.
It is a good thing that we can drop board-specific hack code
from drivers/mtd/nand/nand_base.c
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Stefan Roese <sr@denx.de>
Cc: Andrea "llandre" Marson <andrea.marson@dave-tech.it>
It turns out that there are some panels where the pwm input is not active low,
so make it configurable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
lcd controller which needs to be initialized over SPI, once that is
done they work like a regular LVDS panel.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
lcd controller which needs to be initialized over SPI, once that is
done they work like a regular LVDS panel.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Testing has shown that on sun4i the display backend engine does not have
deep enough fifo-s causing flickering / tearing in full-hd mode due to
fifo underruns. On sun4i use the display frontend engine to do the dma from
memory, as the frontend does have deep enough fifo-s.
As added advantage of this is that it results in much better memory bandwidth
as it reduces the amount of dram bank switches, for more details see:
http://ssvb.github.io/2014/11/11/revisiting-fullhd-x11-desktop-performance-of-the-allwinner-a10.html
Note that this changes the pipeline searched for in the simplefb node, we can
get away with doing this now, since no kernel has yet shipped with simplefb
dtb nodes, and I will make sure to get a simplefb node with the new pipeline
into 3.19 before it ships.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Instead of using the internal 'tx_clk' clock source, it is also
possible to use the pixel clock signal from the parallel LCD
interface ('pclk') as the reference clock for PLL.
The 'tx_clk' clock speed may be different on different boards/devices
(the allowed range is 8MHz - 30MHz). Which is not very convenient,
especially considering the need to know the exact 'tx_clk' clock
speed. This clock speed may be difficult to identify without having
device schematics and/or accurate documentation/sources every time.
Using 'pclk' is free from all these problems.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Convert GPIO names from Kconfig strings into pin numbers for
the 'ssd2828_config' struct. Add SSD2828 initialization between
enabling the parallel LCD interface and turning on the backlight.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
SSD2828 can take pixel data coming from a parallel LCD interface
and translate it on the fly into MIPI DSI interface for driving
a MIPI compatible TFT display. SSD2828 is configured over SPI
interface, which may or may not have MISO pin wired up on some
hardware. So a write-only SPI mode also has to be supported.
The SSD2828 support code is implemented as a utility function
and needs to be called from real display drivers, which are
responsible for driving parallel LCD hardware in front of the
video pipeline. The usage instructions are provided as comments
in the header file.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
And also add Kconfig option for selecting ELDO3 voltage. The reason
for having this option is that the Android kernel sets ELDO3 to
1.2V when powering up LCD in the case if 'lcd_if' configuration
variable is set to 6 (LCD_IF_EXT_DSI) in the FEX file. Most likely
to supply power for a SSD2828 chip.
However on the MSI Primo81 tablet, which is using this particular
'lcd_if = 6' setup for LCD, setting the ELDO3 voltage appears to
be unnecessary and it works regardless. Having no schematics of
this tablet, I can only guess that 1.2V is supplied to SSD2828
in some other way.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We do not use the axp209 interrupt, and at least in my mini-x (which does not
have a power button) the pwr-button pin and the irq pin are soldered together,
so if the axp209 keeps it irq asserted too long it will see a 10s pwr-button
press and hard power off the board, disabling the irqs fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The clocks on the A80 are hooked up slightly different, add support for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Wait 1 second for the sdcard to respond, rather then waiting for
0xfffff milliseconds.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
While running some tests with an Olinuxino-A13-Micro + a 7" Olimex LCD module
I noticed that the screen flickered. This is caused by the lcd display clk
phase reg value being set to 0, where it should be 1 in this setup.
This commit adds a Kconfig option for the lcd display clk phase, so that we
can set it per board. This defaults to 1, because looking at all the fex
files in sunxi-boards, that is by far the most used value.
This commit updated the Ippo and MSI Primo73 tablet defconfigs to override the
default of 1 with 0, as that is the correct value for those tablets, this
keeps the register settings the same as before this commit.
The Olinuxino-A13 defconfigs are not updated, changing the register setting
for these boards from 0 to 1, this is intentional.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
This patch fix the compilation warning
w+../drivers/net/xilinx_ll_temac.c: In function 'll_temac_init':
w+../drivers/net/xilinx_ll_temac.c:235:3: warning: format '%X' expects
argument of type 'unsigned int', but argument 4 has type 'phys_addr_t'
[-Wformat]
introduced by
"net: Declare physical address as phys_addr_t unsigned type"
(sha1: 16ae782722).
Reported-by: Tom Rini <trini@ti.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Show fpga_op->info even if desc->iface_fns is not defined.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Wider bus widths (larger than default 1 bit) appeared in MMC standard
version 4.0. So, for MMC cards of any earlier version trying to change
the bus width (including ext_csd comparison) does not make any sense.
It may work incorrectly and at least cause unnecessary timeouts.
So, just skip the entire bus width related activity for earlier versions.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
If all the commands switching an MMC card to 4- or 8-bit bus width fail,
and the bus width for the controller and the driver is still set
to default 1 bit, there is no need to send one more command to switch
the card to 1-bit bus width. Also, if the card or host controller do not
support wider bus widths, there is no need to send a switch command at all.
However, if one of switch commands succeeds, but the subsequent ext_csd
fields comparison fails, the card should be switched to some other bus width
(next in the list for the loop), or to default 1-bit bus width as a last
resort. That's why it would be incorrect to just remove the 1-bit bus width
case from the list, it should still be processed in some cases.
panto: Minor cosmetic edit removing superfluous parentheses.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
This extends the mmcinfo hardware partition info output to show
partitions with write reliability enabled with the "WRREL" string.
If the partition does not have write reliability enabled the "WRREL"
string is omitted; this is analogous to the ehhanced attribute.
Example output:
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC16
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.41
High Capacity: Yes
Capacity: 13.8 GiB
Bus Width: 4-bit
Erase Group Size: 8 MiB
HC WP Group Size: 16 MiB
User Capacity: 13.8 GiB ENH WRREL
User Enhanced Start: 0 Bytes
User Enhanced Size: 512 MiB
Boot Capacity: 16 MiB ENH
RPMB Capacity: 128 KiB ENH
GP1 Capacity: 64 MiB ENH WRREL
GP2 Capacity: 64 MiB ENH WRREL
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The eMMC partition write reliability settings are to be set while
partitioning a device, as per the eMMC spec, so changes to these
attributes needs to be done in the hardware partitioning API.
This commit adds such support.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This adds an API to do hardware partitioning on eMMC devices. The
new mmc_hwpart_config() function does the partitioning in one go.
As the different attributes and partitioning options on eMMC may
be interdependent validation has to be done based on the complete
partitioning configuration. The function accepts three modes:
- MMC_HWPART_CONF_CHECK: just validates that the configuration
is valid.
- MMC_HWPART_CONF_SET: validates and sets all the fields in
EXT_CSD but without setting the "partitioning completed" bit,
and thus is reversible.
- MMC_HWPART_CONF_COMPLETE: does everything and is thus not
reversible.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The mmc_startup() function uses the ext_csd data even if reading it
from the mmc device failed. This bug was introduced in commit
bc897b1d4d. We now bail out if
reading it fails, this should not be a problem as ext_csd was
introduced in MMC 4.0 and this code is conditional on MMC >= 4.0.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The eMMC spec says that partitioning is only effective after the
PARTITION_SETTING_COMPLETED is set in EXT_CSD (and a power cycle was done,
but that we cannot know). Thus the partition sizes and attributes should
be ignored when that bit is not set, otherwise the various capacities
are not coherent (e.g., the user data capacity will be that of the
unpartitioned device while partition sizes would be non-zero).
Prescence of non-zero partitioning data is nevertheless still used to
activate the high-capacity size definitions (EXT_CSD_ERASE_GROUP_DEF)
as it is necessary to set that to write any of the partitioning fields
in EXT_CSD, so having partitioning data means someone previously
activated that and we should keep it activated.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
Read the eMMC high capacity write protect group size at mmc device
initialization. This is useful to correctly partition an eMMC device,
as partitions need to be aligned to this size.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The erase_grp_size in struct mmc is to be a size in 512-byte sectors
but the code used to compute it for eMMC when EXT_CSD_ERASE_GROUP_DEF is
enabled computed it as bytes, leading to erase sizes and alignment
much larger than what is actually required by the mmc device.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This modification reads the size of the eMMC enhanced user data area
upon initialization of an mmc device, it will be used later by
mmcinfo.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The eMMC spec mandates that the high-capacity group size definitions
should be enabled when the device is partitioned (by setting
ERASE_GROUP_DEF in EXT_CSD). The current test to determine when this is
required misses a few cases. In particular a device may have been
partitioned without setting the enhanced attribute on any partition
or partitioning may be completed without creating any extra partitions.
This change moves the code to set ERASE_GROUP_DEF to after reading
all partition information. It is also enabled when
PARTITIONING_SETTING_COMPLETED is set as it is necessary to enable
ERASE_GROUP_DEF before setting that bit, so it means that the user
previously switched to the high capacity definitions.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This extends the mmcinfo command's output to show which eMMC partitions
have the enhanced attribute set. Note that the eMMC spec says that
if the enhanced attribute is supported then the boot and RPMB
partitions are of the enhanced type.
The output of mmcinfo becomes:
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC16
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.41
High Capacity: Yes
Capacity: 13.8 GiB
Bus Width: 4-bit
User Capacity: 13.8 GiB ENH
Boot Capacity: 16 MiB ENH
RPMB Capacity: 128 KiB ENH
GP1 Capacity: 64 MiB ENH
GP2 Capacity: 64 MiB ENH
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This patch enables U-Boot to modify the MAC address of the AX88179.
Tested on RECS5250 (similar to Arndale5250)
Signed-off-by: Rene Griessl <rgriessl@cit-ec.uni-bielefeld.de>
Make construct_urb take an urb and hep parameter, rather then having it always
operate on the file global urb and hep structs. This is a preperation patch
for adding interrupt queue support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If a transfer / urb times-out, properly remove it from the schedule, rather
then letting it sit on the ep head. This stops the musb code from getting
confused and refusing to queue further transfers after a timeout.
Tested by unplugging a usb-keyboard, replugging it and doing a usb-reset,
before this commit the keyboard would not work after the usb-reset.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This commit fixes a number of issues with the reset sequence of musb-new
in host mode:
1) Our usb device probe relies on a second device reset being done after the
first descriptors read. Factor the musb reset code into a usb_reset_root_port
function (and add this as an empty define for other controllers), and call
this when a device has no parent.
2) Just like with normal usb controllers there needs to be a delay after
reset, for normal usb controllers, this is handled in hub_port_reset, add a
delay to usb_reset_root_port.
3) Sync the musb reset sequence with the upstream kernel, clear all bits of
power except bits 4-7, and increase the time reset is asserted to 50 ms.
With these fixes an usb keyboard I have now always enumerates properly, where
as earlier it would only enumerare properly once every 5 tries.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For bulk and ctrl transfers common/usb.c sets udev->status = USB_ST_NOT_PROC,
but it does not do so for interrupt transfers.
musb_uboot.c: submit_urb() however was waiting for USB_ST_NOT_PROC to become 0,
and thus without anyone setting USB_ST_NOT_PROC would exit immediately for
interrupt urbs, returning the urb status of EINPROGRESS as error.
This commit fixes this, thereby also making usb_kbd.c work together with
musb_new and CONFIG_SYS_USB_EVENT_POLL.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
CPU cycle based timeouts are no good, because how long they use depends on
CPU speed. Instead use time based timeouts, and wait one second for a
device connection to show up (per the USB spec), and wait USB_TIMEOUT_MS
for various urbs to complete.
This fixes "usb start" taking for ever when no device is plugged into the
otg port.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is based on Jussi Kivilinna's work for the linux-sunxi-3.4 kernel to use
the kernels musb driver instead of Allwinners own custom driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently create_int_queue is only implemented by the ehci code, and that
does not honor interrupt intervals, but other drivers which might also want
to implement create_int_queue may honor intervals, so add an interval param.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fix use-before-initialized bug in pxa25x_udc driver.
Function usb_gadget_register_driver calls udc_disable,
and udc_disable calls pullup_off that uses dev->mach->udc_command.
But dev->mach is initialized in usb_gadget_register_driver after
calling udc_disable. This patch fixes the order of initialization.
Signed-off-by: Alex Sadovsky <Nable.MainInbox@googlemail.com>
Without this function the USB compliance test (USB 2.0 Command Verifier) will
fail in the "Interface Descriptor Test" with this error message:
FAIL
(1.2.51) A successful GetInterface request must return the alternate setting
set by a prior call to SetInterface.
Lets add this function to read back the value so that the DFU device fully
passes the USB compliance test.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Roger Meier <r.meier@siemens.com>
Cc: Samuel Egli <samuel.egli@siemens.com>
Cc: Enrico Leto <enrico.leto@siemens.com>
Acked-by: Heiko Schocher <hs@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
On the DXR2 board (AM335x using MUSB) the USB compliance test suite
(USB 2.0 Command Verifier) will cause the board to crash and reset
upon the "BOS Descriptor Test - Addressed state". Here the output
from the DRX2 while running this test:
GADGET DRIVER: usb_dnl_dfu
musb-hdrc: peripheral reset irq lost!
composite_setup (776)
data abort
pc : [<87f693ac>] lr : [<87f6911c>]
sp : 86f33a58 ip : 00000000 fp : 86f3bbac
r10: 00000f00 r9 : 86f33ef4 r8 : 86f37da8
r7 : 00000005 r6 : 86f33a90 r5 : 00000000 r4 : 86f37e30
r3 : 00000000 r2 : 00000000 r1 : 87f9c888 r0 : 00000016
Flags: Nzcv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
resetting ...
By adding the case statement for USB_DT_BOS and therefore not running
into the default case (jump to unkown label) this crash is fixed.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Roger Meier <r.meier@siemens.com>
Cc: Samuel Egli <samuel.egli@siemens.com>
Cc: Enrico Leto <enrico.leto@siemens.com>
Acked-by: Heiko Schocher <hs@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
This patch adds a driver for VSC9953 L2 Switch. This Vitesse IP
is integrated in Freescale T1040 and T1020 SoCs.
The L2 switch has 10 Ethernet ports: 2 internal fixed-links
(ports 8 and 9) at 2.5 Gbps and and 8 external ports at 1 Gbps.
The external ports may be connected to PHYs over QSGMII and SGMII.
Commands have also been added to enable/disable a port and to
check a port's link speed, duplexity and status. The commands are:
ethsw port <port_nr> enable|disable - enable/disable an l2 switch port
ethsw port <port_nr> show - show an l2 switch port's configuration
port_nr=0..9; use "all" for all ports
For more detailse please see doc/README.t1040-l2switch
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@freescale.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: York Sun <yorksun@freescale.com>
If SerDes is configured to connect L2 Switch ports from T1040
over SGMII or QSGMII, the two FMAN fixed ports (FM1@DTSEC1 and FM2@DTSEC2)
that are connected to two L2 swtch ports must be enabled. These
ports don't have PHYs and must be treated accordingly.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
U-boot assumes that all FMAN ports have a PHY. Some SoCs (like T1040)
have fixed links. This means that the ports are connected MAC to MAc
and there is no Ethernet PHY attatched. This patch initializes a
FMAN MAC even if it doesn't have a PHY attached.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
This patch supports AQ1202, AQ2104, AQR105 PHY.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: York Sun <yorksun@freescale.com>
All the 74xx_7xx boards are still non-generic boards:
P3G4, ZUMA, ppmc7xx, ELPPC, mpc7448hpc2
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: York Sun <yorksun@freescale.com>
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Nye Liu <nyet@zumanetworks.com>
Cc: Roy Zang <tie-fei.zang@freescale.com>
Since commit 843125daeb (ppc4xx: remove HH405 board), CONFIG_HH405
is not defined.
Since commit d526330479 (ppc4xx: remove PMC405), CONFIG_PMC405
is not defined.
Acked-by: Stefan Roese <sr@denx.de>
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
Most of the usb-controller init code found in ehci-sunxi.c also is necessary
to init the otg usb controller, so move it to a common place.
While at it also update various #ifdefs / defines for sun8i support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The axp221 / axp223's N_VBUSEN pin can be configured as an output rather
then an input, add axp_drivebus_enable() and _disable() functions to set
the pin in output mode and control it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The voltage setting code knows it needs to call axp221_init before calling
the various voltage setting functions.
But users of axp utility functions like axp221_get_sid() do not know this,
so the utility functions always call axp221_init() to ensure that the
p2wi / rsb setup magic has been done.
Since doing this repeatedly is quite expensive, add a check to axp221_init
so that it only does the initialization once.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
ALDO2 is used to power LPDDR2 SDRAM on both the reference design and the
Hummingbird A31, when this type of RAM is present.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The external DAC for VGA output might have either a power or reset
control pin that needs to be pulled up, as is the case on the
Hummingbird A31.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In some extreme cases it may be necessary to wait 1.5 seconds or more for a hpd
signal to show up (and be able to read edid info), but we do not want to
penalize all headless boots with an extra second boot delay, so add a hpd_delay
parameter which can be set through the video-mode env. variable.
While at it raise the default from 300ms to 500ms as 300 may very well be too
low in many cases.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add support for VGA directly from the sunxi SoC / display engine.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
If a board has no LCD, but does have VGA fallback to VGA when no HDMI cable
is connected (unless hpd=0).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add support for using PORTD hsync/vsync pins with tcon1, this is a preparation
patch for adding native VGA support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Use sunxi_lcdc_get_clk_delay to calculate tcon1 delay instead of hardcoding
it to 30. We will still end up using 30 for most modes, but for e.g. 800x600
this makes a (small) difference.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Having both a sunxi_display.enabled variable and
sunxi_display.monitor == sunxi_monitor_none duplicates state, use
sunxi_display.monitor = sunxi_monitor_none when ever we do not have a display.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add support for external DACs connected to the parallel LCD interface driving
a VGA connector, such as found on the Olimex A13 boards.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The A23 (sun8i) only has lcd output support, so allow building the video code
without HDMI support for use with the A23.
Also the A23 has the same reset bits (and necessity to enable the DRC block)
as the sun6i, so enable those bits for sun8i too.
Note building without HDMI support is useful for the A13 (sun5i variant) too,
as that one does not have HDMI either.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add lcd output support, see the new Kconfig entries and doc/README.video for
how to enable / configure this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Move sunxi_drc_init to directly above sunxi_engines_init, to avoid
unnecessary #ifdef-ery in later patches.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Modify sunxi_lcdc_pll_set to work with both tcon0 and tcon1, this is a
preparation patch for adding lcd support.
While at it also swap the divider search order, searching from low to
high, as the comment above the code says we should do. In cases where there
are multiple solutions this will result in picking a lower pll clock and
divider, which is more stable and saves power.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Refactor sunxi_mode_set into a bunch of helpers, and make it do a switch
case on sunxi_display.monitor to decide what to do.
Also rename sunxi_lcdc_mode_set to sunxi_lcdc_tcon1_mode_set, as it sets the
timings for tcon1, and for lcd support we need a similar function operating
on tcon0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add a sunxi_monitor enum and parse the monitor option string into this enum
once, rather then doing strcmp-s on it in various places. This also adds
checking for it being a valid value.
This also adds new "none" and "lcd" values in preparation for lcd support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Some boards use GPIO-s on the pmic, one example of this is the A13-OLinuXino
board, which uses gpio0 of the axp209 for the lcd-power signal.
This commit adds support for gpio pins on the AXP209 pmic, the sunxi_gpio.c
changes are universal, adding gpio support for the other AXP pmics (when
necessary) should be a matter of adding the necessary axp_gpio_foo functions
to their resp. drivers, and add "#define AXP_GPIO" to their header file.
Note this commit only adds support for the non device-model version of the
gpio code, patches for adding support to the device-model version are very
welcome.
The string representation for these gpio-s is AXP0-#, the 0 in the AXP0 prefix
is there in case we need to support gpio-s on more then 1 pmic in the future.
At least A80 boards have 2 pmics, and we may end up needing to support gpio-s
on both.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Add a write to the "unknown" (*) register to enable auto input sync, when
initially adding sunxi hdmi output support this magic write from the android
kernel code was missed, causing lcdc -> hdmi encoder sync problems.
With this write added, we can drop the modesetting retries and the extra
delays added to work around these sync problems.
With the retries dropped there also is no need to 0 all the enable flags at
the beginning of the modeset, as they are initialized to 0 already by
engines_init.
*) "unknown" is the actual name of this register in the android kernel sources
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
When using a hdmi powered hdmi to vga dongle, and cold booting a sunxi
device, the hpd detect code would not see the dongle (until a warm reboot),
because the dongle needs some time to boot.
Testing has shown that this dongle needs 213ms to respond on a cold boot,
so wait up to 300ms for a hpd signal to show up before giving up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
When using edid use CEA681 edid extension blocks to select between dvi and
hdmi output formats, so that u-boot will automatically do the right thing.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add a sunxi_hdmi_edid_get_block helper function, this is a preparation patch
for adding support for parsing EDID extension blocks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
So far we've been programming the hdmi-encoder to send out dvi data over the
hdmi connector. This works well for most devices, including hdmi devices, but
not all devices accept dvi data on a hdmi input.
Add support for sending proper hdmi data over the hdmi output found on most
sunxi boards. This can be turned on by adding monitor=hdmi as option to the
video-mode env. variable.
A follow up patch will determine whether to send dvi or hdmi automatically when
EDID is used.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add DDC & EDID support and use it to automatically select the native mode of
the attached monitor. This can be disabled by adding edid=0 as option
to the video-mode env. variable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
Allow the user to specify hpd=0 as option in the video-mode env. variable,
if hpd is set to 0 then the hdmi output will be brought up even if no cable
is connected.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add support for the standard video-mode environment variable using the
videomodes.c video_get_ctfb_res_modes() helper function.
This will allow users to specify the resolution e.g. :
setenv video-mode sunxi:video-mode=1280x1024-24@60
saveenv
Also make the reserved fb mem slightly larger to allow 1920x1200 to work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
Switch from fb_videomode to ctfb_res_modes and use the predefined videotimings
from videomodes.c, rather then defining our own.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add a video_edid_dtd_to_ctfb_res_modes helper function to convert an EDID
detailed timing to a struct ctfb_res_modes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add 2 helper functions to get strings, respectively integers from the options
value returned by video_get_video_mode() / video_get_ctfb_res_modes().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add a video_get_ctfb_res_modes() helper function, which uses
video_get_video_mode() to parse the 'video-mode' environment variable and then
looks up the matching mode in res_mode_init and returns the matching mode.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
The timings for the modes defined in videomodes.c differ (significantly)
from vesa standard timings for these modes.
This commit adds a version with the proper std timings for these modes,
since I do not want to cause regressions, boards which want to use the standard
timings need to define CONFIG_VIDEO_STD_TIMINGS to get the new correct timings.
Since there is no std timing for 960x720 this commit uses the timing used
by the nvidia video drivers for 960x720, which uses a standard pixelclock
of 74.25 MHz rather then the weird 76.335... clock used by the old modes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add pixelclock_khz and refresh fields to ctfb_res_modes:
1) pixelclocks are usually referred to in hz, not picoseconds, and e.g
pll-s are also typically programmed in hz, not ps. Converting between the
2 leads to rounding differences, add a pixelclock_khz field to directly
store the *exact* pixelclock for a mode, so that drivers do not need to
resort to rounding tricks to try and guess the exact pixelclock;
2) The video-mode environment variable, as parsed by video_get_video_mode
also contains the vertical refresh rate, add a refresh field, so that
the refresh-rate can be matched when parsing the video-mode environment
variable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Explicitly turn off unused voltages, rather then leaving them as is. Likewise
explictly enabled the dcdc convertors, rather then assuming they are already
enabled at boot.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The dcdc1 voltage is typically used as generic 3.3V IO voltage for things like
GPIO-s, sdcard interfaces, etc. On most boards this is undervolted to 3.0V to
safe battery, but not on all, make it configurable so that we can use the
same settings as the original firmware on all boards.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Some of the ldo-s of the axp221 are used in the same way on most boards, add
comments to the Kconfig help text to reflect this, and give them defaults
matching their typical usage.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
The axp223 appears to be the same as the axp221, except that it uses the
rsb to communicate rather then the p2wi. At least all the registers we use
are 100% the same.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
