u-boot.git/drivers/core, branch v2021.04

x86: Move INTEL_ACPIGEN to arch/x86

2021-03-09T01:42:12+00:00

This option is better placed in the x86 code since it is not generic
enough to be in the core code. Move it.

Reported-by: Heinrich Schuchardt 
Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
[bmeng: fixed a typo in arch/x86/Kconfig]
Signed-off-by: Bin Meng

dm: core: Add DM_DEVICE_REMOVE condition to all exit paths

2021-03-04T02:17:25+00:00

At present device_bind() does some unnecessary work if a device fails to
bind in SPL. Add the missing conditions.

Also fix a style nit in the same function while we are here.

Signed-off-by: Simon Glass

dm: core: Fix allocation of empty of-platdata

2021-03-04T02:17:25+00:00

With of-platdata we always have a dtv struct that holds the platform data
provided by the driver_info record. However, this struct can be empty if
there are no actual devicetree properties provided.

The upshot of empty platform data is that it will end up as a zero-size
member in the BSS section, which is fine. But if the driver specifies
plat_auto then it expects the correct amount of space to be allocated.

At present this does not happen, since device_bind() assumes that the
platform-data size will always be >0. As a result we end up not
allocating the space and just use the BSS region, overwriting whatever
other contents are present.

Fix this by removing the condition that platform data be non-empty, always
allocating space if requested.

This fixes a strange bug that has been lurking since of-platdata was
implemented. It has likely never been noticed since devices normally have
at least some devicetree properties, BSS is seldom used on SPL, the dtv
structs are normally at the end of bss and the overwriting only happens
if a driver changes its platform data.

It was discovered using sandbox_spl, which exercises more features than
a normal board might, and the critical global_data variable 'gd' happened
to be at the end of BSS.

Fixes: 9fa28190091 ("dm: core: Expand platdata for of-platdata devices")
Signed-off-by: Simon Glass

dm: Introduce DMA constraints into the core device model

2021-02-18T10:56:25+00:00

Calculating the DMA offset between a bus address space and CPU's every
time we call phys_to_bus() and bus_to_phys() isn't ideal performance
wise, as it implies traversing the device tree from the device's node up
to the root. Since this information is static and available before the
device's initialization, parse it before the probe call an provide the
DMA offset in 'struct udevice' for the address translation code to use
it.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Simon Glass 
Tested-by: Peter Robinson 
Signed-off-by: Matthias Brugger

dm: Introduce xxx_get_dma_range()

2021-02-18T10:56:25+00:00

Add the following functions to get a specific device's DMA ranges:
 - dev_get_dma_range()
 - ofnode_get_dma_range()
 - of_get_dma_range()
 - fdt_get_dma_range()
They are specially useful in oder to be able validate a physical address
space range into a bus's and to convert addresses from and to address
spaces.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Simon Glass 
Tested-by: Peter Robinson 
Signed-off-by: Matthias Brugger

Merge branch '2021-02-02-drop-asm_global_data-when-unused'

2021-02-15T15:16:45+00:00

- Merge the patch to take  out of

dm: core: Add late driver remove option

2021-02-03T10:38:41+00:00

Add another flag to the DM core which could be assigned to drivers and
which makes those drivers call their remove callbacks last, just before
booting OS and after all the other drivers finished with their remove
callbacks. This is necessary for things like clock drivers, where the
other drivers might depend on the clock driver in their remove callbacks.
Prime example is the mmc subsystem, which can reconfigure a card from HS
mode to slower modes in the remove callback and for that it needs to
reconfigure the controller clock.

Signed-off-by: Marek Vasut 
Signed-off-by: Simon Glass

dm: core: Avoid partially removing devices

2021-02-03T10:38:41+00:00

At present if device_remove() decides that the device should not actually
be removed, it still calls the uclass pre_remove() method and powers the
device down.

Signed-off-by: Simon Glass

dm: core: Remove children before advising uclass

2021-02-03T10:38:41+00:00

At present the uclass pre-remove method is called before the children are
removed. But the children may refused to be removed, in whch case the
uclass is in a tricky situation. At present we handle this by calling
the uclass' post_probe() method. But it seems better to avoid doing
anything with the uclass in this case.

Switch the ordering so that we make sure the children can be removed
before advising the uclass.

Signed-off-by: Simon Glass

dm: Rename DM_FLAG_REMOVE_WITH_PD_ON

2021-02-03T10:38:41+00:00

This flag has the word 'REMOVE' in it which means it conflicts with
the DM_REMOVE flags. Rename it to DM_FLAG_LEAVE_PD_ON which seems to
indicate its purpose well enough.

Signed-off-by: Simon Glass