Last user of this driver went away in May 2017 in commit
eb5ba3ae ("i2c: Drop use of CONFIG_I2C_HARD").

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Acked-by: Heiko Schocher <hs@denx.de>

Last user of this driver went away in June 2015 in commit
d928664f ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Acked-by: Heiko Schocher <hs@denx.de>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>

Due to adding various new functionalities with SPI and SPI-FLASH
subsystems which are rounding in Mailing list for year these long
term supporting spi driver which never seen any update with
driver-model conversion.

So added migration plan for DM_SPI and DM_SPI_FLASH with
deadline v2018.09

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Rather than naming the phandle struct according to the number of cells it
uses (e.g. struct phandle_2_cell) name it according to the number of
arguments it has (e.g. struct phandle_1_arg). This is a more intuitive
naming.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

Add some documentation for the live device tree support in U-Boot. This
was missing from the initial series.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Łukasz Majewski <lukma@denx.de>

The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
code, with #ifdefs and different code paths. We should try to move over to
this soon so we can drop the old code.

Set a deadline of 9 months for this work, rounded up to the next release.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Sometimes a node will have multiple compatible strings. Drivers may use
one or the other so the best approach seems to be to #define them to be
equivalent.

Update dtoc to support this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added to the main board's busses, e.g. I2C.

The device tree support for such boards would either, quite naturally,
employ the overlay mechanism to add such chips to the tree, or would use
one large default device tree, and delete the devices that are actually
not present.

Regardless of approach, even on the U-Boot level, a modification of the
device tree is a prerequisite to have such modular families of boards
supported properly.

Therefore, we add an option to make the U-Boot device tree (the actual
copy later used by the driver model) writeable, and add a callback
method that allows boards to modify the device tree at an early stage,
at which, hopefully, also the application of device tree overlays will
be possible.

Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>

Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added to the main board's busses, e.g. I2C.

The device tree support for such boards would either, quite naturally,
employ the overlay mechanism to add such chips to the tree, or would use
one large default device tree, and delete the devices that are actually
not present.

Regardless of approach, even on the U-Boot level, a modification of the
device tree is a prerequisite to have such modular families of boards
supported properly.

Therefore, we add an option to make the U-Boot device tree (the actual
copy later used by the driver model) writeable, and add a callback
method that allows boards to modify the device tree at an early stage,
at which, hopefully, also the application of device tree overlays will
be possible.

Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>

Right now the u-boot,dm-pre-reloc flag will make each marked node
always appear in both spl and tpl. But systems needing an additional
tpl might have special constraints for each, like the spl needing to
be very tiny.

So introduce two additional flags to mark nodes for only spl or tpl
environments and introduce a function dm_fdt_pre_reloc to automate
the necessary checks in code instances checking for pre-relocation
flags.

The behaviour of the original flag stays untouched and still marks
a node for both spl and tpl.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.

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

Add a README with a brief guide to porting i2c drivers over to use driver
model.

Add a timeline also. All I2C drivers should be converted by the end
of June 2017.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>

This is not used by any boards. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Müller <d.mueller@elsoft.ch>
Reviewed-by: Jagan Teki <jagan@openedev.com>

This driver was converted so we should remove it from the list.

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

Revise the content based on the v2 additions. This is kept as a separate
patch to avoid confusing those who have already reviewed the v1 series.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>

Add documentation on how this works, including the benefits and drawbacks.

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

This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>

Since all the tests are implemented in pytest infrastructure,
So update the dm tests with the same instead of ./test/dm/test-dm.sh

Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Jagan Teki <jteki@openedev.com>

Remove ARM Debug communication channel driver from the list
of not converted drivers to DM.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>

Update the README to reflect the current status.

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

Enable SPL DM too.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Thomas Chou <thomas@wytron.com.tw>

This adds driver model support to lpuart serial driver.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Tested-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>

Since both altera_jtag_uart and altera_uart are converted to driver
model, remove them from the list of drivers remaining to convert.

Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Chin Liang See <clsee@altera.com>

Signed-off-by: Kamil Lulko <kamil.lulko@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add a README with a brief guide to porting serial drivers over to use
driver model.

Add a timeline also. All serial drivers should be converted by the end
of January 2016.

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

The current name is inconsistent with other driver model data access
functions. Rename it and fix up all users.

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

Many System on Chip(SoC) solutions are complex with multiple processors
on the same die dedicated to either general purpose of specialized
functions. Many examples do exist in today's SoCs from various vendors.
Typical examples are micro controllers such as an ARM M3/M0 doing a
offload of specific function such as event integration or power
management or controlling camera etc.

Traditionally, the responsibility of loading up such a processor with a
firmware and communication has been with a High Level Operating
System(HLOS) such as Linux. However, there exists classes of products
where Linux would need to expect services from such a processor or the
delay of Linux and operating system being able to load up such a
firmware is unacceptable.

To address these needs, we need some minimal capability to load such a
system and ensure it is started prior to an Operating System(Linux or
any other) is started up.

NOTE: This is NOT meant to be a solve-all solution, instead, it tries to
address certain class of SoCs and products that need such a solution.

A very simple model is introduced here as part of the initial support
that supports microcontrollers with internal memory (no MMU, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>

Document how pci devices are bound to device drivers.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

Correct two typos and mention how pci bus will be probed.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

We should guide people more strongly towards device tree to avoid the
proliferation of platform data structures. Add documentation to the driver
model README, and also the platform data header file.

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

This commit cleanups the PMIC framework documentation.

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

Since this framework is still under the construction, the main
documentation is kept in the header files.

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

There are a lot more tests now. To avoid confusion add the updated test
output to the driver model README.

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

Add some documentation describing how USB is implemented with USB. This
might make things easier for people to understand.

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>

Expand the help messages for each driver. Add missing Kconfig for I2C,
SPI flash and thermal.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

Now that we have new bus features, update README.txt and the SPI docs to
explain these.
Signed-off-by: Simon Glass <sjg@chromium.org>

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>

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>