[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #11 from Arek RuÅniak --- between stage 2&3 the winner is: 3da735cc4c478b0ab2ecc2164899cf9d77dc671a is the first bad commit commit 3da735cc4c478b0ab2ecc2164899cf9d77dc671a Author: Jason Ekstrand Date: Sat Aug 23 10:45:00 2014 -0700 main: Add a concept of an array format An array format is a 32-bit integer format identifier that can represent any format that can be represented as an array of standard GL datatypes. Whie the MESA_FORMAT enums provide several of these, they don't account for all of them. v2 by Iago Toral Quiroga : - Implement mesa_array_format as a plain bitfiled uint32_t type instead of using a struct inside a union to access the various components packed in it. This is necessary to support bigendian properly, as pointed out by Ian. - Squashed: Make float types normalized v3 by Iago Toral Quiroga : - Include compiler.h in formats.h, which is necessary to build in MSVC as indicated by Brian Paul. Reviewed-by: Jason Ekstrand :04 04 87f8588bd2eeda5fbf0669360f2ff66564c93a3c f2b353b9593f085e196f184a2d6ebee2e2194dea Msrc for stages 1&2... wip -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/50eb5298/attachment.html>
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #37 from Alex Deucher --- (In reply to Joerg Esser from comment #35) > I had similar problems until I used 3.18.7. > I couldn´t even boot beyond radeon load. The whole kernel crashed and my > Monitor showed no usable signal. I had to blacklist and load it manually > with option radeon.dpm=0, after turning on my Monitor . With kernel 3.18.6 I > could use the radeon option radeon.aspm=0, but still had to turn on my > Monitor before radeon module load. > > Now with this kernel I only need radeon.aspm=0 and no blacklist option, > either the Monitor is turned on before or after radeon module load. Also GPU > speedup with Video output works fine. Please file a different bug. This bug and the patch only affect old asics like the RS880. Something else must have fixed the issue for you. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #14 from Alex Deucher --- (In reply to andre35822 from comment #13) > Just thought I would post a little update, I am in the process of getting my > system to use the new kernel. Ive already compiled it with the patch and > stuff, i am just having a bit of trouble creating a ramdisk (I am followeing > the arch linux wiki) although I will figure it out. Will the fixes from > comment 19 and 20 be implemented into the next release of video-ati or does > it still need testing? I am asking this so that if I know it isn't I may as > well compile another kernel with the patches from 19 and 20. Thank you btw > for everything. FWIW, using make install in your kernel tree will usually handle the ramdisk update, but I'm not that familiar with arch, so if you are comfortable with that, I'd stick with that. As for the patches from 19 and 20, I'm pretty confident they will work, but it would be nice to get some confirmation. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/0fc3704c/attachment.html>
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #36 from Joerg Esser --- Oh I forgot, In the kernel changelog it also hits bug 91861. And it isn´t in 3.19 because there I still have those problem. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 --- Comment #8 from andre35822 at yahoo.com --- (In reply to smoki from comment #7) > The best is if you can bisect mesa, if 10.3 worked fine it should be easy > :) Or try various settings in game, might be only one which trigger slow > case. > Or if someone other want to reproduce it, apitrace trace will be usefull, > etc... > > Otherwise more info is needed, like: > > Which version of Minecraft? > Java or openjdk used? > Did you use optifine? > > You might post your options.txt file, because as i said it might only > happen with exact settings and also optionsof.txt in case you use optifine, > etc... Bisect mesa? I found this in the arch linux wiki https://wiki.archlinux.org/index.php/Bisecting_Mesa so what is it really? Its to notify the mesa developers from git? I am not sure lol sorry. I am going to do some more testing, with Mesa 10.3 and Mesa 10.4 and different versions of Minecraft. I am very new to the whole reporting bugs on linux and don't know of these beautiful programs that exist. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/24e24f5e/attachment.html>
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 Joerg Esser changed: What|Removed |Added CC||jackfritt at boh.de --- Comment #35 from Joerg Esser --- I had similar problems until I used 3.18.7. I couldn´t even boot beyond radeon load. The whole kernel crashed and my Monitor showed no usable signal. I had to blacklist and load it manually with option radeon.dpm=0, after turning on my Monitor . With kernel 3.18.6 I could use the radeon option radeon.aspm=0, but still had to turn on my Monitor before radeon module load. Now with this kernel I only need radeon.aspm=0 and no blacklist option, either the Monitor is turned on before or after radeon module load. Also GPU speedup with Video output works fine. Thx alot!! Here´s my card info lspci -s 01:00.0 -vv 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Device e157 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #13 from andre35822 at yahoo.com --- (In reply to Alex Deucher from comment #12) > (In reply to andre35822 from comment #11) > > I am up to help you for whatever it is that you need, I am just a bit > > confused. You are referring to this bug report yes? > > https://bugs.freedesktop.org/show_bug.cgi?id=87796 and want me to apply the > > patch that you put as attachment in Comment 15? Or is it Comment 19 or 20? I > > am also not sure how to apply the patch, it looks like something to do with > > git? Once I know how to apply the patch, to my understanding you then want > > me to enable the "problematic mode", which would be setting the screen to > > 144hz and then attachming a dmesg output yes? > > Yes, bug 87796. I'm interested in the dmesg output after switching to the > problematic mode from the patch in comment 15. See comment 17 for how to > apply it. > > The patches in 19 and 20 will workaround the issue while still letting you > use auto. Just thought I would post a little update, I am in the process of getting my system to use the new kernel. Ive already compiled it with the patch and stuff, i am just having a bit of trouble creating a ramdisk (I am followeing the arch linux wiki) although I will figure it out. Will the fixes from comment 19 and 20 be implemented into the next release of video-ati or does it still need testing? I am asking this so that if I know it isn't I may as well compile another kernel with the patches from 19 and 20. Thank you btw for everything. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/3cb65ca6/attachment.html>
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 Arek RuÅniak changed: What|Removed |Added Attachment #113672|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/cca2c9f9/attachment.html>
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #10 from Arek RuÅniak --- Created attachment 113672 --> https://bugs.freedesktop.org/attachment.cgi?id=113672&action=edit somewhere between mesa 10.2.x & 10.3 I've tested some tags of mesa with: llvm-3.5.1 & xorg 1.17.1+modesetting & drm_next. 1)mesa 10.2.9 - looks ok 2)mesa 10.3.(0,1)&10.4.4 - looks like a crap (see pic) but not fails (play music, can screen shot, can escape with ALT+F4) 3)mesa dev-10.(5,6) - crashes -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/2a3d9744/attachment.html>
[Bug 89228] Regression with left for dead 2
https://bugs.freedesktop.org/show_bug.cgi?id=89228 --- Comment #2 from Daniel Scharrer --- Did you try the patch form 88561 comment 6. I still see some glitches in your trace with that patch, although it may be worse without it (didn't test). Didn't get any GPU lockups or errors in dmesg with the trace, even after running it a couple of times. GPU: Radeon HD 7950 (OpenGL renderer string: Gallium 0.4 on AMD TAHITI) Mesa git-6c34fd2 + "radeonsi: don't use SQC_CACHES to flush ICACHE and KCACHE on SI" LLVM r229671 Kernel 3.19.0-gentoo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/5dde63bb/attachment.html>
[RFC PATCH] drm/radeon: program auxch directly
On Thu, Feb 19, 2015 at 6:21 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> The atombios tables have an unfortunate restriction on only
> being able to write 12 bytes, MST really wants 16-bytes here,
> and since the hw can do it, we should just write directly to it.
>
> This uses a module option to allow for it now, and maybe
> we should provide the old code as a fallback for a while.
>
> Signed-off-by: Dave Airlie
> ---
>
> Just putting this out there for people to know I'm doing it,
> most likely I'd want to merge on by default for MST systems
> at least.
>
> TODO: testing, irq support?
This code will only work on DCE5+. Things moved around on older
asics. That said, DCE5 is the first asic that supports MST, so we can
stick with atom on the older ones. I'm fine with enabling it for DCE5
and newer by default.
>
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/atombios_dp.c | 5 +-
> drivers/gpu/drm/radeon/radeon.h | 3 +
> drivers/gpu/drm/radeon/radeon_dp_auxch.c | 253
> +++
> drivers/gpu/drm/radeon/radeon_drv.c | 4 +
> 5 files changed, 265 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/radeon/radeon_dp_auxch.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 4605633..fa635f0 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o
> trinity_dpm.o \
> trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o \
> - radeon_sync.o radeon_audio.o
> + radeon_sync.o radeon_audio.o radeon_dp_auxch.o
>
> radeon-$(CONFIG_MMU_NOTIFIER) += radeon_mn.o
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index db42a67..37594b2 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -223,7 +223,10 @@ void radeon_dp_aux_init(struct radeon_connector
> *radeon_connector)
>
> radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
> radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
> - radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
>
Rename the old one to radeon_atombios_dp_aux_transfer.
if (ASIC_IS_DCE5(rdev)) {
if (radeon_auxch)
radeon_connector->ddc_bus->aux.transfer =
radeon_dp_aux_transfer_native;
else
radeon_connector->ddc_bus->aux.transfer =
radeon_atombios_dp_aux_transfer;
} else {
radeon_connector->ddc_bus->aux.transfer =
radeon_atombios_dp_aux_transfer;
}
> ret = drm_dp_aux_register(&radeon_connector->ddc_bus->aux);
> if (!ret)
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 5587603..bd4e8bd 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -111,6 +111,7 @@ extern int radeon_deep_color;
> extern int radeon_use_pflipirq;
> extern int radeon_bapm;
> extern int radeon_backlight;
> +extern int radeon_auxch;
>
> /*
> * Copy from radeon_drv.h so we don't have to include both and have
> conflicting
> @@ -3112,6 +3113,8 @@ int r600_cs_common_vline_parse(struct radeon_cs_parser
> *p,
>uint32_t *vline_start_end,
>uint32_t *vline_status);
>
> +ssize_t
> +radeon_dp_aux_transfer_native(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> *msg);
> #include "radeon_object.h"
>
> #endif
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> new file mode 100644
> index 000..0cf94e6
> --- /dev/null
> +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2015 Red Hat Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF
[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 --- Comment #8 from Daniel Scharrer --- The Mesa patch from bug 88561 comment 6 fixes this for me - at least the glitches with the posted apitrace. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/909b5a1f/attachment-0001.html>
[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal
https://bugs.freedesktop.org/show_bug.cgi?id=88561 --- Comment #8 from Daniel Scharrer --- Hi Marek, the patch does improve things a lot: with it I can no longer reproduce any glitches in my Portal trace or in the Dota 2 trace from bug 88978 comment 2. However, in-game some glitches remain. In Portal they are extremely infrequent with your patch, however disappearing terrain patches and garbage vertices are still relatively easy to reproduce in Team Fortress 2. (Maybe this fits belongs in bug 88978?) I tried to record an apitrace of TF2 but it does not replay correctly. Just loading up a practice map (I tried Dustbowl) and walking around should be enough. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/d9af88d3/attachment.html>
[Intel-gfx] [KERNEL] Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61
On to, 2015-02-19 at 15:42 +, Dave Gordon wrote:
> On 19/02/15 11:08, Deak, Imre wrote:
> > On Thu, 2015-02-19 at 10:47 +, Dave Gordon wrote:
> >> On 18/02/15 16:24, Imre Deak wrote:
> >>> On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
> On Tue, 17 Feb 2015, Klaus Ethgen wrote:
> > After solving the conflicts, I applied the revert (see attachment) to
> > v3.18.7. I think it should also apply to the current head. With that
> > patch, suspend is working again on that version.
> >
> > However, I have not to deep knowledge of that subsystem, so please,
> > someone who have, have a deeper look into it. I especially do not know
> > if the lines in .../intel_pm.c are correct or better leaving them as
> > they are in v3.18.7.
> >
> > I want to have it working on a version that I know is stable before
> > asking to pull it to head.
>
> Hi Klaus, we fear this patch may hide the actual cause. Would be useful
> to get a better description of what happens, along with a dmesg with
> drm.debug=14 module parameter set. This might clutter the mailing list,
> would you mind filing a bug at [1] and attach the info there?
>
> Thanks,
> Jani.
>
> [1]
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
> >>>
> >>> In addition to the above could you also try the following patch and
> >>> provide a dmesg log on the bugzilla ticket - at this point only to try
> >>> to narrow down the issue?:
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >>> b/drivers/gpu/drm/i915/i915_irq.c
> >>> index d358ce8..02c65f4 100644
> >>> --- a/drivers/gpu/drm/i915/i915_irq.c
> >>> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >>> @@ -4466,6 +4466,14 @@ static irqreturn_t i965_irq_handler(int irq, void
> >>> *arg)
> >>> I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
> >>> I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
> >>>
> >>> + if (!intel_irqs_enabled(dev_priv)) {
> >>> + if (printk_ratelimit())
> >>> + DRM_ERROR("spurious/shared interrupt iir %08x imr %08x
> >>> ier %08x\n",
> >>> + I915_READ(IIR), I915_READ(IMR),
> >>> I915_READ(IER));
> >>> +
> >>> + return IRQ_NONE;
> >>> + }
> >>> +
> >>> iir = I915_READ(IIR);
> >>>
> >>> for (;;) {
> >>> @@ -4766,7 +4774,10 @@ void intel_runtime_pm_disable_interrupts(struct
> >>> drm_device *dev)
> >>> struct drm_i915_private *dev_priv = dev->dev_private;
> >>>
> >>> dev->driver->irq_uninstall(dev);
> >>> +
> >>> + spin_lock_irq(&dev_priv->irq_lock);
> >>> dev_priv->pm._irqs_disabled = true;
> >>> + spin_unlock_irq(&dev_priv->irq_lock);
> >>> }
> >>>
> >>> /* Restore interrupts so we can recover from runtime PM. */
> >>> @@ -4774,7 +4785,10 @@ void intel_runtime_pm_restore_interrupts(struct
> >>> drm_device *dev)
> >>> {
> >>> struct drm_i915_private *dev_priv = dev->dev_private;
> >>>
> >>> + spin_lock_irq(&dev_priv->irq_lock);
> >>> dev_priv->pm._irqs_disabled = false;
> >>> + spin_unlock_irq(&dev_priv->irq_lock);
> >>> +
> >>> dev->driver->irq_preinstall(dev);
> >>> dev->driver->irq_postinstall(dev);
> >>> }
> >>
> >> Surely surrounding (what ought to be) an atomic assignment to a single
> >> variable cannot make a difference? Unless it's the memory barrier
> >> semantics that have some effect? It seems unlikely that the compiler has
> >> deferred the write to the variable past the pre/postinstall calls that
> >> actually enable the h/w interrupts, but maybe we should add "volatile"
> >> just in case?
> >
> > spinlocks also serve as a memory barrier. volatile would guarantee only
> > that the compiler doesn't reorder the write, so it wouldn't be enough
> > alone. Otoh, we may also need to add spinlocking to the interrupt
> > handler if the issue turns out to be that we can't access some register
> > past/before intel_runtime_pm_{disable,enable}_interrupts.
> >
> > --Imre
>
> If we were getting interrupts during the enabling sequence, there would
> be three possibilities:
> 1.compiler has delayed writeback. This would be a compiler bug
> (IMHO) but 'volatile' might fix it.
> 2.the 'restore' thread has written the value, but it isn't seen
> by the thread handling the interrupt (on a different cpu?).
> This would be a coherency issue, and a memory barrier should
> fix it. But I would have expected the variable to be in
> coherent memory anyway.
> 3.the GPU h/w sending interrupts before they're enabled :(
For enabling I want to make sure _irqs_disabled=false is stored to
memory before the interrupt handler can run. This flag is in normal
write-back memory, hence you need a memory barrier which is provided by
the spin lock. I could have also used here mb() or rely on the implicit
memory barrier of the iowrite in preinstall/postinstall hooks; I didn't
since as I said we may want to add spin locking to the ir
[PATCH] drm/radeon: fix 1 RB harvest config setup for TN/RL
The logic was reversed from what the hw actually exposed.
Fixes graphics corruption in certain harvest configurations.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ni.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index ebe68dd..dab0081 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1088,12 +1088,12 @@ static void cayman_gpu_init(struct radeon_device *rdev)
if ((rdev->config.cayman.max_backends_per_se == 1) &&
(rdev->flags & RADEON_IS_IGP)) {
- if ((disabled_rb_mask & 3) == 1) {
- /* RB0 disabled, RB1 enabled */
- tmp = 0x;
- } else {
+ if ((disabled_rb_mask & 3) == 2) {
/* RB1 disabled, RB0 enabled */
tmp = 0x;
+ } else {
+ /* RB0 disabled, RB1 enabled */
+ tmp = 0x;
}
} else {
tmp = gb_addr_config & NUM_PIPES_MASK;
--
1.8.3.1
[Bug 43209] PAE and radeon integrated rs690 (x1200) prevents dri
https://bugzilla.kernel.org/show_bug.cgi?id=43209 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #3 from Alan --- This bug relates to a very old kernel. Closing as obsolete. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 43295] panic occurred switching back to text console ubuntu 11.10
https://bugzilla.kernel.org/show_bug.cgi?id=43295 Alan changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |OBSOLETE --- Comment #5 from Alan --- This bug relates to a very old kernel. Closing as obsolete. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89228] Regression with left for dead 2
https://bugs.freedesktop.org/show_bug.cgi?id=89228 --- Comment #1 from kdj0c at djinvi.net --- apitrace available at https://djinvi.net/jirafeau/f.php?h=1Gs0-v6H -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/9f1865a0/attachment.html>
[Bug 43346] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
https://bugzilla.kernel.org/show_bug.cgi?id=43346 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |OBSOLETE --- Comment #1 from Alan --- This bug relates to a very old kernel. Closing as obsolete. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 43360] nouveau on "NVce" 560 Ti: Failed to idle channel 1
https://bugzilla.kernel.org/show_bug.cgi?id=43360 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 43365] nouveau on "NVce" 560 Ti: on hi-res video shifting artefacts
https://bugzilla.kernel.org/show_bug.cgi?id=43365 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |OBSOLETE --- Comment #3 from Alan --- This bug relates to a very old kernel. Closing as obsolete. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 43741] /sys/class/backlight/ is empty with AMD (ATI) Radeon HD 4350
https://bugzilla.kernel.org/show_bug.cgi?id=43741 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning
https://bugzilla.kernel.org/show_bug.cgi?id=44341 Alan changed: What|Removed |Added Status|REOPENED|RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 44831] Radeon HD6970: HDMI audio doesn't work with radeon.hw_i2c=1
https://bugzilla.kernel.org/show_bug.cgi?id=44831 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |OBSOLETE --- Comment #5 from Alan --- This bug relates to a very old kernel. Closing as obsolete. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 44851] resume to black screen
https://bugzilla.kernel.org/show_bug.cgi?id=44851 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Kernel Version|3.5.0-3 |3.9 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 29842] Radeon runs very hot
https://bugzilla.kernel.org/show_bug.cgi?id=29842 Alan changed: What|Removed |Added Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #9 from Arek RuÅniak --- Igor, i use 1-day old git/svn for mesa/llvm/kenel except for xf86-video-ati, i don't use it at all. If your distribution use xorg-1.17.x you may try xf86-video-modesetting. It would be really nice if you can. As I wrote before, for xf86-video-ati the problem doesn't exist ...at least for me. Could you tell which version of radeon ddx failed for unvanquished + AA. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/d6d125b9/attachment.html>
[Bug 22022] 2.6.32 regression: sometimes Suspend-To-RAM causes system hangup - ATI RS480
https://bugzilla.kernel.org/show_bug.cgi?id=22022 Alan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76487] [PIGLIT,radeonsi] spec/{EXT_texture_array/fbo-generatemipmap-array, ARB_framebuffer_object/fbo-generatemipmap-3d} RGB9_E5 crashes
https://bugs.freedesktop.org/show_bug.cgi?id=76487 smoki changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from smoki --- This seems long time fixed with commit 26c41398cc47c0f72259a34406831443238b7ba9 Closing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/5b969e61/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 Alexandre Demers changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=87278 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/456279a3/attachment-0001.html>
[Bug 87278] Packet0 not allowed and GPU fault detected errors with Serious Engine games
https://bugs.freedesktop.org/show_bug.cgi?id=87278 Alexandre Demers changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=84500 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/f5989936/attachment-0001.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #46 from Alexandre Demers --- (In reply to Lorenzo Bona from comment #45) > Since yesterday I've been testing last drm-fixes-3.19 kernel with old radeon > firmwares. I mean before big upgrade on 24th of July. > > I've played Dota2 and watched videos on flash and on mpv with vdpau, and I > can't reproduce those warnings anymore. > > But while I play I can see these: > > [10319.747657] radeon :07:00.0: GPU fault detected: 146 0x0b080404 > [10319.747665] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00017258 > [10319.747670] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x08004004 > [10319.747675] VM fault (0x04, vmid 4) at page 94808, read from TC (4) > [12134.226711] radeon :07:00.0: GPU fault detected: 146 0x0b084404 > [12134.226719] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00017258 > [12134.226724] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x08044004 > [12134.226728] VM fault (0x04, vmid 4) at page 94808, read from TC (68) Your VM errors may be related to bug 87278, which was also reopened after a reverted commit in LLVM. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/6012434d/attachment.html>
[Intel-gfx] [PATCH 3/4] drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c
On to, 2015-02-19 at 15:39 +0200, Imre Deak wrote: > On to, 2015-02-19 at 12:25 +, Dave Gordon wrote: > > On 12/02/15 22:38, Imre Deak wrote: > > > On Tue, 2015-02-03 at 11:30 +0100, Daniel Vetter wrote: > > >> UMS is no more! > > >> > > >> Signed-off-by: Daniel Vetter > > > > Some machines now won't boot in "recovery mode", which specifies > > "nomodeset" and therefore results in various important bits of code not > > being executed. Will we eventually ignore "modeset" completely, or just > > refuse to load at all if "nomodeset" is explicitly specified? > > The driver will already refuse to load with nomodeset for GEN6+ for > quite some time now. On old platforms UMS would still work before this > patch, but afaik there was a decision to stop supporting UMS. Note that > this doesn't mean "recovery mode" or equivalently nomodeset will break > booting, it just means user space will fall back to vesa/vga or text > mode. Ah, or did you mean after this patch we should refuse loading the driver in case of nomodeset even for old platforms? That would make sense indeed. --Imre
[Intel-gfx] [KERNEL] Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61
On 19/02/15 11:08, Deak, Imre wrote:
> On Thu, 2015-02-19 at 10:47 +, Dave Gordon wrote:
>> On 18/02/15 16:24, Imre Deak wrote:
>>> On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
On Tue, 17 Feb 2015, Klaus Ethgen wrote:
> After solving the conflicts, I applied the revert (see attachment) to
> v3.18.7. I think it should also apply to the current head. With that
> patch, suspend is working again on that version.
>
> However, I have not to deep knowledge of that subsystem, so please,
> someone who have, have a deeper look into it. I especially do not know
> if the lines in .../intel_pm.c are correct or better leaving them as
> they are in v3.18.7.
>
> I want to have it working on a version that I know is stable before
> asking to pull it to head.
Hi Klaus, we fear this patch may hide the actual cause. Would be useful
to get a better description of what happens, along with a dmesg with
drm.debug=14 module parameter set. This might clutter the mailing list,
would you mind filing a bug at [1] and attach the info there?
Thanks,
Jani.
[1]
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
>>>
>>> In addition to the above could you also try the following patch and
>>> provide a dmesg log on the bugzilla ticket - at this point only to try
>>> to narrow down the issue?:
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>>> b/drivers/gpu/drm/i915/i915_irq.c
>>> index d358ce8..02c65f4 100644
>>> --- a/drivers/gpu/drm/i915/i915_irq.c
>>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>>> @@ -4466,6 +4466,14 @@ static irqreturn_t i965_irq_handler(int irq, void
>>> *arg)
>>> I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
>>> I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
>>>
>>> + if (!intel_irqs_enabled(dev_priv)) {
>>> + if (printk_ratelimit())
>>> + DRM_ERROR("spurious/shared interrupt iir %08x imr %08x
>>> ier %08x\n",
>>> + I915_READ(IIR), I915_READ(IMR),
>>> I915_READ(IER));
>>> +
>>> + return IRQ_NONE;
>>> + }
>>> +
>>> iir = I915_READ(IIR);
>>>
>>> for (;;) {
>>> @@ -4766,7 +4774,10 @@ void intel_runtime_pm_disable_interrupts(struct
>>> drm_device *dev)
>>> struct drm_i915_private *dev_priv = dev->dev_private;
>>>
>>> dev->driver->irq_uninstall(dev);
>>> +
>>> + spin_lock_irq(&dev_priv->irq_lock);
>>> dev_priv->pm._irqs_disabled = true;
>>> + spin_unlock_irq(&dev_priv->irq_lock);
>>> }
>>>
>>> /* Restore interrupts so we can recover from runtime PM. */
>>> @@ -4774,7 +4785,10 @@ void intel_runtime_pm_restore_interrupts(struct
>>> drm_device *dev)
>>> {
>>> struct drm_i915_private *dev_priv = dev->dev_private;
>>>
>>> + spin_lock_irq(&dev_priv->irq_lock);
>>> dev_priv->pm._irqs_disabled = false;
>>> + spin_unlock_irq(&dev_priv->irq_lock);
>>> +
>>> dev->driver->irq_preinstall(dev);
>>> dev->driver->irq_postinstall(dev);
>>> }
>>
>> Surely surrounding (what ought to be) an atomic assignment to a single
>> variable cannot make a difference? Unless it's the memory barrier
>> semantics that have some effect? It seems unlikely that the compiler has
>> deferred the write to the variable past the pre/postinstall calls that
>> actually enable the h/w interrupts, but maybe we should add "volatile"
>> just in case?
>
> spinlocks also serve as a memory barrier. volatile would guarantee only
> that the compiler doesn't reorder the write, so it wouldn't be enough
> alone. Otoh, we may also need to add spinlocking to the interrupt
> handler if the issue turns out to be that we can't access some register
> past/before intel_runtime_pm_{disable,enable}_interrupts.
>
> --Imre
If we were getting interrupts during the enabling sequence, there would
be three possibilities:
1. compiler has delayed writeback. This would be a compiler bug
(IMHO) but 'volatile' might fix it.
2. the 'restore' thread has written the value, but it isn't seen
by the thread handling the interrupt (on a different cpu?).
This would be a coherency issue, and a memory barrier should
fix it. But I would have expected the variable to be in
coherent memory anyway.
3. the GPU h/w sending interrupts before they're enabled :(
But I suspect this might be during *disabling* the interrupt. Possibly a
race condition in which the h/w has already generated an interrupt
before it's disabled, but that interrupt has not yet been fielded; so
that by the time the interrupt handler runs (on a different CPU from the
'suspend' thread), the write to the variable can have happened and then
the new value is seen by the interrupt handler.
In which case the tweak above will reduce but not necessarily eliminate
the window; it will ensure that if the handler has got at least as far
as taking the spinlock before the suspend thread, then the write w
[Intel-gfx] [PATCH 3/4] drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c
On to, 2015-02-19 at 12:25 +, Dave Gordon wrote: > On 12/02/15 22:38, Imre Deak wrote: > > On Tue, 2015-02-03 at 11:30 +0100, Daniel Vetter wrote: > >> UMS is no more! > >> > >> Signed-off-by: Daniel Vetter > > Some machines now won't boot in "recovery mode", which specifies > "nomodeset" and therefore results in various important bits of code not > being executed. Will we eventually ignore "modeset" completely, or just > refuse to load at all if "nomodeset" is explicitly specified? The driver will already refuse to load with nomodeset for GEN6+ for quite some time now. On old platforms UMS would still work before this patch, but afaik there was a decision to stop supporting UMS. Note that this doesn't mean "recovery mode" or equivalently nomodeset will break booting, it just means user space will fall back to vesa/vga or text mode. --Imre
[Bug 14596] radeon DRI driver produces garbled console with KMS enabled on Thinkpad T42
https://bugzilla.kernel.org/show_bug.cgi?id=14596 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #14 from Alan --- This bug relates to a very old kernel. Closing as obsolete. Please reopen if seen on a modern 3.x kernel (3.10+ say) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal
https://bugs.freedesktop.org/show_bug.cgi?id=88561 --- Comment #7 from Lorenzo Bona --- (In reply to Marek Olšák from comment #6) > Created attachment 113659 [details] [review] > possible fix > > Please test this patch. It seems to fix the bug for the apitrace. Thank you Marek. Your patch fix this bug https://bugs.freedesktop.org/show_bug.cgi?id=88978 too. Nice. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/974f5b6f/attachment.html>
[GIT PULL] drm/tegra: Fixes for v3.20-rc1
Hi Dave, The following changes since commit 45ee2dbc65cbf6910892c480e6f428be342fa733: Merge branch 'drm-next-3.20' of git://people.freedesktop.org/~agd5f/linux into drm-next (2015-02-16 13:55:49 +1000) are available in the git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-3.20-rc1-fixes for you to fetch changes up to 07d05cbf60ed8f06c61484d3d85c06c1aa7edf38: drm/tegra: dc: Move more code into ->init() (2015-02-19 14:21:51 +0100) Thanks, Thierry drm/tegra: Fixes for v3.20-rc1 This fixes a bit of fallout that was caused by the atomic modesetting driver conversion and some last-minute changes in the DRM atomic core. It also fixes a bug exposed by recent changes in the clock framework which results in non-working HDMI. Thierry Reding (4): drm/tegra: hdmi: Explicitly set clock rate drm/tegra: dc: Reset state's active_changed field drm/tegra: dc: Wire up CRTC parent of atomic state drm/tegra: dc: Move more code into ->init() drivers/gpu/drm/tegra/dc.c | 79 ++-- drivers/gpu/drm/tegra/hdmi.c | 8 + 2 files changed, 48 insertions(+), 39 deletions(-)
[Bug 89228] Regression with left for dead 2
https://bugs.freedesktop.org/show_bug.cgi?id=89228 Bug ID: 89228 Summary: Regression with left for dead 2 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: kdj0c at djinvi.net QA Contact: dri-devel at lists.freedesktop.org L4d2 used to work with mesa 10.3, I now have graphical glitches, and it ends up in GPU hang after ~5min of game. might be related to https://bugs.freedesktop.org/show_bug.cgi?id=88561 Hardware is Radeon HD7950 llvm 3.7svn, Linux 3.19.0-g18320f2 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD TAHITI OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.0-devel (git-9216348) OpenGL core profile shading language version string: 3.30 I'm uploading an apitrace, will add a comment with the link when it's done. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/fc78dcba/attachment.html>
[Bug 89059] Dota crashes constantly before 10min mark
https://bugs.freedesktop.org/show_bug.cgi?id=89059 --- Comment #10 from Sebastian Parborg --- (In reply to Jarkko K from comment #9) > How can I swap between those 2? > > I don't know what linux mint 17.1 uses as default. You can see it in your Xorg log. If it manages to load "radeon_drv.so" and/or "ati_drv.so", and them prints: (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), With a long list of cards, then you are using the video-ati modesetting driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/5935719d/attachment.html>
[PATCH] drm: Adding edp1.4 specific dpcd macros
Adding dpcd macros related to edp1.4 and link rates v2: Added DP_SUPPORTED_LINK_RATES macros Signed-off-by: Sonika Jindal --- include/drm/drm_dp_helper.h |8 1 file changed, 8 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 11f8c84..77a55e2 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -92,6 +92,9 @@ # define DP_MSA_TIMING_PAR_IGNORED (1 << 6) /* eDP */ # define DP_OUI_SUPPORT(1 << 7) +#define DP_SUPPORTED_LINK_RATES0x010 /*eDP 1.4*/ +#define DP_MAX_SUPPORTED_RATES 0x8 + #define DP_I2C_SPEED_CAP 0x00c/* DPI */ # define DP_I2C_SPEED_1K 0x01 # define DP_I2C_SPEED_5K 0x02 @@ -101,6 +104,7 @@ # define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ +# define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */ #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ /* Multiple stream transport */ @@ -221,6 +225,8 @@ # define DP_UP_REQ_EN (1 << 1) # define DP_UPSTREAM_IS_SRC(1 << 2) +#define DP_LINK_RATE_SET 0x115 + #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE (1 << 0) # define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) @@ -332,6 +338,8 @@ # define DP_SET_POWER_D30x2 # define DP_SET_POWER_MASK 0x3 +#define DP_EDP_DPCD_REV 0x700 + #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ -- 1.7.10.4
[Intel-gfx] [KERNEL] Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61
On Thu, 2015-02-19 at 10:47 +, Dave Gordon wrote:
> On 18/02/15 16:24, Imre Deak wrote:
> > On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
> >> On Tue, 17 Feb 2015, Klaus Ethgen wrote:
> >>> After solving the conflicts, I applied the revert (see attachment) to
> >>> v3.18.7. I think it should also apply to the current head. With that
> >>> patch, suspend is working again on that version.
> >>>
> >>> However, I have not to deep knowledge of that subsystem, so please,
> >>> someone who have, have a deeper look into it. I especially do not know
> >>> if the lines in .../intel_pm.c are correct or better leaving them as
> >>> they are in v3.18.7.
> >>>
> >>> I want to have it working on a version that I know is stable before
> >>> asking to pull it to head.
> >>
> >> Hi Klaus, we fear this patch may hide the actual cause. Would be useful
> >> to get a better description of what happens, along with a dmesg with
> >> drm.debug=14 module parameter set. This might clutter the mailing list,
> >> would you mind filing a bug at [1] and attach the info there?
> >>
> >> Thanks,
> >> Jani.
> >>
> >> [1]
> >> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
> >
> > In addition to the above could you also try the following patch and
> > provide a dmesg log on the bugzilla ticket - at this point only to try
> > to narrow down the issue?:
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index d358ce8..02c65f4 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -4466,6 +4466,14 @@ static irqreturn_t i965_irq_handler(int irq, void
> > *arg)
> > I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
> > I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
> >
> > + if (!intel_irqs_enabled(dev_priv)) {
> > + if (printk_ratelimit())
> > + DRM_ERROR("spurious/shared interrupt iir %08x imr %08x
> > ier %08x\n",
> > + I915_READ(IIR), I915_READ(IMR),
> > I915_READ(IER));
> > +
> > + return IRQ_NONE;
> > + }
> > +
> > iir = I915_READ(IIR);
> >
> > for (;;) {
> > @@ -4766,7 +4774,10 @@ void intel_runtime_pm_disable_interrupts(struct
> > drm_device *dev)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > dev->driver->irq_uninstall(dev);
> > +
> > + spin_lock_irq(&dev_priv->irq_lock);
> > dev_priv->pm._irqs_disabled = true;
> > + spin_unlock_irq(&dev_priv->irq_lock);
> > }
> >
> > /* Restore interrupts so we can recover from runtime PM. */
> > @@ -4774,7 +4785,10 @@ void intel_runtime_pm_restore_interrupts(struct
> > drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > + spin_lock_irq(&dev_priv->irq_lock);
> > dev_priv->pm._irqs_disabled = false;
> > + spin_unlock_irq(&dev_priv->irq_lock);
> > +
> > dev->driver->irq_preinstall(dev);
> > dev->driver->irq_postinstall(dev);
> > }
>
> Surely surrounding (what ought to be) an atomic assignment to a single
> variable cannot make a difference? Unless it's the memory barrier
> semantics that have some effect? It seems unlikely that the compiler has
> deferred the write to the variable past the pre/postinstall calls that
> actually enable the h/w interrupts, but maybe we should add "volatile"
> just in case?
spinlocks also serve as a memory barrier. volatile would guarantee only
that the compiler doesn't reorder the write, so it wouldn't be enough
alone. Otoh, we may also need to add spinlocking to the interrupt
handler if the issue turns out to be that we can't access some register
past/before intel_runtime_pm_{disable,enable}_interrupts.
--Imre
[Intel-gfx] [PATCH 3/4] drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c
On 12/02/15 22:38, Imre Deak wrote: > On Tue, 2015-02-03 at 11:30 +0100, Daniel Vetter wrote: >> UMS is no more! >> >> Signed-off-by: Daniel Vetter Some machines now won't boot in "recovery mode", which specifies "nomodeset" and therefore results in various important bits of code not being executed. Will we eventually ignore "modeset" completely, or just refuse to load at all if "nomodeset" is explicitly specified? .Dave.
[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal
https://bugs.freedesktop.org/show_bug.cgi?id=88561 --- Comment #6 from Marek Olšák --- Created attachment 113659 --> https://bugs.freedesktop.org/attachment.cgi?id=113659&action=edit possible fix Please test this patch. It seems to fix the bug for the apitrace. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/1e791f76/attachment.html>
[PATCH] drm/cma: Fix 64-bit size_t build warnings
On Thu, Feb 19, 2015 at 2:06 AM, Magnus Damm wrote:
> From: Magnus Damm
>
> Fix warnings related to size_t when building for 64-bit architectures:
>
> drivers/gpu/drm/drm_gem_cma_helper.c: In function
> ââ¬Ëdrm_gem_cma_createââ¬â¢:
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
But the atcual content is UTF8?
> drivers/gpu/drm/drm_gem_cma_helper.c:114:4: warning: format ââ¬Ë%dââ¬â¢
> expects argument of type ââ¬Ëintââ¬â¢, but argument 3 has type
> ââ¬Ësize_tââ¬â¢ [-Wformat=]
> size);
> ^
> drivers/gpu/drm/drm_gem_cma_helper.c: In function
> ââ¬Ëdrm_gem_cma_describeââ¬â¢:
> drivers/gpu/drm/drm_gem_cma_helper.c:393:4: warning: format ââ¬Ë%dââ¬â¢
> expects argument of type ââ¬Ëintââ¬â¢, but argument 8 has type
> ââ¬Ësize_tââ¬â¢ [-Wformat=]
> off, &cma_obj->paddr, cma_obj->vaddr, obj->size);
>
> Signed-off-by: Magnus Damm
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #45 from Lorenzo Bona --- Since yesterday I've been testing last drm-fixes-3.19 kernel with old radeon firmwares. I mean before big upgrade on 24th of July. I've played Dota2 and watched videos on flash and on mpv with vdpau, and I can't reproduce those warnings anymore. But while I play I can see these: [10319.747657] radeon :07:00.0: GPU fault detected: 146 0x0b080404 [10319.747665] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00017258 [10319.747670] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x08004004 [10319.747675] VM fault (0x04, vmid 4) at page 94808, read from TC (4) [12134.226711] radeon :07:00.0: GPU fault detected: 146 0x0b084404 [12134.226719] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00017258 [12134.226724] radeon :07:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x08044004 [12134.226728] VM fault (0x04, vmid 4) at page 94808, read from TC (68) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/7d93616d/attachment.html>
[PATCH 7/7] drm/exynos: track vblank events on a per crtc basis
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: Mandeep Singh Baines
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 92 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 -
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 +--
3 files changed, 44 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 47dd2b0..eb49195 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
- !atomic_read(&exynos_crtc->pending_flip),
- HZ/20))
- atomic_set(&exynos_crtc->pending_flip, 0);
+ (exynos_crtc->event == NULL), HZ/20))
+ exynos_crtc->event = NULL;
drm_crtc_vblank_off(crtc);
}
@@ -164,11 +163,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
uint32_t page_flip_flags)
{
struct drm_device *dev = crtc->dev;
- struct exynos_drm_private *dev_priv = dev->dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
- int ret = -EINVAL;
+ int ret;
/* when the page flip is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -176,48 +174,49 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
return -EINVAL;
}
- mutex_lock(&dev->struct_mutex);
+ if (!event)
+ return -EINVAL;
- if (event) {
- /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
- event->pipe = exynos_crtc->pipe;
+ spin_lock_irq(&dev->event_lock);
+ if (exynos_crtc->event) {
+ ret = -EBUSY;
+ goto out;
+ }
- ret = drm_vblank_get(dev, exynos_crtc->pipe);
- if (ret) {
- DRM_DEBUG("failed to acquire vblank counter\n");
+ ret = drm_vblank_get(dev, exynos_crtc->pipe);
+ if (ret) {
+ DRM_DEBUG("failed to acquire vblank counter\n");
+ goto out;
+ }
- goto out;
- }
+ exynos_crtc->event = event;
+ spin_unlock_irq(&dev->event_lock);
+ /*
+* the pipe from user always is 0 so we can set pipe number
+* of current owner to event.
+*/
+ event->pipe = exynos_crtc->pipe;
+
+ crtc->primary->fb = fb;
+ crtc_w = fb->width - crtc->x;
+ crtc_h = fb->height - crtc->y;
+ ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, crtc->x, crtc->y,
+ crtc_w, crtc_h);
+ if (ret) {
+ crtc->primary->fb = old_fb;
spin_lock_irq(&dev->event_lock);
- list_add_tail(&event->base.link,
- &dev_priv->pageflip_event_list);
- atomic_set(&exynos_crtc->pending_flip, 1);
+ exynos_crtc->event = NULL;
+ drm_vblank_put(dev, exynos_crtc->pipe);
spin_unlock_irq(&dev->event_lock);
-
- crtc->primary->fb = fb;
- crtc_w = fb->width - crtc->x;
- crtc_h = fb->height - crtc->y;
- ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
- if (ret) {
- crtc->primary->fb = old_fb;
-
- spin_lock_irq(&dev->event_lock);
- drm_vblank_put(dev, exynos_crtc->pipe);
- list_del(&event->base.link);
- atomic_set(&exynos_crtc->pending_flip, 0);
- spin_unlock_irq(&dev->event_lock);
-
- goto out;
- }
+ return ret;
}
+
+ return 0;
+
out:
- mutex_
[PATCH 6/7] drm/exynos: remove leftover functions declarations
From: Gustavo Padovan These functions were already removed by previous cleanup work, but these ones were left behind. Signed-off-by: Gustavo Padovan Acked-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h b/drivers/gpu/drm/exynos/exynos_drm_crtc.h index e1fd2ef..0ecd8fc 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h @@ -28,12 +28,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe); void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe); void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb); -void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc, - struct exynos_drm_plane *plane); -void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos); -void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos); -void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos); - /* This function gets pipe value to crtc device matched with out_type. */ int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev, unsigned int out_type); -- 2.1.0
[PATCH 5/7] drm/exynos: remove exynos_plane_destroy()
From: Gustavo Padovan
The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 2fbac9b..2b0479e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -178,16 +178,10 @@ static int exynos_disable_plane(struct drm_plane *plane)
return 0;
}
-static void exynos_plane_destroy(struct drm_plane *plane)
-{
- exynos_disable_plane(plane);
- drm_plane_cleanup(plane);
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = exynos_update_plane,
.disable_plane = exynos_disable_plane,
- .destroy= exynos_plane_destroy,
+ .destroy= drm_plane_cleanup,
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
--
2.1.0
[PATCH 4/7] drm/exynos: make zpos property immutable
From: Gustavo Padovan
We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 504bd6e..2fbac9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -184,27 +184,10 @@ static void exynos_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
}
-static int exynos_plane_set_property(struct drm_plane *plane,
-struct drm_property *property,
-uint64_t val)
-{
- struct drm_device *dev = plane->dev;
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- struct exynos_drm_private *dev_priv = dev->dev_private;
-
- if (property == dev_priv->plane_zpos_property) {
- exynos_plane->zpos = val;
- return 0;
- }
-
- return -EINVAL;
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = exynos_update_plane,
.disable_plane = exynos_disable_plane,
.destroy= exynos_plane_destroy,
- .set_property = exynos_plane_set_property,
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
@@ -216,8 +199,8 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
prop = dev_priv->plane_zpos_property;
if (!prop) {
- prop = drm_property_create_range(dev, 0, "zpos", 0,
-MAX_PLANE - 1);
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+"zpos", 0, MAX_PLANE - 1);
if (!prop)
return;
--
2.1.0
[PATCH 3/7] drm/exynos: preset zpos value for overlay planes
From: Gustavo Padovan
Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.
Also all places that were storing zpos positions are now unsigned int.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 20 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 7 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 16 +---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 +
drivers/gpu/drm/exynos/exynos_mixer.c | 11 +--
7 files changed, 37 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 2cbe328..bee1f72 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -378,7 +378,7 @@ static void decon_win_set_colkey(struct decon_context *ctx,
unsigned int win)
* @protect: 1 to protect (disable updates)
*/
static void decon_shadow_protect_win(struct decon_context *ctx,
- int win, bool protect)
+unsigned int win, bool protect)
{
u32 bits, val;
@@ -392,12 +392,12 @@ static void decon_shadow_protect_win(struct decon_context
*ctx,
writel(val, ctx->regs + SHADOWCON);
}
-static void decon_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *mode = &crtc->base.mode;
struct exynos_drm_plane *plane;
- int padding, win = zpos;
+ int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
@@ -405,9 +405,6 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
int zpos)
if (ctx->suspended)
return;
- if (win == DEFAULT_ZPOS)
- win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;
@@ -513,16 +510,12 @@ static void decon_win_commit(struct exynos_drm_crtc
*crtc, int zpos)
plane->enabled = true;
}
-static void decon_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
- int win = zpos;
u32 val;
- if (win == DEFAULT_ZPOS)
- win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;
@@ -764,7 +757,8 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
enum drm_plane_type type;
- int zpos, ret;
+ unsigned int zpos;
+ int ret;
ret = decon_ctx_initialize(ctx, drm_dev);
if (ret) {
@@ -776,7 +770,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, &ctx->planes[zpos], 1 << ctx->pipe,
- type);
+ type, zpos);
}
exynos_plane = &ctx->planes[ctx->default_win];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8a2f943..26d6de1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -21,7 +21,6 @@
#define MAX_CRTC 3
#define MAX_PLANE 5
#define MAX_FB_BUFFER 4
-#define DEFAULT_ZPOS -1
#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc, base)
#define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
@@ -104,7 +103,7 @@ struct exynos_drm_plane {
unsigned int pitch;
uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
- int zpos;
+ unsigned int zpos;
unsigned int index_color;
bool default_win:1;
@@ -189,8 +188,8 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
- void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
- void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
+ void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+ void (*win_disable)
[PATCH 2/7] drm/exynos: remove struct *_win_data abstraction on planes
From: Gustavo Padovan
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 164 --
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c| 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h| 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 +
drivers/gpu/drm/exynos/exynos_drm_plane.c | 23 +---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 -
drivers/gpu/drm/exynos/exynos_mixer.c | 212 ++---
10 files changed, 242 insertions(+), 497 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..2cbe328 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -28,6 +28,7 @@
#include
#include "exynos_drm_crtc.h"
+#include "exynos_drm_plane.h"
#include "exynos_drm_drv.h"
#include "exynos_drm_fbdev.h"
#include "exynos_drm_iommu.h"
@@ -41,32 +42,16 @@
#define WINDOWS_NR 2
-struct decon_win_data {
- unsigned intovl_x;
- unsigned intovl_y;
- unsigned intoffset_x;
- unsigned intoffset_y;
- unsigned intovl_width;
- unsigned intovl_height;
- unsigned intfb_width;
- unsigned intfb_height;
- unsigned intbpp;
- unsigned intpixel_format;
- dma_addr_t dma_addr;
- boolenabled;
- boolresume;
-};
-
struct decon_context {
struct device *dev;
struct drm_device *drm_dev;
struct exynos_drm_crtc *crtc;
+ struct exynos_drm_plane planes[WINDOWS_NR];
struct clk *pclk;
struct clk *aclk;
struct clk *eclk;
struct clk *vclk;
void __iomem*regs;
- struct decon_win_data win_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long irq_flags;
booli80_if;
@@ -296,59 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc
*crtc)
}
}
-static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
- struct exynos_drm_plane *plane)
-{
- struct decon_context *ctx = crtc->ctx;
- struct decon_win_data *win_data;
- int win, padding;
-
- if (!plane) {
- DRM_ERROR("plane is NULL\n");
- return;
- }
-
- win = plane->zpos;
- if (win == DEFAULT_ZPOS)
- win = ctx->default_win;
-
- if (win < 0 || win >= WINDOWS_NR)
- return;
-
-
- win_data = &ctx->win_data[win];
-
- padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
- win_data->offset_x = plane->fb_x;
- win_data->offset_y = plane->fb_y;
- win_data->fb_width = plane->fb_width + padding;
- win_data->fb_height = plane->fb_height;
- win_data->ovl_x = plane->crtc_x;
- win_data->ovl_y = plane->crtc_y;
- win_data->ovl_width = plane->crtc_width;
- win_data->ovl_height = plane->crtc_height;
- win_data->dma_addr = plane->dma_addr[0];
- win_data->bpp = plane->bpp;
- win_data->pixel_format = plane->pixel_format;
-
- DRM_DEBUG_KMS("offset_x = %d, offset_y = %d\n",
- win_data->offset_x, win_data->offset_y);
- DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
- win_data->ovl_width, win_data->ovl_height);
- DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
- DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
- plane->fb_width, plane->crtc_width);
-}
-
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
{
- struct decon_win_data *win_data = &ctx->win_data[win];
+ struct exynos_drm_plane *plane = &ctx->planes[win];
unsigned long val;
+ int padding;
val = readl(ctx->regs + WINCON(win));
val &= ~WINCONx_BPPMODE_MASK;
- switch (win_data->pixel_format) {
+ switch (plane->pixel_format) {
case DRM_FORMAT_RGB565:
val |= WINCONx_BPPMODE_16BPP_565;
val |= WINCONx_BURSTLEN_16WORD;
@@ -397,7 +339,7 @@ static void decon_win_set_pixfmt(struc
[PATCH 1/7] drm/exynos: remove unused exynos_crtc->win_enable() callback
From: Gustavo Padovan
None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9afd390..4e8f0b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -174,7 +174,6 @@ struct exynos_drm_display {
* hardware overlay is updated.
* @win_mode_set: copy drm overlay info to hw specific overlay info.
* @win_commit: apply hardware specific overlay data to registers.
- * @win_enable: enable hardware specific overlay.
* @win_disable: disable hardware specific overlay.
* @te_handler: trigger to transfer video image at the tearing effect
* synchronization signal if there is a page flip request.
@@ -192,7 +191,6 @@ struct exynos_drm_crtc_ops {
void (*win_mode_set)(struct exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane);
void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
- void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
};
--
2.1.0
[PATCH 0/7] drm/exynos: clean ups
From: Gustavo Padovan Hi, Here goes some clean ups to the exynos drivers. The main clean ups is the presetting and zpos making the property immutable and the removal of *_win_data structures. Gustavo Padovan (6): drm/exynos: remove unused exynos_crtc->win_enable() callback drm/exynos: remove struct *_win_data abstraction on planes drm/exynos: preset zpos value for overlay planes drm/exynos: make zpos property immutable drm/exynos: remove exynos_plane_destroy() drm/exynos: remove leftover functions declarations Mandeep Singh Baines (1): drm/exynos: track vblank events on a per crtc basis drivers/gpu/drm/exynos/exynos7_drm_decon.c | 176 +-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 101 ++ drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.c| 27 drivers/gpu/drm/exynos/exynos_drm_drv.h| 20 +-- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 195 ++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 66 +++-- drivers/gpu/drm/exynos/exynos_drm_plane.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 134 +- drivers/gpu/drm/exynos/exynos_mixer.c | 217 ++--- 10 files changed, 311 insertions(+), 639 deletions(-) -- 2.1.0
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #8 from Igor Ulyanov --- kernel 3.19 and xf86-video-ati current git version fixed similar problem for me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/4dfb6a1d/attachment.html>
[Intel-gfx] [KERNEL] Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61
On 18/02/15 16:24, Imre Deak wrote:
> On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
>> On Tue, 17 Feb 2015, Klaus Ethgen wrote:
>>> After solving the conflicts, I applied the revert (see attachment) to
>>> v3.18.7. I think it should also apply to the current head. With that
>>> patch, suspend is working again on that version.
>>>
>>> However, I have not to deep knowledge of that subsystem, so please,
>>> someone who have, have a deeper look into it. I especially do not know
>>> if the lines in .../intel_pm.c are correct or better leaving them as
>>> they are in v3.18.7.
>>>
>>> I want to have it working on a version that I know is stable before
>>> asking to pull it to head.
>>
>> Hi Klaus, we fear this patch may hide the actual cause. Would be useful
>> to get a better description of what happens, along with a dmesg with
>> drm.debug=14 module parameter set. This might clutter the mailing list,
>> would you mind filing a bug at [1] and attach the info there?
>>
>> Thanks,
>> Jani.
>>
>> [1]
>> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
>
> In addition to the above could you also try the following patch and
> provide a dmesg log on the bugzilla ticket - at this point only to try
> to narrow down the issue?:
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d358ce8..02c65f4 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4466,6 +4466,14 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
> I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
> I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
>
> + if (!intel_irqs_enabled(dev_priv)) {
> + if (printk_ratelimit())
> + DRM_ERROR("spurious/shared interrupt iir %08x imr %08x
> ier %08x\n",
> + I915_READ(IIR), I915_READ(IMR),
> I915_READ(IER));
> +
> + return IRQ_NONE;
> + }
> +
> iir = I915_READ(IIR);
>
> for (;;) {
> @@ -4766,7 +4774,10 @@ void intel_runtime_pm_disable_interrupts(struct
> drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> dev->driver->irq_uninstall(dev);
> +
> + spin_lock_irq(&dev_priv->irq_lock);
> dev_priv->pm._irqs_disabled = true;
> + spin_unlock_irq(&dev_priv->irq_lock);
> }
>
> /* Restore interrupts so we can recover from runtime PM. */
> @@ -4774,7 +4785,10 @@ void intel_runtime_pm_restore_interrupts(struct
> drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> + spin_lock_irq(&dev_priv->irq_lock);
> dev_priv->pm._irqs_disabled = false;
> + spin_unlock_irq(&dev_priv->irq_lock);
> +
> dev->driver->irq_preinstall(dev);
> dev->driver->irq_postinstall(dev);
> }
Surely surrounding (what ought to be) an atomic assignment to a single
variable cannot make a difference? Unless it's the memory barrier
semantics that have some effect? It seems unlikely that the compiler has
deferred the write to the variable past the pre/postinstall calls that
actually enable the h/w interrupts, but maybe we should add "volatile"
just in case?
.Dave.
drm: bridge: ps8622 and ptn3460 depend on gpiolib
On Wed, Feb 18, 2015 at 05:09:25PM +0100, Arnd Bergmann wrote:
> The ptn3460 driver recently started usign the gpiod interface
> which is only available on platforms that come with GPIOLIB
> support, resulting in a compile-time error:
>
> drivers/gpu/drm/bridge/ps8622.c: In function 'ps8622_pre_enable':
> drivers/gpu/drm/bridge/ps8622.c:368:2: error: implicit declaration of
> function 'gpiod_set_value' [-Werror=implicit-function-declaration]
> gpiod_set_value(ps8622->gpio_rst, 0);
> ^
> drivers/gpu/drm/bridge/ps8622.c: In function 'ps8622_probe':
> drivers/gpu/drm/bridge/ps8622.c:584:2: error: implicit declaration of
> function 'devm_gpiod_get' [-Werror=implicit-function-declaration]
> ps8622->gpio_slp = devm_gpiod_get(dev, "sleep");
> ^
>
> Similarly, the newly added ps8622 driver started out with the same
> problem.
>
> This patch adds explicit Kconfig dependencies to avoid trying to
> build invalid configurations.
>
> Signed-off-by: Arnd Bergmann
> Fixes: f1336e6afb ("drm/bridge: Add I2C based driver for ps8622/ps8625
> bridge")
> Fixes: af478d8823 ("drm/bridge: ptn3460: use gpiod interface")
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/355be74c/attachment-0001.sig>
[PATCH] drm/cma: Fix 64-bit size_t build warnings
From: Magnus Damm
Fix warnings related to size_t when building for 64-bit architectures:
drivers/gpu/drm/drm_gem_cma_helper.c: In function âdrm_gem_cma_createâ:
drivers/gpu/drm/drm_gem_cma_helper.c:114:4: warning: format â%dâ expects
argument of type âintâ, but argument 3 has type âsize_tâ [-Wformat=]
size);
^
drivers/gpu/drm/drm_gem_cma_helper.c: In function âdrm_gem_cma_describeâ:
drivers/gpu/drm/drm_gem_cma_helper.c:393:4: warning: format â%dâ expects
argument of type âintâ, but argument 8 has type âsize_tâ [-Wformat=]
off, &cma_obj->paddr, cma_obj->vaddr, obj->size);
Signed-off-by: Magnus Damm
---
drivers/gpu/drm/drm_gem_cma_helper.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 0001/drivers/gpu/drm/drm_gem_cma_helper.c
+++ work/drivers/gpu/drm/drm_gem_cma_helper.c 2015-02-19 06:29:39.155526831
+0900
@@ -110,7 +110,7 @@ struct drm_gem_cma_object *drm_gem_cma_c
cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
&cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
if (!cma_obj->vaddr) {
- dev_err(drm->dev, "failed to allocate buffer with size %d\n",
+ dev_err(drm->dev, "failed to allocate buffer with size %zu\n",
size);
ret = -ENOMEM;
goto error;
@@ -388,7 +388,7 @@ void drm_gem_cma_describe(struct drm_gem
off = drm_vma_node_start(&obj->vma_node);
- seq_printf(m, "%2d (%2d) %08llx %pad %p %d",
+ seq_printf(m, "%2d (%2d) %08llx %pad %p %zu",
obj->name, obj->refcount.refcount.counter,
off, &cma_obj->paddr, cma_obj->vaddr, obj->size);
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #7 from Igor Ulyanov --- Please check your kernel version and if it is outdated test with at least 3.19 and rebuilded xf86-video-ati. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/2a36909a/attachment.html>
[Bug 89164] AMD Kaveri: gbm_bo_get_stride returns wrong values for cursor buffers
https://bugs.freedesktop.org/show_bug.cgi?id=89164 --- Comment #3 from Michel Dänzer --- (In reply to Andreas Pokorny from comment #2) > Yes, but since buffer creation with a smaller size does not fail, > gbm_bo_get_stride should return the right size. It returns the stride of the allocated buffer. The problem is that the buffer size doesn't match the hardware cursor size in the first place. Returning a different stride can't change that. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/3d94cfcf/attachment-0001.html>
[Bug 89059] Dota crashes constantly before 10min mark
https://bugs.freedesktop.org/show_bug.cgi?id=89059 --- Comment #9 from Jarkko K --- How can I swap between those 2? I don't know what linux mint 17.1 uses as default. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/a1c3fcd9/attachment.html>
[Bug 89164] AMD Kaveri: gbm_bo_get_stride returns wrong values for cursor buffers
https://bugs.freedesktop.org/show_bug.cgi?id=89164 --- Comment #2 from Andreas Pokorny --- (In reply to Michel Dänzer from comment #1) > You need to pass the dimensions queried from DRM_CAP_CURSOR_WIDTH and > DRM_CAP_CURSOR_HEIGHT instead of hardcoding 64. As of CIK, Radeon hardware > only supports 256x256 hardware cursors. Yes, but since buffer creation with a smaller size does not fail, gbm_bo_get_stride should return the right size. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/f1e33c9b/attachment.html>
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 Christian König changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment #39 from Christian König --- Created attachment 113654 --> https://bugs.freedesktop.org/attachment.cgi?id=113654&action=edit Possible fix Wow, nice catch! I have to admit that i just copied the sleep mode handling from previous generations. Well, in this case please everybody on this bug take a look at the attached patch and see if it does the trick. Thanks a lot for the help, Christian. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/9a2ee0cc/attachment.html>
[Bug 74329] Please expose OES_texture_float and OES_texture_half_float on the ES3 context
https://bugs.freedesktop.org/show_bug.cgi?id=74329 --- Comment #3 from Matt Turner --- The Mesa core support was added in this commit: commit a63c8a524b01e802cf2505099f930c0cb97df0b2 Author: Kalyan Kondapally Date: Wed Jan 7 20:30:25 2015 -0800 Mesa: Add support for GL_OES_texture_*float* extensions. This patch series adds support for following GLES2 Texture Float extensions: 1)GL_OES_texture_float, 2)GL_OES_texture_half_float, 3)GL_OES_texture_float_linear, 4)GL_OES_texture_half_float_linear. Gallium drivers just need to enable the extensions now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/ed8c39ca/attachment.html>
[Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 --- Comment #7 from smoki --- The best is if you can bisect mesa, if 10.3 worked fine it should be easy :) Or try various settings in game, might be only one which trigger slow case. Or if someone other want to reproduce it, apitrace trace will be usefull, etc... Otherwise more info is needed, like: Which version of Minecraft? Java or openjdk used? Did you use optifine? You might post your options.txt file, because as i said it might only happen with exact settings and also optionsof.txt in case you use optifine, etc... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/d153789c/attachment.html>
[Bug 89059] Dota crashes constantly before 10min mark
https://bugs.freedesktop.org/show_bug.cgi?id=89059 Sebastian Parborg changed: What|Removed |Added CC||darkdefende at gmail.com --- Comment #8 from Sebastian Parborg --- This might not be related at all, but are you using "xf86-video-ati" for mode setting or the "modesetting" driver that comes with Xorg? I switched to the modesetting one because I saw that you could gain a couple fps when doing so. I got a few more fps (1-8fps) in the games I tried. But when I try to play Dota2 it hard locks after a while. The computer doesn't freeze but I have to manually kill dota2. When switching back to video-ati, I haven't gotten any of these hard locks yet. Perhaps they are unrelated, or the same thing that managed to hardlock Dota2 with the "modesetting" driver is doing the same thing to you. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/596f4e13/attachment-0001.html>
[PATCH v5 8/9] ARM: dts: exynos5250: add display power domain
Am 02.02.2015 um 14:20 schrieb Marek Szyprowski: > From: Andrzej Hajda > > The patch adds domain definition and references to it in appropriate devices. > > Signed-off-by: Andrzej Hajda > [mszyprow: rebased onto generic power domains dt bindings] > Signed-off-by: Marek Szyprowski > Tested-by: Javier Martinez Canillas > Reviewed-by: Javier Martinez Canillas On Spring, Tested-by: Andreas Färber Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
[PATCH v5 7/9] ARM: dts: Exynos: add 'hdmi' clock to mixer nodes
Am 02.02.2015 um 14:20 schrieb Marek Szyprowski:
> Mixed block needs to control hdmi clock to properly perform power on/off
> operation, so add 'hdmi' clock also to mixer nodes.
>
> Signed-off-by: Marek Szyprowski
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 5 +++--
> arch/arm/boot/dts/exynos5420.dtsi | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 9bb1b0b738f5..e8c67fdb69fb 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,8 +732,9 @@
> compatible = "samsung,exynos5250-mixer";
> reg = <0x1445 0x1>;
> interrupts = <0 94 0>;
> - clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>;
> - clock-names = "mixer", "sclk_hdmi";
> + clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
> + <&clock CLK_SCLK_HDMI>;
> + clock-names = "mixer", "hdmi", "sclk_hdmi";
> };
>
> dp_phy: video-phy at 10040720 {
[snip]
Tested-by: Andreas Färber
Without this patch, next-20150218 exynos drm mixer fails to locate the
hdmi clock on Spring.
Kukjin, can you please queue the remaining patches 1-8?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
[Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 --- Comment #6 from andre35822 at yahoo.com --- (In reply to Michel Dänzer from comment #4) > Does it work better with the current Mesa Git 10.4 or master branch? Uh I am not sure, it runs fine on 10.4 at acceptable framerates, sometimes a bit over 100 but once chunks starts to load (more of the map loads) I get a massive frame drop to 1 or 0 and then while it starts catching back up it just stutters). I just tried 10.6-git from arch AUR and its acts pretty much the same as 10.4 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/f9ac69b6/attachment.html>
[Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 --- Comment #5 from andre35822 at yahoo.com --- (In reply to smoki from comment #3) > Try mesa git or 10.5.0-rc1 or up, or just patch older mesa... i am mostly > thinking of this patch: > > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=a338dc01866ce50bf7555ee8dc08491c7f63b585 > > Not sure if helps Minecraft exactly, so it is just a guess because i have > another games which stutter similar to what you describe before it. I just tried out mesa-git 10.6 (as that was available in the Arch AUR and I wanted something quick to test) and the stuttering/frame drops still occur. Although entering/exiting fullscreen on 10.6 don't seem to be as buggy as before in Minecraft. I will try 10.3. and see -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/15529765/attachment.html>
[Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 --- Comment #4 from Michel Dänzer --- Does it work better with the current Mesa Git 10.4 or master branch? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150219/02abdfd2/attachment.html>
