lkml.org 
[lkml]   [2007]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [linux-pm] [3/6] 2.6.21-rc4: known regressions
    Date
    On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
    > On Friday 30 March 2007 00:33:35 David Brownell wrote:
    > > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:

    > > > So the only way out is to emulate RTC using HPET,
    > > > It is done this way in old rtc driver, rtc-cmos should do the same.
    > >
    > > No. Patches like
    > >
    > > http://marc.info/?l=linux-kernel&m=117219531503973&w=2

    also: http://marc.info/?l=linux-kernel&m=117219531526317&w=2

    > > should be merged (I hope they're in the 2.6.22 queue!), making
    > > HPET run in "Standard Mode" so that HPET can stop sticking its
    > > fingers in code where they don't belong.
    > >
    > > ...
    >
    > It is not that simple,
    >
    > Only in legacy replacement mode HPET can be put on IRQ0 (and sadly IRQ8)
    > At least this is true on some systems, on mine for example

    Right, that's the entire point of legacy replacement mode.

    But so what? In standard mode, HPET just uses other IRQs.
    Nothing would care about irq0, and irq8 would be used by
    the RTC as necessary.


    > this will make it difficult to use it as a clockevents source

    Why? It's not like the clockevent logic cares what IRQ a given
    programmable timer uses. So long as the HPET driver can receive
    its IRQ, it'll make a fine clockevent. There's no reason to have
    HPET prevent other drivers from working, by insisting it use that
    nasty "prevent other hardware from issuing IRQs" mode.

    The patches from Venkatesh sure seem to have behaved for him.
    And while he might have complained about difficulty, I think
    that'd be more likely due to the SMP issues he also addressed
    than because of some (historical?) attachment to irq0.


    > Not to mention the fact that current code assumes that BIOS
    > assigned IRQs to all timers which is not true on my system.

    Getting IRQ routing sorted out is a problem that's been solved
    numerous times before. And again, the patches referenced above
    seem to have resolved any such issues.


    > What is wrong with relying on HPET to provide RTC IRQ ?

    For starters, it's not an RTC. Why in the world would you want to
    make the OS think it's an RTC ... unless you're Microsoft, and are
    desperate to get another periodic timer (and don't much care about
    the other RTC functionality?


    ... that's all off-topic for 2.6.21 regressions though; it's too
    late to merge x86_64 clockevent support, or fix HPET issues like
    not using "standard mode".

    - Dave

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

    \
     
     \ /
      Last update: 2007-03-30 02:11    [W:0.034 / U:0.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site