1. 25 Aug, 2004 8 commits
    • Tony Lindgren's avatar
      [ARM PATCH] 2040/1: Increase ARM HARDIRQ_BITS to 9, version 2 · 89041f1b
      Tony Lindgren authored
      Patch from Tony Lindgren
      
      This is an updated version of patch 2004/1 to optimize for immediate constant
      89041f1b
    • Lennert Buytenhek's avatar
      [ARM PATCH] 2047/1: disable NWFPE_XP on big endian · 933d1ff5
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      Hi,
      
      gcc doesn't understand 80-bit floating point on the ARM currently,
      according to the kernel's Kconfig docs, but it would seem that the
      current extended double emulation code is broken for big endian
      platforms.
      
      So, this patch disables NWFPE_XP on big endian architectures, until
      someone comes round and fixes it.
      
      
      cheers,
      Lennert
      933d1ff5
    • Lennert Buytenhek's avatar
      [ARM PATCH] 2046/1: fix nwfpe for double arithmetic on big-endian platforms · 6349ff20
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      Hi,
      
      I need the patch below (against 2.6.8-rc1-ds1) to make nwfpe properly
      emulate arithmetic with doubles on a big endian ARM platform.
      
      From reading the mailing list archives and from helpful comments I've
      received from people on this list, I gather that this has come up in
      the past, but it appears that Russell King was never really convinced
      as to why this patch is needed.  I think I understand what's going on,
      and will try to explain.
      
      On little endian ARM, the double value 1.0 looks like this when stored
      in memory in FPA word ordering:
      bytes: 0x00 0x00 0xf0 0x3f 0x00 0x00 0x00 0x00
      u32s:  0x3ff00000 0x00000000
      u64:   0x000000003ff00000
      
      On big endian, it looks like this:
      bytes: 0x3f 0xf0 0x00 0x00 0x00 0x00 0x00 0x00
      u32s:  0x3ff00000 0x00000000
      u64:   0x3ff0000000000000
      
      It appears to be this way because once upon a time, somebody decided
      that the sub-words of a double will use native endian word ordering
      within themselves, but the two separate words will always be stored
      with the most significant one first.  God knows why they did it this
      way, but they did.
      
      Anyway.  The key observation is that nwfpe internally stores double
      values in the type 'float64', which is basically just a typedef for
      unsigned long long.  It never accesses 'float64's on the byte level
      by casting pointers around or anything like that, it just uses direct
      u64 arithmetic primitives (add, shift, or, and) for float64
      manipulations and that's it.
      
      So.  For little endian platforms, 1.0 looks like:
      0x00 0x00 0xf0 0x3f 0x00 0x00 0x00 0x00
      But since nwfpe treats it as a u64, it wants it to look like:
      0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x3f
      So, that's why the current code swaps the words around when getting
      doubles from userspace and putting them back (see fpa11_cpdt.c,
      loadDouble and storeDouble.)
      
      On big endian, 1.0 looks like:
      0x3f 0xf0 0x00 0x00 0x00 0x00 0x00 0x00
      Since nwfpe treats it as a u64, it wants it to look like:
      0x3f 0xf0 0x00 0x00 0x00 0x00 0x00 0x00
      Hey!  That's exactly the same.  So in this case, it shouldn't be
      swapping the halves around.  However, it currently does that swapping
      unconditionally, and that's why floating point emulation messes up.
      
      This is how I understand things -- hope it makes sense to other people
      too.
      
      
      cheers,
      Lennert
      6349ff20
    • Ben Dooks's avatar
      [ARM PATCH] 2044/1: S3C2410 - missing IRQ_TICK from RTC resources · f43750ec
      Ben Dooks authored
      Patch from Ben Dooks
      
      Fixes missing IRQ_TICK from RTC resources
      f43750ec
    • Ben Dooks's avatar
      [ARM PATCH] 2043/1: S3C2410 update to registered devices · a2132900
      Ben Dooks authored
      Patch from Ben Dooks
      
      Updated all arch/arm/mach-s3c2410/mach-XXX.c files to
      register default set of devices
      
      Added new board struct to keep this sort of info, as it
      isn't possible to register platform_devices until after
      the init_io functions have been called.
      a2132900
    • Ben Dooks's avatar
      [ARM PATCH] 2042/1: S3C2410 - Clock fixes, added watchdog clock · 3ecf83f8
      Ben Dooks authored
      Patch from Ben Dooks
      
      Added clock definition for watchdog, and fixed it so
      that clocks that cannot be enabled/disabled will be
      left alone.
      
      Fixed typo in naming of clocks when registering
      3ecf83f8
    • Russell King's avatar
    • Russell King's avatar
      46e13d2a
  2. 24 Aug, 2004 24 commits
  3. 25 Aug, 2004 2 commits
  4. 24 Aug, 2004 6 commits