LinuxLists.cc - [PATCH v2 00/11] Add Milk-V Pioneer RISC-V board support

2023-09-20 13:56:12

by Chen Wang

Yo,

On Wed, Sep 20, 2023 at 05:08:41PM +0800, Inochi Amaoto wrote:
> >On Wed, Sep 20, 2023 at 02:39:39PM +0800, Chen Wang wrote:
> >> From: Inochi Amaoto <[email protected]>
> >>
> >> Add two new compatible string formatted like `C9xx-clint-xxx` to identify
> >> the timer and ipi device separately, and do not allow c900-clint as the
> >> fallback to avoid conflict.
> >>
> >> Signed-off-by: Inochi Amaoto <[email protected]>
> >> Signed-off-by: Chen Wang <[email protected]>
> >
> >Have you ignored Krzysztof's comments on this? I don't see a response or
> >a reaction to his comments about the compatibles on the last version.
> >Additionally, where is the user for these? I don't see any drivers that
> >actually make use of these.
> >
>
> Sorry for late reply and wrong message-id.
>
> The clint is parsed by sbi.

That needs to go in the commit message.

> As use the same compatible, the opensbi will
> parse the device twice. This will cause a fault.

Then only have one compatible with 2 register ranges? Then your SBI
implementation can use those two register ranges to find out the base
address for the mtimer bits and for the mswi bits.
I don't understand why this cannot be done, could you please explain.
I also don't see anything in the opensbi repo right now that is using
these (nor could I easily see any patches for opensbi adding this).
Is there another SBI implementation that you are using that I can take
a look at to try and understand this better?

> >Why do you need to have 2 compatibles (and therefore 2 devices) for the
> >clint? I thought the clint was a single device, of which the mtimer and
> >mswi bits were just "features"? Having split register ranges isn't a
> >reason to have two compatibles, so I must be missing something here...

> Sorry for late reply, The clint consists of mtimer and ipi devices, which
> is defined in [1].

Yes, I have looked at the spec. I went to check it again before replying
here in case there was something immediately obvious that I was missing.

> This standard shows clint(or the aclint) has two device,

The wording used here doesn't really matter. It's one interrupt
controller that does mtimer and mswi.

> but not one. In another word, there is no need to defined mtimer and ipi
> device on the same base address.

There's also no need to have two compatibles for the same interrupt
controller, so I do not get this reasoning. What actually _requires_
them to be split?

> So we need two compatibles to allow sbi to identify them correctly.

Why is it not sufficient to identify the individual memory regions?

Thanks,
Conor.

Attachments:

(No filename) (2.62 kB)
signature.asc (235.00 B)
Download all attachments

2023-09-20 15:38:26

On Wed, Sep 20, 2023 at 02:39:39PM +0800, Chen Wang wrote:
> From: Inochi Amaoto <[email protected]>
>
> Add two new compatible string formatted like `C9xx-clint-xxx` to identify
> the timer and ipi device separately, and do not allow c900-clint as the
> fallback to avoid conflict.
>
> Signed-off-by: Inochi Amaoto <[email protected]>
> Signed-off-by: Chen Wang <[email protected]>

Have you ignored Krzysztof's comments on this? I don't see a response or
a reaction to his comments about the compatibles on the last version.
Additionally, where is the user for these? I don't see any drivers that
actually make use of these.

Why do you need to have 2 compatibles (and therefore 2 devices) for the
clint? I thought the clint was a single device, of which the mtimer and
mswi bits were just "features"? Having split register ranges isn't a
reason to have two compatibles, so I must be missing something here...

Thanks,
Conor.

> ---
> Documentation/devicetree/bindings/timer/sifive,clint.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> index a0185e15a42f..ae69696c5c75 100644
> --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> @@ -39,6 +39,14 @@ properties:
> - allwinner,sun20i-d1-clint
> - thead,th1520-clint
> - const: thead,c900-clint
> + - items:
> + - enum:
> + - sophgo,sg2042-clint-mtimer
> + - const: thead,c900-clint-mtimer
> + - items:
> + - enum:
> + - sophgo,sg2042-clint-mswi
> + - const: thead,c900-clint-mswi
> - items:
> - const: sifive,clint0
> - const: riscv,clint0
> --
> 2.25.1
>

Attachments:

(No filename) (1.89 kB)
signature.asc (235.00 B)
Download all attachments

2023-09-20 18:49:24

Regards,

unicornx

Conor Dooley <[email protected]> 于2023年9月21日周四 20:18写道：
>
> On Thu, Sep 21, 2023 at 06:21:08PM +0800, Chen Wang wrote:
> > Conor Dooley <[email protected]> 于2023年9月20日周三 16:29写道：
> > > On Wed, Sep 20, 2023 at 02:37:51PM +0800, Chen Wang wrote:
> > > > Add DT binding documentation for the Sophgo SG2042 Soc [1] and the
> > > > Milk-V Pioneer board [2].
> > > >
> > > > [1]: https://en.sophgo.com/product/introduce/sg2042.html
> > > > [2]: https://milkv.io/pioneer
> > >
> > > Again, link tags please.
> > >
> > > > Acked-by: Chao Wei <[email protected]>
> > > > Acked-by: Xiaoguang Xing <[email protected]>
> > > > Signed-off-by: Chen Wang <[email protected]>
> > > > ---
> > > > .../devicetree/bindings/riscv/sophgo.yaml | 28 +++++++++++++++++++
> > > > MAINTAINERS | 7 +++++
> > > > 2 files changed, 35 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/riscv/sophgo.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/riscv/sophgo.yaml b/Documentation/devicetree/bindings/riscv/sophgo.yaml
> > > > new file mode 100644
> > > > index 000000000000..82468ae915db
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/riscv/sophgo.yaml
> > > > @@ -0,0 +1,28 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/riscv/sophgo.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Sophgo SoC-based boards
> > > > +
> > > > +maintainers:
> > > > + - Chao Wei <[email protected]>
> > > > + - Xiaoguang Xing <[email protected]>
> > > > +
> > > > +description:
> > > > + Sophgo SoC-based boards
> > > > +
> > > > +properties:
> > > > + $nodename:
> > > > + const: '/'
> > > > + compatible:
> > > > + oneOf:
> > > > + - items:
> > > > + - enum:
> > > > + - milkv,pioneer
> > > > + - const: sophgo,sg2042
> > > > +
> > > > +additionalProperties: true
> > > > +
> > > > +...
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 90f13281d297..b74d505003e2 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -20063,6 +20063,13 @@ F: drivers/char/sonypi.c
> > > > F: drivers/platform/x86/sony-laptop.c
> > > > F: include/linux/sony-laptop.h
> > > >
> > > > +SOPHGO DEVICETREES
> > > > +M: Xiaoguang Xing <[email protected]>
> > > > +M: Chao Wei <[email protected]>
> > > > +S: Maintained
> > > > +F: Documentation/devicetree/bindings/riscv/sophgo.yaml
> > >
> > > > +F: arch/riscv/boot/dts/sophgo/
> > >
> > > Firstly, this directory does not exist at the time of this patch, so it
> > > should not be added here, but rather at the time that you create it.
> > >
> > > Secondly, are Xiaoguang Xing and Chao Wei going to monitor the lists &
> > > apply patches for these files? If so, you should add a git tree here
> > > that they will apply patches to & add to linux-next. Also, I'd really
> > > like to see some on-list signs of life from these people, otherwise
> > > I'd rather see your name here instead of theirs.
> > >
> > > If they don't intend reviewing/testing/applying patches, I can do it as
> > > a last resort but I would rather that someone who specifically cares for
> > > this hardware does it.
> >
> > Please allow me to explain first. As a community volunteer, I actually
> > had full discussions and testing with Sophgo people when submitting
> > patches, so I added tag such "Acked-by: Xiaoguang Xing ..." to the
> > signature part of most patches. Also if you think a formal email is
> > required, I will talk them to send it.
>
> No, I'm okay with the acks that are on these patches. I just want to
> make sure that those who are acking know why they are & am wondering why
> your name is not there, seeing as you're the one who has submitted these
> patches.
>
> > As for the issue of MAINTAINERS, I discussed it with the people from
> > Sophgo. They (including me also) feel that we are not very familiar
> > with the community process (especially as maintainer, and actually I
> > modify the file MAINTAINERS is just to suppress warning information
> > when running checkpatch.pl), so we sincerely hope to invite you, Mr.
> > Conor,
>
> Oh god, there's no need to call me "Mr. Conor". Conor will do perfectly
> fine!
>
> > to help us for a period of time on maintenance work, including
> > checking relevant patches, merging and submitting PRs, we will learn
> > together with you for a while, and then take over this part of the
> > work when we become familiar with it. We know that you are also very
> > busy at work, especially if you don't have the hardware at hand. I
> > have the hardware here and I can take the responsibility to run
> > testing. What do you think? I'm waiting for your reply. Thanks in
> > advance.
>
> That seems fine to me. In that case, you should add yourself to the
> MAINTAINERS entry.
>
> Thanks,
> Conor.

Okay，I will add it in next revision, thank you again.

2023-09-21 23:57:22

On Fri, Sep 22, 2023 at 01:16:35PM +0800, Inochi Amaoto wrote:

> >> The SiFive CLINT has flexibility related limitations which makes it
> >> not useful for multi-socket and mult-die systems. The SiFive CLINT
> >> is also not useful for systems with AIA because with AIA M-mode has
> >> a new way of doing M-mode IPIs. Due to this reasons, the RISC-V
> >> ACLINT spec breaks down traditional SiFive CLINT into two separate
> >> devices namely mtimer and mswi. This allows platforms to implement
> >> only the required set of devices. The mtimer as defined by the ACLINT
> >> specifications also allows platforms to place mtime and mtimecmp
> >> registers at different locations.
> >>
> >> Refer, https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc
> >>
> >> We need a separate DT bindings document for ACLINT MTIMER
> >> and ACLINT MSWI because these are separate devices. The
> >> Sophgo sg2042 SoC should add their implementation specific
> >> compatible strings in this document.
> >
> >If the spec isn't frozen, I'm not accepting a binding for the "generic"
> >version of it. Bindings for this specific implemtnation are okay.
> >For sure though, squeezing this into the sifive,plic binding isn't
> >appropriate.
> >
>
> It seems I have missed a point. I wonder whether it is better to add a
> "aclint" binding firstly and then add sg2042 to it, or just use sg2042
> specific binding?

sg2042 specific, being frozen is a requirement for merging patches
related to RVI specifications.

> If use "aclint" binding, I wonder it is OK to add
> thead quirks as compatible specific properties, or left this to the SBI to
> handle? e.g. T-HEAD timer is not 64bit timer, and we should identify this.

The compatible string alone should be sufficient to identify the width
of the timer etc.

Thanks,
Conor.

Attachments:

(No filename) (1.81 kB)
signature.asc (235.00 B)
Download all attachments

2023-09-22 11:23:14

Emil Renner Berthing <[email protected]> 于2023年9月22日周五 18:40写道：
>
> Ben Dooks wrote:
> > On 20/09/2023 07:40, Chen Wang wrote:
> > > From: Emil Renner Berthing <[email protected]>
> > >
> > > Add quirk to skip setting the input clock rate for the uarts on the
> > > Sophgo SG2042 SoC similar to the StarFive JH7100.
> >
> > I'd love an actual explanation of why this is necessary here.
>
> Makes sense. For the JH7100 the commit message is:
>
> On the StarFive JH7100 RISC-V SoC the UART core clocks can't be set to
> exactly 16 * 115200Hz and many other common bitrates. Trying this will
> only result in a higher input clock, but low enough that the UART's
> internal divisor can't come close enough to the baud rate target.
> So rather than try to set the input clock it's better to skip the
> clk_set_rate call and rely solely on the UART's internal divisor.
>
> @Chen Wang is this also true for the SG2042?
>
> /Emil

Emil & Ben,
After double-checking with Sophgo engineers and doing more
investigation, we think the original changes(quirk to skip setting the
input clock) on UART may not be required. Due to currently, the
target of this patchset is just to enable a minimal system and no
clock relateding changes are included yet. I will first remove this
quirk change on UART and use the fixed frequence - 500M - and reply
solely on the UART's internal divisor to work. We will re-evaluate
this quirk change in next patchset when we involve clock related
stuff.
Looping Haijiao, engineer from Sophgo, who is working on clock on sg2042.

Regards,
Chen