- 17 12月, 2014 1 次提交
-
-
由 Ben Goz 提交于
This patch fixes a bug in kgd_set_pasid_vmid_mapping(), where the function only updated the ATC registers (IOMMU) with the new VMID <--> PASID mapping, but didn't update the IH (Interrupt) registers. The bug only occurs when using non-HWS mode. In HWS mode, the CP automatically does the VMID <--> PASID mapping. Signed-off-by: NBen Goz <ben.goz@amd.com> Signed-off-by: NOded Gabbay <oded.gabbay@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 04 1月, 2015 1 次提交
-
-
由 Alexey Khoroshilov 提交于
If timeout happens, kgd_hqd_destroy() just returns -ETIME leaving queue acquired. It may cause a deadlock, so the patch proposes to release queue before return. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
-
- 05 1月, 2015 1 次提交
-
-
由 Ben Goz 提交于
This patch fixes a bug in DQM, where the MQD of a newly created compute queue is not loaded to an HQD slot. As a result, the CP never reads packets from this queue. This bug happens only in non-HWS (hardware scheduling) mode. In HWS mode, the CP is responsible of loading MQDs to HQDs slots. Signed-off-by: NBen Goz <ben.goz@amd.com> Signed-off-by: NOded Gabbay <oded.gabbay@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 09 12月, 2014 1 次提交
-
-
由 Ben Goz 提交于
Signed-off-by: NBen Goz <ben.goz@amd.com> Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
-
- 29 12月, 2014 2 次提交
-
-
由 Oded Gabbay 提交于
This patch changes the radeon_kfd_init(), which is used to initialize the interface between radeon and amdkfd, so the interface will be initialized only if amdkfd was build, either as module or inside the kernel image. In the modules case, the symbol_request() will be used (same as old code). In the in-image compilation case, a direct call to kgd2kfd_init() will be done. For other cases, radeon_kfd_init() will just return false. This patch is necessary because in case of the following specific configuration: kernel 32-bit, no modules support, random kernel base and no hibernation, the symbol_request() doesn't work as expected - it doesn't return NULL if the symbol doesn't exists - which makes the kernel panic. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
-
由 Sasha Levin 提交于
Commit "amdkfd: use sizeof(long) granularity for the pasid bitmask" calculated the number of longs it will need, but ended up allocating that number of bytes rather than longs. Fix that silly error and allocate the amount of data really required. Signed-off-by: NSasha Levin <sasha.levin@oracle.com> Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
-
- 24 12月, 2014 1 次提交
-
-
由 Dave Airlie 提交于
This reverts commit 355a7018. This had some bad side effects under normal operation, and should have been dropped earlier. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 12月, 2014 1 次提交
-
-
由 Dave Airlie 提交于
nouveau userspace back at 1.0.1 used to call the X server DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts to map the sarea and fails if it can't. Since 884c6dab from Daniel, this fails, but only ancient drivers would see it. Revert the nouveau bits of that fix. Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 3.18 Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 21 12月, 2014 1 次提交
-
-
由 Oded Gabbay 提交于
When amdkfd and radeon are compiled inside the kernel image (not as modules), radeon will load before amdkfd, which will cause a bug when radeon will probe the GPUs. When the two drivers are compiled as modules, amdkfd is loaded after radeon is loaded but before radeon starts probing the GPUs. This is done because radeon loads the amdkfd module through symbol_request function. This patch makes amdkfd load before radeon when they are both compiled inside the kernel image, which makes the behavior similar to the case when they are modules, and prevents the kernel bug. Signed-off-by: NOded Gabbay <oded.gabbay@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
- 19 12月, 2014 4 次提交
-
-
由 Jilai Wang 提交于
Disable the HPD interrupt when acking it, to avoid spurious interrupt. Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>
-
由 Jilai Wang 提交于
HPD regulators need to be enabled before clocks, otherwise clock driver will report warning. Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>
-
由 Rob Clark 提交于
If crtc <-> encoder linkage changes, we could end up with the CRTC listening for the wrong error or vsync irqs. Generally this problem would correct itself relatively quickly, since we update the global irqmask after dispatching irqs, but to be sure let the CRTC trigger update_irq(). Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
We can't have multiple updates pending on a given CRTC, and we don't want a sync update to race w/ an async update that preceeded it. So keep track of which CRTCs have updates in flight, and block later updates that would conflict. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 18 12月, 2014 5 次提交
-
-
由 Imre Deak 提交于
Without this RPM ref we can hit the device suspended WARN via: i915_gem_object_pin()->ggtt_bind_vma->gen6_ggtt_insert_entries(). I noticed this on my BYT while keeping the i915 device in runtime suspended state for a while. I chose this place to take the ref to avoid the possible deadlock via the mutex_lock taken both later in this function and in the runtime suspend handler. This can happen if an RPM suspend event is queued and need to be flushed before taking the RPM ref. Testcase: igt/pm_rpm/gem-evict-pwrite Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87363Signed-off-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
The VGA_2X_MODE bit apparently affects the display even when the VGA plane is disabled. The bit will set by the BIOS when the panel width is at least 1280 pixels. So by preserving the bit from the BIOS we end up with corrupted display on machines with such high res panels. I only have 1024x768 panels on my gen2 machines so never ran into this problem. The original reason for preserving the VGACNTR register was to make my 830 survive S3 with acpi_sleep=s3_bios option. However after further 830 fixes that option is no longer needed to make S3 work and preserving VGACNTR doesn't seem to be necessary without it, so we can just revert the entire patch. This reverts commit 69769f9a Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Aug 15 01:22:08 2014 +0300 drm/i915: Preserve VGACNTR bits from the BIOS Cc: Bruno Prémont <bonbons@linux-vserver.org> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That means if we first call intel_prepare_page_flip() but don't call intel_finish_page_flip(), the next stall check will erroneosly think the page flip was somehow stuck. With enough debug spew emitted from the interrupt handler my 830 hangs when this happens. My theory is that the previous vblank interrupt gets sufficiently delayed that the handler will see the pending bit set in IIR, but ISR still has the bit set as well (ie. the flip was processed by CS but didn't complete yet). In this case the handler will proceed to call intel_check_page_flip() immediately after intel_prepare_page_flip(). It then tries to print a backtrace for the stuck flip WARN, which apparetly results in way too much debug spew delaying interrupt processing further. That then seems to cause an endless loop in the interrupt handler, and the machine is dead until the watchdog kicks in and reboots. At least limiting the number of iterations of the loop in the interrupt handler also prevented the hang. So it seems better to not call intel_prepare_page_flip() without immediately calling intel_finish_page_flip(). The IIR/ISR trickery avoids races here so this is a perfectly safe thing to do. v2: Fix typo in commit message (checkpatch) Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
pps_{lock,unlock}() call intel_display_power_{get,put}() outside pps_mutes to avoid deadlocks with the power_domain mutex. In theory during aux transfers we should usually have the relevant power domain references already held by some higher level code, so this should not result in much overhead (exception being userspace i2c-dev access). However thanks to the check_power_well() calls in intel_display_power_{get/put}() we end up doing a few Punit reads for each aux transfer. Obviously doing this for each byte transferred via i2c-over-aux is not a good idea. I can't think of a good way to keep check_power_well() while eliminating the overhead, so let's just remove check_power_well() entirely. Fixes a driver init time regression introduced by: commit 773538e8 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:56 2014 +0300 drm/i915: Reset power sequencer pipe tracking when disp2d is off Credit goes to Jani for figuring this out. v2: Add the regression note in the commit message. Cc: stable@vger.kernel.org (v3.18+) Cc: Egbert Eich <eich@suse.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201Tested-by: NWendy Wang <wendy.wang@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Rob Clark 提交于
When a plane is being enabled, plane->crtc has not been set yet. Use plane->state->crtc. Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 12月, 2014 10 次提交
-
-
由 Markus Elfring 提交于
The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Markus Elfring 提交于
The functions framebuffer_release() and vunmap() perform also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Sean Paul 提交于
In finish pageflip, the driver was not selecting the root window when dispatching events. This exposed a race where a plane update would change the window selection and cause tegra_dc_finish_page_flip to check the wrong base address. This patch also protects access to the window selection register as well as the registers affected by it. Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
If the requested buffer size wasn't a multiple of the page size, the IOMMU code would round down the size to the next multiple of the page size, thereby causing translation errors. To fix this we no longer pass around the requested size but reuse the computed size of the GEM object. This is already rounded to the next page boundary, so mapping that size works out fine. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Buffers obtained via shmem may still have associated cachelines. If they aren't properly flushed they may cause framebuffer corruption if the cache gets flushed after the application has drawn to it. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Page-flip completion could race with page-flip submission, so extend the critical section to include all accesses to page-flip related data. Reported-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
The hardware pipe numbers don't always match the DRM CRTC indices. This can happen for example if the first display controller defers probe, causing it to be registered with DRM after the second display controller. When that happens the hardware pipe numbers and DRM CRTC indices become different. Make sure that the CRTC index is always used when accessing per-CRTC VBLANK data. This can be ensured by using the drm_crtc_vblank_*() API, which will do the right thing automatically given a struct drm_crtc *. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
This function is the KMS native variant of drm_vblank_count(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
This function is the KMS native variant of drm_handle_vblank(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
This function is the KMS native variant of drm_send_vblank_event(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 16 12月, 2014 5 次提交
-
-
由 Chris Wilson 提交于
There exists a current workaround to prevent a hang on context switch should the ring go to sleep in the middle of the restore, WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In spite of disabling arbitration (which prevents the ring from powering down during the critical section) we were still hitting hangs that had the hallmarks of the known erratum. That is we are still seeing hangs "on the last instruction in the context restore". By comparing -nightly (broken) with requests (working), we were able to deduce that it was the semaphore LRI cross-talk that reproduced the original failure. The key was that requests implemented deferred semaphore signalling, and disabling that, i.e. emitting the semaphore signal to every other ring after every batch restored the frequent hang. Explicitly disabling PSMI sleep on the RCS ring was insufficient, all the rings had to be awake to prevent the hangs. Fortunately, we can reduce the wakelock to the MI_SET_CONTEXT operation itself, and so should be able to limit the extra power implications. Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above products, we should apply this extra hammer for all of the same platforms despite so far that we have only been able to reproduce the hang on certain ivb and hsw models. The last question is whether we want to always use the extra hammer or only when we know semaphores are in operation. At the moment, we only use LRI on non-RCS rings for semaphores, but that may change in the future with the possibility of reintroducing this bug under subtle conditions. v2: Make it explicit that the PSMI LRI are an extension to the original workaround for the other rings. v3: Bikeshedding variable names and whitespacing Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677 Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Tested-by: NPeter Frühberger <fritsch@xbmc.org> Reviewed-by: NDaniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
In order to act as a full command barrier by itself, we need to tell the pipecontrol to actually stall the command streamer while the flush runs. We require the full command barrier before operations like MI_SET_CONTEXT, which currently rely on a prior invalidate flush. References: https://bugs.freedesktop.org/show_bug.cgi?id=83677 Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
In the gen7 pipe control there is an extra bit to flush the media caches, so let's set it during cache invalidation flushes. v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec. Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
Atm, we don't disable RPS interrupts and related work items before resetting the GPU. This may interfere with the following GPU initialization and cause RPS interrupts to show up in PM_IIR too early before calling gen6_enable_rps_interrupts() (triggering a WARN there). Solve this by disabling RPS interrupts and flushing any related work items before resetting the GPU. v2: - split out the common parts of the gt suspend and the new gt reset functions (Paulo) v3: - remove the check for UMS, it's a NOP nowadays (Daniel) Reported-by: NHe, Shuang <shuang.he@intel.com> Testcase: igt/gem_reset_stats/ban-render Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86644Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
Paulo noticed that we don't enable RPS interrupts via PM_IER in gen6_enable_rps_interrupts(). This wasn't a problem so far, since the only place we disabled RPS interrupts was during system/runtime suspend and after that we reenable all interrupts in the IRQ pre/postinstall hooks. In the next patch we'll disable/reenable RPS interrupts during GPU reset too, but not call IRQ uninstall, pre/postinstall hooks, so there the above wouldn't work. The logical place for programming PM_IER is gen6_enable_rps_interrupts() and this also makes the function more symmetric with gen6_disable_rps_interrupts(), so move the programming there from the postinstall hooks. Note that these changes don't affect the ILK RPS interrupt code, which could be sanitized in a similar way. But that can be done as a follow-up. Credits-to: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 15 12月, 2014 1 次提交
-
-
When compiling in module some symbol aren't missing, export them correctly. Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 11 12月, 2014 6 次提交
-
-
由 Imre Deak 提交于
irq_mask should include all IRQ bits that we want to mask, but atm we set it incorrectly to the inverse of this. If the mask is used subsequently to enable/disable some IRQ bits, we may unintentionally unmask unrelated IRQs. I can't see any way that this can lead to a real problem in the current -nightly code, since the first place the mask will be used next (after a suspend/resume cycle) is in valleyview_irq_postinstall(), but the mask is reset there to its proper value. This causes a problem in the upstream kernel though, where - due to another issue - the mask is used in the above way to disable only the display IRQs. This other issue is fixed by: commit 950eabaf Author: Imre Deak <imre.deak@intel.com> Date: Mon Sep 8 15:21:09 2014 +0300 drm/i915: vlv: fix display IRQ enable/disable Interestingly, even with the above two bugs, we shouldn't in theory have any real problems (arguably a famous last sentence:). That's because even if we unmask something unintentionally via the VLV_IMR/VLV_IER register the master IRQ masking bit in VLV_MASTER_IER is still set and should prevent all i915 interrupts. According to my testing on an ASUS T100 with DSI output this isn't the case at least with the MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as shown in the bugzilla ticket below. This fix should get rid of the problem reported there in upstream and older kernels. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920 Cc: stable@vger.kernel.org (v3.15+) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jesse Barnes 提交于
Should probably just init this in the GMbus code all the time, based on the cdclk and HPLL like we do on newer platforms. Ville has code for that in a rework branch, but until then we can fix this bug fairly easily. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NNikolay <mar.kolya@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Benjamin Gaignard 提交于
When bind failed make sure that CRTC and planes are completely clean up to avoid properties duplication. Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
-
由 Benjamin Gaignard 提交于
High Quality Video Data Plane is hardware IP dedicated to video rendering. Compare to GPD (graphic planes) it have better scaler capabilities. HQVDP use VID layer to push data into hardware compositor without going into DDR. From data flow point of view HQVDP and VID are nested so HQVPD update/disable VID. Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
-
由 Benjamin Gaignard 提交于
stih407 SoC have a dedicated hardware cursor plane, this patch enable it. The hardware have a color look up table, fix it to be able to use ARGB8888. Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
-
由 Benjamin Gaignard 提交于
For stih407 SoC enable the second mixer to get two CRTC. Allow GPD planes and encoders to be connected to this new CRTC. Cursor plane can only be set on first CRTC. GPD clocks needed change the parent clock depending on which CRTC GPD are used. Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
-