dm: Introduce device sequence numbering

In U-Boot it is pretty common to number devices from 0 and access them
on the command line using this numbering. While it may come to pass that
we will move a

dm: Introduce device sequence numbering

In U-Boot it is pretty common to number devices from 0 and access them
on the command line using this numbering. While it may come to pass that
we will move away from this numbering, the possibility seems remote at
present.

Given that devices within a uclass will have an implied numbering, it
makes sense to build this into driver model as a core feature. The cost
is fairly small in terms of code and data space.

With each uclass having numbered devices we can ask for SPI port 0 or
serial port 1 and receive a single device.

Devices typically request a sequence number using aliases in the device
tree. These are resolved when the device is probed, to deal with conflicts.
Sequence numbers need not be sequential and holes are permitted.

At present there is no support for sequence numbers using static platform
data. It could easily be added to 'struct driver_info' if needed, but it
seems better to add features as we find a use for them, and the use of -1
to mean 'no sequence' makes the default value somewhat painful.

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

show more ...

dm: Allow drivers to be marked 'before relocation'

Driver model currently only operates after relocation is complete. In this
state U-Boot typically has a small amount of memory available. In adding

dm: Allow drivers to be marked 'before relocation'

Driver model currently only operates after relocation is complete. In this
state U-Boot typically has a small amount of memory available. In adding
support for driver model prior to relocation we must try to use as little
memory as possible.

In addition, on some machines the memory has not be inited and/or the CPU
is not running at full speed or the data cache is off. These can reduce
execution performance, so the less initialisation that is done before
relocation the better.

An immediately-obvious improvement is to only initialise drivers which are
actually going to be used before relocation. On many boards the only such
driver is a serial UART, so this provides a very large potential benefit.

Allow drivers to mark themselves as 'pre-reloc' which means that they will
be initialised prior to relocation. This can be done either with a driver
flag or with a 'dm,pre-reloc' device tree property.

To support this, the various dm scanning function now take a 'pre_reloc_only'
parameter which indicates that only drivers marked pre-reloc should be
bound.

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

show more ...

dm: Expand and improve the device lifecycle docs

The lifecycle of a device is an important part of driver model. Add to the
existing documentation and clarify it.

Reported-by: Jon Loeliger <jdl@jdl

dm: Expand and improve the device lifecycle docs

The lifecycle of a device is an important part of driver model. Add to the
existing documentation and clarify it.

Reported-by: Jon Loeliger <jdl@jdl.com>

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

show more ...

dm: Rename struct device_id to udevice_id

It is best to avoid having any occurence of 'struct device' in driver
model, so rename to achieve this.

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

docs: driver-model: Fix spelling

Signed-off-by: Chris Packham <judge.packham@gmail.com>

dm: rename device struct to udevice

using UBI and DM together leads in compiler error, as
both define a "struct device", so rename "struct device"
in include/dm/device.h to "struct udevice", as we u

dm: rename device struct to udevice

using UBI and DM together leads in compiler error, as
both define a "struct device", so rename "struct device"
in include/dm/device.h to "struct udevice", as we use
linux code (MTD/UBI/UBIFS some USB code,...) and cannot
change the linux "struct device"

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Marek Vasut <marex@denx.de>

show more ...

dm: Remove old driver model documentation

This documentation pertains to the planned implementation of driver model
in U-Boot for each subsystem, but it has not been superseded. It is
probably bette

dm: Remove old driver model documentation

This documentation pertains to the planned implementation of driver model
in U-Boot for each subsystem, but it has not been superseded. It is
probably better to have this documentation in the source code for each
subsystem where possible, so that docbook will pick it up. Where this does
not make sense, new documentation can be placed in some suitable file in
doc/driver-model.

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

show more ...

dm: Add README for driver model

This adds a README to help with understanding of this series.

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

ARM: serial: Remove the IXP UART driver

This driver is no longer used, remove it.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Michael Schwingen <mi

ARM: serial: Remove the IXP UART driver

This driver is no longer used, remove it.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Michael Schwingen <michael@schwingen.org>
Cc: Tom Rini <trini@ti.com>

show more ...

ARM: PCI: Remove the IXP PCI driver

The driver is no longer used, remove it.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Michael Schwingen <michael

ARM: PCI: Remove the IXP PCI driver

The driver is no longer used, remove it.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Michael Schwingen <michael@schwingen.org>
Cc: Tom Rini <trini@ti.com>

show more ...