- 03 Nov, 2015 37 commits
-
-
Roy Spliet authored
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>
-
Roy Spliet authored
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 authored
Like Pierre's G94. We might want to structure Kepler similarly in a follow-up. Signed-off-by:
-
Roy Spliet authored
Does not seem to be necessary for NVA0, hence untested by me. Signed-off-by:
-
Roy Spliet authored
Seems to be mostly equal to DDR3 on < GT218, should improve stability for DDR2 reclocks. Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Roy Spliet authored
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 authored
Signed-off-by:
-
Pierre Moreau authored
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: -
Julia Lawall authored
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:
-
Ilia Mirkin authored
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:
-
Ilia Mirkin authored
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:
-
Sudip Mukherjee authored
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:
-
Sudip Mukherjee authored
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:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Signed-off-by:
-
Ben Skeggs authored
Reported to be needed as per fdo#70354 comment #61. Signed-off-by: -
Ben Skeggs authored
Not 100% confirmed, but seems to match from the few boards I've looked at so far. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
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 authored
An upcoming patch will implement functionality that we don't use on any NV40 chipset. Signed-off-by: -
Ben Skeggs authored
An upcoming patch will implement functionality that we don't use on the original NV50. Signed-off-by: -
Samuel Pitoiset authored
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:
-
Martin Peres authored
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:
-
Martin Peres authored
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 authored
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 authored
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 authored
Signed-off-by:
-
Alexandre Courbot authored
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:
-
Alexandre Courbot authored
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 authored
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 authored
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 authored
The Great Nouveau Refactoring Take II brought us a lot of goodness, including acquire/release methods that are called before and after an instobj is modified. These functions can be used as synchronization points to manage CPU/GPU coherency if we modify an instobj using the CPU. This patch replaces the legacy and slow PRAMIN access for gk20a instmem with CPU mappings and writes. A LRU list is used to unmap unused mappings after a certain threshold (currently 1MB) of mapped instobjs is reached. This allows mappings to be reused most of the time. Accessing instobjs using the CPU requires to maintain the GPU L2 cache, which we do in the acquire/release functions. This triggers a lot of L2 flushes/invalidates, but most of them are performed on an empty cache (and thus return immediately), and overall context setup performance greatly benefits from this (from 250ms to 160ms on Jetson TK1 for a simple libdrm program). Making L2 management more explicit should allow us to grab some more performance in the future. Signed-off-by:
-
Ben Skeggs authored
No longer required in a lot of cases, as objects are identified over NVIF via an alternate mechanism since the rework. Signed-off-by: -
Alexandre Courbot authored
Allow clients to manually flush and invalidate L2. This will be useful for Tegra systems for which we want to write instmem using the CPU. Signed-off-by:
-
Alexandre Courbot authored
These are useful for systems without a coherent CPU/GPU bus. For such systems we may need to maintain the L2 ourselves. Signed-off-by:
-
Alexandre Courbot authored
Reintroduce macros allowing us to test a register against a certain mask, since this is the most common usage pattern for the more generic nvkm_xsec macros and makes the code more concise and readable. Signed-off-by:
-
Alexandre Courbot authored
Some devices may not have a PMU. Avoid a NULL pointer dereference in such cases by checking whether the pointer given to nvkm_pmu_pgob() is valid. Signed-off-by:
-
Ilia Mirkin authored
On nv50+, we restrict the valid domains to just the one where the buffer was originally created. However after the buffer is evicted to system memory, we might move it back to a different domain that was not originally valid. When sharing the buffer and retrieving its GEM_INFO data, we still want the domain that will be valid for this buffer in a pushbuf, not the one where it currently happens to be. This resolves fdo#92504 and several others. These are due to suspend evicting all buffers, making it more likely that they temporarily end up in the wrong place. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504Signed-off-by:
-
- 29 Oct, 2015 3 commits
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Few more drm-misc stragglers for 4.4. Big thing is the generic probe for imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing). Also the hdmi clocking fixes from Ville which was a lot of confusion about which tree it should be applied to ;-) * tag 'topic/drm-misc-2015-10-22' of git://anongit.freedesktop.org/drm-intel: drm: correctly check failed allocation vga_switcheroo: Constify vga_switcheroo_handler drm/armada: Convert the probe function to the generic drm_of_component_probe() drm/rockchip: Convert the probe function to the generic drm_of_component_probe() drm/imx: Convert the probe function to the generic drm_of_component_probe() drm: Introduce generic probe function for component based masters. drm/edid: Round to closest when computing the CEA/HDMI alternate clock drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
More amdgpu and radeon stuff for drm-next. Stoney support is the big change. The rest is just bug fixes and code cleanups. The Stoney stuff is pretty low impact with respect to existing chips. * 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: change VM size default to 64GB drm/amdgpu: add Stoney pci ids drm/amdgpu: update the core VI support for Stoney drm/amdgpu: add VCE support for Stoney (v2) drm/amdgpu: add UVD support for Stoney drm/amdgpu: add GFX support for Stoney (v2) drm/amdgpu: add SDMA support for Stoney (v2) drm/amdgpu: add DCE support for Stoney drm/amdgpu: Update SMC/DPM for Stoney drm/amdgpu: add GMC support for Stoney drm/amdgpu: add Stoney chip family drm/amdgpu: fix the broken vm->mutex V2 drm/amdgpu: remove the unnecessary parameter adev for amdgpu_fence_wait_any() drm/amdgpu: remove the exclusive lock drm/amdgpu: remove old lockup detection infrastructure drm: fix trivial typos drm/amdgpu/dce: simplify suspend/resume drm/amdgpu/gfx8: set TC_WB_ACTION_EN in RELEASE_MEM packet drm/radeon: Use rdev->gem.mutex to protect hyperz/cmask owners
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2015-10-22' of git://anongit.freedesktop.org/drm-intel into drm-next Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work from Ville in here since it's low-risk but lots of churn all over. * tag 'drm-intel-next-fixes-2015-10-22' of git://anongit.freedesktop.org/drm-intel: (23 commits) drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks drm/i915: Kill the leftover RMW from ivb_sprite_disable() drm/i915: restore ggtt double-bind avoidance drm/i915/skl: Enable pipe gamma for sprite planes. drm/i915/skl+: Enable pipe CSC on cursor planes. (v2) MAINTAINERS: add link to the Intel Graphics for Linux web site drm/i915: Move skl/bxt gt specific workarounds to ring init drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level drm/i915: revert a few more watermark commits drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE drm/i915: Clean up LVDS register handling drm/i915: Throw out some useless variables drm/i915: Parametrize and fix SWF registers drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc. drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function drm/i915: Fix a few bad hex numbers in register defines drm/i915: Protect register macro arguments drm/i915: Include gpio_mmio_base in GMBUS reg defines drm/i915: Parametrize HSW video DIP data registers drm/i915: Eliminate weird parameter inversion from BXT PPS registers ...
-
