[PATCH 1/2] arm: rmobile: Add RZ/G2M SoC

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

On 9/21/20 7:29 PM, Biju Das wrote:

[...]

>> There might be even better way. Look at rmobile_get_cpu_type() , that is a
>> weak function. So if you can implement one for RZG2 , then that function can
>> return CPU_TYPE_RZG2_something ; and rmobile_get_cpu_type() for RZG2
>> can be implemented using the match on /compatible string .
>>
>> Take a look at how arch/arm/mach-rmobile/cpu_info-rcar.c implements it
>> using PRR, you might need cpu_info-rzg.c I think.
> 
> As mentioned in the commit message PRR values of both R-Car M3-W and RZ/G2M are identical. So there is no need for separate cpu_info-rzg.c.
> I believe it is duplication of code.

I wonder whether it wouldn't be easier to simply ignore PRR on RZG
altogether, and simply match on the /compatible string from the DT.

> We are matching PRR first (device binding)  and then use TFA SoC compatible string to differentiate from R-Car family.
> Please see the diff below[3].

I wonder whether we need the PRR matching at all ?

>> Also, I hope there should already be some function to which you provide a
>> compatible string and a table of supported compatible strings (of match
>> table), from which it will return the .data field of the matching entry in that
>> table. And that .data field can already be the CPU_TYPE_RZG_something , so
>> you don't have to implement the table look up again.
>>
>> What do you think ?
> 
> Device binding is important use case, run time you need to match PRR, that is same for both RCar-M3W and RZ/G2E.
> In RZ/G2 case, we miss device binding if just go with TFA compatible Approach. So we need both.
> 
> What do you think?
> 
> [3]
> +static const struct {
> +char *compatible;
> +u16 cpu_type;
> +u8 cpu_name[10];
> +} tfa_cpuinfo[] = {
> +{ "renesas,r8a774a1", RMOBILE_CPU_TYPE_R8A774A1, "R8A774A1" },
> +{ },
> +};

btw Can you please fix your mailer so it doesn't drop indent ? It's real
hard to read the code.

[...]