| Message ID | 1447958344-836-18-git-send-email-geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
Hi Geert, Thank you for the patch. On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: > The "renesas,scif" compatible value is currently used for the SCIF > variant in all Renesas SoCs of the R-Car family. However, the variant > used in the R-Car family is not the common "SH-4(A)" variant, but a > derivative with added "Baud Rate Generator for External Clock" (BRG), > which is also present in sh7734. Time to introduce a "renesas,scif-rcar" compatible string ? ;-) As the only DT-enabled platform to have a different SCIF type is r7s72100 we could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's listed after the "renesas,scif- r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh though, but even if that happens due to the J-Core processors I'd be surprised to see the old Renesas SH platforms being moved to DT. > Use the (already documented) SoC-specific SCIF compatible values for all > supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate. The > "renesas,scif" compatible value can still be used as a common > denominator for SCIF variants with the "SH-4(A)" register layout (i.e. > ignoring the "Serial Extension Mode Register" (SCEMR) and the new > BRG-specific registers). > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c > index b0127f38af744fcf..726c96d5a511c222 100644 > --- a/drivers/tty/serial/sh-sci.c > +++ b/drivers/tty/serial/sh-sci.c > @@ -2605,6 +2605,30 @@ static const struct of_device_id of_sci_match[] = { > { > .compatible = "renesas,scif-r7s72100", > .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7778", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7779", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7790", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7791", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7792", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7793", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7794", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > + }, { > + .compatible = "renesas,scif-r8a7795", > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), > }, > /* Generic types */ > {
Hi Laurent, On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: >> The "renesas,scif" compatible value is currently used for the SCIF >> variant in all Renesas SoCs of the R-Car family. However, the variant >> used in the R-Car family is not the common "SH-4(A)" variant, but a >> derivative with added "Baud Rate Generator for External Clock" (BRG), >> which is also present in sh7734. > > Time to introduce a "renesas,scif-rcar" compatible string ? ;-) > > As the only DT-enabled platform to have a different SCIF type is r7s72100 we > could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE > for the generic "renesas,scif" entry as it's listed after the "renesas,scif- > r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh > though, but even if that happens due to the J-Core processors I'd be surprised > to see the old Renesas SH platforms being moved to DT. I thought about that, but you never know in which out-of-tree BSP it ended up being used, too. So better safe than sorry. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote: > On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote: > > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: > >> The "renesas,scif" compatible value is currently used for the SCIF > >> variant in all Renesas SoCs of the R-Car family. However, the variant > >> used in the R-Car family is not the common "SH-4(A)" variant, but a > >> derivative with added "Baud Rate Generator for External Clock" (BRG), > >> which is also present in sh7734. > > > > Time to introduce a "renesas,scif-rcar" compatible string ? ;-) > > > > As the only DT-enabled platform to have a different SCIF type is r7s72100 > > we could also consider just switching the regtype to > > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's > > listed after the "renesas,scif- r7s72100" entry. That might cause an > > issue if we want to enable DT on arch/sh though, but even if that happens > > due to the J-Core processors I'd be surprised to see the old Renesas SH > > platforms being moved to DT. > > I thought about that, but you never know in which out-of-tree BSP it ended > up being used, too. So better safe than sorry. Out-of-tree should be banned :-) More seriously, I suppose you wouldn't be thrilled by the idea of a "renesas,scif-rcar-gen2" ?
Hi Laurent, On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote: >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote: >> > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: >> >> The "renesas,scif" compatible value is currently used for the SCIF >> >> variant in all Renesas SoCs of the R-Car family. However, the variant >> >> used in the R-Car family is not the common "SH-4(A)" variant, but a >> >> derivative with added "Baud Rate Generator for External Clock" (BRG), >> >> which is also present in sh7734. >> > >> > Time to introduce a "renesas,scif-rcar" compatible string ? ;-) >> > >> > As the only DT-enabled platform to have a different SCIF type is r7s72100 >> > we could also consider just switching the regtype to >> > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's >> > listed after the "renesas,scif- r7s72100" entry. That might cause an >> > issue if we want to enable DT on arch/sh though, but even if that happens >> > due to the J-Core processors I'd be surprised to see the old Renesas SH >> > platforms being moved to DT. >> >> I thought about that, but you never know in which out-of-tree BSP it ended >> up being used, too. So better safe than sorry. > > Out-of-tree should be banned :-) > > More seriously, I suppose you wouldn't be thrilled by the idea of a > "renesas,scif-rcar-gen2" ? Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote: > On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote: > > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote: > >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote: > >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: > >>>> The "renesas,scif" compatible value is currently used for the SCIF > >>>> variant in all Renesas SoCs of the R-Car family. However, the variant > >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a > >>>> derivative with added "Baud Rate Generator for External Clock" (BRG), > >>>> which is also present in sh7734. > >>> > >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-) > >>> > >>> As the only DT-enabled platform to have a different SCIF type is > >>> r7s72100 we could also consider just switching the regtype to > >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's > >>> listed after the "renesas,scif- r7s72100" entry. That might cause an > >>> issue if we want to enable DT on arch/sh though, but even if that > >>> happens due to the J-Core processors I'd be surprised to see the old > >>> Renesas SH platforms being moved to DT. > >> > >> I thought about that, but you never know in which out-of-tree BSP it > >> ended up being used, too. So better safe than sorry. > > > > Out-of-tree should be banned :-) > > > > More seriously, I suppose you wouldn't be thrilled by the idea of a > > "renesas,scif-rcar-gen2" ? > > Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734. Yes, but it would at least cover the whole Gen2 family that behaves the same way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat strings only.
On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote: >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote: >> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote: >> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote: >> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: >> >>>> The "renesas,scif" compatible value is currently used for the SCIF >> >>>> variant in all Renesas SoCs of the R-Car family. However, the variant >> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a >> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG), >> >>>> which is also present in sh7734. >> >>> >> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-) >> >>> >> >>> As the only DT-enabled platform to have a different SCIF type is >> >>> r7s72100 we could also consider just switching the regtype to >> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's >> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an >> >>> issue if we want to enable DT on arch/sh though, but even if that >> >>> happens due to the J-Core processors I'd be surprised to see the old >> >>> Renesas SH platforms being moved to DT. >> >> >> >> I thought about that, but you never know in which out-of-tree BSP it >> >> ended up being used, too. So better safe than sorry. >> > >> > Out-of-tree should be banned :-) >> > >> > More seriously, I suppose you wouldn't be thrilled by the idea of a >> > "renesas,scif-rcar-gen2" ? >> >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734. > > Yes, but it would at least cover the whole Gen2 family that behaves the same > way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat > strings only. In light of all the recent "add fallback compatibility strings" patch series from Simon, perhaps I should reconsider, and just match against three (new) family-specific compatible values: "renesas,scif-rcar-gen1" "renesas,scif-rcar-gen2" "renesas,scif-rcar-gen3" instead of the 8 (and more coming) SoC-specific compatible values? Following that scheme means we will have to add many compatible values to the existing dtsis. I.e. every SCIx device node (there are more than 100) will have 3, like scif0: serial@e6e60000 { compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2", "renesas,scif"; Not having the SoC-specific ones in the driver won't cause an issue when using an old DTS with a new kernel: you can't use the new BRG features without adding the extra clocks to the DTS anyway, so you can add the family-specific compatible value when doing that update. Simon, what do you think? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 10, 2015 at 10:21:27AM +0100, Geert Uytterhoeven wrote: > On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote: > >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote: > >> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote: > >> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote: > >> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: > >> >>>> The "renesas,scif" compatible value is currently used for the SCIF > >> >>>> variant in all Renesas SoCs of the R-Car family. However, the variant > >> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a > >> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG), > >> >>>> which is also present in sh7734. > >> >>> > >> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-) > >> >>> > >> >>> As the only DT-enabled platform to have a different SCIF type is > >> >>> r7s72100 we could also consider just switching the regtype to > >> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's > >> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an > >> >>> issue if we want to enable DT on arch/sh though, but even if that > >> >>> happens due to the J-Core processors I'd be surprised to see the old > >> >>> Renesas SH platforms being moved to DT. > >> >> > >> >> I thought about that, but you never know in which out-of-tree BSP it > >> >> ended up being used, too. So better safe than sorry. > >> > > >> > Out-of-tree should be banned :-) > >> > > >> > More seriously, I suppose you wouldn't be thrilled by the idea of a > >> > "renesas,scif-rcar-gen2" ? > >> > >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734. > > > > Yes, but it would at least cover the whole Gen2 family that behaves the same > > way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat > > strings only. > > In light of all the recent "add fallback compatibility strings" patch series > from Simon, perhaps I should reconsider, and just match against three (new) > family-specific compatible values: > > "renesas,scif-rcar-gen1" > "renesas,scif-rcar-gen2" > "renesas,scif-rcar-gen3" > > instead of the 8 (and more coming) SoC-specific compatible values? > > Following that scheme means we will have to add many compatible values > to the existing dtsis. I.e. every SCIx device node (there are more than 100) > will have 3, like > > scif0: serial@e6e60000 { > compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2", > "renesas,scif"; > > Not having the SoC-specific ones in the driver won't cause an issue when using > an old DTS with a new kernel: you can't use the new BRG features without > adding the extra clocks to the DTS anyway, so you can add the family-specific > compatible value when doing that update. > > Simon, what do you think? This sounds good to me. In fact it sounds like the kind of upgrade path that I would like to see in action. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Thursday 10 December 2015 10:21:27 Geert Uytterhoeven wrote: > On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart wrote: > > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote: > >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote: > >>> On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote: > >>>> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote: > >>>>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote: > >>>>>> The "renesas,scif" compatible value is currently used for the SCIF > >>>>>> variant in all Renesas SoCs of the R-Car family. However, the > >>>>>> variant used in the R-Car family is not the common "SH-4(A)" > >>>>>> variant, but a derivative with added "Baud Rate Generator for > >>>>>> External Clock" (BRG), which is also present in sh7734. > >>>>> > >>>>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-) > >>>>> > >>>>> As the only DT-enabled platform to have a different SCIF type is > >>>>> r7s72100 we could also consider just switching the regtype to > >>>>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as > >>>>> it's listed after the "renesas,scif- r7s72100" entry. That might > >>>>> cause an issue if we want to enable DT on arch/sh though, but even if > >>>>> that happens due to the J-Core processors I'd be surprised to see the > >>>>> old Renesas SH platforms being moved to DT. > >>>> > >>>> I thought about that, but you never know in which out-of-tree BSP it > >>>> ended up being used, too. So better safe than sorry. > >>> > >>> Out-of-tree should be banned :-) > >>> > >>> More seriously, I suppose you wouldn't be thrilled by the idea of a > >>> "renesas,scif-rcar-gen2" ? > >> > >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734. > > > > Yes, but it would at least cover the whole Gen2 family that behaves the > > same way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's > > two compat strings only. > > In light of all the recent "add fallback compatibility strings" patch series > from Simon, perhaps I should reconsider, and just match against three (new) > family-specific compatible values: > > "renesas,scif-rcar-gen1" > "renesas,scif-rcar-gen2" > "renesas,scif-rcar-gen3" > > instead of the 8 (and more coming) SoC-specific compatible values? > > Following that scheme means we will have to add many compatible values > to the existing dtsis. I.e. every SCIx device node (there are more than 100) > will have 3, like > > scif0: serial@e6e60000 { > compatible = "renesas,scif-r8a7791", > "renesas,scif-rcar-gen2", "renesas,scif"; > > Not having the SoC-specific ones in the driver won't cause an issue when > using an old DTS with a new kernel: you can't use the new BRG features > without adding the extra clocks to the DTS anyway, so you can add the > family-specific compatible value when doing that update. > > Simon, what do you think? Needless to say I agree :-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index b0127f38af744fcf..726c96d5a511c222 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -2605,6 +2605,30 @@ static const struct of_device_id of_sci_match[] = { { .compatible = "renesas,scif-r7s72100", .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7778", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7779", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7790", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7791", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7792", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7793", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7794", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), + }, { + .compatible = "renesas,scif-r8a7795", + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE), }, /* Generic types */ {
The "renesas,scif" compatible value is currently used for the SCIF variant in all Renesas SoCs of the R-Car family. However, the variant used in the R-Car family is not the common "SH-4(A)" variant, but a derivative with added "Baud Rate Generator for External Clock" (BRG), which is also present in sh7734. Use the (already documented) SoC-specific SCIF compatible values for all supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate. The "renesas,scif" compatible value can still be used as a common denominator for SCIF variants with the "SH-4(A)" register layout (i.e. ignoring the "Serial Extension Mode Register" (SCEMR) and the new BRG-specific registers). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)