| Message ID | cover.1704726960.git.geert+renesas@glider.be |
|---|---|
| Headers | show |
| Series | arm64: renesas: Add R-Car V4M and Gray Hawk Single support | expand |
Hi Krzysztof, On Tue, Jan 9, 2024 at 8:21 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 08/01/2024 16:33, Geert Uytterhoeven wrote: > > From: Duy Nguyen <duy.nguyen.rh@renesas.com> > > > > Add all Clock Pulse Generator Core Clock Outputs for the Renesas R-Car > > V4M (R8A779H0) SoC. > > > > Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> > > Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > --- > > Changes compared to the BSP: > > - Drop POST* clocks, as they are internal clocks. > > --- > > include/dt-bindings/clock/r8a779h0-cpg-mssr.h | 96 +++++++++++++++++++ > > Mediatek was able to switch to vendor,device naming scheme, so Renesas > should follow as well. For new bindings, or also for existing ones? Doing the former means there are inconsistencies among different SoCs in the same family. Doing the latter requires keeping the existing header files as wrappers including the new header files, because the binding definitions are part of the stable DT API. Thanks! Gr{oetje,eeting}s, Geert
On 15/01/2024 10:27, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Tue, Jan 9, 2024 at 8:21 PM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> On 08/01/2024 16:33, Geert Uytterhoeven wrote: >>> From: Duy Nguyen <duy.nguyen.rh@renesas.com> >>> >>> Add all Clock Pulse Generator Core Clock Outputs for the Renesas R-Car >>> V4M (R8A779H0) SoC. >>> >>> Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> >>> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> >>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >>> --- >>> Changes compared to the BSP: >>> - Drop POST* clocks, as they are internal clocks. >>> --- >>> include/dt-bindings/clock/r8a779h0-cpg-mssr.h | 96 +++++++++++++++++++ >> >> Mediatek was able to switch to vendor,device naming scheme, so Renesas >> should follow as well. > > For new bindings, or also for existing ones? > Doing the former means there are inconsistencies among different SoCs > in the same family. For the new ones. It's just naming inconsistency which does not cause any issues. Otherwise you never move to vendor,device.h format... which is not that critical, but in the long term brings uniformity. > Doing the latter requires keeping the existing header files as wrappers > including the new header files, because the binding definitions are > part of the stable DT API. This could also work if you want all the filenames to be consistent. I would go only with new ones, though. Best regards, Krzysztof
- trimmed cc-list On Mon, 8 Jan 2024 at 16:34, Geert Uytterhoeven <geert+renesas@glider.be> wrote: > > From: Duy Nguyen <duy.nguyen.rh@renesas.com> > > Add support for R-Car V4M (R8A779H0) SoC power areas to the R-Car SYSC > driver. > > Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> To make sure we agree on the merge strategy; should I pick up $subject patch, patch3 and patch4 through my pmdomain tree? DT patches, like patch3 and patch4, I should share as usual via my immutable "dt" branch, so you can pull it into your renesas tree? Kind regards Uffe > --- > Changes compared to the BSP: > - Move from drivers/soc/renesas/ to drivers/pmdomain/renesas/, > - Include rcar-gen4-sysc glue from "soc: renesas: rcar-gen4-sysc: > Introduce R-Car Gen4 SYSC driver", > - Remove unneeded includes, > - Align second column, > - Fix names of "a33dga" and "a23dgb" domains, > - Add missing "a3cr[012]" domains. > --- > drivers/pmdomain/renesas/Kconfig | 4 ++ > drivers/pmdomain/renesas/Makefile | 1 + > drivers/pmdomain/renesas/r8a779h0-sysc.c | 55 +++++++++++++++++++++++ > drivers/pmdomain/renesas/rcar-gen4-sysc.c | 3 ++ > drivers/pmdomain/renesas/rcar-gen4-sysc.h | 1 + > 5 files changed, 64 insertions(+) > create mode 100644 drivers/pmdomain/renesas/r8a779h0-sysc.c > > diff --git a/drivers/pmdomain/renesas/Kconfig b/drivers/pmdomain/renesas/Kconfig > index 80bf2cf8b60e6f63..54acb4b1ec7c4892 100644 > --- a/drivers/pmdomain/renesas/Kconfig > +++ b/drivers/pmdomain/renesas/Kconfig > @@ -71,6 +71,10 @@ config SYSC_R8A779G0 > bool "System Controller support for R-Car V4H" if COMPILE_TEST > select SYSC_RCAR_GEN4 > > +config SYSC_R8A779H0 > + bool "System Controller support for R-Car V4M" if COMPILE_TEST > + select SYSC_RCAR_GEN4 > + > config SYSC_RMOBILE > bool "System Controller support for R-Mobile" if COMPILE_TEST > > diff --git a/drivers/pmdomain/renesas/Makefile b/drivers/pmdomain/renesas/Makefile > index e306e396fc8c10e3..89180f19c23be732 100644 > --- a/drivers/pmdomain/renesas/Makefile > +++ b/drivers/pmdomain/renesas/Makefile > @@ -24,6 +24,7 @@ obj-$(CONFIG_SYSC_R8A77995) += r8a77995-sysc.o > obj-$(CONFIG_SYSC_R8A779A0) += r8a779a0-sysc.o > obj-$(CONFIG_SYSC_R8A779F0) += r8a779f0-sysc.o > obj-$(CONFIG_SYSC_R8A779G0) += r8a779g0-sysc.o > +obj-$(CONFIG_SYSC_R8A779H0) += r8a779h0-sysc.o > # Family > obj-$(CONFIG_SYSC_RCAR) += rcar-sysc.o > obj-$(CONFIG_SYSC_RCAR_GEN4) += rcar-gen4-sysc.o > diff --git a/drivers/pmdomain/renesas/r8a779h0-sysc.c b/drivers/pmdomain/renesas/r8a779h0-sysc.c > new file mode 100644 > index 0000000000000000..bf3fd50dc8dccaf0 > --- /dev/null > +++ b/drivers/pmdomain/renesas/r8a779h0-sysc.c > @@ -0,0 +1,55 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Renesas R-Car V4M System Controller > + * > + * Copyright (C) 2016-2017 Glider bvba > + * Copyright (C) 2023 Renesas Electronics Corp > + */ > + > +#include <linux/kernel.h> > + > +#include <dt-bindings/power/r8a779h0-sysc.h> > + > +#include "rcar-gen4-sysc.h" > + > +static struct rcar_gen4_sysc_area r8a779h0_areas[] __initdata = { > + { "always-on", R8A779H0_PD_ALWAYS_ON, -1, PD_ALWAYS_ON }, > + { "c4", R8A779H0_PD_C4, R8A779H0_PD_ALWAYS_ON }, > + { "a2e0d0", R8A779H0_PD_A2E0D0, R8A779H0_PD_C4, PD_SCU }, > + { "a1e0d0c0", R8A779H0_PD_A1E0D0C0, R8A779H0_PD_A2E0D0, PD_CPU_NOCR }, > + { "a1e0d0c1", R8A779H0_PD_A1E0D0C1, R8A779H0_PD_A2E0D0, PD_CPU_NOCR }, > + { "a1e0d0c2", R8A779H0_PD_A1E0D0C2, R8A779H0_PD_A2E0D0, PD_CPU_NOCR }, > + { "a1e0d0c3", R8A779H0_PD_A1E0D0C3, R8A779H0_PD_A2E0D0, PD_CPU_NOCR }, > + { "a3cr0", R8A779H0_PD_A3CR0, R8A779H0_PD_ALWAYS_ON, PD_CPU_NOCR }, > + { "a3cr1", R8A779H0_PD_A3CR1, R8A779H0_PD_ALWAYS_ON, PD_CPU_NOCR }, > + { "a3cr2", R8A779H0_PD_A3CR2, R8A779H0_PD_ALWAYS_ON, PD_CPU_NOCR }, > + { "a33dga", R8A779H0_PD_A33DGA, R8A779H0_PD_C4 }, > + { "a23dgb", R8A779H0_PD_A23DGB, R8A779H0_PD_A33DGA }, > + { "a3vip0", R8A779H0_PD_A3VIP0, R8A779H0_PD_C4 }, > + { "a3vip2", R8A779H0_PD_A3VIP2, R8A779H0_PD_C4 }, > + { "a3dul", R8A779H0_PD_A3DUL, R8A779H0_PD_C4 }, > + { "a3isp0", R8A779H0_PD_A3ISP0, R8A779H0_PD_C4 }, > + { "a2cn0", R8A779H0_PD_A2CN0, R8A779H0_PD_C4 }, > + { "a1cn0", R8A779H0_PD_A1CN0, R8A779H0_PD_A2CN0 }, > + { "a1dsp0", R8A779H0_PD_A1DSP0, R8A779H0_PD_A2CN0 }, > + { "a1dsp1", R8A779H0_PD_A1DSP1, R8A779H0_PD_A2CN0 }, > + { "a2imp01", R8A779H0_PD_A2IMP01, R8A779H0_PD_C4 }, > + { "a2psc", R8A779H0_PD_A2PSC, R8A779H0_PD_C4 }, > + { "a2dma", R8A779H0_PD_A2DMA, R8A779H0_PD_C4 }, > + { "a2cv0", R8A779H0_PD_A2CV0, R8A779H0_PD_C4 }, > + { "a2cv1", R8A779H0_PD_A2CV1, R8A779H0_PD_C4 }, > + { "a2cv2", R8A779H0_PD_A2CV2, R8A779H0_PD_C4 }, > + { "a2cv3", R8A779H0_PD_A2CV3, R8A779H0_PD_C4 }, > + { "a3imr0", R8A779H0_PD_A3IMR0, R8A779H0_PD_C4 }, > + { "a3imr1", R8A779H0_PD_A3IMR1, R8A779H0_PD_C4 }, > + { "a3imr2", R8A779H0_PD_A3IMR2, R8A779H0_PD_C4 }, > + { "a3imr3", R8A779H0_PD_A3IMR3, R8A779H0_PD_C4 }, > + { "a3vc", R8A779H0_PD_A3VC, R8A779H0_PD_C4 }, > + { "a3pci", R8A779H0_PD_A3PCI, R8A779H0_PD_C4 }, > + { "a2pciphy", R8A779H0_PD_A2PCIPHY, R8A779H0_PD_A3PCI }, > +}; > + > +const struct rcar_gen4_sysc_info r8a779h0_sysc_info __initconst = { > + .areas = r8a779h0_areas, > + .num_areas = ARRAY_SIZE(r8a779h0_areas), > +}; > diff --git a/drivers/pmdomain/renesas/rcar-gen4-sysc.c b/drivers/pmdomain/renesas/rcar-gen4-sysc.c > index 9e5e6e077abc081c..728248659a97e8cc 100644 > --- a/drivers/pmdomain/renesas/rcar-gen4-sysc.c > +++ b/drivers/pmdomain/renesas/rcar-gen4-sysc.c > @@ -284,6 +284,9 @@ static const struct of_device_id rcar_gen4_sysc_matches[] __initconst = { > #endif > #ifdef CONFIG_SYSC_R8A779G0 > { .compatible = "renesas,r8a779g0-sysc", .data = &r8a779g0_sysc_info }, > +#endif > +#ifdef CONFIG_SYSC_R8A779H0 > + { .compatible = "renesas,r8a779h0-sysc", .data = &r8a779h0_sysc_info }, > #endif > { /* sentinel */ } > }; > diff --git a/drivers/pmdomain/renesas/rcar-gen4-sysc.h b/drivers/pmdomain/renesas/rcar-gen4-sysc.h > index 388cfa8f8f9fd656..fdf843aa51134f87 100644 > --- a/drivers/pmdomain/renesas/rcar-gen4-sysc.h > +++ b/drivers/pmdomain/renesas/rcar-gen4-sysc.h > @@ -40,5 +40,6 @@ struct rcar_gen4_sysc_info { > extern const struct rcar_gen4_sysc_info r8a779a0_sysc_info; > extern const struct rcar_gen4_sysc_info r8a779f0_sysc_info; > extern const struct rcar_gen4_sysc_info r8a779g0_sysc_info; > +extern const struct rcar_gen4_sysc_info r8a779h0_sysc_info; > > #endif /* __SOC_RENESAS_RCAR_GEN4_SYSC_H__ */ > -- > 2.34.1 >
Hi Ulf, On Mon, Jan 15, 2024 at 5:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > - trimmed cc-list CC krzk ;-) > On Mon, 8 Jan 2024 at 16:34, Geert Uytterhoeven <geert+renesas@glider.be> wrote: > > From: Duy Nguyen <duy.nguyen.rh@renesas.com> > > > > Add support for R-Car V4M (R8A779H0) SoC power areas to the R-Car SYSC > > driver. > > > > Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > > To make sure we agree on the merge strategy; should I pick up $subject > patch, patch3 and patch4 through my pmdomain tree? DT patches, like > patch3 and patch4, I should share as usual via my immutable "dt" > branch, so you can pull it into your renesas tree? Thanks, that would be great! However, please note that Krzysztof wants me to add a vendor-prefix to DT binding definition files[1], so there will be a v2. [1] include/dt-bindings/power/r8a779h0-sysc.h Gr{oetje,eeting}s, Geert
> > For new bindings, or also for existing ones? > > Doing the former means there are inconsistencies among different SoCs > > in the same family. > > For the new ones. It's just naming inconsistency which does not cause > any issues. Otherwise you never move to vendor,device.h format... which > is not that critical, but in the long term brings uniformity. I haven't reviewed the patch itself, but for the naming scheme I'd suggest to follow Krzysztof's suggestion. If he is OK with this level of uniformity, then all is good, I'd say. Converting existing ones sounds more messy to me.