| Message ID | 20211005143748.2471647-3-pan@semihalf.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add support for the Mercury+ AA1 module | expand |
On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote: > > On SoCFPGA systems, it's desireable to have fixed numbering for > i2c busses, while being able to enable/disable them (e.g. have i2c1 > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also > be achieved using devicetree aliases (see i2c_add_adapter). However, > having the driver be self-contained without relying on aliases is more > robust. > > Signed-off-by: Paweł Anikiel <pan@semihalf.com> I don't see how adding a nonstandard property in one of the i2c bus drivers helps at all. How do you expect this to work when there are multiple i2c controllers in the system using different drivers? What should happen if both an alias and the busno property are set? Arnd
On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote: > On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote: > > > > On SoCFPGA systems, it's desireable to have fixed numbering for > > i2c busses, while being able to enable/disable them (e.g. have i2c1 > > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also > > be achieved using devicetree aliases (see i2c_add_adapter). However, > > having the driver be self-contained without relying on aliases is more > > robust. > > > > Signed-off-by: Paweł Anikiel <pan@semihalf.com> > > I don't see how adding a nonstandard property in one of the i2c bus > drivers helps at all. How do you expect this to work when there are > multiple i2c controllers in the system using different drivers? What > should happen if both an alias and the busno property are set? > What happens when two nodes have the same busno property because e.g. one is in a dtsi and the other one is in a dts?
On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni < alexandre.belloni@bootlin.com> wrote: > On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote: > > On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote: > > > > > > On SoCFPGA systems, it's desireable to have fixed numbering for > > > i2c busses, while being able to enable/disable them (e.g. have i2c1 > > > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also > > > be achieved using devicetree aliases (see i2c_add_adapter). However, > > > having the driver be self-contained without relying on aliases is more > > > robust. > > > > > > Signed-off-by: Paweł Anikiel <pan@semihalf.com> > > > > I don't see how adding a nonstandard property in one of the i2c bus > > drivers helps at all. How do you expect this to work when there are > > multiple i2c controllers in the system using different drivers? What > > should happen if both an alias and the busno property are set? > > > > What happens when two nodes have the same busno property because e.g. > one is in a dtsi and the other one is in a dts? > If busno is set, the alias is ignored (the code that checks aliases is never reached). If two nodes have the same busno property, we get a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them gets attached. What is a better way of doing this then? Is adding aliases to the devicetree like this okay? aliases { ... i2c0 = &i2c0; i2c1 = &i2c1; };
On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote: > > On Tue, Oct 5, 2021 at 4:37 PM Paweł Anikiel <pan@semihalf.com> wrote: > > > > > > On SoCFPGA systems, it's desireable to have fixed numbering for > > > i2c busses, while being able to enable/disable them (e.g. have i2c1 > > > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also > > > be achieved using devicetree aliases (see i2c_add_adapter). However, > > > having the driver be self-contained without relying on aliases is more > > > robust. > > > > > > Signed-off-by: Paweł Anikiel <pan@semihalf.com> > > > > I don't see how adding a nonstandard property in one of the i2c bus > > drivers helps at all. How do you expect this to work when there are > > multiple i2c controllers in the system using different drivers? What > > should happen if both an alias and the busno property are set? > > > > What happens when two nodes have the same busno property because e.g. > one is in a dtsi and the other one is in a dts? > If busno is set, the alias is ignored (the code that checks aliases is never reached). If two nodes have the same busno property, we get a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them gets attached. What is a better way of doing this then? Is adding aliases to the devicetree like this okay? aliases { ... i2c0 = &i2c0; i2c1 = &i2c1; };
On Wed, Oct 6, 2021 at 11:21 AM Paweł Anikiel <pan@semihalf.com> wrote: > On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: >> >> What happens when two nodes have the same busno property because e.g. >> one is in a dtsi and the other one is in a dts? > > > If busno is set, the alias is ignored (the code that checks aliases > is never reached). If two nodes have the same busno property, we get > a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them > gets attached. > > What is a better way of doing this then? Is adding aliases to the > devicetree like this okay? > > aliases { > ... > i2c0 = &i2c0; > i2c1 = &i2c1; > }; Yes, this is the normal way to do it. The way I tend to think of it is that the soc.dtsi file contains a description of hardware that exists inside of the chip and is as much as possible detached from how an OS uses it or what is connected to it on the outside. You then have the board.dts file that contains everything specific to the board. The /chosen and /aliases nodes in turn are specific to the individual machine, based on local configuration, installed OS and boot loader, and how the devices on the board are used. We tend to have the /aliases node populated with a sensible configuration of how we expect them to be used for a given board. So if your machine connects two of the internal i2c buses on the SoC, it makes sense to assign them the aliases i2c0 and i2c1. On the other hand, if one of them is not connected anywhere, you may skip that, or if there is an additional i2c controller in programmable logic or behind some gpio lines, you can make that your i2c0 alias. Arnd
diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml index d9293c57f573..1e02ddcbd690 100644 --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml @@ -93,6 +93,11 @@ properties: - const: tx - const: rx + busno: + description: | + The property should contain the desired bus number (as opposed to + being assigned automatically) + unevaluatedProperties: false required:
On SoCFPGA systems, it's desireable to have fixed numbering for i2c busses, while being able to enable/disable them (e.g. have i2c1 be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also be achieved using devicetree aliases (see i2c_add_adapter). However, having the driver be self-contained without relying on aliases is more robust. Signed-off-by: Paweł Anikiel <pan@semihalf.com> --- .../devicetree/bindings/i2c/snps,designware-i2c.yaml | 5 +++++ 1 file changed, 5 insertions(+)