Eric Lee / smarc-ti-linux-kernel

02 Mar, 2007

1 commit

12 Feb, 2007

1 commit

  • 72fd4a35a   [PATCH] Numerous fixes to kernel-doc info in source files. ... Browse Code »

    A variety of (mostly) innocuous fixes to the embedded kernel-doc content in
    source files, including:

    * make multi-line initial descriptions single line
    * denote some function names, constants and structs as such
    * change erroneous opening '/*' to '/**' in a few places
    * reword some text for clarity

    Signed-off-by: Robert P. J. Day
    Cc: "Randy.Dunlap"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robert P. J. Day
     

12 Oct, 2006

1 commit

  • 01a3ee2b2   [PATCH] bitmap: parse input from kernel and user buffers ... Browse Code »

    lib/bitmap.c:bitmap_parse() is a library function that received as input a
    user buffer. This seemed to have originated from the way the write_proc
    function of the /proc filesystem operates.

    This has been reworked to not use kmalloc and eliminates a lot of
    get_user() overhead by performing one access_ok before using __get_user().

    We need to test if we are in kernel or user space (is_user) and access the
    buffer differently. We cannot use __get_user() to access kernel addresses
    in all cases, for example in architectures with separate address space for
    kernel and user.

    This function will be useful for other uses as well; for example, taking
    input for /sysfs instead of /proc, so it was changed to accept kernel
    buffers. We have this use for the Linux UWB project, as part as the
    upcoming bandwidth allocator code.

    Only a few routines used this function and they were changed too.

    Signed-off-by: Reinette Chatre
    Signed-off-by: Inaky Perez-Gonzalez
    Cc: Paul Jackson
    Cc: Joe Korty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Reinette Chatre
     

26 Jun, 2006

1 commit

27 Mar, 2006

1 commit

  • 37d54111c   [PATCH] bitops: hweight() related cleanup ... Browse Code »

    By defining generic hweight*() routines

    - hweight64() will be defined on all architectures
    - hweight_long() will use architecture optimized hweight32() or hweight64()

    I found two possible cleanups by these reasons.

    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

24 Mar, 2006

3 commits

  • 3cf64b933   [PATCH] bitmap: region restructuring ... Browse Code »

    Restructure the bitmap_*_region() operations, to avoid code duplication.

    Also reduces binary text size by about 100 bytes (ia64 arch). The original
    Bottomley bitmap_*_region patch added about 1000 bytes of compiled kernel text
    (ia64). The Mundt multiword extension added another 600 bytes, and this
    restructuring patch gets back about 100 bytes.

    But the real motivation was the reduced amount of duplicated code.

    Tested by Paul Mundt using
    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     
  • 74373c6ac   [PATCH] bitmap: region multiword spanning support ... Browse Code »

    Add support to the lib/bitmap.c bitmap_*_region() routines

    For bitmap regions larger than one word (nbits > BITS_PER_LONG). This removes
    a BUG_ON() in lib bitmap.

    I have an updated store queue API for SH that is currently using this with
    relative success, and at first glance, it seems like this could be useful for
    x86 (arch/i386/kernel/pci-dma.c) as well. Particularly for anything using
    dma_declare_coherent_memory() on large areas and that attempts to allocate
    large buffers from that space.

    Paul Jackson also did some cleanup to this patch.

    Signed-off-by: Paul Mundt
    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mundt
     
  • 87e248025   [PATCH] bitmap: region cleanup ... Browse Code »

    Paul Mundt says:

    This patch set implements a number of patches to clean up and restructure the
    bitmap region code, in addition to extending the interface to support
    multiword spanning allocations.

    The current implementation (before this patch set) is limited by only being
    able to allocate pages BITS_PER_LONG);

    As I seem to have been the first person to trigger this, the result ends up
    being the following patch set with the help of Paul Jackson.

    The final patch in the series eliminates quite a bit of code duplication, so
    the bitmap code size ends up being smaller than the current implementation as
    an added bonus.

    After these are applied, it should already be possible to do multiword
    allocations with dma_alloc_coherent() out of ranges established by
    dma_declare_coherent_memory() on x86 without having to change any of the code,
    and the SH store queue API will follow up on this as the other user that needs
    support for this.

    This patch:

    Some code cleanup on the lib/bitmap.c bitmap_*_region() routines:

    * spacing
    * variable names
    * comments

    Has no change to code function.

    Signed-off-by: Paul Mundt
    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

09 Jan, 2006

1 commit

  • 96b7f3414   [PATCH] cpuset: better bitmap remap defaults ... Browse Code »

    Fix the default behaviour for the remap operators in bitmap, cpumask and
    nodemask.

    As previously submitted, the pair of masks defined a map of the
    positions of the set bits in A to the corresponding bits in B. This is still
    true.

    The issue is how to map the other positions, corresponding to the unset (0)
    bits in A. As previously submitted, they were all mapped to the first set bit
    position in B, a constant map.

    When I tried to code per-vma mempolicy rebinding using these remap operators,
    I realized this was wrong.

    This patch changes the default to map all the unset bit positions in A to the
    same positions in B, the identity map.

    For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
    defined by the pair maps each bit position in the first 32 bits as
    follows:

    0 ==> 0
    ...
    3 ==> 3
    4 ==> 9
    ...
    7 ==> 12
    8 ==> 8
    9 ==> 9
    ...
    31 ==> 31

    This now corresponds to the typical behaviour desired when migrating pages and
    policies from one cpuset to another.

    The pages on nodes within the original cpuset, and the references in memory
    policies to nodes within the original cpuset, are migrated to the
    corresponding cpuset-relative nodes in the destination cpuset. Other pages
    and node references are left untouched.

    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

31 Oct, 2005

1 commit

  • fb5eeeee4   [PATCH] cpusets: bitmap and mask remap operators ... Browse Code »

    In the forthcoming task migration support, a key calculation will be
    mapping cpu and node numbers from the old set to the new set while
    preserving cpuset-relative offset.

    For example, if a task and its pages on nodes 8-11 are being migrated to
    nodes 24-27, then pages on node 9 (the 2nd node in the old set) should be
    moved to node 25 (the 2nd node in the new set.)

    As with other bitmap operations, the proper way to code this is to provide
    the underlying calculation in lib/bitmap.c, and then to provide the usual
    cpumask and nodemask wrappers.

    This patch provides that. These operations are termed 'remap' operations.
    Both remapping a single bit and a set of bits is supported.

    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

26 Jun, 2005

1 commit

17 Apr, 2005

1 commit

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

    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