The function part_init() will only be built when we have both
CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to
this function with both of these tests now.
Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Cc: Mingkai Hu <mingkai.hu@nxp.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Vanessa Maegima <vanessa.maegima@nxp.com>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Adam Ford <aford173@gmail.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The biggest part of migration to using CONFIG_BLK is that we need to
have the various subsystems migrated first, so reword the plan here to
reference the new deadlines.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
As the core of the subsystem has been converted along with some of the
drivers, formalize a deadline for migration.
Cc: Akshay Bhat <akshaybhat@timesys.com>
Cc: Andreas Geisreiter <ageisreiter@dh-electronics.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Jason Liu <jason.hui.liu@nxp.com>
Cc: Ken Lin <Ken.Lin@advantech.com.tw>
Cc: Ludwig Zenz <lzenz@dh-electronics.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Max Krummenacher <max.krummenacher@toradex.com>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Soeren Moch <smoch@web.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: York Sun <york.sun@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
As much of the USB system has been migrated to DM now, formalize a
deadline for migration.
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Given that at this point the MMC subsystem itself has been migrated
along with a number of subsystem drivers, formalize a deadline for
migration.
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
spi_init used in some areas in tree, but the respective
drivers will remove in future patches.
So remove the same instances.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Add some description about pre-relocation driver binding, including
usage of DM_FLAG_PRE_RELOC flag and caveats.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reword the documentation to make it clear the compatible string is now
optional, yet still matching on it takes precedence over PCI IDs and
PCI classes.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present it is not possible to specify that a node should be used before
relocation (in U-Boot proper) without it also ending up in SPL and TPL
device trees. Add a new "u-boot,dm-pre-proper" boolean property for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide information about
- overview of file system firmware loader driver model
- describe storage device and partition in device tree source
- describe fie system firmware loader API
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the section about Device Trees add a paragraph at the end that
clarifies how we decide of a tree is valid or not. We say that all
bindings must either be in the specification (link provided) or in our
device-tree-bindings directory. We say that most of these come from the
Linux Kernel and as such some design decisions are made for us already,
but that in most cases we wish to retain compatibility.
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present all emulated sandbox pci devices must be present in the
device tree in order to be used. The real world pci uclass driver
supports pci device driver matching, and we should add such support
on sandbox too.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Last user of this driver went away in May 2017 in commit
eb5ba3aefd ("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
d928664f41 ("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>
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>
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>
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>
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>
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>
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>
