>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/
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=66067
Nicholas Miell changed:
What|Removed |Added
Attachment #82061|Call 5654455, |Call 5654455,
description|GL_COL
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
--- 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
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
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
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 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 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 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: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: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:
> 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 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
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
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.
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 #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 #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
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
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
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
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
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 +++
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
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
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/145a0ebe/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/83a36dc2/attachment.html>
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
|Drivers/Gallium/r600
--
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/dri-devel/attachments/20130704/186ea491/attachment.html>
|Drivers/Gallium/r600
--
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/dri-devel/attachments/20130704/0915d9ba/attachment.html>
> -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
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/dri-devel/attachments/20130704/6c311c9b/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/5d55e8bc/attachment.html>
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
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
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
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130704/805e9f78/attachment.html>
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
> -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.
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.
_
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 #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.
__
From: Christian K?nig
Our different hardware blocks are actually completely
separated, so it doesn't make much sense any more to
structure the code by pure chipset generations.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/Makefile | 12 +-
drivers/gpu/drm/radeon/cik.c
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
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
Give the ring functions a separate structure and let the asic
structure point to the ring specific functions. This simplifies
the code and allows us to make changes at only point.
No change in functionality.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeo
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
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
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
> ...
>>> 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
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
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
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
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
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
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
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
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
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 +++-
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/
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/
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/
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
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
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
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
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(),
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(),
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
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
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
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
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
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
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
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
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 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. C
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 componentize
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
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
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 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
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
>>
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.
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 +++
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
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
> -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
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
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 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
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 pix
https://bugs.freedesktop.org/show_bug.cgi?id=66450
Michel Dänzer changed:
What|Removed |Added
Product|DRI |Mesa
Component|DRM/Radeon
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. A
1 - 100 of 159 matches
Mail list logo
