From: Jeremy Kerr <jk@codeconstruct.com.au>
To: linux-aspeed@lists.ozlabs.org
Subject: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2
Date: Sun, 26 Feb 2023 15:04:16 +0800 [thread overview]
Message-ID: <8999ef4a57b035a81b086d8732d119638d46968c.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20230226031321.3126756-2-ryan_chen@aspeedtech.com>
Hi Ryan,
> --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
> @@ -49,6 +49,25 @@ properties:
> ???? description:
> ?????? states that there is another master active on this bus
> ?
> +? aspeed,timeout:
> +??? type: boolean
> +??? description: I2C bus timeout enable for master/slave mode
> +
> +? aspeed,xfer-mode:
> +??? description: |
> +????? I2C bus transfer mode selection.
> +????? - "byte": I2C bus byte transfer mode.
> +????? - "buffered": I2C bus buffer register transfer mode.
> +????? - "dma": I2C bus dma transfer mode (default)
> +??? items:
> +????? enum: [byte, buffered, dma]
> +??? maxItems: 1
> +??? $ref: /schemas/types.yaml#/definitions/non-unique-string-array
There are still unresolved questions about this xfer-mode property from
previous submissions of this binding. We don't yet have a justification
on why the mode configuration is needed in the device tree rather than
something that is specified in a driver implementation.
By now, I think we well understand what the modes are, and how a driver
implementation might configure them, but none of that has (so far)
provided sufficient rationale on why this belongs in the device tree.
The previous threads had a couple of pending discussions, following up on
those here:
A) You mentioned in [1] that the DMA controller is shared between all i3c
devices, does that have any consequence on which modes individual
devices might want to choose?
B) You implied in [2] that the different transfer modes might be related
to whether there are other masters present on the bus, but the logic
behind that is not clear.
C) In [3] you mentioned that there might be some DRAM savings by using a
particular mode.
and, most importantly:
D) unanswered from [4] and [5]: what are the hardware-specified reasons
why a DT author would chose one mode over another?
If you can write this out in some format like:
- in hardware situation X, you should use DMA mode
- in hardware situation Y, you should use byte mode
- [...]
that might help us to understand where this configuration belongs, or
what a reasonable DT representation should look like, or even if
existing DT schema can already provide the information required to
decide.
Cheers,
Jeremy
[1]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009876.html
[2]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009892.html
[3]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009880.html
[4]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009871.html
[5]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009884.html
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Ryan Chen <ryan_chen@aspeedtech.com>,
Andrew Jeffery <andrew@aj.id.au>,
Brendan Higgins <brendan.higgins@linux.dev>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Joel Stanley <joel@jms.id.au>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2
Date: Sun, 26 Feb 2023 15:04:16 +0800 [thread overview]
Message-ID: <8999ef4a57b035a81b086d8732d119638d46968c.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20230226031321.3126756-2-ryan_chen@aspeedtech.com>
Hi Ryan,
> --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
> @@ -49,6 +49,25 @@ properties:
> description:
> states that there is another master active on this bus
>
> + aspeed,timeout:
> + type: boolean
> + description: I2C bus timeout enable for master/slave mode
> +
> + aspeed,xfer-mode:
> + description: |
> + I2C bus transfer mode selection.
> + - "byte": I2C bus byte transfer mode.
> + - "buffered": I2C bus buffer register transfer mode.
> + - "dma": I2C bus dma transfer mode (default)
> + items:
> + enum: [byte, buffered, dma]
> + maxItems: 1
> + $ref: /schemas/types.yaml#/definitions/non-unique-string-array
There are still unresolved questions about this xfer-mode property from
previous submissions of this binding. We don't yet have a justification
on why the mode configuration is needed in the device tree rather than
something that is specified in a driver implementation.
By now, I think we well understand what the modes are, and how a driver
implementation might configure them, but none of that has (so far)
provided sufficient rationale on why this belongs in the device tree.
The previous threads had a couple of pending discussions, following up on
those here:
A) You mentioned in [1] that the DMA controller is shared between all i3c
devices, does that have any consequence on which modes individual
devices might want to choose?
B) You implied in [2] that the different transfer modes might be related
to whether there are other masters present on the bus, but the logic
behind that is not clear.
C) In [3] you mentioned that there might be some DRAM savings by using a
particular mode.
and, most importantly:
D) unanswered from [4] and [5]: what are the hardware-specified reasons
why a DT author would chose one mode over another?
If you can write this out in some format like:
- in hardware situation X, you should use DMA mode
- in hardware situation Y, you should use byte mode
- [...]
that might help us to understand where this configuration belongs, or
what a reasonable DT representation should look like, or even if
existing DT schema can already provide the information required to
decide.
Cheers,
Jeremy
[1]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009876.html
[2]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009892.html
[3]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009880.html
[4]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009871.html
[5]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009884.html
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Ryan Chen <ryan_chen@aspeedtech.com>,
Andrew Jeffery <andrew@aj.id.au>,
Brendan Higgins <brendan.higgins@linux.dev>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Joel Stanley <joel@jms.id.au>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org,
devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2
Date: Sun, 26 Feb 2023 15:04:16 +0800 [thread overview]
Message-ID: <8999ef4a57b035a81b086d8732d119638d46968c.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20230226031321.3126756-2-ryan_chen@aspeedtech.com>
Hi Ryan,
> --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
> @@ -49,6 +49,25 @@ properties:
> description:
> states that there is another master active on this bus
>
> + aspeed,timeout:
> + type: boolean
> + description: I2C bus timeout enable for master/slave mode
> +
> + aspeed,xfer-mode:
> + description: |
> + I2C bus transfer mode selection.
> + - "byte": I2C bus byte transfer mode.
> + - "buffered": I2C bus buffer register transfer mode.
> + - "dma": I2C bus dma transfer mode (default)
> + items:
> + enum: [byte, buffered, dma]
> + maxItems: 1
> + $ref: /schemas/types.yaml#/definitions/non-unique-string-array
There are still unresolved questions about this xfer-mode property from
previous submissions of this binding. We don't yet have a justification
on why the mode configuration is needed in the device tree rather than
something that is specified in a driver implementation.
By now, I think we well understand what the modes are, and how a driver
implementation might configure them, but none of that has (so far)
provided sufficient rationale on why this belongs in the device tree.
The previous threads had a couple of pending discussions, following up on
those here:
A) You mentioned in [1] that the DMA controller is shared between all i3c
devices, does that have any consequence on which modes individual
devices might want to choose?
B) You implied in [2] that the different transfer modes might be related
to whether there are other masters present on the bus, but the logic
behind that is not clear.
C) In [3] you mentioned that there might be some DRAM savings by using a
particular mode.
and, most importantly:
D) unanswered from [4] and [5]: what are the hardware-specified reasons
why a DT author would chose one mode over another?
If you can write this out in some format like:
- in hardware situation X, you should use DMA mode
- in hardware situation Y, you should use byte mode
- [...]
that might help us to understand where this configuration belongs, or
what a reasonable DT representation should look like, or even if
existing DT schema can already provide the information required to
decide.
Cheers,
Jeremy
[1]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009876.html
[2]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009892.html
[3]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009880.html
[4]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009871.html
[5]: https://lists.ozlabs.org/pipermail/linux-aspeed/2023-February/009884.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-02-26 7:04 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-26 3:13 [PATCH v6 0/2] Add ASPEED AST2600 I2Cv2 controller driver Ryan Chen
2023-02-26 3:13 ` Ryan Chen
2023-02-26 3:13 ` Ryan Chen
2023-02-26 3:13 ` [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 Ryan Chen
2023-02-26 3:13 ` Ryan Chen
2023-02-26 3:13 ` Ryan Chen
2023-02-26 7:04 ` Jeremy Kerr [this message]
2023-02-26 7:04 ` Jeremy Kerr
2023-02-26 7:04 ` Jeremy Kerr
2023-02-27 4:12 ` Ryan Chen
2023-02-27 4:12 ` Ryan Chen
2023-02-27 4:12 ` Ryan Chen
2023-02-27 5:40 ` Jeremy Kerr
2023-02-27 5:40 ` Jeremy Kerr
2023-02-27 5:40 ` Jeremy Kerr
2023-03-01 3:02 ` Ryan Chen
2023-03-01 3:02 ` Ryan Chen
2023-03-01 3:02 ` Ryan Chen
2023-03-01 3:23 ` Jeremy Kerr
2023-03-01 3:23 ` Jeremy Kerr
2023-03-01 3:23 ` Jeremy Kerr
2023-03-01 3:40 ` Ryan Chen
2023-03-01 3:40 ` Ryan Chen
2023-03-01 3:40 ` Ryan Chen
2023-02-27 8:25 ` Krzysztof Kozlowski
2023-02-27 8:25 ` Krzysztof Kozlowski
2023-02-27 8:25 ` Krzysztof Kozlowski
2023-03-01 5:57 ` Ryan Chen
2023-03-01 5:57 ` Ryan Chen
2023-03-01 5:57 ` Ryan Chen
2023-03-03 8:20 ` Krzysztof Kozlowski
2023-03-03 8:20 ` Krzysztof Kozlowski
2023-03-03 8:20 ` Krzysztof Kozlowski
2023-03-03 8:28 ` Ryan Chen
2023-03-03 8:28 ` Ryan Chen
2023-03-03 8:28 ` Ryan Chen
2023-03-03 8:28 ` Ryan Chen
2023-03-03 8:50 ` Krzysztof Kozlowski
2023-03-03 8:50 ` Krzysztof Kozlowski
2023-03-03 8:50 ` Krzysztof Kozlowski
2023-03-03 8:55 ` Ryan Chen
2023-03-03 8:55 ` Ryan Chen
2023-03-03 8:55 ` Ryan Chen
2023-03-03 8:55 ` Ryan Chen
2023-03-03 9:26 ` Krzysztof Kozlowski
2023-03-03 9:26 ` Krzysztof Kozlowski
2023-03-03 9:26 ` Krzysztof Kozlowski
2023-03-03 10:16 ` Ryan Chen
2023-03-03 10:16 ` Ryan Chen
2023-03-03 10:16 ` Ryan Chen
2023-03-03 10:16 ` Ryan Chen
2023-03-03 10:41 ` Krzysztof Kozlowski
2023-03-03 10:41 ` Krzysztof Kozlowski
2023-03-03 10:41 ` Krzysztof Kozlowski
2023-03-04 1:33 ` Ryan Chen
2023-03-04 1:33 ` Ryan Chen
2023-03-04 1:33 ` Ryan Chen
2023-03-04 1:33 ` Ryan Chen
2023-03-05 9:49 ` Krzysztof Kozlowski
2023-03-05 9:49 ` Krzysztof Kozlowski
2023-03-05 9:49 ` Krzysztof Kozlowski
2023-03-06 0:48 ` Ryan Chen
2023-03-06 0:48 ` Ryan Chen
2023-03-06 0:48 ` Ryan Chen
2023-03-06 0:48 ` Ryan Chen
2023-03-07 8:11 ` Krzysztof Kozlowski
2023-03-07 8:11 ` Krzysztof Kozlowski
2023-03-07 8:11 ` Krzysztof Kozlowski
2023-03-07 10:09 ` Ryan Chen
2023-03-07 10:09 ` Ryan Chen
2023-03-07 10:09 ` Ryan Chen
2023-03-07 10:09 ` Ryan Chen
2023-03-09 8:51 ` Krzysztof Kozlowski
2023-03-09 8:51 ` Krzysztof Kozlowski
2023-03-09 8:51 ` Krzysztof Kozlowski
2023-03-09 9:15 ` Ryan Chen
2023-03-09 9:15 ` Ryan Chen
2023-03-09 9:15 ` Ryan Chen
2023-03-09 9:15 ` Ryan Chen
2023-03-12 12:33 ` Andi Shyti
2023-03-12 12:33 ` Andi Shyti
2023-03-12 12:33 ` Andi Shyti
2023-03-12 12:33 ` Andi Shyti
2023-03-18 9:09 ` Andi Shyti
2023-03-18 9:09 ` Andi Shyti
2023-03-18 9:09 ` Andi Shyti
2023-03-18 9:09 ` Andi Shyti
2023-03-19 2:05 ` Ryan Chen
2023-03-19 2:05 ` Ryan Chen
2023-03-19 2:05 ` Ryan Chen
2023-03-19 2:05 ` Ryan Chen
2023-02-26 3:13 ` [PATCH v6 2/2] i2c: aspeed: support ast2600 i2cv new register mode driver Ryan Chen
2023-02-26 3:13 ` Ryan Chen
2023-02-26 3:13 ` Ryan Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8999ef4a57b035a81b086d8732d119638d46968c.camel@codeconstruct.com.au \
--to=jk@codeconstruct.com.au \
--cc=linux-aspeed@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.