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: NSimon Glass <sjg@chromium.org>

This is required on some platforms, so add it.
Signed-off-by: NSimon 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: NSimon 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: NYork 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: NYork 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: NSimon Glass <sjg@chromium.org>

We always use device tree on exynos, so remove the unused code.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This has moved to driver model so we can drop the fdtdec support.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We have a new one which uses driver model and device tree configuration.
Remove the old one.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is not needed with driver mode. Remove it.
Signed-off-by: NSimon 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: NSimon 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: NSimon 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: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw 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: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw 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: NSimon Glass <sjg@chromium.org>

Enable PMICs, regulators and the like so that new drivers will be made
available.
Signed-off-by: NSimon 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: NSimon 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: NSimon Glass <sjg@chromium.org>

The driver supports driver model. Add a node for snow, which needs it.
Signed-off-by: NSimon 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: NSimon 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: NSimon 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: NSimon 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: NSimon 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: NSimon Glass <sjg@chromium.org>

Allow this function to be selected using the pinmux API.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function should return 0 on success, not 1. Fix it.
Signed-off-by: NSimon 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: NSimon 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: NSimon 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: NSimon 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: NSimon 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: NSimon Glass <sjg@chromium.org>

When a regulator command cannot honour the requested voltage, display the
limits to try to be helpful.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw 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: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

Add support for all BUCK regulators, now that the correct register is
accessed for each.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Some regulators use the wrong voltage register and thus it is not possible
to control them. Fix this.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

This should write the register, not read it. Fix this bug.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

The driver name should not have a space in it. Also the regulator names
should match the case of the device tree. Fix these problems.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

This PMIC is used with SoCs which need a combination of BUCKs and LDOs. The
driver supports changing voltage and enabling/disabling each regulator. It
supports the standard device tree binding and supports driver model.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

This PMIC is used with SoCs which need a combination of BUCKs and LDOs. The
driver supports probing and basic register access. It supports the standard
device tree binding and supports driver model. A regulator driver can be
provided also.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

The TPS65090 has 7 FETs which are modelled as regulators. This allows them
to be controlled by drivers easier, accessed through the 'regulator' command
and used by other drivers.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>