Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb()

From: Russell King
Date: Fri Nov 07 2008 - 15:12:54 EST


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.

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.)

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.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/