[U-Boot] [PATCH 01/31] iMX28: Initial support for iMX28 CPU

[Marek Vasut <marek.vasut@gmail.com>]

On Friday, September 09, 2011 12:29:01 PM Stefano Babic wrote:
> On 09/09/2011 12:12 PM, Marek Vasut wrote:
> >> Another general remark here: we tend to have the same structure and the
> >> same files for all IMX SOC. This means that all IMX SOC have a
> >> imx-regs.h that contain the required register definitions (really a
> >> subset what we have in kernel). Is it really necessary to split the
> >> definitions in several small files ?
> > 
> > Just like Heiko said ... it'd produce terribly big and messy file. I'd
> > prefer to avoid that.
> 
> This is ok, and it is ok also that your imx-regs.h file contains only
> the reg-specific include files. What is not ok, is that you do not use
> imx-regs.h and you still includes each separate file. And as I see, they
> must be included in a specific order.

I patched the reg definition files. This should be solved.
> 
> This order must be defined only in imx-regs.h, as you have already done
> and then each driver/board requires to include only imx-regs.h, without
> having to care of the single files.

Ok
> 
> > Honestly, I need to check if the file is used at all. We replaced the
> > original driver with pl011 driver.
> 
> Ok
> 
> >> Again, regarding file splitting for register. If you prefer to have
> >> several files, I think it is better that imx-regs.h include them. Then
> >> we have still a common header imx-regs.h that contains all needed
> >> register definitions. This is a better interface for a board maintainer.
> > 
> > Won't it make the compiler slower at compile time if it has to go through
> > all of the included files instead of a subset ?
> 
> Well, I do not know if on our Intel-PC this makes a so noticeable
> difference ;-)

It's a point-of-view question, really. But what about people compiling stuff on 
slower machines ?

> 
> What I remark here, it is to have a clear and identical interface among
> the several SOCs. This is not only easier for board developers, but also
> removes some nasty #ifdef CONFIG_MX from the drivers.

Yes, I understand. btw there's no CONFIG_MX stuff.

> 
> >> To understand: does a reset mean on the i.MX28 a power off ? Do you turn
> >> off the power ? If this is the case, some features are not possible (as
> >> PRAM, for example) on this SOC.
> > 
> > This should just reset the chip. No poweroff.
> 
> Ok - thanks for clarification.
> 
> > I'll probably wait for someone to clearly say how this should be to avoid
> > reworking it for the fourth time.
> 
> Right.
> 
> Best regards,
> Stefano Babic

Cheers