Hi, Krzysztof, On Thu, Feb 16, 2023 at 4:10 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > On 16/02/2023 02:46, Binbin Zhou wrote: > > On Tue, Feb 14, 2023 at 8:43 PM Krzysztof Kozlowski > > <krzysztof.kozlowski@xxxxxxxxxx> wrote: > >> > >> On 14/02/2023 13:40, Binbin Zhou wrote: > >>> On Tue, Feb 14, 2023 at 5:53 PM Krzysztof Kozlowski > >>> <krzysztof.kozlowski@xxxxxxxxxx> wrote: > >>>> > >>>> On 13/02/2023 13:15, Binbin Zhou wrote: > >>>>> Add Loongson Extended I/O Interrupt controller binding with DT schema > >>>>> format using json-schema. > >>>>> > >>>>> Signed-off-by: Binbin Zhou <zhoubinbin@xxxxxxxxxxx> > >>>>> --- > >>>>> .../loongson,eiointc.yaml | 80 +++++++++++++++++++ > >>>>> 1 file changed, 80 insertions(+) > >>>>> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml > >>>>> new file mode 100644 > >>>>> index 000000000000..88580297f955 > >>>>> --- /dev/null > >>>>> +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml > >>>>> @@ -0,0 +1,80 @@ > >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>>>> +%YAML 1.2 > >>>>> +--- > >>>>> +$id: "http://devicetree.org/schemas/interrupt-controller/loongson,eiointc.yaml#"; > >>>>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > >>>> > >>>> Drop quotes from bopth. > >>>> > >>>>> + > >>>>> +title: Loongson Extended I/O Interrupt Controller > >>>>> + > >>>>> +maintainers: > >>>>> + - Binbin Zhou <zhoubinbin@xxxxxxxxxxx> > >>>>> + > >>>>> +description: | > >>>>> + This interrupt controller is found on the Loongson-3 family chips and > >>>>> + Loongson-2K0500 chip and is used to distribute interrupts directly to > >>>>> + individual cores without forwarding them through the HT's interrupt line. > >>>>> + > >>>>> +allOf: > >>>>> + - $ref: /schemas/interrupt-controller.yaml# > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + enum: > >>>>> + - loongson,eiointc-1.0 > >>>> > >>>> Why not using SoC based compatible? It is preferred. > >>> > >>> Hi Krzysztof: > >>> > >>> So far, from the datasheet, I know that only the EXIOINTC of the > >>> Loongson-2K0500 is different from the other chips, and that is the > >>> "loongson,eio-num-vecs" below, which is 128, while all the others are > >>> 256. > >>> My original idea was to add this property to make compatible > >>> consistent, and also to make it easier to add new chips if they have > >>> different eio-num-vecs. > >> > >> We talk about different things. SoC based compatibles are preferred over > >> version ones. This was on the lists expressed many times. Please provide > >> a reason why you deviate from general recommendation. Flexibility and > >> genericness of bindings is not a reason - it's the opposite of the > >> argument, thus this will be a: NAK. :( > >> > >> > > Hi Krzysztof: > > > > Allow me to give a brief overview of the current status of eiointc (DT-based): > > Loongson-3A series supports eiointc; > > Loongson-2K1000 does not support eiointc now; > > Loongson-2K0500 supports eiointc, with differences from > > Loongson-3, e.g. only up to 128 devices are supported; > > Loongson-2K2000 supports eiointc, similar to Loongson-3. > > .... > > > > As can be seen, there is now a bit of confusion in the chip's design of eiointc. > > > > The design of eiointc is probably refined step by step with the chip. > > The same version of eiointc can be used for multiple chips, and the > > same chip series may also use different versions of eiointc. Low-end > > chips may use eiointc-2.0, and high-end chips may use eiointc-1.0, > > depending on the time it's produced. > > > > So in the Loongson-2K series I have defined the current state as > > eiointc-1.0, using the dts property to indicate the maximum number of > > devices supported by eiointc that can be used directly in the driver. > > > > If there are new changes to the design later on, such as the > > definition of registers, we can call it eiointc-2.0, which can also > > cover more than one chip. > > Just go with SoC-based compatibles. If your version is not specific > enough, then it is not a good way to represent the hardware. EIOINTC is a bit like the existing LIOINTC which is already use version to represent hardware. Huacai > > Best regards, > Krzysztof >
