https://bugs.freedesktop.org/show_bug.cgi?id=99488
--- Comment #12 from Jan Vesely ---
The first patch is already in the mainline (https://reviews.llvm.org/D29792)
The second one is under review (https://reviews.llvm.org/D30230)
Feel free to leave this bug open until jpeg conversion works.
The k
https://bugs.freedesktop.org/show_bug.cgi?id=99488
--- Comment #11 from nixscrip...@gmail.com ---
Also, a link to the patch in the build system would be nice, so I know when
that happens.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=99488
--- Comment #10 from nixscrip...@gmail.com ---
I have finally gotten a build done, and the patch does indeed fix the hang. I
get the same assertion.
Once that patch lands, I will verify that SVN build number, and close this bug.
(And then, I'll
https://bugs.freedesktop.org/show_bug.cgi?id=99969
Bug ID: 99969
Summary: kernel 4.9.11-1 locksup at login screen
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Sev
https://bugs.freedesktop.org/show_bug.cgi?id=99967
--- Comment #2 from Christoph Haag ---
Created attachment 129919
--> https://bugs.freedesktop.org/attachment.cgi?id=129919&action=edit
dmesg with linux 4.8
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99967
--- Comment #1 from Christoph Haag ---
Created attachment 129918
--> https://bugs.freedesktop.org/attachment.cgi?id=129918&action=edit
screenshot with echo auto > power_dpm_force_performance_level
On "auto" the sclk clock speeds resets by itse
https://bugs.freedesktop.org/show_bug.cgi?id=99967
Bug ID: 99967
Summary: RX 480 sclk clock speed lowers when under load
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: norm
https://bugzilla.kernel.org/show_bug.cgi?id=88861
--- Comment #25 from Wilfried Klaebe (linux-ker...@lebenslange-mailadresse.de)
---
This issue is still there in Linux 4.10. Because I didn't manage to find this
bugzilla entry again I opened a new bug, #194697.
The status on this bug here is "NEE
On Fri, Feb 24, 2017 at 05:25:16PM -0800, John Stultz wrote:
> In some cases I've been seeing a race where two framebuffers
> would be initialized, as kirin_fbdev_output_poll_changed()
> might get called quickly in succession, resulting in the
> initialization happening twice. This could cause the
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #27 from cosiek...@o2.pl ---
Created attachment 129912
--> https://bugs.freedesktop.org/attachment.cgi?id=129912&action=edit
Piglit dri2 w/o patch
I have done piglit test you guys was talking about on the mailinglist. I can do
it ag
On Sat, Feb 25, 2017 at 12:36 PM, Daniel Vetter wrote:
> On Sat, Feb 25, 2017 at 4:43 PM, Rob Clark wrote:
>> Probably a symptom of needing finer grained locking, but if we wait on
>> the incoming fence-fd (which could come from a different context) while
>> holding struct_mutex, that blocks reti
Hi,
On 20-02-17 14:24, Hans de Goede wrote:
So when userspace
(e.g. the Xorg server + modesetting driver) asks for 0° degree
rotation under the hood they get 90 applied, when they aks for
the panel resolution they get 1280x720 instead of 720x1280.
The idea was that userspace will inherit th
On Sat, Feb 25, 2017 at 4:43 PM, Rob Clark wrote:
> Probably a symptom of needing finer grained locking, but if we wait on
> the incoming fence-fd (which could come from a different context) while
> holding struct_mutex, that blocks retire_worker so gpu fences cannot get
> scheduled.
>
> This caus
Hi John,
The patch seems good to me, except one minus comment.
Maybe change fb_lock to fbdev_lock would be better.
Thanks,
-xinliang
On 2017/2/25 9:25, John Stultz wrote:
In some cases I've been seeing a race where two framebuffers
would be initialized, as kirin_fbdev_output_poll_changed()
mig
On 2017/2/25 5:33, John Stultz wrote:
On Thu, Feb 23, 2017 at 5:55 PM, liuxinliang
wrote:
Hi John,
On 2017/2/23 8:56, John Stultz wrote:
In some cases I've been seeing a race where two framebuffers
would be initialized, as kirin_fbdev_output_poll_changed()
might get called quickly in succes
Consistently use types from linux/types.h like in other uapi drm/*_drm.h
header files to fix the following drm/omap_drm.h userspace compilation
errors:
/usr/include/drm/omap_drm.h:36:2: error: unknown type name 'uint64_t'
uint64_t param; /* in */
/usr/include/drm/omap_drm.h:37:2: error: unknow
On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> Detect on probe whether a PCI device is part of a Thunderbolt controller.
>
> Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234
> on such devices. Detect presence of this VSEC and cache it in a newly
> added is_t
On Fri, Feb 24, 2017 at 5:51 PM, Lucas Stach wrote:
> +CC Thierry, as the drm_panel maintainer.
>
> Am Donnerstag, den 23.02.2017, 10:54 -0500 schrieb Sean Paul:
>> On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
>> > Hello,
>> >
>> > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsa
On Sat, Feb 25, 2017 at 08:40:03AM +0100, Lukas Wunner wrote:
> On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote:
> > On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > > --- a/include/linux/pci.h
> > > +++ b/include/linux/pci.h
> > > @@ -358,6 +358,7 @@ struct pci_dev {
Hi,
Dne petek, 24. februar 2017 ob 14:30:36 CET je Rob Herring napisal(a):
> On Wed, Feb 22, 2017 at 2:09 PM, Maxime Ripard
>
> wrote:
> > Hi,
> >
> > On Wed, Feb 22, 2017 at 11:23:06PM +0800, Icenowy Zheng wrote:
> >> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
> >
On 2017/2/25 9:39, liuxinliang wrote:
Hi John,
The patch seems good to me, except one minus comment.
Maybe change fb_lock to fbdev_lock would be better.
Thanks,
-xinliang
On 2017/2/25 9:25, John Stultz wrote:
In some cases I've been seeing a race where two framebuffers
would be initialized,
On Sat, Feb 25, 2017 at 10:43 AM, Rob Clark wrote:
> Probably a symptom of needing finer grained locking, but if we wait on
> the incoming fence-fd (which could come from a different context) while
> holding struct_mutex, that blocks retire_worker so gpu fences cannot get
> scheduled.
s/scheduled
Probably a symptom of needing finer grained locking, but if we wait on
the incoming fence-fd (which could come from a different context) while
holding struct_mutex, that blocks retire_worker so gpu fences cannot get
scheduled.
This causes a problem if userspace manages to get more than a frame
ahe
https://bugs.freedesktop.org/show_bug.cgi?id=97590
--- Comment #14 from Vedran Miletić ---
(In reply to Adam Bolte from comment #9)
> The only difference between this patch and the Windows behaviour is with the
> second card at idle - Windows will display only a single green LED which I
> believe
24 matches
Mail list logo
