Eric Lee / smarc-fsl-linux-kernel

27 Oct, 2010

1 commit

  • 658716d19   div64_u64(): improve precision on 32bit platforms ... Browse Code »

    The current implementation of div64_u64 for 32bit systems returns an
    approximately correct result when the divisor exceeds 32bits. Since doing
    64bit division using 32bit hardware is a long since solved problem we just
    use one of the existing proven methods.

    Additionally, add a div64_s64 function to correctly handle doing signed
    64bit division.

    Addresses https://bugzilla.redhat.com/show_bug.cgi?id=616105

    Signed-off-by: Brian Behlendorf
    Signed-off-by: Oleg Nesterov
    Cc: Ben Woodard
    Cc: Jeremy Fitzhardinge
    Cc: Mark Grondona
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brian Behlendorf
     

12 Jun, 2008

2 commits

  • d5e181f78   add an inlined version of iter_div_u64_rem ... Browse Code »

    iter_div_u64_rem is used in the x86-64 vdso, which cannot call other
    kernel code. For this case, provide the always_inlined version,
    __iter_div_u64_rem.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Ingo Molnar

    Jeremy Fitzhardinge
     
  • f595ec964   common implementation of iterative div/mod ... Browse Code »

    We have a few instances of the open-coded iterative div/mod loop, used
    when we don't expcet the dividend to be much bigger than the divisor.
    Unfortunately modern gcc's have the tendency to strength "reduce" this
    into a full mod operation, which isn't necessarily any faster, and
    even if it were, doesn't exist if gcc implements it in libgcc.

    The workaround is to put a dummy asm statement in the loop to prevent
    gcc from performing the transformation.

    This patch creates a single implementation of this loop, and uses it
    to replace the open-coded versions I know about.

    Signed-off-by: Jeremy Fitzhardinge
    Cc: Andrew Morton
    Cc: john stultz
    Cc: Segher Boessenkool
    Cc: Christian Kujau
    Cc: Robert Hancock
    Signed-off-by: Ingo Molnar

    Jeremy Fitzhardinge
     

01 May, 2008

2 commits

  • 6f6d6a1a6   rename div64_64 to div64_u64 ... Browse Code »

    Rename div64_64 to div64_u64 to make it consistent with the other divide
    functions, so it clearly includes the type of the divide. Move its definition
    to math64.h as currently no architecture overrides the generic implementation.
    They can still override it of course, but the duplicated declarations are
    avoided.

    Signed-off-by: Roman Zippel
    Cc: Avi Kivity
    Cc: Russell King
    Cc: Geert Uytterhoeven
    Cc: Ralf Baechle
    Cc: David Howells
    Cc: Jeff Dike
    Cc: Ingo Molnar
    Cc: "David S. Miller"
    Cc: Patrick McHardy
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     
  • 2418f4f28   introduce explicit signed/unsigned 64bit divide ... Browse Code »

    The current do_div doesn't explicitly say that it's unsigned and the signed
    counterpart is missing, which is e.g. needed when dealing with time values.

    This introduces 64bit signed/unsigned divide functions which also attempts to
    cleanup the somewhat awkward calling API, which often requires the use of
    temporary variables for the dividend. To avoid the need for temporary
    variables everywhere for the remainder, each divide variant also provides a
    version which doesn't return the remainder.

    Each architecture can now provide optimized versions of these function,
    otherwise generic fallback implementations will be used.

    As an example I provided an alternative for the current x86 divide, which
    avoids the asm casts and using an union allows gcc to generate better code.
    It also avoids the upper divde in a few more cases, where the result is known
    (i.e. upper quotient is zero).

    Signed-off-by: Roman Zippel
    Cc: john stultz
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     

26 Apr, 2007

3 commits

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds