[U-Boot] [U-Boot-DM] FDT driver initialization function declaration

[Pavel Herrmann]

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 message<4FFC1EF8.9060705 at 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