- 03 10月, 2015 5 次提交
-
-
由 Grazvydas Ignotas 提交于
There doesn't seem to be any need to have 'ib' volatile, the code is not even consistent with it and some places already miss it. As it is now it's just making gcc produce worse code. If there are special requirements for that memory, then proper primitives like memory barriers or accessor functions should be used, but it doesn't look like that is needed here. While at it, change the type to match the one in radeon_ib structure. Reviewed-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Grazvydas Ignotas 提交于
After this patch the register check loop does the same thing as before, except that now gcc does better job optimizing it: it now sees that end_reg was already checked against PACKET3_SET_CONTEXT_REG_END and can optimize REG_SAFE_BM_SIZE comparison out of evergreen_is_safe_reg() as (PACKET3_SET_CONTEXT_REG_END >> 7) < REG_SAFE_BM_SIZE. Reviewed-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Grazvydas Ignotas 提交于
evergreen_cs_check_reg() is a large function and gcc doesn't want to inline it. It has a quick check for reg_safe_bm[] to see if register needs special handling, which often results in early exit. However because the function is large, it has a long prologue/epilogue to save/restore all the callee-save registers which according to perf is taking significant amount of time. To avoid this, we can reuse evergreen_is_safe_reg() to do the early check directly in register loop. Reviewed-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Grazvydas Ignotas 提交于
To avoid having to distinguish between CAYMAN or older on every register check, place a pointer in evergreen_cs_track and use it unconditionally. Also make use of the fact that both reg_safe_bm[] arrays are of the same length to remove another CAYMAN check. Reviewed-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lukas Wunner 提交于
Currently everyone and their dog has their own favourite spelling for vga_switcheroo. This makes it hard to grep dmesg for log entries relating to vga_switcheroo. It also makes it hard to find related source files in the tree. vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 25 9月, 2015 2 次提交
-
-
由 Ville Syrjälä 提交于
linedur_ns, and especially pixeldur_ns are becoming rather inaccurate to be used for the vblank timestamp correction. With 4k@60 the pixel duration is already below 2ns, so the amount of error due to the truncation to nanoseconds is introducing quite a bit of error. We can avoid such problems if we instead calculate the timestamp delta_ns directly from the dislay timings, avoiding the use of these intermediate truncated values. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in fixup from Thierry Reding for amdgpu.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Collect the timestamping constants alongside the rest of the relevant stuff under drm_vblank_crtc. We can now get rid of the 'refcrtc' parameter to drm_calc_vbltimestamp_from_scanoutpos(). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 9月, 2015 2 次提交
-
-
由 Maxim Sheviakov 提交于
Just adds the quirk for MSI R7 370 Armor 2X Bug: https://bugs.freedesktop.org/show_bug.cgi?id=91294Signed-off-by: NMaxim Sheviakov <mrader3940@yandex.ru> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Daniel Vetter 提交于
In commit 7a3f3d66 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 9 23:44:28 2015 +0200 drm: Check locking in drm_for_each_connector I added locking checks to drm_for_each_connector but failed that through drm_helper_connector_dpms -> drm_helper_choose_encoder_dpms it's used in a few more places in the radeon resume/suspend code. Fix them up. Note that we could use the connector iterator macros in there too, but that's for the future. Reported-and-tested-by: NBorislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 09 9月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
When we get an i2c defer or short ack for i2c-over-aux write we need to switch to WRITE_STATUS_UPDATE to poll for the completion of the original request. Looks like radeon doesn't do anything special with the request type, so hopefully just treating it the same as a i2c write is enough. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 03 9月, 2015 1 次提交
-
-
由 Jeffery Miller 提交于
With the radeon driver loaded the HP Compaq dc5750 Small Form Factor machine fails to resume from suspend. Adding a quirk similar to other devices avoids the problem and the system resumes properly. Signed-off-by: NJeffery Miller <jmiller@neverware.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 31 8月, 2015 2 次提交
-
-
由 Alex Deucher 提交于
AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Port of: drm/radeon/atom: Send out the full AUX address to radeon non-atom aux path Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Ville Syrjälä 提交于
AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 29 8月, 2015 1 次提交
-
-
由 Alex Deucher 提交于
Support for output_csc is only available on DCE5 and newer so don't mess with the HDMI quantization_range on pre-DCE5 asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=83226Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 22 8月, 2015 1 次提交
-
-
由 Stephen Chandler Paul 提交于
Most of the time this isn't an issue since hotplugging an adaptor will trigger a crtc mode change which in turn, causes the driver to probe every DisplayPort for a dpcd. However, in cases where hotplugging doesn't cause a mode change (specifically when one unplugs a monitor from a DisplayPort connector, then plugs that same monitor back in seconds later on the same port without any other monitors connected), we never probe for the dpcd before starting the initial link training. What happens from there looks like this: - GPU has only one monitor connected. It's connected via DisplayPort, and does not go through an adaptor of any sort. - User unplugs DisplayPort connector from GPU. - Change in HPD is detected by the driver, we probe every DisplayPort for a possible connection. - Probe the port the user originally had the monitor connected on for it's dpcd. This fails, and we clear the first (and only the first) byte of the dpcd to indicate we no longer have a dpcd for this port. - User plugs the previously disconnected monitor back into the same DisplayPort. - radeon_connector_hotplug() is called before everyone else, and tries to handle the link training. Since only the first byte of the dpcd is zeroed, the driver is able to complete link training but does so against the wrong dpcd, causing it to initialize the link with the wrong settings. - Display stays blank (usually), dpcd is probed after the initial link training, and the driver prints no obvious messages to the log. In theory, since only one byte of the dpcd is chopped off (specifically, the byte that contains the revision information for DisplayPort), it's not entirely impossible that this bug may not show on certain monitors. For instance, the only reason this bug was visible on my ASUS PB238 monitor was due to the fact that this monitor using the enhanced framing symbol sequence, the flag for which is ignored if the radeon driver thinks that the DisplayPort version is below 1.1. Signed-off-by: NStephen Chandler Paul <cpaul@redhat.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 21 8月, 2015 1 次提交
-
-
由 Dave Airlie 提交于
We apparantly get a hotplug irq before we've initialised modesetting, [drm] Loading R100 Microcode BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91 *pde = 00000000 Oops: 0002 [#1] Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf674028 #111 Hardware name: MicroLink /D850MV , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003 Workqueue: events radeon_hotplug_work_func [radeon] task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000 EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0 EIP is at __mutex_lock_slowpath+0x23/0x91 EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0 Stack: f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940 Call Trace: [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7 [<c125f162>] ? mutex_lock+0x9/0xa [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon] [<c1034741>] ? process_one_work+0xfc/0x194 [<c1034b58>] ? worker_thread+0x18d/0x218 [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5 [<c103742a>] ? kthread+0x7b/0x80 [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30 [<c10373af>] ? init_completion+0x18/0x18 Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63 Reported-and-Tested-by: NMeelis Roos <mroos@linux.ee> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 18 8月, 2015 2 次提交
-
-
由 Daniel Vetter 提交于
We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock and rdev->ring_lock), adding another global mutex won't serialize this code more. And since there's really nothing interesting that gets protected in radeon by dev->struct mutex (we only have the global z buffer owners and it's still serializing gem bo destruction in the drm core - which is irrelevant since radeon uses ttm anyway internally) this doesn't add protection. Remove it. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Daniel Vetter 提交于
It really doesn't protect anything which doesn't have other locks already. Also this is run from driver unload code so not much need for locks anyway. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 17 8月, 2015 1 次提交
-
-
由 Alex Deucher 提交于
This allows you to send different audio to each audio capable display. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 06 8月, 2015 1 次提交
-
-
由 Archit Taneja 提交于
Use the newly created wrapper drm_fb_helper functions instead of calling core fbdev functions directly. They also simplify the fb_info creation. v3: - Don't touch remove_conflicting_framebuffers v2: - Fix build break because of missing include of drm_fb_helper in radeon_drv.c Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 7月, 2015 3 次提交
-
-
由 Alex Deucher 提交于
Fixes a broken hsync start value uncovered by: abc0b144 (drm: Perform basic sanity checks on probed modes) The driver handled the bad hsync start elsewhere, but the above commit prevented it from getting added. bug: https://bugs.freedesktop.org/show_bug.cgi?id=91401Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Need to setup the deep color and avi packets regardless of audio setup. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
1. Always assign audio function pointers even if the display does not support audio. We need to properly disable the audio stream when when using a non-audio capable monitor. Fixes purple line on some hdmi monitors. 2. Check if a pin is in use by another encoder before disabling it. v2: make sure we've fetched the edid before checking audio and look up the encoder before calling audio_detect since connector->encoder may not be assigned yet. Separate pin and afmt. They are allocated at different times and have no dependency on eachother. v3: fix connector fetching in encoder functions v4: fix missed dig->pin check in dce6_afmt_write_latency_fields bugs: https://bugzilla.kernel.org/show_bug.cgi?id=93701 https://bugzilla.redhat.com/show_bug.cgi?id=1236337 https://bugs.freedesktop.org/show_bug.cgi?id=91041Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 27 7月, 2015 1 次提交
-
-
由 Maarten Lankhorst 提交于
This is required to properly handle failing dpms calls. When making a wait in i915 interruptible, I've noticed that the dpms sequence could fail with -ERESTARTSYS because it was waiting interruptibly for flips. So from now on allow drivers to fail in their connector dpms callback. Encoder and crtc dpms callbacks are unaffected. Changes since v1: - Update kerneldoc for the drm helper functions. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Resolve conflicts due to different merge order.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 7月, 2015 2 次提交
-
-
由 Daniel Vetter 提交于
Two nice things here: - drm_dev_register will truly register everything in the right order if the driver doesn't have a ->load callback. Before this we had to init the primary mode_group after the device nodes where already registered. - Less things to keep track of when reworking the connector locking, yay! Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
Similar with the i915 take all modeset locks for mst hotplug. This is needed to make sure radeon holds both mode_config.mutex and mode_config.connection_mutex when updating the connector_list, which is the new (interim) locking regime we want for that. Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 20 7月, 2015 1 次提交
-
-
由 Oded Gabbay 提交于
This patch splits the KGD_ENGINE_SDMA to KGD_ENGINE_SDMA1 and KGD_ENGINE_SDMA2 to match CZ definitions. Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
-
- 17 7月, 2015 4 次提交
-
-
由 Alex Deucher 提交于
This has been a source of confusion. Make it debug only. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Christian König 提交于
Port of amdgpu patch 9298e52f. Signed-off-by: NChristian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Michel Dänzer 提交于
This can be the case when the GPU is powered off, e.g. via vgaswitcheroo or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin flushes the TLB after setting rdev->gart.ptr to non-NULL. Fixes panic on powering off R7xx GPUs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 09 7月, 2015 9 次提交
-
-
由 Alex Deucher 提交于
Cayman does not have vce. There were a few places in the shared cayman/TV code where we were trying to do vce stuff. v2: remove -ENOENT check Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Otherwise we try to clear BO_VAs without an address. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91141Signed-off-by: NChristian König <christian.koenig@amd.com> Test-by: hadack@gmx.de Tested-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
We need to allways add the VM clear duplicate of the BO_VA, no matter what the old status was. Signed-off-by: NChristian König <christian.koenig@amd.com> Test-by: hadack@gmx.de Tested-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This reverts commit ac913490. We've fixed the underlying problem with cursors, so re-enable this.
-
由 Michel Dänzer 提交于
Reviewed-by: NGrigori Goronzy <greg@chown.ath.cx> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Grigori Goronzy 提交于
Everything is evicted from VRAM before suspend, so we need to make sure all BOs are unpinned and re-pinned after resume. Fixes broken mouse cursor after resume introduced by commit b9729b17. [Michel Dänzer: Add pinning BOs on resume] v2: [Alex Deucher: merge cursor unpin into fb unpin loop] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541 Cc: stable@vger.kernel.org Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Michel Dänzer 提交于
Take a GEM reference for and pin the new cursor BO, unpin and drop the GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use radeon_crtc->cursor_addr in radeon_set_cursor. This fixes radeon_cursor_reset accidentally incrementing the cursor BO pin count, and cleans up the code a little. Cc: stable@vger.kernel.org Reviewed-by: NGrigori Goronzy <greg@chown.ath.cx> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Dan Carpenter 提交于
The "if (pass_size > buf->total)" can underflow so I have changed the type of size and pass_size to unsigned to avoid this problem. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Grigori Goronzy 提交于
Newer ASICs have more VRAM on average and allocating more GART as well can have advantages. Also see commit edcd26e8. Ideally, we should scale GART size based on actual VRAM size, but that requires significant restructuring of initialization. v2: extract small helper, apply to error paths Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-