When OF_PLATDATA_INST is enabled, we need dt-uclass.c and dt-device.c for
the build to work. When OF_PLATDATA_INST is not enabled, we only need
dt-plat.c

Update the Makefile rules to indicate this.

At present all files are generated and compiled regardless of which are
actually needed.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Since the dst_dir rule always runs, it causes a rebuild of the of-platdata
files even if not needed.

Create the directory inside the rule instead.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present the build rule for pylibfdt depends on _libfdt.so but modern
Python versions add a different suffix to the output file, resulting in
something like _libfdt.cpython-38-x86_64-linux-gnu.so

The result is that pylibfdt is rebuilt every time.

Rename the file the standard name so that the rule works correctly. Also
add libfdt.py to the dependencies, so that file is always created if
missing.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Now that dtoc generates some new C files, add these to the build so that
the instantiated devices and uclasses can be used.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

There is no need to ever add new uclasses since these are set up at build
time. Update the code to return an error if this is attempted.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

With this we don't need to scan and bind drivers, not even the root
device. We just need to locate the root device that was set up at build
time, then set our root in global_data to point to it.

Update the code to handle this case.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

When OF_PLATDATA_INST is enabled we don't need to create the uclass list.
Instead we just need to point to the existing list. Update the code
accordingly.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

With OF_PLATDATA_INST devices are bound at build time. We should not need
binding of devices at runtime in most cases. However it is inflexible to
absolutely prohibit it, so add an option to control this.

Update the driver model core so that it does not bind devices. Update
device_bind() to return an error if called.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add macros which work with instantiated devices and uclasses, as created
at build time by dtoc. Include variants that can be used in data
structures.

These are mostly used by dtoc but it is worth documenting them fully for
the occasional case where they might come up in user code.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present linker lists are designed for use in code. They make use of
statements within expressions ({...}), for example.

It is possible to generate a reference to a linker_list entry that can
be used in data structures, where such features are not permitted. It
requires that the reference first be declared as extern. In other
words the existing macro needs to be split into two parts.

Add new macros to support this.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is not needed in normal operation. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

We can use extern instead, so let's drop these macros. It adds one more
thing to learn about and doesn't make the code any clearer.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

The module defines a duplicate uclass driver for UCLASS_SIMPLE_BUS, but
it is not allowed. This breaks of-platdata and makes the result
non-deterministic.

The driver does not need to be an uclass driver, so lets remove it. I
had turned it into an uclass driver because I thought wrongly it had to
call the dm_scan_fdt_dev routine to work properly, but some tests on the
board have shown otherwise.
Signed-off-by: NDario Binacchi <dariobin@libero.it>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add support for generating a file containing udevice instances. This
avoids the need to create these at run time.

Update a test uclass to include a 'per_device_plat_auto' member, to
increase test coverage.

Add another tab to the driver_info output so it lines up nicely like the
device-instance output.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add support for generating a file containing uclass instances. This avoids
the need to create these at run time.

Update a test uclass to include a 'priv_auto' member, to increase test
coverage.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add a summary to the top of the generated code, to make it easier to see
what the file contains.

Also add a tab to .plat so that its value lines up with the others.
Signed-off-by: NSimon Glass <sjg@chromium.org>

For now dtoc only supports a hard-coded list of phandle properties, to
avoid any situation where it makes a mistake in its determination.

Make this into a constant dict, recording both the phandle property name
and the associated #cells property in the target node. This makes it
easier to find and modify.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Some of these do not follow the rules. Make sure the driver name matches
the compatible string in all cases.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present this property is a phandle but does not have a #xxx-cells
property to match it. Add one so that is works the same as gpio and clock
phandles.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This file is not used when instantiating devices. Update dtoc to skip
generating its contents and just add a comment instead.

Also it is useful to see the driver name and parent for each device.
Update the file to show that information, to avoid updating the same
tests twice.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add an option to generate the declaration file, which declares all
drivers and uclasses, so references can be used in the code.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add Kconfig options to support build-time device instantiation. When
fully implemented, this will allow dtoc to create U-Boot devices (i.e.
struct udevice records) at build time, thus reducing code space in
SPL.

For now this defaults to off, but will be enabled when the rest of
the implementation is in place.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add an option to instantiate devices at build time. For now this just
parses the option and sets up a few parameters.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The device for the root node is normally bound by driver model on init.
With devices being instantiated at build time, we must handle the root
device also.

Add support for processing the root node, which may not have a compatible
string.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We only care about uclasses that are actually used. This is determined by
the drivers that use them. Check all the used drivers and build a list of
'valid' uclasses.

Also add references to the uclasses so we can generate C code that uses
them. Attach a uclass to each valid driver.

For the tests, now that we have uclasses we must create an explicit test
for the case where a node does not have one. This should only happen if
the source code does not build, or the source-code scanning fails to find
it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Now that we have the alias information we can assign a sequence number
to each device in the uclass. Store this in the node associated with each
device.

This requires renaming the sandbox test drivers to have the right name.
Note that test coverage is broken with this patch, but fixed in the next
one.
Signed-off-by: NSimon Glass <sjg@chromium.org>

If a driver declaration is included in a comment, dtoc currently gets
confused. Update the parser to only consider declarations that begin at
the start of a line. Since multi-line comments begin with an asterisk,
this avoids the problem.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Scan the aliases in the device tree to establish the number of devices
within each uclass, and the sequence number of each.
Signed-off-by: NSimon Glass <sjg@chromium.org>

If drivers have the same name then we cannot distinguish them. This only
matters if the driver is actually used by dtoc, but in that case, issue
a warning.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Instead of using a separate step for this processing, handle it while
scanning its associated driver. This allows us to drop the code coverage
exception in this case.

Note that only files containing drivers are scanned by dtoc, so aliases
declared in a file that doesn't hold a driver will not be noticed. It
would be confusing to put them anywhere other than in the driver that they
relate to, but update the documentation to say this explicitly, just in
case.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Typically dtoc can detect the header file needed for a driver by looking
for the structs that it uses. For example, if a driver as a .priv_auto
that uses 'struct serial_priv', then dtoc can search header files for the
definition of that struct and use the file.

In some cases, enums are used in drivers, typically with the .data field
of struct udevice_id. Since dtoc does not support searching for these,
add a way to tell dtoc which header to use. This works as a macro included
in the driver definition.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Pass the U-Boot phase as a parameter so dtoc can use it. At present it is
ether "spl" or "tpl".
Signed-off-by: NSimon Glass <sjg@chromium.org>

U-Boot operates in several phases, typically TPL, SPL and U-Boot proper.
The latter does not use dtoc.

In some rare cases different drivers are used for two phases. For example,
in TPL it may not be necessary to use the full PCI subsystem, so a simple
driver can be used instead.

This works in the build system simply by compiling in one driver or the
other (e.g. PCI driver + uclass for SPL; simple_bus for TPL). But dtoc has
no way of knowing which code is compiled in for which phase, since it does
not inspect Makefiles or dependency graphs.

So to make this work for dtoc, we need to be able to explicitly mark
drivers with their phase. This is done by adding an empty macro to the
driver. Add support for this in dtoc.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Mark all nodes that are actually used, so we can perform extra checks on
them.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add logic to assign property values to nodes as required by dtoc. The
references allow nodes to refer to each other in C code. The macros used
by dtoc are not yet defined in driver model. They will be added along
with the actual driver model implementation.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Now that we have these available, use them instead of recalculating
things each time.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It is convenient to attach drivers, etc. to nodes so that we can use the
Node object as the main data structure in this module.

Add a function which adds the new properties, along with documentation.
Signed-off-by: NSimon Glass <sjg@chromium.org>

These have '_test' suffixes which are not present on the drivers in the
source code. Drop the suffixes to avoid a mismatch when scanning.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It is confusing to have the test files in the same places as the
implementation. Move them into a separate directory.

Add a helper function for test_dtoc, to avoid repeating the same
path.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Drivers can have private / platform data contained in structs and these
struct definitions are generally kept in header files. In order to
generate build-time devices, dtoc needs to generate code that declares
the data contained in those structs. This generated code must include the
relevant header file, to avoid a build error.

We need a way for dtoc to scan header files for struct definitions. Then,
when it wants to generate code that uses a struct, it can make sure it
includes the correct header file, first.

Add a parser for struct information, similar to drivers. Keep a dict of
the structs that were found.
Signed-off-by: NSimon Glass <sjg@chromium.org>