Messages in this thread | | | From | Inochi Amaoto <> | Subject | Re: [PATCH v2 06/11] dt-bindings: timer: Add Sophgo sg2042 clint | Date | Fri, 22 Sep 2023 13:16:35 +0800 |
| |
> >On Wed, Sep 20, 2023 at 08:08:49PM +0530, Anup Patel wrote: >> On Wed, Sep 20, 2023 at 6:28 PM Conor Dooley <conor@kernel.org> wrote: >>> >>> On Wed, Sep 20, 2023 at 08:40:07PM +0800, Inochi Amaoto wrote: >>>>> On 20/09/2023 14:15, Inochi Amaoto wrote: >>>>>>> On 20/09/2023 08:39, Chen Wang wrote: >>>>>>>> From: Inochi Amaoto <inochiama@outlook.com> >>>>>>>> >>>>>>>> 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 >>>>>>> >>>>>>> Why? >>>>>>> >>>>>> >>>>>> If use the same compatible, SBI will process this twice in both ipi and >>>>>> timer, use different compatible will allow SBI to treat these as different. >>>>>> AFAIK, the aclint in SBI use the same concepts, which make hard to use the >>>>>> second register range. I have explained in another response. >>>>> >>>>> What is a SBI? Linux driver? If so, why some intermediate Linux driver >>>>> choice should affect bindings? >>>>> Best regards, >>>>> Krzysztof >>>>> >>>> >>>> SBI (Supervisor Binary Interface) is defined by riscv, which is an interface >>>> between the Supervisor Execution Environment (SEE) and the supervisor. The >>>> detailed documentation can be found in [1]. >>>> >>>> The implement of SBI needs fdt info of the platform, which is provided by >>>> kernel. So we need a dt-bindings for these devices, and these will be >>>> processed by SBI. >>>> >>>> [1] https://github.com/riscv-non-isa/riscv-sbi-doc >>> >>> Yeah, this is the unfortunate problem of half-baked bindings (IMO) >>> ending up in OpenSBI (which likely means they also ended up in QEMU). >>> This T-Head stuff is coming across our (metaphorical) desks, so we are >>> obviously going to try to do things correctly. I may end up speaking to >>> Anup later today, if I do I will point him at this thread (if he hasn't >>> seen it already). >> >> RISC-V ACLINT is one of those unfortunate non-ISA specs (like >> SiFive PLIC) which is implemented by various organizations but >> not officially ratified by RVI. > >Yeah, I brought this stuff up at the weekly pw sync call, and Paul >pointed that out. > >> 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? 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.
>What was pointed out, I think by Samuel, that the reason that this may >need to be split is the fact that there are many possible MTIMER >register ranges & possibly sswi stuff too that would need to be >differentiated. > >> >> Regards, >> Anup >
| |