Re: [PATCH] deinline sleep/delay functions

From: Denis Vlasenko (vda_at_ilport.com.ua)
Date: 06/30/05

  • Next message: Wang Jian: "Re: 2.6.12.1 problems I meet (please CC: me)"
    To: Arjan van de Ven <arjan@infradead.org>, Andrew Morton <akpm@osdl.org>
    Date:	Thu, 30 Jun 2005 13:21:20 +0300
    
    

    On Thursday 30 June 2005 12:19, Arjan van de Ven wrote:
    >
    > > > There are a number of compile-time checks that your patch has removed
    > > > which catch such things, and as such your patch is not acceptable.
    > > > Some architectures have a lower threshold of acceptability for the
    > > > maximum udelay value, so it's absolutely necessary to keep this.
    > >
    > > It removes that check from x86 - other architectures retain it.
    > >
    > > I don't recall seeing anyone trigger the check,
    >
    > I do ;) Esp in vendor out of tree crap. It's a good compile time
    > diagnostic so the junk code doesnt' hit mainline but gets fixed first.

    It seems my patch was incomplete.

    Thinking more about it, since it exists in all arches
    and also since delaying is not performance critical
    (hey, if we're going to delay/sleep, we surely can burn
    a few more cycles), this can be done as follows:

    linux/timer.c:

    void ndelay(unsigned int nsecs)
    {
            unsigned int m = nsecs/(1024*1024);
                   while (m--)
                    __ndelay(1024);
            __ndelay(nsecs % (1024*1024));
    }

    void udelay(unsigned int usecs)
    {
            unsigned int k = usecs/1024;
                   while (k--)
                    __udelay(1024);
            __udelay(usecs % 1024);
    }

    void mdelay(unsigned int msecs)
    {
                   while (msecs--)
                    udelay(1000);
    }

    void ssleep(unsigned int secs)
    {
            msleep(secs * 1000);
    }

    and arches will need to only supply two functions:

    __udelay(n) [n is guaranteed <1024]
    __ndelay(n) [n is guaranteed <1024*1024]

    For users, _any_ value, however large, will work for
    any delay function.

    Comments?

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

  • Next message: Wang Jian: "Re: 2.6.12.1 problems I meet (please CC: me)"

    Relevant Pages

    • Help in Java swings(internal Frame)
      ... public int getSize() ... public void valueChanged{ ... private JScrollPane scrollPane1; ... public class PeakContainer extends JInternalFrame ...
      (comp.lang.java.programmer)
    • [PATCH,RFC 2.6.14 09/15] KGDB: SuperH-specific changes
      ... This adds basic support for KGDB on SuperH as well as adding some architecture ... -static int kgdb_uart_getchar ... -static void kgdb_uart_putchar ... * The command-line option can include a serial port specification ...
      (Linux-Kernel)
    • problem in java swings
      ... public int getSize() ... public void valueChanged{ ... private JScrollPane scrollPane1; ... public class PeakContainer extends JInternalFrame ...
      (comp.lang.java.programmer)
    • ToolTips in a View and TTN_NEEDTEXT
      ... extern int g_minWorkPeriod; ... void CDayView::CreateAllFonts ... void CDayView::DrawDayLog(CDC* pDC) ... BOOL CDayView::TimeToY ...
      (microsoft.public.vc.mfc)
    • [PATCH 6/20] FRV: Fujitsu FR-V CPU arch implementation part 4
      ... +static void register_irq_proc (unsigned int irq); ...
      (Linux-Kernel)