Message ID | 1573642136-30488-1-git-send-email-akashast@codeaurora.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v5,1/3] tty: serial: qcom_geni_serial: IRQ cleanup | expand |
Quoting Akash Asthana (2019-11-13 02:48:56) > Add system wakeup capability over UART RX line for wakeup capable UART. > When system is suspended, RX line act as an interrupt to wakeup system > for any communication requests from peer. How does the RX line get remuxed as a GPIO interrupt here? Is that through some pinctrl magic in DT or just via enabling/disabling the interrupt? > > diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c > index 634054a..56dad67 100644 > --- a/drivers/tty/serial/qcom_geni_serial.c > +++ b/drivers/tty/serial/qcom_geni_serial.c > @@ -1321,6 +1327,23 @@ static int qcom_geni_serial_probe(struct platform_device *pdev) > return ret; > } > > + if (port->wakeup_irq > 0) { > + /* > + * Set pm_runtime status as ACTIVE so that wakeup_irq gets > + * enabled/disabled from dev_pm_arm_wake_irq during system > + * suspend/resume respectively. > + */ > + pm_runtime_set_active(&pdev->dev); We can always set this device as active regardless of wakeup interrupt, right? Can we move this call outside of this if? > + device_init_wakeup(&pdev->dev, true); > + ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, > + port->wakeup_irq); > + if (ret) { > + device_init_wakeup(&pdev->dev, false); > + uart_remove_one_port(drv, uport); > + return ret; > + } > + } > + > return ret; > } >
On 11/14/2019 11:10 PM, Stephen Boyd wrote: > Quoting Akash Asthana (2019-11-13 02:48:56) >> Add system wakeup capability over UART RX line for wakeup capable UART. >> When system is suspended, RX line act as an interrupt to wakeup system >> for any communication requests from peer. > How does the RX line get remuxed as a GPIO interrupt here? Is that > through some pinctrl magic in DT or just via enabling/disabling the > interrupt? Yes, For wakeup capable UART node, we have registered UART RX line with TLMM interrupt controller in DT file . Example: if GPIO48 is UART RX line interrupts-extended = <&intc GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>, <&tlmm 48 IRQ_TYPE_EDGE_FALLING>; > >> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c >> index 634054a..56dad67 100644 >> --- a/drivers/tty/serial/qcom_geni_serial.c >> +++ b/drivers/tty/serial/qcom_geni_serial.c >> @@ -1321,6 +1327,23 @@ static int qcom_geni_serial_probe(struct platform_device *pdev) >> return ret; >> } >> >> + if (port->wakeup_irq > 0) { >> + /* >> + * Set pm_runtime status as ACTIVE so that wakeup_irq gets >> + * enabled/disabled from dev_pm_arm_wake_irq during system >> + * suspend/resume respectively. >> + */ >> + pm_runtime_set_active(&pdev->dev); > We can always set this device as active regardless of wakeup interrupt, > right? Can we move this call outside of this if? Ok, Yes we can move this call outside of if. I will update in next version. > >> + device_init_wakeup(&pdev->dev, true); >> + ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, >> + port->wakeup_irq); >> + if (ret) { >> + device_init_wakeup(&pdev->dev, false); >> + uart_remove_one_port(drv, uport); >> + return ret; >> + } >> + } >> + >> return ret; >> } >>
Quoting Akash Asthana (2019-11-15 02:00:44) > > On 11/14/2019 11:10 PM, Stephen Boyd wrote: > > Quoting Akash Asthana (2019-11-13 02:48:56) > >> Add system wakeup capability over UART RX line for wakeup capable UART. > >> When system is suspended, RX line act as an interrupt to wakeup system > >> for any communication requests from peer. > > How does the RX line get remuxed as a GPIO interrupt here? Is that > > through some pinctrl magic in DT or just via enabling/disabling the > > interrupt? > Yes, For wakeup capable UART node, we have registered UART RX line with > TLMM interrupt controller in DT file . Example: if GPIO48 is UART RX line > > interrupts-extended = <&intc GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>, <&tlmm > 48 IRQ_TYPE_EDGE_FALLING>; Right. So is gpio48 muxed as 'uart' function forever and the interrupt logic in tlmm is connected to that pad regardless of the function selected? I thought that gpios through TLMM had to be muxed as function 0, i.e. gpio function, so that interrupts worked. But maybe that's wrong and it can work without that.
On 11/16/2019 1:11 AM, Stephen Boyd wrote: > Quoting Akash Asthana (2019-11-15 02:00:44) >> On 11/14/2019 11:10 PM, Stephen Boyd wrote: >>> Quoting Akash Asthana (2019-11-13 02:48:56) >>>> Add system wakeup capability over UART RX line for wakeup capable UART. >>>> When system is suspended, RX line act as an interrupt to wakeup system >>>> for any communication requests from peer. >>> How does the RX line get remuxed as a GPIO interrupt here? Is that >>> through some pinctrl magic in DT or just via enabling/disabling the >>> interrupt? >> Yes, For wakeup capable UART node, we have registered UART RX line with >> TLMM interrupt controller in DT file . Example: if GPIO48 is UART RX line >> >> interrupts-extended = <&intc GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>, <&tlmm >> 48 IRQ_TYPE_EDGE_FALLING>; > Right. So is gpio48 muxed as 'uart' function forever and the interrupt > logic in tlmm is connected to that pad regardless of the function > selected? I thought that gpios through TLMM had to be muxed as function > 0, i.e. gpio function, so that interrupts worked. But maybe that's wrong > and it can work without that. Yes, gpio48 is muxed as "uart' function function forever. There is no need to mux gpio48 to gpio function, interrupts can work without that.
Quoting Akash Asthana (2019-11-21 22:46:32) > > On 11/16/2019 1:11 AM, Stephen Boyd wrote: > > Quoting Akash Asthana (2019-11-15 02:00:44) > >> On 11/14/2019 11:10 PM, Stephen Boyd wrote: > >>> Quoting Akash Asthana (2019-11-13 02:48:56) > >>>> Add system wakeup capability over UART RX line for wakeup capable UART. > >>>> When system is suspended, RX line act as an interrupt to wakeup system > >>>> for any communication requests from peer. > >>> How does the RX line get remuxed as a GPIO interrupt here? Is that > >>> through some pinctrl magic in DT or just via enabling/disabling the > >>> interrupt? > >> Yes, For wakeup capable UART node, we have registered UART RX line with > >> TLMM interrupt controller in DT file . Example: if GPIO48 is UART RX line > >> > >> interrupts-extended = <&intc GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>, <&tlmm > >> 48 IRQ_TYPE_EDGE_FALLING>; > > Right. So is gpio48 muxed as 'uart' function forever and the interrupt > > logic in tlmm is connected to that pad regardless of the function > > selected? I thought that gpios through TLMM had to be muxed as function > > 0, i.e. gpio function, so that interrupts worked. But maybe that's wrong > > and it can work without that. > > Yes, gpio48 is muxed as "uart' function function forever. There is no > need to mux gpio48 to > > gpio function, interrupts can work without that. > Ok thanks for confirming.
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c index 634054a..56dad67 100644 --- a/drivers/tty/serial/qcom_geni_serial.c +++ b/drivers/tty/serial/qcom_geni_serial.c @@ -14,6 +14,8 @@ #include <linux/of.h> #include <linux/of_device.h> #include <linux/platform_device.h> +#include <linux/pm_runtime.h> +#include <linux/pm_wakeirq.h> #include <linux/qcom-geni-se.h> #include <linux/serial.h> #include <linux/serial_core.h> @@ -116,6 +118,7 @@ struct qcom_geni_serial_port { bool brk; unsigned int tx_remaining; + int wakeup_irq; }; static const struct uart_ops qcom_geni_console_pops; @@ -1302,6 +1305,9 @@ static int qcom_geni_serial_probe(struct platform_device *pdev) return irq; uport->irq = irq; + if (!console) + port->wakeup_irq = platform_get_irq_optional(pdev, 1); + uport->private_data = drv; platform_set_drvdata(pdev, port); port->handle_rx = console ? handle_rx_console : handle_rx_uart; @@ -1321,6 +1327,23 @@ static int qcom_geni_serial_probe(struct platform_device *pdev) return ret; } + if (port->wakeup_irq > 0) { + /* + * Set pm_runtime status as ACTIVE so that wakeup_irq gets + * enabled/disabled from dev_pm_arm_wake_irq during system + * suspend/resume respectively. + */ + pm_runtime_set_active(&pdev->dev); + device_init_wakeup(&pdev->dev, true); + ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, + port->wakeup_irq); + if (ret) { + device_init_wakeup(&pdev->dev, false); + uart_remove_one_port(drv, uport); + return ret; + } + } + return ret; } @@ -1330,6 +1353,10 @@ static int qcom_geni_serial_remove(struct platform_device *pdev) struct uart_driver *drv = port->uport.private_data; uart_remove_one_port(drv, &port->uport); + + device_init_wakeup(&pdev->dev, false); + dev_pm_clear_wake_irq(&pdev->dev); + return 0; }
Add system wakeup capability over UART RX line for wakeup capable UART. When system is suspended, RX line act as an interrupt to wakeup system for any communication requests from peer. Signed-off-by: Akash Asthana <akashast@codeaurora.org> --- Changes in V5: - No change. Changes in V4: - As per Greg's comment, removed extra dev_err logging. - As per Stephen's comment, using common code that manage wakeirq irqs for devices. Using dev_pm_set_dedicated_wake_irq API that will take care of requesting and attaching wakeup irqs for devices. Also, it sets wakeirq status to WAKE_IRQ_DEDICATED_ALLOCATED as a result enabling/disabling of wake irq will be managed by suspend/resume framework so, removed the code for enabling and disabling of wake irq from the driver. Changes in V3: - As per Stephen's comment, using platform_get_irq_optional API to get wakeup IRQ for device. Changes in V2: - As per Stephen's comment, splitted V1 patch into 2 seperate patch. a) Clean up of core IRQ registration b) Add wakeup feature. drivers/tty/serial/qcom_geni_serial.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)