[U-Boot] FDT driver initialization function declaration

[Michal Simek <monstr@monstr.eu>]

On 07/10/2012 03:12 PM, Marek Vasut wrote:
> Dear Wolfgang Denk,
>
>> Dear Michal Simek,
>>
>> In message<4FFC1EF8.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?


struct driver:
- for device-tree support there must be any pointer to matching table
defined in every device driver.

- 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?

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.

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.

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?


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.

Thanks,
Michal









-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian