> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
> Sent: Wednesday, July 03, 2013 8:52 PM
> To: Inki Dae
> Cc: 'Russell King'; devicetree-disc...@lists.ozlabs.org; 'Jean-Francois
> Moine'; 'Sascha Hauer'; 'Daniel Drake'; dri-devel@lists.freedeskt
On 07/04/2013 07:11 AM, Laurent Pinchart wrote:
Hi Joonyoung,
Thank you for the patches.
On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote:
Hello,
This is the second version patchset.
GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
dma_buf. We can use prime helper
The drm_gem_map_detach() can be called with sgt is NULL.
Change-Id: I3b2f5878dfac6e1e77aebeeb7be781113dec59a7
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/dr
The drm_gem_map_detach() can be called with sgt is NULL.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1e0de41..ff5fece 100644
--- a/dri
On Don, 2013-07-04 at 00:51 +0200, Andrej Gelenberg wrote:
>
> i have an Radeon HD 7870 GHz Edition graphic card and at finnaly got
> some 3D and VDPAU acceleration with kernel 3.10, mesa 9.2 from
> 19.6.2013 and glamor accelerations, but it carsh a lot. I attached
> dmesg witch hopefully helpful
Hi Dave,
This is final pull request for 3.11. This resolves some memory leak
issues, and includes some code and dt document file cleanups; just
removed unnecessary descriptions.
And the patch work for enhancing hdmiphy driver isn't in progress so
this patch may go to 3.12.
Please
On Wed, Jul 03, 2013 at 09:35:12PM -0400, Ilija Hadzic wrote:
> > I certainly don't pull patches in from others to it very often, and
> > modetest I generally blame on jbarnes.
> >
>
> Speaking of forgotten patches, could someone with the commit access please
> pick up this one:
>
> http://lists.
> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
> Sent: Thursday, July 04, 2013 4:25 PM
> To: Inki Dae
> Cc: 'Jean-Francois Moine'; 'Daniel Drake'; devicetree-
> disc...@lists.ozlabs.org; dri-devel@lists.freedesktop.org; 'Sascha Hauer';
> 'Russe
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #6 from Michel Dänzer 2013-07-04 08:20:06 ---
(In reply to comment #0)
> with static PM it crashes if you try to change the profile
FWIW, that might work better if you explicitly set the low profile first.
--
Configure bugmail
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> > > Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
> > > really consider Linux framebuffer or other subsystems? The above dtsi file
> > > is specific to DRM subsystem. And I think the dtsi file has no any
>
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
> On 07/04/13 10:33, Sascha Hauer wrote:
> >
> >A componentized device never completes and it doesn't have to. A
> >componentized device can start once there is a path from an input
> >(crtc, i2s unit) to an output (connector, s
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
> On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> > > > > Sorry but I'd like to say that this cannot be used commonly.
> > > > > Shouldn't you
> > > > > r
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote:
> For an upcoming patch where we introduce the i915 VMA, it's ideal to
> have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
> Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
> will break a bunch
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote:
> For an upcoming patch where we introduce the i915 VMA, it's ideal to
> have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
> Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
> will break a bunch
On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
> On 07/04/13 10:53, Sascha Hauer wrote:
> >On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
> >>On 07/04/13 10:33, Sascha Hauer wrote:
> >>>
> >>>A componentized device never completes and it doesn't have
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
> On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
> > On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
> > > Wrong. Please read the example with the diagrams I gave. Consider
> > > what happens if you have tw
https://bugzilla.kernel.org/show_bug.cgi?id=43114
RussianNeuroMancer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, Jul 04, 2013 at 10:08:29AM +0100, Russell King wrote:
> On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> > A componentized device never completes and it doesn't have to. A
> > componentized device can start once there is a path from an input
> > (crtc, i2s unit) to an output
On Thu, Jul 04, 2013 at 11:40:17AM +0200, Sebastian Hesselbarth wrote:
> On 07/04/13 11:23, Sascha Hauer wrote:
> >
> >With this you can describe the whole graph of devices you have in the
> >devicetree. The examples in this file have a path from a camera sensor
> >via a MIPI converter to a capture
On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote:
> On 07/04/13 11:30, Sascha Hauer wrote:
> >On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
> >>On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
> >>>On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell K
Hi
This series changes the way we handle firmware framebuffers on x86 systems. On
other architectures the recently introduced "simple-framebuffer"
platform-devices provide a sane and proper way to handle firmware framebuffers.
So why not use it on x86, too?
This series adds x86 setup code to crea
If we create proper platform-devices in x86 boot-code, we can use simplefb
for VBE or EFI framebuffers, too. However, there is normally no OF support
so we introduce a platform_data object so x86 boot-code can pass the
parameters via plain old platform-data.
This also removes the OF dependency as
fbdev-core uses FBINFO_MISC_FIRMWARE to mark drivers that use firmware
framebuffers. Furthermore, we now allocate apertures for the fbinfo
device.
Both information is used by remove_conflicting_framebuffers() to remove a
fbdev device whenever a real driver is loaded. This is used heavily on x86
for
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/
The EFI FB quirks from efifb.c are useful for simple-framebuffer devices
as well. Apply them by default so we can convert efifb.c to use
efi-framebuffer platform devices.
Signed-off-by: David Herrmann
---
arch/x86/include/asm/sysfb.h | 57 +++
arch/x86/kernel/Makefile | 1 +
arch/
32bit XRGB and ARGB are used by modern x86 systems for EFI and VESA
framebuffers. Add both variants so simplefb can be used on such systems.
Signed-off-by: David Herrmann
---
include/linux/platform_data/simplefb.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data/
x86 creates platform-framebuffer platform devices for every system
framebuffer. Use these instead of creating a dummy device.
This requires us to remove the __init annotations as hotplugging may occur
during runtime.
Signed-off-by: David Herrmann
---
drivers/video/vesafb.c | 55 +++-
Instead of creating a dummy device, we now bind to the efi-fb device
which is provided by x86 initialization code.
Signed-off-by: David Herrmann
---
drivers/video/efifb.c | 68 +--
1 file changed, 22 insertions(+), 46 deletions(-)
diff --git a/dri
fbdev provides framebuffer hotplugging, hence, we need to allow fbcon to
unbind from framebuffers. Unfortunately, fbcon_fb_unbind() cannot unbind
from the last framebuffer, unless console-unbinding is supported.
Fixing fbcon_unbind() to return 0 caused some horrible NULL-derefs in the
VT layer and
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 initial mode.
Userspace can create one dumb-buffer and attach it to the CRTC. Only if
the buffer is destroyed, a new buffer can be created. The
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/simpledrm/Kconfig | 11 ++
drivers/gpu/drm/simpledrm/Makefile | 1 +
drivers/gpu/drm/simpledrm/simpledrm.h | 22
driv
If we load a real hardware DRM driver, we want all firmware drivers to be
unloaded. Historically, this was done via
remove_conflicting_framebuffers(), but for DRM drivers (like SimpleDRM) we
need a new way.
This patch introduces DRIVER_FIRMWARE and DRM apertures to provide a quite
similar way to k
Use the new DRM infrastructure to kick out firmware drivers before probing
the real driver.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_d
Use the new DRM infrastructure to kick out firmware DRM drivers before
loading i915.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index
Kick out firmware DRM and fbdev drivers via the new
drm_kick_out_firmware() before loading radeon.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/radeon/radeon_drv.c | 28
drivers/gpu/drm/radeon/radeon_kms.c | 30 ++
2 files changed, 30
Hi everybody,
for quite some time we have the idea of restructuring the kernel driver code
to actually better reflect the different hardware blocks and also the
different generations of them.
The following patchset starts this task by separating out the UVD block into
files for different UVD gene
From: Christian König
The hardware just doesn't support this correctly.
Disable it before we accidentally write anywhere we shouldn't.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c |3 +--
drivers/gpu/drm/radeon/evergreen.c |3 +--
drivers/gpu/drm/radeon/ni.
From: Christian König
Now that we have callbacks for [rw]ptr handling we can
remove the special handling for the DMA rings and use
the callbacks instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 20 ++-
drivers/gpu/drm/radeon/evergreen.c |6
On Wed, Jul 3, 2013 at 5:02 AM, Sascha Hauer wrote:
> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
>> > video {
>> > /* Single video card w/ multiple lcd controllers */
>> > card0 {
>> > compatible = "marvell,armada-510-display";
>> > reg = <0 0x3f0
https://bugs.freedesktop.org/show_bug.cgi?id=64850
--- Comment #21 from Niels Ole Salscheider ---
Does it work for you with older kernels? If so, can you bisect?
I wonder if this is the same as
https://bugzilla.kernel.org/show_bug.cgi?id=58121 .
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #16 from Pierre Ossman ---
Does anyone have any more ideas as to what I can test?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=64503
--- Comment #17 from Alex Deucher ---
maybe this patch will help?
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=f100380ecd8287b0909d3c5694784adc46e78a4a
Some monitors are picky about the checksum or hdmi version.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=66450
Michel Dänzer changed:
What|Removed |Added
Product|DRI |Mesa
Component|DRM/Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=66452
Michel Dänzer changed:
What|Removed |Added
Product|DRI |Mesa
Component|DRM/Radeon
On 07/04/2013 05:25 AM, David Herrmann wrote:
- What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS?
(other than ARGB/XRGB32)
The common pixel formats on x86 are:
- Palettized 4-bit planar (bigendian, i.e. MSB to the left)
- Palettized 8-bit packed (one byte per pixe
Hello,
Here are two small fixes to the R-Car DU DRM driver. They have previously been
posted as part of the larger "R-Car DU DRM support for R8A7790" series, and
Daniel Vetter rightfully noticed that they should be applied to v3.11.
Laurent Pinchart (2):
drm/rcar-du: Don't ignore rcar_du_crtc_c
Handle error cases correctly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 9c63f39..06cacf6 100644
--- a/dr
The DU requires a 16 pixels pitch alignement. Make sure dumb buffers are
allocated with the correct pitch, and validate the pitch when creating
frame buffers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 19 +++
https://bugs.freedesktop.org/show_bug.cgi?id=66349
--- Comment #3 from Vadim Girlin ---
(In reply to comment #2)
> Created attachment 81982 [details]
> output with R600_DEBUG=sb,ps,vs
>
> Steam also use opengl to draw it's UI so some of these shaders comes from it.
Steam shaders are not a probl
Add new TTM/GEM ioctls to be able to manage buffer regions from
different domains. Included in the new ioctls is the ability to
query hardware information.
Signed-Off-by: James Simmons
---
include/uapi/drm/via_drm.h | 115
1 file changed, 95 inserti
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #13 from Alex Deucher ---
Try comparing the following registers between fglrx and radeon:
0x98FC
0x98F8
0x8950
0x98F4
0x3F88
0x9B7C
0x3F90
0x9148
0x3F94
0x914C
0x8954
0x2004
0x2008
0x2768
0x8B24
0xA008
0xA020
0xA02C
0x9100
0x913C
0x9
On Thu, Jul 04, 2013 at 11:19:58AM +0200, David Herrmann wrote:
> Hi
>
> On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote:
> > For an upcoming patch where we introduce the i915 VMA, it's ideal to
> > have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
> > Part of the conve
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(),
Hi
On Thu, Jul 4, 2013 at 10:14 PM, Ben Widawsky wrote:
> For an upcoming patch where we introduce the i915 VMA, it's ideal to
> have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
> Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
> will break a bunch
> ...
>>> Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
>>> really consider Linux framebuffer or other subsystems? The above dtsi file
>>> is specific to DRM subsystem. And I think the dtsi file has no any
>>> dependency on certain subsystem so board dtsi f
https://bugzilla.kernel.org/show_bug.cgi?id=60510
Bug ID: 60510
Summary: AMD Mobility Radeon HD4650 Screen Corruption with DPM
Product: Drivers
Version: 2.5
Kernel Version: 3.10.0-drm-next-20130705
Hardware: All
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=60510
--- Comment #1 from Wong Yong Jie ---
Created attachment 106792
--> https://bugzilla.kernel.org/attachment.cgi?id=106792&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=60510
--- Comment #2 from Wong Yong Jie ---
Created attachment 106793
--> https://bugzilla.kernel.org/attachment.cgi?id=106793&action=edit
lspci
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=60510
--- Comment #3 from Wong Yong Jie ---
Created attachment 106794
--> https://bugzilla.kernel.org/attachment.cgi?id=106794&action=edit
glxinfo
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60510
--- Comment #4 from Wong Yong Jie ---
Created attachment 106795
--> https://bugzilla.kernel.org/attachment.cgi?id=106795&action=edit
Video BIOS
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
On Thu, Jul 4, 2013 at 5:28 PM, Dave Airlie wrote:
> > ...
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has n
On 07/04/13 09:05, Inki Dae wrote:
-Original Message-
From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
Sent: Wednesday, July 03, 2013 8:52 PM
To: Inki Dae
Cc: 'Russell King'; devicetree-disc...@lists.ozlabs.org; 'Jean-Francois
Moine'; 'Sascha Hauer'; 'Daniel Drake'; dr
On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> > > > Sorry but I'd like to say that this cannot be used commonly. Shouldn't
> > > > you
> > > > really consider Linux framebuffer or other subsystems? The above dtsi
>
On 07/04/13 10:33, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the
On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> A componentized device never completes and it doesn't have to. A
> componentized device can start once there is a path from an input
> (crtc, i2s unit) to an output (connector, speaker).
Sorry for the incomplete reply.
If you read al
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
componentized device can start once there is a path from an input
(crtc, i2s uni
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
> > Wrong. Please read the example with the diagrams I gave. Consider
> > what happens if you have two display devices connected to a single
> > output, one which fixes th
On 07/04/13 11:23, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never comp
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
Wrong. Please read the example with the diagrams I gave. Consider
w
On 07/04/13 12:09, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 11:30, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
On Thu, Jul 04, 2013
From: Wei Yongjun
In case of error, the function ipp_find_obj() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 ++--
1 file changed, 6 insert
https://bugs.freedesktop.org/show_bug.cgi?id=66067
--- Comment #4 from Nicholas Miell ---
Created attachment 82060
--> https://bugs.freedesktop.org/attachment.cgi?id=82060&action=edit
Call 5654455, GL_COLOR_ATTACMENT0, Mesa
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=66067
--- Comment #5 from Nicholas Miell ---
Created attachment 82061
--> https://bugs.freedesktop.org/attachment.cgi?id=82061&action=edit
Call 5654455, GL_COLOR_ATTACMENT0, Catalyst
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=66067
Nicholas Miell changed:
What|Removed |Added
Attachment #82061|Call 5654455, |Call 5654455,
description|GL_COL
On Thu, Jul 4, 2013 at 5:14 PM, Joonyoung Shim wrote:
> On 07/04/2013 07:11 AM, Laurent Pinchart wrote:
>>
>> Hi Joonyoung,
>>
>> Thank you for the patches.
>>
>> On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote:
>>>
>>> Hello,
>>>
>>> This is the second version patchset.
>>>
>>> GEM CMA suppo
On 07/05/2013 02:38 PM, Dave Airlie wrote:
On Thu, Jul 4, 2013 at 5:14 PM, Joonyoung Shim wrote:
On 07/04/2013 07:11 AM, Laurent Pinchart wrote:
Hi Joonyoung,
Thank you for the patches.
On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote:
Hello,
This is the second version patchset.
GEM C
>From drm gem CMA helper, it wasn't fixed dma_buf refcount problem fixed
by commit 011c228. This patch solves it.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_gem_cma_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/
Hi Joonyoung,
Thank you for the patches.
On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote:
> Hello,
>
> This is the second version patchset.
>
> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
> dma_buf. We can use prime helpers for dma_buf by commit
> 89177644a7b63
Working on KMS support on OpenBSD/sparc64, I ended up with the initial
framebuffer on a Sun XVR-100 card (Radeon 7000/VE, RV100 with
OpenFirmware) being tiled when none of the tiling flags were set.
Tracked it down to an issue with r100_set_surface_reg(). The tiling
bits on these older chips are a
nts/20130704/5fc948c3/attachment-0001.obj>
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 45824 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/5fc948c3/attachment-0001.bin>
https://bugzilla.kernel.org/show_bug.cgi?id=60381
Summary: AMD Radeon 7770 Ghz edition Crash with DPM active
Product: Drivers
Version: 2.5
Kernel Version: 3.10.0-next-20130703
Platform: All
OS/Version: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #1 from rafael castillo 2013-07-04
00:38:04 ---
Created an attachment (id=106741)
--> (https://bugzilla.kernel.org/attachment.cgi?id=106741)
glxinfo
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #2 from rafael castillo 2013-07-04
00:38:24 ---
Created an attachment (id=106751)
--> (https://bugzilla.kernel.org/attachment.cgi?id=106751)
lspci
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
-
https://bugzilla.kernel.org/show_bug.cgi?id=60381
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #4 from rafael castillo 2013-07-04
01:11:51 ---
thanks for your response, im attaching the vbios info but im unable to get an
dmesg output in the moment of the crash since it kicks in kms load and
hangs[keyboard keys blinking] an
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #5 from rafael castillo 2013-07-04
01:12:10 ---
Created an attachment (id=106781)
--> (https://bugzilla.kernel.org/attachment.cgi?id=106781)
vbios.rom
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
-
> -Original Message-
> From: Russell King [mailto:rmk at arm.linux.org.uk]
> Sent: Wednesday, July 03, 2013 9:05 PM
> To: Inki Dae
> Cc: 'Sebastian Hesselbarth'; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-
> Francois Moine'; devicetree-discuss at lists.ozlabs.org; dri-
> devel at lists.freedes
> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
> Sent: Wednesday, July 03, 2013 8:52 PM
> To: Inki Dae
> Cc: 'Russell King'; devicetree-discuss at lists.ozlabs.org; 'Jean-Francois
> Moine'; 'Sascha Hauer'; 'Daniel Drake'; dri-devel at lists.
On 07/04/2013 07:11 AM, Laurent Pinchart wrote:
> Hi Joonyoung,
>
> Thank you for the patches.
>
> On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote:
>> Hello,
>>
>> This is the second version patchset.
>>
>> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
>> dma_buf. We
The drm_gem_map_detach() can be called with sgt is NULL.
Change-Id: I3b2f5878dfac6e1e77aebeeb7be781113dec59a7
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/dr
The drm_gem_map_detach() can be called with sgt is NULL.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1e0de41..ff5fece 100644
--- a/dri
On Don, 2013-07-04 at 00:51 +0200, Andrej Gelenberg wrote:
>
> i have an Radeon HD 7870 GHz Edition graphic card and at finnaly got
> some 3D and VDPAU acceleration with kernel 3.10, mesa 9.2 from
> 19.6.2013 and glamor accelerations, but it carsh a lot. I attached
> dmesg witch hopefully helpful
Hi Dave,
This is final pull request for 3.11. This resolves some memory leak
issues, and includes some code and dt document file cleanups; just
removed unnecessary descriptions.
And the patch work for enhancing hdmiphy driver isn't in progress so
this patch may go to 3.12.
Please
On Wed, Jul 03, 2013 at 09:35:12PM -0400, Ilija Hadzic wrote:
> > I certainly don't pull patches in from others to it very often, and
> > modetest I generally blame on jbarnes.
> >
>
> Speaking of forgotten patches, could someone with the commit access please
> pick up this one:
>
> http://lists.
> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
> Sent: Thursday, July 04, 2013 4:25 PM
> To: Inki Dae
> Cc: 'Jean-Francois Moine'; 'Daniel Drake'; devicetree-
> discuss at lists.ozlabs.org; dri-devel at lists.freedesktop.org; 'Sascha
> Haue
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #6 from Michel D?nzer 2013-07-04 08:20:06
---
(In reply to comment #0)
> with static PM it crashes if you try to change the profile
FWIW, that might work better if you explicitly set the low profile first.
--
Configure bugmai
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> > > Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
> > > really consider Linux framebuffer or other subsystems? The above dtsi file
> > > is specific to DRM subsystem. And I think the dtsi file has no any
>
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
> On 07/04/13 10:33, Sascha Hauer wrote:
> >
> >A componentized device never completes and it doesn't have to. A
> >componentized device can start once there is a path from an input
> >(crtc, i2s unit) to an output (connector, s
On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
> On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> > > > > Sorry but I'd like to say that this cannot be used commonly.
> > > > > Shouldn't you
> > > > > r
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote:
> For an upcoming patch where we introduce the i915 VMA, it's ideal to
> have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
> Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
> will break a bunch
1 - 100 of 159 matches
Mail list logo
