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 <pra...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev