https://bugs.freedesktop.org/show_bug.cgi?id=70042
--- Comment #3 from Alexandre Demers ---
Created attachment 87012
--> https://bugs.freedesktop.org/attachment.cgi?id=87012&action=edit
Visible corruption on mini-map
While the texture flickering is very fast, it appears as static on screenshot
https://bugs.freedesktop.org/show_bug.cgi?id=70042
--- Comment #2 from Alexandre Demers ---
I can't seem to be able to launch dota 2 with apitrace. I can launch Steam, but
Dota keeps crashing at launch. I'll add screenshots later.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=69983
Jos van Wolput changed:
What|Removed |Added
Summary|[r600g, bisected] Screen|[r600g, bisected] Screen
https://bugs.freedesktop.org/show_bug.cgi?id=69983
--- Comment #9 from Jos van Wolput ---
Same corrupted screen issue running /demos/cuberender, cubemap and dinoshade
using mesa-68f6dec32ed5eede361f76c8dbdf897652659baf
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=70042
--- Comment #1 from Alexandre Demers ---
We can cross off the board:
sb optimization
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@list
First of all, I can't complain about the reliability of the hardware
GPU reset. It's mostly the kernel driver that happens to run into a
deadlock at the same time.
Regarding the issue with fences, the problem is that the GPU reset
completes successfully according to dmesg, but X doesn't respond. I
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #5 from Marek Olšák ---
Do particular shaders fail to compile or is there just incorrect rendering?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #5 from Franz Häuslschmid ---
(In reply to comment #4)
> Can you bisect?
I'll do it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
d
https://bugs.freedesktop.org/show_bug.cgi?id=70053
--- Comment #3 from Lucas Stach ---
Yes, the patch fixes the immediate lockup. But it seems your analysis on why it
fails isn't correct as I can now see your printks toggling between AC and DC
when plugging in/out external power.
--
You are rec
Disable CG/PG and stop the rlc before resetting.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/si.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index c354c10..d4652af 100644
--- a/dr
Disable CG/PG before resetting.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index d02fd1c..b874ccd 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #4 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #3 from Franz Häuslschmid ---
Created attachment 87008
--> https://bugs.freedesktop.org/attachment.cgi?id=87008&action=edit
Xorg.0.log after failing suspend to disk
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #2 from Franz Häuslschmid ---
Created attachment 87007
--> https://bugs.freedesktop.org/attachment.cgi?id=87007&action=edit
Output of dmesg after failing suspend to disk
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=70053
--- Comment #2 from Alex Deucher ---
Created attachment 87006
--> https://bugs.freedesktop.org/attachment.cgi?id=87006&action=edit
possible fix
Does this patch help? Seems like maybe your system isn't getting ac events
properly. Can you atta
Hi,
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul wrote:
> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
> bridge chip.
>
> Signed-off-by: Sean Paul
> ---
[...]
> +Example:
> + ptn3460-bridge@20 {
Nit: Name is usually generic device name, i.e. "lvds-bridge" or
som
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul wrote:
> This patch adds the dp-controller node to the exynos5250-snow board dts
> file.
>
> Signed-off-by: Sean Paul
> ---
> arch/arm/boot/dts/exynos5250-snow.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/e
Hi,
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul wrote:
> This set adds some missing devicetree nodes to the exynos5250-snow file as
> well
> as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in
> the exynos5250-snow board.
>
> Sean
>
>
> Sean Paul (5):
> ARM: dts: Add fi
https://bugs.freedesktop.org/show_bug.cgi?id=70053
--- Comment #1 from Lucas Stach ---
Created attachment 87003
--> https://bugs.freedesktop.org/attachment.cgi?id=87003&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=70053
Priority: medium
Bug ID: 70053
Assignee: dri-devel@lists.freedesktop.org
Summary: hard machine hang when switching to battery power with
DPM enabled on Trinity APU
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=69341
darkbasic changed:
What|Removed |Added
Product|DRI |Mesa
Version|DRI CVS
When userspace removes the active framebuffer using DRM_IOCTL_MODE_RMFB,
or explicitly disables the CRTC (by calling drmModeSetCrtc(..., NULL)
for example), a NULL framebuffer will be passed to the .set_config()
implementation of a CRTC. The drm_crtc_helper_set_config() helper will
decide to disabl
On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
wrote:
> The timeline is similar to what I called a fence context. Each command stream
> on a gpu can have a context. Because
> nvidia hardware can have 4095 separate timelines, I didn't want to keep the
> bookkeeping for each timeline, although
https://bugs.freedesktop.org/show_bug.cgi?id=70042
Alexandre Demers changed:
What|Removed |Added
Summary|Major texture flickering in |Major texture flickering in
https://bugs.freedesktop.org/show_bug.cgi?id=70042
Priority: medium
Bug ID: 70042
Assignee: dri-devel@lists.freedesktop.org
Summary: Major texture flickering in Dota 2
Severity: normal
Classification: Unclassified
OS: All
Hi
On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren wrote:
> On 10/02/2013 08:58 AM, David Herrmann wrote:
>> Unfortunately, fbdev does not create its own "struct device" for
>> framebuffers. Instead, it attaches to the device of the parent layer. This
>> has the side-effect that devm_* managed res
On 10/02/2013 08:58 AM, David Herrmann wrote:
> Unfortunately, fbdev does not create its own "struct device" for
> framebuffers. Instead, it attaches to the device of the parent layer. This
> has the side-effect that devm_* managed resources are not cleaned up on
> framebuffer-destruction but rathe
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #4 from Pavel Ondračka ---
(In reply to comment #3)
> (In reply to comment #2)
> > So is seems, that when I record a trace using r300g driver (RV530) and
> > replay it using either llvmpipe or i965, it works fine. Probably this is
> >
On Sat, Sep 28, 2013 at 5:35 AM, Dan Carpenter wrote:
> These checks should be ">=" instead of ">". j is used as an offset into
> the table->mc_reg_address[] array and that has
> SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE (16) elements.
>
> Signed-off-by: Dan Carpenter
Applied. thanks!
Alex
>
> dif
On Fri, Sep 27, 2013 at 4:18 PM, Dan Carpenter wrote:
> It should be ">=" instead of ">" here. The table->mc_reg_address[]
> array has SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE (16) elements.
>
> Signed-off-by: Dan Carpenter
> ---
> Resend.
Applied. thanks!
Alex
>
> diff --git a/drivers/gpu/drm/r
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #3 from Alex Deucher ---
(In reply to comment #2)
> So is seems, that when I record a trace using r300g driver (RV530) and
> replay it using either llvmpipe or i965, it works fine. Probably this is
> just some issue in the r300g drive
Hi Tom
On Sat, Sep 21, 2013 at 4:18 PM, Tom Gundersen wrote:
> Hi David,
>
> On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote:
>> The SimpleDRM driver binds to simple-framebuffer devices and provides a
>> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
>> plus one i
Hi Tom
On Sun, Sep 8, 2013 at 11:38 AM, Tom Gundersen wrote:
> On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann wrote:
>> Hi
>>
>> On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote:
>>> Hi David,
>>>
>>> On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote:
On Sat, Sep 7, 2013 at 4:30 PM,
Framebuffers shouldn't be cached and it is usually very uncommon to read
them. Therefore, use ioremap_wc() to get significant speed improvements on
systems which provide it. On all other systems it's aliased to
ioremap_nocache() which is also fine.
Reported-by: Tom Gundersen
Signed-off-by: David
Unfortunately, fbdev does not create its own "struct device" for
framebuffers. Instead, it attaches to the device of the parent layer. This
has the side-effect that devm_* managed resources are not cleaned up on
framebuffer-destruction but rather during destruction of the
parent-device. In case of
https://bugs.freedesktop.org/show_bug.cgi?id=70009
Pavel Ondračka changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
Possible, but I would rather guess that this doesn't work because the IB test
runs into a deadlock situation and so the GPU reset never fully completes.
Can you reproduce the problem?
If you want to make GPU resets more reliable I would rather suggest to remove
the ring lock dependency.
Then we
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Jan Kara
---
drivers/gpu/drm/via/via_dmablit.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/via/via_dmablit.c
b/drivers/gpu/drm/via/via_dmablit.c
index 8b0f25904e6d..7e377
Hi Andrzej,
On 02/10/13 15:23, Andrzej Hajda wrote:
>> Using Linux buses for DBI/DSI
>> =
>>
>> I still don't see how it would work. I've covered this multiple times in
>> previous posts so I'm not going into more details now.
>>
>> I implemented DSI (just command mode
Hi Tomi,
On 09/30/2013 03:48 PM, Tomi Valkeinen wrote:
> On 09/08/13 20:14, Laurent Pinchart wrote:
>> Hi everybody,
>>
>> Here's the third RFC of the Common Display Framework.
>
>
> Hi,
>
> I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gather
> some notes here about what
I'm afraid signalling the fences with an IB test is not reliable.
Marek
On Wed, Oct 2, 2013 at 3:52 PM, Christian König wrote:
> NAK, after recovering from a lockup the first thing we do is signalling all
> remaining fences with an IB test.
>
> If we don't recover we indeed signal all fences ma
On Tue, Jul 2, 2013 at 2:22 AM, Dan Carpenter wrote:
> The rv6xx_clocks_per_unit() function pretends it can set flags in a u64
> bitfield but really because "1" is an int it doesn't work for more than
> 32 bits. The only caller truncates the high bits away anyway. I've
> just changed it to be a
On Mon, Jul 1, 2013 at 12:39 PM, Dan Carpenter wrote:
> The error path does this:
>
> for (--i; i >= 0; --i) {
>
> which is a forever loop because "i" is unsigned.
>
> Signed-off-by: Dan Carpenter
Sorry I missed this one. Applied.
Thanks!
Alex
>
> diff --git a/drivers/gpu/drm/radeon/
NAK, after recovering from a lockup the first thing we do is signalling all
remaining fences with an IB test.
If we don't recover we indeed signal all fences manually.
Signalling all fences regardless of the outcome of the reset creates problems
with both types of partial resets.
Christian.
M
From: Marek Olšák
After a lockup, fences are not signalled sometimes, causing
the GEM_WAIT_IDLE ioctl to never return, which sometimes results
in an X server freeze.
This fixes only one of many deadlocks which can occur during a lockup.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/ra
https://bugs.freedesktop.org/show_bug.cgi?id=70035
Alex Deucher changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
On Wed, Oct 2, 2013 at 4:15 AM, David Herrmann wrote:
> All drivers embed gem-objects into their own buffer objects. There is no
> reason to keep drm_gem_object_alloc(), gem->driver_private and
> ->gem_init_object() anymore.
>
> New drivers are highly encouraged to do the same. There is no benefit
DRM core shares a single address_space across all inodes that belong to
the same DRM device. This allows efficient unmapping of user-space
mappings during buffer eviction. However, there is no easy way to get a
shared address_space for DRM devices during initialization. Therefore, we
currently dela
Instead of delaying inode initialization until first ->open(), we can use
an anonymous inode. This avoids modifying FS internal inode fields and
provides us a private address_space right during initialization.
Delayed TTM dev_mapping initialization is currently left untouched to keep
this simple.
On Wed, 02 Oct 2013, Chris Wilson wrote:
> If the firmware is not builtin and userspace is not yet running, we can
> stall the boot process for a minute whilst the firmware loader times
> out. This is contrary to expectations of providing a builtin EDID!
>
> In the process, we can rearrange the co
If the firmware is not builtin and userspace is not yet running, we can
stall the boot process for a minute whilst the firmware loader times
out. This is contrary to expectations of providing a builtin EDID!
In the process, we can rearrange the code to make the error handling
more resilient and pr
On Wed, Oct 02, 2013 at 10:32:35AM +0100, Chris Wilson wrote:
> On Wed, Oct 02, 2013 at 12:22:07PM +0300, Ville Syrjälä wrote:
> > > +static bool edid_check_size(const u8 *data, int data_size)
> > > +{
> > > + if (data[0x7e] > 0x7e)
> > > + return false;
> >
> > That should be 'if (data_si
Hi
On Wed, Oct 2, 2013 at 11:25 AM, David Herrmann wrote:
> If vgacon got unloaded for any reason, we can never be sure that vga
> registers are still accessible. fbdev/DRM/xycon might reconfigure graphics
> devices in a way that prevents vgacon from working again. Therefore,
> inhibit rebinding
On Wed, Oct 02, 2013 at 12:22:07PM +0300, Ville Syrjälä wrote:
> > +static bool edid_check_size(const u8 *data, int data_size)
> > +{
> > + if (data[0x7e] > 0x7e)
> > + return false;
>
> That should be 'if (data_size <= 0x7e) return false;' no?
>
> Or maybe just 'data_size < EDID_LENG
If vgacon got unloaded for any reason, we can never be sure that vga
registers are still accessible. fbdev/DRM/xycon might reconfigure graphics
devices in a way that prevents vgacon from working again. Therefore,
inhibit rebinding vgacon.
Note that this _might_ break use-cases where users unbind v
Analog to drm_dev_register(), we now provide drm_dev_unregister() which
does the reverse. drm_dev_put() is still in place and combines the calls
to drm_dev_unregister() and drm_dev_free() so buses don't have to change.
*_get() and *_put() are used for reference-counting in the kernel.
However, drm
The error paths in DRM bus drivers currently leak memory as they don't
correctly revert drm_dev_alloc(). Introduce drm_dev_free() to free DRM
devices which haven't been registered, yet.
We must be careful not to introduce any side-effects with cleanups done in
drm_dev_free(). drm_ht_remove(), drm_
Try to keep all functions that handle DRM file_operations in drm_fops.c
so internal helpers can be marked static later.
This makes the split between the 3 core files more obvious:
- drm_stub.c: DRM device allocation/destruction and management
- drm_fops.c: DRM file_operations (except for ioctl)
All bus drivers do device setup themselves. This requires us to adjust all
of them if we introduce new core features. Thus, merge all these into a
uniform drm_dev_register() helper.
Note that this removes the drm_lastclose() error path for AGP as it is
horribly broken. Moreover, no bus driver call
Instead of managing device allocation+initialization in each bus-driver,
we should do that in a central place. drm_fill_in_dev() already does most
of it, but also requires the global drm lock for partial AGP device
registration.
Split both apart so we have a clean device initialization/allocation
Hi
This cleans up the bus drivers in DRM. Instead of copying the device alloc/free
semantics into each bus driver (drm_{pci,platform,usb}.c) we now have a central
place in drm_stub.c.
This introduces drm_dev_{alloc,free,register,unregister}(). They have the same
semantics as most other kernel sub
On Wed, Oct 02, 2013 at 10:07:39AM +0100, Chris Wilson wrote:
> If the firmware is not builtin and userspace is not yet running, we can
> stall the boot process for a minute whilst the firmware loader times
> out. This is contrary to expectations of providing a builtin EDID!
>
> In the process, we
If the firmware is not builtin and userspace is not yet running, we can
stall the boot process for a minute whilst the firmware loader times
out. This is contrary to expectations of providing a builtin EDID!
In the process, we can rearrange the code to make the error handling
more resilient and pr
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #7 from Nikolay Amiantov ---
Oh, but I have not tried this with new kernel. I'll do this later, and if I
have enough time today, I'll try to bisect the bug.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #6 from Nikolay Amiantov ---
Yes, reverting to 9.1.3 (from Ubuntu repos) solves the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing l
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie
Cc: Ale
There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.
The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff
On Tue, 01 Oct 2013, Chris Wilson wrote:
> On Tue, Oct 01, 2013 at 06:49:42PM +0300, Ville Syrjälä wrote:
>> On Tue, Oct 01, 2013 at 02:06:13PM +0100, Chris Wilson wrote:
>> > CC drivers/gpu/drm/drm_edid_load.o
>> > drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’:
>> >
Hey,
So I took a look at the sync stuff in android, in a lot of ways I believe that
they're similar, yet subtly different.
Most of the stuff I looked at is from the sync.h header in drivers/staging, so
maybe my knowledge is incomplete.
The timeline is similar to what I called a fence context. E
69 matches
Mail list logo
