From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: "Aguirre, Sergio" <saaguirre@ti.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"Warren, Christina" <cawarren@ti.com>,
"Boateng, Akwasi" <akwasi.boateng@ti.com>,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: [Query][videobuf-dma-sg] Pages in Highmem handling
Date: Mon, 20 Dec 2010 09:23:23 -0200 [thread overview]
Message-ID: <4D0F3CAB.5090501@redhat.com> (raw)
In-Reply-To: <A24693684029E5489D1D202277BE8944719829DB@dlee02.ent.ti.com>
Hi Sergio,
Em 27-08-2010 11:57, Aguirre, Sergio escreveu:
> Hi,
>
> I see that in current videobuf library, for DMA SG code, these functions fail when
> Detecting a page in Highmem region:
>
> - videobuf_pages_to_sg
> - videobuf_vmalloc_to_sg
>
> Now, what's the real reason to not allow handling of Highmem pages?
> Is it an assumption that _always_ HighMem is not reachable by DMA?
>
> I guess my point is, OMAP platform (and maybe other platforms) can handle
> Highmem pages without any problem. I commented these validations:
>
> 65 static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char *virt,
> 66 int nr_pages)
> 67 {
>
> ...
>
> 77 for (i = 0; i < nr_pages; i++, virt += PAGE_SIZE) {
> 78 pg = vmalloc_to_page(virt);
> 79 if (NULL == pg)
> 80 goto err;
> 81 /* BUG_ON(PageHighMem(pg)); */
>
> ...
>
> 96 static struct scatterlist *videobuf_pages_to_sg(struct page **pages,
> 97 int nr_pages, int offset)
> 98 {
>
> ...
>
> 109 /* if (PageHighMem(pages[0])) */
> 110 /* DMA to highmem pages might not work */
> 111 /* goto highmem; */
> 112 sg_set_page(&sglist[0], pages[0], PAGE_SIZE - offset, offset);
> 113 for (i = 1; i < nr_pages; i++) {
> 114 if (NULL == pages[i])
> 115 goto nopage;
> 116 /* if (PageHighMem(pages[i]))
> 117 goto highmem; */
> 118 sg_set_page(&sglist[i], pages[i], PAGE_SIZE, 0);
> 119 }
>
> Can somebody shed any light on this?
Sorry for taking so long to answer you.
Basically, videobuf code were written at Linux 2.4 days, to be used by
bttv driver (and later used by cx88 and saa7134). At that time, there where
a hack for the usage of highmem (I think it was called bigmem or something
like that).
As I was not maintaining the code on that time, I'm not really sure what where
the issues, but I suspect that this were an arch-implementation limit
related to DMA transfers at highmem, on that time, due to x86 intrinsic
limits. I'm not sure about the current limits of newer x86 chips, on 32
and on 64 bits mode, but i think that this limit doesn't exist anymore.
So, I suspect that just converting it to a call to dma_capable() should
be enough to fix the issue.
Yet, as videobuf2 is almost ready for merge, maybe the best is to take
some efforts on testing it, and to be sure that it doesn't contain any
arch-specific limits inside its code.
Cheers,
Mauro
next prev parent reply other threads:[~2010-12-20 11:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-27 14:57 [Query][videobuf-dma-sg] Pages in Highmem handling Aguirre, Sergio
2010-12-20 11:23 ` Mauro Carvalho Chehab [this message]
2011-01-07 14:21 ` Aguirre, Sergio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D0F3CAB.5090501@redhat.com \
--to=mchehab@redhat.com \
--cc=akwasi.boateng@ti.com \
--cc=cawarren@ti.com \
--cc=linux-media@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=saaguirre@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.