mirror of https://gitee.com/openkylin/linux.git
7 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Joe Perches
|
25d0479a59 |
drm/ttm: Use pr_fmt and pr_<level>
Use the more current logging style. Add pr_fmt and remove the TTM_PFX uses. Coalesce formats and align arguments. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Dave Airlie <airlied@redhat.com> |
|
|
Konrad Rzeszutek Wilk
|
0e11331579 |
ttm/dma: Remove the WARN() which is not useful.
. It was useful during development, but now on a production system we can get this (if the user forgot to upload the firmware): [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: ib pool ready. [drm] Loading SUMO Microcode r600_cp: Failed to load firmware "radeon/SUMO_pfp.bin" atl1c 0000:03:00.0: version 1.0.1.0-NAPI.213057] [drm:evergreen_startup] *ERROR* Failed to load firmware! radeon 0000:00:01.0: disabling GPU acceleration 88] radeon 0000:00:01.0: ffff8801bb782400 unpin not necessary ------------[ cut here ]------------ WARNING: at /home/konrad/linux-linus/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:956 ttm_dma_unpopulate+0x79/0x300 [ttm]() Hardware name: System Product Name Modules linked in: e1000e atl1c radeon(+) ahci libahci libata scsi_mod fbcon tileblit font ttm bitblit softcursor drm_kms_helper wmi xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd Pid: 1600, comm: modprobe Not tainted 3.2.0-06100-ge343a89 #1 Call Trace: [<ffffffff8108973a>] warn_slowpath_common+0x7a/0xb0 [<ffffffff81089785>] warn_slowpath_null+0x15/0x20 [<ffffffffa0060309>] ttm_dma_unpopulate+0x79/0x300 [ttm] [<ffffffffa01341c0>] radeon_ttm_tt_unpopulate+0x120/0x130 [radeon] [<ffffffffa0056e0c>] ttm_tt_destroy+0x2c/0x70 [ttm] [<ffffffffa0057a4e>] ttm_bo_cleanup_memtype_use+0x3e/0x80 [ttm] [<ffffffffa00595a1>] ttm_bo_release+0x251/0x280 [ttm] [<ffffffffa0059610>] ttm_bo_unref+0x40/0x60 [ttm] [<ffffffffa0134d02>] radeon_bo_unref+0x42/0x80 [radeon] [<ffffffffa0186dfb>] radeon_sa_bo_manager_fini+0x6b/0x80 [radeon] [<ffffffffa0146b8f>] radeon_ib_pool_fini+0x6f/0x90 [radeon] [<ffffffffa014be49>] r100_ib_fini+0x19/0x20 [radeon] [<ffffffffa017b47e>] evergreen_init+0x1ee/0x2d0 [radeon] The big WARN() has nothing to do with the culprit - which is that the firmware was not loaded. So lets remove the WARN() from the TTM DMA code. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> |
|
|
Dan Carpenter
|
7920aa5a9d |
drm/ttm: fix condition (and vs or)
The "if (!p && !p->dev)" condition isn't right because || was intended instead of &&. But actually, "p" is the list cursor and so it's always non-NULL and we can just remove that bit. We can remove the another similar check as well. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com> |
|
|
Konrad Rzeszutek Wilk
|
2c05114d23 |
drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and don't try to free freed pages.
The code to figure out how many pages to shrink the pool ends up capping the 'count' at _manager->options.max_size - which is OK. Except that the 'count' is also used when accounting for how many pages are recycled - which we end up with the invalid values. This fixes it by using a different value for the amount of pages to shrink. On top of that we would free the cached page pool - which is nonsense as they are deleted from the pool - so there are no free pages in that pool.. Also we also missed the opportunity to batch the amount of pages to free (similar to how ttm_page_alloc.c does it). This reintroduces the code that was lost during rebasing. Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com> |
|
|
Konrad Rzeszutek Wilk
|
36d7c537c3 |
drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool.
Otherwise we are doing redundant work. Especially since the 'unbind'
and 'unpopulate' have been merged and nouveau driver ends up calling
it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3)
we end up spending about 54% CPU time in __change_page_attr_set_clr
checking the page flags.
The callgraph (annotated) looks as so before this patch:
53.29% gnome-shell [kernel.kallsyms] [k] static_protections
|
--- static_protections
|
|--91.80%-- __change_page_attr_set_clr
| change_page_attr_set_clr
| set_pages_array_wb
| |
| |--96.55%-- ttm_dma_unpopulate
| | nouveau_ttm_tt_unpopulate
| | ttm_tt_destroy
| | ttm_bo_cleanup_memtype_use
| | ttm_bo_release
| | kref_put
| | ttm_bo_unref
| | nouveau_gem_object_del
| | drm_gem_object_free
| | kref_put
| | drm_gem_object_unreference_unlocked
| | drm_gem_object_handle_unreference_unlocked.part.1
| | drm_gem_handle_delete
| | drm_gem_close_ioctl
| | drm_ioctl
| | do_vfs_ioctl
| | sys_ioctl
| | system_call_fastpath
| | __GI___ioctl
| |
| --3.45%-- ttm_dma_pages_put
| ttm_dma_page_pool_free
| ttm_dma_unpopulate
| nouveau_ttm_tt_unpopulate
| ttm_tt_destroy
| ttm_bo_cleanup_memtype_use
| ttm_bo_release
| kref_put
| ttm_bo_unref
| nouveau_gem_object_del
| drm_gem_object_free
| kref_put
| drm_gem_object_unreference_unlocked
| drm_gem_object_handle_unreference_unlocked.part.1
| drm_gem_handle_delete
| drm_gem_close_ioctl
| drm_ioctl
| do_vfs_ioctl
| sys_ioctl
| system_call_fastpath
| __GI___ioctl
|
--8.20%-- change_page_attr_set_clr
set_pages_array_wb
|
|--93.76%-- ttm_dma_unpopulate
| nouveau_ttm_tt_unpopulate
| ttm_tt_destroy
| ttm_bo_cleanup_memtype_use
| ttm_bo_release
| kref_put
| ttm_bo_unref
| nouveau_gem_object_del
| drm_gem_object_free
| kref_put
| drm_gem_object_unreference_unlocked
| drm_gem_object_handle_unreference_unlocked.part.1
| drm_gem_handle_delete
| drm_gem_close_ioctl
| drm_ioctl
| do_vfs_ioctl
| sys_ioctl
| system_call_fastpath
| __GI___ioctl
|
--6.24%-- ttm_dma_pages_put
ttm_dma_page_pool_free
ttm_dma_unpopulate
nouveau_ttm_tt_unpopulate
ttm_tt_destroy
ttm_bo_cleanup_memtype_use
ttm_bo_release
kref_put
ttm_bo_unref
nouveau_gem_object_del
drm_gem_object_free
kref_put
drm_gem_object_unreference_unlocked
drm_gem_object_handle_unreference_unlocked.part.1
drm_gem_handle_delete
drm_gem_close_ioctl
drm_ioctl
do_vfs_ioctl
sys_ioctl
system_call_fastpath
__GI___ioctl
and after this patch all of that disappears.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
Jerome Glisse
|
8e7e70522d |
drm/ttm: isolate dma data from ttm_tt V4
Move dma data to a superset ttm_dma_tt structure which herit from ttm_tt. This allow driver that don't use dma functionalities to not have to waste memory for it. V2 Rebase on top of no memory account changes (where/when is my delorean when i need it ?) V3 Make sure page list is initialized empty V4 typo/syntax fixes Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> |
|
|
Konrad Rzeszutek Wilk
|
2334b75ffb |
drm/ttm: provide dma aware ttm page pool code V9
In TTM world the pages for the graphic drivers are kept in three different
pools: write combined, uncached, and cached (write-back). When the pages
are used by the graphic driver the graphic adapter via its built in MMU
(or AGP) programs these pages in. The programming requires the virtual address
(from the graphic adapter perspective) and the physical address (either System RAM
or the memory on the card) which is obtained using the pci_map_* calls (which does the
virtual to physical - or bus address translation). During the graphic application's
"life" those pages can be shuffled around, swapped out to disk, moved from the
VRAM to System RAM or vice-versa. This all works with the existing TTM pool code
- except when we want to use the software IOTLB (SWIOTLB) code to "map" the physical
addresses to the graphic adapter MMU. We end up programming the bounce buffer's
physical address instead of the TTM pool memory's and get a non-worky driver.
There are two solutions:
1) using the DMA API to allocate pages that are screened by the DMA API, or
2) using the pci_sync_* calls to copy the pages from the bounce-buffer and back.
This patch fixes the issue by allocating pages using the DMA API. The second
is a viable option - but it has performance drawbacks and potential correctness
issues - think of the write cache page being bounced (SWIOTLB->TTM), the
WC is set on the TTM page and the copy from SWIOTLB not making it to the TTM
page until the page has been recycled in the pool (and used by another application).
The bounce buffer does not get activated often - only in cases where we have
a 32-bit capable card and we want to use a page that is allocated above the
4GB limit. The bounce buffer offers the solution of copying the contents
of that 4GB page to an location below 4GB and then back when the operation has been
completed (or vice-versa). This is done by using the 'pci_sync_*' calls.
Note: If you look carefully enough in the existing TTM page pool code you will
notice the GFP_DMA32 flag is used - which should guarantee that the provided page
is under 4GB. It certainly is the case, except this gets ignored in two cases:
- If user specifies 'swiotlb=force' which bounces _every_ page.
- If user is using a Xen's PV Linux guest (which uses the SWIOTLB and the
underlaying PFN's aren't necessarily under 4GB).
To not have this extra copying done the other option is to allocate the pages
using the DMA API so that there is not need to map the page and perform the
expensive 'pci_sync_*' calls.
This DMA API capable TTM pool requires for this the 'struct device' to
properly call the DMA API. It also has to track the virtual and bus address of
the page being handed out in case it ends up being swapped out or de-allocated -
to make sure it is de-allocated using the proper's 'struct device'.
Implementation wise the code keeps two lists: one that is attached to the
'struct device' (via the dev->dma_pools list) and a global one to be used when
the 'struct device' is unavailable (think shrinker code). The global list can
iterate over all of the 'struct device' and its associated dma_pool. The list
in dev->dma_pools can only iterate the device's dma_pool.
/[struct device_pool]\
/---------------------------------------------------| dev |
/ +-------| dma_pool |
/-----+------\ / \--------------------/
|struct device| /-->[struct dma_pool for WC]</ /[struct device_pool]\
| dma_pools +----+ /-| dev |
| ... | \--->[struct dma_pool for uncached]<-/--| dma_pool |
\-----+------/ / \--------------------/
\----------------------------------------------/
[Two pools associated with the device (WC and UC), and the parallel list
containing the 'struct dev' and 'struct dma_pool' entries]
The maximum amount of dma pools a device can have is six: write-combined,
uncached, and cached; then there are the DMA32 variants which are:
write-combined dma32, uncached dma32, and cached dma32.
Currently this code only gets activated when any variant of the SWIOTLB IOMMU
code is running (Intel without VT-d, AMD without GART, IBM Calgary and Xen PV
with PCI devices).
Tested-by: Michel Dänzer <michel@daenzer.net>
[v1: Using swiotlb_nr_tbl instead of swiotlb_enabled]
[v2: Major overhaul - added 'inuse_list' to seperate used from inuse and reorder
the order of lists to get better performance.]
[v3: Added comments/and some logic based on review, Added Jerome tag]
[v4: rebase on top of ttm_tt & ttm_backend merge]
[v5: rebase on top of ttm memory accounting overhaul]
[v6: New rebase on top of more memory accouting changes]
[v7: well rebase on top of no memory accounting changes]
[v8: make sure pages list is initialized empty]
[v9: calll ttm_mem_global_free_page in unpopulate for accurate accountg]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Acked-by: Thomas Hellstrom <thellstrom@vmware.com>
|