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
next prev parent reply other threads:[~2023-02-26 7:04 UTC|newest]
Thread overview: 28+ 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 ` [PATCH v6 1/2] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 Ryan Chen
2023-02-26 7:04 ` Jeremy Kerr [this message]
2023-02-27 4:12 ` Ryan Chen
2023-02-27 5:40 ` Jeremy Kerr
2023-03-01 3:02 ` Ryan Chen
2023-03-01 3:23 ` Jeremy Kerr
2023-03-01 3:40 ` Ryan Chen
2023-02-27 8:25 ` Krzysztof Kozlowski
2023-03-01 5:57 ` Ryan Chen
2023-03-03 8:20 ` Krzysztof Kozlowski
2023-03-03 8:28 ` Ryan Chen
2023-03-03 8:50 ` Krzysztof Kozlowski
2023-03-03 8:55 ` Ryan Chen
2023-03-03 9:26 ` Krzysztof Kozlowski
2023-03-03 10:16 ` Ryan Chen
2023-03-03 10:41 ` Krzysztof Kozlowski
2023-03-04 1:33 ` Ryan Chen
2023-03-05 9:49 ` Krzysztof Kozlowski
2023-03-06 0:48 ` Ryan Chen
2023-03-07 8:11 ` Krzysztof Kozlowski
2023-03-07 10:09 ` Ryan Chen
2023-03-09 8:51 ` Krzysztof Kozlowski
2023-03-09 9:15 ` Ryan Chen
2023-03-12 12:33 ` Andi Shyti
2023-03-18 9:09 ` Andi Shyti
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
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=andrew@aj.id.au \
--cc=benh@kernel.crashing.org \
--cc=brendan.higgins@linux.dev \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=ryan_chen@aspeedtech.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox