- 09 4月, 2013 3 次提交
-
-
由 Samuel Li 提交于
This patch allows the CPU to map the stolen vram segment directly rather than going through the PCI BAR. This significantly improves performance for certain workloads with a properly patched ddx. Use radeon.fastfb=1 to enable it (disabled by default). Currently only supported on RS690, but support for RS780/880 and newer APUs may be added eventually. Signed-off-by: NSamuel Li <samuel.li@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
A new tiling config register for the display blocks was added on DCE6. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=62889 https://bugs.freedesktop.org/show_bug.cgi?id=57919Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Add a per-asic MC (memory controller) mask which holds the mak address mask the asic is capable of. Use this when calculating the vram and gtt locations rather using asic specific functions or limiting everything to 32 bits. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 08 4月, 2013 1 次提交
-
-
由 Alex Deucher 提交于
Doesn't affect anything as the same address gets written in both cases. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 02 4月, 2013 2 次提交
-
-
由 Alex Deucher 提交于
Monitors seem to prefer it. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37696Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
It doesn't work reliably. Just report back the currently selected engine clock. Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=62493Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 24 3月, 2013 5 次提交
-
-
由 Daniel Vetter 提交于
This reverts commit cf0a6584. Turns out that cargo-culting breaks systems. Note that we can't revert further, since commit 770c1231 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid fixed a regression in 3.6-rc kernels for which we've never figured out the exact root cause. But some further inspection of the backlight code reveals that it's seriously lacking locking. And especially the asle backlight update is know to get fired (through some smm magic) when writing specific backlight control registers. So the possibility of suffering from races is rather real. Until those races are fixed I don't think it makes sense to try further hacks. Which sucks a bit, but sometimes that's how it is :( References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941Tested-by: NTakashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
We're still not 100% ready to disable the power well, so don't disable it for now. When we disable it we break the audio driver (because some of the audio registers are on the power well) and machines with eDP on port D (because it doesn't use TRANSCODER_EDP). Also, instead of just reverting the code, add a Kernel option to let us disable it if we want. This will allow us to keep developing and testing the feature while it's not enabled. This fixes problems caused by the following commit: commit d6dd9eb1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jan 29 16:35:20 2013 -0200 drm/i915: dynamic Haswell display power well support References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html Cc: Takashi Iwai <tiwai@suse.de> Cc: Mengdong Lin <mengdong.lin@intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
This reverts commit cc464b2a. The reason is that Takashi Iwai reported a regression bisected to this commit: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html His machine has eDP on port D (usual desktop all-in-on setup), which intel_dp.c identifies as an eDP panel, but the hsw ddi code mishandles. Closer inspection of the code reveals that haswell_crtc_mode_set also checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell that doesn't make much sense (since there's no edp on the pch), but what this function _really_ checks is whether that edp connector is on port A or port D. It's just that on ilk-ivb port D was on the pch ... So that explains why this seemingly innocent change killed eDP on port D. Furthermore it looks like everything else accidentally works, since we've never enabled eDP on port D support for hsw intentionally (e.g. we still register the HDMI output for port D in that case). But in retrospective I also don't like that this leaks highly platform specific details into common code, and the reason is that the drm vblank layer sucks. So instead I think we should: - move the cpu_transcoder into the dynamic pipe_config tracking (once that's merged). - fix up the drm vblank layer to finally deal with kms crtc objects instead of int pipes. v2: Pimp commit message with the better diagnosis as discussed with Paulo on irc. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Torsten Duwe 提交于
When KMS has parsed an EDID "detailed timing", it leaves the frame rate zeroed. Consecutive (debug-) output of that mode thus yields 0 for vsync. This simple fix also speeds up future invocations of drm_mode_vrefresh(). While it is debatable whether this qualifies as a -stable fix I'd apply it for consistency's sake; drm_helper_probe_single_connector_modes() does the same thing already for all probed modes. Cc: stable@vger.kernel.org Signed-off-by: NTorsten Duwe <duwe@lst.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Torsten Duwe 提交于
EDID spreads some values across multiple bytes; bit-fiddling is needed to retrieve these. The current code to parse "detailed timings" has a cut&paste error that results in a vsync offset of at most 15 lines instead of 63. See http://en.wikipedia.org/wiki/EDID and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why that needs to be a left shift. Cc: stable@vger.kernel.org Signed-off-by: NTorsten Duwe <duwe@lst.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 3月, 2013 1 次提交
-
-
由 Julia Lemire 提交于
While testing the mgag200 kms driver on the HP ProLiant Gen8, a bug was seen. Once the bootloader would load the selected kernel, the screen would go black. At first it was assumed that the mgag200 kms driver was hanging. But after setting up the grub serial output, it was seen that the driver was being loaded properly. After trying serval monitors, one finaly displayed the message "Frequency Out of Range". By comparing the kms pll algorithm with the previous mgag200 xorg driver pll algorithm, discrepencies were found. Once the kms pll algorithm was modified, the expected pll values were produced. This fix was tested on several monitors of varying native resolutions. Signed-off-by: NJulia Lemire <jlemire@matrox.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 20 3月, 2013 12 次提交
-
-
由 YoungJun Cho 提交于
This patch checks command list from user for g2d restrictions. For now, g2d driver wasn't considered for G2D hardware restrictions properly. The below is the restrictions to G2D hardware and this patch considers them. - width or height value in the command list has to be in valid range (1 to 8000 pixels) - The requested area should be less than buffer size. - right has to be bigger than left. - bottom has to be bigger than top. Changelog v2: - Fix merge conflict. Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 Inki Dae 提交于
This patch adds a new function to get gem buffer size. And this funtion could be used for g2d driver or others can get gem buffer size to check if the buffer is valid or not. Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <inki.dae@samsung.com>
-
由 YoungJun Cho 提交于
This patch adds g2d_buf_info structure and buffer relevant variables moves into the g2d_buf_info to manage g2d buffer information more efficiently. Changelog v2: - Fix merge conflict. Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 YoungJun Cho 提交于
This patch just cleans up G2D codes for readability. For this, it changes the member of g2d_cmdlist_node, obj_type into buf_type. Changelog v2: - Revert irrelevant codes. Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 YoungJun Cho 提交于
This patch fixes G2D core malfunctioning issue once g2d dma is started. Without 'DMA_HOLD_CMD_REG' register setting, there is only one interrupt after the execution to all command lists have been completed. And that induces watchdog. So this patch sets 'LIST_HOLD' command to the register so that command execution interrupt can be occured whenever each command list execution is finished. Changelog v2: - Consider for interrupt setup to each command list and all command lists And correct typo. Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 YoungJun Cho 提交于
This patch clears node object type in G2D unmap cmdlist. The obj_type of cmdlist node has to be cleared in g2d_unmap_cmdlist_gem() so that the node can be reused in g2d_map_cmdlist_gem(). Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 YoungJun Cho 提交于
This patch fixes error routine when g2d_userptr_get_dma_add is failed. When sg_alloc_table_from_pages() is failed, it doesn't call sg_free_table() anymore. Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 Alexandru Gheorghiu 提交于
Replaced calls to kzalloc followed by memcpy with call to kmemdup. Patch found using coccinelle. Signed-off-by: NAlexandru Gheorghiu <gheorghiuandru@gmail.com> Acked-by: NSeung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Leela Krishna Amudala 提交于
Calculate the correct address offset values for alpha and color key control registers based on exynos4 and exynos5 user manuals. Also remove VIDOSD_C_SIZE_W0 macro and fix comments about registers for size and alpha. Signed-off-by: NLeela Krishna Amudala <l.krishna@samsung.com> Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Sachin Kamat 提交于
Fixes the following sparse warning: drivers/gpu/drm/exynos/exynos_mixer.c:821:5: warning: symbol 'mixer_check_timing' was not declared. Should it be static? Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Vikas Sajjan 提交于
modified compatible string for exynos4 fimd as "exynos4210-fimd" and exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible value should be named after first specific SoC model in which this particular IP version was included as discussed at https://patchwork.kernel.org/patch/2144861/Signed-off-by: NVikas Sajjan <vikas.sajjan@linaro.org> Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Jiri Kosina 提交于
Commit 28c70f16 ("drm/i915: use the gmbus irq for waits") switched to using GMBUS irqs instead of GPIO bit-banging for chipset generations 4 and above. It turns out though that on many systems this leads to spurious interrupts being generated, long after the register write to disable the IRQs has been issued. Typically this results in the spurious interrupt source getting disabled: [ 9.636345] irq 16: nobody cared (try booting with the "irqpoll" option) [ 9.637915] Pid: 4157, comm: ifup Tainted: GF 3.9.0-rc2-00341-g08637024 #422 [ 9.639484] Call Trace: [ 9.640731] <IRQ> [<ffffffff8109b40d>] __report_bad_irq+0x1d/0xc7 [ 9.640731] [<ffffffff8109b7db>] note_interrupt+0x15b/0x1e8 [ 9.640731] [<ffffffff810999f7>] handle_irq_event_percpu+0x1bf/0x214 [ 9.640731] [<ffffffff81099a88>] handle_irq_event+0x3c/0x5c [ 9.640731] [<ffffffff8109c139>] handle_fasteoi_irq+0x7a/0xb0 [ 9.640731] [<ffffffff8100400e>] handle_irq+0x1a/0x24 [ 9.640731] [<ffffffff81003d17>] do_IRQ+0x48/0xaf [ 9.640731] [<ffffffff8142f1ea>] common_interrupt+0x6a/0x6a [ 9.640731] <EOI> [<ffffffff8142f952>] ? system_call_fastpath+0x16/0x1b [ 9.640731] handlers: [ 9.640731] [<ffffffffa000d771>] usb_hcd_irq [usbcore] [ 9.640731] [<ffffffffa0306189>] yenta_interrupt [yenta_socket] [ 9.640731] Disabling IRQ #16 The really curious thing is now that irq 16 is _not_ the interrupt for the i915 driver when using MSI, but it _is_ the interrupt when not using MSI. So by all indications it seems like gmbus is able to generate a legacy (shared) interrupt in MSI mode on some configurations. I've tried to reproduce this and the differentiating thing seems to be that on unaffected systems no other device uses irq 16 (which seems to be the non-MSI intel gfx interrupt on all gm45). I have no idea how that even can happen. To avoid tempting this elephant into a rage, just disable gmbus interrupt support on gen 4. v2: Improve the commit message with exact details of what's going on. Also add a comment in the code to warn against this particular elephant in the room. v3: Move the comment explaing how gen4 blows up next to the definition of HAS_GMBUS_IRQ to keep the code-flow straight. Suggested by Chris Wilson. Signed-off-by: Jiri Kosina <jkosina@suse.cz> (v1) Acked-by: NChris Wilson <chris@chris-wilson.co.uk> References: https://lkml.org/lkml/2013/3/8/325Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 19 3月, 2013 2 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 18 3月, 2013 13 次提交
-
-
由 Takashi Iwai 提交于
The eDP output on HP Z1 is still broken when X is started even after fixing the infinite link-train loop. The regression was introduced in 3.6 kernel for cleaning up the mode clock handling code in intel_dp.c by the commit [71244653: drm/i915: adjusted_mode->clock in the dp mode_fix]. In the past, the clock of the reference mode was modified in intel_dp_mode_fixup() in the case of eDP fixed clock, and this clock was used for calculating in intel_dp_set_m_n(). This override was removed, thus the wrong mode clock is used for the calculation, resulting in a psychedelic smoking output in the end. This patch corrects the clock to be used in the place. v1->v2: Use intel_edp_target_clock() for checking eDP fixed clock instead of open code as in ironlake_set_m_n(). Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Martin Peres 提交于
Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Reported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
The kernel message "[ PTHERM][0000:01:00.0] Thermal management: disabled" is misleading as it actually means "fan management: disabled". This patch fixes both the source and the message to improve readability. Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
In nouveau_therm_sensor_event, temperature is stored as an uint8_t even though the original interface returns an int. This change should make it more obvious when the sensor is either very-ill-calibrated or when we selected the wrong sensor style on the nv40 family. Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Based on my experience, 10ms wasn't always enough. Let's bump that to a little more. If this turns out to be insufficient-enough again, then an approach based on letting the sensor settle for several seconds before starting polling on the temperature would be better suited. This way, boot time wouldn't be impacted by those waits too much. Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
The condition to select between the old and new style was a thinko as rnndb orders chipsets based on their release date (or general chronologie hw-wise) and not based on their chipset number. As the nv40 family is a mess when it comes to numbers, this patch introduces a switch-based selection between the old and new style. Signed-off-by: NMartin Peres <martin.peres@labri.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Takashi Iwai 提交于
This reverts commit 0d710688. Not only that the commit introduces a bogus check (voltage_tries == 5 will never meet at the inserted code path), it brings the i915 driver into an endless dp-train loop on HP Z1 desktop machine with IVY+eDP. At least reverting this commit recovers the framebuffer (but X is still broken by other reasons...) Cc: <stable@vger.kernel.org> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 16 3月, 2013 1 次提交
-
-
由 Alex Deucher 提交于
Richland APUs are a new version of the Trinity APUs with performance and power management improvements. Reviewed-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-