Re: device driver for the SGI system clock, mmtimer

[Robert Picco <Robert.Picco@hp.com>]

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@vger.kernel.org
>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