From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 22 Sep 2020 15:11:25 +0200 Subject: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC In-Reply-To: References: <20200918160307.14323-1-biju.das.jz@bp.renesas.com> <5fed48d5-95f5-c237-45fa-3b4343f0cf9a@gmail.com> <3c3a7e31-e9b5-0cc9-518f-b3e2c3a11fa3@gmail.com> <583b789e-3c39-f354-a33d-d6ca54ec81ce@gmail.com> Message-ID: <5b95abef-25a2-4271-fcb2-e52a8c521927@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. [...]