LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH v2 0/4] Add support for the Mercury+ AA1 module
@ 2021-10-05 14:37 Paweł Anikiel
  2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel
                   ` (4 more replies)
  0 siblings, 5 replies; 11+ messages in thread
From: Paweł Anikiel @ 2021-10-05 14:37 UTC (permalink / raw)
  To: jarkko.nikula, andriy.shevchenko, mika.westerberg, robh+dt,
	p.zabel, arnd, olof, soc, dinguyen, p.yadav, Tudor.Ambarus
  Cc: linux-i2c, linux-kernel, alexandre.belloni, sre, thunder.leizhen,
	Jonathan.Cameron, devicetree, linux-arm-kernel, ka, tn, jam,
	amstan, Paweł Anikiel

The following patches add support for the Mercury+ AA1 with an
Arria 10 SoCFPGA.

This version differs from the previous one by removing the spi
flash node, renaming the memory and mdio nodes, adding gpio nodes,
and adding a bus number property to Synopsys DesignWare i2c
controller node.

Paweł Anikiel (4):
  i2c: check bus number property in DesignWare I2C Controller
  dt-bindings: add bus number property
  reset: socfpga: add empty driver allowing consumers to probe
  dts: socfpga: Add Mercury+ AA1 devicetree

 .../bindings/i2c/snps,designware-i2c.yaml     |  5 +
 arch/arm/boot/dts/Makefile                    |  1 +
 .../boot/dts/socfpga_arria10_mercury_aa1.dts  | 99 +++++++++++++++++++
 drivers/i2c/busses/i2c-designware-platdrv.c   |  3 +-
 drivers/reset/reset-socfpga.c                 | 26 +++++
 5 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts

-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller
  2021-10-05 14:37 [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel
@ 2021-10-05 14:37 ` Paweł Anikiel
  2021-10-05 16:19   ` Andy Shevchenko
  2021-10-05 14:37 ` [PATCH v2 2/4] dt-bindings: add bus number property Paweł Anikiel
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 11+ messages in thread
From: Paweł Anikiel @ 2021-10-05 14:37 UTC (permalink / raw)
  To: jarkko.nikula, andriy.shevchenko, mika.westerberg, robh+dt,
	p.zabel, arnd, olof, soc, dinguyen, p.yadav, Tudor.Ambarus
  Cc: linux-i2c, linux-kernel, alexandre.belloni, sre, thunder.leizhen,
	Jonathan.Cameron, devicetree, linux-arm-kernel, ka, tn, jam,
	amstan, Paweł Anikiel

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>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 21113665ddea..f27e6bc9ad9d 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -280,7 +280,8 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
 					I2C_CLASS_HWMON : I2C_CLASS_DEPRECATED;
 	ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
 	adap->dev.of_node = pdev->dev.of_node;
-	adap->nr = -1;
+	if (of_property_read_u32(pdev->dev.of_node, "busno", &adap->nr))
+		adap->nr = -1;
 
 	if (dev->flags & ACCESS_NO_IRQ_SUSPEND) {
 		dev_pm_set_driver_flags(&pdev->dev,
-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v2 2/4] dt-bindings: add bus number property
  2021-10-05 14:37 [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel
  2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel
@ 2021-10-05 14:37 ` Paweł Anikiel
  2021-10-05 16:22   ` Arnd Bergmann
  2021-10-05 14:37 ` [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe Paweł Anikiel
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 11+ messages in thread
From: Paweł Anikiel @ 2021-10-05 14:37 UTC (permalink / raw)
  To: jarkko.nikula, andriy.shevchenko, mika.westerberg, robh+dt,
	p.zabel, arnd, olof, soc, dinguyen, p.yadav, Tudor.Ambarus
  Cc: linux-i2c, linux-kernel, alexandre.belloni, sre, thunder.leizhen,
	Jonathan.Cameron, devicetree, linux-arm-kernel, ka, tn, jam,
	amstan, Paweł Anikiel

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(+)

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:
-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe
  2021-10-05 14:37 [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel
  2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel
  2021-10-05 14:37 ` [PATCH v2 2/4] dt-bindings: add bus number property Paweł Anikiel
@ 2021-10-05 14:37 ` Paweł Anikiel
  2021-10-05 14:37 ` [PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree Paweł Anikiel
       [not found] ` <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>
  4 siblings, 0 replies; 11+ messages in thread
From: Paweł Anikiel @ 2021-10-05 14:37 UTC (permalink / raw)
  To: jarkko.nikula, andriy.shevchenko, mika.westerberg, robh+dt,
	p.zabel, arnd, olof, soc, dinguyen, p.yadav, Tudor.Ambarus
  Cc: linux-i2c, linux-kernel, alexandre.belloni, sre, thunder.leizhen,
	Jonathan.Cameron, devicetree, linux-arm-kernel, ka, tn, jam,
	amstan, Paweł Anikiel

The early reset driver doesn't ever probe, which causes consuming
devices to be unable to probe. Add an empty driver to set this device
as available, allowing consumers to probe.

Signed-off-by: Paweł Anikiel <pan@semihalf.com>
---
 drivers/reset/reset-socfpga.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index 2a72f861f798..8c6492e5693c 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -92,3 +92,29 @@ void __init socfpga_reset_init(void)
 	for_each_matching_node(np, socfpga_early_reset_dt_ids)
 		a10_reset_init(np);
 }
+
+/*
+ * The early driver is problematic, because it doesn't register
+ * itself as a driver. This causes certain device links to prevent
+ * consumer devices from probing. The hacky solution is to register
+ * an empty driver, whose only job is to attach itself to the reset
+ * manager and call probe.
+ */
+static const struct of_device_id socfpga_reset_dt_ids[] = {
+	{ .compatible = "altr,rst-mgr", },
+	{ /* sentinel */ },
+};
+
+static int reset_simple_probe(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static struct platform_driver reset_socfpga_driver = {
+	.probe	= reset_simple_probe,
+	.driver = {
+		.name		= "socfpga-reset",
+		.of_match_table	= socfpga_reset_dt_ids,
+	},
+};
+builtin_platform_driver(reset_socfpga_driver);
-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree
  2021-10-05 14:37 [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel
                   ` (2 preceding siblings ...)
  2021-10-05 14:37 ` [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe Paweł Anikiel
@ 2021-10-05 14:37 ` Paweł Anikiel
       [not found] ` <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>
  4 siblings, 0 replies; 11+ messages in thread
From: Paweł Anikiel @ 2021-10-05 14:37 UTC (permalink / raw)
  To: jarkko.nikula, andriy.shevchenko, mika.westerberg, robh+dt,
	p.zabel, arnd, olof, soc, dinguyen, p.yadav, Tudor.Ambarus
  Cc: linux-i2c, linux-kernel, alexandre.belloni, sre, thunder.leizhen,
	Jonathan.Cameron, devicetree, linux-arm-kernel, ka, tn, jam,
	amstan, Paweł Anikiel, Joanna Brozek, Mariusz Glebocki,
	Tomasz Gorochowik, Maciej Mikunda

Add support for the Mercury+ AA1 module for Arria 10 SoC FPGA.

Signed-off-by: Paweł Anikiel <pan@semihalf.com>
Signed-off-by: Joanna Brozek <jbrozek@antmicro.com>
Signed-off-by: Mariusz Glebocki <mglebocki@antmicro.com>
Signed-off-by: Tomasz Gorochowik <tgorochowik@antmicro.com>
Signed-off-by: Maciej Mikunda <mmikunda@antmicro.com>
---
 arch/arm/boot/dts/Makefile                    |   1 +
 .../boot/dts/socfpga_arria10_mercury_aa1.dts  | 111 ++++++++++++++++++
 2 files changed, 112 insertions(+)
 create mode 100644 arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e0934180724..0a7809eb3795 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1078,6 +1078,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += \
 	socfpga_arria10_socdk_nand.dtb \
 	socfpga_arria10_socdk_qspi.dtb \
 	socfpga_arria10_socdk_sdmmc.dtb \
+	socfpga_arria10_mercury_aa1.dtb \
 	socfpga_cyclone5_chameleon96.dtb \
 	socfpga_cyclone5_mcvevk.dtb \
 	socfpga_cyclone5_socdk.dtb \
diff --git a/arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts b/arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts
new file mode 100644
index 000000000000..1e11168b80db
--- /dev/null
+++ b/arch/arm/boot/dts/socfpga_arria10_mercury_aa1.dts
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "socfpga_arria10.dtsi"
+
+/ {
+
+	model = "Enclustra Mercury AA1";
+	compatible = "altr,socfpga-arria10", "altr,socfpga";
+
+	aliases {
+		ethernet0 = &gmac0;
+		serial1 = &uart1;
+	};
+
+	memory@0 {
+		name = "memory";
+		device_type = "memory";
+		reg = <0x0 0x80000000>; /* 2GB */
+	};
+
+	chosen {
+		stdout-path = "serial1:115200n8";
+	};
+};
+
+&eccmgr {
+	sdmmca-ecc@ff8c2c00 {
+		compatible = "altr,socfpga-sdmmc-ecc";
+		reg = <0xff8c2c00 0x400>;
+		altr,ecc-parent = <&mmc>;
+		interrupts = <15 IRQ_TYPE_LEVEL_HIGH>,
+			     <47 IRQ_TYPE_LEVEL_HIGH>,
+			     <16 IRQ_TYPE_LEVEL_HIGH>,
+			     <48 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+&gmac0 {
+	phy-mode = "rgmii";
+	phy-addr = <0xffffffff>; /* probe for phy addr */
+
+	max-frame-size = <3800>;
+	status = "okay";
+
+	phy-handle = <&phy3>;
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+		phy3: ethernet-phy@3 {
+			txd0-skew-ps = <0>; /* -420ps */
+			txd1-skew-ps = <0>; /* -420ps */
+			txd2-skew-ps = <0>; /* -420ps */
+			txd3-skew-ps = <0>; /* -420ps */
+			rxd0-skew-ps = <420>; /* 0ps */
+			rxd1-skew-ps = <420>; /* 0ps */
+			rxd2-skew-ps = <420>; /* 0ps */
+			rxd3-skew-ps = <420>; /* 0ps */
+			txen-skew-ps = <0>; /* -420ps */
+			txc-skew-ps = <1860>; /* 960ps */
+			rxdv-skew-ps = <420>; /* 0ps */
+			rxc-skew-ps = <1680>; /* 780ps */
+			reg = <3>;
+		};
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gpio1 {
+	status = "okay";
+};
+
+&gpio2 {
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+	busno = <1>;
+	isl12022: isl12022@6f {
+		status = "okay";
+		compatible = "isil,isl12022";
+		reg = <0x6f>;
+	};
+};
+
+/* Following mappings are taken from arria10 socdk dts */
+&mmc {
+	status = "okay";
+	cap-sd-highspeed;
+	broken-cd;
+	bus-width = <4>;
+};
+
+&osc1 {
+	clock-frequency = <33330000>;
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&usb0 {
+	status = "okay";
+	dr_mode = "host";
+};
-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller
  2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel
@ 2021-10-05 16:19   ` Andy Shevchenko
  0 siblings, 0 replies; 11+ messages in thread
From: Andy Shevchenko @ 2021-10-05 16:19 UTC (permalink / raw)
  To: Paweł Anikiel
  Cc: jarkko.nikula, mika.westerberg, robh+dt, p.zabel, arnd, olof,
	soc, dinguyen, p.yadav, Tudor.Ambarus, linux-i2c, linux-kernel,
	alexandre.belloni, sre, thunder.leizhen, Jonathan.Cameron,
	devicetree, linux-arm-kernel, ka, tn, jam, amstan

On Tue, Oct 05, 2021 at 04:37:45PM +0200, Paweł Anikiel 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.

Why? This number means nothing, user space has another means to have
this being robust. Sorry, but I don't see any even close to good enough
justification, NAK.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2 2/4] dt-bindings: add bus number property
  2021-10-05 14:37 ` [PATCH v2 2/4] dt-bindings: add bus number property Paweł Anikiel
@ 2021-10-05 16:22   ` Arnd Bergmann
  2021-10-05 16:28     ` Alexandre Belloni
  0 siblings, 1 reply; 11+ messages in thread
From: Arnd Bergmann @ 2021-10-05 16:22 UTC (permalink / raw)
  To: Paweł Anikiel
  Cc: jarkko.nikula, Andy Shevchenko, Mika Westerberg, Rob Herring,
	Philipp Zabel, Arnd Bergmann, Olof Johansson, SoC Team,
	Dinh Nguyen, Pratyush Yadav, Tudor Ambarus, Linux I2C,
	Linux Kernel Mailing List, Alexandre Belloni, Sebastian Reichel,
	Leizhen (ThunderTown),
	Jonathan Cameron, DTML, Linux ARM, ka, Tomasz Nowicki, jam,
	amstan

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2 2/4] dt-bindings: add bus number property
  2021-10-05 16:22   ` Arnd Bergmann
@ 2021-10-05 16:28     ` Alexandre Belloni
  2021-10-06  9:29       ` Paweł Anikiel
       [not found]       ` <CAF9_jYT6mbk6dr8=ZYZ8B=gxnuHas7QBfDfuoTJnMzSKZt=WGw@mail.gmail.com>
  0 siblings, 2 replies; 11+ messages in thread
From: Alexandre Belloni @ 2021-10-05 16:28 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Paweł Anikiel, jarkko.nikula, Andy Shevchenko,
	Mika Westerberg, Rob Herring, Philipp Zabel, Olof Johansson,
	SoC Team, Dinh Nguyen, Pratyush Yadav, Tudor Ambarus, Linux I2C,
	Linux Kernel Mailing List, Sebastian Reichel,
	Leizhen (ThunderTown),
	Jonathan Cameron, DTML, Linux ARM, ka, Tomasz Nowicki, jam,
	amstan

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?


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2 2/4] dt-bindings: add bus number property
  2021-10-05 16:28     ` Alexandre Belloni
@ 2021-10-06  9:29       ` Paweł Anikiel
       [not found]       ` <CAF9_jYT6mbk6dr8=ZYZ8B=gxnuHas7QBfDfuoTJnMzSKZt=WGw@mail.gmail.com>
  1 sibling, 0 replies; 11+ messages in thread
From: Paweł Anikiel @ 2021-10-06  9:29 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Arnd Bergmann, jarkko.nikula, Andy Shevchenko, Mika Westerberg,
	Rob Herring, Philipp Zabel, Olof Johansson, SoC Team,
	Dinh Nguyen, Pratyush Yadav, Tudor Ambarus, Linux I2C,
	Linux Kernel Mailing List, Sebastian Reichel,
	Leizhen (ThunderTown),
	Jonathan Cameron, DTML, Linux ARM, Konrad Adamczyk,
	Tomasz Nowicki, Jacek Majkowski, Alexandru Stan

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;
};

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2 2/4] dt-bindings: add bus number property
       [not found]       ` <CAF9_jYT6mbk6dr8=ZYZ8B=gxnuHas7QBfDfuoTJnMzSKZt=WGw@mail.gmail.com>
@ 2021-10-06  9:41         ` Arnd Bergmann
  0 siblings, 0 replies; 11+ messages in thread
From: Arnd Bergmann @ 2021-10-06  9:41 UTC (permalink / raw)
  To: Paweł Anikiel
  Cc: Alexandre Belloni, Arnd Bergmann, jarkko.nikula, Andy Shevchenko,
	Mika Westerberg, Rob Herring, Philipp Zabel, Olof Johansson,
	SoC Team, Dinh Nguyen, Pratyush Yadav, Tudor Ambarus, Linux I2C,
	Linux Kernel Mailing List, Sebastian Reichel,
	Leizhen (ThunderTown),
	Jonathan Cameron, DTML, Linux ARM, Konrad Adamczyk,
	Tomasz Nowicki, Jacek Majkowski, Alexandru Stan

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2 2/4] dt-bindings: add bus number property
       [not found] ` <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>
@ 2021-10-14 16:46   ` Rob Herring
  0 siblings, 0 replies; 11+ messages in thread
From: Rob Herring @ 2021-10-14 16:46 UTC (permalink / raw)
  To: Paweł Anikiel
  Cc: jarkko.nikula, andriy.shevchenko, mika.westerberg, p.zabel, arnd,
	olof, soc, dinguyen, p.yadav, Tudor.Ambarus, linux-i2c,
	linux-kernel, alexandre.belloni, sre, thunder.leizhen,
	Jonathan.Cameron, devicetree, linux-arm-kernel, ka, tn, jam,
	amstan

On Tue, Oct 05, 2021 at 04:37:46PM +0200, Paweł Anikiel 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.

Your header is a bit weird as you have 2 Message-IDs:

> Message-ID: <20211005143748.2471647-3-pan@semihalf.com>                                                                                                     
> X-Mailer: git-send-email 2.25.1                                                                                                                             
> Message-ID: <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>                                                                                  

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-10-14 16:47 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-05 14:37 [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel
2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel
2021-10-05 16:19   ` Andy Shevchenko
2021-10-05 14:37 ` [PATCH v2 2/4] dt-bindings: add bus number property Paweł Anikiel
2021-10-05 16:22   ` Arnd Bergmann
2021-10-05 16:28     ` Alexandre Belloni
2021-10-06  9:29       ` Paweł Anikiel
     [not found]       ` <CAF9_jYT6mbk6dr8=ZYZ8B=gxnuHas7QBfDfuoTJnMzSKZt=WGw@mail.gmail.com>
2021-10-06  9:41         ` Arnd Bergmann
2021-10-05 14:37 ` [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe Paweł Anikiel
2021-10-05 14:37 ` [PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree Paweł Anikiel
     [not found] ` <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>
2021-10-14 16:46   ` [PATCH v2 2/4] dt-bindings: add bus number property Rob Herring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).