| Message ID | 20230222210425.626474-2-martin.blumenstingl@googlemail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v1,RFC,1/3] dt-bindings: serial: amlogic,meson-uart: Add compatible string for G12A | expand |
On 22/02/2023 22:04, Martin Blumenstingl wrote: > Amlogic G12A SoCs gained a new "divide XTAL by 2" bit. Everything else > (we know about) is identical to the UART IP on GX (GXBB/GXL/GXM) SoCs. > Add a new compatible string for this SoC so this new bit can be managed > accordingly. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > --- > Why am I sending this as RFC? The last change in this series means > that the resulting .dtbs are not compatible with old kernels anymore. > My understanding is that this is fine and only the opposite case (using > old .dtbs on new kernels) has to be supported (which is still the case > with this series). I'd like to get some confirmation for this. The other way around is also nice to have, because DTS is used in other projects. You fixed here Linux kernel, but what about all other out-of-tree kernels, BSDs, firmwares and bootloaders? Did you fix them as well? The question is whether the devices can be made compatible thus keeping DTS working on older kernel. This commit suggests they are. Your DTS commit is written in different tone - something was broken and is being fixed. Best regards, Krzysztof
Hello Krzysztof, On Thu, Feb 23, 2023 at 10:12 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 22/02/2023 22:04, Martin Blumenstingl wrote: > > Amlogic G12A SoCs gained a new "divide XTAL by 2" bit. Everything else > > (we know about) is identical to the UART IP on GX (GXBB/GXL/GXM) SoCs. > > Add a new compatible string for this SoC so this new bit can be managed > > accordingly. > > > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > --- > > Why am I sending this as RFC? The last change in this series means > > that the resulting .dtbs are not compatible with old kernels anymore. > > My understanding is that this is fine and only the opposite case (using > > old .dtbs on new kernels) has to be supported (which is still the case > > with this series). I'd like to get some confirmation for this. > > The other way around is also nice to have, because DTS is used in other > projects. You fixed here Linux kernel, but what about all other > out-of-tree kernels, BSDs, firmwares and bootloaders? Did you fix them > as well? Indeed, u-boot is of concern here (as mainline u-boot does have Meson G12A SoC support). > The question is whether the devices can be made compatible thus keeping > DTS working on older kernel. This commit suggests they are. Your DTS > commit is written in different tone - something was broken and is being > fixed. If we keep "amlogic,meson-gx-uart" as fallback compatible string then old kernels (or other .dtb consumers - like u-boot) would still work. Without the new "amlogic,meson-g12a-uart" compatible string we're unable to make use of a newly added clock divider within the UART IP block which allows baud rates such as 1500000 to work without (a lot of) jitter. Old kernels - with the new .dtb - would still be able to use serial (thanks to the "amlogic,meson-gx-uart" fallback compatible string) albeit with limited divider support (so not all baud rates can be used). Is this a valid plan? Best regards, Martin
On 23/02/2023 21:14, Martin Blumenstingl wrote: > >> The question is whether the devices can be made compatible thus keeping >> DTS working on older kernel. This commit suggests they are. Your DTS >> commit is written in different tone - something was broken and is being >> fixed. > If we keep "amlogic,meson-gx-uart" as fallback compatible string then > old kernels (or other .dtb consumers - like u-boot) would still work. > Without the new "amlogic,meson-g12a-uart" compatible string we're > unable to make use of a newly added clock divider within the UART IP > block which allows baud rates such as 1500000 to work without (a lot > of) jitter. Old kernels - with the new .dtb - would still be able to > use serial (thanks to the "amlogic,meson-gx-uart" fallback compatible > string) albeit with limited divider support (so not all baud rates can > be used). > Is this a valid plan? Yes. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index 7822705ad16c..3d9d51389171 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -29,6 +29,7 @@ properties: - amlogic,meson8-uart - amlogic,meson8b-uart - amlogic,meson-gx-uart + - amlogic,meson-g12a-uart - amlogic,meson-s4-uart - const: amlogic,meson-ao-uart - description: Everything-Else power domain UART controller @@ -37,6 +38,7 @@ properties: - amlogic,meson8-uart - amlogic,meson8b-uart - amlogic,meson-gx-uart + - amlogic,meson-g12a-uart - amlogic,meson-s4-uart reg:
Amlogic G12A SoCs gained a new "divide XTAL by 2" bit. Everything else (we know about) is identical to the UART IP on GX (GXBB/GXL/GXM) SoCs. Add a new compatible string for this SoC so this new bit can be managed accordingly. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- Why am I sending this as RFC? The last change in this series means that the resulting .dtbs are not compatible with old kernels anymore. My understanding is that this is fine and only the opposite case (using old .dtbs on new kernels) has to be supported (which is still the case with this series). I'd like to get some confirmation for this. .../devicetree/bindings/serial/amlogic,meson-uart.yaml | 2 ++ 1 file changed, 2 insertions(+)