olour frame buffer device 180x56
> fb0: radeondrmfb frame buffer device
> drm: registered panic notifier
> =
> and i wanna know if there is some thing wrong ,if the problem is here
> ,how can i sol
https://bugzilla.kernel.org/show_bug.cgi?id=85421
--- Comment #34 from EmanueL Czirai ---
There were no further lockups for me thus far, although that v4l2_release stack
dump I still got when closing vlc(or was it when I unplugged, i forget) but
that seems to be a different issue: pasted here
htt
Hopefully there is someone at the mesa team that
plays games and can test CSGO on AMD hardware?
--
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/d
Dear Andrej,
On Mon, 23 Mar 2015 10:31:58 +0100
Andrzej Hajda wrote:
> On 03/20/2015 06:15 AM, Hyungwon Hwang wrote:
> > Dear Andrej,
> >
> > On Thu, 19 Mar 2015 10:32:10 +0100
> > Andrzej Hajda wrote:
> >
> >> On 03/19/2015 02:18 AM, Hyungwon Hwang wrote:
> >>> Dear Daniel,
> >>>
> >>> On Thu,
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/b902cb7c/attachment.html>
Hi Laurent,
Am Samstag, 28. Februar 2015, 01:42:45 schrieb Heiko Stübner:
> thanks for the comments
>
> Am Donnerstag, 26. Februar 2015, 20:33:33 schrieb Laurent Pinchart:
> > On Saturday 31 January 2015 17:32:56 Heiko Stuebner wrote:
> > > There exist simple vga encoders without any type of man
On Mon, Mar 23, 2015 at 11:33:42AM -0400, Josh Boyer wrote:
> I have a machine that no longer boots in a headless manner with -rc5.
> It's an Celeron based NUC device. I blacklisted the i915 driver and
> it boots fine, then I ran insmod manually and got the backtrace below.
> This machine onl
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/09b3c870/attachment-0001.html>
[adding more people and intel-gfx, original message with backtrace at
http://mid.gmane.org/550EED22.9070008 at gmail.com]
On Mon, 23 Mar 2015, François Valenduc wrote:
> Le 23/03/15 09:52, Jani Nikula a écrit :
>> On Sun, 22 Mar 2015, François Valenduc
>> wrote:
>>> It seems commit 7ce42ae6
;s so LGTM
Reviewed-by: Jan Vesely
> return 0;/* Added to table */
> }
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/f07ab2bf/attachment.sig>
t; -#define SL_DEBUG 0
> #define SL_RANDOM_SEED 0xc01055a1LU
>
> #if SL_MAIN
Reviewed-by: Jan Vesely
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/ddb41366/attachment.sig>
Le 23/03/15 09:52, Jani Nikula a écrit :
> On Sun, 22 Mar 2015, François Valenduc wrote:
>> It seems commit 7ce42ae67c49204c0b2252edd06f7920e0a51037 causes
>> several errors.
> It seems I don't have this commit. Which tree is this?
>
> I also admit to being pretty bad at associating commit ids w
Hi Philipp,
Am Donnerstag, 12. März 2015, 21:45:19 schrieb Heiko Stuebner:
> At least the Rockchip variant of the dw_hdmi can have controllable power
> supplies providing 1.0 and 1.8V. Therefore add the possibility for the
> generic bridge driver to enable supplies provided by the hw-specific
> d
id)
> drmHashInsert(table, random(), (void *)&i);
> srandom(0xbeefbeef);
> for (i = 0; i < 5000; i++)
> -check_table(table, random(), i);
> +ret = check_table(table, random(), i) && ret;
> srandom(0xbeefbeef);
> for (i = 0; i < 5000; i++)
> -check_table(table, random(), i);
> +ret = check_table(table, random(), i) && ret;
> compute_dist(table);
> drmHashDestroy(table);
>
Reviewed-by: Jan Vesely
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/bea5ac91/attachment.sig>
able, random(), i);
> compute_dist(table);
> drmHashDestroy(table);
>
> printf("\n* 5000 random integers ****\n");
> table = drmHashCreate();
> srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) drmHashInsert(table, random(), (void *)&i);
> +for (i = 0; i < 5000; i++)
> +drmHashInsert(table, random(), (void *)&i);
> srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> +for (i = 0; i < 5000; i++)
> +check_table(table, random(), i);
> srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> +for (i = 0; i < 5000; i++)
> +check_table(table, random(), i);
> compute_dist(table);
> drmHashDestroy(table);
>
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/6b066f5b/attachment-0001.sig>
m integers \n");
> table = drmHashCreate();
> srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) drmHashInsert(table, random(), i);
> +for (i = 0; i < 5000; i++) drmHashInsert(table, random(), (void *)&i);
> srandom(0xbeefbeef);
> for (i = 0; i < 5000; i++) check_table(table, random(), i);
> srandom(0xbeefbeef);
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/0a4319c6/attachment.sig>
On Thu, Mar 12, 2015 at 4:48 PM, Jilai Wang wrote:
> Introduce msm_drm_sub_dev for each mdp interface component such as
> HDMI/eDP/DSI to contain common information shared with MDP.
>
> Signed-off-by: Jilai Wang
> ---
> drivers/gpu/drm/msm/edp/edp.c | 18 +--
> drivers/gpu/drm/
256; i >= 0; i--) check_table(table, i, i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 1024 consecutive integers ****\n");
> -table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i, i);
> -for (i = 0; i < 1024; i++) check_table(table, i, i);
> -for (i = 1024; i >= 0; i--) check_table(table, i, i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 1024 consecutive page addresses (4k pages) \n");
> -table = drmHashCreate();
> -for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, i);
> -for (i = 0; i < 1024; i++) check_table(table, i*4096, i);
> -for (i = 1024; i >= 0; i--) check_table(table, i*4096, i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 1024 random integers \n");
> -table = drmHashCreate();
> -srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) drmHashInsert(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) check_table(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 1024; i++) check_table(table, random(), i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -printf("\n* 5000 random integers \n");
> -table = drmHashCreate();
> -srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) drmHashInsert(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> -srandom(0xbeefbeef);
> -for (i = 0; i < 5000; i++) check_table(table, random(), i);
> -compute_dist(table);
> -drmHashDestroy(table);
> -
> -return 0;
> -}
> -#endif
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/a40241e3/attachment-0001.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #24 from Mihai Coman ---
Still happens on 3.19.2-1-ARCH. After blanking, sometimes the image comes back
on; I can move the cursor, but the interface is unresponsive.
--
You are receiving this mail because:
You are watching the assign
);
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/aecd6028/attachment.sig>
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
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/e
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
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 ++--
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 a
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.
v2: alloca
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/
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: remov
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/923886d8/attachment.html>
Hi Archit,
> Hi Stephane,
>
> On 03/14/2015 01:19 AM, Stephane Viau wrote:
>> Some interfaces (WB, DSI Command Mode) need to be kicked off
>> through a START Signal. This signal needs to be sent at the right
>> time and requests in some cases to keep track of the pipeline
>> status (eg: whether pi
On Mon, Mar 23, 2015 at 12:34:04PM +, Jeff Epler wrote:
> On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
> > +/*
> > + * Same as above but for u64 dividends. divisor must be a 32-bit
> > + * number.
> > + */
> > +#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \
> > +{
Hi,
On 23 March 2015 at 08:20, Daniel Vetter wrote:
> On Thu, Mar 19, 2015 at 04:32:36AM +, Daniel Stone wrote:
>> This series ends up touching pretty much all the drivers, by virtue of
>> turning
>> crtc->mode (in particular) into both a const and a pointer.
>
> Ok this is quite a bit a dif
Hi Hai,
On 03/19/2015 02:35 AM, hali at codeaurora.org wrote:
> Hi Archit,
>
> Thanks for your comments. Please see my response for some comments below.
> Comments without response will be addressed in patch version 2. I will
> wait for other comments if any to push patch V2.
>
>>> +static int dsi
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, March 23, 2015 2:33 AM
> To: Konduru, Chandra
> Cc: intel-gfx at lists.freedesktop.org; Conselvan De Oliveira, Ander; Vetter,
> Daniel
> Subject: Re: [Intel-gfx] [P
Hi Archit,
> Hi Hai,
>
> On 03/19/2015 02:35 AM, hali at codeaurora.org wrote:
>> Hi Archit,
>>
>> Thanks for your comments. Please see my response for some comments
>> below.
>> Comments without response will be addressed in patch version 2. I will
>> wait for other comments if any to push patch
Hi Stephane,
On 03/14/2015 01:19 AM, Stephane Viau wrote:
> Some interfaces (WB, DSI Command Mode) need to be kicked off
> through a START Signal. This signal needs to be sent at the right
> time and requests in some cases to keep track of the pipeline
> status (eg: whether pipeline registers are
https://bugzilla.kernel.org/show_bug.cgi?id=85421
EmanueL Czirai changed:
What|Removed |Added
CC||emanueLczirai at cryptoLab.net
--- Comme
On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer
wrote:
>> Xi Ruoyao (1):
>> drm/i915: Ensure plane->state->fb stays in sync with plane->fb
Turns out to be that commit.
git bisect start 'drivers/gpu/drm/i915/'
# good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch
'for-linus' of g
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/fb5edc55/attachment.html>
The DI pixel clock divider bit field is only 8 bits wide for the
integer part, so limit the divider to the 1...255 interval before
deciding whether the internal clock can be used and before writing
to the register.
Reported-by: Felix Mellmann
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/
commit 2378ad1228d2 ("drm: rcar-du: Remove platform data support")
removed the file, remove the pattern.
Signed-off-by: Joe Perches
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 78195d3..47aaa52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3
We checked "ver" and "ramcfg.size" before and they haven't changed so
static checkers complain when we test them again here. "rammap.data"
isn't be NULL so "ramcfg.data" is also not NULL so there is no need to
check.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/
The value for downsizing 8:1 is marked as reserved in the technical reference
manual and the documentation states downsizing capability up to 4:1 only.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-ic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie wrote:
>
> Hi Linus,
>
> a bunch of fixes across drivers,
> radeon: disable two ended allocation for now, it breaks some stuff
> amdkfd: misc fixes
> nouveau: fix irq loop problem, add basic support for GM206 (new hw)
> i915: fix some WARNs people were
From: Christian König
Otherwise the VCE firmware needs to be in the first 256MB of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cikd.h | 1 +
drivers/gpu/drm/radeon/vce_v2_0.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drive
From: Christian König
Dumping is still possible if a ring isn't ready, only when it
isn't allocated at all we need to abort here.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon
On Mon, Mar 23, 2015 at 6:32 AM, Christian König
wrote:
> From: Christian König
>
> Dumping is still possible if a ring isn't ready, only when it
> isn't allocated at all we need to abort here.
>
> Signed-off-by: Christian König
Applied the series. thanks!
Alex
> ---
> drivers/gpu/drm/ra
Hi Tobias,
On 22/03/15 16:29, Tobias Jakobi wrote:
> Hello Emil,
> Emil Velikov wrote:
>> I fear we are not (yet) allowed to do either of these changes.
>>
>> The exynos/exynos_drm.h header is (supposed to) be in sync/come from the
>> kernel. And changes here are to be reflected only when the corre
On Sun, 22 Mar 2015, François Valenduc wrote:
> It seems commit 7ce42ae67c49204c0b2252edd06f7920e0a51037 causes
> several errors.
It seems I don't have this commit. Which tree is this?
I also admit to being pretty bad at associating commit ids with the
actual commits, especially so for commit i
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/e7b2679a/attachment-0001.html>
On 03/20/2015 06:15 AM, Hyungwon Hwang wrote:
> Dear Andrej,
>
> On Thu, 19 Mar 2015 10:32:10 +0100
> Andrzej Hajda wrote:
>
>> On 03/19/2015 02:18 AM, Hyungwon Hwang wrote:
>>> Dear Daniel,
>>>
>>> On Thu, 19 Mar 2015 01:13:21 +
>>> Daniel Stone wrote:
>>>
Hi Hyungwon,
On 19 M
On Thu, Mar 19, 2015 at 04:32:36AM +, Daniel Stone wrote:
> Well, that escalated quickly.
>
> I've been looking at adding modesetting support to the atomic ioctl, and this
> is what I've ended up with so far. It's definitely not perfect, but given how
> out of hand it's got at the moment, I wa
On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
> We have grown a number of different implementations of
> DIV_ROUND_CLOSEST_ULL throughout the kernel. Move the i915 one to
> kernel.h so that it can be reused.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: David Airlie
> Cc: Darric
Hi Dave,
drm-intel-next-2015-03-13-rebased:
- EU count report param for gen9+ (Jeff McGee)
- piles of pll/wm/... fixes for chv, finally out of preliminary hw support
(Ville, Vijay)
- gen9 rps support from Akash
- more work to move towards atomic from Matt, Ander and others
- runtime pm support f
On Fri, Mar 20, 2015 at 11:14:40AM +, Javi Merino wrote:
> +/*
> + * Same as above but for u64 dividends. divisor must be a 32-bit
> + * number.
> + */
> +#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \
> +{\
> + unsigned long long
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/d6636341/attachment.html>
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150323/c1cc53d4/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150323/506d4161/attachment.html>
58 matches
Mail list logo
