Re: [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 8/12/2020 7:03 AM, John Stultz wrote:
On Tue, Aug 11, 2020 at 4:11 PM John Stultz <john.stultz@xxxxxxxxxx> wrote:

On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak <rnayak@xxxxxxxxxxxxxx> wrote:

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@xxxxxxxxxxxxxx>
Signed-off-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
---
  drivers/tty/serial/qcom_geni_serial.c | 15 +++++++++++++--
  1 file changed, 13 insertions(+), 2 deletions(-)


Hey,
   I just wanted to follow up on this patch, as I've bisected it
(a5819b548af0) down as having broken qca bluetooth on the Dragonboard
845c.

I haven't yet had time to debug it yet, but wanted to raise the issue
in case anyone else has seen similar trouble.

So I dug in a bit further, and this chunk seems to be causing the issue:
@@ -961,7 +963,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;



With that applied, I see the following errors in dmesg and bluetooth
fails to function:
[    4.763467] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate:
failed to find OPP for freq 102400000 (-34)
[    4.773493] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate:
failed to find OPP for freq 102400000 (-34)

With just that chunk reverted on linus/HEAD, bluetooth seems to work ok.

This seems like the same issue that was also reported on venus [1] because the
clock frequency tables apparently don;t exactly match the achievable clock
frequencies (which we also used to construct the OPP tables)

Can you try updating the OPP table for QUP to have 102400000 instead of the
current 100000000 and see if that fixes it?

[1] https://lkml.org/lkml/2020/7/27/507


thanks
-john


--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux