On 07/10/2012 03:18 PM, Simon Glass wrote:
Hi Michal,

On Tue, Jul 10, 2012 at 12:23 PM, Michal Simek <mon...@monstr.eu 
<mailto:mon...@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.



    +
      /*
       * 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.



    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.

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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to