lkml.org 
[lkml]   [2006]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: mapping PCI registers with write combining (and PAT on x86)...
    Date
    Roland Dreier <rdreier@cisco.com> writes:

    > Suppose that I would like to map some PIO registers (in a PCI BAR) to
    > userspace, and I would like to enable write combining if possible.
    >
    > I have two problems. First, there's no generic interface for
    > requesting write combining if possible when doing
    > io_remap_pfn_range(). Would it make sense to define
    > pageprot_writecombine for all architectures (and make it fall back to
    > doing non-cached access if write combining is not possible)? And it
    > seems that making pgprot_noncached() universal wouldn't hurt either.

    So I think we may simplify this but there is pci_mmap_page_range. That
    already handles this for the architectures that currently support it.
    So it is probably the case the fbdev should be changed to use that.

    I am certainly in favor of simpler infrastructure like making
    pgprot_writecombine and pgprot_uncached universal but I would like to
    start with what works today.

    Then we can go reexamine things like the ia64 slavishly trusting the
    BIOS to know which page protections are good.

    > Second, given the extreme shortage of MTRRs, it seems that write
    > combining is not really possible in general on x86 without some
    > interface to use PATs instead. What is holding up something like Eric
    > Biederman's patches from going in?

    No one had any serious objections to my patches as they were. The actual
    problem was that the patches were incomplete. In particular if you
    mismatch page protections it is possible to get silent data corruption
    or processor crashes. So we need checks to ensure all mappings of
    a given page are using the same protections.

    To a certain extent I think adding those checks really is a strawman
    and should not stop the merge effort, because we have this feature and
    those possible bugs on other architectures right now and we don't have
    those checks. But I also think in the long term we need them, it just
    requires several days of going through the mm so we don't leave any
    path uncovered.

    > Right now we end up with stuff like the absolutely hair-raising code
    > in drivers/video/fbmem.c shown below. I really would like to make
    > progress towards having a better interface for doing this stuff, and
    > I'm more than willing to work on getting something mergable.

    I hope my comments help.

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

    \
     
     \ /
      Last update: 2006-12-12 23:51    [W:2.244 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site