[PATCH v4 1/2] arm: rmobile: Add PRR CPU ID macros for RZ/G2[HMNE]

[Marek Vasut]

On 10/3/20 9:31 PM, Biju Das wrote:

Hi,

[...]

>>>  /* PRR CPU IDs */
>>>  #define RMOBILE_CPU_TYPE_SH73A00x37
>>>  #define RMOBILE_CPU_TYPE_R8A77400x40
>>> +#define RMOBILE_CPU_TYPE_R8A774A10x52
>>
>> The problem here is that this is the same as
>> #define RMOBILE_CPU_TYPE_R8A7796   0x52
>>
>> So if you use that ^ in the code, you cannot discern it from
>> RMOBILE_CPU_TYPE_R8A774A1 .
> 
> But this value is same as per the hardware manual, see the definitions in linux[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc7#n114
> Please correct me, if this macros are not as per hardware manual.

This is not what I am complaining about. See for example the output of
$ git grep RMOBILE_CPU_TYPE_
...
drivers/mmc/renesas-sdhi.c:     if (((rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A7795) &&
drivers/mmc/renesas-sdhi.c:         ((rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A7796) &&
drivers/net/ravb.c:     if ((rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A77990) ||
drivers/net/ravb.c:         (rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A77995))

These tests will no longer work on RZG as they should (the test to match
on RMOBILE_CPU_TYPE_R8A7796 will also match on RMOBILE_CPU_TYPE_R8A774A1
and that might not be what is expected). So there needs to be some way
to implement match on RZG-only.

So we will need some rmobile_cpu_match(RMOBILE_CPU_TYPE_R8A7796)
function, which will match on 7796 only and if it is called with
RMOBILE_CPU_TYPE_R8A774A1 it will not match (assuming the SoC on which
it is running is 7796).

>> We really need to find a way to tell these two apart first, e.g. by checking the
>> bootrom, and then use it in U-Boot all over the place.
> 
> Yes, I agree we need to differentiate them. Different ways I can think of is
> 
> 1) Bootrom level
> 2) Checking some IP register which is present in RCar and not in RZ/G2

Did you make any progress on these two ?

> 3) Compatible SoC string from TFA

This only shifts the problem into TFA, so now TFA has to figure out a
way to discern RZG and RCar. Surely one can argue that TFA is built for
a specific SoC, so this could be a no-problem.

> 4) TFA there will be separation for RZ/G2 SoC and RCar Gen3 SoC, So populate some dtfragment for RCar/RZG2 SoC similar to dram and u-boot handling it for SoC separation.
> 5) Use compile time macros in U-boot.

No, we worked too hard to make things based purely on DT and get rid of
compile-time macros, so lets not put those back.

> Please let me you know, which is the best way to go forward and also let me know, if you have any other ideas in your mind.

I would highly prefer 1) or 2) if possible.