This patch series does the following:
-Simplify with dev_err_probe().
-Reduce spinlock array to array.
-Add interrupt support
-Add support for suspend and resume
-Add check for gpio-width
---
Changes in V4:
-Created new patch to simplify code with dev_err_probe().
-Updated minor review comments.
-Created new patch to check gpio-width.
Changes in V3:
-Created separate patch to arrange headers in sorting order.
-Updated dt-bindings.
-Created separate patch for Clock changes and runtime resume.
and suspend.
-Created separate patch for spinlock changes.
-Created separate patch for remove support.
-Fixed coverity errors.
-Updated minor review comments.
Changes in V2:
-Added check for return value of platform_get_irq() API.
-Updated code to support rising edge and falling edge.
-Added xgpio_xlate() API to support switch.
-Added MAINTAINERS fragment.
Tested Below scenarios:
-Tested Loop Back.(channel 1.0 connected to channel 2.0)
-Tested External switch(Used DIP switch)
-Tested Cascade scenario(Here gpio controller acting as
an interrupt controller).
---
Srinivas Neeli (5):
gpio: gpio-xilinx: Simplify with dev_err_probe()
gpio: gpio-xilinx: Reduce spinlock array to array
gpio: gpio-xilinx: Add interrupt support
gpio: gpio-xilinx: Add support for suspend and resume
gpio: gpio-xilinx: Add check if width exceeds 32
drivers/gpio/Kconfig | 3 +
drivers/gpio/gpio-xilinx.c | 367 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 347 insertions(+), 23 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Srinivas Neeli <redacted>
---
Changes in V4:
-New patch
---
drivers/gpio/gpio-xilinx.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
@@ -357,11 +357,8 @@ static int xgpio_probe(struct platform_device *pdev)}chip->clk=devm_clk_get_optional(&pdev->dev,NULL);-if(IS_ERR(chip->clk)){-if(PTR_ERR(chip->clk)!=-EPROBE_DEFER)-dev_dbg(&pdev->dev,"Input clock not found\n");-returnPTR_ERR(chip->clk);-}+if(IS_ERR(chip->clk))+returndev_err_probe(&pdev->dev,PTR_ERR(chip->clk),"input clock not found.\n");status=clk_prepare_enable(chip->clk);if(status<0){
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Add check to see if gpio-width property does not exceed 32.
If it exceeds then return -EINVAL.
Signed-off-by: Srinivas Neeli <redacted>
---
Changes in V4:
-New patch.
---
drivers/gpio/gpio-xilinx.c | 5 +++++
1 file changed, 5 insertions(+)
Changed spinlock array to single. It is preparation for irq support which
is shared between two channels that's why spinlock should be only one.
Signed-off-by: Srinivas Neeli <redacted>
---
Changes in V4:
-None.
Changes in V3:
-Created new patch for spinlock changes.
---
drivers/gpio/gpio-xilinx.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
@@ -113,7 +113,7 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)intindex=xgpio_index(chip,gpio);intoffset=xgpio_offset(chip,gpio);-spin_lock_irqsave(&chip->gpio_lock[index],flags);+spin_lock_irqsave(&chip->gpio_lock,flags);/* Write to GPIO signal and set its direction to output */if(val)
@@ -124,7 +124,7 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)xgpio_writereg(chip->regs+XGPIO_DATA_OFFSET+xgpio_regoffset(chip,gpio),chip->gpio_state[index]);-spin_unlock_irqrestore(&chip->gpio_lock[index],flags);+spin_unlock_irqrestore(&chip->gpio_lock,flags);}/**
@@ -144,7 +144,7 @@ static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,intindex=xgpio_index(chip,0);intoffset,i;-spin_lock_irqsave(&chip->gpio_lock[index],flags);+spin_lock_irqsave(&chip->gpio_lock,flags);/* Write to GPIO signals */for(i=0;i<gc->ngpio;i++){
@@ -190,14 +190,14 @@ static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)intindex=xgpio_index(chip,gpio);intoffset=xgpio_offset(chip,gpio);-spin_lock_irqsave(&chip->gpio_lock[index],flags);+spin_lock_irqsave(&chip->gpio_lock,flags);/* Set the GPIO bit in shadow register and set direction as input */chip->gpio_dir[index]|=BIT(offset);xgpio_writereg(chip->regs+XGPIO_TRI_OFFSET+xgpio_regoffset(chip,gpio),chip->gpio_dir[index]);-spin_unlock_irqrestore(&chip->gpio_lock[index],flags);+spin_unlock_irqrestore(&chip->gpio_lock,flags);return0;}
@@ -221,7 +221,7 @@ static int xgpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)intindex=xgpio_index(chip,gpio);intoffset=xgpio_offset(chip,gpio);-spin_lock_irqsave(&chip->gpio_lock[index],flags);+spin_lock_irqsave(&chip->gpio_lock,flags);/* Write state of GPIO signal */if(val)
@@ -236,7 +236,7 @@ static int xgpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)xgpio_writereg(chip->regs+XGPIO_TRI_OFFSET+xgpio_regoffset(chip,gpio),chip->gpio_dir[index]);-spin_unlock_irqrestore(&chip->gpio_lock[index],flags);+spin_unlock_irqrestore(&chip->gpio_lock,flags);return0;}
@@ -312,7 +312,7 @@ static int xgpio_probe(struct platform_device *pdev)if(of_property_read_u32(np,"xlnx,gpio-width",&chip->gpio_width[0]))chip->gpio_width[0]=32;-spin_lock_init(&chip->gpio_lock[0]);+spin_lock_init(&chip->gpio_lock);if(of_property_read_u32(np,"xlnx,is-dual",&is_dual))is_dual=0;
@@ -336,7 +336,6 @@ static int xgpio_probe(struct platform_device *pdev)&chip->gpio_width[1]))chip->gpio_width[1]=32;-spin_lock_init(&chip->gpio_lock[1]);}chip->gc.base=-1;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Adds interrupt support to the Xilinx GPIO driver so that rising and
falling edge line events can be supported. Since interrupt support is
an optional feature in the Xilinx IP, the driver continues to support
devices which have no interrupt provided.
Depends on OF_GPIO framework for of_xlate function to translate
gpiospec to the GPIO number and flags.
Signed-off-by: Robert Hancock <redacted>
Signed-off-by: Shubhrajyoti Datta <redacted>
Signed-off-by: Srinivas Neeli <redacted>
---
Changes in V4:
-Added more commit description.
Changes in V3:
-Created separate patch for Clock changes and runtime resume
and suspend.
-Updated minor review comments.
Changes in V2:
-Added check for return value of platform_get_irq() API.
-Updated code to support rising edge and falling edge.
-Added xgpio_xlate() API to support switch.
-Added MAINTAINERS fragment.
---
drivers/gpio/Kconfig | 3 +
drivers/gpio/gpio-xilinx.c | 242 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 241 insertions(+), 4 deletions(-)
Add support for suspend and resume, pm runtime suspend and resume.
Added free and request calls.
Signed-off-by: Srinivas Neeli <redacted>
---
Changes in V4:
-Adjust code to remove conflicts.
Changes in V3:
-Created new patch for suspend and resume.
---
drivers/gpio/gpio-xilinx.c | 94 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 90 insertions(+), 4 deletions(-)
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Srinivas Neeli <redacted>
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
Changed spinlock array to single. It is preparation for irq support which
is shared between two channels that's why spinlock should be only one.
Signed-off-by: Srinivas Neeli <redacted>
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
Adds interrupt support to the Xilinx GPIO driver so that rising and
falling edge line events can be supported. Since interrupt support is
an optional feature in the Xilinx IP, the driver continues to support
devices which have no interrupt provided.
Depends on OF_GPIO framework for of_xlate function to translate
gpiospec to the GPIO number and flags.
Signed-off-by: Robert Hancock <redacted>
Signed-off-by: Shubhrajyoti Datta <redacted>
Signed-off-by: Srinivas Neeli <redacted>
This looks a bit dangerous. What actually happens if this is something
like 3. The translate function is not going to work. I would just dev_err()
and bail out if #gpio-cells != 2.
Other than that this looks good!
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
Add support for suspend and resume, pm runtime suspend and resume.
Added free and request calls.
Signed-off-by: Srinivas Neeli <redacted>
(...)
+static int xgpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+ int ret;
+
+ ret = pm_runtime_get_sync(chip->parent);
+ /*
+ * If the device is already active pm_runtime_get() will return 1 on
+ * success, but gpio_request still needs to return 0.
+ */
+ return ret < 0 ? ret : 0;
+}
That's clever. I think more GPIO drivers should be doing it like this,
today I think most just ignore the return code.
+static int __maybe_unused xgpio_suspend(struct device *dev)
+static int __maybe_unused xgpio_resume(struct device *dev)
Those look good.
quoted hunk
/**
* xgpio_remove - Remove method for the GPIO device.
* @pdev: pointer to the platform device
@@ -289,7 +323,10 @@ static int xgpio_remove(struct platform_device *pdev) { struct xgpio_instance *gpio = platform_get_drvdata(pdev);- clk_disable_unprepare(gpio->clk);+ if (!pm_runtime_suspended(&pdev->dev))+ clk_disable_unprepare(gpio->clk);++ pm_runtime_disable(&pdev->dev);
This looks complex and racy. What if the device is resumed after you
executed the
first part of the statement.
The normal sequence is:
pm_runtime_get_sync(dev);
pm_runtime_put_noidle(dev);
pm_runtime_disable(dev);
This will make sure the clock is enabled and pm runtime is disabled.
After this you can unconditionally call clk_disable_unprepare(gpio->clk);
It is what you are doing on the errorpath of probe().
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
Add check to see if gpio-width property does not exceed 32.
If it exceeds then return -EINVAL.
Signed-off-by: Srinivas Neeli <redacted>
Aha
quoted hunk
@@ -591,6 +591,9 @@ static int xgpio_probe(struct platform_device *pdev) if (of_property_read_u32(np, "xlnx,gpio-width", &chip->gpio_width[0])) chip->gpio_width[0] = 32;
This xlnx,gpio-width seems very much like the standard ngpios property
from Documentation/devicetree/bindings/gpio/gpio.txt
but I guess not much to do about that now. :/
Do you think you can add support for both?
From: Michal Simek <hidden> Date: 2021-01-07 10:30:39
On 07. 01. 21 11:17, Linus Walleij wrote:
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
quoted
Add check to see if gpio-width property does not exceed 32.
If it exceeds then return -EINVAL.
Signed-off-by: Srinivas Neeli <redacted>
Aha
quoted
@@ -591,6 +591,9 @@ static int xgpio_probe(struct platform_device *pdev) if (of_property_read_u32(np, "xlnx,gpio-width", &chip->gpio_width[0])) chip->gpio_width[0] = 32;
This xlnx,gpio-width seems very much like the standard ngpios property
from Documentation/devicetree/bindings/gpio/gpio.txt
but I guess not much to do about that now. :/
Do you think you can add support for both?
support for both is definitely possible but we need to handle also gpio
width for second channel referenced by xlnx,gpio2-widht now.
It means we could end up in situation which can be misleading for users
where ngpios will be 10 and xlnx,gpio2-width another 10 and in total we
have 20 gpios.
I think that it is better not to start to mess with ngpios property not
to confuse people which are coming from other SOCs because ngpios can
suggest all gpios assigned to this controller.
And in second case where ngpios is total number of gpios and if
xlnx,gpio2-width is defined you can find width for first bank.
But it is questionable if this improve situation here.
Please correct me if my logic is not correct.
Definitely this should be done separately out of this patch.
On Thu, Jan 7, 2021 at 11:29 AM Michal Simek [off-list ref] wrote:
On 07. 01. 21 11:17, Linus Walleij wrote:
quoted
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
quoted
quoted
@@ -591,6 +591,9 @@ static int xgpio_probe(struct platform_device *pdev) if (of_property_read_u32(np, "xlnx,gpio-width", &chip->gpio_width[0])) chip->gpio_width[0] = 32;
This xlnx,gpio-width seems very much like the standard ngpios property
from Documentation/devicetree/bindings/gpio/gpio.txt
but I guess not much to do about that now. :/
Do you think you can add support for both?
support for both is definitely possible but we need to handle also gpio
width for second channel referenced by xlnx,gpio2-widht now.
It means we could end up in situation which can be misleading for users
where ngpios will be 10 and xlnx,gpio2-width another 10 and in total we
have 20 gpios.
OK that is confusing. Let's not do that then.
I think that it is better not to start to mess with ngpios property not
to confuse people which are coming from other SOCs because ngpios can
suggest all gpios assigned to this controller.
OK I agree.
quoted
quoted
+ if (chip->gpio_width[0] > 32)
+ return -EINVAL;
This looks OK.
Does it mean ack for this patch?
Yeah after explanations this patch is fine:
Acked-by: Linus Walleij <redacted>
It's just that this hardware with paired controllers is a bit weird so it will
lead to discussions all the time because it's hard to understand.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Michal Simek <hidden> Date: 2021-01-07 10:54:02
On 07. 01. 21 11:47, Linus Walleij wrote:
On Thu, Jan 7, 2021 at 11:29 AM Michal Simek [off-list ref] wrote:
quoted
On 07. 01. 21 11:17, Linus Walleij wrote:
quoted
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref] wrote:
quoted
quoted
quoted
@@ -591,6 +591,9 @@ static int xgpio_probe(struct platform_device *pdev) if (of_property_read_u32(np, "xlnx,gpio-width", &chip->gpio_width[0])) chip->gpio_width[0] = 32;
This xlnx,gpio-width seems very much like the standard ngpios property
from Documentation/devicetree/bindings/gpio/gpio.txt
but I guess not much to do about that now. :/
Do you think you can add support for both?
support for both is definitely possible but we need to handle also gpio
width for second channel referenced by xlnx,gpio2-widht now.
It means we could end up in situation which can be misleading for users
where ngpios will be 10 and xlnx,gpio2-width another 10 and in total we
have 20 gpios.
OK that is confusing. Let's not do that then.
quoted
I think that it is better not to start to mess with ngpios property not
to confuse people which are coming from other SOCs because ngpios can
suggest all gpios assigned to this controller.
OK I agree.
quoted
quoted
quoted
+ if (chip->gpio_width[0] > 32)
+ return -EINVAL;
This looks OK.
Does it mean ack for this patch?
Yeah after explanations this patch is fine:
Acked-by: Linus Walleij <redacted>
It's just that this hardware with paired controllers is a bit weird so it will
lead to discussions all the time because it's hard to understand.
Maybe it should be described a little bit differently in DT.
Just to have gpio node and every bank could be described as a child node
where standard properties could be used and irq will be shared.
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-----Original Message-----
From: Linus Walleij <redacted>
Sent: Thursday, January 7, 2021 3:17 PM
To: Srinivas Neeli <redacted>
Cc: Bartosz Golaszewski <redacted>; Michal Simek
[off-list ref]; Shubhrajyoti Datta [off-list ref]; Srinivas
Goud [off-list ref]; Robert Hancock [off-list ref];
William Breathitt Gray [off-list ref]; Syed Nayyar Waris
[off-list ref]; open list:GPIO SUBSYSTEM <linux-
gpio@vger.kernel.org>; Linux ARM [off-list ref];
linux-kernel@vger.kernel.org; git [off-list ref]
Subject: Re: [PATCH V4 4/5] gpio: gpio-xilinx: Add support for suspend and
resume
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref]
wrote:
quoted
Add support for suspend and resume, pm runtime suspend and resume.
Added free and request calls.
Signed-off-by: Srinivas Neeli <redacted>
(...)
quoted
+static int xgpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+ int ret;
+
+ ret = pm_runtime_get_sync(chip->parent);
+ /*
+ * If the device is already active pm_runtime_get() will return 1 on
+ * success, but gpio_request still needs to return 0.
+ */
+ return ret < 0 ? ret : 0;
+}
That's clever. I think more GPIO drivers should be doing it like this, today I
think most just ignore the return code.
/**
* xgpio_remove - Remove method for the GPIO device.
* @pdev: pointer to the platform device @@ -289,7 +323,10 @@ static
int xgpio_remove(struct platform_device *pdev) {
struct xgpio_instance *gpio = platform_get_drvdata(pdev);
- clk_disable_unprepare(gpio->clk);
+ if (!pm_runtime_suspended(&pdev->dev))
+ clk_disable_unprepare(gpio->clk);
+
+ pm_runtime_disable(&pdev->dev);
This looks complex and racy. What if the device is resumed after you
executed the first part of the statement.
Could you please explain more on this.
What is the need to call pm_runtime_get_sync(); in remove API ?
The normal sequence is:
pm_runtime_get_sync(dev);
pm_runtime_put_noidle(dev);
pm_runtime_disable(dev);
This will make sure the clock is enabled and pm runtime is disabled.
After this you can unconditionally call clk_disable_unprepare(gpio->clk);
It is what you are doing on the errorpath of probe().
Yours,
Linus Walleij
On Fri, Jan 8, 2021 at 12:41 PM Srinivas Neeli [off-list ref] wrote:
quoted
On Wed, Jan 6, 2021 at 1:27 PM Srinivas Neeli [off-list ref]
wrote:
quoted
quoted
/**
* xgpio_remove - Remove method for the GPIO device.
* @pdev: pointer to the platform device @@ -289,7 +323,10 @@ static
int xgpio_remove(struct platform_device *pdev) {
struct xgpio_instance *gpio = platform_get_drvdata(pdev);
- clk_disable_unprepare(gpio->clk);
+ if (!pm_runtime_suspended(&pdev->dev))
+ clk_disable_unprepare(gpio->clk);
+
+ pm_runtime_disable(&pdev->dev);
This looks complex and racy. What if the device is resumed after you
executed the first part of the statement.
Could you please explain more on this.
What is the need to call pm_runtime_get_sync(); in remove API ?
I explain that on the lines right below your comment ;D
quoted
The normal sequence is:
pm_runtime_get_sync(dev);
pm_runtime_put_noidle(dev);
pm_runtime_disable(dev);
This will make sure the clock is enabled and pm runtime is disabled.
After this you can unconditionally call clk_disable_unprepare(gpio->clk);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel