[RFC Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64

Dave Kleikamp shaggy at linux.vnet.ibm.com
Sat Mar 27 08:11:45 EST 2010


On Tue, 2010-03-23 at 19:37 +0530, K.Prasad wrote:
> plain text document attachment (ppc64_hbkpt_02)
> Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
> These interfaces help arbitrate requests from various users and schedules
> them as appropriate.
> 
> Signed-off-by: K.Prasad <prasad at linux.vnet.ibm.com>

SNIP

> Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h
> ===================================================================
> --- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/cputable.h
> +++ linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h
> @@ -511,6 +511,13 @@ static inline int cpu_has_feature(unsign
>  		& feature);
>  }
> 
> +#define CPU_FTR_HAS_DABR (defined(CONFIG_PPC64) && \
> +			  !defined(CONFIG_PPC_ADV_DEBUG_REGS))
> +#ifdef CPU_FTR_HAS_DABR
> +/* Number of physical HW breakpoint registers */
> +#define HBP_NUM 1
> +#endif
> +
>  #endif /* !__ASSEMBLY__ */
> 
>  #endif /* __KERNEL__ */

These new defines don't really correlate to the cpu table.  One would
expect cpu_has_feature(CPU_FTR_HAS_DABR) to have meaning, but it would
have to be defined similar to the other CPU_FTR_ constants, and or-ed
with CPU_FTRS_ALWAYS (when appropriate).

Similarly, I would expect the cpu_spec structure to have a new field,
hbp_num, which is initialized in cputable.c.  Maybe a longer name would
be better, num_hw_brkpts?

When I added the PPC_ADV_DEBUG config options for the bookE features, I
didn't see an immediate need to clutter the cputable since their values
are fixed at compile time.  We should be consistent with these, but
unless we are going to determine any of these at run-time, I don't know
that they belong in the cpu table.

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center



More information about the Linuxppc-dev mailing list