Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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@e6e6 {
> 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 :-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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@e6e6 {
> 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 :-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Simon Horman]

On Thu, Dec 10, 2015 at 10:21:27AM +0100, 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@e6e6 {
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

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@e6e6 {
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 -- ge...@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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

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@e6e6 {
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 -- ge...@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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Simon Horman]

On Thu, Dec 10, 2015 at 10:21:27AM +0100, 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@e6e6 {
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

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.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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" ?

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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" ?

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

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.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

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.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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 
> ---
>  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 */
>   {

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Laurent Pinchart]

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 
> ---
>  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 */
>   {

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

[Geert Uytterhoeven]

Hi Laurent,

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.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/