On Tue, Jan 18, 2011 at 04:44:52PM +0200, Kirill A. Shutemov wrote: > On Tue, Jan 18, 2011 at 02:40:14PM +0000, Russell King - ARM Linux wrote: > > On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote: > > > On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote: > > > > This patch series reworks the ARMv6/ARMv6K support options, code > > > > selection, and bit operations such that it's possible to safely > > > > build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP > > > > in one image. > > > > > > Is it posible to implement CPU_ARCH_ARMv6K as well for runtime checks? > > > > Err what? There's no CPU_ARCH_ARMv6K. > > I some cases we need runtime check for K extention (see exceptions_init()) > Is there any facility for it? >From what I can tell there's no hard and fast way to say at runtime "this CPU has K extensions" as it appears possible from the ARM ARM to have a CPU which is ARMv6K (eg, the CPU in Dove) which does not support SMP. Whether that identifies itself as ARMv6 in the architecture field of the main ID register, or uses the new CPUID scheme is not clear. If it identifies itself as ARMv6, then there's no CPUID registers to detect what it supports. If it's the new CPUID scheme, while we can tell that a CPU has CLREX support, that doesn't necessary mean that it has the access fault stuff. That just means that a greater range of exclusive operations are supported. Also: | An implementation that provides hardware management of the access flag: | â does not generate Access Flag faults when the access flag is enabled | ... So, if we don't enable the access flag support, then we shouldn't see them (we don't enable them.) What's more: | Memory Model Feature Register 2 (ID_MMFR2) | HW access flag, bits [31:28] | Indicates support for a Hardware access flag, as part of the VMSAv7 implementation. | Permitted values are: | 0b0000 Not supported. | 0b0001 Support for VMSAv7 access flag, updated in hardware. That doesn't suggest that it's valid to assume that this will be '1' on ARMv6K - and istr there's some subtle differences between the various CPUID registers for different architectures as well - to make the CPUID scheme just that little more complicated to use, so these bits may not even be defined that way for ARMv6K. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html