| Message ID | 1473469413-11019-3-git-send-email-oss@buserror.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, The changes in arm64's <asm/arch_timer.h> are going to conflict with some cleanup [1,2] that just landed in the arm64 for-next/core branch. Could you please rebase atop of that? On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote: > Erratum A-008585 says that the ARM generic timer counter "has the > potential to contain an erroneous value for a small number of core > clock cycles every time the timer value changes". Accesses to TVAL > (both read and write) are also affected due to the implicit counter > read. Accesses to CVAL are not affected. > > The workaround is to reread TVAL and count registers until successive reads > return the same value, and when writing TVAL to retry until counter > reads before and after the write return the same value. This doesn't match the code, which doesn't seem to write TVAL at all, and instead does the work manually, reading CNTVCT then writing to CVAL. Please update the patch description. [...] > +extern struct static_key_false arch_timer_read_ool_enabled; > + > +#define ARCH_TIMER_REG_READ(reg, func) \ > +extern u64 func##_ool(void); \ > +static inline u64 __##func(void) \ > +{ \ > + u64 val; \ > + asm volatile("mrs %0, " reg : "=r" (val)); \ > + return val; \ > +} \ Following recent cleanup, please use read_sysreg(). > +static inline u64 _##func(void) \ > +{ \ > + if (IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) && \ > + static_branch_unlikely(&arch_timer_read_ool_enabled)) \ > + return func##_ool(); \ > + else \ > + return __##func(); \ > +} > + > +ARCH_TIMER_REG_READ("cntp_tval_el0", arch_timer_get_ptval) > +ARCH_TIMER_REG_READ("cntv_tval_el0", arch_timer_get_vtval) > +ARCH_TIMER_REG_READ("cntvct_el0", arch_counter_get_cntvct) > + > +#undef ARCH_TIMER_REG_READ Rather than defining a number of inline functions here as wrappers for read_sysreg(), can we pass the reg name down instead? e.g. #if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) extern struct static_key_false arch_timer_read_ool_enabled; #define needs_fsl_a008585_workaround() \ static_branch_unlikely(&arch_timer_read_ool_enabled) #else #define needs_fsl_a008585_workaround() false #endif #define arch_timer_unstable_reg_read(reg) \ ({ \ if (needs_fsl_a008585_workaround()) \ return __fsl_a008585_read_##reg(); \ else \ return read_sysreg(reg); \ }) ... with __fsl_a008585_read_{cntp_tval_el0,cntv_tval_el0,cntvct_el0} defined appropriately in the driver code. [...] > +static __always_inline void arch_timer_cval_write_cp15(int access, u64 val) > +{ > + if (access == ARCH_TIMER_PHYS_ACCESS) > + asm volatile("msr cntp_cval_el0, %0" : : "r" (val)); > + else if (access == ARCH_TIMER_VIRT_ACCESS) > + asm volatile("msr cntv_cval_el0, %0" : : "r" (val)); > + > + isb(); > +} Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these accesses into arch_timer_reg_write_cp15(). [...] > +#ifdef CONFIG_FSL_ERRATUM_A008585 > +DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled); > +EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled); > + > +/* > + * __always_inline is used to ensure that func() is not an actual function > + * pointer, which would result in the register accesses potentially being too > + * far apart for the loop to work. > + * > + * The timeout is an arbitrary value well beyond the highest number > + * of iterations the loop has been observed to take. > + */ > +static __always_inline u64 fsl_a008585_reread_counter(u64 (*func)(void)) Please: * Rename this to __fsl_a008585_read_reg, as it's used for registers other than the counters. * Make this a macro, to which the register name is passed in, such that it can use read_sysreg(), as with my suggestion above regarding how to restructure the function. * Move this into the ifdef'd block in the arm64 header, leaving the callers where they are in the driver code. > +{ > + u64 cval_old, cval_new; Nit: use 'old' and 'new', so as to not imply that this applies (only) to CNT{V,P}_CVAL. > + int timeout = 200; Nit: s/timeout/retries/ > + > + do { > + isb(); What's the ISB for? The core should order accesses to the same counter, and any ISB required for ordering against other counters should already be present. So I don't follow what this is trying to achieve. If this is necessary, please add a comment explaining what it is intended to ensure. > + cval_old = func(); > + cval_new = func(); > + timeout--; > + } while (unlikely(cval_old != cval_new) && timeout); > + > + WARN_ON_ONCE(!timeout); > + return cval_new; > +} > + > +u64 arch_counter_get_cntvct_ool(void) > +{ > + return fsl_a008585_reread_counter(__arch_counter_get_cntvct); > +} > +EXPORT_SYMBOL(arch_counter_get_cntvct_ool); > + > +u64 arch_timer_get_vtval_ool(void) > +{ > + return fsl_a008585_reread_counter(__arch_timer_get_vtval); > +} > + > +u64 arch_timer_get_ptval_ool(void) > +{ > + return fsl_a008585_reread_counter(__arch_timer_get_ptval); > +} With the above suggestion, these will need to be renamed to something like: __fsl_a008585_read_{cntvct_el0,cntv_tval_el0,cntp_tval_el0} [...] > +#ifdef CONFIG_FSL_ERRATUM_A008585 > +static __always_inline void fsl_a008585_set_next_event(const int access, > + unsigned long evt, struct clock_event_device *clk) > +{ > + unsigned long ctrl; > + u64 cval = evt + arch_counter_get_cntvct(); > + > + ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk); > + ctrl |= ARCH_TIMER_CTRL_ENABLE; > + ctrl &= ~ARCH_TIMER_CTRL_IT_MASK; > + arch_timer_cval_write_cp15(access, cval); > + arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk); > +} > + > +static int fsl_a008585_set_next_event_virt(unsigned long evt, > + struct clock_event_device *clk) > +{ > + fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk); > + return 0; > +} > + > +static int fsl_a008585_set_next_event_phys(unsigned long evt, > + struct clock_event_device *clk) > +{ > + fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk); > + return 0; > +} > +#endif /* CONFIG_FSL_ERRATUM_A008585 */ > + > static int arch_timer_set_next_event_virt(unsigned long evt, > struct clock_event_device *clk) > { > @@ -271,6 +346,19 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt, > return 0; > } > > +static void fsl_a008585_set_sne(struct clock_event_device *clk) > +{ > +#ifdef CONFIG_FSL_ERRATUM_A008585 > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled)) > + return; > + > + if (arch_timer_uses_ppi == VIRT_PPI) > + clk->set_next_event = fsl_a008585_set_next_event_virt; > + else > + clk->set_next_event = fsl_a008585_set_next_event_phys; > +#endif > +} > + I'm not keen on the magic hook to reset the function pointers, and the additional phys/virt stubs seem pointless. Instead, can we fold this into the existing set_next_event? e.g. have that do: if (needs_fsl_a008585_workaround() { fsl_a008585_set_next_event(access, evt, clk); return; } ... with a stub BUILD_BUG() fsl_a008585_set_next_event() when !CONFIG_FSL_ERRATUM_A008585, and: #ifndef needs_fsl_a008585_workaround #define needs_fsl_a008585_workaround() false #endif ... in the driver, so as to not cause issues for 32-bit. [...] > +#ifdef CONFIG_FSL_ERRATUM_A008585 > + /* > + * Don't use the vdso fastpath if errata require using > + * the out-of-line counter accessor. > + */ > + if (static_branch_unlikely(&arch_timer_read_ool_enabled)) > + clocksource_counter.name = "arch_sys_counter_ool"; Can we move the next patch before this, and avoid messing with the name entirely? [...] > @@ -800,6 +899,11 @@ static int __init arch_timer_of_init(struct device_node *np) > > arch_timer_c3stop = !of_property_read_bool(np, "always-on"); > > +#ifdef CONFIG_FSL_ERRATUM_A008585 > + if (of_property_read_bool(np, "fsl,erratum-a008585")) > + static_branch_enable(&arch_timer_read_ool_enabled); > +#endif Please log something, e.g. pr_info("Enabling workaround for FSL erratum A008585\n"); Thanks, Mark. [1] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/commit/?h=arm64/read-write-sysreg&id=ad2d624a50b900a3148d74ed8597508bc472c12e [2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/read-write-sysreg [3] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core
On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > The changes in arm64's <asm/arch_timer.h> are going to conflict with > some cleanup [1,2] that just landed in the arm64 for-next/core branch. > > Could you please rebase atop of that? Well, we should figure out what tree this is going through first. There are a mixture of arm, arm64, driver and dts changes here and not all of it is carrying the appropriate acks for me to queue it. Will
On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > > The changes in arm64's <asm/arch_timer.h> are going to conflict with > > some cleanup [1,2] that just landed in the arm64 for-next/core branch. > > > > Could you please rebase atop of that? > > Well, we should figure out what tree this is going through first. There > are a mixture of arm, arm64, driver and dts changes here and not all > of it is carrying the appropriate acks for me to queue it. Given that mix, I had assumed that this would all go through the arm64 tree -- I see that Rob has already acked the binding, and I'm happy to give my ack for the driver once that's in shape. The dts change could go through arm-soc in parallel, I guess. It doesn't look like arm-soc have been Cc'd for that, though. Thanks, Mark.
On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote: > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch. > > > > > > Could you please rebase atop of that? > > > > Well, we should figure out what tree this is going through first. There > > are a mixture of arm, arm64, driver and dts changes here and not all > > of it is carrying the appropriate acks for me to queue it. > > Given that mix, I had assumed that this would all go through the arm64 > tree -- I see that Rob has already acked the binding, and I'm happy to > give my ack for the driver once that's in shape. Now I see that I'd missed the arch/arm changes in patch 4, which lack a relevant ack. Given that, I don't know what to suggest. Thanks, Mark.
On 12/09/16 13:59, Mark Rutland wrote: > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote: >> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: >>> On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: >>>> The changes in arm64's <asm/arch_timer.h> are going to conflict with >>>> some cleanup [1,2] that just landed in the arm64 for-next/core branch. >>>> >>>> Could you please rebase atop of that? >>> >>> Well, we should figure out what tree this is going through first. There >>> are a mixture of arm, arm64, driver and dts changes here and not all >>> of it is carrying the appropriate acks for me to queue it. >> >> Given that mix, I had assumed that this would all go through the arm64 >> tree -- I see that Rob has already acked the binding, and I'm happy to >> give my ack for the driver once that's in shape. > > Now I see that I'd missed the arch/arm changes in patch 4, which lack a > relevant ack. > > Given that, I don't know what to suggest. I wouldn't mind delaying patch 4 until it gets acked by RMK, as it doesn't impact the functionality. Thanks, M.
On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote: > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: > > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > > > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch. > > > > > > Could you please rebase atop of that? > > Well, we should figure out what tree this is going through first. There > > are a mixture of arm, arm64, driver and dts changes here and not all > > of it is carrying the appropriate acks for me to queue it. > Given that mix, I had assumed that this would all go through the arm64 > tree -- I see that Rob has already acked the binding, and I'm happy to > give my ack for the driver once that's in shape. > > The dts change could go through arm-soc in parallel, I guess. It doesn't > look like arm-soc have been Cc'd for that, though. The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I did. There doesn't appear to be a separate arm-soc mailing list, nor is there a request to CC Olof/Arnd. I did CC Shawn Guo who has been handling the device tree patches for these chips. -Scott
On Mon, 2016-09-12 at 14:07 +0100, Marc Zyngier wrote: > On 12/09/16 13:59, Mark Rutland wrote: > > > > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote: > > > > > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: > > > > > > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > > > > > > > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with > > > > > some cleanup [1,2] that just landed in the arm64 for-next/core > > > > > branch. > > > > > > > > > > Could you please rebase atop of that? > > > > Well, we should figure out what tree this is going through first. > > > > There > > > > are a mixture of arm, arm64, driver and dts changes here and not all > > > > of it is carrying the appropriate acks for me to queue it. > > > Given that mix, I had assumed that this would all go through the arm64 > > > tree -- I see that Rob has already acked the binding, and I'm happy to > > > give my ack for the driver once that's in shape. > > Now I see that I'd missed the arch/arm changes in patch 4, which lack a > > relevant ack. > > > > Given that, I don't know what to suggest. > I wouldn't mind delaying patch 4 until it gets acked by RMK, as it > doesn't impact the functionality. Mark asked me to move that patch before the workaround patch, to avoid ever having to add more code that messes with the name. Should I keep the order as is then? -Scott
On Mon, 2016-09-12 at 12:36 +0100, Mark Rutland wrote: > On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote: > > +static __always_inline void arch_timer_cval_write_cp15(int access, u64 > > val) > > +{ > > + if (access == ARCH_TIMER_PHYS_ACCESS) > > + asm volatile("msr cntp_cval_el0, %0" : : "r" (val)); > > + else if (access == ARCH_TIMER_VIRT_ACCESS) > > + asm volatile("msr cntv_cval_el0, %0" : : "r" (val)); > > + > > + isb(); > > +} > Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these > accesses into arch_timer_reg_write_cp15(). Adding ARCH_TIMER_REG_CVAL to the enum means we get warnings from bunch of switch statements that don't actually need a CVAL implementation -- or else we have to add untested CVAL accessors for arm32 and mmio. The arm32 part would add another dependency on getting an ack from RMK, that can't be postponed as easily as the archdata/vdso patch. Since this is specific to an erratum rather than general cval support, I can move the accesses into fsl_a008585_set_next_event (and convert to write_sysreg). > > > > + > > + do { > > + isb(); > What's the ISB for? > > The core should order accesses to the same counter, and any ISB required > for ordering against other counters should already be present. So I > don't follow what this is trying to achieve. > > If this is necessary, please add a comment explaining what it is > intended to ensure. I think it may have been a leftover from early patch versions when this function was entirely replacing arch_counter_get_cntvct(). I'm not sure why I put it in the loop, though. > > @@ -271,6 +346,19 @@ static int > > arch_timer_set_next_event_phys_mem(unsigned long evt, > > return 0; > > } > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk) > > +{ > > +#ifdef CONFIG_FSL_ERRATUM_A008585 > > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled)) > > + return; > > + > > + if (arch_timer_uses_ppi == VIRT_PPI) > > + clk->set_next_event = fsl_a008585_set_next_event_virt; > > + else > > + clk->set_next_event = fsl_a008585_set_next_event_phys; > > +#endif > > +} > > + > I'm not keen on the magic hook to reset the function pointers, and the > additional phys/virt stubs seem pointless. Instead, can we fold this > into the existing set_next_event? e.g. have that do: > > if (needs_fsl_a008585_workaround() { > fsl_a008585_set_next_event(access, evt, clk); > return; > } OK. I had been trying to avoid messing with the standard set_next_event, but it doesn't matter as much now that static branches are being used. In that case we can avoid duplicating the ctrl code, and only replace the tval write. -Scott
On Sunday, September 18, 2016 11:28:44 PM CEST Scott Wood wrote: > On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote: > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: > > > > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > > > > > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with > > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch. > > > > > > > > Could you please rebase atop of that? > > > Well, we should figure out what tree this is going through first. There > > > are a mixture of arm, arm64, driver and dts changes here and not all > > > of it is carrying the appropriate acks for me to queue it. > > Given that mix, I had assumed that this would all go through the arm64 > > tree -- I see that Rob has already acked the binding, and I'm happy to > > give my ack for the driver once that's in shape. > > > > The dts change could go through arm-soc in parallel, I guess. It doesn't > > look like arm-soc have been Cc'd for that, though. > > The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I > did. There doesn't appear to be a separate arm-soc mailing list, nor is there > a request to CC Olof/Arnd. I did CC Shawn Guo who has been handling the > device tree patches for these chips. That is the right way to do it. If the DT change is a bugfix that should get merged along with the rest, Shawn can also provide an Ack to have it merged through the arm64 tree, ideally warning us if there might be any conflicts with stuff that gets sent for arm-soc. Arnd
On Sun, Sep 18, 2016 at 11:41:25PM -0500, Scott Wood wrote: > On Mon, 2016-09-12 at 12:36 +0100, Mark Rutland wrote: > > On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote: > > > +static __always_inline void arch_timer_cval_write_cp15(int access, u64 > > > val) > > > +{ > > > + if (access == ARCH_TIMER_PHYS_ACCESS) > > > + asm volatile("msr cntp_cval_el0, %0" : : "r" (val)); > > > + else if (access == ARCH_TIMER_VIRT_ACCESS) > > > + asm volatile("msr cntv_cval_el0, %0" : : "r" (val)); > > > + > > > + isb(); > > > +} > > Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these > > accesses into arch_timer_reg_write_cp15(). > > Adding ARCH_TIMER_REG_CVAL to the enum means we get warnings from bunch of > switch statements that don't actually need a CVAL implementation -- or else we > have to add untested CVAL accessors for arm32 and mmio. The arm32 part would > add another dependency on getting an ack from RMK, that can't be postponed as > easily as the archdata/vdso patch. That's annoying. Never mind, then. > Since this is specific to an erratum rather than general cval support, I can > move the accesses into fsl_a008585_set_next_event (and convert to > write_sysreg). Ok. I think that's preferable given we have no other users. > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk) > > > +{ > > > +#ifdef CONFIG_FSL_ERRATUM_A008585 > > > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled)) > > > + return; > > > + > > > + if (arch_timer_uses_ppi == VIRT_PPI) > > > + clk->set_next_event = fsl_a008585_set_next_event_virt; > > > + else > > > + clk->set_next_event = fsl_a008585_set_next_event_phys; > > > +#endif > > > +} > > > + > > I'm not keen on the magic hook to reset the function pointers, and the > > additional phys/virt stubs seem pointless. Instead, can we fold this > > into the existing set_next_event? e.g. have that do: > > > > if (needs_fsl_a008585_workaround() { > > fsl_a008585_set_next_event(access, evt, clk); > > return; > > } > > OK. I had been trying to avoid messing with the standard set_next_event, but > it doesn't matter as much now that static branches are being used. In that > case we can avoid duplicating the ctrl code, and only replace the tval write. Reconsidering my suggestion, I realise this will also affect the MMIO timers, so that doesn't work. So for the moment, I guess we have to keep fsl_a008585_set_next_event(). Thanks, Mark.
On Sun, Sep 18, 2016 at 11:31:45PM -0500, Scott Wood wrote: > On Mon, 2016-09-12 at 14:07 +0100, Marc Zyngier wrote: > > On 12/09/16 13:59, Mark Rutland wrote: > > > > > > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote: > > > > > > > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: > > > > > > > > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > > > > > > > > > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with > > > > > > some cleanup [1,2] that just landed in the arm64 for-next/core > > > > > > branch. > > > > > > > > > > > > Could you please rebase atop of that? > > > > > Well, we should figure out what tree this is going through first. > > > > > There > > > > > are a mixture of arm, arm64, driver and dts changes here and not all > > > > > of it is carrying the appropriate acks for me to queue it. > > > > Given that mix, I had assumed that this would all go through the arm64 > > > > tree -- I see that Rob has already acked the binding, and I'm happy to > > > > give my ack for the driver once that's in shape. > > > Now I see that I'd missed the arch/arm changes in patch 4, which lack a > > > relevant ack. > > > > > > Given that, I don't know what to suggest. > > I wouldn't mind delaying patch 4 until it gets acked by RMK, as it > > doesn't impact the functionality. > > Mark asked me to move that patch before the workaround patch, to avoid ever > having to add more code that messes with the name. Should I keep the order as > is then? Yes; at this stage I think we have to. Thanks, Mark.
On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote: > > > > > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk) > > > > +{ > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585 > > > > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled)) > > > > + return; > > > > + > > > > + if (arch_timer_uses_ppi == VIRT_PPI) > > > > + clk->set_next_event = > > > > fsl_a008585_set_next_event_virt; > > > > + else > > > > + clk->set_next_event = > > > > fsl_a008585_set_next_event_phys; > > > > +#endif > > > > +} > > > > + > > > I'm not keen on the magic hook to reset the function pointers, and the > > > additional phys/virt stubs seem pointless. Instead, can we fold this > > > into the existing set_next_event? e.g. have that do: > > > > > > if (needs_fsl_a008585_workaround() { > > > fsl_a008585_set_next_event(access, evt, clk); > > > return; > > > } > > OK. I had been trying to avoid messing with the standard set_next_event, > > but > > it doesn't matter as much now that static branches are being used. In > > that > > case we can avoid duplicating the ctrl code, and only replace the tval > > write. > Reconsidering my suggestion, I realise this will also affect the MMIO > timers, so that doesn't work. > > So for the moment, I guess we have to keep fsl_a008585_set_next_event(). What is the problem with MMIO timers? needs_fsl_a008585_workaround() should always be false for them. -Scott
On Mon, Sep 19, 2016 at 12:01:29PM -0500, Scott Wood wrote: > On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote: > > > > > > > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk) > > > > > +{ > > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585 > > > > > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled)) > > > > > + return; > > > > > + > > > > > + if (arch_timer_uses_ppi == VIRT_PPI) > > > > > + clk->set_next_event = > > > > > fsl_a008585_set_next_event_virt; > > > > > + else > > > > > + clk->set_next_event = > > > > > fsl_a008585_set_next_event_phys; > > > > > +#endif > > > > > +} > > > > > + > > > > I'm not keen on the magic hook to reset the function pointers, and the > > > > additional phys/virt stubs seem pointless. Instead, can we fold this > > > > into the existing set_next_event? e.g. have that do: > > > > > > > > if (needs_fsl_a008585_workaround() { > > > > fsl_a008585_set_next_event(access, evt, clk); > > > > return; > > > > } > > > OK. I had been trying to avoid messing with the standard set_next_event, > > > but > > > it doesn't matter as much now that static branches are being used. In > > > that > > > case we can avoid duplicating the ctrl code, and only replace the tval > > > write. > > Reconsidering my suggestion, I realise this will also affect the MMIO > > timers, so that doesn't work. > > > > So for the moment, I guess we have to keep fsl_a008585_set_next_event(). > > What is the problem with MMIO timers? needs_fsl_a008585_workaround() should > always be false for them. As suggested, needs_fsl_a008585_workaround() takes no parameter, and set_next_event is called for both cp15/sysreg and MMIO timers. So it would either be true for all, or false for all. If it's true for all, we'd end up calling fsl_a008585_set_next_event() for the MMIO timers too. Thanks, Mark.
On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote: > On Mon, Sep 19, 2016 at 12:01:29PM -0500, Scott Wood wrote: > > > > On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk) > > > > > > +{ > > > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585 > > > > > > + if > > > > > > (!static_branch_unlikely(&arch_timer_read_ool_enabled)) > > > > > > + return; > > > > > > + > > > > > > + if (arch_timer_uses_ppi == VIRT_PPI) > > > > > > + clk->set_next_event = > > > > > > fsl_a008585_set_next_event_virt; > > > > > > + else > > > > > > + clk->set_next_event = > > > > > > fsl_a008585_set_next_event_phys; > > > > > > +#endif > > > > > > +} > > > > > > + > > > > > I'm not keen on the magic hook to reset the function pointers, and > > > > > the > > > > > additional phys/virt stubs seem pointless. Instead, can we fold this > > > > > into the existing set_next_event? e.g. have that do: > > > > > > > > > > if (needs_fsl_a008585_workaround() { > > > > > fsl_a008585_set_next_event(access, evt, clk); > > > > > return; > > > > > } > > > > OK. I had been trying to avoid messing with the standard > > > > set_next_event, > > > > but > > > > it doesn't matter as much now that static branches are being used. In > > > > that > > > > case we can avoid duplicating the ctrl code, and only replace the tval > > > > write. > > > Reconsidering my suggestion, I realise this will also affect the MMIO > > > timers, so that doesn't work. > > > > > > So for the moment, I guess we have to keep fsl_a008585_set_next_event(). > > What is the problem with MMIO timers? needs_fsl_a008585_workaround() > > should > > always be false for them. > As suggested, needs_fsl_a008585_workaround() takes no parameter, and > set_next_event is called for both cp15/sysreg and MMIO timers. So it > would either be true for all, or false for all. > > If it's true for all, we'd end up calling fsl_a008585_set_next_event() > for the MMIO timers too. There should not be any MMIO timers on a system where fsl_a008585_set_next_event() returns true. -Scott
On Mon, Sep 19, 2016 at 02:16:00PM -0500, Scott Wood wrote: > On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote: > > > > Reconsidering my suggestion, I realise this will also affect the MMIO > > > > timers, so that doesn't work. > > > > > > > > So for the moment, I guess we have to keep fsl_a008585_set_next_event(). > > > What is the problem with MMIO timers? needs_fsl_a008585_workaround() > > > should > > > always be false for them. > > As suggested, needs_fsl_a008585_workaround() takes no parameter, and > > set_next_event is called for both cp15/sysreg and MMIO timers. So it > > would either be true for all, or false for all. > > > > If it's true for all, we'd end up calling fsl_a008585_set_next_event() > > for the MMIO timers too. > > There should not be any MMIO timers on a system where > fsl_a008585_set_next_event() returns true. I'm generally not keen on relying on that. For reference, are no MMIO timers implemented at all, or are they simply not listed in the DT today? Thanks, Mark.
On Sun, Sep 18, 2016 at 11:28:44PM -0500, Scott Wood wrote: > On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote: > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote: > > > > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote: > > > > > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with > > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch. > > > > > > > > Could you please rebase atop of that? > > > Well, we should figure out what tree this is going through first. There > > > are a mixture of arm, arm64, driver and dts changes here and not all > > > of it is carrying the appropriate acks for me to queue it. > > Given that mix, I had assumed that this would all go through the arm64 > > tree -- I see that Rob has already acked the binding, and I'm happy to > > give my ack for the driver once that's in shape. > > > > The dts change could go through arm-soc in parallel, I guess. It doesn't > > look like arm-soc have been Cc'd for that, though. > > The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I > did. There doesn't appear to be a separate arm-soc mailing list, nor is there > a request to CC Olof/Arnd. I did CC Shawn Guo who has been handling the > device tree patches for these chips. This is kind of new feature development, and there is no hard dependency between driver and DTS changes. In this case, we normally pick up the DTS patch only after driver part get accepted. Shawn
On Tue, 2016-09-20 at 10:35 +0100, Mark Rutland wrote: > On Mon, Sep 19, 2016 at 02:16:00PM -0500, Scott Wood wrote: > > > > On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote: > > > > > > > > > > > > > > > > > Reconsidering my suggestion, I realise this will also affect the > > > > > MMIO > > > > > timers, so that doesn't work. > > > > > > > > > > So for the moment, I guess we have to keep > > > > > fsl_a008585_set_next_event(). > > > > What is the problem with MMIO timers? needs_fsl_a008585_workaround() > > > > should > > > > always be false for them. > > > As suggested, needs_fsl_a008585_workaround() takes no parameter, and > > > set_next_event is called for both cp15/sysreg and MMIO timers. So it > > > would either be true for all, or false for all. > > > > > > If it's true for all, we'd end up calling fsl_a008585_set_next_event() > > > for the MMIO timers too. > > There should not be any MMIO timers on a system where > > fsl_a008585_set_next_event() returns true. > I'm generally not keen on relying on that. > > For reference, are no MMIO timers implemented at all, or are they simply > not listed in the DT today? As far as I can tell they're not implemented, but it's possible I'm just not looking at the right documentation. I agree though that depending on that isn't particularly pretty. I'll stick with the current approach for set_next_event(). -Scott
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt index ccc6032..405da11 100644 --- a/Documentation/arm64/silicon-errata.txt +++ b/Documentation/arm64/silicon-errata.txt @@ -61,3 +61,5 @@ stable kernels. | Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 | | Cavium | ThunderX SMMUv2 | #27704 | N/A | +| | | | | +| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h index fbe0ca3..927dc6f 100644 --- a/arch/arm64/include/asm/arch_timer.h +++ b/arch/arm64/include/asm/arch_timer.h @@ -23,10 +23,36 @@ #include <linux/bug.h> #include <linux/init.h> +#include <linux/jump_label.h> #include <linux/types.h> #include <clocksource/arm_arch_timer.h> +extern struct static_key_false arch_timer_read_ool_enabled; + +#define ARCH_TIMER_REG_READ(reg, func) \ +extern u64 func##_ool(void); \ +static inline u64 __##func(void) \ +{ \ + u64 val; \ + asm volatile("mrs %0, " reg : "=r" (val)); \ + return val; \ +} \ +static inline u64 _##func(void) \ +{ \ + if (IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) && \ + static_branch_unlikely(&arch_timer_read_ool_enabled)) \ + return func##_ool(); \ + else \ + return __##func(); \ +} + +ARCH_TIMER_REG_READ("cntp_tval_el0", arch_timer_get_ptval) +ARCH_TIMER_REG_READ("cntv_tval_el0", arch_timer_get_vtval) +ARCH_TIMER_REG_READ("cntvct_el0", arch_counter_get_cntvct) + +#undef ARCH_TIMER_REG_READ + /* * These register accessors are marked inline so the compiler can * nicely work out which register we want, and chuck away the rest of @@ -58,6 +84,16 @@ void arch_timer_reg_write_cp15(int access, enum arch_timer_reg reg, u32 val) isb(); } +static __always_inline void arch_timer_cval_write_cp15(int access, u64 val) +{ + if (access == ARCH_TIMER_PHYS_ACCESS) + asm volatile("msr cntp_cval_el0, %0" : : "r" (val)); + else if (access == ARCH_TIMER_VIRT_ACCESS) + asm volatile("msr cntv_cval_el0, %0" : : "r" (val)); + + isb(); +} + static __always_inline u32 arch_timer_reg_read_cp15(int access, enum arch_timer_reg reg) { @@ -66,19 +102,19 @@ u32 arch_timer_reg_read_cp15(int access, enum arch_timer_reg reg) if (access == ARCH_TIMER_PHYS_ACCESS) { switch (reg) { case ARCH_TIMER_REG_CTRL: - asm volatile("mrs %0, cntp_ctl_el0" : "=r" (val)); + asm volatile("mrs %0, cntp_ctl_el0" : "=r" (val)); break; case ARCH_TIMER_REG_TVAL: - asm volatile("mrs %0, cntp_tval_el0" : "=r" (val)); + val = _arch_timer_get_ptval(); break; } } else if (access == ARCH_TIMER_VIRT_ACCESS) { switch (reg) { case ARCH_TIMER_REG_CTRL: - asm volatile("mrs %0, cntv_ctl_el0" : "=r" (val)); + asm volatile("mrs %0, cntv_ctl_el0" : "=r" (val)); break; case ARCH_TIMER_REG_TVAL: - asm volatile("mrs %0, cntv_tval_el0" : "=r" (val)); + val = _arch_timer_get_vtval(); break; } } @@ -116,12 +152,8 @@ static inline u64 arch_counter_get_cntpct(void) static inline u64 arch_counter_get_cntvct(void) { - u64 cval; - isb(); - asm volatile("mrs %0, cntvct_el0" : "=r" (cval)); - - return cval; + return _arch_counter_get_cntvct(); } static inline int arch_timer_arch_init(void) diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 5677886..8a753fd 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -305,6 +305,16 @@ config ARM_ARCH_TIMER_EVTSTREAM This must be disabled for hardware validation purposes to detect any hardware anomalies of missing events. +config FSL_ERRATUM_A008585 + bool "Workaround for Freescale/NXP Erratum A-008585" + default y + depends on ARM_ARCH_TIMER && ARM64 + help + This option enables a workaround for Freescale/NXP Erratum + A-008585 ("ARM generic timer may contain an erroneous + value"). The workaround will only be active if the + fsl,erratum-a008585 property is found in the timer node. + config ARM_GLOBAL_TIMER bool "Support for the ARM global timer" if COMPILE_TEST select CLKSRC_OF if OF diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 5770054..2526543 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -94,6 +94,52 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg); * Architected system timer support. */ +#ifdef CONFIG_FSL_ERRATUM_A008585 +DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled); +EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled); + +/* + * __always_inline is used to ensure that func() is not an actual function + * pointer, which would result in the register accesses potentially being too + * far apart for the loop to work. + * + * The timeout is an arbitrary value well beyond the highest number + * of iterations the loop has been observed to take. + */ +static __always_inline u64 fsl_a008585_reread_counter(u64 (*func)(void)) +{ + u64 cval_old, cval_new; + int timeout = 200; + + do { + isb(); + cval_old = func(); + cval_new = func(); + timeout--; + } while (unlikely(cval_old != cval_new) && timeout); + + WARN_ON_ONCE(!timeout); + return cval_new; +} + +u64 arch_counter_get_cntvct_ool(void) +{ + return fsl_a008585_reread_counter(__arch_counter_get_cntvct); +} +EXPORT_SYMBOL(arch_counter_get_cntvct_ool); + +u64 arch_timer_get_vtval_ool(void) +{ + return fsl_a008585_reread_counter(__arch_timer_get_vtval); +} + +u64 arch_timer_get_ptval_ool(void) +{ + return fsl_a008585_reread_counter(__arch_timer_get_ptval); +} + +#endif /* CONFIG_FSL_ERRATUM_A008585 */ + static __always_inline void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val, struct clock_event_device *clk) @@ -243,6 +289,35 @@ static __always_inline void set_next_event(const int access, unsigned long evt, arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk); } +#ifdef CONFIG_FSL_ERRATUM_A008585 +static __always_inline void fsl_a008585_set_next_event(const int access, + unsigned long evt, struct clock_event_device *clk) +{ + unsigned long ctrl; + u64 cval = evt + arch_counter_get_cntvct(); + + ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk); + ctrl |= ARCH_TIMER_CTRL_ENABLE; + ctrl &= ~ARCH_TIMER_CTRL_IT_MASK; + arch_timer_cval_write_cp15(access, cval); + arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk); +} + +static int fsl_a008585_set_next_event_virt(unsigned long evt, + struct clock_event_device *clk) +{ + fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk); + return 0; +} + +static int fsl_a008585_set_next_event_phys(unsigned long evt, + struct clock_event_device *clk) +{ + fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk); + return 0; +} +#endif /* CONFIG_FSL_ERRATUM_A008585 */ + static int arch_timer_set_next_event_virt(unsigned long evt, struct clock_event_device *clk) { @@ -271,6 +346,19 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt, return 0; } +static void fsl_a008585_set_sne(struct clock_event_device *clk) +{ +#ifdef CONFIG_FSL_ERRATUM_A008585 + if (!static_branch_unlikely(&arch_timer_read_ool_enabled)) + return; + + if (arch_timer_uses_ppi == VIRT_PPI) + clk->set_next_event = fsl_a008585_set_next_event_virt; + else + clk->set_next_event = fsl_a008585_set_next_event_phys; +#endif +} + static void __arch_timer_setup(unsigned type, struct clock_event_device *clk) { @@ -299,6 +387,8 @@ static void __arch_timer_setup(unsigned type, default: BUG(); } + + fsl_a008585_set_sne(clk); } else { clk->features |= CLOCK_EVT_FEAT_DYNIRQ; clk->name = "arch_mem_timer"; @@ -515,6 +605,15 @@ static void __init arch_counter_register(unsigned type) arch_timer_read_counter = arch_counter_get_cntvct; else arch_timer_read_counter = arch_counter_get_cntpct; + +#ifdef CONFIG_FSL_ERRATUM_A008585 + /* + * Don't use the vdso fastpath if errata require using + * the out-of-line counter accessor. + */ + if (static_branch_unlikely(&arch_timer_read_ool_enabled)) + clocksource_counter.name = "arch_sys_counter_ool"; +#endif } else { arch_timer_read_counter = arch_counter_get_cntvct_mem; @@ -800,6 +899,11 @@ static int __init arch_timer_of_init(struct device_node *np) arch_timer_c3stop = !of_property_read_bool(np, "always-on"); +#ifdef CONFIG_FSL_ERRATUM_A008585 + if (of_property_read_bool(np, "fsl,erratum-a008585")) + static_branch_enable(&arch_timer_read_ool_enabled); +#endif + /* * If we cannot rely on firmware initializing the timer registers then * we should use the physical timers instead.
Erratum A-008585 says that the ARM generic timer counter "has the potential to contain an erroneous value for a small number of core clock cycles every time the timer value changes". Accesses to TVAL (both read and write) are also affected due to the implicit counter read. Accesses to CVAL are not affected. The workaround is to reread TVAL and count registers until successive reads return the same value, and when writing TVAL to retry until counter reads before and after the write return the same value. This erratum can be found on LS1043A and LS2080A. Signed-off-by: Scott Wood <oss@buserror.net> --- v5: - Export arch_timer_read_ool_enabled so that get_cycles() can be called from modules. v4: - Undef ARCH_TIMER_REG_READ after use v3: - Used cval rather than a loop for the write side of the erratum - Added a Kconfig control - Moved the device tree binding into its own patch - Added erratum to silicon-errata.txt - Changed function names to contain the erratum name - Factored out the setting of erratum versions of set_next_event to improve readability - Added a comment clarifying that the timeout is arbitrary v2: Significant rework based on feedback, including using static_key, disabling VDSO counter access rather than adding the workaround to the VDSO, and uninlining the loops. Dropped the separate property for indicating that writes to TVAL are affected, as I believe that's just a side effect of the implicit counter read being corrupted, and thus a chip that is affected by one will always be affected by the other. Dropped the arm32 portion as it seems there was confusion about whether LS1021A is affected. Currently I am being told that it is not affected. I considered writing to CVAL rather than looping on TVAL writes, but that would still have required separate set_next_event() code for the erratum, and adding CVAL to the enum would have required a bunch of extra handlers in switch statements (even where unused, due to compiler warnings about unhandled enum values) including in an arm32 header. It seemed better to avoid the arm32 interaction and new untested accessors. --- Documentation/arm64/silicon-errata.txt | 2 + arch/arm64/include/asm/arch_timer.h | 50 +++++++++++++--- drivers/clocksource/Kconfig | 10 ++++ drivers/clocksource/arm_arch_timer.c | 104 +++++++++++++++++++++++++++++++++ 4 files changed, 157 insertions(+), 9 deletions(-)