From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
devicetree@vger.kernel.org
Cc: linux-aspeed@lists.ozlabs.org, linux-i3c@lists.infradead.org,
Rob Herring <robh+dt@kernel.org>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Dylan Hung <dylan_hung@aspeedtech.com>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>
Subject: Re: [RFC PATCH] dt-bindings: Add AST2600 i3c controller binding
Date: Mon, 13 Feb 2023 22:04:50 +0800 [thread overview]
Message-ID: <2528217bf1d43b834587cc0e399d7e86695bd390.camel@codeconstruct.com.au> (raw)
In-Reply-To: <71aeb3da-13a1-1c79-9fe6-f5c23d398394@linaro.org>
Hi Krzysztof,
> > Yes, that's essentially what I'm looking for with this change -
> > particularly with the pullup config, which (as you say) could
> > arguably
> > be a pinctrl config instead.
>
> Depends, there was just a short sentence. If this is external
> resistor
> on the board, why this device needs such property (and none of other
> devices need...)? If this is internal pull up of I3C (and there is no
> other pin configuration possible, no other pins), it looks reasonable
> to me to have it here. But I am all guessing it...
It's the second case: there is a configurable pullup resistor in each of
the i3c controllers (or, more accurately: in the ast2600's glue
between the SoC and the I3C IP block).
The pullup configuration is controlled by the SoC "global" i3c
registers; a block shared by all of the SoC's i3c controllers. So, any
driver implementation would need to set up that global register
configuration on i3c controller init.
So, I can see two options for the binding (and consequently the driver
implementation):
1) the sda-pullup-ohms property on the controller binding, which a
driver implementation could set directly through the global register
set
2) define a pin controller on the global register block, allowing other
(standard) DT pinctrl definitions to control the pullup calue. This
would need a new driver implementation for the pin controller, but that
shouldn't be too complex to implement.
For the binding proposed here, I've chosen (1). We can handle all of the
other (non-pullup-related) global register configuration by treating the
globals as a simple generic syscon device.
I'm happy to try (2) instead, if that's the better approach. However,
that may be over-engineering the binding spec (and consequently, the
necessary driver implementation) for just setting a register value.
From your second point:
> (and there is no other pin configuration possible, no other pins)
This is a fairly small and isolated component of the global ast2600 pin
configuration; the pullup value is set separately from the
already-implemented SoC-wide pinctrl. Merging the pullup values into
that wouldn't really fit the hardware interface mode though; this is a
separate IP block linked to the i3c controllers.
Let me know if you have any preferences on the approach to a biding
structure.
And Andrew: let me know if your experience with the ast2600 SoC's
pinctrl would suggest either option.
Cheers,
Jeremy
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2023-02-15 10:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 7:41 [RFC PATCH] dt-bindings: Add AST2600 i3c controller binding Jeremy Kerr
2023-02-13 8:42 ` Krzysztof Kozlowski
2023-02-13 8:55 ` Jeremy Kerr
2023-02-13 9:05 ` Krzysztof Kozlowski
2023-02-13 9:21 ` Jeremy Kerr
2023-02-13 9:35 ` Krzysztof Kozlowski
2023-02-13 14:04 ` Jeremy Kerr [this message]
2023-02-13 15:09 ` Rob Herring
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=2528217bf1d43b834587cc0e399d7e86695bd390.camel@codeconstruct.com.au \
--to=jk@codeconstruct.com.au \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@aj.id.au \
--cc=devicetree@vger.kernel.org \
--cc=dylan_hung@aspeedtech.com \
--cc=joel@jms.id.au \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-i3c@lists.infradead.org \
--cc=robh+dt@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox