From: Peng Fan <[email protected]>
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 <[email protected]>
---
drivers/clk/imx/clk-lpcg-scu.c | 10 ++++++++++
1 file changed, 10 insertions(+)
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);
}
--
2.16.4
Quoting Peng Fan (2019-08-27 01:17:50)
> From: Peng Fan <[email protected]>
>
> 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 <[email protected]>
Does this need a Fixes tag?
On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[email protected]> wrote:
>
> Quoting Peng Fan (2019-08-27 01:17:50)
> > From: Peng Fan <[email protected]>
> >
> > 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 <[email protected]>
>
> 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
>
On Tue, Aug 27, 2019 at 4:19 PM Peng Fan <[email protected]> wrote:
>
> From: Peng Fan <[email protected]>
>
> 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 <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Regards
Aisheng
> On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[email protected]> wrote:
> >
> > Quoting Peng Fan (2019-08-27 01:17:50)
> > > From: Peng Fan <[email protected]>
> > >
> > > 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 <[email protected]>
> >
> > 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.
On Tue, Sep 10, 2019 at 1:40 PM Anson Huang <[email protected]> wrote:
>
>
>
> > On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[email protected]> wrote:
> > >
> > > Quoting Peng Fan (2019-08-27 01:17:50)
> > > > From: Peng Fan <[email protected]>
> > > >
> > > > 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 <[email protected]>
> > >
> > > 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.
On Tue, Sep 10, 2019 at 02:47:59AM +0000, Anson Huang wrote:
>
>
> > On Sat, Sep 7, 2019 at 9:47 PM Stephen Boyd <[email protected]> wrote:
> > >
> > > Quoting Peng Fan (2019-08-27 01:17:50)
> > > > From: Peng Fan <[email protected]>
> > > >
> > > > 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 <[email protected]>
> > >
> > > 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