Hi
On Wednesday 11 of July 2012 11:52:13 Michal Simek wrote:
On 07/10/2012 03:12 PM, Marek Vasut wrote:
Dear Wolfgang Denk,
Dear Michal Simek,
In message4FFC1EF8.9060705@monstr.eu you wrote:
The hardest part I have identify on microblaze was about u-boot variables. Because based on information from device-tree you can choose where variables should be stored and also this memory should be accessible before u-boot try to read variables. It mean in very early state.
Device initialization before relocation is already hard enough;
+1
resources are very limited then.
And we'll be introducing the early mallocator. This is where MPC85x will blow my mind :) (I'm repeating myself here, but it might help getting others unaware of the DM work better in line).
You will add the additional need to have the FDT library available then, too. Not to mention that you need to load the DT blob, too.
DT blob can be read from ROM if that was the problem. The DT library and parser might be an issue.
This will be a lot of added complexity.
And therefore slowing down the boot. But I believe it can be optimized to leverage this to some point. Though I'm not quite sure how much. This is worthy investigation.
Michal, can you try investigating how will the DT probing intertwine with the DM?
I have read your documentation and there are some things I would like to discuss.
UDM-design.txt
How do you want to distinguish between early drivers(console/memory) and common drivers?
there should be no difference. memory mallocator should switch transparently, and each driver should be able to reallocate all its memory (which happens between the early and "normal" stage)
struct driver:
- for device-tree support there must be any pointer to matching table
defined in every device driver.
this part is not complete, we still have to add PnP ids to the driver (currently being discussed)
- struct driver *cores[array] - can you please clear this usage?
For example for any device on spi/i2c bus. What cores will depends on it? All SPI/I2C devices/device-drivers, just one, which one? Isn't it better to do it by priorities I mentioned above?
cores work as an abstraction of a device type, so anything on a SPI bus will not depend on a SPI core, rather the SPI controller will depend on SPI core. of course transitive dependencies will occur, because each device will also depend on its parent (SPI controller in case of SPI device)
struct driver_info - Where do you want to fill the platform_data? Because for current u-boot configuration style this will be setup statically and for device-tree dynamically.
platform_data can either be filled statically, or dynamically (in case of PnP, FDT). come to think about it, this may cause some problems in the relocation stage if the driver_info is in dynamic memory (PnP shouldnt happen at this stage, but FDT will)
probe function require struct instance as parameter and how is it passed that platform data from struct driver_info which probably contains information required for probing - like address and other parameters required for configuration.
probe() is called when the device is actually being activated (aka just before the first use), so the function you should watch for is driver_bind()
For device-tree all these options should be selected at run time. It means remove all ifdefs from drivers which of course increase u-boot binary size.
UDM-cores.txt about driver cores initialization at runtime. Do you need to initialized all driver cores at early-init stage? Or just that crucial one?
core will be initialized on-demand, so only the crucial ones will exist in the early-init stage
I am missing how you want to pass driver configuration data(addresses, settings) to the driver. I expect that this must be done out of device drivers.
thats what platform_data is for, if i understand what you mean
Thanks, Michal