- 08 Mar, 2017 4 commits
-
-
Ville Syrjälä authored
printks are slow so we should not be doing them from the vblank evade critical section. These could explain why we sometimes seem to blow past our 100 usec deadline. The problem has been there ever since commit bfd16b2a ("drm/i915: Make updating pipe without modeset atomic.") but it may not have been readily visible until commit e1edbd44 ("drm/i915: Complain if we take too long under vblank evasion.") increased our chances of noticing it. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: bfd16b2a ("drm/i915: Make updating pipe without modeset atomic.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307205419.19447-1-ville.syrjala@linux.intel.comReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Daniel Vetter authored
Backmerge drm-next to get at all the good stuff in drm-misc. We need that because: - drm_connector_list_iter conversion for i915 needs the core patches. - Maarten's patches to use the new atomic state iterators also need the core patches. - We need the new link status property to complete the DP retraining work, merging through 2 branches wasn't a good idea and we had to partially backtrack. - Chris needs reservation_object_trylock and we want to roll out kref_read everywhere. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
git://github.com/skeggsb/linuxDave Airlie authored
- Re-architecture of the code to handle proprietary fw, more abstracted to support the multitude of differences that NVIDIA introduce - Support in the said code for GP10x ACR and GR fw, giving acceleration support \o/ - Fix for GTX 970 GPUs that are in an odd MMU configuration * 'linux-4.12' of git://github.com/skeggsb/linux: (60 commits) drm/nouveau/fb/gf100-: rework ram detection drm/nouveau/fb/gm200: split ram implementation from gm107 drm/nouveau/fb/gf108: split implementation from gf100 drm/nouveau/fb/gf100-: modify constructors to allow more customisation drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm drm/nouveau/i2c/g94-: return REPLY_M value on reads drm/nouveau/i2c: modify aux interface to return length actually transferred drm/nouveau/gp10x: enable secboot and GR drm/nouveau/gr/gp102: initial support drm/nouveau/falcon: support for gp10x msgqueue drm/nouveau/secboot: add gp102/gp104/gp106/gp107 support drm/nouveau/secboot: put HS code loading code into own file drm/nouveau/secboot: support for r375 ACR drm/nouveau/secboot: support for r367 ACR drm/nouveau/secboot: support for r364 ACR drm/nouveau/secboot: workaround bug when starting SEC2 firmware drm/nouveau/secboot: support standard NVIDIA HS binaries drm/nouveau/secboot: support for unload blob bootloader drm/nouveau/secboot: let callers interpret return value of blobs drm/nouveau/secboot: support for different load and unload falcons ...
-
git://anongit.freedesktop.org/git/drm-intelDave Airlie authored
4 weeks worth of stuff since I was traveling&lazy: - lspcon improvements (Imre) - proper atomic state for cdclk handling (Ville) - gpu reset improvements (Chris) - lots and lots of polish around fences, requests, waiting and everything related all over (both gem and modeset code), from Chris - atomic by default on gen5+ minus byt/bsw (Maarten did the patch to flip the default, really this is a massive joint team effort) - moar power domains, now 64bit (Ander) - big pile of in-kernel unit tests for various gem subsystems (Chris), including simple mock objects for i915 device and and the ggtt manager. - i915_gpu_info in debugfs, for taking a snapshot of the current gpu state. Same thing as i915_error_state, but useful if the kernel didn't notice something is stick. From Chris. - bxt dsi fixes (Umar Shankar) - bxt w/a updates (Jani) - no more struct_mutex for gem object unreference (Chris) - some execlist refactoring (Tvrtko) - color manager support for glk (Ander) - improve the power-well sync code to better take over from the firmware (Imre) - gem tracepoint polish (Tvrtko) - lots of glk fixes all around (Ander) - ctx switch improvements (Chris) - glk dsi support&fixes (Deepak M) - dsi fixes for vlv and clanups, lots of them (Hans de Goede) - switch to i915.ko types in lots of our internal modeset code (Ander) - byt/bsw atomic wm update code, yay (Ville) * tag 'drm-intel-next-2017-03-06' of git://anongit.freedesktop.org/git/drm-intel: (432 commits) drm/i915: Update DRIVER_DATE to 20170306 drm/i915: Don't use enums for hardware engine id drm/i915: Split breadcrumbs spinlock into two drm/i915: Refactor wakeup of the next breadcrumb waiter drm/i915: Take reference for signaling the request from hardirq drm/i915: Add FIFO underrun tracepoints drm/i915: Add cxsr toggle tracepoint drm/i915: Add VLV/CHV watermark/FIFO programming tracepoints drm/i915: Add plane update/disable tracepoints drm/i915: Kill level 0 wm hack for VLV/CHV drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun drm/i915: Sanitize VLV/CHV watermarks properly drm/i915: Only use update_wm_{pre,post} for pre-ilk platforms drm/i915: Nuke crtc->wm.cxsr_allowed drm/i915: Compute proper intermediate wms for vlv/cvh drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed drm/i915: Compute vlv/chv wms the atomic way drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks drm/i915: Plop vlv/chv fifo sizes into crtc state drm/i915: Plop vlv wm state into crtc_state ...
-
- 07 Mar, 2017 36 commits
-
-
Chris Wilson authored
Before we instantiate/pin the backing store for our use, we can prepopulate the shmemfs filp efficiently using a write into the pagecache. We avoid the penalty of instantiating all the pages, important if the user is just writing to a few and never uses the object on the GPU, and using a direct write into shmemfs allows it to avoid the cost of retrieving a page (mostly the clear-before-use, but in theory we could curtail swapin) before it is overwritten. This can be extended later to provide additional specialisation for other backends (other than shmemfs). For now it provides a defense against very large write-only allocations from exhausting all of system memory. v2: Smelling fixes. Fixes: fe115628 ("drm/i915: Implement pwrite without struct-mutex") References: https://bugs.freedesktop.org/show_bug.cgi?id=99107Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.10+ Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307120338.7277-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Once the object has been truncated, it is unrecoverable. To facilitate detection of this state store the error in obj->mm.pages. This is required for the next patch which should be applied to v4.10 (via stable), so we also need to mark this patch for backporting. In that regard, let's consider this to be a fix/improvement too. v2: Avoid dereferencing the ERR_PTR when freeing the object. Fixes: 1233e2db ("drm/i915: Move object backing storage manipulation to its own locking") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.10+ Link: http://patchwork.freedesktop.org/patch/msgid/20170307132031.32461-1-chris@chris-wilson.co.ukReviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Paulo Zanoni authored
Move the {skl,bxt}_{i,uni}nit_cdclk declarations to the place where the intel_cdclk.c functions are declared since these functions have moved there. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487712207-17181-1-git-send-email-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
The IS_G4X macro is defined as IS_G45 || IS_GM45. We have two points in our code where we have an if statement checking for GM45 followed by an else if statement checking for IS_G4X. This can be confusing since the IS_G4X check won't be catching the previously-checked GM45. Someone quickly trying to check which functions run on each platform may end up getting confused while reading the code. Fix the potential confusion by limiting the else if statements to only check for the platform that was not already checked earlier in the if ladder. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487620842-22893-3-git-send-email-paulo.r.zanoni@intel.com
-
Chris Wilson authored
In order for the missed-irq update to take effect, the device must be idle. So when the user updates the fault injection via debugfs, idle the device. v2: Idle is explicitly required for setting test_irq, and good behaviour for clearing the missed_irq. v3: Use matching types; expanding to more than ulong rings is left as an exercise to the reader. Testcase: igt/drv_missed_irq Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307155908.14576-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
No functional changes. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/fadc3b0de70d2c7db7a6ecbe7121328483330f04.1488810382.git.jani.nikula@intel.com
-
Jani Nikula authored
Emphasize that the VBT file is nowadays more about initializing and running stuff based on the VBT contents, not so much about being a "panel driver". No functional changes. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/b13cb012a555ff5eb56b5e4bb2b0205c3e025a99.1488810382.git.jani.nikula@intel.com
-
Jani Nikula authored
The hook names reflect more the phase in the mode set sequence the hooks are called in than what they actually do in terms of the specific encoder. Stick to that scheme, and rename intel_dsi_pre_disable to intel_dsi_disable. Unify the comments around this while at it. No functional changes. v2: Add more sense in the enable/disable hook comments (Ville) Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1488878659-10386-1-git-send-email-jani.nikula@intel.com
-
Jani Nikula authored
Use the prefix intel_dsi_vbt for all the DSI VBT functions. No functional changes. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/0a05abca364f3bc7f9caf90c9bd3a68eef5f222f.1488810382.git.jani.nikula@intel.com
-
Jani Nikula authored
Now that we've stopped using the drm_panel hooks, there aren't any benefits left with using the drm_panel framework. Remove the rest of the drm_panel use. No functional changes. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/6602e36641451952065092401bd6e6cfbe93e208.1488810382.git.jani.nikula@intel.com
-
Jani Nikula authored
Commit 18a00095 ("drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences") started calling the VBT sequence functions directly instead of using the drm_panel hooks. Remove the last drm_panel hook by calling vbt_panel_get_modes() directly. No functional changes. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/63d0d41f29583507f5968b42b5f52e6574a1f245.1488810382.git.jani.nikula@intel.com
-
Jani Nikula authored
Fact is, there are no other panel drivers except the VBT based one. Simplify the code and maintenance. No functional changes. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7dfd041dd25e8e930150ede09589bb232f6248d5.1488810382.git.jani.nikula@intel.com
-
Chris Wilson authored
To prevent having to preserve the drm_crtc_state as we clear the intel_crtc_state, only memset our extended state. Fixes: drivers/gpu/drm/i915/intel_display.c: In function ‘clear_intel_crtc_state’: drivers/gpu/drm/i915/intel_display.c:11301:1: error: the frame size of 1056 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] v2: Add a comment and BUILD_BUG_ON to explain the memset() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170303154644.6709-1-chris@chris-wilson.co.ukReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Anusha Srivatsa authored
There is a nre version of DMC available for GLK. The release notes mentions: This FW has the fix to remove the hang conditions due to some debug related issues. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487793336-31857-1-git-send-email-anusha.srivatsa@intel.com
-
Tvrtko Ursulin authored
It is called from either the process or timer context so it is correct to always disable interrupts. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170306150321.29024-1-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
Timer callback is a known context so it is correct to always disable interrupts. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Tvrtko Ursulin authored
It is always called from thread context. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Ben Skeggs authored
This commit reworks the RAM detection algorithm, using RAM-per-LTC to determine whether a board has a mixed-memory configuration instead of using RAM-per-FBPA. I'm not certain the algorithm is perfect, but it should handle all currently known configurations in the very least. This should fix GTX 970 boards with 4GiB of RAM where the last 512MiB isn't fully accessible, as well as only detecting half the VRAM on GF108 boards. As a nice side-effect, GP10x memory detection now reuses the majority of the code from earlier chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
GF108/GM107 implementations will want slightly different functions for the upcoming RAM detection improvements. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
I'm not entirely sure NVKM needs to support this now, but I haven't removed it as of yet just in case it's needed from DEVINIT scripts where DRM isn't available. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This value represents the actual number of bytes recieved on the AUX channel as the result of a read transaction. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Apparently sinks are allows to respond with ACK even if they didn't fully complete a transaction... It seems like a missed opportunity for DEFER to me, but what do I know :) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
All the bricks are in place for secure boot to be enabled. This in turn makes GR usable so enable them all. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Differences from GP100: - 3 PPCs/GPC. - Another random reg to calculate/write. - Attrib CB setup a little different. - PascalB - PascalComputeB Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
Add support for the msgqueue firmware used to process SEC2 commands for gp10x chips. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
These gp10x chips are supporting using (roughly) the same firmware. Compared to previous secure chips, ACR runs on SEC2 and so does the low-secure msgqueue. ACR for these chips is based on r367. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
We will also need to load HS blobs outside of acr_r352 (for instance, to run the NVDEC VPR scrubber), so make this code reusable. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
r375 ACR uses a unified bootloader descriptor for the GR and PMU firmwares. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
r367 uses a different hsflcn_desc layout and LS firmware signature format, requiring a rewrite of some functions. It also makes use of the shadow region, and uses SEC as the boot falcon. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
r364 is similar to r361, but uses a different hsflcn_desc structure to introduce the shadow region address (even though it is not yet used by this version). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
For some unknown reason the LS SEC2 firmware needs to be started twice to operate. Detect and address that condition. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
I had the brilliant idea to "improve" the binary format by removing a useless indirection in the HS binary files. In the end it just makes things more complicated than they ought to be as NVIDIA-provided files need to be adapted. Since the format used can be identified by the header, support both. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
If the load and unload falcons are different, then a different bootloader must also be used. Support this case. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
Since the HS blobs are provided and signed by NVIDIA, we cannot expect always-consistent behavior. In this case, on GP10x the unload blob may return 0x1d even though things have run perfectly well. This behavior has been confirmed by NVIDIA. So let the callers of the run_blob() hook receive the blob return's value (a positive integer) and decide what it means. This allows us to workaround the 0x1d code instead of issuing an error. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-