On some archs masking the parameter is inefficient, so don't use u8.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reported-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Many functions returned -1 previously. Change them to return appropriate error
codes.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reported-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Move some things around and organize things so that the driver model
implementation will fit in more easily.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Many of the functions in net.h were preceded extern needlessly. Removing
them to limit the number of checkpatch.pl complaints.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Make it clear that the helper is checking the addr, not setting it.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The current implementation exposes the eth_device struct to code that
needs to access the MAC address.  Add a wrapper function for this to
abstract away the pointer for this operation.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

In the case where the arch defines a custom map_sysmem(), make sure that
including just mapmem.h is sufficient to have these functions as they
are when the arch does not override it.

Also split the non-arch specific functions out of common.h
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Simon Glass <sjg@chromium.org>

Add some basic tests to check that things work as expected with sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>

Move chromebook_link over to driver model for PCI.

This involves:
- adding a uclass for platform controller hub
- removing most of the existing PCI driver
- adjusting how CPU init works to use driver model instead
- rename the lpc compatible string (it will be removed later)

This does not really take advantage of driver model fully, but it does work.
Furture work will improve the code structure to remove many of the explicit
calls to init the board.
Signed-off-by: Simon Glass <sjg@chromium.org>

Move coreboot-x86 over to driver model for PCI.
Signed-off-by: Simon Glass <sjg@chromium.org>

Add a simple x86 PCI driver which uses standard functions provided by the
architecture.
Signed-off-by: Simon Glass <sjg@chromium.org>

Enable PCI options so that sandbox can be used for testing this bus with
driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>

This device sits on the sandbox PCI bus and provides a case-swapping
service for sandbox. It illustrates the use of both PCI I/O and PCI
memory accesses.
Signed-off-by: Simon Glass <sjg@chromium.org>

Since sandbox does not have real devices (unless it borrows those from the
host) it must use emulations. Provide a uclass which permits PCI operations
to be passed through to an emulation device.
Signed-off-by: Simon Glass <sjg@chromium.org>

Add a driver which can access emulations of devices and make them available
in sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>

Add the required header information, device tree nodes and I/O accessor
functions to support PCI on sandbox. All devices are emulated by drivers
which can be added as required for testing or development.
Signed-off-by: Simon Glass <sjg@chromium.org>

Add a uclass for PCI controllers and a generic one for PCI devices. Adjust
the 'pci' command and the existing PCI support to work with this new uclass.
Keep most of the compatibility code in a separate file so that it can be
removed one day.

TODO: Add more header file comments to the new parts of pci.h
Signed-off-by: Simon Glass <sjg@chromium.org>

Driver model will share many functions with the existing PCI implementation.
Move these into their own file to avoid duplication and confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>

Both of these values are useful for understanding what is going on, so show
them both.

The requested number comes from a device tree alias. The allocated one is
set up when the device is activated, and is unique throughout the uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>

Some uclasses want to set up a device before it is probed. Add a method
for this.

An example is with PCI, where a PCI uclass wants to set up its private
data for later use. This allows the device's uclass() method to make calls
whcih use that data (for example, read PCI memory regions from device
tree, set up bus numbers).
Signed-off-by: Simon Glass <sjg@chromium.org>

At present the device is not active when the probe() method is called. But
some probe() methods want to set up the device and this can involve
accessing it through normal methods. For example a PCI bus may wish to
set up its PCI parameters using calls to pci_hose_write_config_dword() and
similar.

At present this does not work because every such call within the probe()
method sees that the device is not active and attempts to probe it.

Already we mark the device as probed before calling the uclass post_probe()
method. This is a subtle change but I believe the new approach is better.
Since the scope of the change is only the probe() method and all its callees
it should still be within the control of the board author.
Signed-off-by: Simon Glass <sjg@chromium.org>

Add a convenience function to access the private data that a uclass stores
for each of its devices. Convert over most existing uses for consistency
and to provide an example for others.
Signed-off-by: Simon Glass <sjg@chromium.org>

This function returns -ENOENT when the property is missing (which the caller
might forgive) and also when the property is present but incorrectly
formatted (which many callers would like to report).

Update the error return value to allow these different situations to be
distinguished.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

This function does not unmap what it maps. Correct it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

At present we do more in this function than we should. Split out the
post-driver-model part into a separate function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Since driver model is set up after arch_cpu_init(), that function cannot
use drivers. Add a new arch_cpu_init_dm() function which is called
immediately after driver model is ready, and can reference devices.

This can be used to probe essential devices for the CPU.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

These functions currently use a generic name, but they are for x86 only.
This may introduce confusion and prevents U-Boot from using these names
more widely.

In fact it should be possible to remove these at some point and use
generic functions, but for now, rename them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

This function is missing a prototype but is more widey useful. Add it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

We should have a size value for these. Add one in each case. This will
be needed for PCI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Support running U-Boot as a coreboot payload. Tested peripherals include:

- Video (HDMI and DisplayPort)
- SATA disk
- Gigabit Ethernet
- SPI flash

USB3 does not work. This may be a problem with the USB3 PCI driver or
something in the USB3 stack and has not been investigated So far this is
disabled. The SD card slot also does not work.

For video, coreboot will need to run the OPROM to set this up.

With this board, bare support (running without coreboot) is not available
as yet.
Signed-off-by: Simon Glass <sjg@chromium.org>

Since Chromebooks mostly have similar configuration, put it in a common
file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Add Lynxpoint to the driver so that the Asus Chromebox can be supported.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>

Add some new device IDs used by this haswell-based chipset.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

At present a VGA console assumes a keyboard unless a CONFIG option is set.
This difference can be dealt with by a device tree option, allowing boards
that are otherwise the same to use the same configuration.
Signed-off-by: Simon Glass <sjg@chromium.org>

Some systems have more than 4GB of RAM. U-Boot can only place things below
4GB so any memory above that should not be used. Ignore any such memory so
that the memory size will not exceed the maximum.

This prevents gd->ram_size exceeding 4GB which causes problems for PCI
devices which use DMA.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>

Commit d3cfcb3e

 (ARM: DRA7: Enable clocks for USB OTGSS and USB PHY)
changed the member names of prcm_regs from cm_l3init_usb_otg_ss_clkctrl
to cm_l3init_usb_otg_ss1_clkctrl and from cm_coreaon_usb_phy_core_clkctrl
to cm_coreaon_usb_phy1_core_clkctrl in order to differentiate between
the two dwc3 controllers present in dra7xx/am43xx and enabled these
clocks in enable_basic_clocks() in hw_data.c. However these clocks
continued to be enabled in board files/driver files for dwc3 host
mode functionality causing compilation break with few configs.

Fixed it here by making all the clocks enabled in enable_basic_clocks()
and removing it from board files/driver files here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Sunxi platforms come with at least 3 TWI (I2C) controllers and some platforms
even have up to 5. This adds support for every controller on each supported
platform, which is especially useful when using expansion ports on single-board-
computers.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI
controller. However, other platforms using MVTWSI may come with more: this is
the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found
on the same chip.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>