Re: device driver for the SGI system clock, mmtimer

From: Robert Picco
Date: Thu Sep 16 2004 - 20:28:53 EST


Christoph Lameter wrote:

On Thu, 16 Sep 2004, Robert Picco wrote:



Is there something specific that drivers/char/hpet.c expects that
your hardware doesn't implement?


Look at HPET revision history. Specifically 0.98 01/20/2002
* Product name changed: from Multimedia Timer to HPET (High
Precision Event Timer)



The HPET timer has a specific memory layout of registers that is mappable
to user space. The mmtimer driver only allows the mapping of a single 64
bit counter to use space. We have lots of applications at SGI
that rely on mmtimer since mmtimer provides a locally accessible
clock in an NUMA environment with hundreds of CPU. A hpet device would
have to show up in the global address space and require cross node
accesses in our NUMA environment that would make access to the timer
slow. All CPU would content for access to a certain global memory address.

The HPET hardware and the sgi mmtimer are totally different architectures
that are not easily reconcilable.

The software API to handle both is similar and we would like it to be as
compatible as possible.

-
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/



Ah. Well this might be possible. The HP HPET hardware is on each NUMA node. So cross node issues could be addressed. The bit counter isn't an open point for the HPET driver. Only the HPET timers which march against the bit counter can be opened. The current open logic in the driver hunts to find an available timer. To coexist with mmtimer and just enabling the mmaping of the bit counter would require changing the driver API. The other API issues are resolvable with little effort. I think ;-)

Bob
-
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/