[U-Boot] FDT driver initialization function declaration
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
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
Dear Wolfgang,
On 07/10/2012 01:54 PM, Wolfgang Denk wrote:
Dear Michal,
In message4FFC02BD.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
Dear Michal Simek,
Dear Wolfgang,
On 07/10/2012 01:54 PM, Wolfgang Denk wrote:
Dear Michal,
In message4FFC02BD.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
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 message4FFC02BD.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
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
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
On 07/10/2012 03:12 PM, Marek Vasut wrote:
Dear Wolfgang Denk,
Dear Michal Simek,
In message4FFC1EF8.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
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
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
On 07/10/2012 03:12 PM, Marek Vasut wrote:
Dear Wolfgang Denk,
Dear Michal Simek,
In message4FFC1EF8.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
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 message4FFC1EF8.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
<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
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
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
Dear Wolfgang,
On 07/10/2012 03:03 PM, Wolfgang Denk wrote:
Dear Michal Simek,
In message4FFC1EF8.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
Dear Michal Simek,
Dear Wolfgang,
On 07/10/2012 03:03 PM, Wolfgang Denk wrote:
Dear Michal Simek,
In message4FFC1EF8.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
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 message4FFC1EF8.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
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 message4FFC1EF8.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
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
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) ...
- 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.
- 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.
- 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
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) ...
- 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.
- 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.
- If you could go over the documentation and comment on it, that'd be
very nice.
- 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
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
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
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); +#endifI 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
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 portedit).
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, intflags, unsigned long ctrl_addr);
+#ifdef CONFIG_OF_CONTROL +int xilinx_emaclite_init(bd_t *bis); +#endifI 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 itsown 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 oneheader 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
participants (7)
-
Marek Vasut -
Marek Vasut -
Michal Simek -
Pavel Herrmann -
Simon Glass -
Tomas Hlavacek -
Wolfgang Denk