[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 --- Comment #6 from Damian Nowak --- Not an LLVM issue, just hung with a downgraded LLVM 3.4. So the problem has to be in mesa. I will now try to find the latest working version of mesa. Starting from 10.1.4 for now. Regarding recent two hangs. One was total, and I had to hard reset. The other, that happened 10 minutes after reboot, wasn't that bad. After `pkill -9 kdm` from SSH I was able to CTRL+ALT+F1. The error was "EQ overflow" again of course, but has got a different stacktrace just a little bit. However, X wasn't able to start again. I had to reboot. [ 480.971] (EE) RADEON(0): [drm] Failed to open DRM device for pci::01:00.0: No such file or directory -- 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/20140706/383ae2dd/attachment.html>
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 --- Comment #7 from Damian Nowak --- Created attachment 102315 --> https://bugs.freedesktop.org/attachment.cgi?id=102315&action=edit Xorg.0.log after the second crash -- 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/20140706/5775c96d/attachment.html>
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 --- Comment #8 from Damian Nowak --- Created attachment 102316 --> https://bugs.freedesktop.org/attachment.cgi?id=102316&action=edit Xorg.0.log after the second crash - trying to start X again -- 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/20140706/32655375/attachment.html>
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 Damian Nowak changed: What|Removed |Added Severity|critical|blocker Version|unspecified |10.2 -- 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/20140706/9f8cd310/attachment.html>
[git pull] drm fixes
On 6 July 2014 12:24, Ed Tomlinson wrote: > Hi Dave, > > This is NOT fixing problems with a stalled boot due to VGA problems as > reported in thread: [PATCH 5/5] drm/i915: Kick out vga console > It can be fixed by reverting: a4de05268e674e8ed31df6348269e22d6c6a1803 > or applying the patch from Chris Wilson which can be found as a reply to my > report. I was hoping Daniel would get to it, but he is on holidays (as am I really!), I'll take a look at the fix when I'm back in the office myself if nobody has sent it to me. Dave.
[PATCH 1/1] drm/omap: remove null test before kfree
Hi On Fri, Jul 4, 2014 at 9:17 PM, Fabian Frederick wrote: > Fix checkpatch warning: > WARNING: kfree(NULL) is safe this check is probably not required > > Cc: David Airlie > Cc: David Herrmann > Cc: Tomi Valkeinen > Cc: dri-devel at lists.freedesktop.org > Signed-off-by: Fabian Frederick Reviewed-by: David Herrmann Thanks David > --- > drivers/gpu/drm/omapdrm/omap_gem.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c > b/drivers/gpu/drm/omapdrm/omap_gem.c > index 95dbce2..be0c2e8 100644 > --- a/drivers/gpu/drm/omapdrm/omap_gem.c > +++ b/drivers/gpu/drm/omapdrm/omap_gem.c > @@ -1183,9 +1183,7 @@ int omap_gem_op_sync(struct drm_gem_object *obj, enum > omap_gem_op op) > } > } > spin_unlock(&sync_lock); > - > - if (waiter) > - kfree(waiter); > + kfree(waiter); > } > return ret; > } > -- > 1.9.1 >
[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 --- Comment #5 from Hadrien --- I am making progress, I can build r600_dri.so in debug mode, make programs use it instead of the version released with Ubuntu and perform step by step debugging. However some functions are located in libgallium.so and I can't figure out how to build that library. The only thing close I get is a static library in a hidden directory with path "src/gallium/auxiliary/.libs" -- 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/20140706/1986813a/attachment-0001.html>
radeon module ignores audio option?
Hello. I tried to disable the HDMI audio (dont use it) via the kernel command line option radeon.audio=0 (latest linus git kernel). But after reboot the HDMI audio device is still detected. Isnt this kernel option supposed to disable it for good? -- O zi buna, Kertesz Laszlo
radeon module ignores audio option?
Am 06.07.2014 16:22, schrieb Kertesz Laszlo: > Hello. > > I tried to disable the HDMI audio (dont use it) via the kernel command > line option radeon.audio=0 (latest linus git kernel). > But after reboot the HDMI audio device is still detected. > Isnt this kernel option supposed to disable it for good? No, it just disables support within the radeon module to send the information necessary for HDMI audio from the gfx hardware to the audio codec. The codec itself is still present and so also detected (while probably not working correctly). Regards, Christian.
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #119 from Martin Andersson --- I have been running 3.15 + plus the latest patch for a couple of days now. So far not a single lockup. -- 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/20140706/419a5832/attachment.html>
[Intel-gfx] [v2 10/11] drm/i915: Add 180 degree primary plane rotation support
On 7/4/2014 8:28 PM, Damien Lespiau wrote:
> On Fri, Jul 04, 2014 at 03:14:02PM +0530, sonika.jindal at intel.com wrote:
>> +static int intel_primary_plane_set_property(struct drm_plane *plane,
>> +struct drm_property *prop,
>> +uint64_t val)
>> +{
>> +struct drm_device *dev = plane->dev;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct intel_plane *intel_plane = to_intel_plane(plane);
>> +struct intel_crtc *intel_crtc = to_intel_crtc(plane->crtc);
>> +struct drm_crtc *crtc = &intel_crtc->base;
>> +uint64_t old_val;
>> +
>> +if (prop == plane->rotation_property) {
>> +/* exactly one rotation angle please */
>> +if (hweight32(val & 0xf) != 1)
>> +return -EINVAL;
>> +
>> +old_val = intel_plane->rotation;
>> +intel_plane->rotation = val;
>> +
>> +if (intel_crtc->active && intel_crtc->primary_enabled) {
>> +intel_crtc_wait_for_pending_flips(crtc);
>> +
>> +/* FBC does not work on some platforms for rotated planes */
>> +if (INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev)) {
>> +if (dev_priv->fbc.plane == intel_crtc->plane &&
>> +intel_plane->rotation !=
>> BIT(DRM_ROTATE_0))
>> +intel_disable_fbc(dev);
>> +/* If rotation was set earlier and new rotation
>> is 0, we might
>> + * have disabled fbc earlier. So update it now
>> */
>> +else if (intel_plane->rotation ==
>> BIT(DRM_ROTATE_0) &&
>> +old_val != BIT(DRM_ROTATE_0))
>> +intel_update_fbc(dev);
>
> I see a intel_update_fbc() called with the struct_mutext lock elsewhere,
> don't we need it here as well?
>
> mutex_lock(&dev->struct_mutex);
> intel_update_fbc(dev);
> mutex_unlock(&dev->struct_mutex);
>
Sure, I'l add that and post the patch.
[PATCH 1/4] drm/dsi: Add flag for continuous clock behavior
On Fri, Jul 4, 2014 at 6:53 PM, Andrzej Hajda wrote: > On 07/04/2014 07:57 AM, Alexandre Courbot wrote: >> Hi Andrejz, >> >> On Thu, Jul 3, 2014 at 5:23 PM, Andrzej Hajda wrote: >>> Hi Alexandre, >>> >>> Thanks for the patch. >>> >>> On 07/02/2014 02:19 PM, Alexandre Courbot wrote: As per section 5.6.1 of the DSI specification, all DSI transmitters must support continuous clock behavior on the clock lane, while non-continuous mode support is only optional. Add a flag that allows devices to indicate that they require continuous clock mode to operate properly. Signed-off-by: Alexandre Courbot --- include/drm/drm_mipi_dsi.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h index 944f33f..5913ef4 100644 --- a/include/drm/drm_mipi_dsi.h +++ b/include/drm/drm_mipi_dsi.h @@ -94,6 +94,8 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host); #define MIPI_DSI_MODE_VSYNC_FLUSHBIT(8) /* disable EoT packets in HS mode */ #define MIPI_DSI_MODE_EOT_PACKET BIT(9) +/* use continuous clock behavior on the clock lane */ +#define MIPI_DSI_MODE_CLOCK_CONTINUOUS BIT(10) >>> According to MIPI DSI specification "All DSI transmitters and receivers >>> shall support continuous clock behavior on the Clock Lane, and >>> optionally may support non-continuous clock behavior". It suggests that >>> continuous clock should be default behavior. So maybe better is to >>> introduce sth like: >>> +#define MIPI_DSI_MODE_CLOCK_NON_CONTINUOUS BIT(10) >> I started under the assumption that current host drivers assumed >> non-continuous clock (as the Tegra driver currently does). > > Exynos DSI driver uses continuous clock. > Currently, in mainline, there are no more dsi hosts using drm_mipi_dsi.h. > As I stated before I prefer to follow dsi specification and it states > clearly that > continuous behavior is required, non-continouous is optional. > Moreover for tegra chip continuous behavior is also the default one. Makes perfect sense indeed, especially if we have only two users of this interface for now. Will resubmit this series to make the Tegra driver use continuous clock by default, and update the panels it used to far to make use of the new flag. Thanks, Alex.
[Intel-gfx] [v2 00/11] Support for 180 degree HW rotation
On 7/4/2014 8:36 PM, Damien Lespiau wrote: > On Fri, Jul 04, 2014 at 03:13:52PM +0530, sonika.jindal at intel.com wrote: >> From: Sonika Jindal >> >> Enables 180 degree rotation for sprite and primary planes. >> Updated the primary plane rotation support as per the new universal plane >> design. >> >> Most of these patches were already reviewed in intel-gfx in February 2014 >> thats >> why there is version history in few of them. >> >> v2: Moved rotation_property to drm_plane. Added updation of FBC when >> rotation is >> again set to 0. >> >> Testcase: kms_rotation_crc >> This igt can be extended for clipped rotation cases. Right it only tests 180 >> degree rotation for sprite and primary plane with crc check. >> >> >> Sonika Jindal (2): >>drm/i915: Add 180 degree primary plane rotation support >>drm: Resetting rotation property >> >> Ville Syrj?l? (9): >>drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h >>drm: Add support_bits parameter to drm_property_create_bitmask() >>drm: Add drm_mode_create_rotation_property() >>drm/omap: Switch omapdrm over to drm_mode_create_rotation_property() >>drm: Add drm_rect rotation functions >>drm: Add drm_rotation_simplify() >>drm/i915: Add 180 degree sprite rotation support >>drm/i915: Make intel_plane_restore() return an error >>drm/i915: Add rotation property for sprites > > Missing from this series, your two documentation patches (we need to > bundle things up as a entity that makes sense for one of the maintainers > to pick it up (either Dave or Daniel)). > I was not aware that documentation patches should also be part of this. Because I was asked to send the igt testcase separately I thought documentation will also go separately. Documentation patches have also got reviewed-by tags. What do you suggest? Should I send the patchset again with documentation? Will Igt still be a separate post?
[PATCH RFC 06/15] drm/armada: move variant initialisation to CRTC init
On 07/05/2014 02:21 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 05, 2014 at 01:58:37PM +0200, Sebastian Hesselbarth wrote:
>> On 07/05/2014 12:38 PM, Russell King wrote:
>>> Move the variant initialisation entirely to the CRTC init function -
>>> the variant support is really about the CRTC properties than the whole
>>> system, and we want to treat each CRTC individually when we support DT.
>>>
>>> Signed-off-by: Russell King
>>> ---
>> [...]
>>> diff --git a/drivers/gpu/drm/armada/armada_crtc.h
>>> b/drivers/gpu/drm/armada/armada_crtc.h
>>> index 531a9b0bdcfb..3f0e70bb2e9c 100644
>>> --- a/drivers/gpu/drm/armada/armada_crtc.h
>>> +++ b/drivers/gpu/drm/armada/armada_crtc.h
>>> @@ -38,6 +38,7 @@ struct armada_crtc {
>>> unsignednum;
>>> void __iomem*base;
>>> struct clk *clk;
>>> + struct clk *extclk[2];
>>
>> I wonder, if we should rename above array srcclk instead of extclk
>> while moving it anyway. That way we can use it for the other variant
>> specific clocks, too.
>
> pixelclk may be a better name for it. I would like to think about the
The name was derived from the "SCLK_SOURCE_SELECT" bits in Dove FS, but
any other name not limited to external clocks is fine, too.
> clock handling further though - the issues surrounding clock selection
> are not limited to just Armada - imx-drm has the exact same problem.
>
> The issue with clocking of CRTCs is that it seems to be common that:
>
> 1. you have multiple clocks to choose from, some of which may be more
>suitable than others depending on the type of output.
Given the limited capabilities of the internal clock dividers, on Dove
the heuristic seems to be fairly simple: always prefer the external
clock. This is true for all actively supported Dove boards (Cubox and
{d2,d3}plug) as all have an external PLL connected.
I'd even say to make the external clock mandatory. Hitting a standard
pixclk frequency with one of the internal clocks is pure coincidence.
As long as there is no board using anything else than HDMI transmitter
on dumb RGB, we shouldn't try to foresee any suitable heuristic.
> 2. clocks end up being shared between multiple CRTCs, and one CRTC
>can (at the moment) interfere with the clock rate delivered to
>another CRTC.
>
> This happens on imx-drm today, where the two DIs (CRTCs) are in use -
> one for HDMI, the other for LVDS. We end up with HDMI set first to
> 148.5MHz, and then LVDS sets it's clock to 65MHz, which results in
> HDMI receiving a clock at over 500MHz! At the moment, there are hacks
> to solve this by adjusting the muxes in the clock paths to ensure that
> they both derive from different PLLs - moving the LVDS onto the USB OTG
> PLL rather than the video PLL. That works fine until USB OTG wants
> to change the OTG PLL.
Again, luckily on Cubox we have 2 VCOs for the two external clocks
(audio and video) so we won't have to deal with it. For the {d2,d3}plug
I'll have to check the IDT datasheet again.
In particular, for imx maybe it is possible to identify some clock tree
configurations for specific use-cases. I don't think there is any non-
manual way to tell the best clock tree config.
> There's also the issue whether the output can cope with fractional
> clock-skipping dividers - entirely synchronous display systems can
> (such as synchronously clocked LCD panels), but asynchronous display
> systems (such as HDMI, TV out, etc) can't. That said, the other
> parameter that needs to be taken account of here is that even with the
> fractional divider, the minimum output clock period isn't the average
> frequency, but the maximum frequency, which may violate a panel's minimum
> clock period specification.
Yeah, the fractional divider isn't made for external HDMI transmitters
for sure. I have seen from your branch that there is some Armada 610
stub for OLPC, do they have a dumb panel directly connected?
I also saw that they do have an external PLL, so maybe we should stick
to the external clock inputs as long as no other configurations pops-up
(which may never happen).
Sebastian
> I think there's lots to do on the clocking side, and as it's a fairly
> complex problem which is common to multiple implementations, I think
> that any solution should not be specific.
>
> However, this topic isn't one which I want to work on until I have
> reduced down my patch sets to something more manageable - something
> which I'm desperate to do. (I've been trying to avoid adding any
> further patches to any tree for some time now.) This is why (eg) I'm
> not going to fix the kernel oops-able bugs I found in the SGTL5000
> codec - someone else can do that.
[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 --- Comment #6 from Hadrien --- I finally got all needed library to build in debug and being used by the game! I followed the instruction on this page: http://x.debian.net/howto/build-mesa.html with the exception of "--with-dri-drivers=r600" that didn't work but I guess it is not important as gallium is standard now for r600, and the addition of "--enable-debug". However with those debug libraries I do not get the crash at the very same moment, but something like one second later. However it is the same kind of problem: a read access made too far from the source buffer (I'll attach the call stack again). This time a memcpy of 520 bytes is attempted from a buffer of 512 bytes. Now that I can do step by step debugging with all symbols identified by gdb I will try to understand what's happening. -- 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/20140706/413b5d54/attachment.html>
[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 --- Comment #7 from Hadrien --- Created attachment 102330 --> https://bugs.freedesktop.org/attachment.cgi?id=102330&action=edit callstack of other similar problem when running with Mesa debug libs This time 520 bytes were read but the buffer is 512 bytes only. -- 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/20140706/eff6866e/attachment.html>
[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3
https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #27 from Dan Merillat --- No, I reverted to a clean 3.16-rc3 (changed the 32 back to 100) and applied the patch: [drm:radeon_compute_pll_avivo] 229500 - 229500, pll dividers - fb: 1602.7 ref: 20, post 5 fb: is the same, ref and post are different. Same results as without the patch - the monitor wakes up out of sleep, but doesn't display anything. I can't get the OSD to display, so I don't know what it thinks the sync rates are. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes
https://bugs.freedesktop.org/show_bug.cgi?id=77394 --- Comment #13 from nine at detonation.org --- After two months with a stable system using fglrx, I gave radeon a try again. I can still easily reproduce the GPU lockups using kernel 3.16.0-rc2-5.g19015a0-desktop and radeon_ucode fetched today. dmesg output changed a litte. Maybe this helps? -- 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/20140706/318a8c28/attachment.html>
[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes
https://bugs.freedesktop.org/show_bug.cgi?id=77394 --- Comment #14 from nine at detonation.org --- Created attachment 102331 --> https://bugs.freedesktop.org/attachment.cgi?id=102331&action=edit dmesg after echo auto > power_profile Problem starts at 131.600354 -- 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/20140706/0b266385/attachment.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #120 from Alexandre Demers --- Alex, I think we can close this bug as soon as the "drm/radeon/dpm: fix vddci setup typo on cayman" patch lands in the kernel tree: I had no problem for the last couple of days since I applied the patch. The same goes for Martin. Any chance of seeing it included in kernel 3.16 (against which I'm testing the patch)? -- 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/20140706/25367535/attachment.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #121 from Alexandre Demers --- I just saw the latest RC kernel and the patch was included. Thanks! -- 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/20140706/e0dfce31/attachment.html>
[Bug 76998] hang on CEDAR right after log on
https://bugs.freedesktop.org/show_bug.cgi?id=76998 --- Comment #7 from tcl_de at gmx.net --- Yes, I think I can. In fact, I already tried and managed to go through the register arrays. There is a single problematic register in cedar_golden_registers, namely 0x5cc. The complete corresponding row of the array is 0x5cc, 0x, 0x0001 (line 384). -- 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/20140706/5cccfefb/attachment.html>
[Bug 77521] radeon: Horizontal lines of semi-random contents are sometimes displayed
https://bugzilla.kernel.org/show_bug.cgi?id=77521 Martin Andersson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #3 from Martin Andersson --- Tested the latest 3.16-rc4 and the artifacts are now gone. -- You are receiving this mail because: You are watching the assignee of the bug.
