History log of /rk3399_rockchip-uboot/drivers/core/devres.c (Results 1 – 4 of 4)
Revision Date Author Comments
# ae27120c 06-Aug-2015 Tom Rini <trini@konsulko.com>

Merge git://git.denx.de/u-boot-dm


# 40b6f2d0 25-Jul-2015 Masahiro Yamada <yamada.masahiro@socionext.com>

devres: add debug command to dump device resources

This new command can dump all device resources associated to
each device. The fields in every line shows:
- The address of the resource
- The

devres: add debug command to dump device resources

This new command can dump all device resources associated to
each device. The fields in every line shows:
- The address of the resource
- The size of the resource
- The name of the release function
- The stage in which the resource has been acquired (BIND/PROBE)

Currently, there is no driver using devres, but if such drivers are
implemented, the output of this command should look like this:

=> dm devres
- root_driver
- soc
- extbus
- serial@54006800
bfb541e8 (8 byte) devm_kmalloc_release BIND
bfb54440 (4 byte) devm_kmalloc_release PROBE
bfb54460 (4 byte) devm_kmalloc_release PROBE
- serial@54006900
bfb54270 (8 byte) devm_kmalloc_release BIND
- gpio@55000000
- i2c@58780000
bfb5bce8 (12 byte) devm_kmalloc_release PROBE
bfb5bd10 (4 byte) devm_kmalloc_release PROBE
- eeprom
bfb54418 (12 byte) devm_kmalloc_release BIND

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...


# 2b07f685 25-Jul-2015 Masahiro Yamada <yamada.masahiro@socionext.com>

devres: add devm_kmalloc() and friends (managed memory allocators)

devm_kmalloc() is identical to kmalloc() except that the memory
allocated with it is managed and will be automatically released
whe

devres: add devm_kmalloc() and friends (managed memory allocators)

devm_kmalloc() is identical to kmalloc() except that the memory
allocated with it is managed and will be automatically released
when the device is removed/unbound.

Likewise for the other variants.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...


# 608f26c5 25-Jul-2015 Masahiro Yamada <yamada.masahiro@socionext.com>

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 sp

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>

show more ...