Re: [Linux-fbdev-devel] [PATCH] video: arch specific page protection support for deferred io

[Magnus D. <mag...@gm...>]

On Thu, Jun 25, 2009 at 4:03 PM, Andrew Morton<ak...@li...> wrote:
> On Thu, 25 Jun 2009 15:06:24 +0900 Magnus Damm <mag...@gm...> wrote:
>
>> On Thu, Jun 25, 2009 at 11:56 AM, Andrew
>> Morton<ak...@li...> wrote:
>> > On Wed, 24 Jun 2009 19:54:13 +0900 Magnus Damm <mag...@gm...> wrote:
>> >
>> >> From: Magnus Damm <da...@ig...>
>> >>
>> >> This patch adds arch specific page protection support to deferred io.
>> >>
>> >> Instead of overwriting the info->fbops->mmap pointer with the
>> >> deferred io specific mmap callback, modify fb_mmap() to include
>> >> a #ifdef wrapped call to fb_deferred_io_mmap(). __The function
>> >> fb_deferred_io_mmap() is extended to call fb_pgprotect() in the
>> >> case of non-vmalloc() frame buffers.
>> >>
>> >> With this patch uncached deferred io can be used together with
>> >> the sh_mobile_lcdcfb driver. Without this patch arch specific
>> >> page protection code in fb_pgprotect() never gets invoked with
>> >> deferred io.
>> >>
>> >> Signed-off-by: Magnus Damm <da...@ig...>
>> >> ---
>> >>
>> >> __For proper runtime operation with uncached vmas make sure
>> >> __"[PATCH][RFC] mm: uncached vma support with writenotify"
>> >> __is applied. There are no merge order dependencies.
>> >
>> > So this is dependent upon a patch which is in your tree, which is in
>> > linux-next?
>>
>> I tried to say that there were _no_ dependencies merge wise. =)
>>
>> There are 3 levels of dependencies:
>> 1: pgprot_noncached() patches from Arnd
>> 2: mm: uncached vma support with writenotify
>> 3: video: arch specfic page protection support for deferred io
>>
>> 2 depends on 1 to compile, but 3 (this one) is disconnected from 2 and
>> 1. So this patch can be merged independently.
>
> OIC.  I didn't like the idea of improper runtime operation ;)
>
> Still, it's messy.  If only because various trees might be running
> untested combinations of patches.  Can we get these all into the same
> tree?  Paul's?

There may also be some dependencies related to other patches posted to
linux-fbdev-devel, for instance:
[PATCH] add mutex to fbdev for fb_mmap locking (v2)
The fb_mmap() locking will conflict with this patch.

So it may make sense to group the fbdev patches together.

>>
>> The code is fbmem.c is currently filled with #ifdefs today, want me
>> create inline versions for fb_deferred_io_open() and
>> fb_deferred_io_fsync() as well?
>
> It was a minor point.  Your call.

I'd prefer to submit a patch on top of this one if possible.

Cheers,

/ magnus