https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #14 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Created attachment 86945
-- https://bugs.freedesktop.org/attachment.cgi?id=86945action=edit
A small simplification to low state adjustment
This doesn't solve the problem,
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.
On Tue, 01 Oct 2013, Chris Wilson ch...@chris-wilson.co.uk 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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #6 from Nikolay Amiantov nikoa...@gmail.com ---
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.
___
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #7 from Nikolay Amiantov nikoa...@gmail.com ---
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
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
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 can
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
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
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
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)
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(),
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,
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_LENGTH' since we
Hi
On Wed, Oct 2, 2013 at 11:25 AM, David Herrmann dh.herrm...@gmail.com 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,
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_size = 0x7e) return
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
On Wed, 02 Oct 2013, Chris Wilson ch...@chris-wilson.co.uk 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
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.
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
On Wed, Oct 2, 2013 at 4:15 AM, David Herrmann dh.herrm...@gmail.com 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70035
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org
From: Marek Olšák marek.ol...@amd.com
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
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.
On Mon, Jul 1, 2013 at 12:39 PM, Dan Carpenter dan.carpen...@oracle.com 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 dan.carpen...@oracle.com
Sorry I missed this one. Applied.
Thanks!
Alex
On Tue, Jul 2, 2013 at 2:22 AM, Dan Carpenter dan.carpen...@oracle.com 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
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 deathsim...@vodafone.de 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
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've
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 for now) as
CC: David Airlie airl...@linux.ie
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Jan Kara j...@suse.cz
---
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=70009
Pavel Ondračka pavel.ondra...@email.cz changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop.
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
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 t...@jklm.no
Hi Tom
On Sun, Sep 8, 2013 at 11:38 AM, Tom Gundersen t...@jklm.no wrote:
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen t...@jklm.no wrote:
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no
Hi Tom
On Sat, Sep 21, 2013 at 4:18 PM, Tom Gundersen t...@jklm.no wrote:
Hi David,
On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann dh.herrm...@gmail.com wrote:
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #3 from Alex Deucher ag...@yahoo.com ---
(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
On Fri, Sep 27, 2013 at 4:18 PM, Dan Carpenter dan.carpen...@oracle.com 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 dan.carpen...@oracle.com
---
Resend.
Applied. thanks!
Alex
On Sat, Sep 28, 2013 at 5:35 AM, Dan Carpenter dan.carpen...@oracle.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #4 from Pavel Ondračka pavel.ondra...@email.cz ---
(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.
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 rather
Hi
On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren swar...@wwwdotorg.org 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=70042
Alexandre Demers alexandre.f.dem...@gmail.com changed:
What|Removed |Added
Summary|Major texture flickering in |Major
On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
maarten.lankho...@canonical.com 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=69341
darkbasic darkba...@linuxsystems.it changed:
What|Removed |Added
Product|DRI |Mesa
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=70053
--- Comment #1 from Lucas Stach d...@lynxeye.de ---
Created attachment 87003
-- https://bugs.freedesktop.org/attachment.cgi?id=87003action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
Hi,
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul seanp...@chromium.org 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:
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul seanp...@chromium.org wrote:
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
Hi,
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul seanp...@chromium.org wrote:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
[...]
+Example:
+ ptn3460-bridge@20 {
Nit: Name is usually generic
https://bugs.freedesktop.org/show_bug.cgi?id=70053
--- Comment #2 from Alex Deucher ag...@yahoo.com ---
Created attachment 87006
-- https://bugs.freedesktop.org/attachment.cgi?id=87006action=edit
possible fix
Does this patch help? Seems like maybe your system isn't getting ac events
properly.
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #2 from Franz Häuslschmid haeus...@fastmail.fm ---
Created attachment 87007
-- https://bugs.freedesktop.org/attachment.cgi?id=87007action=edit
Output of dmesg after failing suspend to disk
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #3 from Franz Häuslschmid haeus...@fastmail.fm ---
Created attachment 87008
-- https://bugs.freedesktop.org/attachment.cgi?id=87008action=edit
Xorg.0.log after failing suspend to disk
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #4 from Alex Deucher ag...@yahoo.com ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
Disable CG/PG before resetting.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
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
---
Disable CG/PG and stop the rlc before resetting.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
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
https://bugs.freedesktop.org/show_bug.cgi?id=70053
--- Comment #3 from Lucas Stach d...@lynxeye.de ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #5 from Franz Häuslschmid haeus...@fastmail.fm ---
(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.
___
https://bugs.freedesktop.org/show_bug.cgi?id=70009
--- Comment #5 from Marek Olšák mar...@gmail.com ---
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.
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.
https://bugs.freedesktop.org/show_bug.cgi?id=70042
--- Comment #1 from Alexandre Demers alexandre.f.dem...@gmail.com ---
We can cross off the board:
sb optimization
--
You are receiving this mail because:
You are the assignee for the bug.
___
65 matches
Mail list logo
