From: Dave Airlie <airlied@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: airlied@linux.ie, tglx@linutronix.de, hpa@zytor.com,
linux-kernel@vger.kernel.org, konrad@kernel.org,
Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [RFC PATCH] Utilize the PCI API in the AGP framework.
Date: Tue, 07 Dec 2010 10:02:06 +1000 [thread overview]
Message-ID: <1291680126.8232.5.camel@clockmaker-el6> (raw)
In-Reply-To: <1291677875-30493-1-git-send-email-konrad.wilk@oracle.com>
On Mon, 2010-12-06 at 18:24 -0500, Konrad Rzeszutek Wilk wrote:
> Attached is a set of RFC patches that make it possible for AGP graphic drivers to
> work under Xen. The major problem that Linux kernel has when running under Xen
> is that the usage of "virt_to_phys(x) >> PAGE_SIZE" to get the DMA address is not
> applicable. That is due to the fact that the PFN value is not the real Machine
> Frame Number (MFN), hence virt_to_phys(x) >> PAGE_SIZE ends up pointing to a
> random physical address. But if you use the PCI API, then the DMA (bus) address
> returned is a valid MFN.
Can I ask you to go back a step and address what the use case for all of
this is, the patch description doesn't address why anyone cares about
AGP in 2010, esp with Xen. Virtualising hw drivers for the sake of it
is all well and good, but since most of these drivers are for really
legacy systems I can't imagine we are going to see a lot of regression
testing before they hit distros like Debian two years from now, though
maybe Gentoo might pick up some, (is anyone even running IA64?).
I can maybe imagine the Intel GTT being cared about but we've already
addressed the issues in it from what I can see.
Also the X server use case is still possibly valid for a lot of the
systems here, its userspace ABI so it can't just end up broken. The move
to TTM/DRM being the main user didn't suddenly remove the use of the X
server case on older systems which don't have a TTM/DRM layer.
Other than that the idea seems sane, I just hate having to upgrade large
parts of the subsystem without some reasonable justification that
someone out there is going to use it. If it allows some major cleanup
else where that would also be a possibly good justification.
Dave.
next prev parent reply other threads:[~2010-12-07 0:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 23:24 [RFC PATCH] Utilize the PCI API in the AGP framework Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 01/23] agp: Add bridge argument to [free|alloc]_gatt_pages macro Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 02/23] agp: Add dma_addr array in struct agp_memory Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 03/23] agp: Introduce two new macros: _agp_[alloc|free]_page Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 04/23] agp: Make agp_generic_[alloc|destroy]_pages use the _agp_[alloc|free]_page macro Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 05/23] agp: Make agp_generic_[alloc|destroy]_page use " Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 06/23] agp/ali: Use the dma_addr instead of page_to_phys for m1541_[alloc|destroy]_page Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 07/23] agp/nvidia: Use the dma_addr[] instead of page_to_phys when inserting Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 08/23] agp/amd64: Use the dma_addr[] and gatt_bus_addr instead of [page|virt]_to_phys respectivly Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 09/23] agp/amd-k7: Utilize the PCI API for creating/inserting pages Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 10/23] ati/agp: " Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 11/23] agp/serverworks: Utilize the PCI API for allocating/inserting pages Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 12/23] agp/intel-gtt: Utilize the PCI DMA for i8xxx, Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 13/23] ia64/agp/zx1: Use PCI API for inserting pages in HP's ZX1 AGP device Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 14/23] ia64/agp/i460: Use PCI API for inserting pages in DIG (non-VT-d) platforms Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 15/23] agp: Make agp_generic_insert_memory use the mem->dma_addr[i] Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 16/23] agp: save the size of GATT table Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 17/23] agp: Make agp_generic_[create|free]_gatt_table be aware of PCI API Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 18/23] agp/x86: Make agp_generic_* use " Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 19/23] ia64/sgi: fix compile error Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 20/23] ia64: Add DMA_ERROR_CODE define Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 21/23] agp/sgi: Use PCI API for inserting/creating pages on SGI Altix Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 22/23] ia64/agp: Make agp_generic_* use PCI API Konrad Rzeszutek Wilk
2010-12-06 23:24 ` [PATCH 23/23] agp/generic: Set the dma_addr[i] to DMA_ERROR_CODE Konrad Rzeszutek Wilk
2010-12-07 0:02 ` Dave Airlie [this message]
2010-12-07 0:48 ` [RFC PATCH] Utilize the PCI API in the AGP framework Konrad Rzeszutek Wilk
2010-12-07 1:16 ` Dave Airlie
2010-12-07 2:12 ` Konrad Rzeszutek Wilk
2010-12-08 16:45 ` Konrad Rzeszutek Wilk
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=1291680126.8232.5.camel@clockmaker-el6 \
--to=airlied@redhat.com \
--cc=airlied@linux.ie \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=konrad@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox