lkml.org 
[lkml]   [2008]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectio resources and cached mappings (was: [git pull] drm patches for 2.6.27-rc1)

    * Keith Packard <keithp@keithp.com> wrote:

    > On Sat, 2008-10-18 at 21:14 -0700, Keith Packard wrote:
    > > On Sun, 2008-10-19 at 00:32 +0200, Ingo Molnar wrote:
    > >
    > > > Mind sending patches for this? :-)
    >
    > Here's a patch for the i915 driver that includes the new API. Tested
    > on x86_32+HIGHMEM and x86_64. I stuck a new 'io_reserve.h' header in
    > the i915 directory for this patch, but it should go elsewhere.
    >
    > The new APIs are:
    >
    > io_reserve_create_wc
    > io_reserve_free
    > io_reserve_map_atomic_wc
    > io_reserve_unmap_atomic
    > io_reserve_map_wc
    > io_reserve_unmap

    very nice!

    I think we need a somewhat different abstraction though.

    Firstly, regarding drivers/gpu/drm/i915/io_reserve.h, that needs to move
    to generic code.

    Secondly, wouldnt the right abstraction be to attach this functionality
    to 'struct resource' ? [or at least create a second struct that embedds
    struct resource]

    this abstraction is definitely not a PCI thing and not a
    detached-from-everything thing, it's an IO resource thing. We could make
    it a property of struct resource:

    struct resource {
    resource_size_t start;
    resource_size_t end;
    const char *name;
    unsigned long flags;
    struct resource *parent, *sibling, *child;
    + void *mapping;
    };

    The APIs would be:

    int io_resource_init_mapping(struct resource *res);
    void io_resource_free_mapping(struct resource *res);
    void * io_resource_map(struct resource *res, pfn_t pfn, unsigned long offset);
    void io_resource_unmap(struct resource *res, void *kaddr);

    Note how simple and consistent it all gets: IO resources already know
    their physical location and their size limits. Being able to cache an
    ioremap in a mapping [and being able to use atomic kmaps on 32-bit] is a
    relatively simple and natural extension to the concept.

    i think that would be quite acceptable - and the APIs could just
    transparently work on it. This would also allow the PCI code to
    automatically unmap any cached mappings from resources, when the driver
    deinitializes.

    Linus, Jesse, what do you think?

    i think we need to finalize the API names and their abstraction level,
    and then could even merge those APIs into v2.6.28 on a fast path, to
    enable you to use it. It does not interact with anything else so it
    should be safe to do.

    (i'd not suggest to merge the i915 bits just yet - but that's obviously
    not my call.)

    Ingo


    \
     
     \ /
      Last update: 2008-10-19 19:57    [W:3.500 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site