[10/12] serial: 8250_dw: Add Sophgo SG2042 support

  From: Emil Renner Berthing <emil.renner.berthing@canonical.com>

Add quirk to skip setting the input clock rate for the uarts on the
Sophgo SG2042 SoC similar to the StarFive JH7100.

Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
---
 drivers/tty/serial/8250/8250_dw.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
  

Krzysztof Kozlowski wrote:
> On 15/09/2023 09:25, Wang Chen wrote:
> > From: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> >
> > Add quirk to skip setting the input clock rate for the uarts on the
> > Sophgo SG2042 SoC similar to the StarFive JH7100.
> >
> > Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
>
> Missing SoB.
>
> > ---
> >  drivers/tty/serial/8250/8250_dw.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> > index f4cafca1a7da..6c344877a07f 100644
> > --- a/drivers/tty/serial/8250/8250_dw.c
> > +++ b/drivers/tty/serial/8250/8250_dw.c
> > @@ -770,7 +770,7 @@ static const struct dw8250_platform_data dw8250_renesas_rzn1_data = {
> >  	.quirks = DW_UART_QUIRK_IS_DMA_FC,
> >  };
> >
> > -static const struct dw8250_platform_data dw8250_starfive_jh7100_data = {
> > +static const struct dw8250_platform_data dw8250_skip_set_rate_data = {
>
> Why? What is wrong with old name?
>
> >  	.usr_reg = DW_UART_USR,
> >  	.quirks = DW_UART_QUIRK_SKIP_SET_RATE,
> >  };
> > @@ -780,7 +780,8 @@ static const struct of_device_id dw8250_of_match[] = {
> >  	{ .compatible = "cavium,octeon-3860-uart", .data = &dw8250_octeon_3860_data },
> >  	{ .compatible = "marvell,armada-38x-uart", .data = &dw8250_armada_38x_data },
> >  	{ .compatible = "renesas,rzn1-uart", .data = &dw8250_renesas_rzn1_data },
> > -	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_starfive_jh7100_data },
> > +	{ .compatible = "sophgo,sg2042-uart", .data = &dw8250_skip_set_rate_data },
> > +	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_skip_set_rate_data },
>
> So devices are fully compatible? Then use compatibility and drop this
> patch entirely.

I'm fine with this, but these are two different companies and SoCs that just
happens to have both implemented the Designware UART with an inflexible input
clock. So if fx. a real quirk is found on the JH7110 then we'd need to either
change the compatible on an unrelated SoC or change compatible on the JH7110 to
something like "starfive,jh7100-uart-with-quirk" and "starfive,jh7100-uart" will
forever be a quirky way to spell "dw8250 with inflexible input clock".
Is that how device trees are supposed to work?

/Emil
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
  

On 15/09/2023 12:02, Emil Renner Berthing wrote:
> Krzysztof Kozlowski wrote:
>> On 15/09/2023 09:25, Wang Chen wrote:
>>> From: Emil Renner Berthing <emil.renner.berthing@canonical.com>
>>>
>>> Add quirk to skip setting the input clock rate for the uarts on the
>>> Sophgo SG2042 SoC similar to the StarFive JH7100.
>>>
>>> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
>>
>> Missing SoB.
>>
>>> ---
>>>  drivers/tty/serial/8250/8250_dw.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
>>> index f4cafca1a7da..6c344877a07f 100644
>>> --- a/drivers/tty/serial/8250/8250_dw.c
>>> +++ b/drivers/tty/serial/8250/8250_dw.c
>>> @@ -770,7 +770,7 @@ static const struct dw8250_platform_data dw8250_renesas_rzn1_data = {
>>>  	.quirks = DW_UART_QUIRK_IS_DMA_FC,
>>>  };
>>>
>>> -static const struct dw8250_platform_data dw8250_starfive_jh7100_data = {
>>> +static const struct dw8250_platform_data dw8250_skip_set_rate_data = {
>>
>> Why? What is wrong with old name?
>>
>>>  	.usr_reg = DW_UART_USR,
>>>  	.quirks = DW_UART_QUIRK_SKIP_SET_RATE,
>>>  };
>>> @@ -780,7 +780,8 @@ static const struct of_device_id dw8250_of_match[] = {
>>>  	{ .compatible = "cavium,octeon-3860-uart", .data = &dw8250_octeon_3860_data },
>>>  	{ .compatible = "marvell,armada-38x-uart", .data = &dw8250_armada_38x_data },
>>>  	{ .compatible = "renesas,rzn1-uart", .data = &dw8250_renesas_rzn1_data },
>>> -	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_starfive_jh7100_data },
>>> +	{ .compatible = "sophgo,sg2042-uart", .data = &dw8250_skip_set_rate_data },
>>> +	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_skip_set_rate_data },
>>
>> So devices are fully compatible? Then use compatibility and drop this
>> patch entirely.
> 
> I'm fine with this, but these are two different companies and SoCs that just
> happens to have both implemented the Designware UART with an inflexible input
> clock. So if fx. a real quirk is found on the JH7110 then we'd need to either
> change the compatible on an unrelated SoC or change compatible on the JH7110 to

Wait, why? The compatible is still there, so you just add here proper
entry, if ever needed.

> something like "starfive,jh7100-uart-with-quirk" and "starfive,jh7100-uart" will
> forever be a quirky way to spell "dw8250 with inflexible input clock".
> Is that how device trees are supposed to work?

I don't get this part. But anyway if the blocks are really designed or
done independently and there is no shared part, except the DWC block,
then indeed the compatibility might be just a coincidence...



Best regards,
Krzysztof
  

Krzysztof Kozlowski wrote:
> On 15/09/2023 12:02, Emil Renner Berthing wrote:
> > Krzysztof Kozlowski wrote:
> >> On 15/09/2023 09:25, Wang Chen wrote:
> >>> From: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> >>>
> >>> Add quirk to skip setting the input clock rate for the uarts on the
> >>> Sophgo SG2042 SoC similar to the StarFive JH7100.
> >>>
> >>> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> >>
> >> Missing SoB.
> >>
> >>> ---
> >>>  drivers/tty/serial/8250/8250_dw.c | 5 +++--
> >>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> >>> index f4cafca1a7da..6c344877a07f 100644
> >>> --- a/drivers/tty/serial/8250/8250_dw.c
> >>> +++ b/drivers/tty/serial/8250/8250_dw.c
> >>> @@ -770,7 +770,7 @@ static const struct dw8250_platform_data dw8250_renesas_rzn1_data = {
> >>>  	.quirks = DW_UART_QUIRK_IS_DMA_FC,
> >>>  };
> >>>
> >>> -static const struct dw8250_platform_data dw8250_starfive_jh7100_data = {
> >>> +static const struct dw8250_platform_data dw8250_skip_set_rate_data = {
> >>
> >> Why? What is wrong with old name?
> >>
> >>>  	.usr_reg = DW_UART_USR,
> >>>  	.quirks = DW_UART_QUIRK_SKIP_SET_RATE,
> >>>  };
> >>> @@ -780,7 +780,8 @@ static const struct of_device_id dw8250_of_match[] = {
> >>>  	{ .compatible = "cavium,octeon-3860-uart", .data = &dw8250_octeon_3860_data },
> >>>  	{ .compatible = "marvell,armada-38x-uart", .data = &dw8250_armada_38x_data },
> >>>  	{ .compatible = "renesas,rzn1-uart", .data = &dw8250_renesas_rzn1_data },
> >>> -	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_starfive_jh7100_data },
> >>> +	{ .compatible = "sophgo,sg2042-uart", .data = &dw8250_skip_set_rate_data },
> >>> +	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_skip_set_rate_data },
> >>
> >> So devices are fully compatible? Then use compatibility and drop this
> >> patch entirely.
> >
> > I'm fine with this, but these are two different companies and SoCs that just
> > happens to have both implemented the Designware UART with an inflexible input
> > clock. So if fx. a real quirk is found on the JH7110 then we'd need to either
> > change the compatible on an unrelated SoC or change compatible on the JH7110 to
>
> Wait, why? The compatible is still there, so you just add here proper
> entry, if ever needed.

Sorry, I messed up my example by writing JH7110 where I meant JH7100

> > something like "starfive,jh7100-uart-with-quirk" and "starfive,jh7100-uart" will
> > forever be a quirky way to spell "dw8250 with inflexible input clock".
> > Is that how device trees are supposed to work?
>
> I don't get this part. But anyway if the blocks are really designed or
> done independently and there is no shared part, except the DWC block,
> then indeed the compatibility might be just a coincidence...
>

It is. Sophgo and StarFive are not the same company. Sophgo are using RISC-V
cores from T-Head and StarFive are using cores from SiFive. They just happen to
both use the Designware UART in the same way.

/Emil
  

Ben Dooks wrote:
> On 15/09/2023 11:23, Emil Renner Berthing wrote:
> > Krzysztof Kozlowski wrote:
> >> On 15/09/2023 12:02, Emil Renner Berthing wrote:
> >>> Krzysztof Kozlowski wrote:
> >>>> On 15/09/2023 09:25, Wang Chen wrote:
> >>>>> From: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> >>>>>
> >>>>> Add quirk to skip setting the input clock rate for the uarts on the
> >>>>> Sophgo SG2042 SoC similar to the StarFive JH7100.
> >>>>>
> >>>>> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> >>>>
> >>>> Missing SoB.
> >>>>
> >>>>> ---
> >>>>>   drivers/tty/serial/8250/8250_dw.c | 5 +++--
> >>>>>   1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> >>>>> index f4cafca1a7da..6c344877a07f 100644
> >>>>> --- a/drivers/tty/serial/8250/8250_dw.c
> >>>>> +++ b/drivers/tty/serial/8250/8250_dw.c
> >>>>> @@ -770,7 +770,7 @@ static const struct dw8250_platform_data dw8250_renesas_rzn1_data = {
> >>>>>   	.quirks = DW_UART_QUIRK_IS_DMA_FC,
> >>>>>   };
> >>>>>
> >>>>> -static const struct dw8250_platform_data dw8250_starfive_jh7100_data = {
> >>>>> +static const struct dw8250_platform_data dw8250_skip_set_rate_data = {
> >>>>
> >>>> Why? What is wrong with old name?
> >>>>
> >>>>>   	.usr_reg = DW_UART_USR,
> >>>>>   	.quirks = DW_UART_QUIRK_SKIP_SET_RATE,
> >>>>>   };
> >>>>> @@ -780,7 +780,8 @@ static const struct of_device_id dw8250_of_match[] = {
> >>>>>   	{ .compatible = "cavium,octeon-3860-uart", .data = &dw8250_octeon_3860_data },
> >>>>>   	{ .compatible = "marvell,armada-38x-uart", .data = &dw8250_armada_38x_data },
> >>>>>   	{ .compatible = "renesas,rzn1-uart", .data = &dw8250_renesas_rzn1_data },
> >>>>> -	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_starfive_jh7100_data },
> >>>>> +	{ .compatible = "sophgo,sg2042-uart", .data = &dw8250_skip_set_rate_data },
> >>>>> +	{ .compatible = "starfive,jh7100-uart", .data = &dw8250_skip_set_rate_data },
> >>>>
> >>>> So devices are fully compatible? Then use compatibility and drop this
> >>>> patch entirely.
> >>>
> >>> I'm fine with this, but these are two different companies and SoCs that just
> >>> happens to have both implemented the Designware UART with an inflexible input
> >>> clock. So if fx. a real quirk is found on the JH7110 then we'd need to either
> >>> change the compatible on an unrelated SoC or change compatible on the JH7110 to
> >>
> >> Wait, why? The compatible is still there, so you just add here proper
> >> entry, if ever needed.
> >
> > Sorry, I messed up my example by writing JH7110 where I meant JH7100
> >
> >>> something like "starfive,jh7100-uart-with-quirk" and "starfive,jh7100-uart" will
> >>> forever be a quirky way to spell "dw8250 with inflexible input clock".
> >>> Is that how device trees are supposed to work?
> >>
> >> I don't get this part. But anyway if the blocks are really designed or
> >> done independently and there is no shared part, except the DWC block,
> >> then indeed the compatibility might be just a coincidence...
> >>
> >
> > It is. Sophgo and StarFive are not the same company. Sophgo are using RISC-V
> > cores from T-Head and StarFive are using cores from SiFive. They just happen to
> > both use the Designware UART in the same way.
>
> Out of interest, what's the issue with just providing an fixed clock in
> the device tree for these machines?

You mean adding a "fake" fixed clock to the device tree and specify that in the
uart nodes? That would break the clock dependency, so then you'd need to add
some other way to tell the clock framework not to shut down the real clock.

/Emil