* [PATCH v4 0/2] i2c: mv64xxx: reset-gpios @ 2023-10-24 22:30 Chris Packham 2023-10-24 22:30 ` [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property Chris Packham 2023-10-24 22:30 ` [PATCH v4 2/2] i2c: mv64xxx: add an optional " Chris Packham 0 siblings, 2 replies; 7+ messages in thread From: Chris Packham @ 2023-10-24 22:30 UTC (permalink / raw) To: gregory.clement, andi.shyti, robh+dt, krzysztof.kozlowski+dt, conor+dt Cc: linux-i2c, devicetree, linux-kernel, Chris Packham This series adds the ability to associate a gpio with an I2C bus so that downstream devices can be brought out of reset when the host controller is probed. Chris Packham (2): dt-bindings: i2c: mv64xxx: add reset-gpios property i2c: mv64xxx: add an optional reset-gpios property .../bindings/i2c/marvell,mv64xxx-i2c.yaml | 10 ++++++++++ drivers/i2c/busses/i2c-mv64xxx.c | 16 ++++++++++++++++ 2 files changed, 26 insertions(+) -- 2.42.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property 2023-10-24 22:30 [PATCH v4 0/2] i2c: mv64xxx: reset-gpios Chris Packham @ 2023-10-24 22:30 ` Chris Packham 2023-10-24 23:29 ` Andi Shyti 2023-10-26 11:15 ` Wolfram Sang 2023-10-24 22:30 ` [PATCH v4 2/2] i2c: mv64xxx: add an optional " Chris Packham 1 sibling, 2 replies; 7+ messages in thread From: Chris Packham @ 2023-10-24 22:30 UTC (permalink / raw) To: gregory.clement, andi.shyti, robh+dt, krzysztof.kozlowski+dt, conor+dt Cc: linux-i2c, devicetree, linux-kernel, Chris Packham Add reset-gpios and reset-duration-us properties to the marvell,mv64xxx-i2c binding. These can be used to describe hardware where a common reset GPIO is connected to all downstream devices on and I2C bus. This reset will be asserted then released before the downstream devices on the bus are probed. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- Notes: Changes in v4: - Add r-by from Krzysztof Changes in v3: - Rename reset-delay-us to reset-duration-us to better reflect its purpose - Add default: for reset-duration-us - Add description: for reset-gpios Changes in v2: - Update commit message - Add reset-delay-us property .../devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml index 461d1c9ee3f7..ecf5b279cfa4 100644 --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -70,6 +70,16 @@ properties: resets: maxItems: 1 + reset-gpios: + description: + GPIO pin providing a common reset for all downstream devices. This GPIO + will be asserted then released before the downstream devices are probed. + maxItems: 1 + + reset-duration-us: + description: Reset duration in us. + default: 1 + dmas: items: - description: RX DMA Channel -- 2.42.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property 2023-10-24 22:30 ` [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property Chris Packham @ 2023-10-24 23:29 ` Andi Shyti 2023-10-26 11:15 ` Wolfram Sang 1 sibling, 0 replies; 7+ messages in thread From: Andi Shyti @ 2023-10-24 23:29 UTC (permalink / raw) To: Chris Packham Cc: gregory.clement, robh+dt, krzysztof.kozlowski+dt, conor+dt, linux-i2c, devicetree, linux-kernel Hi Chris, On Wed, Oct 25, 2023 at 11:30:31AM +1300, Chris Packham wrote: > Add reset-gpios and reset-duration-us properties to the > marvell,mv64xxx-i2c binding. These can be used to describe hardware > where a common reset GPIO is connected to all downstream devices on and > I2C bus. This reset will be asserted then released before the downstream > devices on the bus are probed. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Andi Shyti <andi.shyti@kernel.org> Thanks, Andi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property 2023-10-24 22:30 ` [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property Chris Packham 2023-10-24 23:29 ` Andi Shyti @ 2023-10-26 11:15 ` Wolfram Sang 2023-10-26 20:04 ` Chris Packham 1 sibling, 1 reply; 7+ messages in thread From: Wolfram Sang @ 2023-10-26 11:15 UTC (permalink / raw) To: Chris Packham Cc: gregory.clement, andi.shyti, robh+dt, krzysztof.kozlowski+dt, conor+dt, linux-i2c, devicetree, linux-kernel [-- Attachment #1: Type: text/plain, Size: 451 bytes --] > + reset-gpios: > + description: > + GPIO pin providing a common reset for all downstream devices. This GPIO > + will be asserted then released before the downstream devices are probed. How about renaming this to "bus-reset-gpios"? Reason: When I read "reset-gpios", then I assume the device itself will be reset. In this case, the Marvell I2C controller. Some I2C mux devices and PCA9564 already use the property like I described. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property 2023-10-26 11:15 ` Wolfram Sang @ 2023-10-26 20:04 ` Chris Packham 0 siblings, 0 replies; 7+ messages in thread From: Chris Packham @ 2023-10-26 20:04 UTC (permalink / raw) To: Wolfram Sang, gregory.clement@bootlin.com, andi.shyti@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org (resend as plain text) On 27/10/23 00:15, Wolfram Sang wrote: >> + reset-gpios: >> + description: >> + GPIO pin providing a common reset for all downstream devices. This GPIO >> + will be asserted then released before the downstream devices are probed. > How about renaming this to "bus-reset-gpios"? > > Reason: When I read "reset-gpios", then I assume the device itself will > be reset. In this case, the Marvell I2C controller. Some I2C mux devices > and PCA9564 already use the property like I described. I don't have an objection to "bus-reset-gpios" it would be trivial for me to spin a v5 with the naming changed if everyone is in agreement (given my timezone I might just send out a v5 with this change and then it can be argued whether to apply v4 or v5). ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v4 2/2] i2c: mv64xxx: add an optional reset-gpios property 2023-10-24 22:30 [PATCH v4 0/2] i2c: mv64xxx: reset-gpios Chris Packham 2023-10-24 22:30 ` [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property Chris Packham @ 2023-10-24 22:30 ` Chris Packham 2023-10-24 23:30 ` Andi Shyti 1 sibling, 1 reply; 7+ messages in thread From: Chris Packham @ 2023-10-24 22:30 UTC (permalink / raw) To: gregory.clement, andi.shyti, robh+dt, krzysztof.kozlowski+dt, conor+dt Cc: linux-i2c, devicetree, linux-kernel, Chris Packham Some hardware designs have a GPIO used to control the reset of all the devices on and I2C bus. It's not possible for every child node to declare a reset-gpios property as only the first device probed would be able to successfully request it (the others will get -EBUSY). Represent this kind of hardware design by associating the reset-gpios with the parent I2C bus. The reset line will be released prior to the child I2C devices being probed. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> --- Notes: Changes in v4: - Add missing gpio/consumer.h - use fsleep() for enforcing reset-duration Changes in v3: - Rename reset-delay to reset-duration - Use reset-duration-us property to control the reset pulse rather than delaying after the reset Changes in v2: - Add a property to cover the length of delay after releasing the reset GPIO - Use dev_err_probe() when requesing the GPIO fails drivers/i2c/busses/i2c-mv64xxx.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c index efd28bbecf61..a7c6617655f7 100644 --- a/drivers/i2c/busses/i2c-mv64xxx.c +++ b/drivers/i2c/busses/i2c-mv64xxx.c @@ -13,6 +13,7 @@ #include <linux/slab.h> #include <linux/module.h> #include <linux/spinlock.h> +#include <linux/gpio/consumer.h> #include <linux/i2c.h> #include <linux/interrupt.h> #include <linux/mv643xx_i2c.h> @@ -160,6 +161,7 @@ struct mv64xxx_i2c_data { bool clk_n_base_0; struct i2c_bus_recovery_info rinfo; bool atomic; + struct gpio_desc *reset_gpio; }; static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = { @@ -1036,6 +1038,7 @@ mv64xxx_i2c_probe(struct platform_device *pd) struct mv64xxx_i2c_data *drv_data; struct mv64xxx_i2c_pdata *pdata = dev_get_platdata(&pd->dev); struct resource *res; + u32 reset_duration; int rc; if ((!pdata && !pd->dev.of_node)) @@ -1083,6 +1086,14 @@ mv64xxx_i2c_probe(struct platform_device *pd) if (drv_data->irq < 0) return drv_data->irq; + drv_data->reset_gpio = devm_gpiod_get_optional(&pd->dev, "reset", GPIOD_OUT_HIGH); + if (IS_ERR(drv_data->reset_gpio)) + return dev_err_probe(&pd->dev, PTR_ERR(drv_data->reset_gpio), + "Cannot get reset gpio\n"); + rc = device_property_read_u32(&pd->dev, "reset-duration-us", &reset_duration); + if (rc) + reset_duration = 1; + if (pdata) { drv_data->freq_m = pdata->freq_m; drv_data->freq_n = pdata->freq_n; @@ -1121,6 +1132,11 @@ mv64xxx_i2c_probe(struct platform_device *pd) goto exit_disable_pm; } + if (drv_data->reset_gpio) { + fsleep(reset_duration); + gpiod_set_value_cansleep(drv_data->reset_gpio, 0); + } + rc = request_irq(drv_data->irq, mv64xxx_i2c_intr, 0, MV64XXX_I2C_CTLR_NAME, drv_data); if (rc) { -- 2.42.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v4 2/2] i2c: mv64xxx: add an optional reset-gpios property 2023-10-24 22:30 ` [PATCH v4 2/2] i2c: mv64xxx: add an optional " Chris Packham @ 2023-10-24 23:30 ` Andi Shyti 0 siblings, 0 replies; 7+ messages in thread From: Andi Shyti @ 2023-10-24 23:30 UTC (permalink / raw) To: Chris Packham Cc: gregory.clement, robh+dt, krzysztof.kozlowski+dt, conor+dt, linux-i2c, devicetree, linux-kernel Hi Chris, On Wed, Oct 25, 2023 at 11:30:32AM +1300, Chris Packham wrote: > Some hardware designs have a GPIO used to control the reset of all the > devices on and I2C bus. It's not possible for every child node to > declare a reset-gpios property as only the first device probed would be > able to successfully request it (the others will get -EBUSY). Represent > this kind of hardware design by associating the reset-gpios with the > parent I2C bus. The reset line will be released prior to the child I2C > devices being probed. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Thanks, Andi ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-10-26 20:04 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-24 22:30 [PATCH v4 0/2] i2c: mv64xxx: reset-gpios Chris Packham 2023-10-24 22:30 ` [PATCH v4 1/2] dt-bindings: i2c: mv64xxx: add reset-gpios property Chris Packham 2023-10-24 23:29 ` Andi Shyti 2023-10-26 11:15 ` Wolfram Sang 2023-10-26 20:04 ` Chris Packham 2023-10-24 22:30 ` [PATCH v4 2/2] i2c: mv64xxx: add an optional " Chris Packham 2023-10-24 23:30 ` Andi Shyti
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).