* [PATCH v2 0/4] Add support for the Mercury+ AA1 module [not found] <20211005143744.Ya-FNxPYj6F7VrdWeF9qPn7E8MK-ZAw5BpQ_41CqBLY@z> @ 2021-10-05 14:37 ` Paweł Anikiel [not found] ` <20211005143745.KzSPsixDL4qG7NmMnTdV7Cu5_ERt2hASRD4vxiWs0nw@z> ` (3 more replies) 0 siblings, 4 replies; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20211005143745.KzSPsixDL4qG7NmMnTdV7Cu5_ERt2hASRD4vxiWs0nw@z>]
* [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller [not found] ` <20211005143745.KzSPsixDL4qG7NmMnTdV7Cu5_ERt2hASRD4vxiWs0nw@z> @ 2021-10-05 14:37 ` Paweł Anikiel [not found] ` <20211005161957.T5wmze4erQwVaJ_Qz6HuYpG-tazZVAsCNsrUKO-yStE@z> 0 siblings, 1 reply; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 15+ messages in thread
[parent not found: <20211005161957.T5wmze4erQwVaJ_Qz6HuYpG-tazZVAsCNsrUKO-yStE@z>]
* Re: [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller [not found] ` <20211005161957.T5wmze4erQwVaJ_Qz6HuYpG-tazZVAsCNsrUKO-yStE@z> @ 2021-10-05 16:19 ` Andy Shevchenko 0 siblings, 0 replies; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>]
* [PATCH v2 2/4] dt-bindings: add bus number property [not found] ` <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z> @ 2021-10-05 14:37 ` Paweł Anikiel [not found] ` <20211005162212.TBayj1cRWFPMW12JtO9UGqTBB0s8Z9dPi6yMlWIFDu4@z> [not found] ` <20211014164648.M1uKnzcw4t5Jv7OPB9trVkB5i-AW_cXSVgUekIUW13c@z> 1 sibling, 1 reply; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 15+ messages in thread
[parent not found: <20211005162212.TBayj1cRWFPMW12JtO9UGqTBB0s8Z9dPi6yMlWIFDu4@z>]
* Re: [PATCH v2 2/4] dt-bindings: add bus number property [not found] ` <20211005162212.TBayj1cRWFPMW12JtO9UGqTBB0s8Z9dPi6yMlWIFDu4@z> @ 2021-10-05 16:22 ` Arnd Bergmann 2021-10-05 16:22 ` Arnd Bergmann [not found] ` <20211005162816.BPDIv2pF16bxw77sA5vfuNPngDocmoVgJebhwWNW2TA@z> 0 siblings, 2 replies; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ 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:22 ` Arnd Bergmann [not found] ` <20211005162816.BPDIv2pF16bxw77sA5vfuNPngDocmoVgJebhwWNW2TA@z> 1 sibling, 0 replies; 15+ 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] 15+ messages in thread
[parent not found: <20211005162816.BPDIv2pF16bxw77sA5vfuNPngDocmoVgJebhwWNW2TA@z>]
* Re: [PATCH v2 2/4] dt-bindings: add bus number property [not found] ` <20211005162816.BPDIv2pF16bxw77sA5vfuNPngDocmoVgJebhwWNW2TA@z> @ 2021-10-05 16:28 ` Alexandre Belloni 2021-10-06 9:21 ` Paweł Anikiel [not found] ` <20211006092903.A-w9OTOPZGWXPAJIqh-5D8g9oKE98CQ5F_LqTxvtFXQ@z> 0 siblings, 2 replies; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ 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:21 ` Paweł Anikiel [not found] ` <20211006094117.AQee7MSq4c78svBS2Xfh4K4zh5TGQHOfUAbB4byqcCc@z> [not found] ` <20211006092903.A-w9OTOPZGWXPAJIqh-5D8g9oKE98CQ5F_LqTxvtFXQ@z> 1 sibling, 1 reply; 15+ messages in thread From: Paweł Anikiel @ 2021-10-06 9:21 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 [-- Attachment #1: Type: text/plain, Size: 1484 bytes --] 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; }; [-- Attachment #2: Type: text/html, Size: 2054 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20211006094117.AQee7MSq4c78svBS2Xfh4K4zh5TGQHOfUAbB4byqcCc@z>]
* Re: [PATCH v2 2/4] dt-bindings: add bus number property [not found] ` <20211006094117.AQee7MSq4c78svBS2Xfh4K4zh5TGQHOfUAbB4byqcCc@z> @ 2021-10-06 9:41 ` Arnd Bergmann 2021-10-06 9:41 ` Arnd Bergmann 0 siblings, 1 reply; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 2/4] dt-bindings: add bus number property 2021-10-06 9:41 ` Arnd Bergmann @ 2021-10-06 9:41 ` Arnd Bergmann 0 siblings, 0 replies; 15+ 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] 15+ messages in thread
[parent not found: <20211006092903.A-w9OTOPZGWXPAJIqh-5D8g9oKE98CQ5F_LqTxvtFXQ@z>]
* Re: [PATCH v2 2/4] dt-bindings: add bus number property [not found] ` <20211006092903.A-w9OTOPZGWXPAJIqh-5D8g9oKE98CQ5F_LqTxvtFXQ@z> @ 2021-10-06 9:29 ` Paweł Anikiel 2021-10-06 9:29 ` Paweł Anikiel 0 siblings, 1 reply; 15+ 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; }; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 2/4] dt-bindings: add bus number property 2021-10-06 9:29 ` Paweł Anikiel @ 2021-10-06 9:29 ` Paweł Anikiel 0 siblings, 0 replies; 15+ 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] 15+ messages in thread
[parent not found: <20211014164648.M1uKnzcw4t5Jv7OPB9trVkB5i-AW_cXSVgUekIUW13c@z>]
* Re: [PATCH v2 2/4] dt-bindings: add bus number property [not found] ` <20211014164648.M1uKnzcw4t5Jv7OPB9trVkB5i-AW_cXSVgUekIUW13c@z> @ 2021-10-14 16:46 ` Rob Herring 0 siblings, 0 replies; 15+ 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> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <20211005143747.DbuXJjyVqQGuiZ84zqR8E7krMYcbgI2hOXzeTz-G9EQ@z>]
* [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe [not found] ` <20211005143747.DbuXJjyVqQGuiZ84zqR8E7krMYcbgI2hOXzeTz-G9EQ@z> @ 2021-10-05 14:37 ` Paweł Anikiel 0 siblings, 0 replies; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 15+ messages in thread
[parent not found: <20211005143748.I4_BMbwCzbJqDZM7MjSm0kkCQvrzHpNje3IF2f1tyyo@z>]
* [PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree [not found] ` <20211005143748.I4_BMbwCzbJqDZM7MjSm0kkCQvrzHpNje3IF2f1tyyo@z> @ 2021-10-05 14:37 ` Paweł Anikiel 0 siblings, 0 replies; 15+ 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-10-14 16:48 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20211005143744.Ya-FNxPYj6F7VrdWeF9qPn7E8MK-ZAw5BpQ_41CqBLY@z> 2021-10-05 14:37 ` [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel [not found] ` <20211005143745.KzSPsixDL4qG7NmMnTdV7Cu5_ERt2hASRD4vxiWs0nw@z> 2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel [not found] ` <20211005161957.T5wmze4erQwVaJ_Qz6HuYpG-tazZVAsCNsrUKO-yStE@z> 2021-10-05 16:19 ` Andy Shevchenko [not found] ` <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z> 2021-10-05 14:37 ` [PATCH v2 2/4] dt-bindings: add bus number property Paweł Anikiel [not found] ` <20211005162212.TBayj1cRWFPMW12JtO9UGqTBB0s8Z9dPi6yMlWIFDu4@z> 2021-10-05 16:22 ` Arnd Bergmann 2021-10-05 16:22 ` Arnd Bergmann [not found] ` <20211005162816.BPDIv2pF16bxw77sA5vfuNPngDocmoVgJebhwWNW2TA@z> 2021-10-05 16:28 ` Alexandre Belloni 2021-10-06 9:21 ` Paweł Anikiel [not found] ` <20211006094117.AQee7MSq4c78svBS2Xfh4K4zh5TGQHOfUAbB4byqcCc@z> 2021-10-06 9:41 ` Arnd Bergmann 2021-10-06 9:41 ` Arnd Bergmann [not found] ` <20211006092903.A-w9OTOPZGWXPAJIqh-5D8g9oKE98CQ5F_LqTxvtFXQ@z> 2021-10-06 9:29 ` Paweł Anikiel 2021-10-06 9:29 ` Paweł Anikiel [not found] ` <20211014164648.M1uKnzcw4t5Jv7OPB9trVkB5i-AW_cXSVgUekIUW13c@z> 2021-10-14 16:46 ` Rob Herring [not found] ` <20211005143747.DbuXJjyVqQGuiZ84zqR8E7krMYcbgI2hOXzeTz-G9EQ@z> 2021-10-05 14:37 ` [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe Paweł Anikiel [not found] ` <20211005143748.I4_BMbwCzbJqDZM7MjSm0kkCQvrzHpNje3IF2f1tyyo@z> 2021-10-05 14:37 ` [PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree Paweł Anikiel
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).