clk: imx: lpcg: write twice when writing lpcg regs

Commit Message

Peng Fan Aug. 27, 2019, 8:17 a.m. UTC

From: Peng Fan <[e-mail]>

There is hardware issue that:
The output clock the LPCG cell will not turn back on as expected,
even though a read of the IPG registers in the LPCG indicates that
the clock should be enabled.

The software workaround is to write twice to enable the LPCG clock
output.

Signed-off-by: Peng Fan <[e-mail]>
---
 drivers/clk/imx/clk-lpcg-scu.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Stephen Boyd Sept. 6, 2019, 5:20 p.m. UTC | #1

Quoting Peng Fan (2019-08-27 01:17:50)
> From: Peng Fan <[e-mail]>
> 
> There is hardware issue that:
> The output clock the LPCG cell will not turn back on as expected,
> even though a read of the IPG registers in the LPCG indicates that
> the clock should be enabled.
> 
> The software workaround is to write twice to enable the LPCG clock
> output.
> 
> Signed-off-by: Peng Fan <[e-mail]>

Does this need a Fixes tag?

Dong Aisheng Sept. 9, 2019, 11:44 a.m. UTC | #2

On Tue, Aug 27, 2019 at 4:19 PM Peng Fan <[e-mail]> wrote:
>
> From: Peng Fan <[e-mail]>
>
> There is hardware issue that:
> The output clock the LPCG cell will not turn back on as expected,
> even though a read of the IPG registers in the LPCG indicates that
> the clock should be enabled.
>
> The software workaround is to write twice to enable the LPCG clock
> output.
>
> Signed-off-by: Peng Fan <[e-mail]>

Reviewed-by: Dong Aisheng <[e-mail]>

Regards
Aisheng

Dong Aisheng Sept. 9, 2019, 11:51 a.m. UTC | #3

On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[e-mail]> wrote:
>
> Quoting Peng Fan (2019-08-27 01:17:50)
> > From: Peng Fan <[e-mail]>
> >
> > There is hardware issue that:
> > The output clock the LPCG cell will not turn back on as expected,
> > even though a read of the IPG registers in the LPCG indicates that
> > the clock should be enabled.
> >
> > The software workaround is to write twice to enable the LPCG clock
> > output.
> >
> > Signed-off-by: Peng Fan <[e-mail]>
>
> Does this need a Fixes tag?

Not sure as it's not code logic issue but a hardware bug.
And 4.19 LTS still have not this driver support.

Regards
Aisheng

>

Anson Huang Sept. 10, 2019, 2:47 a.m. UTC | #4

> On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[e-mail]> wrote:
> >
> > Quoting Peng Fan (2019-08-27 01:17:50)
> > > From: Peng Fan <[e-mail]>
> > >
> > > There is hardware issue that:
> > > The output clock the LPCG cell will not turn back on as expected,
> > > even though a read of the IPG registers in the LPCG indicates that
> > > the clock should be enabled.
> > >
> > > The software workaround is to write twice to enable the LPCG clock
> > > output.
> > >
> > > Signed-off-by: Peng Fan <[e-mail]>
> >
> > Does this need a Fixes tag?
> 
> Not sure as it's not code logic issue but a hardware bug.
> And 4.19 LTS still have not this driver support.

Looks like there is an errata for this issue, and Ranjani just sent a patch for review internally,

Back-to-back LPCG writes can be ignored by the LPCG register due to a 
HW bug. The writes need to be separated by atleast 4 cycles of the gated clock.
The workaround is implemented as follows:
1. For clocks running greater than 50MHz no delay is required as the 
delay in accessing the LPCG register is sufficient.
2. For clocks running greater than 23MHz, a read followed by the write 
will provide the sufficient delay.
3. For clocks running below 23MHz, LPCG is not used.

Need double check?

Anson.

Daniel Baluta Sept. 10, 2019, 11:50 a.m. UTC | #5

On Tue, Sep 10, 2019 at 1:40 PM Anson Huang <[e-mail]> wrote:
>
>
>
> > On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[e-mail]> wrote:
> > >
> > > Quoting Peng Fan (2019-08-27 01:17:50)
> > > > From: Peng Fan <[e-mail]>
> > > >
> > > > There is hardware issue that:
> > > > The output clock the LPCG cell will not turn back on as expected,
> > > > even though a read of the IPG registers in the LPCG indicates that
> > > > the clock should be enabled.
> > > >
> > > > The software workaround is to write twice to enable the LPCG clock
> > > > output.
> > > >
> > > > Signed-off-by: Peng Fan <[e-mail]>
> > >
> > > Does this need a Fixes tag?
> >
> > Not sure as it's not code logic issue but a hardware bug.
> > And 4.19 LTS still have not this driver support.
>
> Looks like there is an errata for this issue, and Ranjani just sent a patch for review internally,
>
> Back-to-back LPCG writes can be ignored by the LPCG register due to a
> HW bug. The writes need to be separated by atleast 4 cycles of the gated clock.
> The workaround is implemented as follows:
> 1. For clocks running greater than 50MHz no delay is required as the
> delay in accessing the LPCG register is sufficient.
> 2. For clocks running greater than 23MHz, a read followed by the write
> will provide the sufficient delay.
> 3. For clocks running below 23MHz, LPCG is not used.

Lets add this information in the commit message and also
enhance the comment before the double write.

Also, why can't we add a udelay after the first write and remove
the second write as having two writes for writing a value looks
very un-natural.

Shawn Guo Sept. 13, 2019, 3:42 a.m. UTC | #6

On Tue, Sep 10, 2019 at 02:47:59AM +0000, Anson Huang wrote:
> 
> 
> > On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[e-mail]> wrote:
> > >
> > > Quoting Peng Fan (2019-08-27 01:17:50)
> > > > From: Peng Fan <[e-mail]>
> > > >
> > > > There is hardware issue that:
> > > > The output clock the LPCG cell will not turn back on as expected,
> > > > even though a read of the IPG registers in the LPCG indicates that
> > > > the clock should be enabled.
> > > >
> > > > The software workaround is to write twice to enable the LPCG clock
> > > > output.
> > > >
> > > > Signed-off-by: Peng Fan <[e-mail]>
> > >
> > > Does this need a Fixes tag?
> > 
> > Not sure as it's not code logic issue but a hardware bug.
> > And 4.19 LTS still have not this driver support.
> 
> Looks like there is an errata for this issue, and Ranjani just sent a patch for review internally,

Having errata number in both commit log and code comment is generally
helpful.

Shawn

Patch

diff --git a/drivers/clk/imx/clk-lpcg-scu.c b/drivers/clk/imx/clk-lpcg-scu.c
index a73a799fb777..7391d0668ec4 100644
--- a/drivers/clk/imx/clk-lpcg-scu.c
+++ b/drivers/clk/imx/clk-lpcg-scu.c
@@ -54,6 +54,11 @@  static int clk_lpcg_scu_enable(struct clk_hw *hw)
 
 	reg |= val << clk->bit_idx;
 	writel(reg, clk->reg);
+	/*
+	 * There is hardware bug. When enabling the LPCG clock
+	 * output, SW can write the enabling value twice
+	 */
+	writel(reg, clk->reg);
 
 	spin_unlock_irqrestore(&imx_lpcg_scu_lock, flags);
 
@@ -71,6 +76,11 @@  static void clk_lpcg_scu_disable(struct clk_hw *hw)
 	reg = readl_relaxed(clk->reg);
 	reg &= ~(CLK_GATE_SCU_LPCG_MASK << clk->bit_idx);
 	writel(reg, clk->reg);
+	/*
+	 * There is hardware bug. When enabling the LPCG clock
+	 * output, SW can write the enabling value twice
+	 */
+	writel(reg, clk->reg);
 
 	spin_unlock_irqrestore(&imx_lpcg_scu_lock, flags);
 }