[PATCH 05/14] at91: use structure to store the current soc

[Ryan Mallon]

On 05/03/2011 10:06 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> The boards are different. They have a common base pinout, but their
>> peripheral pinouts are different. Multiple mach-types cost nothing and
>> are a well understood part of ARM Linux. Your proposed cpu detection
>> code adds complexity and code, and has zero benefit for any of the
>> boards currently in mainline.
> So we will do an other re-architecture in the few months
> Linus is going to said no
> We do need to stop to do changset again and again just because we don't solve
> the issue at the beginning

Agreed. That is why I am saying that we should focusing on reducing the
size and complexity of AT91 and getting a single kernel working for all
of the at91 boards which are currently in mainline.

>> Carrier boards are a separate issue, and there has not really been a
>> consensus on what the best way to solve the issue of combining system on
>> modules (SoMs) with carrier boards. Should the mach-type belong to the
>> SoM or to the system as a whole (SoM + carrier board)? There is
>> currently a push to get ARM to consolidate on things rather than each
>> sub-architecture doing things its own way.
> Sorry but cpu detection is soc specific

The method for specifying the setup of a system including SoM and
carrier board(s) is not cpu/soc specific and does not necessarily need
to be done via cpu detection. In fact, I think cpu detection is a bad
way to do it.

> hardcode it via machine ID is not good
>> So if you want a way to
>> differentiate carrier boards, then I think that needs to be discussed
>> with other sub-architecture maintainers so that a common approach can be
>> devised. I don't think that cpu detection is a robust solution. Device
>> tree is probably the long-term solution to this.
>>
>> In short, your soc detection patches add additional complexity, but have
>> zero effect on the possibility of supporting all of the current mainline
>> at91 platforms in a single kernel. We need to fix the other barriers to
>> this support first (such as the work Andrew Victor is doing).
> Which can be also simply be knowning the CPU you are on
> 
> If you take a look on other arch they do cpu detection and there is nothing
> wrong about it.

There is nothing wrong with the current solution for at91, yet you are
trying to add code which is confusing (two sets of cpu_is macros) and
adds more lines for something which _already works_.

This argument is getting frustrating. My current objections to this
patch are:

- The current solution (explicitly specifying the soc type) works for
all of the at91 boards currently in mainline.
- It adds two sets of cpu_is macros (second set with __ prefix), which
is confusing and pointless.
- You have implied that the __cpu_is macros will be removed at a later
date. Since they are basically useless now, this is just more code churn
when we are trying to reduce it on ARM.
- The patch as it stands won't work in a unified at91 kernel because the
address of the DBGU registers is different on some at91 platforms.
- By itself this patch adds complexity without fixing anything and
without introducing any functional change.
- There are other barriers to having a unified at91 kernel which need to
be solved first. This patch is trying to jump ahead and solve problems
that don't exist yet.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934