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

[Ryan Mallon]

On 04/29/2011 11:24 AM, Ryan Mallon wrote:
> On 04/29/2011 11:06 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 08:20 Fri 29 Apr     , Ryan Mallon wrote:
>>> On 04/29/2011 02:10 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> On 16:04 Thu 28 Apr     , Andrew Victor wrote:
>>>>> hi,
>>>>>
>>>>>>> If this eventually reduces code size then I think it is useful, but
>>>>>>> otherwise I'm not sure I see the point?
>>>>>> It's on purpose as the dbgu physical address is not at the same place
>>>>>> so read the other register really does not impact the chip but if we do it
>>>>>> later duting the boot or the life to the kernel it's an other story
>>>>>>
>>>>>> so the split between __cpu_is and cpu_is is necessarly
>>>>>>
>>>>>> all of this work is in preparation to allow multiple soc in the same kernel
>>>>>> that's also why I map the system controller the same way on all at91 arm9
>>>>>
>>>>> The cpu_is() or__cpu_is() perform a at91_sys_read() of one of the DBGU
>>>>> registers.
>>>>>
>>>>> But the address of the DBGU differs between CPUs regardless if you map
>>>>> the system controller the same:
>>>>>    at572d940hf.h:#define AT91_DBGU	(0xfffff200 - AT91_BASE_SYS)
>>>>>    at91cap9.h:#define AT91_DBGU	(0xffffee00 - AT91_BASE_SYS)
>>>>>    at91rm9200.h:#define AT91_DBGU	(0xfffff200 - AT91_BASE_SYS)
>>>>>    at91sam9260.h:#define AT91_DBGU	(0xfffff200 - AT91_BASE_SYS)
>>>>>    at91sam9261.h:#define AT91_DBGU	(0xfffff200 - AT91_BASE_SYS)
>>>>>    at91sam9263.h:#define AT91_DBGU	(0xffffee00 - AT91_BASE_SYS)
>>>>>    at91sam9g45.h:#define AT91_DBGU	(0xffffee00 - AT91_BASE_SYS)
>>>>>    at91sam9rl.h:#define AT91_DBGU	(0xfffff200 - AT91_BASE_SYS)
>>>>>
>>>>> So I don't see how you can "detect" the CPU without first knowing
>>>>> which CPU and therefore where the DBGU register is anyway.
>>>>> And probing different addresses for a value is not an acceptable solution.
>>>>>
>>>>>
>>>>> While having a single kernel image that supports AT91 processors is a
>>>>> good goal, the soc.h is a totally unnecessary complication.
>>>>> I can't think of any situation where an AT91 board.c file doesn't know
>>>>> what processor it has.
>>>>>
>>>>> So instead of :
>>>>>    boardXYZ-init ->  at91_initialize() --> magic-cpu-detection -->
>>>>> at91XX_initialize()
>>>>> just do:
>>>>>    boardXYZ-init  -> at91XX_initialize()
>>>> except there is no need to known it and board seach as the usb-926x are the
>>>> same nearly and do not need to known on which soc they are
>>>>
>>>> ditto for other boards you do not need to known the soc we are on.
>>>> And when you work on CPU module the board is the same but not the cpu on the
>>>> module so detect the SOC allow to have one kernel for all and not multiple
>>>> machine ID for each module and board combination
>>>
>>> I Agree with Andrew. When can determine everything we need from the
>>> mach-type. For boards such as the usb-926x we have two separate
>>> mach-types for the 9263 and the 9260 variants. The init_machine callback
>>> can be separated in this case so that both of the boards initialise the
>>> correct cpu type.
>> I do work on board where is the case and I do not want to keep the limitation
>> and yes I'll put them mainline
>>
>> And Russell will not accept I'll create 10 or 20 machine ID for board / cpu
>> module combinaison just because of different I do not detect the SOC type
>>
>> so I'll continue to detect the soc
> 
> How? It has been pointed out that there is no way that this can be
> reliably done if you have all of the at91 socs built into a single
> kernel. You cannot know where the DBGU registers are to read determine
> the cpu/soc type.
> 
> The most reliable way to do this, which also requires the least code, is
> to have the boards explicitly specify which cpu/soc type they are. In
> this case most of the cpu detection code can be removed. Only the minor
> variant (i.e. 9260/9G20) detection code would need to remain.

Having another look at this, the cpu detection is already fine. For
example, board-snapper9260.c calls at91sam9260_initialize, which in turn
determines whether the soc is a 9xe, 9260, or 9g20 and does the
appropriate intialisation. This all works fine because the three socs
have the same DBGU location.

There are other obstacles to having a single kernel for all of AT91, in
particular the big ifdef switch in include/mach/hardware.h and the whole
AT91_BASE_SYS thing, but the cpu/soc detection should not actually need
to be modified.

Lets fix the other problems first.

~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