Re: [U-Boot] FDT driver initialization function declaration

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