On Mon, Nov 07, 2016 at 10:35:31AM +0100, Geert Uytterhoeven wrote: > On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven > <geert+renesas@xxxxxxxxx> wrote: > > Some Renesas SoCs may exist in different revisions, providing slightly > > different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior > > (errate and quirks). This needs to be catered for by drivers and/or > > platform code. The recently proposed soc_device_match() API seems like > > a good fit to handle this. > > > > This patch series implements the core infrastructure to provide SoC and > > revision information through the SoC bus for Renesas ARM SoCs. It > > consists of 7 patches: > > - Patches 1-4 provide soc_device_match(), with some related fixes, > > - Patches 5-7 implement identification of Renesas SoCs and > > registration with the SoC bus, > > > > Changes compared to v1: > > - Add Acked-by, > > - New patches: > > - "[4/7] base: soc: Provide a dummy implementation of > > soc_device_match()", > > - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR", > > - "[6/7] arm64: dts: r8a7795: Add device node for PRR" > > (more similar patches available, I'm not yet spamming you all > > with them), > > - Drop SoC families and family names; use fixed "Renesas" instead, > > - Drop EMEV2, which doesn't have a chip ID register, and doesn't share > > devices with other SoCs, > > - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for > > M1A: not accessible from the ARM core?), > > - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols > > for SoCs that provide a chip ID register, > > - Build renesas-soc only if SOC_BUS is enabled, > > - Use "renesas,prr" and "renesas,cccr" device nodes in DT if > > available, else fall back to hardcoded addresses for compatibility > > with existing DTBs, > > - Remove verification of product IDs; just print the ID instead, > > - Don't register the SoC bus if the chip ID register is missing, > > - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has > > both). > > > > Merge strategy: > > - In theory, patches 1-4 should go through Greg's driver core tree. > > But it's a hard dependency for all users. > > If people agree, I can provide an immutable branch in my > > renesas-drivers repository, to be merged by all interested parties. > > So far I'm aware of Freescale/NXP, and Renesas. > > And Samsung. Yes, I would need it as well. > Shall I create the immutable branch now? ...or the applying person could provide one. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
