* Re: [PATCH 1/2] serial: mps2-uart: move to dynamic port allocation
From: Greg KH @ 2019-01-30 9:24 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: linux-arm-kernel, linux-serial, sudeep.holla
In-Reply-To: <0bea8e14-9ade-aed4-c41e-f02ab0b81d24@arm.com>
On Wed, Jan 30, 2019 at 08:58:53AM +0000, Vladimir Murzin wrote:
> On 1/30/19 8:27 AM, Greg KH wrote:
> > On Fri, Jan 25, 2019 at 02:13:16PM +0000, Vladimir Murzin wrote:
> >> Some designs, like MPS3, expose number of virtual serial ports which
> >> already close or exceeds MPS2_MAX_PORTS. Increasing MPS2_MAX_PORTS
> >> would have negative impact (in terms of memory consumption) on tiny
> >> MPS2 platform which, in fact, has only one physically populated UART.
> >>
> >> Start with converting existent static port array to idr. As a bonus it
> >> make driver not to fail in case when no alias was specified in device
> >> tree.
> >>
> >> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> >> ---
> >> drivers/tty/serial/mps2-uart.c | 47 ++++++++++++++++++++++++++++--------------
> >> 1 file changed, 31 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
> >> index 9f8f637..6da0633 100644
> >> --- a/drivers/tty/serial/mps2-uart.c
> >> +++ b/drivers/tty/serial/mps2-uart.c
> >> @@ -22,6 +22,7 @@
> >> #include <linux/serial_core.h>
> >> #include <linux/tty_flip.h>
> >> #include <linux/types.h>
> >> +#include <linux/idr.h>
> >>
> >> #define SERIAL_NAME "ttyMPS"
> >> #define DRIVER_NAME "mps2-uart"
> >> @@ -397,7 +398,7 @@ static const struct uart_ops mps2_uart_pops = {
> >> .verify_port = mps2_uart_verify_port,
> >> };
> >>
> >> -static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
> >> +static DEFINE_IDR(ports_idr);
> >
> > You forgot to call idr_destroy() when your code unloads :(
>
> Hmm, but code doesn't unload since ce87122911f8 ("serial: mps2-uart: make driver explicitly non-modular")
> or I'm missing something?
Ugh, ok, nevermind, I missed that, sorry.
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] serial: mps2-uart: support combined tx and rx irq
From: Vladimir Murzin @ 2019-01-30 9:00 UTC (permalink / raw)
To: linux-serial; +Cc: linux-arm-kernel, sudeep.holla
In-Reply-To: <1548425597-38175-3-git-send-email-vladimir.murzin@arm.com>
On 1/25/19 2:13 PM, Vladimir Murzin wrote:
> It turns out that some designs went for implementing only combined tx
> and rx interrupt, which is currently not supported by the driver.
> Support of combined irq is built on top of existent irq handlers and
> activated by the hint form device tree.
>
It seems that folks combine rx, tx and overrun interrupts, so I'll send v2
Cheers
Vladimir
^ permalink raw reply
* Re: [PATCH 1/2] serial: mps2-uart: move to dynamic port allocation
From: Vladimir Murzin @ 2019-01-30 8:58 UTC (permalink / raw)
To: Greg KH; +Cc: linux-arm-kernel, linux-serial, sudeep.holla
In-Reply-To: <20190130082753.GA24317@kroah.com>
On 1/30/19 8:27 AM, Greg KH wrote:
> On Fri, Jan 25, 2019 at 02:13:16PM +0000, Vladimir Murzin wrote:
>> Some designs, like MPS3, expose number of virtual serial ports which
>> already close or exceeds MPS2_MAX_PORTS. Increasing MPS2_MAX_PORTS
>> would have negative impact (in terms of memory consumption) on tiny
>> MPS2 platform which, in fact, has only one physically populated UART.
>>
>> Start with converting existent static port array to idr. As a bonus it
>> make driver not to fail in case when no alias was specified in device
>> tree.
>>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>> ---
>> drivers/tty/serial/mps2-uart.c | 47 ++++++++++++++++++++++++++++--------------
>> 1 file changed, 31 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
>> index 9f8f637..6da0633 100644
>> --- a/drivers/tty/serial/mps2-uart.c
>> +++ b/drivers/tty/serial/mps2-uart.c
>> @@ -22,6 +22,7 @@
>> #include <linux/serial_core.h>
>> #include <linux/tty_flip.h>
>> #include <linux/types.h>
>> +#include <linux/idr.h>
>>
>> #define SERIAL_NAME "ttyMPS"
>> #define DRIVER_NAME "mps2-uart"
>> @@ -397,7 +398,7 @@ static const struct uart_ops mps2_uart_pops = {
>> .verify_port = mps2_uart_verify_port,
>> };
>>
>> -static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
>> +static DEFINE_IDR(ports_idr);
>
> You forgot to call idr_destroy() when your code unloads :(
Hmm, but code doesn't unload since ce87122911f8 ("serial: mps2-uart: make driver explicitly non-modular")
or I'm missing something?
Cheers
Vladimir
>
> Yeah, it's not an obvious design pattern, I think someone will fix it up
> someday...
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
From: Russell King - ARM Linux admin @ 2019-01-30 8:40 UTC (permalink / raw)
To: Sugaya, Taichi
Cc: Rob Herring, Stephen Boyd, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-clk, linux-kernel@vger.kernel.org, open list:SERIAL DRIVERS,
Michael Turquette, Mark Rutland, Greg Kroah-Hartman,
Daniel Lezcano, Thomas Gleixner, Jiri Slaby, Masami Hiramatsu,
Jassi Brar
In-Reply-To: <2bf9d327-580b-afb6-f872-701dde249b22@socionext.com>
On Tue, Jan 29, 2019 at 05:28:48PM +0900, Sugaya, Taichi wrote:
> Hi,
>
> On 2019/01/22 20:50, Russell King - ARM Linux admin wrote:
> > On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:
> > > Hi
> > >
> > > On 2018/12/04 22:32, Rob Herring wrote:
> > > > On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
> > > > <sugaya.taichi@socionext.com> wrote:
> > > > >
> > > > > Hi
> > > > >
> > > > > On 2018/12/04 0:49, Rob Herring wrote:
> > > > > > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
> > > > > > <sugaya.taichi@socionext.com> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On 2018/11/30 17:16, Stephen Boyd wrote:
> > > > > > > > Quoting Sugaya, Taichi (2018-11-29 04:24:51)
> > > > > > > > > On 2018/11/28 11:01, Stephen Boyd wrote:
> > > > > > > > > > Quoting Sugaya Taichi (2018-11-18 17:01:07)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 0000000..f5d906c
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> > > > > > > > > > > @@ -0,0 +1,12 @@
> > > > > > > > > > > +Socionext M10V SMP trampoline driver binding
> > > > > > > > > > > +
> > > > > > > > > > > +This is a driver to wait for sub-cores while boot process.
> > > > > > > > > > > +
> > > > > > > > > > > +- compatible: should be "socionext,smp-trampoline"
> > > > > > > > > > > +- reg: should be <0x4C000100 0x100>
> > > > > > > > > > > +
> > > > > > > > > > > +EXAMPLE
> > > > > > > > > > > + trampoline: trampoline@0x4C000100 {
> > > > > > > > > > Drop the 0x part of unit addresses.
> > > > > > > > >
> > > > > > > > > Okay.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > + compatible = "socionext,smp-trampoline";
> > > > > > > > > > > + reg = <0x4C000100 0x100>;
> > > > > > > > > > Looks like a software construct, which we wouldn't want to put into DT
> > > > > > > > > > this way. DT doesn't describe drivers.
> > > > > > > > > We would like to use this node only getting the address of the
> > > > > > > > > trampoline area
> > > > > > > > > in which sub-cores wait. (They have finished to go to this area in previous
> > > > > > > > > bootloader process.)
> > > > > > > >
> > > > > > > > Is this area part of memory, or a special SRAM? If it's part of memory,
> > > > > > > > I would expect this node to be under the reserved-memory node and
> > > > > > > > pointed to by some other node that uses this region. Could even be the
> > > > > > > > CPU nodes.
> > > > > > >
> > > > > > > Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
> > > > > > > we would like to use the SRAM ( allocated 0x00000000 ) area instead.
> > > > > > > BTW, sorry, the trampoline address of this example is simply wrong. We
> > > > > > > were going to use a part of the SRAM from the beginning.
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > So should we embed the constant value in source codes instead of getting
> > > > > > > > > from
> > > > > > > > > DT because the address is constant at the moment? Or is there other
> > > > > > > > > approach?
> > > > > > > > >
> > > > > > > >
> > > > > > > > If it's constant then that also works. Why does it need to come from DT
> > > > > > > > at all then?
> > > > > > >
> > > > > > > We think it is not good to embed constant value in driver codes and do
> > > > > > > not have another way...
> > > > > > > Are there better ways?
> > > > > >
> > > > > > If this is just memory, can you use the standard spin-table binding in
> > > > > > the DT spec? There are some requirements like 64-bit values even on
> > > > > > 32-bit machines (though this gets violated).
> > > > >
> > > > > The spin-table seems to be used on only 64-bit arch. Have it ever worked
> > > > > on 32-bit machine?
> > > >
> > > > Yes.
> > > >
> > > > > And I would like not to use it because avoid violation.
> > > >
> > > > The issue now that I remember is cpu-release-addr is defined to always
> > > > be a 64-bit value while some platforms made it a 32-bit value.
> > > > 'cpu-release-addr' is also used for some other enable-methods.
> > >
> > > I have a question about the spin-table.
> > > The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so can
> > > not be compiled in arm-v7 arch. That means the spin-table can not be used
> > > arm-v7 arch..? , or is there the way to compile the code in arm-v7 arch?
> >
> > Why do you think you need it? Do you have no way to control individual
> > CPUs?
> >
> > We are going through a process in 32-bit eliminating the "spin table"
> > stuff from platforms.
> >
>
> Not always necessary to us and considering the history I think it is not
> suitable to use the spin-table.
> I try to use another way.
Please do - the "spin" approach was a hack to allow ARM Ltd's platforms
to work. These platforms have no power control or reset of secondary
CPUs and no low power states (so can't suspend/resume). Early firmware
only had the capabilities to release _all_ secondary CPUs to the kernel
together. The "spin" approach is incompatible with suspend/resume,
hibernate, and kexec features of the kernel.
Real platforms do not have these problems, and thus should not use the
spin-table approach.
Modern platforms use PSCI to make the control of low power modes and
secondary CPUs independent of the kernel.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH] tty: ldisc: add sysctl to prevent autoloading of ldiscs
From: Greg Kroah-Hartman @ 2019-01-30 8:28 UTC (permalink / raw)
To: Theodore Y. Ts'o, kernel-hardening, linux-kernel,
linux-serial, Jiri Slaby
In-Reply-To: <20190122000142.GB19379@mit.edu>
On Mon, Jan 21, 2019 at 07:01:42PM -0500, Theodore Y. Ts'o wrote:
> On Mon, Jan 21, 2019 at 05:26:42PM +0100, Greg Kroah-Hartman wrote:
> > By default, the kernel will automatically load the module of any line
> > dicipline that is asked for. As this sometimes isn't the safest thing
> > to do, provide a sysctl to disable this feature.
> >
> > By default, we set this to 'y' as that is the historical way that Linux
> > has worked, and we do not want to break working systems. But in the
> > future, perhaps this can default to 'n' to prevent this functionality.
> >
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Thanks for the review!
^ permalink raw reply
* Re: [PATCH 1/2] serial: mps2-uart: move to dynamic port allocation
From: Greg KH @ 2019-01-30 8:27 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: linux-arm-kernel, linux-serial, sudeep.holla
In-Reply-To: <1548425597-38175-2-git-send-email-vladimir.murzin@arm.com>
On Fri, Jan 25, 2019 at 02:13:16PM +0000, Vladimir Murzin wrote:
> Some designs, like MPS3, expose number of virtual serial ports which
> already close or exceeds MPS2_MAX_PORTS. Increasing MPS2_MAX_PORTS
> would have negative impact (in terms of memory consumption) on tiny
> MPS2 platform which, in fact, has only one physically populated UART.
>
> Start with converting existent static port array to idr. As a bonus it
> make driver not to fail in case when no alias was specified in device
> tree.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> drivers/tty/serial/mps2-uart.c | 47 ++++++++++++++++++++++++++++--------------
> 1 file changed, 31 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
> index 9f8f637..6da0633 100644
> --- a/drivers/tty/serial/mps2-uart.c
> +++ b/drivers/tty/serial/mps2-uart.c
> @@ -22,6 +22,7 @@
> #include <linux/serial_core.h>
> #include <linux/tty_flip.h>
> #include <linux/types.h>
> +#include <linux/idr.h>
>
> #define SERIAL_NAME "ttyMPS"
> #define DRIVER_NAME "mps2-uart"
> @@ -397,7 +398,7 @@ static const struct uart_ops mps2_uart_pops = {
> .verify_port = mps2_uart_verify_port,
> };
>
> -static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
> +static DEFINE_IDR(ports_idr);
You forgot to call idr_destroy() when your code unloads :(
Yeah, it's not an obvious design pattern, I think someone will fix it up
someday...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
From: Sugaya, Taichi @ 2019-01-29 8:28 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Rob Herring, Stephen Boyd, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-clk, linux-kernel@vger.kernel.org, open list:SERIAL DRIVERS,
Michael Turquette, Mark Rutland, Greg Kroah-Hartman,
Daniel Lezcano, Thomas Gleixner, Jiri Slaby, Masami Hiramatsu,
Jassi Brar
In-Reply-To: <20190122115010.ziopujojh6hkxyag@e5254000004ec.dyn.armlinux.org.uk>
Hi,
On 2019/01/22 20:50, Russell King - ARM Linux admin wrote:
> On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:
>> Hi
>>
>> On 2018/12/04 22:32, Rob Herring wrote:
>>> On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
>>> <sugaya.taichi@socionext.com> wrote:
>>>>
>>>> Hi
>>>>
>>>> On 2018/12/04 0:49, Rob Herring wrote:
>>>>> On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
>>>>> <sugaya.taichi@socionext.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 2018/11/30 17:16, Stephen Boyd wrote:
>>>>>>> Quoting Sugaya, Taichi (2018-11-29 04:24:51)
>>>>>>>> On 2018/11/28 11:01, Stephen Boyd wrote:
>>>>>>>>> Quoting Sugaya Taichi (2018-11-18 17:01:07)
>>>>>>>>>> create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 0000000..f5d906c
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
>>>>>>>>>> @@ -0,0 +1,12 @@
>>>>>>>>>> +Socionext M10V SMP trampoline driver binding
>>>>>>>>>> +
>>>>>>>>>> +This is a driver to wait for sub-cores while boot process.
>>>>>>>>>> +
>>>>>>>>>> +- compatible: should be "socionext,smp-trampoline"
>>>>>>>>>> +- reg: should be <0x4C000100 0x100>
>>>>>>>>>> +
>>>>>>>>>> +EXAMPLE
>>>>>>>>>> + trampoline: trampoline@0x4C000100 {
>>>>>>>>> Drop the 0x part of unit addresses.
>>>>>>>>
>>>>>>>> Okay.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> + compatible = "socionext,smp-trampoline";
>>>>>>>>>> + reg = <0x4C000100 0x100>;
>>>>>>>>> Looks like a software construct, which we wouldn't want to put into DT
>>>>>>>>> this way. DT doesn't describe drivers.
>>>>>>>> We would like to use this node only getting the address of the
>>>>>>>> trampoline area
>>>>>>>> in which sub-cores wait. (They have finished to go to this area in previous
>>>>>>>> bootloader process.)
>>>>>>>
>>>>>>> Is this area part of memory, or a special SRAM? If it's part of memory,
>>>>>>> I would expect this node to be under the reserved-memory node and
>>>>>>> pointed to by some other node that uses this region. Could even be the
>>>>>>> CPU nodes.
>>>>>>
>>>>>> Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
>>>>>> we would like to use the SRAM ( allocated 0x00000000 ) area instead.
>>>>>> BTW, sorry, the trampoline address of this example is simply wrong. We
>>>>>> were going to use a part of the SRAM from the beginning.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> So should we embed the constant value in source codes instead of getting
>>>>>>>> from
>>>>>>>> DT because the address is constant at the moment? Or is there other
>>>>>>>> approach?
>>>>>>>>
>>>>>>>
>>>>>>> If it's constant then that also works. Why does it need to come from DT
>>>>>>> at all then?
>>>>>>
>>>>>> We think it is not good to embed constant value in driver codes and do
>>>>>> not have another way...
>>>>>> Are there better ways?
>>>>>
>>>>> If this is just memory, can you use the standard spin-table binding in
>>>>> the DT spec? There are some requirements like 64-bit values even on
>>>>> 32-bit machines (though this gets violated).
>>>>
>>>> The spin-table seems to be used on only 64-bit arch. Have it ever worked
>>>> on 32-bit machine?
>>>
>>> Yes.
>>>
>>>> And I would like not to use it because avoid violation.
>>>
>>> The issue now that I remember is cpu-release-addr is defined to always
>>> be a 64-bit value while some platforms made it a 32-bit value.
>>> 'cpu-release-addr' is also used for some other enable-methods.
>>
>> I have a question about the spin-table.
>> The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so can
>> not be compiled in arm-v7 arch. That means the spin-table can not be used
>> arm-v7 arch..? , or is there the way to compile the code in arm-v7 arch?
>
> Why do you think you need it? Do you have no way to control individual
> CPUs?
>
> We are going through a process in 32-bit eliminating the "spin table"
> stuff from platforms.
>
Not always necessary to us and considering the history I think it is not
suitable to use the spin-table.
I try to use another way.
^ permalink raw reply
* [RFC/PATCH 5/5] arm64: dts: sdm845: Add OPP table for all qup devices
From: Stephen Boyd @ 2019-01-29 1:55 UTC (permalink / raw)
To: linux-kernel
Cc: Rajendra Nayak, linux-arm-msm, linux-pm, linux-serial, linux-spi,
Ulf Hansson, Viresh Kumar, Doug Anderson
In-Reply-To: <20190129015547.213276-1-swboyd@chromium.org>
From: Rajendra Nayak <rnayak@codeaurora.org>
qup has a requirement to vote on the performance state of the CX domain
in sdm845 devices. Add OPP tables for these and also add power-domains
property for all qup instances.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 115 +++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 22dc2b2df662..05c4862a195c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -366,6 +366,25 @@
clock-names = "core";
};
+ qup_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-19200000 {
+ opp-hz = /bits/ 64 <19200000>;
+ required-opps = <&rpmhpd_opp_min_svs>;
+ };
+
+ opp-75000000 {
+ opp-hz = /bits/ 64 <75000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+ };
+
qupv3_id_0: geniqup@8c0000 {
compatible = "qcom,geni-se-qup";
reg = <0x8c0000 0x6000>;
@@ -387,6 +406,8 @@
interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -400,6 +421,8 @@
interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -411,6 +434,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart0_default>;
interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -424,6 +449,8 @@
interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -437,6 +464,8 @@
interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -448,6 +477,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart1_default>;
interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -461,6 +492,8 @@
interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -474,6 +507,8 @@
interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -485,6 +520,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart2_default>;
interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -498,6 +535,8 @@
interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -511,6 +550,8 @@
interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -522,6 +563,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart3_default>;
interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -535,6 +578,8 @@
interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -548,6 +593,8 @@
interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -559,6 +606,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart4_default>;
interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -572,6 +621,8 @@
interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -585,6 +636,8 @@
interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -596,6 +649,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart5_default>;
interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -609,6 +664,8 @@
interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -622,6 +679,8 @@
interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -633,6 +692,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart6_default>;
interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -646,6 +707,8 @@
interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -659,6 +722,8 @@
interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -670,6 +735,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart7_default>;
interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
};
@@ -695,6 +762,8 @@
interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -708,6 +777,8 @@
interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -719,6 +790,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart8_default>;
interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -732,6 +805,8 @@
interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -745,6 +820,8 @@
interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -756,6 +833,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart9_default>;
interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -769,6 +848,8 @@
interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -782,6 +863,8 @@
interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -793,6 +876,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart10_default>;
interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -806,6 +891,8 @@
interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -819,6 +906,8 @@
interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -830,6 +919,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart11_default>;
interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -843,6 +934,8 @@
interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -856,6 +949,8 @@
interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -867,6 +962,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart12_default>;
interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -880,6 +977,8 @@
interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -893,6 +992,8 @@
interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -904,6 +1005,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart13_default>;
interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -917,6 +1020,8 @@
interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -930,6 +1035,8 @@
interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -941,6 +1048,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart14_default>;
interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -954,6 +1063,8 @@
interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -967,6 +1078,8 @@
interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
@@ -978,6 +1091,8 @@
pinctrl-names = "default";
pinctrl-0 = <&qup_uart15_default>;
interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&qup_opp_table>;
status = "disabled";
};
};
--
Sent by a computer through tubes
^ permalink raw reply related
* [RFC/PATCH 4/5] spi: spi-geni-qcom: Use OPP API to set clk/perf state
From: Stephen Boyd @ 2019-01-29 1:55 UTC (permalink / raw)
To: linux-kernel
Cc: Rajendra Nayak, linux-arm-msm, linux-pm, linux-serial, linux-spi,
Ulf Hansson, Viresh Kumar, Doug Anderson
In-Reply-To: <20190129015547.213276-1-swboyd@chromium.org>
From: Rajendra Nayak <rnayak@codeaurora.org>
geni spi needs to express a perforamnce state requirement on CX
depending on the frequency of the clock rates. Use OPP table from
DT to register with OPP framework and use dev_pm_opp_set_rate() to
set the clk/perf state.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/spi/spi-geni-qcom.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index fdb7cb88fb56..3ffb6b25b58d 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -116,9 +116,9 @@ static int get_spi_clk_cfg(unsigned int speed_hz,
dev_dbg(mas->dev, "req %u=>%u sclk %lu, idx %d, div %d\n", speed_hz,
actual_hz, sclk_freq, *clk_idx, *clk_div);
- ret = clk_set_rate(se->clk, sclk_freq);
+ ret = dev_pm_opp_set_rate(mas->dev, sclk_freq);
if (ret)
- dev_err(mas->dev, "clk_set_rate failed %d\n", ret);
+ dev_err(mas->dev, "dev_pm_opp_set_rate failed %d\n", ret);
return ret;
}
@@ -564,6 +564,12 @@ static int spi_geni_probe(struct platform_device *pdev)
if (!spi)
return -ENOMEM;
+ ret = dev_pm_opp_of_add_table(&pdev->dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to init OPP table: %d\n", ret);
+ return ret;
+ }
+
platform_set_drvdata(pdev, spi);
mas = spi_master_get_devdata(spi);
mas->irq = irq;
@@ -629,6 +635,8 @@ static int __maybe_unused spi_geni_runtime_suspend(struct device *dev)
struct spi_master *spi = dev_get_drvdata(dev);
struct spi_geni_master *mas = spi_master_get_devdata(spi);
+ /* Drop the performance state vote */
+ dev_pm_opp_set_rate(dev, 0);
return geni_se_resources_off(&mas->se);
}
--
Sent by a computer through tubes
^ permalink raw reply related
* [RFC/PATCH 3/5] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
From: Stephen Boyd @ 2019-01-29 1:55 UTC (permalink / raw)
To: linux-kernel
Cc: Rajendra Nayak, linux-arm-msm, linux-pm, linux-serial, linux-spi,
Ulf Hansson, Viresh Kumar, Doug Anderson
In-Reply-To: <20190129015547.213276-1-swboyd@chromium.org>
From: Rajendra Nayak <rnayak@codeaurora.org>
geni serial needs to express a perforamnce state requirement on CX
depending on the frequency of the clock rates. Use OPP table from
DT to register with OPP framework and use dev_pm_opp_set_rate() to
set the clk/perf state.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/tty/serial/qcom_geni_serial.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index a72d6d9fb983..dca8f6845463 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/pm_opp.h>
#include <linux/platform_device.h>
#include <linux/qcom-geni-se.h>
#include <linux/serial.h>
@@ -119,6 +120,7 @@ struct qcom_geni_serial_port {
bool brk;
unsigned int tx_remaining;
+ struct device *dev;
};
static const struct uart_ops qcom_geni_console_pops;
@@ -1028,7 +1030,7 @@ static void qcom_geni_serial_set_termios(struct uart_port *uport,
goto out_restart_rx;
uport->uartclk = clk_rate;
- clk_set_rate(port->se.clk, clk_rate);
+ dev_pm_opp_set_rate(port->dev, clk_rate);
ser_clk_cfg = SER_CLK_EN;
ser_clk_cfg |= clk_div << CLK_DIV_SHFT;
@@ -1265,8 +1267,10 @@ static void qcom_geni_serial_pm(struct uart_port *uport,
if (new_state == UART_PM_STATE_ON && old_state == UART_PM_STATE_OFF)
geni_se_resources_on(&port->se);
else if (new_state == UART_PM_STATE_OFF &&
- old_state == UART_PM_STATE_ON)
+ old_state == UART_PM_STATE_ON) {
+ dev_pm_opp_set_rate(port->dev, 0);
geni_se_resources_off(&port->se);
+ }
}
static const struct uart_ops qcom_geni_console_pops = {
@@ -1332,6 +1336,7 @@ static int qcom_geni_serial_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Invalid line %d\n", line);
return PTR_ERR(port);
}
+ port->dev = &pdev->dev;
uport = &port->uport;
/* Don't allow 2 drivers to access the same port */
@@ -1353,6 +1358,12 @@ static int qcom_geni_serial_probe(struct platform_device *pdev)
return -EINVAL;
uport->mapbase = res->start;
+ ret = dev_pm_opp_of_add_table(&pdev->dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to init OPP table: %d\n", ret);
+ return ret;
+ }
+
port->tx_fifo_depth = DEF_FIFO_DEPTH_WORDS;
port->rx_fifo_depth = DEF_FIFO_DEPTH_WORDS;
port->tx_fifo_width = DEF_FIFO_WIDTH_BITS;
--
Sent by a computer through tubes
^ permalink raw reply related
* [RFC/PATCH 2/5] OPP: Make dev_pm_opp_set_rate() with freq=0 as valid
From: Stephen Boyd @ 2019-01-29 1:55 UTC (permalink / raw)
To: linux-kernel
Cc: Rajendra Nayak, linux-arm-msm, linux-pm, linux-serial, linux-spi,
Ulf Hansson, Viresh Kumar, Doug Anderson
In-Reply-To: <20190129015547.213276-1-swboyd@chromium.org>
From: Rajendra Nayak <rnayak@codeaurora.org>
For devices with performance state, we use dev_pm_opp_set_rate()
to set the appropriate clk rate and the performance state.
We do need a way to *remove* the performance state vote when
we idle the device and turn the clocks off. Use dev_pm_opp_set_rate()
with freq=0 to achieve this.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/opp/core.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index b6516d623c5a..ac5099c237de 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -709,18 +709,24 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
struct clk *clk;
int ret;
- if (unlikely(!target_freq)) {
- dev_err(dev, "%s: Invalid target frequency %lu\n", __func__,
- target_freq);
- return -EINVAL;
- }
-
opp_table = _find_opp_table(dev);
if (IS_ERR(opp_table)) {
dev_err(dev, "%s: device opp doesn't exist\n", __func__);
return PTR_ERR(opp_table);
}
+ if (unlikely(!target_freq)) {
+ if (opp_table->required_opp_tables) {
+ /* drop the performance state vote */
+ dev_pm_genpd_set_performance_state(dev, 0);
+ return 0;
+ } else {
+ dev_err(dev, "%s: Invalid target frequency %lu\n", __func__,
+ target_freq);
+ return -EINVAL;
+ }
+ }
+
clk = opp_table->clk;
if (IS_ERR(clk)) {
dev_err(dev, "%s: No clock available for the device\n",
--
Sent by a computer through tubes
^ permalink raw reply related
* [RFC/PATCH 1/5] OPP: Don't overwrite rounded clk rate
From: Stephen Boyd @ 2019-01-29 1:55 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-msm, linux-pm, linux-serial, linux-spi, Rajendra Nayak,
Ulf Hansson, Viresh Kumar, Doug Anderson
In-Reply-To: <20190129015547.213276-1-swboyd@chromium.org>
Doing this allows us to call this API with any rate requested and have
it not need to match in the OPP table. Instead, we'll round the rate up
to the nearest OPP that we see so that we can get the voltage or level
that's required for that OPP. This supports users of OPP that want to
specify the 'fmax' tables of a device instead of every single frequency
that they need. And for devices that required the exact frequency, we
can rely on the clk framework to round the rate to the nearest supported
frequency instead of the OPP framework to do so.
Note that this may affect drivers that don't want the clk framework to
do rounding, but instead want the OPP table to do the rounding for them.
Do we have that case? Should we add some flag to the OPP table to
indicate this and then not have that flag set when there isn't an OPP
table for the device and also introduce a property like 'opp-use-clk' to
tell the table that it should use the clk APIs to round rates instead of
OPP?
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/opp/core.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index e06a0ab05ad6..b6516d623c5a 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -704,7 +704,7 @@ static int _set_required_opps(struct device *dev,
int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
{
struct opp_table *opp_table;
- unsigned long freq, old_freq;
+ unsigned long freq, opp_freq, old_freq, old_opp_freq;
struct dev_pm_opp *old_opp, *opp;
struct clk *clk;
int ret;
@@ -743,13 +743,15 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
goto put_opp_table;
}
- old_opp = _find_freq_ceil(opp_table, &old_freq);
+ old_opp_freq = old_freq;
+ old_opp = _find_freq_ceil(opp_table, &old_opp_freq);
if (IS_ERR(old_opp)) {
dev_err(dev, "%s: failed to find current OPP for freq %lu (%ld)\n",
__func__, old_freq, PTR_ERR(old_opp));
}
- opp = _find_freq_ceil(opp_table, &freq);
+ opp_freq = freq;
+ opp = _find_freq_ceil(opp_table, &opp_freq);
if (IS_ERR(opp)) {
ret = PTR_ERR(opp);
dev_err(dev, "%s: failed to find OPP for freq %lu (%d)\n",
--
Sent by a computer through tubes
^ permalink raw reply related
* [RFC/PATCH 0/5] DVFS in the OPP core
From: Stephen Boyd @ 2019-01-29 1:55 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-msm, linux-pm, linux-serial, linux-spi, Rajendra Nayak,
Ulf Hansson, Viresh Kumar, Doug Anderson
This patch series is an RFC around how we can implement DVFS for devices
that aren't your typical OPPish device (i.e. GPU/CPU). They don't have a
strict set of frequencies that they have been tested at to derive some
operating performance point. Instead they have a coarser set of
frequency max or 'fmax' OPPs that describe the maiximum frequency the
device can operate at with a given voltage.
The approach we take is to let the devm_pm_opp_set_rate() API accept 0
as a valid frequency indicating the frequency isn't required anymore and
to make the same API use the clk framework to round the frequency passed
in instead of relying on the OPP table to specify each frequency that
can be used. Once we have these two patches in place, we can use the OPP
API to change clk rates instead of clk_set_rate() and use all the recent
OPP enhancements that have been made around required-opps and genpd
performance states to do DVFS for all devices.
One nice feature of this approach is that we don't need to change the
OPP binding to support this. We can specify only the max frequencies and
the voltage requirements in DT with the existing binding and slightly
tweak the OPP code to achieve these results.
This series includes a conversion of the uart and spi drivers on
qcom sdm845 where these patches are being developed. It shows how a
driver is converted from the clk APIs to the OPP APIs and how
enable/disable state of the clk is communicated to the OPP layer.
Some open topics and initial points for discussion are:
1) The dev_pm_opp_set_rate() API changes may break something that's
relying on the rate rounding that OPP provides. If those exist,
we may need to implement another API that is more explicit about using
the clk API instead of the OPP tables.
2) dev_pm_opp_set_rate(0) is an interesting solution to the problem of
dropping the rate requirement. Is there anything better than this?
3) How do we handle devices that already have power-domains specified in
DT? The opp binding for required-opps doesn't let us specify the power
domain to target, instead it assumes that whatever power domain is
attached to a device is the one that OPP needs to use to change the
genpd performance state. Do we need a
dev_pm_opp_set_required_opps_name() or something to be explicit about
this? Can we have some way for the power domain that required-opps
correspond to be expressed in the OPP tables themselves?
4) How do we achieve the "full constraint" state? i.e. what do we do
about some devices being active and others being inactive during boot
and making sure that the voltage for the shared power domains doesn't
drop until all devices requiring it have informed OPP about their
power requirements?
Rajendra Nayak (4):
OPP: Make dev_pm_opp_set_rate() with freq=0 as valid
tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
spi: spi-geni-qcom: Use OPP API to set clk/perf state
arm64: dts: sdm845: Add OPP table for all qup devices
Stephen Boyd (1):
OPP: Don't overwrite rounded clk rate
arch/arm64/boot/dts/qcom/sdm845.dtsi | 115 ++++++++++++++++++++++++++
drivers/opp/core.c | 26 ++++--
drivers/spi/spi-geni-qcom.c | 12 ++-
drivers/tty/serial/qcom_geni_serial.c | 15 +++-
4 files changed, 155 insertions(+), 13 deletions(-)
For the interested, these patches are located here:
https://github.com/rrnayak/linux/ v5.0-rc3/opp-corners-wip
I've generated these patches by cutting off the top of that tree and
massaging the commit text a bit for the first patch.
base-commit: 49a57857aeea06ca831043acbb0fa5e0f50602fd
prerequisite-patch-id: 9c3ee728603596b8b0ba06ffd66084bdc21b1271
prerequisite-patch-id: f160e050bcd74f5de6fad66329381853869a6a97
prerequisite-patch-id: aa23548d2b486c29489b4304d85799d08762254e
prerequisite-patch-id: 40dd117c45fecb4308298352346546612db94b64
prerequisite-patch-id: cd102fa42bab19897c2295e8b990b2156626054a
prerequisite-patch-id: 3b9e5c8ed65ee96cc0f1c50166cf6bbb597ef582
prerequisite-patch-id: 7e71b957b90ad51d0619944d5ebc859380e8e3e4
prerequisite-patch-id: 5abd2bd6b3ae3e91551e2b8f9295169019ba82c7
prerequisite-patch-id: 68bb3e44cf4e5dbd363a1a1750e4d378971ed393
prerequisite-patch-id: 882b14ef9527b15d22cfddbb5fa2b9d43df1ff04
prerequisite-patch-id: 6fc14ddeb074fb0826f1f40031e9d161f1361666
--
Sent by a computer through tubes
^ permalink raw reply
* Re: [PATCH] tty: Fix WARNING in tty_set_termios
From: shuah @ 2019-01-28 21:29 UTC (permalink / raw)
To: Al Viro
Cc: marcel, johan.hedberg, w.d.hubbs, chris, kirk, samuel.thibault,
gregkh, robh, jslaby, sameo, davem, arnd, nishka.dasgupta_ug18,
m.maya.nakamura, santhameena13, zhongjiang, linux-bluetooth,
linux-kernel, speakup, devel, linux-serial, linux-wireless,
netdev, shuah
In-Reply-To: <20190126041416.GF2217@ZenIV.linux.org.uk>
On 1/25/19 9:14 PM, Al Viro wrote:
> On Fri, Jan 25, 2019 at 04:29:05PM -0700, Shuah Khan wrote:
>> tty_set_termios() has the following WARMN_ON which can be triggered with a
>> syscall to invoke TIOCGETD __NR_ioctl.
>>
>> WARN_ON(tty->driver->type == TTY_DRIVER_TYPE_PTY &&
>> tty->driver->subtype == PTY_TYPE_MASTER);
>> Reference: https://syzkaller.appspot.com/bug?id=2410d22f1d8e5984217329dd0884b01d99e3e48d
>>
>> A simple change would have been to print error message instead of WARN_ON.
>> However, the callers assume that tty_set_termios() always returns 0 and
>> don't check return value. The complete solution is fixing all the callers
>> to check error and bail out to fix the WARN_ON.
>>
>> This fix changes tty_set_termios() to return error and all the callers
>> to check error and bail out. The reproducer is used to reproduce the
>> problem and verify the fix.
>
>> --- a/drivers/bluetooth/hci_ldisc.c
>> +++ b/drivers/bluetooth/hci_ldisc.c
>> @@ -321,6 +321,8 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool enable)
>> status = tty_set_termios(tty, &ktermios);
>> BT_DBG("Disabling hardware flow control: %s",
>> status ? "failed" : "success");
>> + if (status)
>> + return;
>
> Can that ldisc end up set on pty master? And does it make any sense there?
The initial objective of the patch is to prevent the WARN_ON by making
the change to return error instead of WARN_ON. However, without changes
to places that don't check the return and keep making progress, there
will be secondary problems.
Without this change to return here, instead of WARN_ON, it will fail
with the following NULL pointer dereference at the next thing
hci_uart_set_flow_control() attempts.
status = tty->driver->ops->tiocmget(tty);
kernel: [10140.649783] BUG: unable to handle kernel NULL pointer
dereference at 0000000000000000
kernel: [10140.649786] #PF error: [INSTR]
kernel: [10140.649787] PGD 0 P4D 0
kernel: [10140.649790] Oops: 0010 [#1] SMP PTI
Jan 24 15:33:35 deneb kernel: [10140.649793] CPU: 2 PID: 55 Comm:
kworker/u33:0 Tainted: G W 5.0.0-rc3+ #5
kernel: [10140.649794] Hardware name: Dell Inc. OptiPlex 790/0HY9JP,
BIOS A18 09/24/2013
Workqueue: hci0 hci_power_on [bluetooth]
kernel: [10140.649805] RIP: 0010: (null)
kernel: [10140.649809] Code: Bad RIP value.
kernel: [10140.649810] RSP: 0018:ffffa01a8153fd28 EFLAGS: 00010282
kernel: [10140.649812] RAX: 0000000000000000 RBX: ffff8958d6bc4800 RCX:
35ad8b0300000000
kernel: [10140.649814] RDX: ffffffff00000001 RSI: 0000000000000000 RDI:
ffff8958d6bc4800
kernel: [10140.649816] RBP: ffffa01a8153fd78 R08: 0000000091773f09 R09:
0000000000000003
kernel: [10140.649817] R10: ffff8958d6bc4a98 R11: 0000000000000720 R12:
ffff895814500c00
kernel: [10140.649819] R13: ffff8958a858e000 R14: 0000000000000000 R15:
ffff8958af1af440
kernel: [10140.649821] FS: 0000000000000000(0000)
GS:ffff895925880000(0000) knlGS:0000000000000000
kernel: [10140.649823] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: [10140.649824] CR2: ffffffffffffffd6 CR3: 0000000083f46002 CR4:
00000000000606e0
kernel: [10140.649826] Call Trace:
kernel: [10140.649830] ? hci_uart_set_flow_control+0x20e/0x2c0 [hci_uart]
kernel: [10140.649836] mrvl_setup+0x17/0x80 [hci_uart]
kernel: [10140.649840] hci_uart_setup+0x56/0x160 [hci_uart]
kernel: [10140.649850] hci_dev_do_open+0xe6/0x630 [bluetooth]
kernel: [10140.649860] hci_power_on+0x52/0x220 [bluetooth]
>
> IOW, I don't believe that this patch makes any sense. If anything,
> we need to prevent unconditional tty_set_termios() on the path
> that *does* lead to calling it for pty.
>
I don't think preventing unconditional tty_set_termios() is enough to
prevent secondary problems such as the one above.
For example, the following call chain leads to the WARN_ON that was
reported. Even if void hci_uart_set_baudrate() prevents the very first
tty_set_termios() call, its caller hci_uart_setup() continues with
more tty setup. It goes ahead to call driver setup callback. The
driver callback goes on to do more setup calling tty_set_termios().
WARN_ON call path:
hci_uart_set_baudrate+0x1cc/0x250 drivers/bluetooth/hci_ldisc.c:378
hci_uart_setup+0xa2/0x490 drivers/bluetooth/hci_ldisc.c:401
hci_dev_do_open+0x6b1/0x1920 net/bluetooth/hci_core.c:1423
Once this WARN_ON is changed to return error, the following
happens, when hci_uart_setup() does driver setup callback.
kernel: [10140.649836] mrvl_setup+0x17/0x80 [hci_uart]
kernel: [10140.649840] hci_uart_setup+0x56/0x160 [hci_uart]
kernel: [10140.649850] hci_dev_do_open+0xe6/0x630 [bluetooth]
kernel: [10140.649860] hci_power_on+0x52/0x220 [bluetooth]
I think continuing to catch the invalid condition in tty_set_termios()
and preventing progress by checking return value is a straight forward
change to avoid secondary problems, and it might be difficult to catch
all the cases where it could fail. Here is the reproducer for reference:
#define _GNU_SOURCE
#include <endian.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
uint64_t r[1] = {0xffffffffffffffff};
int main(void)
{
syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
long res = 0;
memcpy((void*)0x20000100, "/dev/ptmx\x00", 10);
res = syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0);
if (res != -1)
r[0] = res;
*(uint32_t*)0x200000c0 = 0xf;
syscall(__NR_ioctl, r[0], 0x5423, 0x200000c0);
syscall(__NR_ioctl, r[0], 0x400455c8, 0xb);
return 0;
}
thanks,
-- Shuah
^ permalink raw reply
* [PATCH v3 2/2] Dt-bindings: Serial: Add X1000 serial bindings.
From: Zhou Yanjie @ 2019-01-28 17:03 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-serial, devicetree, robh+dt, paul.burton,
gregkh, jslaby, mark.rutland, syq, jiaxun.yang, 772753199
In-Reply-To: <1548695029-11900-1-git-send-email-zhouyanjie@zoho.com>
Add the serial bindings for the X1000 Soc from Ingenic.
Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>
---
Documentation/devicetree/bindings/serial/ingenic,uart.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.txt b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
index c3c6406..24ed876 100644
--- a/Documentation/devicetree/bindings/serial/ingenic,uart.txt
+++ b/Documentation/devicetree/bindings/serial/ingenic,uart.txt
@@ -6,7 +6,8 @@ Required properties:
- "ingenic,jz4760-uart",
- "ingenic,jz4770-uart",
- "ingenic,jz4775-uart",
- - "ingenic,jz4780-uart".
+ - "ingenic,jz4780-uart",
+ - "ingenic,x1000-uart".
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
- clocks : phandles to the module & baud clocks.
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] Serial: Ingenic: Add support for the X1000.
From: Zhou Yanjie @ 2019-01-28 17:03 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-serial, devicetree, robh+dt, paul.burton,
gregkh, jslaby, mark.rutland, syq, jiaxun.yang, 772753199
In-Reply-To: <1548695029-11900-1-git-send-email-zhouyanjie@zoho.com>
Add support for probing the 8250_ingenic driver on the
X1000 Soc from Ingenic.
Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>
---
drivers/tty/serial/8250/8250_ingenic.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index 15a8c8d..424c07c 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -129,22 +129,21 @@ static int __init ingenic_early_console_setup(struct earlycon_device *dev,
return 0;
}
-EARLYCON_DECLARE(jz4740_uart, ingenic_early_console_setup);
OF_EARLYCON_DECLARE(jz4740_uart, "ingenic,jz4740-uart",
ingenic_early_console_setup);
-EARLYCON_DECLARE(jz4770_uart, ingenic_early_console_setup);
OF_EARLYCON_DECLARE(jz4770_uart, "ingenic,jz4770-uart",
ingenic_early_console_setup);
-EARLYCON_DECLARE(jz4775_uart, ingenic_early_console_setup);
OF_EARLYCON_DECLARE(jz4775_uart, "ingenic,jz4775-uart",
ingenic_early_console_setup);
-EARLYCON_DECLARE(jz4780_uart, ingenic_early_console_setup);
OF_EARLYCON_DECLARE(jz4780_uart, "ingenic,jz4780-uart",
ingenic_early_console_setup);
+OF_EARLYCON_DECLARE(x1000_uart, "ingenic,x1000-uart",
+ ingenic_early_console_setup);
+
static void ingenic_uart_serial_out(struct uart_port *p, int offset, int value)
{
int ier;
@@ -328,12 +327,18 @@ static const struct ingenic_uart_config jz4780_uart_config = {
.fifosize = 64,
};
+static const struct ingenic_uart_config x1000_uart_config = {
+ .tx_loadsz = 32,
+ .fifosize = 64,
+};
+
static const struct of_device_id of_match[] = {
{ .compatible = "ingenic,jz4740-uart", .data = &jz4740_uart_config },
{ .compatible = "ingenic,jz4760-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4770-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4775-uart", .data = &jz4760_uart_config },
{ .compatible = "ingenic,jz4780-uart", .data = &jz4780_uart_config },
+ { .compatible = "ingenic,x1000-uart", .data = &x1000_uart_config },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_match);
--
2.7.4
^ permalink raw reply related
* Add Ingenic X1000 serial support
From: Zhou Yanjie @ 2019-01-28 17:03 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-serial, devicetree, robh+dt, paul.burton,
gregkh, jslaby, mark.rutland, syq, jiaxun.yang, 772753199
In-Reply-To: <1548667176-119830-1-git-send-email-zhouyanjie@zoho.com>
v1->v2: Remove unnecessary "EARLYCON_DECLARE".
v2->v3: Use different subject line for each patch.
^ permalink raw reply
* Re: [PATCH v2 1/2] Serial: Ingenic: Add X1000 suppor for the UART driver.
From: Zhou Yanjie @ 2019-01-28 16:45 UTC (permalink / raw)
To: Greg KH
Cc: linux-mips, linux-kernel, linux-serial, devicetree, robh+dt,
paul.burton, jslaby, mark.rutland, syq, jiaxun.yang, 772753199
In-Reply-To: <20190128162245.GA25853@kroah.com>
I am very sorry, I understood wrong before.
On 2019年01月29日 00:22, Greg KH wrote:
> On Mon, Jan 28, 2019 at 09:57:00PM +0800, Zhou Yanjie wrote:
>> Add support for probing the 8250_ingenic driver on the
>> X1000 Soc from Ingenic.
>>
>> Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>
>> ---
>> drivers/tty/serial/8250/8250_ingenic.c | 13 +++++++++----
>> 1 file changed, 9 insertions(+), 4 deletions(-)
> Your subject lines are still identical for both patches :(
^ permalink raw reply
* [PATCH AUTOSEL 3.18 34/61] tty: serial: samsung: Properly set flags in autoCTS mode
From: Sasha Levin @ 2019-01-28 16:25 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Beomho Seo, Marek Szyprowski, Greg Kroah-Hartman, Sasha Levin,
linux-serial
In-Reply-To: <20190128162623.59854-1-sashal@kernel.org>
From: Beomho Seo <beomho.seo@samsung.com>
[ Upstream commit 31e933645742ee6719d37573a27cce0761dcf92b ]
Commit 391f93f2ec9f ("serial: core: Rework hw-assited flow control support")
has changed the way the autoCTS mode is handled.
According to that change, serial drivers which enable H/W autoCTS mode must
set UPSTAT_AUTOCTS to prevent the serial core from inadvertently disabling
TX. This patch adds proper handling of UPSTAT_AUTOCTS flag.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
[mszyprow: rephrased commit message]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/samsung.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 957992ceba0a..67cbc5647c36 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -817,11 +817,14 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
wr_regl(port, S3C2410_ULCON, ulcon);
wr_regl(port, S3C2410_UBRDIV, quot);
+ port->status &= ~UPSTAT_AUTOCTS;
+
umcon = rd_regl(port, S3C2410_UMCON);
if (termios->c_cflag & CRTSCTS) {
umcon |= S3C2410_UMCOM_AFC;
/* Disable RTS when RX FIFO contains 63 bytes */
umcon &= ~S3C2412_UMCON_AFC_8;
+ port->status = UPSTAT_AUTOCTS;
} else {
umcon &= ~S3C2410_UMCOM_AFC;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 3.18 08/61] serial: fsl_lpuart: clear parity enable bit when disable parity
From: Sasha Levin @ 2019-01-28 16:25 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andy Duan, Lukas Wunner, Greg Kroah-Hartman, Sasha Levin,
linux-serial
In-Reply-To: <20190128162623.59854-1-sashal@kernel.org>
From: Andy Duan <fugang.duan@nxp.com>
[ Upstream commit 397bd9211fe014b347ca8f95a8f4e1017bac1aeb ]
Current driver only enable parity enable bit and never clear it
when user set the termios. The fix clear the parity enable bit when
PARENB flag is not set in termios->c_cflag.
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Andy Duan <fugang.duan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/fsl_lpuart.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 92b7a5bf7c4d..839e65da4d3f 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1284,6 +1284,8 @@ lpuart_set_termios(struct uart_port *port, struct ktermios *termios,
else
cr1 &= ~UARTCR1_PT;
}
+ } else {
+ cr1 &= ~UARTCR1_PE;
}
/* ask the core to calculate the divisor */
@@ -1419,6 +1421,8 @@ lpuart32_set_termios(struct uart_port *port, struct ktermios *termios,
else
ctrl &= ~UARTCTRL_PT;
}
+ } else {
+ ctrl &= ~UARTCTRL_PE;
}
/* ask the core to calculate the divisor */
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 45/80] tty: serial: samsung: Properly set flags in autoCTS mode
From: Sasha Levin @ 2019-01-28 16:23 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Beomho Seo, Marek Szyprowski, Greg Kroah-Hartman, Sasha Levin,
linux-serial
In-Reply-To: <20190128162401.58841-1-sashal@kernel.org>
From: Beomho Seo <beomho.seo@samsung.com>
[ Upstream commit 31e933645742ee6719d37573a27cce0761dcf92b ]
Commit 391f93f2ec9f ("serial: core: Rework hw-assited flow control support")
has changed the way the autoCTS mode is handled.
According to that change, serial drivers which enable H/W autoCTS mode must
set UPSTAT_AUTOCTS to prevent the serial core from inadvertently disabling
TX. This patch adds proper handling of UPSTAT_AUTOCTS flag.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
[mszyprow: rephrased commit message]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/samsung.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 4d532a085db9..12bac2cbae4b 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1329,11 +1329,14 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
wr_regl(port, S3C2410_ULCON, ulcon);
wr_regl(port, S3C2410_UBRDIV, quot);
+ port->status &= ~UPSTAT_AUTOCTS;
+
umcon = rd_regl(port, S3C2410_UMCON);
if (termios->c_cflag & CRTSCTS) {
umcon |= S3C2410_UMCOM_AFC;
/* Disable RTS when RX FIFO contains 63 bytes */
umcon &= ~S3C2412_UMCON_AFC_8;
+ port->status = UPSTAT_AUTOCTS;
} else {
umcon &= ~S3C2410_UMCOM_AFC;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 11/80] serial: fsl_lpuart: clear parity enable bit when disable parity
From: Sasha Levin @ 2019-01-28 16:22 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andy Duan, Lukas Wunner, Greg Kroah-Hartman, Sasha Levin,
linux-serial
In-Reply-To: <20190128162401.58841-1-sashal@kernel.org>
From: Andy Duan <fugang.duan@nxp.com>
[ Upstream commit 397bd9211fe014b347ca8f95a8f4e1017bac1aeb ]
Current driver only enable parity enable bit and never clear it
when user set the termios. The fix clear the parity enable bit when
PARENB flag is not set in termios->c_cflag.
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Andy Duan <fugang.duan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/fsl_lpuart.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 01e2274b23f2..8b5ec9386f0f 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1267,6 +1267,8 @@ lpuart_set_termios(struct uart_port *port, struct ktermios *termios,
else
cr1 &= ~UARTCR1_PT;
}
+ } else {
+ cr1 &= ~UARTCR1_PE;
}
/* ask the core to calculate the divisor */
@@ -1402,6 +1404,8 @@ lpuart32_set_termios(struct uart_port *port, struct ktermios *termios,
else
ctrl &= ~UARTCTRL_PT;
}
+ } else {
+ ctrl &= ~UARTCTRL_PE;
}
/* ask the core to calculate the divisor */
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] Serial: Ingenic: Add X1000 suppor for the UART driver.
From: Greg KH @ 2019-01-28 16:22 UTC (permalink / raw)
To: Zhou Yanjie
Cc: linux-mips, linux-kernel, linux-serial, devicetree, robh+dt,
paul.burton, jslaby, mark.rutland, syq, jiaxun.yang, 772753199
In-Reply-To: <1548683821-120924-2-git-send-email-zhouyanjie@zoho.com>
On Mon, Jan 28, 2019 at 09:57:00PM +0800, Zhou Yanjie wrote:
> Add support for probing the 8250_ingenic driver on the
> X1000 Soc from Ingenic.
>
> Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>
> ---
> drivers/tty/serial/8250/8250_ingenic.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
Your subject lines are still identical for both patches :(
^ permalink raw reply
* [PATCH AUTOSEL 4.9 059/107] tty: serial: samsung: Properly set flags in autoCTS mode
From: Sasha Levin @ 2019-01-28 16:18 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Beomho Seo, Marek Szyprowski, Greg Kroah-Hartman, Sasha Levin,
linux-serial
In-Reply-To: <20190128161947.57405-1-sashal@kernel.org>
From: Beomho Seo <beomho.seo@samsung.com>
[ Upstream commit 31e933645742ee6719d37573a27cce0761dcf92b ]
Commit 391f93f2ec9f ("serial: core: Rework hw-assited flow control support")
has changed the way the autoCTS mode is handled.
According to that change, serial drivers which enable H/W autoCTS mode must
set UPSTAT_AUTOCTS to prevent the serial core from inadvertently disabling
TX. This patch adds proper handling of UPSTAT_AUTOCTS flag.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
[mszyprow: rephrased commit message]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/samsung.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 5609305b3676..01ff8ec78023 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1335,11 +1335,14 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
wr_regl(port, S3C2410_ULCON, ulcon);
wr_regl(port, S3C2410_UBRDIV, quot);
+ port->status &= ~UPSTAT_AUTOCTS;
+
umcon = rd_regl(port, S3C2410_UMCON);
if (termios->c_cflag & CRTSCTS) {
umcon |= S3C2410_UMCOM_AFC;
/* Disable RTS when RX FIFO contains 63 bytes */
umcon &= ~S3C2412_UMCON_AFC_8;
+ port->status = UPSTAT_AUTOCTS;
} else {
umcon &= ~S3C2410_UMCOM_AFC;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 013/107] serial: fsl_lpuart: clear parity enable bit when disable parity
From: Sasha Levin @ 2019-01-28 16:18 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andy Duan, Lukas Wunner, Greg Kroah-Hartman, Sasha Levin,
linux-serial
In-Reply-To: <20190128161947.57405-1-sashal@kernel.org>
From: Andy Duan <fugang.duan@nxp.com>
[ Upstream commit 397bd9211fe014b347ca8f95a8f4e1017bac1aeb ]
Current driver only enable parity enable bit and never clear it
when user set the termios. The fix clear the parity enable bit when
PARENB flag is not set in termios->c_cflag.
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Andy Duan <fugang.duan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/fsl_lpuart.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index e2ec04904f54..5c471c3481bd 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1344,6 +1344,8 @@ lpuart_set_termios(struct uart_port *port, struct ktermios *termios,
else
cr1 &= ~UARTCR1_PT;
}
+ } else {
+ cr1 &= ~UARTCR1_PE;
}
/* ask the core to calculate the divisor */
@@ -1487,6 +1489,8 @@ lpuart32_set_termios(struct uart_port *port, struct ktermios *termios,
else
ctrl &= ~UARTCTRL_PT;
}
+ } else {
+ ctrl &= ~UARTCTRL_PE;
}
/* ask the core to calculate the divisor */
--
2.19.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox