FDT driver initialization function declaration

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).

Dear Michal,

Quoted 6 lines · In message<[email protected]> you wrote:

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).

I"m not sure if it's a good idea to do this right now. Any such activities would in minimum cause a moving target for the upcoming driver model work, and most probably cause lots of conflicts on both sides.

I think your plans should be co-ordinated (and probably be merged) with the DM group.

Dear Wolfgang,

Quoted 15 lines · Wolfgang Denk

Dear Michal,

Quoted 6 lines · In message<[email protected]> you wrote:

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).

I"m not sure if it's a good idea to do this right now. Any such activities would in minimum cause a moving target for the upcoming driver model work, and most probably cause lots of conflicts on both sides.

Quoted 2 lines

I think your plans should be co-ordinated (and probably be merged) with the DM group.

I wasn't aware about this group. I was CC in that announcement email but I missed it. :-(

ok. I have signed to this ml. There are some familiar name and also some czech guys. I have added u-boot-dm list to CC too.

Can someone update me about current state of device-tree model?

I will read archive and dm documentation in Marek's git tree.

Let me summarize what I have done and tested on microblaze. I have ported emaclite/ll_temac/systemace/timer/intc/cfi-flash/spi-flash uartlite/uart16550 (serial-multi) drivers.
My expectation is that minimum information I need for compilation is u-boot starting address and microblaze compilation flags (the same one as we need for the Linux kernel).

Serial console is selected based on aliases node where serial0 is always the first console. Based on type driver is initialized.
I am using up to 4 uart16550 and 4 uartlite drivers but I do care just for serial0-serial3 aliases.

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.

Thanks,
Michal

Dear Michal Simek,

Quoted 18 lines

Dear Wolfgang,

Quoted 15 lines · Wolfgang Denk

Dear Michal,

Quoted 6 lines · In message<[email protected]> you wrote:

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).

I"m not sure if it's a good idea to do this right now. Any such activities would in minimum cause a moving target for the upcoming driver model work, and most probably cause lots of conflicts on both sides.

Quoted 5 lines

Quoted 2 lines

I think your plans should be co-ordinated (and probably be merged) with the DM group.

I wasn't aware about this group. I was CC in that announcement email but I missed it. :-(

I believe we can meet up, have some good beer, where are you located in CZ?

Quoted 5 lines

ok. I have signed to this ml. There are some familiar name and also some czech guys. I have added u-boot-dm list to CC too.

Can someone update me about current state of device-tree model?

git clone git://git.denx.de/u-boot-marex.git -dm branch ... but the documents will soon see further updates. The rough outline is there thought. See doc/driver-model/

I hope the DM will be very easily possible to integrate with DT, it's done with that in mind. But we included a few more interesting components, like late probing of devices, unification of block devices and other craziness.

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.

Dear Michal Simek,

Quoted 5 lines · In message <[email protected]> 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;

resources are very limited then.

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.

This will be a lot of added complexity.

Best regards,

Wolfgang Denk

Dear Wolfgang Denk,

Quoted 10 lines

Dear Michal Simek,

Quoted 5 lines · In message<[email protected]> 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

Quoted 1 line

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).

Quoted 3 lines

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.

Quoted 1 line

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?

Quoted 2 lines

Michal, can you try investigating how will the DT probing intertwine with the DM?

Firstly I need to understand what you are trying to achieve and how. Then if I have time I can look at how DT probing can be added to it.

But I think that there is good example in the Linux kernel how to do it. I believe that device-tree guys will have some good comments and experiences from the kernel.

Thanks,
Michal

Dear Michal Simek,

[...]

Quoted 6 lines

Quoted 2 lines

Michal, can you try investigating how will the DT probing intertwine with the DM?

Firstly I need to understand what you are trying to achieve and how. Then if I have time I can look at how DT probing can be added to it.

Quoted 3 lines

But I think that there is good example in the Linux kernel how to do it. I believe that device-tree guys will have some good comments and experiences from the kernel.

But please understand we have some additional special requirements on the driver model. We tried to keep it as close as possible though.

Dear Wolfgang Denk,

Quoted 10 lines

Dear Michal Simek,

Quoted 5 lines · In message<[email protected]> 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

Quoted 1 line

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).

Quoted 3 lines

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.

Quoted 1 line

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?

Quoted 28 lines · Marek Vasut

Dear Wolfgang Denk,

Quoted 10 lines

Dear Michal Simek,

Quoted 5 lines · In message<[email protected]> 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

Quoted 1 line

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).

Quoted 3 lines

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.

Quoted 8 lines

Quoted 1 line

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

Quoted 3 lines

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

Quoted 4 lines

thats what platform_data is for, if i understand what you mean

That's my understanding too. But the point is how it is passed to the driver itself
because I didn't see any pointer to it there.

Quoted 5 lines

Quoted 1 line

thats what platform_data is for, if i understand what you mean

That's my understanding too. But the point is how it is passed to the driver itself
because I didn't see any pointer to it there.

I had an impression that platform data are and should be static and therefore universally visible/known...?

Tomas

Dear Michal Simek,

Quoted 5 lines · In message<[email protected]> 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; resources are very limited then. 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.

This will be a lot of added complexity.

Dear Wolfgang,

Quoted 14 lines · Wolfgang Denk

Dear Michal Simek,

Quoted 5 lines · In message<[email protected]> 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; resources are very limited then. 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.

Quoted 1 line

This will be a lot of added complexity.

Do you have any timeframe for this work?
Or any expectation when this work should be merged to mainline?

Thanks,
Michal

Dear Michal Simek,

Quoted 17 lines

Dear Wolfgang,

Quoted 14 lines · Wolfgang Denk

Dear Michal Simek,

Quoted 5 lines · In message<[email protected]> 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; resources are very limited then. 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.

Quoted 4 lines

Quoted 1 line

This will be a lot of added complexity.

Do you have any timeframe for this work?
Or any expectation when this work should be merged to mainline?

6 months, 2 releases ... or so. We booted it as a university project to maximize the gain.

Quoted 21 lines

Dear Michal Simek,

Quoted 19 lines

Dear Wolfgang,

Quoted 15 lines · Wolfgang Denk

Dear Michal Simek,

Quoted 5 lines · In message<[email protected]> 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; resources are very limited then. 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.

This will be a lot of added complexity.

Quoted 5 lines

Quoted 2 lines

Do you have any timeframe for this work?
Or any expectation when this work should be merged to mainline?

6 months, 2 releases ... or so. We booted it as a university project to maximize the gain.

ok. Sounds good. Do you have any repo somewhere?
I would like to look at it.

Thanks,
Michal

Hi Simon, Wolfgang and others,

just want to open new topic about FDT driver initialization function declaration.

Dear Michal Simek,

Quoted 4 lines

Hi Simon, Wolfgang and others,

just want to open new topic about FDT driver initialization function declaration.

Ok, my few nits (with consideration of the DM stuff) ...
1) Parsing the DTB is slowish

2) The DT can bind nicely with the DM, but if you could investigate further and
help evaluating possible corner cases, that'd help a lot

3) If you could go over the documentation and comment on it, that'd be very nice.

Wolfgang, is it possible to somehow tag the DM patches so we can later collect
these tagged patches to prove we did the amount of work to the university committee? Or maybe simple "dm:" in the subject will suffice.

Best regards,
Marek Vasut

Hi,

Quoted 4 lines · Marek Vasut

Dear Michal Simek,

Quoted 2 lines

Hi Simon, Wolfgang and others,

Quoted 5 lines

Quoted 2 lines

just want to open new topic about FDT driver initialization function declaration.

Ok, my few nits (with consideration of the DM stuff) ...
1) Parsing the DTB is slowish

Yes, particularly early when (for example) the dcache is off and we can't store anything.

One solution may be to have a simple way of picking out things that are needed early, and placing them in a simple C structure. Things like the serial base address (for console_init_f()) might fit this model.

Of course
this needs a tool to do it. But the advantage is that everything is controlled from the fdt but without the performance penalty.

Quoted 3 lines

2) The DT can bind nicely with the DM, but if you could investigate further and
help evaluating possible corner cases, that'd help a lot

I also only just became aware of your tree.

It looks very promising and
looks like it will solve a number of multi-device / initcall issues we have at present.

Quoted 2 lines

3) If you could go over the documentation and comment on it, that'd be very nice.

4) First patches for the DT shall land in next few weeks

Do you mean land in mainline, or just in your tree?

Quoted 7 lines

Wolfgang, is it possible to somehow tag the DM patches so we can later collect
these tagged patches to prove we did the amount of work to the university committee? Or maybe simple "dm:" in the subject will suffice.

Best regards,
Marek Vasut

Regards,
Simon

Wolfgang, is it possible to somehow tag the DM patches so we can later collect these tagged patches to prove we did the amount of work to the university committee? Or maybe simple "dm:" in the subject will suffice.

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:

include/netdev.h +0 -0

index 4724717..96e62ee 100644

include/netdev.h +1 -0

+

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

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?

Thanks for your comments.

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

Hi Michal,

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

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

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,

Quoted 38 lines · Simon Glass

Hi Michal,

On Tue, Jul 10, 2012 at 12:23 PM, Michal Simek <[email protected] <mailto:[email protected]>> 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

Quoted 1 line

I don't think you need the #ifdef here.

Probably not but why not to protect it.

Quoted 19 lines

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

Quoted 1 line

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.

Quoted 9 lines

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.

Quoted 7 lines

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