[U-Boot] [PATCH] Add support for TechNexion edm1-cf-imx6 SoM

[Stefano Babic]

Hi Tapani,

On 04/09/2013 13:21, Tapani wrote:

> 
> Are the strict rules written down somewhere, so people less involved in
> u-boot development can read them before submitting?
> 

As far as I know, there is not such documentation ;-(

> 
> Sure, we might do it for the mmdc. But long term maintainable, it is not.
> 
>>> * It is a lot of effort to do struct accessors for huge tables. Both
>>> of IOMUX and MMDC are large (offsets of 0x800+).
>>
>> You forget that for iomuxc the job was already done - there is structure
>> and functions to setup the pinmux.
>>
> 
> You would not accept code using the current iomux structure...

I do not get what you are meaning. Supported boards are using iomux
structures and utility functions to set up the pinmux.

> 
>>> Having struct
>>> accessors would take quite long to enter manually (two tables of 500+ entries 
>>> each, and different between cpu types). This would be hours, if not a day of
>>> braindead work without any tangible benefit.
>>>
>>
>> Sorry, I see benefits in terms of readability and maintenability of the
>> source code and it makes easier to add new boards. This is the reason
>> why there are accessors for iomuxc(), as well as for most SOC's internal
>> controller.
>>
> 
> If making the addition of new boards easier is a goal, there are other parts 
> of the process that are currently a greater hurdle than writing the code. :-)

Well, of course it is an iterative process. We are trying to make
everything better ;-)

> 
> To summarize, we are expected to:
> (i) Create a more general DDR3 API for IMX6, to setup memory chips on any board?

Yes - as the setup of the DDR controller is moving from DCD to code, I
am expecting to reuse that code.

> (ii) Use the above API to redo our already working DDR setup for our board.

Agree.

> (iii) Rewrite the iomux struct(s) to more accurately reflect the iomux memory space. 

Not sure what you are meaning here. If mean what we have discuss before,
that is a way to declare a set of pins independently from the processor
generating then the required setup / tables, yes.

> There is more than plain pinmuxing there. 
> (iv) Rewrite any code that gets broken from changing the iomux struct(s)

Right. If something is changed that breaks boads, we should adapt the
broken boards.

> (v) Use the new struct(s) in setting up memory for our board
> 
> Some of the above might need to be done differently for different cpu variants.

Let's see - we will have to check the single detail.

> 
> We are worried that we might not familiar enough with u-boot development to get 
> such changes accepted in reasonable time.

I do not know what you mean for a reasonable time. Merge window is
closed, that is patchsets adding new features will not be merged in the
next release 2013.10. The next release should be 2013.01, and there are
chances to get them merged.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================