[U-Boot] FDT driver initialization function declaration

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

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

[U-Boot] FDT driver initialization function declaration

[Wolfgang Denk]

Dear Michal,

In message <4FFC02BD.7060106@monstr.eu> 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The faster I go, the behinder I get.                 -- Lewis Carroll

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

Dear Wolfgang,

On 07/10/2012 01:54 PM, Wolfgang Denk wrote:
> Dear Michal,
>
> In message<4FFC02BD.7060106@monstr.eu>  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.

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


-- 
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] FDT driver initialization function declaration

[Marek Vasut]

Dear Michal Simek,

> Dear Wolfgang,
> 
> On 07/10/2012 01:54 PM, Wolfgang Denk wrote:
> > Dear Michal,
> > 
> > In message<4FFC02BD.7060106@monstr.eu>  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.
> 
> 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?

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

> 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

Best regards,
Marek Vasut

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

On 07/10/2012 03:00 PM, Marek Vasut wrote:
> Dear Michal Simek,
>
>> Dear Wolfgang,
>>
>> On 07/10/2012 01:54 PM, Wolfgang Denk wrote:
>>> Dear Michal,
>>>
>>> In message<4FFC02BD.7060106@monstr.eu>   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.
>>
>> 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?

Move to off topic discussion.

>
>> 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 have downloaded that tree.


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

ok. Let me read it what have you done first.

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

[U-Boot] FDT driver initialization function declaration

[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;
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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Always try to do things in chronological order; it's  less  confusing
that way.

[U-Boot] FDT driver initialization function declaration

[Marek Vasut]

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?

> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

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?

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

-- 
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] FDT driver initialization function declaration

[Marek Vasut]

Dear Michal Simek,

[...]

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

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

> Thanks,
> Michal

Best regards,
Marek Vasut

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

On 07/10/2012 05:08 PM, Marek Vasut wrote:
> Dear Michal Simek,
>
> [...]
>
>>> 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.
>
> But please understand we have some additional special requirements on the driver
> model. We tried to keep it as close as possible though.

Sure but also have a lot of in common.

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

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

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

[U-Boot] [U-Boot-DM] FDT driver initialization function declaration

[Pavel Herrmann]

Hi

On Wednesday 11 of July 2012 11:52:13 Michal Simek wrote:
> 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?

there should be no difference. memory mallocator should switch transparently, 
and each driver should be able to reallocate all its memory (which happens 
between the early and "normal" stage)

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

this part is not complete, we still have to add PnP ids to the driver 
(currently being discussed)

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

cores work as an abstraction of a device type, so anything on a SPI bus will 
not depend on a SPI core, rather the SPI controller will depend on SPI core. 
of course transitive dependencies will occur, because each device will also 
depend on its parent (SPI controller in case of SPI device)

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

platform_data can either be filled statically, or dynamically (in case of PnP, 
FDT). come to think about it, this may cause some problems in the relocation 
stage if the driver_info is in dynamic memory (PnP shouldnt happen at this 
stage, but FDT will)

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

probe() is called when the device is actually being activated (aka just before 
the first use), so the function you should watch for is driver_bind()

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

core will be initialized on-demand, so only the crucial ones will exist in the 
early-init stage

> 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

> Thanks,
> Michal

[U-Boot] [U-Boot-DM] FDT driver initialization function declaration

[Michal Simek]

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

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.

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

[U-Boot] [U-Boot-DM] FDT driver initialization function declaration

[Tomas Hlavacek]

On Thu, Jul 12, 2012 at 10:22 AM, Michal Simek <monstr@monstr.eu> wrote:
>
>
>> 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

-- 
Tom?? Hlav??ek <tmshlvck@gmail.com>

[U-Boot] [U-Boot-DM] FDT driver initialization function declaration

[Marek Vasut]

Dear Tomas Hlavacek,

> On Thu, Jul 12, 2012 at 10:22 AM, Michal Simek <monstr@monstr.eu> wrote:
> >> 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...?

Passed through struct driver_info * which is in turn available through struct 
instance *

> Tomas

Best regards,
Marek Vasut

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

Dear Wolfgang,

On 07/10/2012 03:03 PM, Wolfgang Denk wrote:
> 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;
> 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.

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

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

[U-Boot] FDT driver initialization function declaration

[Marek Vasut]

Dear Michal Simek,

> Dear Wolfgang,
> 
> On 07/10/2012 03:03 PM, Wolfgang Denk wrote:
> > 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;
> > 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.
> 
> 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.

> Thanks,
> Michal

Best regards,
Marek Vasut

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

On 07/10/2012 05:11 PM, Marek Vasut wrote:
> Dear Michal Simek,
>
>> Dear Wolfgang,
>>
>> On 07/10/2012 03:03 PM, Wolfgang Denk wrote:
>>> 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;
>>> 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.
>>
>> 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



-- 
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] FDT driver initialization function declaration

[Marek Vasut]

Dear Michal Simek,

> On 07/10/2012 05:11 PM, Marek Vasut wrote:
> > Dear Michal Simek,
> > 
> >> Dear Wolfgang,
> >> 
> >> On 07/10/2012 03:03 PM, Wolfgang Denk wrote:
> >>> 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;
> >>> 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.
> >> 
> >> 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.

There's not much code yet. As for the docs, see git://git.denx.de/u-boot-
marex.git the "dm" branch

> Thanks,
> Michal

Best regards,
Marek Vasut

[U-Boot] FDT driver initialization function declaration

[Marek Vasut]

Dear Michal Simek,

> 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.
4) First patches for the DT shall land in next few weeks

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

[U-Boot] FDT driver initialization function declaration

[Simon Glass]

Hi,

On Tue, Jul 10, 2012 at 3:05 PM, Marek Vasut <marek.vasut@gmail.com> wrote:

> Dear Michal Simek,
>
> > 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
>

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.


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


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


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

[U-Boot] [U-Boot-DM] FDT driver initialization function declaration

[Marek Vasut]

Dear Simon Glass,

> Hi,
> 
> On Tue, Jul 10, 2012 at 3:05 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Dear Michal Simek,
> > 
> > > 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
> 
> Yes, particularly early when (for example) the dcache is off and we can't
> store anything.

Well if you use DCache as DRAM ... but that's different tale ;-)

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

This smells by global data. And picking them from the DTB is still complicated.

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

Hum, I did send out the email to many people, announcing this.

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

That's the point (right after making my life easier ;-) ). To squash the growing 
number of ad-hoc hacks trying to support multiple devices too.

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

I mean in the mailing list :)
 
> > 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

Best regards,
Marek Vasut

[U-Boot] FDT driver initialization function declaration

[Wolfgang Denk]

Dear Marek,

In message <201207101505.26919.marek.vasut@gmail.com> you wrote:
> 
> 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.

Yes, I recommend to make this simple and efficient - adding something
as "dm:" to the Subject should work just fine.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of all possible committee reactions to any  given  agenda  item,  the
reaction  that will occur is the one which will liberate the greatest
amount of hot air.                                -- Thomas L. Martin

[U-Boot] FDT driver initialization function declaration

[Simon Glass]

Hi Michal,

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


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

Regards,
Simon


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

[U-Boot] FDT driver initialization function declaration

[Michal Simek]

On 07/10/2012 03:18 PM, Simon Glass wrote:
> Hi Michal,
>
> On Tue, Jul 10, 2012 at 12:23 PM, Michal Simek <monstr at 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.


>
>     +
>       /*
>        * 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] FDT driver initialization function declaration

[Simon Glass]

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