| Message ID | 20250304104434.481429-2-kevin_chen@aspeedtech.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/3] dt-binding: aspeed: Add LPC PCC controller | expand |
On 04/03/2025 11:44, Kevin Chen wrote: > Add dt-bindings for Aspeed for Aspeed LPC POST code capture controller. Please use subject prefixes matching the subsystem. You can get them for example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your patch is touching. For bindings, the preferred subjects are explained here: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters Missing 's'. > > Signed-off-by: Kevin Chen <kevin_chen@aspeedtech.com> > --- > .../devicetree/bindings/mfd/aspeed-lpc.yaml | 36 +++++++++++++++++++ > 1 file changed, 36 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > index 5dfe77aca167..367847bd7e75 100644 > --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > @@ -149,6 +149,35 @@ patternProperties: > - interrupts > - snoop-ports > > + "^lpc-pcc@[0-9a-f]+$": > + type: object > + additionalProperties: false > + > + description: > + The LPC pcc interface allows the BMC to listen on and record the data > + bytes written by the Host to the targeted LPC I/O pots. > + > + properties: > + compatible: > + items: > + - enum: > + - aspeed,ast2600-lpc-pcc > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + pcc-ports: Missing vendor prefix > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: The LPC I/O ports to pcc Description is too vague. Why would we encode I/O ports as some numbers instead of GPIOs for example? If these are ports, why this is not a graph? Missing constraints - min/maxItems, defaults, minimum/maximum etc. > + > + required: > + - compatible > + - interrupts > + - pcc-ports > + > "^uart-routing@[0-9a-f]+$": > $ref: /schemas/soc/aspeed/uart-routing.yaml# > description: The UART routing control under LPC register space > @@ -176,6 +205,13 @@ examples: > #size-cells = <1>; > ranges = <0x0 0x1e789000 0x1000>; > > + lpc_pcc: lpc-pcc@0 { > + compatible = "aspeed,ast2600-lpc-pcc"; > + reg = <0x0 0x140>; > + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; > + pcc-ports = <0x80>; So what 0x80 stands for? Best regards, Krzysztof
> On 04/03/2025 11:44, Kevin Chen wrote: > > Add dt-bindings for Aspeed for Aspeed LPC POST code capture controller. > > Please use subject prefixes matching the subsystem. You can get them for > example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your > patch is touching. For bindings, the preferred subjects are explained here: > https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patch > es.html#i-for-patch-submitters > > Missing 's'. > > > > > Signed-off-by: Kevin Chen <kevin_chen@aspeedtech.com> > > --- > > .../devicetree/bindings/mfd/aspeed-lpc.yaml | 36 > +++++++++++++++++++ > > 1 file changed, 36 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > > b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > > index 5dfe77aca167..367847bd7e75 100644 > > --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > > @@ -149,6 +149,35 @@ patternProperties: > > - interrupts > > - snoop-ports > > > > + "^lpc-pcc@[0-9a-f]+$": > > + type: object > > + additionalProperties: false > > + > > + description: > > + The LPC pcc interface allows the BMC to listen on and record the > data > > + bytes written by the Host to the targeted LPC I/O pots. > > + > > + properties: > > + compatible: > > + items: > > + - enum: > > + - aspeed,ast2600-lpc-pcc > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + pcc-ports: > > Missing vendor prefix OK, so I need to add the vendor prefix such as "aspeed,pcc-ports". Right? But I want to check the snoop-ports usage. In the HW controller, the usage should be the same. Not only aspeed but nuvoton, there exist a HW module for the snoop-ports or pcc-ports usage. > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + description: The LPC I/O ports to pcc > > Description is too vague. Why would we encode I/O ports as some numbers > instead of GPIOs for example? If these are ports, why this is not a graph? For the port-mmaped I/O in x80 architecture, BMC need to handle specific port I/O in the relative HW module. So, I need to add the pcc-ports property as the snoop-ports property in Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > > Missing constraints - min/maxItems, defaults, minimum/maximum etc. The port-mmaped I/O is defined from host, BMC as the device would capture the port I/O from the pcc-ports property defined in dts. > > > + > > + required: > > + - compatible > > + - interrupts > > + - pcc-ports > > + > > "^uart-routing@[0-9a-f]+$": > > $ref: /schemas/soc/aspeed/uart-routing.yaml# > > description: The UART routing control under LPC register space @@ > > -176,6 +205,13 @@ examples: > > #size-cells = <1>; > > ranges = <0x0 0x1e789000 0x1000>; > > > > + lpc_pcc: lpc-pcc@0 { > > + compatible = "aspeed,ast2600-lpc-pcc"; > > + reg = <0x0 0x140>; > > + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; > > + pcc-ports = <0x80>; > > So what 0x80 stands for? Host as x86 architecture would access the 0x80 port, which is mapped to the BMC PCC HW module. As a result, x86 can keep the port-mmaped I/O usage and access the BMC device, which is needed to know which port using in the PCC module in BMC. > > > Best regards, > Krzysztof
On 10/03/2025 02:50, Kevin Chen wrote: >>> + $ref: /schemas/types.yaml#/definitions/uint32-array >>> + description: The LPC I/O ports to pcc >> >> Description is too vague. Why would we encode I/O ports as some numbers >> instead of GPIOs for example? If these are ports, why this is not a graph? > For the port-mmaped I/O in x80 architecture, BMC need to handle specific port I/O in the relative HW module. > So, I need to add the pcc-ports property as the snoop-ports property in Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > >> >> Missing constraints - min/maxItems, defaults, minimum/maximum etc. > The port-mmaped I/O is defined from host, BMC as the device would capture the port I/O from the pcc-ports property defined in dts. Put this information in the description, instead of copying property name. > >> >>> + >>> + required: >>> + - compatible >>> + - interrupts >>> + - pcc-ports >>> + >>> "^uart-routing@[0-9a-f]+$": >>> $ref: /schemas/soc/aspeed/uart-routing.yaml# >>> description: The UART routing control under LPC register space @@ >>> -176,6 +205,13 @@ examples: >>> #size-cells = <1>; >>> ranges = <0x0 0x1e789000 0x1000>; >>> >>> + lpc_pcc: lpc-pcc@0 { >>> + compatible = "aspeed,ast2600-lpc-pcc"; >>> + reg = <0x0 0x140>; >>> + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; >>> + pcc-ports = <0x80>; >> >> So what 0x80 stands for? > Host as x86 architecture would access the 0x80 port, which is mapped to the BMC PCC HW module. > As a result, x86 can keep the port-mmaped I/O usage and access the BMC device, which is needed to know which port using in the PCC module in BMC. And on different boards this is not 0x80? Best regards, Krzysztof
> On 10/03/2025 02:50, Kevin Chen wrote: > >>> + $ref: /schemas/types.yaml#/definitions/uint32-array > >>> + description: The LPC I/O ports to pcc > >> > >> Description is too vague. Why would we encode I/O ports as some > >> numbers instead of GPIOs for example? If these are ports, why this is not a > graph? > > For the port-mmaped I/O in x86 architecture, BMC need to handle specific > port I/O in the relative HW module. > > So, I need to add the pcc-ports property as the snoop-ports property > > in Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml > > > >> > >> Missing constraints - min/maxItems, defaults, minimum/maximum etc. > > The port-mmaped I/O is defined from host, BMC as the device would capture > the port I/O from the pcc-ports property defined in dts. > > Put this information in the description, instead of copying property name. OK. I will put this information in the description. > > > > >> > >>> + > >>> + required: > >>> + - compatible > >>> + - interrupts > >>> + - pcc-ports > >>> + > >>> "^uart-routing@[0-9a-f]+$": > >>> $ref: /schemas/soc/aspeed/uart-routing.yaml# > >>> description: The UART routing control under LPC register space > >>> @@ > >>> -176,6 +205,13 @@ examples: > >>> #size-cells = <1>; > >>> ranges = <0x0 0x1e789000 0x1000>; > >>> > >>> + lpc_pcc: lpc-pcc@0 { > >>> + compatible = "aspeed,ast2600-lpc-pcc"; > >>> + reg = <0x0 0x140>; > >>> + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; > >>> + pcc-ports = <0x80>; > >> > >> So what 0x80 stands for? > > Host as x86 architecture would access the 0x80 port, which is mapped to the > BMC PCC HW module. > > As a result, x86 can keep the port-mmaped I/O usage and access the BMC > device, which is needed to know which port using in the PCC module in BMC. > > And on different boards this is not 0x80? The port-mmaped I/O defined in the intel legacy document as the example usage. For example, the common usage agreement of port-mmaped I/O are the following. But this setting can be modified due to the host usage. We provide the flexibility to modify the I/O port settings. KCS : 0xCA2(CMD)/CA3(Data) BT : 0xE4/E5/E6 SNOOP/PCC : 0x80/81/82/83 Mailbox : 0xCC0 SuperIO : 0x2E/2F or 0x4E/0x4F System UART : 0x3F8/2F8/3E8/2E8 > > Best regards, > Krzysztof
On 10/03/2025 10:49, Kevin Chen wrote: >>>>> + compatible = "aspeed,ast2600-lpc-pcc"; >>>>> + reg = <0x0 0x140>; >>>>> + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; >>>>> + pcc-ports = <0x80>; >>>> >>>> So what 0x80 stands for? >>> Host as x86 architecture would access the 0x80 port, which is mapped to the >> BMC PCC HW module. >>> As a result, x86 can keep the port-mmaped I/O usage and access the BMC >> device, which is needed to know which port using in the PCC module in BMC. >> >> And on different boards this is not 0x80? > The port-mmaped I/O defined in the intel legacy document as the example usage. > For example, the common usage agreement of port-mmaped I/O are the following. But this setting can be modified due to the host usage. We provide the flexibility to modify the I/O port settings. > KCS : 0xCA2(CMD)/CA3(Data) > BT : 0xE4/E5/E6 > SNOOP/PCC : 0x80/81/82/83 > Mailbox : 0xCC0 > SuperIO : 0x2E/2F or 0x4E/0x4F > System UART : 0x3F8/2F8/3E8/2E8 So which boards have it modified? Best regards, Krzysztof
> On 10/03/2025 10:49, Kevin Chen wrote: > >>>>> + compatible = "aspeed,ast2600-lpc-pcc"; > >>>>> + reg = <0x0 0x140>; > >>>>> + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; > >>>>> + pcc-ports = <0x80>; > >>>> > >>>> So what 0x80 stands for? > >>> Host as x86 architecture would access the 0x80 port, which is mapped to > the > >> BMC PCC HW module. > >>> As a result, x86 can keep the port-mmaped I/O usage and access the BMC > >> device, which is needed to know which port using in the PCC module in > BMC. > >> > >> And on different boards this is not 0x80? > > The port-mmaped I/O defined in the intel legacy document as the example > usage. > > For example, the common usage agreement of port-mmaped I/O are the > following. But this setting can be modified due to the host usage. We provide > the flexibility to modify the I/O port settings. > > KCS : 0xCA2(CMD)/CA3(Data) > > BT : 0xE4/E5/E6 > > SNOOP/PCC : 0x80/81/82/83 > > Mailbox : 0xCC0 > > SuperIO : 0x2E/2F or 0x4E/0x4F > > System UART : 0x3F8/2F8/3E8/2E8 > So which boards have it modified? This setting should be as same as the snoop-ports. You can check the dts in arch/arm/boot/dts/aspeed folder. aspeed-bmc-amd-daytonax.dts 212: snoop-ports = <0x80>, <0x81>; aspeed-bmc-facebook-tiogapass.dts 77: snoop-ports = <0x80>; > > Best regards, > Krzysztof
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml index 5dfe77aca167..367847bd7e75 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml @@ -149,6 +149,35 @@ patternProperties: - interrupts - snoop-ports + "^lpc-pcc@[0-9a-f]+$": + type: object + additionalProperties: false + + description: + The LPC pcc interface allows the BMC to listen on and record the data + bytes written by the Host to the targeted LPC I/O pots. + + properties: + compatible: + items: + - enum: + - aspeed,ast2600-lpc-pcc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + pcc-ports: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: The LPC I/O ports to pcc + + required: + - compatible + - interrupts + - pcc-ports + "^uart-routing@[0-9a-f]+$": $ref: /schemas/soc/aspeed/uart-routing.yaml# description: The UART routing control under LPC register space @@ -176,6 +205,13 @@ examples: #size-cells = <1>; ranges = <0x0 0x1e789000 0x1000>; + lpc_pcc: lpc-pcc@0 { + compatible = "aspeed,ast2600-lpc-pcc"; + reg = <0x0 0x140>; + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; + pcc-ports = <0x80>; + }; + lpc_ctrl: lpc-ctrl@80 { compatible = "aspeed,ast2600-lpc-ctrl"; reg = <0x80 0x80>;
Add dt-bindings for Aspeed for Aspeed LPC POST code capture controller. Signed-off-by: Kevin Chen <kevin_chen@aspeedtech.com> --- .../devicetree/bindings/mfd/aspeed-lpc.yaml | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+)