| Message ID | 20211130111325.29328-1-semen.protsenko@linaro.org |
|---|---|
| Headers | show |
| Series | soc: samsung: Add USI driver | expand |
On Tue, 30 Nov 2021 13:13:21 +0200, Sam Protsenko wrote: > 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 > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/soc/samsung/exynos-usi.example.dts:35.39-42.15: Warning (unique_unit_address): /example-0/usi@138200c0/serial@13820000: duplicate unit-address (also used in node /example-0/usi@138200c0/i2c@13820000) Documentation/devicetree/bindings/soc/samsung/exynos-usi.example.dt.yaml:0:0: /example-0/usi@138200c0/i2c@13820000: failed to match any schema with compatible: ['samsung,exynosautov9-hsi2c'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1561571 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On 30/11/2021 18:43, Rob Herring wrote: > On Tue, 30 Nov 2021 13:13:21 +0200, Sam Protsenko wrote: >> 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 >> > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > Documentation/devicetree/bindings/soc/samsung/exynos-usi.example.dts:35.39-42.15: Warning (unique_unit_address): /example-0/usi@138200c0/serial@13820000: duplicate unit-address (also used in node /example-0/usi@138200c0/i2c@13820000) Rob, The checker complains about two nodes with same unit-address, even though the node name is different. Does it mean that our idea of embedding two children in USI and having enabled only one (used one) is wrong? usi0: usi@138200c0 { // enabled device/child serial@13820000 { status = "okay"; }; // disabled device, keep for reference and for boards which // would like to use it i2c@13820000 { status = "disabled"; }; }; Best regards, Krzysztof
On Wed, Dec 1, 2021 at 12:42 AM Sam Protsenko <semen.protsenko@linaro.org> wrote: > > USI control is now extracted to dedicated USI driver. Remove USI related the dedicated > code from serial driver to avoid conflicts and code duplication. Would it break run-time bisectability? If so, why is it not a problem?
On Tue, Nov 30, 2021 at 2:04 PM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote: > > On 30/11/2021 18:43, Rob Herring wrote: > > On Tue, 30 Nov 2021 13:13:21 +0200, Sam Protsenko wrote: > >> 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 > >> > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > > > yamllint warnings/errors: > > > > dtschema/dtc warnings/errors: > > Documentation/devicetree/bindings/soc/samsung/exynos-usi.example.dts:35.39-42.15: Warning (unique_unit_address): /example-0/usi@138200c0/serial@13820000: duplicate unit-address (also used in node /example-0/usi@138200c0/i2c@13820000) > > Rob, > > The checker complains about two nodes with same unit-address, even > though the node name is different. Does it mean that our idea of > embedding two children in USI and having enabled only one (used one) is > wrong? IIRC, we allow for this exact scenario, and there was a change in dtc for it. So I'm not sure why this triggered. Rob
On Wed, 1 Dec 2021 at 18:20, Rob Herring <robh@kernel.org> wrote: > > On Tue, Nov 30, 2021 at 2:04 PM Krzysztof Kozlowski > <krzysztof.kozlowski@canonical.com> wrote: > > > > On 30/11/2021 18:43, Rob Herring wrote: > > > On Tue, 30 Nov 2021 13:13:21 +0200, Sam Protsenko wrote: > > >> 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 > > >> > > > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > > > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > > > > > yamllint warnings/errors: > > > > > > dtschema/dtc warnings/errors: > > > Documentation/devicetree/bindings/soc/samsung/exynos-usi.example.dts:35.39-42.15: Warning (unique_unit_address): /example-0/usi@138200c0/serial@13820000: duplicate unit-address (also used in node /example-0/usi@138200c0/i2c@13820000) > > > > Rob, > > > > The checker complains about two nodes with same unit-address, even > > though the node name is different. Does it mean that our idea of > > embedding two children in USI and having enabled only one (used one) is > > wrong? > > IIRC, we allow for this exact scenario, and there was a change in dtc > for it. So I'm not sure why this triggered. > It's triggered from WARNING(unique_unit_address, ...), because it calls static void check_unique_unit_address_common() function with disable_check=false. I guess we should interpret that this way: the warning makes sense in regular case, when having the same unit address for two nodes is wrong. So the warning is reasonable, it's just not relevant in this particular case. What can be done: 1. We can introduce some specific property to mark nodes with duplicated address as intentional. check_unique_unit_address_common() can be extended then to omit checking the nodes if that property is present. 2. We can just ignore that warning in this particular case (and similar cases). 3. We can add some disambiguation note to that warning message, like "if it's intentional -- please ignore this message" I'm all for option (3), as it's the easiest one, and still reasonable. Rob, what do you think? Can we just ignore that warning in further versions of this patch series? > Rob
On Thu, Dec 2, 2021 at 5:01 AM Sam Protsenko <semen.protsenko@linaro.org> wrote: > > On Wed, 1 Dec 2021 at 18:20, Rob Herring <robh@kernel.org> wrote: > > > > On Tue, Nov 30, 2021 at 2:04 PM Krzysztof Kozlowski > > <krzysztof.kozlowski@canonical.com> wrote: > > > > > > On 30/11/2021 18:43, Rob Herring wrote: > > > > On Tue, 30 Nov 2021 13:13:21 +0200, Sam Protsenko wrote: > > > >> 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 > > > >> > > > > > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > > > > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > > > > > > > yamllint warnings/errors: > > > > > > > > dtschema/dtc warnings/errors: > > > > Documentation/devicetree/bindings/soc/samsung/exynos-usi.example.dts:35.39-42.15: Warning (unique_unit_address): /example-0/usi@138200c0/serial@13820000: duplicate unit-address (also used in node /example-0/usi@138200c0/i2c@13820000) > > > > > > Rob, > > > > > > The checker complains about two nodes with same unit-address, even > > > though the node name is different. Does it mean that our idea of > > > embedding two children in USI and having enabled only one (used one) is > > > wrong? > > > > IIRC, we allow for this exact scenario, and there was a change in dtc > > for it. So I'm not sure why this triggered. > > > > It's triggered from WARNING(unique_unit_address, ...), because it > calls static void check_unique_unit_address_common() function with > disable_check=false. I guess we should interpret that this way: the > warning makes sense in regular case, when having the same unit address > for two nodes is wrong. So the warning is reasonable, it's just not > relevant in this particular case. What can be done: > > 1. We can introduce some specific property to mark nodes with > duplicated address as intentional. check_unique_unit_address_common() > can be extended then to omit checking the nodes if that property is > present. > 2. We can just ignore that warning in this particular case (and > similar cases). > 3. We can add some disambiguation note to that warning message, like > "if it's intentional -- please ignore this message" > > I'm all for option (3), as it's the easiest one, and still reasonable. > Rob, what do you think? Can we just ignore that warning in further > versions of this patch series? Just change the dtc flags to '-Wno-unique_unit_address -Wunique_unit_address_if_enabled' for both examples and dtbs. Rob
On Wed, 1 Dec 2021 at 12:54, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Dec 1, 2021 at 12:42 AM Sam Protsenko > <semen.protsenko@linaro.org> wrote: > > > > USI control is now extracted to dedicated USI driver. Remove USI related > > the dedicated > > > code from serial driver to avoid conflicts and code duplication. > > Would it break run-time bisectability? > If so, why is it not a problem? > It shouldn't. This patch is [3/5], and USI driver (which takes the control over the USI registers) is [2/5]. As for Device Tree, the only platform using "samsung,exynos850-uart" right now is Exynos Auto V9 SADK (serial node is declared in exynosautov9.dtsi). I don't have Exynos Auto V9 datasheet, so I can't really add the USI node properly there, nor I can test that. I guess it should be done separately from this patch series. Chanho, Krzysztof: Guys, what are your thoughts on this? Basically with this patch series applied, Exynos Auto V9 serial might become not functional. New USI node should be added for UART case in Exynos Auto V9 dtsi (providing correct sysreg, SW_CONF offset, clocks, etc), and serial node should be encapsulated inside of that USI node. Also, USI node should be referenced and enabled in SADK dts, providing also "clkreq-on" property. More details can be found in [PATCH 1/5]. Do you think it's ok to take this series as is, and add that later? Because otherwise we might need to collaborate to add that Exynos Auto V9 enablement into this patch series, which might take more time... Thanks! > > -- > With Best Regards, > Andy Shevchenko
On Thu, 2 Dec 2021 at 22:44, Rob Herring <robh@kernel.org> wrote: > > On Thu, Dec 2, 2021 at 5:01 AM Sam Protsenko <semen.protsenko@linaro.org> wrote: > > > > On Wed, 1 Dec 2021 at 18:20, Rob Herring <robh@kernel.org> wrote: > > > > > > On Tue, Nov 30, 2021 at 2:04 PM Krzysztof Kozlowski > > > <krzysztof.kozlowski@canonical.com> wrote: > > > > > > > > On 30/11/2021 18:43, Rob Herring wrote: > > > > > On Tue, 30 Nov 2021 13:13:21 +0200, Sam Protsenko wrote: > > > > >> 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 > > > > >> > > > > > > > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > > > > > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > > > > > > > > > yamllint warnings/errors: > > > > > > > > > > dtschema/dtc warnings/errors: > > > > > Documentation/devicetree/bindings/soc/samsung/exynos-usi.example.dts:35.39-42.15: Warning (unique_unit_address): /example-0/usi@138200c0/serial@13820000: duplicate unit-address (also used in node /example-0/usi@138200c0/i2c@13820000) > > > > > > > > Rob, > > > > > > > > The checker complains about two nodes with same unit-address, even > > > > though the node name is different. Does it mean that our idea of > > > > embedding two children in USI and having enabled only one (used one) is > > > > wrong? > > > > > > IIRC, we allow for this exact scenario, and there was a change in dtc > > > for it. So I'm not sure why this triggered. > > > > > > > It's triggered from WARNING(unique_unit_address, ...), because it > > calls static void check_unique_unit_address_common() function with > > disable_check=false. I guess we should interpret that this way: the > > warning makes sense in regular case, when having the same unit address > > for two nodes is wrong. So the warning is reasonable, it's just not > > relevant in this particular case. What can be done: > > > > 1. We can introduce some specific property to mark nodes with > > duplicated address as intentional. check_unique_unit_address_common() > > can be extended then to omit checking the nodes if that property is > > present. > > 2. We can just ignore that warning in this particular case (and > > similar cases). > > 3. We can add some disambiguation note to that warning message, like > > "if it's intentional -- please ignore this message" > > > > I'm all for option (3), as it's the easiest one, and still reasonable. > > Rob, what do you think? Can we just ignore that warning in further > > versions of this patch series? > > Just change the dtc flags to '-Wno-unique_unit_address > -Wunique_unit_address_if_enabled' for both examples and dtbs. > Thanks. Submitted that separately from this series: [1]. [1] https://lkml.org/lkml/2021/12/3/762 > Rob
On Fri, Dec 3, 2021 at 1:36 PM Sam Protsenko <semen.protsenko@linaro.org> wrote: > > On Tue, 30 Nov 2021 at 21:31, Rob Herring <robh@kernel.org> wrote: > > > > On Tue, Nov 30, 2021 at 01:13:21PM +0200, Sam Protsenko wrote: > > > 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). We went down the version # path with QCom and in the end about every SoC had a different version. > > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + clocks: > > > + items: > > > + - description: Bus (APB) clock > > > + - description: Operating clock for UART/SPI/I2C protocol > > > + > > > + clock-names: > > > + items: > > > + - const: pclk > > > + - const: ipclk > > > + > > > + ranges: true > > > + > > > + "#address-cells": > > > + const: 1 > > > + > > > + "#size-cells": > > > + const: 1 > > > + > > > + samsung,sysreg: > > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > > + description: > > > + Should be phandle/offset pair. The phandle to System Register syscon node > > > + (for the same domain where this USI controller resides) and the offset > > > + of SW_CONF register for this USI controller. > > > + > > > + samsung,mode: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: > > > + Selects USI function (which serial protocol to use). Refer to > > > + <include/dt-bindings/soc/samsung,exynos-usi.h> for valid USI mode values. > > > > This seems to be redundant. Just check which child is enabled. > > > > I think it's not that easy. Soon we'll have USIv1 support added, and > that has some weird configurations, like having dual I2C mode (two > child I2C nodes must be enabled) and UART+I2C mode, etc. So you are going to turn around and make this an array? If you already know you have changes, I'd rather review this all at once. > Looks like it > might take some not very elegant logic to figure out which exactly > mode value should be written in SW_CONF register in that way, it's > much easier to just specify mode in USI node. Also, that reflects > hardware better: we actually write that specified mode to SW_CONF > register. You just have to compare the child node names or compatibles. > Also, later we might want to be able to switch that mode via > SysFS, e.g. for testing purposes. Current design seems to be better > suited for some things like that. The binding should have no impact on that. If for testing, use debugfs. > Please let me know if you have a strong opinion on this one, or it's > ok to leave it as is. > > All other comments are addressed and will be present in v3. Thanks for > the review!
On Fri, 3 Dec 2021 at 22:40, Rob Herring <robh@kernel.org> wrote: > > On Fri, Dec 3, 2021 at 1:36 PM Sam Protsenko <semen.protsenko@linaro.org> wrote: > > > > On Tue, 30 Nov 2021 at 21:31, Rob Herring <robh@kernel.org> wrote: > > > > > > On Tue, Nov 30, 2021 at 01:13:21PM +0200, Sam Protsenko wrote: > > > > 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. > We went down the version # path with QCom and in the end about every > SoC had a different version. > > > > > > > + > > > > + reg: > > > > + maxItems: 1 > > > > + > > > > + clocks: > > > > + items: > > > > + - description: Bus (APB) clock > > > > + - description: Operating clock for UART/SPI/I2C protocol > > > > + > > > > + clock-names: > > > > + items: > > > > + - const: pclk > > > > + - const: ipclk > > > > + > > > > + ranges: true > > > > + > > > > + "#address-cells": > > > > + const: 1 > > > > + > > > > + "#size-cells": > > > > + const: 1 > > > > + > > > > + samsung,sysreg: > > > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > > > + description: > > > > + Should be phandle/offset pair. The phandle to System Register syscon node > > > > + (for the same domain where this USI controller resides) and the offset > > > > + of SW_CONF register for this USI controller. > > > > + > > > > + samsung,mode: > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > + description: > > > > + Selects USI function (which serial protocol to use). Refer to > > > > + <include/dt-bindings/soc/samsung,exynos-usi.h> for valid USI mode values. > > > > > > This seems to be redundant. Just check which child is enabled. > > > > > > > I think it's not that easy. Soon we'll have USIv1 support added, and > > that has some weird configurations, like having dual I2C mode (two > > child I2C nodes must be enabled) and UART+I2C mode, etc. > > So you are going to turn around and make this an array? If you already > know you have changes, I'd rather review this all at once. > No, I'd imagine that would be just a bunch of new dt-bindings constants, for USI_V1. For example, for USI_V2 you already can see these: #define USI_V2_NONE 0 #define USI_V2_UART 1 #define USI_V2_SPI 2 #define USI_V2_I2C 3 and for USI_V1 it would probably be something like this, judging from [1]: #define USI_V1_NONE 4 #define USI_V1_I2C0 5 #define USI_V1_I2C1 6 #define USI_V1_I2C0_I2C1_DUAL 7 #define USI_V1_SPI 8 #define USI_V1_UART 9 #define USI_V1_UART_I2C1_DUAL 10 Guess in that case parsing enabled nodes and figuring out which mode we have, and which value should be written into SW_CONF -- might be not trivial. Having explicit "mode" property simplifies things. [1] https://github.com/ibanezbass/universal7885/blob/oneui/drivers/soc/samsung/usi.c > > Looks like it > > might take some not very elegant logic to figure out which exactly > > mode value should be written in SW_CONF register in that way, it's > > much easier to just specify mode in USI node. Also, that reflects > > hardware better: we actually write that specified mode to SW_CONF > > register. > > You just have to compare the child node names or compatibles. > For USIv1 that would allow for some invalid combinations (e.g. UART+I2C1 is possible, but SPI+I2C1 can't be configured). Also, the list of supported compatibles might grow in future, which will have us constantly add the list to the driver. And node names might be not valid (e.g. you can see @hsi2c names are used in some dts's instead of @i2c; also downstream kernels might have all kinds of names -- not a strong point, but still). Anyway, it can be implemented, and maybe I'm a bit biased here; so if I still didn't convince you that benefits of having "mode" property outweigh the disadvantages, please let me know -- I can send it in next submission. > > Also, later we might want to be able to switch that mode via > > SysFS, e.g. for testing purposes. Current design seems to be better > > suited for some things like that. > > The binding should have no impact on that. If for testing, use debugfs. > > > Please let me know if you have a strong opinion on this one, or it's > > ok to leave it as is. > > > > All other comments are addressed and will be present in v3. Thanks for > > the review!
On 03/12/2021 17:22, Sam Protsenko wrote: > On Wed, 1 Dec 2021 at 12:54, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >> >> On Wed, Dec 1, 2021 at 12:42 AM Sam Protsenko >> <semen.protsenko@linaro.org> wrote: >>> >>> USI control is now extracted to dedicated USI driver. Remove USI related >> >> the dedicated >> >>> code from serial driver to avoid conflicts and code duplication. >> >> Would it break run-time bisectability? >> If so, why is it not a problem? >> > > It shouldn't. This patch is [3/5], and USI driver (which takes the > control over the USI registers) is [2/5]. As for Device Tree, the only > platform using "samsung,exynos850-uart" right now is Exynos Auto V9 > SADK (serial node is declared in exynosautov9.dtsi). I don't have > Exynos Auto V9 datasheet, so I can't really add the USI node properly > there, nor I can test that. I guess it should be done separately from > this patch series. > > Chanho, Krzysztof: > > Guys, what are your thoughts on this? Basically with this patch series > applied, Exynos Auto V9 serial might become not functional. New USI > node should be added for UART case in Exynos Auto V9 dtsi (providing > correct sysreg, SW_CONF offset, clocks, etc), and serial node should > be encapsulated inside of that USI node. Also, USI node should be > referenced and enabled in SADK dts, providing also "clkreq-on" > property. More details can be found in [PATCH 1/5]. Do you think it's > ok to take this series as is, and add that later? Because otherwise we > might need to collaborate to add that Exynos Auto V9 enablement into > this patch series, which might take more time... The patch in current state will probably break Exynos Auto v9 boards, including the in-tree one, unless bootloader sets the USI to serial. The trouble is that. Changing the Exynos Auto v9 DTSI in these series would solve it only partially, because the kernel still won't be bisectable. Breaking Auto v9 serial within a kernel is okay for me, because the board was added recently, I don't expect products using it and it is still development phase. This of course assuming that it's users agree, so the question is to Chanho and other folks. Best regards, Krzysztof
On 03/12/2021 21:40, Rob Herring wrote: > On Fri, Dec 3, 2021 at 1:36 PM Sam Protsenko <semen.protsenko@linaro.org> wrote: >> >> On Tue, 30 Nov 2021 at 21:31, Rob Herring <robh@kernel.org> wrote: >>> >>> On Tue, Nov 30, 2021 at 01:13:21PM +0200, Sam Protsenko wrote: >>>> 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). > > We went down the version # path with QCom and in the end about every > SoC had a different version. I am against v1/v2 versions. The documentation in Samsung was always poor in that matter. There were mistakes or confusions so it wasn't always obvious which IP-block version comes with which SoC. Not mentioning that several contributors do not have access to Samsung datasheets and they submit code based on GPL compliance packages, so they won't know which version they have for given SoC. OTOH there is no single benefit of using USI v1/v2, except "liking". Best regards, Krzysztof
On 04/12/2021 01:18, Sam Protsenko wrote: > On Fri, 3 Dec 2021 at 22:40, Rob Herring <robh@kernel.org> wrote: >> >> On Fri, Dec 3, 2021 at 1:36 PM Sam Protsenko <semen.protsenko@linaro.org> wrote: >>> >>> On Tue, 30 Nov 2021 at 21:31, Rob Herring <robh@kernel.org> wrote: >>>> >>>> On Tue, Nov 30, 2021 at 01:13:21PM +0200, Sam Protsenko wrote: >>>>> 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
On Sat, 4 Dec 2021 at 13:28, Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote: > > On 03/12/2021 21:40, Rob Herring wrote: > > On Fri, Dec 3, 2021 at 1:36 PM Sam Protsenko <semen.protsenko@linaro.org> wrote: > >> > >> On Tue, 30 Nov 2021 at 21:31, Rob Herring <robh@kernel.org> wrote: > >>> > >>> On Tue, Nov 30, 2021 at 01:13:21PM +0200, Sam Protsenko wrote: > >>>> 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). > > > > We went down the version # path with QCom and in the end about every > > SoC had a different version. > > I am against v1/v2 versions. The documentation in Samsung was always > poor in that matter. There were mistakes or confusions so it wasn't > always obvious which IP-block version comes with which SoC. Not > mentioning that several contributors do not have access to Samsung > datasheets and they submit code based on GPL compliance packages, so > they won't know which version they have for given SoC. > > OTOH there is no single benefit of using USI v1/v2, except "liking". > Ok, I'll do as you ask. In general I agree, but I still think in this particular case using "usi" in compatible is feasible. Anyway, I have no strong opinion on this one, and it's easy to rework. > Best regards, > Krzysztof
USIv2 IP-core provides selectable serial protocol (UART, SPI or High-Speed I2C); only one can be chosen at a time. This series implements USIv2 driver, which allows one to select particular USI function in device tree, and also performs USI block initialization. With that driver implemented, it's not needed to do USI initialization in protocol drivers anymore, so that code is removed from the serial driver. Because USI driver is tristate (can be built as a module), serial driver was reworked so it's possible to use its console part as a module too. This way we can load serial driver module from user space and still have serial console functional. Make it impossible to build UART/SPI/I2C driver as a built-in when USIv2 driver built as a module: USIv2 configuration must be always done before tinkering with particular protocol it implements. Design features: - "reg" property contains USI registers start address (0xc0 offset); it's used in the driver to access USI_CON and USI_OPTION registers. This way all USI initialization (reset, HWACG, etc) can be done in USIv2 driver separately, rather than duplicating that code over UART/SPI/I2C drivers - System Register (system controller node) and its SW_CONF register offset are provided in "samsung,sysreg" property; it's used to select USI function (protocol to be used) - USI function is specified in "samsung,mode" property; integer value is used to simplify parsing - there is "samsung,clkreq-on" bool property, which makes driver disable HWACG control (needed for UART to work properly) - PCLK and IPCLK clocks are both provided to USI node; apparently both need to be enabled to access USI registers - protocol nodes are embedded (as a child nodes) in USI node; it allows correct init order, and reflects HW properly - USIv2 driver is a tristate: can be also useful from Android GKI requirements point of view - driver functions are implemented with further development in mind: we might want to add some SysFS interface later for example, or provide some functions to serial drivers with EXPORT_SYMBOL(), etc; also another USI revisions could be added (like USIv1) Changes in v2: - Renamed all 'usi_v2' wording to just 'usi' everywhere - Removed patches adding dependency on EXYNOS_USI for UART/I2C/SPI drivers - Added patch: "tty: serial: samsung: Fix console registration from module" - Combined dt-bindings doc and dt-bindings header patches - Reworked USI driver to be ready for USIv1 addition - Improved dt-bindings - Added USI_V2_NONE mode value Sam Protsenko (5): dt-bindings: soc: samsung: Add Exynos USI bindings soc: samsung: Add USI driver tty: serial: samsung: Remove USI initialization tty: serial: samsung: Enable console as module tty: serial: samsung: Fix console registration from module .../bindings/soc/samsung/exynos-usi.yaml | 135 +++++++++ drivers/soc/samsung/Kconfig | 14 + drivers/soc/samsung/Makefile | 2 + drivers/soc/samsung/exynos-usi.c | 274 ++++++++++++++++++ drivers/tty/serial/Kconfig | 2 +- drivers/tty/serial/samsung_tty.c | 78 ++--- include/dt-bindings/soc/samsung,exynos-usi.h | 17 ++ include/linux/serial_s3c.h | 9 - 8 files changed, 483 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml create mode 100644 drivers/soc/samsung/exynos-usi.c create mode 100644 include/dt-bindings/soc/samsung,exynos-usi.h