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.
[...]