ux500: Export SoC information and some platform clean-up
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 6 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 6 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/6] ux500: Export SoC information and some platform clean-up
Quoted 47 lines · Arnd Bergmann
Quoted 5 lines · Linus Walleij
Quoted 2 lines · Arnd Bergmann
Linus, does this fit with your plans for migrating to only device-tree based probing for ux500?
Quoted 7 lines
Well the SoC registatration (I guess in mach-*/* someplace) needs to be DT compliant by parsing some node too, but that should be some minor thing.
I'm not smart enough to tell whether DT will automagically arrange parenthood between struct device * nodes or if that needs a lot of custom code to work?
Right now,
of_platform_populatetakes a struct device that is used as the parent for all buses that get probed from the OF device tree. This would need to be integrated with thesoc_devprobing in some way, either by lettingof_platform_populatecallsoc_device_registerinternally and gaining an extra structsoc_device_attributeargument, or by callingof_platform_populatefrom a platform specific function and passing a device node below thesoc_devinto it.Quoted 7 lines
Quoted 3 lines
I guess if this goes in
first, you will have to make a few changes so that it keeps working when the devices are put into the dts.Oh well, that is a bit ahead in time anyway. We need DT support in a plethora of drivers before we're getting anywhere on that. Niklas is the right one to ask I guess...
Are there really so many driver changes required for this? We would not do it for the on-chip devices at first, so it basically comes down to the the i2c, sdi, spi and uart devices, all of which have bus bindings already. The hardest thing might be the pinmux configuration, but you already know more about the state of that than I do.
Quoted 7 lines
Quoted 1 line
Everyone else, who is planning to use the infrastructure besides ux500?
I can easily see this being used in the ARM reference designs (Integrator, Versatile, RealView and Versatile Express) some of them I can possibly patch myself even. OMAP has expressed interest in "some way of getting the SoC ID out", and I guess this is the means to that end.
Quoted 3 lines
Ah, good. Once these patches are merged, we can easily refer anyone to this infrastructure if they try to add a different way of finding a SoC ID.
Okay, so this sounds promising. Which route are the patches likely to take? Will they go up through your SoC tree Arnd?
Kind regards,
Lee