* Russell King (rmk+lkml@xxxxxxxxxxxxxxxx) wrote: > On Fri, Nov 07, 2008 at 11:47:58AM -0500, Mathieu Desnoyers wrote: > > But any get_cycles() user of cnt32_to_63() should be shot down. The > > bright side is : there is no way get_cycles() can be used with this > > new code. :) > > > > e.g. of incorrect users for arm (unless they are UP only, but that seems > > like a weird design argument) : > > > > mach-sa1100/include/mach/SA-1100.h:#define OSCR __REG(0x90000010) > > /* OS timer Counter Reg. */ > > mach-sa1100/generic.c: unsigned long long v = cnt32_to_63(OSCR); > > mach-pxa/include/mach/pxa-regs.h:#define OSCR __REG(0x40A00010) /* OS > > Timer Counter Register */ > > mach-pxa/time.c: unsigned long long v = cnt32_to_63(OSCR); > > It's strange for you to make that assertion when PXA was the exact > platform that Nicolas created this code for - and that's a platform > where preempt has been widely used. > > The two you mention are both ARMv5 or older architectures, and the > first real SMP ARM architecture is ARMv6. So architecturally they > are UP only. > Ok. And hopefully they do not execute instructions speculatively ? Because then a instruction sync would be required between the __m_hi_cnt read and get_cycles. If you design such stuff with portability in mind, you'd use per-cpu variables, which ends up being a single variable in the single-cpu special-case. > So, tell me why you say "unless they are UP only, but that seems like > a weird design argument"? If the platforms can only ever be UP only, > what's wrong with UP only code being used with them? (Not that I'm > saying anything there about cnt32_to_63.) That's fine, as long as the code does not end up in include/linux and stays in arch/arm/up-only-subarch/. When one try to create architecture agnostic code (which is what is likely to be palatable to arch agnostic headers), designing with UP in mind does not make much sense. > > I'd like to see you modify the silicon of a PXA or SA11x0 SoC to add > more than one processor to the chip - maybe you could use evostick to > glue two dies together and a microscope to aid bonding wires between > the two? (Of course, you'd need to design something to ensure cache > coherence as well, and arbitrate the internal bus between the two > dies.) ;) > > Personally, I think that's highly unlikely. > Very unlikely indeed. ;) Mathieu > -- > Russell King > Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
