Commit graph

11 commits

Author SHA1 Message Date
Simon Glass
a2040facd2 dm: core: Allow device names to be freed automatically
Some devices have a name that is stored in allocated memory. At present
there is no mechanism to free this memory when the device is unbound.

Add a device flag to track whether a name is allocated and a function to
add the flag. Free the memory when the device is unbound.

Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-17 09:54:43 -06:00
Simon Glass
79725ca4f6 Revert "dm: Export device_remove_children / device_unbind_children"
This reverts commit bb52b367f6.

Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19 20:27:51 -07:00
Masahiro Yamada
608f26c51b devres: introduce Devres (Managed Device Resource) framework
In U-Boot's driver model, memory is basically allocated and freed
in the core framework.  So, low level drivers generally only have
to specify the size of needed memory with .priv_auto_alloc_size,
.platdata_auto_alloc_size, etc.  Nevertheless, some drivers still
need to allocate/free memory on their own in case they cannot
statically know the necessary memory size.  So, I believe it is
reasonable enough to port Devres into U-boot.

Devres, which originates in Linux, manages device resources for each
device and automatically releases them on driver detach.  With devres,
device resources are guaranteed to be freed whether initialization
fails half-way or the device gets detached.

The basic idea is totally the same to that of Linux, but I tweaked
it a bit so that it fits in U-Boot's driver model.

In U-Boot, drivers are activated in two steps: binding and probing.
Binding puts a driver and a device together.  It is just data
manipulation on the system memory, so nothing has happened on the
hardware device at this moment.  When the device is really used, it
is probed.  Probing initializes the real hardware device to make it
really ready for use.

So, the resources acquired during the probing process must be freed
when the device is removed.  Likewise, what has been allocated in
binding should be released when the device is unbound.  The struct
devres has a member "probe" to remember when the resource was
allocated.

CONFIG_DEBUG_DEVRES is also supported for easier debugging.
If enabled, debug messages are printed each time a resource is
allocated/freed.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-06 07:44:29 -06:00
Masahiro Yamada
aed1a4dd88 dm: add DM_FLAG_BOUND flag
Currently, we only have DM_FLAG_ACTIVATED to indicate the device
status, but we still cannot know in which stage is in progress,
binding or probing.

This commit introduces a new flag, DM_FLAG_BOUND, which is set when
the device is really bound, and cleared when it is unbound.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-08-06 07:44:29 -06:00
Hans de Goede
bb52b367f6 dm: Export device_remove_children / device_unbind_children
These functions are useful to remove all children from an usb bus before
rescanning the bus. Give them a better name and export them.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
2015-07-21 17:39:35 -06:00
Przemyslaw Marczak
5eaed88028 dm: core: Extend struct udevice by '.uclass_platdata' field.
This commit adds 'uclass_platdata' field to 'struct udevice', which
can be automatically allocated at bind. The allocation size is defined
in 'struct uclass_driver' as 'per_device_platdata_auto_alloc_size'.

New device's flag is added: DM_FLAG_ALLOC_UCLASS_PDATA, which is used
for memory freeing at device unbind method.

As for other udevice's fields, a complementary function is added:
- dev_get_uclass_platdata()

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
2015-04-22 11:03:14 -06:00
Simon Glass
3479253dad dm: core: Convert driver_bind() to use const
The driver is not modified by driver model, so update driver_bind() to
recognise that.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
2015-04-18 11:11:19 -06:00
Simon Glass
dac8db2ce6 dm: core: Allow uclasses to specify private data for a device's children
In many cases the per-child private data for a device's children is defined
by the uclass rather than the individual driver. For example, a SPI bus
needs to store information about each of its children, but all SPI drivers
store the same information. It makes sense to allow the uclass to define
this data.

If the driver provides a size value for its per-child private data, then use
it. Failng that, fall back to that provided by the uclass.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-29 17:09:55 -07:00
Simon Glass
cdc133bde9 dm: core: Allow parents to have platform data for their children
For buses it is common for parents to need to know the address of the child
on the bus, the bus speed to use for that child, and other information. This
can be provided in platform data attached to each child.

Add driver model support for this, including auto-allocation which can be
requested using a new property to specify the size of the data.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-29 17:09:54 -07:00
Simon Glass
f8a85449ef dm: core: Allocate platform data when binding a device
When using allocated platform data, allocate it when we bind the device.
This makes it possible to fill in this information before the device is
probed.

This fits with the platform data model (when not using device tree),
since platform data exists at bind-time.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-01-29 17:09:54 -07:00
Simon Glass
3ac435d33a dm: Allow device removal features to be dropped
For SPL we don't expect to need to remove a device. Save some code space
by dropping this feature. The board config can define
CONFIG_DM_DEVICE_REMOVE if this is in fact needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
2014-11-21 08:13:02 +01:00