Re: [PATCH v2 RESEND 1/5] dt-bindings: soc: samsung: Add Exynos USI bindings

On 04/12/2021 01:18, Sam Protsenko wrote:

On Fri, 3 Dec 2021 at 22:40, Rob Herring [off-list ref] wrote:

quoted

On Fri, Dec 3, 2021 at 1:36 PM Sam Protsenko [off-list ref] wrote:

quoted

On Tue, 30 Nov 2021 at 21:31, Rob Herring [off-list ref] wrote:

quoted

On Tue, Nov 30, 2021 at 01:13:21PM +0200, Sam Protsenko wrote:

quoted

Add constants for choosing USIv2 configuration mode in device tree.
Those are further used in USI driver to figure out which value to write
into SW_CONF register. Also document USIv2 IP-core bindings.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
---
Changes in v2:
  - Combined dt-bindings doc and dt-bindings header patches
  - Added i2c node to example in bindings doc
  - Added mentioning of shared internal circuits
  - Added USI_V2_NONE value to bindings header

 .../bindings/soc/samsung/exynos-usi.yaml      | 135 ++++++++++++++++++
 include/dt-bindings/soc/samsung,exynos-usi.h  |  17 +++
 2 files changed, 152 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
 create mode 100644 include/dt-bindings/soc/samsung,exynos-usi.h

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
new file mode 100644
index 000000000000..a822bc62b3cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml

@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/samsung/exynos-usi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung's Exynos USI (Universal Serial Interface) binding
+
+maintainers:
+  - Sam Protsenko <semen.protsenko@linaro.org>
+  - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+
+description: |
+  USI IP-core provides selectable serial protocol (UART, SPI or High-Speed I2C).
+  USI shares almost all internal circuits within each protocol, so only one
+  protocol can be chosen at a time. USI is modeled as a node with zero or more
+  child nodes, each representing a serial sub-node device. The mode setting
+  selects which particular function will be used.
+
+  Refer to next bindings documentation for information on protocol subnodes that
+  can exist under USI node:
+
+  [1] Documentation/devicetree/bindings/serial/samsung_uart.yaml
+  [2] Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
+  [3] Documentation/devicetree/bindings/spi/spi-samsung.txt
+
+properties:
+  $nodename:
+    pattern: "^usi@[0-9a-f]+$"
+
+  compatible:
+    const: samsung,exynos-usi-v2

Use SoC based compatibles.

In this particular case, I'd really prefer to have it like this. Most
likely we'll only have USIv1 and USIv1 in the end, and I think that
would be more clear to have USI version in compatible, rather than SoC
name. Please let me know if you have a strong opinion on this one --
if so I'll re-send.

Fine if you have some evidence the ratio of versions to SoC are much
more than 1:1 and the versions correspond to something (IOW, you
aren't making them up).

Yes, it's documented in TRM for different SoCs (USI version 2), and
there are even dedicated registers where you can read the USI IP-core
version. Right now we only know about two USI versions: v1 and v2 (can
be found for example from different published Samsung downstream
kernels, and from TRMs). So the USI block is standardized and
versioned.

There is no version register for USIv1 and it does not look at all as
standardized. At least not documented. Just because later Samsung
introduced some logic behind it, it's not a proof it is standardized.
It's not. Standard comes with specification and there is no such.
Description of current implementation is not a specification.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel