[lkml]   [2006]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/14] Generic ioremap_page_range: introduction
    Hi Andrew,

    If this is acked by the relevant people, could you give it a spin
    in -mm?

    This is a resend of the generic ioremap_page_range() patchset with
    one minor change noted below. As Andi Kleen pointed out, I should
    send the patches directly to the arch maintainers, so I'm Cc'ing them
    this time around. Hopefully at least -- I'm not 100% confident with
    git-send-email yet, but I'm getting there :)

    Some patches have already been acked, but I'm cc'ing the maintainer

    I've reverted the "implementation" patch to use the same
    flush_cache_all()/flush_tlb_all() scheme used by i386 and most other
    architectures and added a second patch that converts them to
    flush_cache_vmap(). This way, if things fall apart during testing,
    there's only a single patch to revert.

    In addition to the generic ioremap_page_range() implementation, this
    updates all architectures that were relatively trivial to convert.
    Most of remaining architectures implement ioremap() as a no-op or
    something close. Exceptions are m68k, powerpc and sparc.

    m68k has some CPU-dependent logic in the middle of the loop.

    powerpc could probably use generic ioremap_page_range(), but doing so
    would probably increase the code size, as the map_page() functions
    have other users in addition to ioremap().

    sparc maps in huge pages when possible. Better not touch it.

    Oh, and I'm going to Taiwan next week, so I may be slow to respond.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-10 18:07    [W:0.018 / U:3.656 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site