[U-Boot] FDT driver initialization function declaration

Simon Glass
2012-07-14T06:49:56Z

Hi Michal,

On Tue, Jul 10, 2012 at 3:49 PM, Michal Simek <monstr@monstr.eu> wrote:
> On 07/10/2012 03:18 PM, Simon Glass wrote:
>>
>> Hi Michal,
>>
>>
>> On Tue, Jul 10, 2012 at 12:23 PM, Michal Simek <monstr@monstr.eu
>> <mailto:monstr@monstr.eu>> wrote:
>>
>> Hi Simon, Wolfgang and others,
>>
>> just want to open new topic about FDT driver initialization function
>> declaration.
>>
>> There are some drivers which can be simple move to fdt initialization.
>> I have in my mind ethernet drivers and then systemace (I have ported
>> it).
>>
>> Ethernet drivers use include/netdev.h file where all initialization
>> functions are declared.
>>
>> For example:
>>
>> diff --git a/include/netdev.h b/include/netdev.h
>> index 4724717..96e62ee 100644
>> --- a/include/netdev.h
>> +++ b/include/netdev.h
>> @@ -105,6 +105,10 @@ int xilinx_emaclite_initialize(bd___t *bis,
>> unsigned long base_addr,
>>
>> int xilinx_ll_temac_eth_init(bd_t *bis, unsigned long base_addr, int
>> flags,
>> unsigned long
>> ctrl_addr);
>>
>> +#ifdef CONFIG_OF_CONTROL
>> +int xilinx_emaclite_init(bd_t *bis);
>> +#endif
>>
>>
>> I don't think you need the #ifdef here.
>
>
> Probably not but why not to protect it.

Just an unnecessary #ifdef IMO.

>
>
>
>>
>> +
>> /*
>> * As long as the Xilinx xps_ll_temac ethernet driver has not its
>> own interface
>> * exported by a public hader file, we need a global definition at
>> this point.
>>
>>
>> But where is the right place for systemace FDT initialization?
>> include/fdtdec.h?
>>
>>
>> or create new header and include it to fdtdec.h?
>>
>>
>> Yes, but don't include it in fdtdec.h. Why do you need to?
>
>
> I am not saying that I want to do, just saying that there should be one file
> which
> cover all of these. Or of course if new device model will be used this will
> be probably solved there.

Normally if there is driver code that must be called elsewhere we add
it to a header in include/. Yes the device model will change/improve
this at some point.

>
>
>>
>>
>> In this case it makes sense to add all FDT driven configuration to one
>> header file
>> to see what drivers can be used. Even for network drivers.
>> Also listing all required parameters can be capture there.
>>
>> What do you think?
>>
>>
>> That's the idea of the list of compatible strings in fdtdec.c / h.
>>
>> I would suggest for now, just doing ad-hoc init using a special function
>> call,
>
> or whatever else makes things easy. Yes fdt can potential clean all that
> stuff up,
> but not without the device model. I think once we have the device model we
> can revisit
> this (and I look forward to it). For now, just think of fdt as a way of
> enabling a driver,
> or specifying the number of ports the driver controls, rather than a way of
> deciding which
> driver inits get called.

FDT certainly fits very nicely with device model, but it doesn't
require it. You can just have:

some_device_probe(const void *blob)

and call that from somewhere to make it look in the FDT for its info
and initialize if it finds it.

>
> Going to delay this FDT stuff till I get some more information about new
> device-model.
>
> Thanks for your comments,
>
> 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

Regards,
Simon