On 30.08.2013, at 16:00, Andreas Färber wrote:
> Am 30.08.2013 15:54, schrieb Alexander Graf:
>>
>> On 30.08.2013, at 08:05, Alexey Kardashevskiy wrote:
>>
>>> On 08/29/2013 03:30 PM, Andreas Färber wrote:
>>>> Am 29.08.2013 06:29, schrieb Alexey Kardashevskiy:
>>>>> On 08/16/2013 08:35 AM, Andreas Färber wrote:
>>>>>> Instead of relying on cpu_model, obtain the device tree node label
>>>>>> per CPU. Use DeviceClass::fw_name when available. This implicitly
>>>>>> resolves HOST@0 node labels for those CPUs through inheritance.
>>>>>>
>>>>>> Whenever DeviceClass::fw_name is not available, derive it from the CPU's
>>>>>> type name and fill it in for that class with a "PowerPC," prefix for
>>>>>> PAPR compliance.
>>>>>
>>>>>
>>>>> I'd rather use the family's @desc instead of CPU class name, would be
>>>>> simpler and we would not have nodes like "PowerPC,POWER7-family@0" (this
>>>>> is
>>>>> what I get when comment out dc->fw_name for power7 with my PVR patch, just
>>>>> to test).
>>>>
>>>> Negative, desc is a free-text field and may contain spaces, parenthesis,
>>>> etc. Each model may set desc differently btw, so given my change request
>>>> for the comparison, we might end up with "POWER7 v2.1" on that
>>>> particular PVR.
>>>
>>> These patches are for spapr and spapr-supported CPUs have short nice names
>>> in @desc. But ok, may be that's a wrong idea.
>>>
>>>
>>>>> Either way, in what case do you expect that code to work at all? power7,
>>>>> 7+, 8 have fw_name field initialized, what else is really supported for
>>>>> spapr and requires this workaround?
>>>>
>>>> 970 comes to mind? Anyway, this was just a more direct way to address
>>>> the issues raised by Prerna. If you guys don't see the need to enforce
>>>> these naming rules beyond a supported list of POWER CPUs then we can
>>>> strip it down further, possibly falling back to a fixed
>>>> "PowerPC,UNKNOWN" rather than trying to construct a name.
>>>
>>>
>>> The direct way would be to finish what the series started and assign
>>> reasonable fw_name values to every existing family class (970, cell,
>>> power6, rs64?).
>>
>> I agree :). Then there's no need for magic fw_name generation anymore and we
>> have a very obvious code path, making the code simple.
>>
>>> There is very limited set of spapr CPU families, they are all there (except
>>> power7+ but I'll have a patch for that too) and new CPU family will require
>>> a new class anyway (so we will put fw_name there when we'll be adding the
>>> class) OR we implement "compatibility mode" which will use one of existing
>>> classes so we get a correct fw_name either way.
>>
>> Well, I think it makes sense to always provide a fw_name field, regardless
>> of whether that particular CPU works with sPAPR or not. We could use the
>> same field for ePAPR too for example.
>
> So does ePAPR have the same or similar naming rules? Could you supply us
> with verified e500 etc. names so that it's not pure speculation on my part?
I don't see any rules on the cpu node naming in ePAPR, but if I look at the
variety of namings in Linux's dts's I don't think we have to worry overly much,
as long as we keep the names simple. I think in almost all cases
sub-powerpc-class_name == fw_name is a pretty reasonable assumption.
Alex
kvm $ grep -R PowerPC arch/powerpc/boot/dts | sed -n 's/.*PowerPC,\(.*\)
{/\1/p' | sort | uniq5121@0
5125@0
5200@0
603e /* Really 8241 */
7447
7448@0
750CL@0
8241@0
8247@0
8248@0
8272@0
8308@0
8313@0
8315@0
8323@0
8347@0
8349@0
8360@0
8377@0
8378@0
8379@0
8536@0
8540@0
8541@0
8544@0
8548@0
8555@0
8560@0
8568@0
8569@0
8572@0
8572@1
860@0
8610@0
8641@0
8641@1
866@0
875@0
885@0
broadway@0
BSC9131@0
e500mc@0
e500mc@1
e500mc@2
e500mc@3
e500mc@4
e500mc@5
e500mc@6
e500mc@7
e5500@0
e5500@1
e5500@2
e5500@3
e6500@0
e6500@10
e6500@12
e6500@14
e6500@16
e6500@18
e6500@2
e6500@20
e6500@22
e6500@4
e6500@6
e6500@8
gekko@0
P1010@0
P1020@0
P1020@1
P1021@0
P1021@1
P1022@0
P1022@1
P1023@0
P1023@1
P2020@0
P2020@1
