Add support for driver model, so that CONFIG_DM_ETH can be defined and used
with this driver.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present struct eth_device is passed around all over the place. This does
not exist with driver model. Add explicit arguments instead, so that with
driver model we can pass the correct things.

Signed-off-by: Simon Glass <sjg@chromium.org>

Instead of returning -1 on error, we should use a proper error number. Fix
the code to conform to this.

Signed-off-by: Simon Glass <sjg@chromium.org>

The AX_ prefix comes from the Asix driver. Since this is not that, we should
avoid this confusing prefix.

Signed-off-by: Simon Glass <sjg@chromium.org>

Tidy up the include file order before adding more.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add driver model support to this driver so it can be used with the new USB
stack.

Signed-off-by: Simon Glass <sjg@chromium.org>

Put all global data in a structure and move (what will be) common code into
common functions. This will make the driver-model conversion much easier.

Signed-off-by: Simon Glass <sjg@chromium.org>

This is required on some platforms, so add it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Not all boards use garbage collection in their link step, so we should avoid
adding options that rely on this for prevention of code bloat. Add separate
Kconfig options for syscon and regmap uclasses.

Signed-off-by: Simon Glass <sjg@chromium.org>

fdt_addr_t is a physical address. It can be either 64-bit or 32-bit,
depending on the architecture. It should be phys_addr_t instead of
u64 or u32. Similarly, fdt_size_t is changed to phys_size_t.

Signed-off-by: York Sun <yorksun@freescale.com>
CC: Simon Glass <sjg@chromium.org>

fdt_addr_t is changed to phys_addr_t. The format in debug should be updated
to %pa to match the type.

Signed-off-by: York Sun <yorksun@freescale.com>
CC: Simon Glass <sjg@chromium.org>

Spring is the first ARM-based HP Chromebook 11. It is similar to snow
and it uses the same Samsung Exynos5250 chip. But has some unusual
features. Mainline support for it has lagged snow (both in kernel and
U-Boot). Now that the exynos5 code is common we can support spring just
by adding a device tree and a few lines of configuration.

Signed-off-by: Simon Glass <sjg@chromium.org>

We always use device tree on exynos, so remove the unused code.

Signed-off-by: Simon Glass <sjg@chromium.org>

This has moved to driver model so we can drop the fdtdec support.

Signed-off-by: Simon Glass <sjg@chromium.org>

We have a new one which uses driver model and device tree configuration.
Remove the old one.

Signed-off-by: Simon Glass <sjg@chromium.org>

This is not needed with driver mode. Remove it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Remove the old drivers (both the normal one and the cros_ec one) now that
we have new drivers that use driver model.

Signed-off-by: Simon Glass <sjg@chromium.org>

Now that most exynos5250 boards can use the generic exynos5 code, switch
over to it and remove the old code.

Signed-off-by: Simon Glass <sjg@chromium.org>

Now that exynos5420 boards can use the generic exynos5 code, switch over to
it and remove the old code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>

Many options are duplicated on the exynos5 boards. Move these to the common
files. Also some options are not used so can be removed.

Tidy this up to make the files easier to maintain.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>

Since device tree is used for all exynos5 boards, we can remove the #ifdef
and reduce confusion.

Signed-off-by: Simon Glass <sjg@chromium.org>

Enable PMICs, regulators and the like so that new drivers will be made
available.

Signed-off-by: Simon Glass <sjg@chromium.org>

Some boards use device tree for almost all board-specific configuration.
They therefore do not need their own separate board code, but can all use
the same version. Add a common version of the board code. It uses the
PMIC, regulator and video bridge uclasses. This will support smdk5250,
smdk5420, snow, spring, pit and pi.

Signed-off-by: Simon Glass <sjg@chromium.org>

While the AP can access the main PMIC on snow, it must coordinate with the
EC which also wants access. Drop the old definition, which can in principle
generate collision errors. We will use the new arbitration driver instead.

Signed-off-by: Simon Glass <sjg@chromium.org>

The driver supports driver model. Add a node for snow, which needs it.

Signed-off-by: Simon Glass <sjg@chromium.org>

The new driver supports driver model and configuration via device tree. Add
a node for pit, which needs this driver.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add a description of the snow memory layout to assist flashing tools which
want to be able to deal with any exynos image.

Signed-off-by: Simon Glass <sjg@chromium.org>

Since a gpio_desc is allowed to be invalid we should return an error
indicating that the operation cannot be completed. This can happen if the
GPIO is optional - e.g. some devices may have a reset line and some may
not.

Signed-off-by: Simon Glass <sjg@chromium.org>

Line up the display with the line below, e.g.:

	CPU:   Exynos5250 @ 1.7 GHz
	Model: Google Spring
	DRAM:  2 GiB
	MMC:   EXYNOS DWMMC: 0

Also show the speed as GHz where appropriate.

Signed-off-by: Simon Glass <sjg@chromium.org>

We should not print a message from the driver when the display is set up.
This is normal behaviour. Change this message to use debug().

Also remove the double newline on another debug message.

Signed-off-by: Simon Glass <sjg@chromium.org>

Allow this function to be selected using the pinmux API.

Signed-off-by: Simon Glass <sjg@chromium.org>

This function should return 0 on success, not 1. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Since the timeout is reported through normal channels, and is sometimes
expected (e.g. if the bus is being probed for a non-existent device),
don't display the message in the driver.

In general, drivers should not write to the console as this limits their
usefulness in error conditions.

Signed-off-by: Simon Glass <sjg@chromium.org>

This chip provides an eDP to LVDS bridge which is useful for SoCs that don't
support LVDS displays (or it would waste scarce pins). There is no setup
required by this chip, other than to adjust power-down and reset pins, and
those are managed by the uclass.

Signed-off-by: Simon Glass <sjg@chromium.org>

This chip provides an eDP to LVDS bridge which is useful for SoCs that don't
support LVDS displays (or it would waste scarce pins). The setup is included
in the device tree.

Signed-off-by: Simon Glass <sjg@chromium.org>

We haven't quite got pinctrl ready to apply to mainline. We don't want to
GPIO pull-up/down support to the driver model GPIO layer either. So work
around this for now.

We can address this when pinctrl is complete.

Signed-off-by: Simon Glass <sjg@chromium.org>

A video bridge typically converts video from one format to another, e.g.
DisplayPort to LVDS. Add driver model support for these with a simple
interface to control activation and backlight. The uclass supports GPIO
control of power and reset lines.

Signed-off-by: Simon Glass <sjg@chromium.org>

When a regulator command cannot honour the requested voltage, display the
limits to try to be helpful.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>

Not all regulators can be set up automatically. Adjust the code so that
regulators_enable_boot_on() will return success when some are skipped.
Only genuine errors are reported.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>

Add support for all BUCK regulators, now that the correct register is
accessed for each.

Signed-off-by: Simon Glass <sjg@chromium.org>