summaryrefslogtreecommitdiffstats
path: root/drivers/thunderbolt (unfollow)
Commit message (Collapse)AuthorFilesLines
2015-11-04drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVEChristian König3-4/+3
Moves are exclusive operations anyway, just use the undefined owner for those. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: remove now unused fence functionsChristian König1-39/+0
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: fix fence fallback checkChristian König1-0/+2
Interrupts are notorious unreliable, enable the fallback at a couple of more places. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: fix stoping the scheduler timeoutChristian König1-1/+1
cancel_delayed_work_sync is forbidden in interrupt context. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-04drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()Dan Carpenter1-2/+4
We recently changed the locking in this function and now there is a missing unlock on error. Also there are some other resources that we should probably release as well... Fixes: f48b2659f521 ('drm/amdgpu: fix the broken vm->mutex V2') Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
2015-11-04drm/i915: Fix locking around GuC firmware loadDaniel Stone2-8/+5
The GuC firmware load requires struct_mutex to create a GEM object, but this collides badly with request_firmware. Move struct_mutex locking down into the loader itself, so we don't hold it across the entire load process, including request_firmware. [ 20.451400] ====================================================== [ 20.451420] [ INFO: possible circular locking dependency detected ] [ 20.451441] 4.3.0-rc5+ #1 Tainted: G W [ 20.451457] ------------------------------------------------------- [ 20.451477] plymouthd/371 is trying to acquire lock: [ 20.451494] (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0093c62>] drm_gem_mmap+0x112/0x290 [drm] [ 20.451538] but task is already holding lock: [ 20.451557] (&mm->mmap_sem){++++++}, at: [<ffffffff811fd9ac>] vm_mmap_pgoff+0x8c/0xf0 [ 20.451591] which lock already depends on the new lock. [ 20.451617] the existing dependency chain (in reverse order) is: [ 20.451640] -> #3 (&mm->mmap_sem){++++++}: [ 20.451661] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.451683] [<ffffffff8120ec9a>] __might_fault+0x7a/0xa0 [ 20.451705] [<ffffffff8127e34e>] filldir+0x9e/0x130 [ 20.451726] [<ffffffff81295b86>] dcache_readdir+0x186/0x230 [ 20.451748] [<ffffffff8127e117>] iterate_dir+0x97/0x130 [ 20.451769] [<ffffffff8127e66a>] SyS_getdents+0x9a/0x130 [ 20.451790] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.451829] -> #2 (&sb->s_type->i_mutex_key#2){+.+.+.}: [ 20.451852] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.451872] [<ffffffff8184b516>] mutex_lock_nested+0x86/0x400 [ 20.451893] [<ffffffff81277790>] walk_component+0x1d0/0x2a0 [ 20.451914] [<ffffffff812779f0>] link_path_walk+0x190/0x5a0 [ 20.451935] [<ffffffff8127803b>] path_openat+0xab/0x1260 [ 20.451955] [<ffffffff8127a651>] do_filp_open+0x91/0x100 [ 20.451975] [<ffffffff81267e67>] file_open_name+0xf7/0x150 [ 20.451995] [<ffffffff81267ef3>] filp_open+0x33/0x60 [ 20.452014] [<ffffffff8157e1e7>] _request_firmware+0x277/0x880 [ 20.452038] [<ffffffff8157e9e4>] request_firmware_work_func+0x34/0x80 [ 20.452060] [<ffffffff810c7020>] process_one_work+0x230/0x680 [ 20.452082] [<ffffffff810c74be>] worker_thread+0x4e/0x450 [ 20.452102] [<ffffffff810ce511>] kthread+0x101/0x120 [ 20.452121] [<ffffffff8184f66f>] ret_from_fork+0x3f/0x70 [ 20.452140] -> #1 (umhelper_sem){++++.+}: [ 20.452159] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.452178] [<ffffffff8184c5c1>] down_read+0x51/0xa0 [ 20.452197] [<ffffffff810c203b>] usermodehelper_read_trylock+0x5b/0x130 [ 20.452221] [<ffffffff8157e147>] _request_firmware+0x1d7/0x880 [ 20.452242] [<ffffffff8157e821>] request_firmware+0x31/0x50 [ 20.452262] [<ffffffffa01b54a4>] intel_guc_ucode_init+0xf4/0x400 [i915] [ 20.452305] [<ffffffffa0213913>] i915_driver_load+0xd63/0x16e0 [i915] [ 20.452343] [<ffffffffa00987d9>] drm_dev_register+0xa9/0xc0 [drm] [ 20.452369] [<ffffffffa009ae3d>] drm_get_pci_dev+0x8d/0x1e0 [drm] [ 20.452396] [<ffffffffa01521e4>] i915_pci_probe+0x34/0x50 [i915] [ 20.452421] [<ffffffff81464675>] local_pci_probe+0x45/0xa0 [ 20.452443] [<ffffffff81465a6d>] pci_device_probe+0xfd/0x140 [ 20.452464] [<ffffffff8156a2e4>] driver_probe_device+0x224/0x480 [ 20.452486] [<ffffffff8156a5c8>] __driver_attach+0x88/0x90 [ 20.452505] [<ffffffff81567cf3>] bus_for_each_dev+0x73/0xc0 [ 20.452526] [<ffffffff81569a7e>] driver_attach+0x1e/0x20 [ 20.452546] [<ffffffff815695ae>] bus_add_driver+0x1ee/0x280 [ 20.452566] [<ffffffff8156b100>] driver_register+0x60/0xe0 [ 20.453197] [<ffffffff81464050>] __pci_register_driver+0x60/0x70 [ 20.453845] [<ffffffffa009b070>] drm_pci_init+0xe0/0x110 [drm] [ 20.454497] [<ffffffffa027f092>] 0xffffffffa027f092 [ 20.455156] [<ffffffff81002123>] do_one_initcall+0xb3/0x200 [ 20.455796] [<ffffffff811d8c01>] do_init_module+0x5f/0x1e7 [ 20.456434] [<ffffffff8114c4e6>] load_module+0x2126/0x27d0 [ 20.457071] [<ffffffff8114cdf9>] SyS_finit_module+0xb9/0xf0 [ 20.457738] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.458370] -> #0 (&dev->struct_mutex){+.+.+.}: [ 20.459773] [<ffffffff8110584f>] __lock_acquire+0x191f/0x1ba0 [ 20.460451] [<ffffffff8110644e>] lock_acquire+0xce/0x1c0 [ 20.461074] [<ffffffffa0093c88>] drm_gem_mmap+0x138/0x290 [drm] [ 20.461693] [<ffffffff8121a5ec>] mmap_region+0x3ec/0x670 [ 20.462298] [<ffffffff8121abb2>] do_mmap+0x342/0x420 [ 20.462901] [<ffffffff811fd9d2>] vm_mmap_pgoff+0xb2/0xf0 [ 20.463532] [<ffffffff81218f62>] SyS_mmap_pgoff+0x1f2/0x290 [ 20.464118] [<ffffffff8102187b>] SyS_mmap+0x1b/0x30 [ 20.464702] [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 20.465289] other info that might help us debug this: [ 20.467179] Chain exists of: &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem [ 20.468928] Possible unsafe locking scenario: [ 20.470161] CPU0 CPU1 [ 20.470745] ---- ---- [ 20.471325] lock(&mm->mmap_sem); [ 20.471902] lock(&sb->s_type->i_mutex_key#2); [ 20.472538] lock(&mm->mmap_sem); [ 20.473118] lock(&dev->struct_mutex); [ 20.473704] *** DEADLOCK *** Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-03drm/amdgpu: update Fiji's Golden settingFlora Cui1-7/+15
Change-Id: Ic3f3bfce4767cc05d04f6eb24e22a0f3e7ceacaa Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-03drm/amdgpu: update Fiji's rev idFlora Cui1-0/+5
Change-Id: I0018e2b72feb771683c57960ba3ce942bec5d3ab Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-03drm/amdgpu: extract common code in vi_common_early_initFlora Cui1-6/+3
Change-Id: I9ed25353c559e27bc1b1d5b50f977b0ff03de87f Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-03drm/amd/scheduler: don't oops on failure to loadDave Airlie1-1/+2
In two places amdgpu tries to tear down something it hasn't initalised when failing. This is what happens when you enable experimental support on topaz which then fails in ring init. This patch allows it to fail cleanly. agd: Split out from from the original patch since the scheduler is a driver independent. Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-11-03drm/amdgpu: don't oops on failure to load (v2)Dave Airlie1-0/+3
In two places amdgpu tries to tear down something it hasn't initalised when failing. This is what happens when you enable experimental support on topaz which then fails in ring init. This patch allows it to fail cleanly. v2 (agd): split out scheduler change into a separate patch Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-11-03drm/amdgpu: don't VT switch on suspendAlex Deucher1-0/+1
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-03drm/nouveau: bump patchlevel to indicate availability of abi16/nvif interopBen Skeggs1-1/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/abi16: implement limited interoperability with usif/nvifBen Skeggs3-2/+53
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/abi16: introduce locked variant of nouveau_abi16_get()Ben Skeggs1-5/+13
USIF already takes the client mutex, but will need access to ABI16 data in order to provide some limited interoperability. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/abi16: remove unused argument from nouveau_abi16_get()Ben Skeggs3-9/+8
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci: enable c800 magic for Medion Erazer X7827Ilia Mirkin1-0/+1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci: enable c800 magic for Lenovo Y510PIlia Mirkin1-1/+7
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70354#c75 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5Karol Herbst1-23/+77
This patch uses an approach closer to the nvidia driver to configure both PLLs for high gddr5 memory clocks (usually above 2400MHz) Previously nouveau used the one PLL as it was used for the lower clocks and just adjusted the second PLL to get as close as possible to the requested clock. This means for my card, that I got a 4050 MHz clock although 4008 MHz was requested. Now the driver iterates over a list of PLL configuration also used by the nvidia driver and then adjust the second PLL to get near the requested clock. Also it hold to some restriction I found while analyzing the PLL configurations This won't fix all gddr5 high clock issues itself, but it should be fine on hybrid gpu systems as found on many laptops these days. Also switching while normal desktop usage should be a lot more stable than before. v2: move the pll code into ramgk104 Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/clk/g84: Enable reclocking for GDDR3 G94-G200Roy Spliet1-1/+1
Your milage may vary, as it's only been tested on a single G94 and one G96. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/bus/hwsq: Implement VBLANK waiting heuristicRoy Spliet5-2/+41
Avoids waiting for VBLANKS that never arrive on headless or otherwise unconventional set-ups. Strategy taken from MEMX. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramnv50: Script changes for G94 and upRoy Spliet1-6/+30
10053c is not even read on some cards, and I have no idea exactly what the criteria are. Likely NVIDIA pre-scans the VBIOS and in their driver disables all features that are never used. The practical effect should be the same as this implementation though. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramnv50: Deal with cards without timing entriesRoy Spliet3-7/+50
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramnv50: Voltage GPIOsRoy Spliet2-0/+42
Does not seem to be necessary for NVA0, hence untested by me. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramgt215: Restructure r111100 calculation for DDR2Roy Spliet1-30/+34
Seems to be mostly equal to DDR3 on < GT218, should improve stability for DDR2 reclocks. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramgt215: Change FBVDD/Q when BIOS asks for itRoy Spliet3-0/+20
Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/fb/ramgt215: Transform GPIO ramfuc method from FBVREF-specific ↵Roy Spliet2-24/+19
to generic In preparation of changing FBVDDQ, as observed on at least one GDDR3 card. While at it, adhere to func.log[1] properly for consistency. Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/bios/rammap: Identify DLLoff for >= GF100Roy Spliet5-12/+39
Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci: Handle 5-bit and 8-bit tag fieldPierre Moreau6-0/+37
If the hardware supports extended tag field (8-bit ones), then enable it. This is usually done by the VBIOS, but not on some MBPs (see fdo#86537). In case extended tag field is not supported, 5-bit tag field is used which limits the possible number of requests to 32. Apparently bits 7:0 of 0x08841c stores some number of outstanding requests, so cap it to 32 if extended tag is unsupported. Fixes: fdo#86537 v2: Restrict changes to chipsets >= 0x84 v3: * Add nvkm_pci_mask to pci.h * Mask bit 8 before setting it v4: * Rename `add` argument of nvkm_pci_mask to `value` * Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset checks v5: * Rebase code on latest PCI structure * Restore PCIe check * Fix namings in nvkm_pci_mask * Rephrase part of the commit message Signed-off-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/disp,pm: constify nvkm_object_func structuresJulia Lawall2-2/+2
These nvkm_object_func structures are never modified. All other nvkm_object_func structures are declared as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/gr: add FERMI_COMPUTE_B class to GF110+Ilia Mirkin3-0/+3
GF110+ supports both the A and B compute classes, make sure to accept both. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/gr: document mp error 0x10Ilia Mirkin1-0/+1
NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE, which apparently happens when trying to use an atomic operation on local or shared memory (instead of global memory). Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau: fix memory leakSudip Mukherjee1-1/+3
If pm_runtime_get_sync() we were going to "out" but we missed freeing vma. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau: remove unused functionSudip Mukherjee2-15/+0
coverity.com reported that memset was using a buffer of size 0, on checking the code it turned out that the function was not being used. So remove it. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pmu/gk107: enable PGOB codepathsBen Skeggs1-1/+1
Reported to be needed as per fdo#70354 comment #61. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pmu/gk104: check fuse to determine presence of PGOBBen Skeggs1-0/+4
Not 100% confirmed, but seems to match from the few boards I've looked at so far. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci: prepare for chipset-specific initialisation tasksBen Skeggs2-0/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci/nv46: attempt to fix msi, and re-enable by defaultBen Skeggs6-12/+12
Was not able to obtain a trace of NVRM due to kernel version annoyances, however, experimentally confirmed that the WAR we use on NV50/G8x boards works here too. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci/g94: split implementation from nv40Ben Skeggs6-26/+67
An upcoming patch will implement functionality that we don't use on any NV40 chipset. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pci/g84: split implementation from nv50Ben Skeggs6-5/+49
An upcoming patch will implement functionality that we don't use on the original NV50. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/ibus/gf100: increase wait timeout to avoid read faultsSamuel Pitoiset6-4/+77
Increase clock timeout of some unknown engines in order to avoid failure at high gpcclk rate. This fixes IBUS read faults on my GF119 when reclocking is manually enabled. Note that memory reclocking is completely broken and NvMemExec has to be disabled to allow core clock reclocking only. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/gm204/6: add voltage control using the new gk104 volt classMartin Peres1-0/+2
I got confirmation that we can read and change the voltage with the same code. The divider is also computed correctly on the gm204 we got our hands on. Thanks to Yoshimo on IRC for executing the tests on his gm204! Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/gm107: add voltage control using the new gk104 volt classMartin Peres1-0/+1
Let's ignore the other desktop Maxwells until I get my hands on one and confirm that we still can change the voltage. Signed-off-by: Martin Peres <martin.peres@free.fr>
2015-11-03drm/nouveau/volt/gk104: add support for pwm and gpio modesMartin Peres6-7/+133
Most Keplers actually use the GPIO-based voltage management instead of the new PWM-based one. Use the GPIO mode as a fallback as it already gracefully handles the case where no GPIOs exist. All the Maxwells seem to use the PWM method though. v2: - Do not forget to commit the PWM configuration change! Signed-off-by: Martin Peres <martin.peres@free.fr>
2015-11-03drm/nouveau/volt: add support for non-vid-based voltage controllersMartin Peres2-1/+12
This patch is not ideal but it definitely beats a rewrite of the current interface and is very self-contained. Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/bios/volt: add support for pwm-based volt managementMartin Peres2-3/+29
Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/ttm: set the DMA mask for platform devicesAlexandre Courbot1-6/+19
So far the DMA mask was not set for platform devices, which limited them to a 32-bit physical space. Allow dma_set_mask() to be called for non-PCI devices, and also take the IOMMU bit into account since it could restrict the physically addressable space. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/ttm: convert to DMA APIAlexandre Courbot1-7/+5
The pci_dma_* functions are now superseeded in the kernel by the DMA API. Make the conversion to this more generic API. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/instmem/gk20a: make use of the IOMMU bitAlexandre Courbot1-4/+6
Use the IOMMU bit specified in platform data instead of hardcoding it to the bit used by current Tegra GPUs. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/platform: allow to specify the IOMMU bitAlexandre Courbot6-10/+46
Current Tegra code taking advantage of the IOMMU assumes a hardcoded value for the IOMMU bit. Make it a platform property instead for flexibility. v2 (Ben Skeggs): remove nvkm dependence on drm structures Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-06 02:28:44 +0100