Patchwork [U-Boot,5/5] microblaze: Wire up fdt emaclite initialization

login
register
mail settings
Submitter Michal Simek
Date June 29, 2012, 7:37 a.m.
Message ID <1340955478-22251-5-git-send-email-monstr@monstr.eu>
Download mbox | patch
Permalink /patch/168011/
State Accepted
Delegated to: Michal Simek
Headers show

Comments

Michal Simek - June 29, 2012, 7:37 a.m.
Call emaclite FDT registration when CONFIG_OF_CONTROL is used.

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 .../xilinx/microblaze-generic/microblaze-generic.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
Stephan Linz - June 29, 2012, 8:22 p.m.
Am Freitag, den 29.06.2012, 09:37 +0200 schrieb Michal Simek: 
> Call emaclite FDT registration when CONFIG_OF_CONTROL is used.
> 
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> ---
>  .../xilinx/microblaze-generic/microblaze-generic.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c b/board/xilinx/microblaze-generic/microblaze-generic.c
> index a1e2bfe..4a719ba 100644
> --- a/board/xilinx/microblaze-generic/microblaze-generic.c
> +++ b/board/xilinx/microblaze-generic/microblaze-generic.c
> @@ -73,6 +73,9 @@ int board_eth_init(bd_t *bis)
>  {
>  	int ret = 0;
>  
> +#ifdef CONFIG_OF_CONTROL
> +	ret |= xilinx_emaclite_init(bis);
> +#else

First of all: I've successful tested on an AXI system on Avnet S6LX9
micro-module.

Now some words to the different configuration strategy. I prefer a
seperation between the ongoing development without device tree support
and the upcoming development with fdt support.

Could you split the development in the context of boards, for example:

OLD: Development w/o fdt in:
  - board/xilinx/microblaze-generic/*
  - configuration in include/configs/microblaze-generic.h

NEW: Development with fdt in:
  - board/xilinx/microblaze-fdt/*
  - configuration in include/configs/microblaze-fdt.h

So you can start with a really clean and slimmed board configuration for
fdt development (especially the content of config header) and the old
generic board support would be retained. Anytime in the future, when the
generic configuration will become obsolete you can remove it.


br,
Stephan

> #ifdef CONFIG_XILINX_AXIEMAC
>  	ret |= xilinx_axiemac_initialize(bis, XILINX_AXIEMAC_BASEADDR,
>  						XILINX_AXIDMA_BASEADDR);
> @@ -125,6 +128,6 @@ int board_eth_init(bd_t *bis)
>  #  endif
>  # endif
>  #endif
> -
> +#endif
>  	return ret;
>  }
Michal Simek - July 3, 2012, 5:23 a.m.
On 06/29/2012 10:22 PM, Stephan Linz wrote:
> Am Freitag, den 29.06.2012, 09:37 +0200 schrieb Michal Simek:
>> Call emaclite FDT registration when CONFIG_OF_CONTROL is used.
>>
>> Signed-off-by: Michal Simek<monstr@monstr.eu>
>> ---
>>   .../xilinx/microblaze-generic/microblaze-generic.c |    5 ++++-
>>   1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c b/board/xilinx/microblaze-generic/microblaze-generic.c
>> index a1e2bfe..4a719ba 100644
>> --- a/board/xilinx/microblaze-generic/microblaze-generic.c
>> +++ b/board/xilinx/microblaze-generic/microblaze-generic.c
>> @@ -73,6 +73,9 @@ int board_eth_init(bd_t *bis)
>>   {
>>   	int ret = 0;
>>
>> +#ifdef CONFIG_OF_CONTROL
>> +	ret |= xilinx_emaclite_init(bis);
>> +#else
>
> First of all: I've successful tested on an AXI system on Avnet S6LX9
> micro-module.
>
> Now some words to the different configuration strategy. I prefer a
> seperation between the ongoing development without device tree support
> and the upcoming development with fdt support.
>
> Could you split the development in the context of boards, for example:
>
> OLD: Development w/o fdt in:
>    - board/xilinx/microblaze-generic/*
>    - configuration in include/configs/microblaze-generic.h
>
> NEW: Development with fdt in:
>    - board/xilinx/microblaze-fdt/*
>    - configuration in include/configs/microblaze-fdt.h
>
> So you can start with a really clean and slimmed board configuration for
> fdt development (especially the content of config header) and the old
> generic board support would be retained. Anytime in the future, when the
> generic configuration will become obsolete you can remove it.

I don't think this is good idea to split it.
All the time when you split development to different trees/configuration they start
to diverge and then you just need to spend more a more time to manage both.

My strategy will be to add both configuration together.
It will have also demonstration purpose to show up differences.

If you want to use two boards you can.

Thanks,
Michal

Patch

diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c b/board/xilinx/microblaze-generic/microblaze-generic.c
index a1e2bfe..4a719ba 100644
--- a/board/xilinx/microblaze-generic/microblaze-generic.c
+++ b/board/xilinx/microblaze-generic/microblaze-generic.c
@@ -73,6 +73,9 @@  int board_eth_init(bd_t *bis)
 {
 	int ret = 0;
 
+#ifdef CONFIG_OF_CONTROL
+	ret |= xilinx_emaclite_init(bis);
+#else
 #ifdef CONFIG_XILINX_AXIEMAC
 	ret |= xilinx_axiemac_initialize(bis, XILINX_AXIEMAC_BASEADDR,
 						XILINX_AXIDMA_BASEADDR);
@@ -125,6 +128,6 @@  int board_eth_init(bd_t *bis)
 #  endif
 # endif
 #endif
-
+#endif
 	return ret;
 }