- 12 Oct, 2016 27 commits
-
-
Alexandre Courbot authored
Doing direct 64 bit divisions in kernel code leads to references to undefined symbols on 32 bit architectures. Replace such divisions with calls to div64_s64 to make the module usable on 32 bit archs. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Reviewed-by:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Baoyou Xie authored
We get 2 warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] In fact, both functions are declared in drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h, so this patch adds missing header dependencies. Signed-off-by:
Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by:
-
Ilia Mirkin authored
Tested on a NV34. There are reports of this also working on the other nv3x chips. Largely useful for testing software written for NV2x without having the actual hardware available. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Martin Peres authored
We received a donation of a Titan which has this useless feature allowing users to control the brightness of the LED behind the logo of NVIDIA. In the true spirit of open source, let's expose that to the users of very expensive cards! This patch hooks up this LED/PWM to the LED subsystem which allows blinking it in sync with cpu/disk/network/whatever activity (heartbeat is quite nice!). Users may also implement some breathing effect or morse code support in the userspace if they feel like it. v2: - surround the use of the LED framework with ifdef CONFIG_LEDS_CLASS v3: - avoid using ifdefs everywhere, follow the recommendations of /doc/Documentation/CodingStyle. Suggested by Emil Velikov. v4 (Ben): - squashed series of fixes from ml Signed-off-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Karol Herbst authored
This enables memory reclocking on Maxwell. Sadly without a PMU firmware it is useless for gm20x gpus. Signed-off-by:
-
Karol Herbst authored
I'm quite sure that those coefficients are real close, because while testing the biggest error compared to nvidia was around -1.5% (biggest error with right coefficients is 12.5mV / 600mV = 2%). These coefficients were REed by modifing the voltage map entries and by calculating the set voltage back until I was able to forecast which voltage nvidia sets for a given voltage map entry. With these formulars I am able to precisely predict at which exact temperature Nvidia down- or upvolts due to a changed therm reading. That's why I am quite sure these are right, or at least really really close. v4: Use better coefficients and speedo. v5: Add error message when speedo is missing. Signed-off-by:
-
Karol Herbst authored
v5: Squashed speedo related commits. Signed-off-by:
-
Karol Herbst authored
Since gf100 we need a speedo value for calculating the voltage. The readout will be added in a later patch. Signed-off-by:
-
Karol Herbst authored
Depending on the value a different formular is used to calculated the voltage for this entry. Signed-off-by:
-
Karol Herbst authored
If we calculate the voltage in the table right, we get all kinds of values, which never fit the hardware steps, so we use the closest higher value the hardware can do. v3: Simplify the implementation. v5: Initialize best_err with volt->max_uv. Signed-off-by:
-
Karol Herbst authored
0: base clock from the vbios is max clock (default) 1: boost only to boost clock from the vbios 2: boost to max clock available v2: Moved into nvkm_cstate_valid. v4: Check the existence of the clocks before limiting. v5: Default to boost level 0. Signed-off-by:
-
Karol Herbst authored
This table contains three important clocks: base clock: This is the non boosted max clock. tdp clock: The clock at wich the vbios guarentees the TDP won't ever be exceeded at max load (seems to be always the same as the base clock, but behaves differently). boost clock: The avg clock the gpu will stay boosted to. It doesn't seem to affect the behaviour of the nvidia driver at all though. v2: Make clear that base/boost/tdp fields are ids. v5: Rename Base clock to vpstate. Make vbios pointers 32bit. Signed-off-by: -
Karol Herbst authored
We should never allow to select a cstate which current voltage (depending on the temperature) is higher than 1. the max volt entries in the voltage map table. 2. what tha gpu actually can volt to. v3: Use find_best for all cstates before actually trying. Add nvkm_cstate_get function to get cstate by index. v5: Cstates with voltages lower then min_uv are valid. Move nvkm_cstate_get into the previous commit. Signed-off-by: -
Karol Herbst authored
Now the cstatei parameter can be used of the nvkm_cstate_prog function to select a specific cstate. v5: Make a constant for the magic value. Use list_last_entry. Add nvkm_cstate_get here instead of in the next commit. Signed-off-by: -
Karol Herbst authored
The voltage entries actually may map to a different voltage depending on the current temperature. v2: Only read the temperature when actually needed. v5: Be smarter about using max(). Don't read the temperature anymore. Signed-off-by: -
Karol Herbst authored
This way other subdevs can notify the clk subdev about temperature changes without the need of clk to poll that value. Also make this function safe to be called from an interrupt handler. Signed-off-by:
-
Karol Herbst authored
It is better to read out the id out of the cstate struct directly instead of iterating over the list of cstates over and over again. Especially when we start saving pointers to a nvkm_cstate struct, it makes things easier. v5: Rename field to id. Signed-off-by:
-
Karol Herbst authored
Each pstate has its own voltage map entry like each cstate has. The voltages of those entries act as a floor value for the currently selected pstate and nvidia never sets a voltage below them. Signed-off-by:
-
Karol Herbst authored
There are at least three "max" entries, which specify the max voltage. Because they are actually normal voltage map entries, they can also be affected by the temperature. Nvidia respects those entries and if they get changed, nvidia uses the lower voltage from all three. We shouldn't exceed those voltages at any given time. v2: State what those entries do in the source. v3: Add the third max entry. v5: Better describe the entries. Signed-off-by:
-
Karol Herbst authored
nvkm_volt_map_min is a copy of nvkm_volt_map, which always returns the lowest possible voltage for a cstate. nvkm_volt_map will get a temperature parameter there later and also fix the voltage calculation, so that this functions will be completly different later. Signed-off-by:
Pierre Moreau <pierre.morrow@free.fr> Signed-off-by:
-
Karol Herbst authored
There is a field in the voltage table which tells us if the VIDs are taken from the entries or calculated through the header. v2: Don't break older versions. v5: Reverse flag name. Signed-off-by:
-
Karol Herbst authored
Some Fermi+ GPUs specify VID information via voltage table entries, rather than describing them as a range in the header. The mask may be bigger than 0x1fffff, but this value is already >2V, so it will be fine for now. This patch fixes volting issues on those cards enabling them to switch cstates. v6: rework message Signed-off-by:
-
Karol Herbst authored
Signed-off-by:
Aidan Epstein <aidan@jmad.org> Signed-off-by:
-
Karol Herbst authored
Signed-off-by:
-
Karol Herbst authored
Previously we parsed that table a bit wrong: 1. The entry layout depends on the sensor type used. 2. We have all resitors in one entry for the INA3221. 3. The config is already included in the vbios. This commit addresses that issue and with that we should be able to read out the right power consumption for every GPU with a INA209, INA219 and INA3221. Signed-off-by:
-
Ilia Mirkin authored
This can show up on SPARC or other architectures that don't handle unaligned accesses. The kernel normally fixes these up, but it shouldn't have to. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836Signed-off-by:
-
Alexandre Courbot authored
gk20a_ibus_init_ibus_ring() can be called from gk20a_ibus_intr(), in non-interruptible context. Replace use of usleep_range() with udelay(). Reported-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
- 11 Oct, 2016 2 commits
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Just flushing out my -misc queue. Slightly important are the prime refcount/unload fixes from Chris. There's also the reservation stuff from Chris still pending, and Sumits hasn't landed that yet. Might get another pull for that, but pls don't hold up the main pull for it ;-) * tag 'topic/drm-misc-2016-10-11' of git://anongit.freedesktop.org/drm-intel: drm/crtc: constify drm_crtc_index parameter drm: use the right function name in documentation drm: Release resources with a safer function drm: Fix up kerneldoc for new drm_gem_dmabuf_export() drm/bridge: Drop drm_connector_unregister and call drm_connector_cleanup directly drm/fb-helper: fix sphinx markup for DRM_FB_HELPER_DEFAULT_OPS drm/bridge: Add RGB to VGA bridge support drm/prime: Take a ref on the drm_dev when exporting a dma_buf drm/prime: Pass the right module owner through to dma_buf_export() drm/bridge: Call drm_connector_cleanup directly drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks drm: Release resources with a safer function
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel into drm-next A big bunch of i915 fixes for drm-next / v4.9 merge window, with more than half of them also cc: stable. We also continue to have more Fixes: annotations for our fixes, which should help the backporters and archeologists. * tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel: (27 commits) drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next drm/i915/guc: Unwind GuC workqueue reservation if request construction fails drm/i915: Reset the breadcrumbs IRQ more carefully drm/i915: Force relocations via cpu if we run out of idle aperture drm/i915: Distinguish last emitted request from last submitted request drm/i915: Allow DP to work w/o EDID drm/i915: Move long hpd handling into the hotplug work drm/i915/execlists: Reinitialise context image after GPU hang drm/i915: Use correct index for backtracking HUNG semaphores drm/i915: Unalias obj->phys_handle and obj->userptr drm/i915: Just clear the mmiodebug before a register access drm/i915/gen9: only add the planes actually affected by ddb changes drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED drm/i915/bxt: Fix HDMI DPLL configuration drm/i915/gen9: fix the watermark res_blocks value drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations drm/i915/gen9: minimum scanlines for Y tile is not always 4 drm/i915/gen9: fix the WaWmMemoryReadLatency implementation drm/i915/kbl: KBL also needs to run the SAGV code drm/i915: introduce intel_has_sagv() ...
-
- 10 Oct, 2016 11 commits
-
-
Jani Nikula authored
Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1476113170-13816-1-git-send-email-jani.nikula@intel.com
-
Chris Wilson authored
The conflict resolution of v4.8-rc8 backmerge to drm-next pulled back in a few lines of dead code due to the code movement around i915_gem_reset(), fix that up. Fixes: ca09fb9f ("Merge tag 'v4.8-rc8' into drm-next") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Chris Wilson authored
We reserve space in the GuC workqueue for submitting the request in the future. However, if we fail to construct the request, we need to give that reserved space back to the system. Fixes: dadd481b ("drm/i915/guc: Prepare for nonblocking execbuf submission") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-4-chris@chris-wilson.co.uk (cherry picked from commit 5ba89908) Signed-off-by:
-
Chris Wilson authored
Along with the interrupt, we want to restore the fake-irq and wait-timeout detection. If we use the breadcrumbs interface to setup the interrupt as it wants, the auxiliary timers will also be restored. v2: Cancel both timers as well, sanitize the IMR. Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-3-chris@chris-wilson.co.uk (cherry picked from commit ad07dfcd) Signed-off-by:
-
Chris Wilson authored
If we run out of enough aperture space to fit the entire object, we fallback to trying to insert a single page. However, if that also fails, we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means to userspace that their batch could not be fitted within the GTT.) Prior to commit e8cb909a ("drm/i915: Fallback to single page GTT mmappings for relocations") the approach is to fallback to using the slow CPU relocation path in case of iomapping failure, and that is the behaviour we need to restore. Fixes: e8cb909a ("drm/i915: Fallback to single page GTT mmappings...") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-2-chris@chris-wilson.co.uk (cherry picked from commit d7f76335) Signed-off-by:
-
Chris Wilson authored
In order not to trigger hangcheck on a idle-but-waiting engine, we need to distinguish between the pending request queue and the actual execution queue. This is done later in "drm/i915: Enable multiple timelines" but for now we need a temporary fix to prevent blaming the wrong engine for a GPU hang. (Note that this causes a temporary subtle change in how we decide when to allow a waitboost to be re-awarded back to the waiter, the temporary effect is that if the wait is upon the most current execution the wait is given for free, instead of checking to see if the client stalled itself. This will be repaired in "drm/i915: Enable multiple timelines".) Fixes: 0a046a0e ("drm/i915: Nonblocking request submission") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98104Signed-off-by:
-
Ville Syrjälä authored
Allow returning "connected" or "unknown" connector status for DP branch devices that don't have an EDID. Currently we'd claim the thing as "disconnected" if there is no EDID. This stuff used to broken already, I think, but it got more broken by commit f21a2198 ("drm/i915: Splitting intel_dp_detect") Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by:
Arno <blouin.arno@gmail.com> Fixes: f21a2198 ("drm/i915: Splitting intel_dp_detect") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> (cherry picked from commit 5cb651a7) Signed-off-by:
-
Ville Syrjälä authored
We can't rely on connector->status in the detect() hook if the long hpd was already handled by the dig_port_work as that won't update connector->status. Thus we have to defer the long hpd handling entirely until the hotplug work runs to avoid the double long hpd handling the "detect_done" flag is trying to prevent. We'll start to depend on connector->status being up to date in a following patch. Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by:
-
Chris Wilson authored
On Braswell, at least, we observe that the context image is written in multiple phases. The first phase is to clear the register state, and subsequently rewrite it. A GPU reset at the right moment can interrupt the context update leaving it corrupt, and our update of the RING_HEAD is not sufficient to restart the engine afterwards. To recover, we need to reset the registers back to their original values. The context state is lost. What we need is a better mechanism to serialise the reset with pending flushes from the GPU. Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
-
Chris Wilson authored
When decoding the semaphores inside hangcheck, we need to use the hw-id and not the local array index. Fixes: de1add36 ("drm/i915: Decouple execbuf uAPI ...") Testcase: igt/gem_exec_whisper/hang # gen6-7 Signed-off-by:
-
Chris Wilson authored
We use obj->phys_handle to choose the pread/pwrite path, but as obj->phys_handle is a union with obj->userptr, we then mistakenly use the phys_handle path for userptr objects within pread/pwrite. Testcase: igt/gem_userptr_blits/forbidden-operations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519Signed-off-by:
-
