Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone
should address the remaining warnings galore you experienced on
Skylake. Almost all of the rest are also fixes against user or QA
reported bugs, with references.
* tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel:
drm/i915/skl: disable display side power well support for now
drm/i915: Extend DSL readout fix to BDW and SKL.
drm/i915: Do graphics device reset under forcewake
drm/i915: Skip fence installation for objects with rotated views (v4)
drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)
drm/i915/skl: Prevent unclaimed register writes on skylake.
drm/i915: disable CPU PWM also on LPT/SPT backlight disable
drm/i915: Fix maxfifo watermark calc on vlv cursor planes
drm/i915: add hotplug activation period to hotplug update mask
One is fix for a regression in 4.3, One irq locking rework.
* 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Relax irq locking somewhat
drm/vmwgfx: Properly flush cursor updates and page-flips
Relax locking with the goal of reducing the number of locking cycles and
time spent with irqs disabled.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
With the introduction of the new command buffer mechanism,
proper care wasn't taken to flush cursor image updates and
event-less screen-target page-flips.
Fix this by introducing explicit flush points.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The display power well support on this platform is in a somewhat broken
state atm, so disable it by default.
This in effect will get rid of incorrect assert WARNs about the CSR/DMC
firmware not being loaded during power well toggling. It also removes a
problem during driver loading where a register is accessed while its
backing power well is down, resulting in another WARN. Until we come up
with the root cause of the second problem and the proper fix for both
issues, keep all display side power wells on.
Also clarify a bit the option description.
Reported-by: Dave Airlie <airlied@redhat.com>
Reference: http://mid.gmane.org/CAPM=9tyjBQjSBTKa49cRr6SYkpNW7Pq-fUFznZZ8Y1snvvk7mA@mail.gmail.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446757451-2777-1-git-send-email-imre.deak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We have a timed release of a forcewake when using
I915_READ/WRITE macros. wait_for() macro will go to quite
long sleep if the first read doesn't satisfy the condition for
successful exit. With these two interacting, it is possible that
we lose the forcewake during the wait_for() and the subsequent read
will reaquire forcewake.
Further experiments with skl shows that when we lose forcewake,
we lose the reset request we submitted. So reset request register
is not power context saved.
Grab forcewakes for all engines before starting the reset/request
dance so that all requests stay valid for the duration of reset
requisition across all the engines.
v2: Add comment on power well sleeps. Wrap the reset handling
under forcewake instead of just reset requests (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92774
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> (v1, v2)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446721898-1450-1-git-send-email-mika.kuoppala@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.
v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).
v3:
Pin and unpin a fence only if the current view type is normal.
v4:
Extend the "view type is normal" check for pin_fence as well.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446170078-20792-1-git-send-email-vivek.kasireddy@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
hda_intel.c:azx_probe() defers initialization of an audio controller
on the discrete GPU if the GPU is powered off. The power state of the
GPU is determined by calling vga_switcheroo_get_client_state().
vga_switcheroo_get_client_state() returns VGA_SWITCHEROO_INIT if
vga_switcheroo is not enabled, i.e. if no second GPU or no handler
has registered.
This can go wrong in the following scenario:
- Driver for the integrated GPU is not loaded.
- Driver for the discrete GPU registers with vga_switcheroo, uses driver
power control to power down the GPU, handler cuts power to the GPU.
- Driver for the audio controller gets loaded after the GPU was powered
down, calls vga_switcheroo_get_client_state() which returns
VGA_SWITCHEROO_INIT instead of VGA_SWITCHEROO_OFF.
- Consequence: azx_probe() tries to initialize the audio controller even
though the GPU is powered down.
The power state VGA_SWITCHEROO_INIT was introduced by c8e9cf7bb2
("vga_switcheroo: Add a helper function to get the client state").
It is not apparent what its benefit might be. The idea seems to
be to initialize the audio controller even if the power state is
VGA_SWITCHEROO_OFF (were vga_switcheroo enabled), but as shown
above this can fail.
Drop VGA_SWITCHEROO_INIT to solve this.
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just two small cleanup patches to fix coccinelle warnings.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWM6yPAAoJEN0jrNd/PrOhyBUQALPErCqaBBlS6nv+inM/dIqH
UrhdBQcLF0BFPQmTEix82inkuqYEqB3u2TSDU6MH1IcJfJsOvSjj3/IOpx6uw1+P
AygHPGluMQzunjC48zPWwfYzbrz5zqLK+Apq6afyEowxpnLUcO4yT14u/s2SVdkg
qcNRU2pja/SsXJpz+JYBtCqyGPyuNU+AUBCqc3xFd2RuRQ99P5lZL0rdFTFihCoK
If8MT3VehSE9QKYTkWuWe2c3y3CeucOmreGT+HITj+BE7rbULu73vyd4zdfhb5n6
ObOER1L8YyyM9YfmWUm1swrcEUlG+mSq+ISm76mCwOVvftK0UKQV090WEgpNCRbH
I9D1+pn1vjEK2FXyErOH0AifNAILdoDj3boXLLtyITnjc4K4gKuMeDUpHwUarg/a
Ys51eHrO2mS4EWRxe8QwuP7hj2XFP6sFg3uwWNWMb2WYNoOGfPtxBfobhqU6jBMt
NkNWqSBv/dOvj/5Bddz+3dH6Ea7LDw1oZ3GbBX8K1x1EQTvEPwTjseL3PSAbRbMO
wmRQq/cknkQ9mSP0FEupUw73wc81C6C0iyxJXVtXfJUDkUfMPFJLo3L1Sjqsl4Ey
DVqRpGFUt6hspw8f+DzeittVrXsq65XRKDTg3VlnEQVq/tBPErzXPwVNLhi9fLkY
WQzb+vHIEic4zYY8yIjB
=Q9bM
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.4-rc1
Just two small cleanup patches to fix coccinelle warnings.
* tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/bridge: ptn3460: Fix coccinelle warnings
drm/bridge: ps8622: Fix coccinelle warnings
Just a couple of minor fixes and cleanups for this cycle.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWM6wLAAoJEN0jrNd/PrOh/HwP/23WEi/j4lBC8NMIOuxg9Eg5
xfEN7hD3VLS3a/wzqCsM5UK9d8hSftCSKrYggKFL1NWsb3XIIyDHTc40dHl3MFMA
r8WVk01XJhdpmSxhc0To1/a0HaKWfKlti2tZNTTYRa2w3pWMLSL/TVKmtAnebv9Z
s15ISWzyjsV6hIMwl3AdvawLDy+u/j3kvwXw/XnSJYRvjDvsFQb0msIu7lGEIWfO
/kabMKJAWUt/cdllWUbPbQdDZv2cY4m3MnSv3NLjOeyHqoZbnHvnx1zNMCYs/3+f
tAzIgpPaMRVNA2vvXINqs7GA3oqks9JmqPysBfUoXD3uiewCzSHXV5fC39kwdhSh
BntCBtL8PTbmVbX7dsgFEFHRx99Lvs37Jrk+4TTzO50L8nTtkXg8UsA/dpL/Ww5B
jlNe/ZAXCOvlEpnmLjmH7Y2N+kbaV7yQmYv/7YKDb1hkQ3mEnv2kwbM9WdN9emyG
pHdXWNGeb72Q8+fBAF1h47M40Zeebkfa6issx8uesTJj1smBwIqxIr3r8f3yShKt
YbMre/K5C+X3xbX9uV79A2k9QqCgWhGkdxSmpGfivOZSzfVNZ3e81fgIeF7f3bbs
uMLs2dpo46XSAOa+fl7GEKIt72824TiQSve+HpqqUv+qt2F5QcBldlwbqv0eJdF+
VmfERYXWM8sgLSLru7L7
=c0/4
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.4-rc1
Just a couple of minor fixes and cleanups for this cycle.
* tag 'drm/tegra/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: dc: Request/free syncpoint at init/exit
drm/tegra: fb: Remove gratuituous blank line
gpu: host1x: Fix MLOCK's debug info
- Some correctness fixes found by coccinelle
- Add drivers/gpu/ipu-v3 directory to MAINTAINERS
- Add support for more color formats
- Fix a regression, making displays larger than FullHD work again
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWM5loAAoJEFDCiBxwnmDrLwkQAOd2iOsgGemyffmh8shGwGq4
pVgw/2Z9FzdlLXe21R9B8rYOsvq/QR74m49blNGSwlNO6c2L3+65BBkyc2VQoI6t
c3GX0w2mnjqfHOZYiBT1Ca84FT1DBXjOprhljVbCBBZOr0xK4jRY3YBtlk30r8Yv
RlithxYNWjoCBidf4w7FyCKM7tIN7bNXXGtyysAMzNuXU7Mq3dfhF8/qYucYFmYP
XHOxFFX/q4EYchcQBCQi56kxEgEHtaFc+pwzM7mCwN5OVETcVeHw0EoTm56AjQrL
zHwBXvP4ryKpuNFCUqsMdy9KZw+4inHycAjfEKwD2s72llycx+W+Kbg/00Ve8rWn
6/Iv4Q0SuSSuRn4fWfioWSdQqHBZig3Y0AWCQ8BVCdTL2K2KIyxcT45vamo/zQhw
uxRVxQzEUle4ZJJ4DOt5h4ZHF70eQNM9TDGYYSKUqtfQcbZ6pr6mz36J9PgyQuh7
lTOfC5OZstTmS1iK+dqb5zbxhC76ff+v1lS8oTyJPK207f0hwt5OXTki9i7TueUH
DXbPmrotajFWoNOkgFPcBBQaI6P5+29lzFqXE2z43Qk6UoYmR4T+UbpD2nNKaj+I
qsIvgn4Zkg2RkxXehVQxRqynxx7XzfXVBXmtpbDfm50PoWsQMQa7fUiqWTyAp493
zQybk9I0eNexJNFIzyie
=EqNE
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-next-2015-10-30' of git://git.pengutronix.de/git/pza/linux into drm-next
imx-drm fixes and color format updates
- Some correctness fixes found by coccinelle
- Add drivers/gpu/ipu-v3 directory to MAINTAINERS
- Add support for more color formats
- Fix a regression, making displays larger than FullHD work again
* tag 'imx-drm-next-2015-10-30' of git://git.pengutronix.de/git/pza/linux:
drm/imx: hdmi: fix HDMI setup to allow modes larger than FullHD
gpu: ipu-v3: fix div_ratio type
gpu: ipu-v3: csi: add support for 8 bpp grayscale sensors.
drm/imx: enable ARGB4444 16-bit color format
gpu: ipu-v3: add support for ARGB4444 16-bit color format
drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats
gpu: ipu-v3: add support for RGBX8888 and RGBA8888 pixel formats
drm/imx: enable 15-bit RGB with 1-bit alpha formats
gpu: ipu-v3: add support for 15-bit RGB with 1-bit alpha formats
MAINTAINERS: Add IPUv3 core driver to the i.MX DRM driver section
gpu: ipu-v3: ipu-csi: bool test doesn't need a comparison to false
- Updated register headers for GFX 8.1 for Stoney
- Add some new CZ revisions
- minor pageflip optimizations
- Fencing clean up
- Warning fix
- More fence cleanup
- oops fix
- Fiji fixes
* 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux: (29 commits)
drm/amdgpu: group together common fence implementation
drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE
drm/amdgpu: remove now unused fence functions
drm/amdgpu: fix fence fallback check
drm/amdgpu: fix stoping the scheduler timeout
drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()
drm/amdgpu: update Fiji's Golden setting
drm/amdgpu: update Fiji's rev id
drm/amdgpu: extract common code in vi_common_early_init
drm/amd/scheduler: don't oops on failure to load
drm/amdgpu: don't oops on failure to load (v2)
drm/amdgpu: don't VT switch on suspend
drm/amdgpu: Make amdgpu_mn functions inline
drm/amdgpu: remove amdgpu_fence_ref/unref
drm/amdgpu: use common fence for sync
drm/amdgpu: use the new fence_is_later
drm/amdgpu: use common fences for VMID management v2
drm/amdgpu: move ring_from_fence to common code
drm/amdgpu: switch to common fence_wait_any_timeout v2
drm/amdgpu: remove unneeded fence functions
...
And also add some missing function documentation. No functional change.
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>
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>
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>
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>
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>
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: f48b2659f5 ('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>
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
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
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>
- Vast improvements to gk20a instmem handling.
- Improved PGOB detection + GK107 support.
- Compatibility between old/new interfaces added, final missing piece to
finally enabling userspace to start using them.
- Kepler GDDR5 PLL stability improvements
- Support for non-GPIO (PWM) voltage controllers
- G8x/GT2xx memory clock improvements
- Misc other fixes
* 'linux-4.4' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (45 commits)
drm/nouveau: bump patchlevel to indicate availability of abi16/nvif interop
drm/nouveau/abi16: implement limited interoperability with usif/nvif
drm/nouveau/abi16: introduce locked variant of nouveau_abi16_get()
drm/nouveau/abi16: remove unused argument from nouveau_abi16_get()
drm/nouveau/pci: enable c800 magic for Medion Erazer X7827
drm/nouveau/pci: enable c800 magic for Lenovo Y510P
drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5
drm/nouveau/clk/g84: Enable reclocking for GDDR3 G94-G200
drm/nouveau/bus/hwsq: Implement VBLANK waiting heuristic
drm/nouveau/fb/ramnv50: Script changes for G94 and up
drm/nouveau/fb/ramnv50: Deal with cards without timing entries
drm/nouveau/fb/ramnv50: Voltage GPIOs
drm/nouveau/fb/ramgt215: Restructure r111100 calculation for DDR2
drm/nouveau/fb/ramgt215: Change FBVDD/Q when BIOS asks for it
drm/nouveau/fb/ramgt215: Transform GPIO ramfuc method from FBVREF-specific to generic
drm/nouveau/bios/rammap: Identify DLLoff for >= GF100
drm/nouveau/pci: Handle 5-bit and 8-bit tag field
drm/nouveau/disp,pm: constify nvkm_object_func structures
drm/nouveau/gr: add FERMI_COMPUTE_B class to GF110+
drm/nouveau/gr: document mp error 0x10
...
This pull request includes comprehensive cleanups to HDMI part and
several fixups. In addition, this pull request includes also a defconfig
patch which enables mixer driver as default. For this, I got already
Acked-by from Krzysztof Kozlowski who is a Exynos SoC maintainer.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (34 commits)
drm/exynos/gem: remove DMA-mapping hacks used for constructing page array
ARM: exynos_defconfig: enable Exynos DRM Mixer driver
drm/exynos: simplify Kconfig component names
drm/exynos: re-arrange Kconfig entries
drm/exynos: abstract out common dependency
drm/exynos: separate Mixer and HDMI drivers
drm/exynos/mixer: replace direct cross-driver call with drm mode validation
drm/exynos: add atomic_check callback to exynos_crtc
drm/exynos/decon5433: add support for DECON-TV
drm/exynos/decon5433: remove duplicated initialization
drm/exynos/decon5433: merge different flag fields
drm/exynos/decon5433: add function to set particular register bits
drm/exynos/decon5433: fix timing registers writes
drm/exynos/decon5433: add PCLK clock
drm/exynos: cleanup name of gem object for exynos_drm
drm/exynos: fix to detach device of iommu
drm/exynos: add cursor plane support
drm/exynos: add global macro for the default primary plane
drm/exynos: fix spelling errors
drm: exynos: mixer: fix using usleep() in atomic context
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
