On Fre, 2012-04-20 at 00:39 +0200, Christian König wrote:
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> b/drivers/gpu/drm/radeon/radeon_fenc
On Fre, 2012-04-20 at 00:39 +0200, Christian König wrote:
> Make the suballocator self containing to locking
> and fix a overrun bug which happens with
> allocations of different alignments.
Sounds like this should be split up into two changes. :)
--
Earthling Michel Dänzer |
On Fri, Apr 20, 2012 at 07:57:09AM +0100, Dave Airlie wrote:
> 2012/4/19 Christian König :
> > Instead of all this humpy pumpy with recursive
> > mutex (which also fixes only halve of the problem)
> > move the actual gpu reset out of the fence code,
> > return -EDEADLK and then reset the gpu in the
Hi Mauro,
On 04/19/2012 10:37 PM, Mauro Carvalho Chehab wrote:
> Em 19-04-2012 11:32, Tomasz Stanislawski escreveu:
>
>> Hi Laurent,
>>
>> One may find similar sentences in MMAP, USERPTR and DMABUF.
>> Maybe the common parts like description of STREAMON/OFF,
>> QBUF/DQBUF shuffling should be mov
On 20.04.2012 09:20, Michel Dänzer wrote:
On Fre, 2012-04-20 at 00:39 +0200, Christian König wrote:
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/dri
Hi Laurent,
On 04/17/2012 02:43 AM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> On Friday 13 April 2012 17:47:50 Tomasz Stanislawski wrote:
>> From: Andrzej Pietrasiewicz
>>
>> This patch introduces usage of dma_map_sg to map memory behind
>> a userspace pointer to a dev
On 20.04.2012 09:24, Michel Dänzer wrote:
On Fre, 2012-04-20 at 00:39 +0200, Christian König wrote:
Make the suballocator self containing to locking
and fix a overrun bug which happens with
allocations of different alignments.
Sounds like this should be split up into two changes. :)
Yeah you
On Fre, 2012-04-20 at 10:49 +0200, Christian König wrote:
> On 20.04.2012 09:20, Michel Dänzer wrote:
> > On Fre, 2012-04-20 at 00:39 +0200, Christian König wrote:
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
> >> 1 files changed, 2 insert
On 20.04.2012 09:50, Daniel Vetter wrote:
On Fri, Apr 20, 2012 at 07:57:09AM +0100, Dave Airlie wrote:
2012/4/19 Christian König:
Instead of all this humpy pumpy with recursive
mutex (which also fixes only halve of the problem)
move the actual gpu reset out of the fence code,
return -EDEADLK an
On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft wrote:
> We have been carrying a (rather poor) patch for an issue we identified in
> the DRM driver. This issue is triggered when a DRM device is initialising
> and userspace attempts to open it, typically in response to the sysfs
> device added eve
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #25 from Tvrtko Ursulin 2012-04-20
03:01:35 PDT ---
(In reply to comment #22)
> Created attachment 60315 [details] [review]
> possible fix
>
> use fract fb div on APUs. Tested on all the hw I have available. Does this
> patch help
On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer wrote:
> This patch adds support for creating simple drm devices. The
> basic idea of this patch is that drm drivers using the sdrm layer
> no longer have to implement a full drm device but instead only
> register crtcs, encoders and connectors with th
On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
wrote:
> Make dev_mapping per-minor instead of per device. This is
> a preparatory patch for introducing render nodes. This
> will allow per-node instead of per-device mapping range,
> once we introduce render nodes.
One problem is this introduces a t
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #17 from Tvrtko Ursulin 2012-04-20
03:07:55 PDT ---
Still leaves the monitor in that weird state (black screen but not powersave,
can't get to OSD menu) after re-plug.
"xset dpms force off" can put it into proper power save.
"xset
> +/* render node create and remove functions
> + if crtc/encoders/connectors/planes all == 0 then gpgpu node */
> +struct drm_render_node_create {
> + __u32 node_minor_id;
> + __u32 num_crtc;
> + __u32 num_encoder;
> + __u32 num_connector;
> + __u32 num_plane;
> +
On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
wrote:
> The following set of patches is the reword of the series
> sent two weeks ago [2] that will revive the drm-render-nodes [1]
> branch. Details of the original series are described in [2].
Thanks for looking at this,
So one thing about adding
On 20.04.2012 11:15, Michel Dänzer wrote:
On Fre, 2012-04-20 at 10:49 +0200, Christian König wrote:
On 20.04.2012 09:20, Michel Dänzer wrote:
On Fre, 2012-04-20 at 00:39 +0200, Christian König wrote:
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
1 f
On Fri, Apr 20, 2012 at 10:40:35AM +0100, Dave Airlie wrote:
> I've just revisited this, maybe I'm going insane but why does
> drm_global_mutex not stop this?
>
> drm_get_pci_dev takes drm_global_mutex before calling drm_fill_in_dev
> and drm_get_minor.
>
> Now the fops should be pointing at stu
>
> I may be reading things wrong but the initialisation does indeed hold
> drm_global_mutex, but and back when this first occured we would have
> been using kernel_lock() which was at least partially reentrant right?
Yup if we slept with the BKL held we'd have allowed others to get past it,
but
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #10 from Tvrtko Ursulin 2012-04-20
03:43:13 PDT ---
Does the driver know it's memory bandwidth so it could remove modes it cannot
drive from the list?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
-
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #26 from Tvrtko Ursulin 2012-04-20
03:45:09 PDT ---
Other than that we are testing your patch on a wider range of monitors/displays
and if that goes well will take it.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cg
On Fre, 2012-04-20 at 12:24 +0200, Christian König wrote:
> On 20.04.2012 11:15, Michel Dänzer wrote:
> > On Fre, 2012-04-20 at 10:49 +0200, Christian König wrote:
> >> On 20.04.2012 09:20, Michel Dänzer wrote:
> >>> On Fre, 2012-04-20 at 00:39 +0200, Christian König wrote:
> Signed-off-by: C
On Thu, Apr 5, 2012 at 7:35 PM, wrote:
> From: Ville Syrjälä
>
> There will be a need for this function in drm_crtc.c later. This
> avoids making drm_crtc.c depend on drm_crtc_helper.c.
Hi Ville,
I've applied these 4 patches, but I might have lost some others for
you, let me know if there is s
On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai wrote:
> At Tue, 17 Apr 2012 17:26:26 +0200,
> Takashi Iwai wrote:
>>
>> At Fri, 13 Apr 2012 16:56:26 -0400,
>> Adam Jackson wrote:
>> >
>> > On 4/13/12 4:33 PM, Adam Jackson wrote:
>> > > Incorporates some feedback from Rodrigo and Takashi. Major the
On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai wrote:
> At Thu, 19 Apr 2012 14:03:58 +0200,
> Takashi Iwai wrote:
>>
>> At Tue, 17 Apr 2012 17:26:26 +0200,
>> Takashi Iwai wrote:
>> >
>> > At Fri, 13 Apr 2012 16:56:26 -0400,
>> > Adam Jackson wrote:
>> > >
>> > > On 4/13/12 4:33 PM, Adam Jackson wr
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_tv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index ca12c70..67f444d 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_volt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_volt.c
b/drivers/gpu/drm/nouveau/nouveau_volt.c
index b010cb9..fdc8f77 100644
--- a/drivers/gpu/drm/
On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
> On Thu, Apr 5, 2012 at 7:35 PM, wrote:
> > From: Ville Syrjälä
> >
> > There will be a need for this function in drm_crtc.c later. This
> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
>
> Hi Ville,
>
> I've applied these
Hi Remi,
On 04/20/2012 12:56 PM, Rémi Denis-Courmont wrote:
> On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
> wrote:
>>> Am I understanding wrong or are you saying that you want to drop
> userptr
>>> from V4L2 API in long-term? If so, why?
>>
>> Dropping userptr is just some brainstormi
On Fri, 20 Apr 2012 13:13:54 +0100, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.o
Hi,
So I've spent today trawling and most likely missing patches on the
list for -next.
-next before today had:
an intel -next from Daniel
radeon - copy optimisation, pci bus master race fix.
two agp patches
I've merged today into drm-core-next
Ville's framebuffer creation sanity check series
Pa
On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
wrote:
> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
>> On Thu, Apr 5, 2012 at 7:35 PM, wrote:
>> > From: Ville Syrjälä
>> >
>> > There will be a need for this function in drm_crtc.c later. This
>> > avoids making drm_crtc.c depend
At Fri, 20 Apr 2012 13:04:42 +0100,
Dave Airlie wrote:
>
> On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai wrote:
> > At Tue, 17 Apr 2012 17:26:26 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Fri, 13 Apr 2012 16:56:26 -0400,
> >> Adam Jackson wrote:
> >> >
> >> > On 4/13/12 4:33 PM, Adam Jackson wro
At Fri, 20 Apr 2012 13:05:48 +0100,
Dave Airlie wrote:
>
> On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai wrote:
> > At Thu, 19 Apr 2012 14:03:58 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Tue, 17 Apr 2012 17:26:26 +0200,
> >> Takashi Iwai wrote:
> >> >
> >> > At Fri, 13 Apr 2012 16:56:26 -0400,
* Dave Airlie wrote:
> I get the feeling the drm can just be a virtual platform device of
> some sort, then it reads the device tree and binds all the information
> on what crtc/encoders are available,
That's pretty much what I've come up with in the second round of Tegra DRM
patches. Basically di
On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie wrote:
> On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
> wrote:
>> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
>>> On Thu, Apr 5, 2012 at 7:35 PM, wrote:
>>> > From: Ville Syrjälä
>>> >
>>> > There will be a need for this function
Hi Tomasz,
On 04/13/2012 05:47 PM, Tomasz Stanislawski wrote:
> This patch enhances s5p-fimc with support for DMABUF importing via
> V4L2_MEMORY_DMABUF memory type.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
Acked-by: Sylwester Nawrocki
Just one nitpick, please cha
https://bugzilla.kernel.org/show_bug.cgi?id=43138
Summary: Radeon HD5450 fails to load cedar firmware ?
Product: Drivers
Version: 2.5
Kernel Version: 3.3.2.
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
[Added some embedded graphics maintainers to Cc who might be interested
in this]
On Fri, Apr 20, 2012 at 11:02:02AM +0100, Dave Airlie wrote:
> On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer wrote:
> > This patch adds support for creating simple drm devices. The
> > basic idea of this patch is tha
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> * Dave Airlie wrote:
> > I get the feeling the drm can just be a virtual platform device of
> > some sort, then it reads the device tree and binds all the information
> > on what crtc/encoders are available,
>
> That's pretty much w
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #1 from Michel Dänzer 2012-04-20 13:28:55 ---
(In reply to comment #0)
> r600_cp: Bogus length 4480 in firmware "radeon/CEDAR_me.bin"
> r600_rlc: Bogus length 5504 in firmware "radeon/CEDAR_rlc.bin"
What does
ls -l /lib/firmwar
On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
> (BTW each driver in drm has this layer somewhere in it. If I had hidden
> it in imx specific functions I probably wouldn't have raised any
> questions, but I don't want to go that way)
That's _exactly_ what you should be doing. And on
On Fri, Apr 20, 2012 at 11:20:45AM +0100, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> wrote:
> > The following set of patches is the reword of the series
> > sent two weeks ago [2] that will revive the drm-render-nodes [1]
> > branch. Details of the original series are des
On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie wrote:
> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
> > wrote:
> >> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
> >>> On Thu, Apr 5, 2012 at 7:35 PM, wrote:
> >>> > F
On Fri, Apr 20, 2012 at 01:24:59PM +0100, Chris Wilson wrote:
> On Fri, 20 Apr 2012 13:13:54 +0100, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > Signed-off-by: Dave Airlie
> Reviewed-by: Chris Wilson
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mo
On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
wrote:
>> Am I understanding wrong or are you saying that you want to drop
userptr
>> from V4L2 API in long-term? If so, why?
>
> Dropping userptr is just some brainstorming idea.
> It was found out that userptr is not a good mean
> for buff
On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski
wrote:
>>> The USERPTR simplifies userspace code but introduce
>>> a lot of complexity problems for the kernel drivers
>>> and frameworks.
>>
>> It is not only a simplification. In some cases, USERPTR is the only I/O
>> method that supports
Em 20-04-2012 07:56, Rémi Denis-Courmont escreveu:
> On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
> wrote:
>>> Am I understanding wrong or are you saying that you want to drop
> userptr
>>> from V4L2 API in long-term? If so, why?
>>
>> Dropping userptr is just some brainstorming idea.
>
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].
v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages
From: Sumit Semwal
Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.
Signed-off-by: Tomasz Stanislawski
[original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal
Signed-off-by: Sumit Semwal
Acked-by: Laurent Pinch
On Fri, Apr 20, 2012 at 8:49 AM, Ville Syrjälä
wrote:
> On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
>> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie wrote:
>> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
>> > wrote:
>> >> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wr
https://bugzilla.kernel.org/show_bug.cgi?id=42729
subscription.discuss...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
From: Sumit Semwal
Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.
Signed-off-by: Tomasz Stanislawski
[original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal
Signed-off-by: Sumit Semwal
Acked-by: Laurent Pinch
From: Sumit Semwal
Adding DMABUF memory type causes videobuf to complain about not using it
in some switch cases. This patch removes these warnings.
Signed-off-by: Sumit Semwal
Acked-by: Laurent Pinchart
---
drivers/media/video/videobuf-core.c |4
1 files changed, 4 insertions(+), 0
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].
v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages
vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
allocation context. That structure only stores a pointer to the physical
device. Remove it and use the device pointer directly as the allocation
context.
Signed-off-by: Tomasz Stanislawski
Acked-by: Laurent Pinchart
---
drivers/
This patch enhances s5p-tv with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-tv/Kconfig |1 +
drivers/media/video/s5p-tv/mixer_video.c |2 +-
2 files changed, 2 insertio
From: Laurent Pinchart
Group functions by buffer type.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 92 ---
1 files changed, 54 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media
This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 179 +++
From: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
in
From: Andrzej Pietrasiewicz
This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
[bugfixing]
Signed-off-by: Kamil Debski
[bugfixing]
Signed
From: Marek Szyprowski
This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.
Signed-off-by: Marek Szyprowski
Acked-by: Laurent Pinchart
---
drivers/media/video/videobuf2-core.c | 11 +++
include/media/videobuf2-core.h
From: Marek Szyprowski
Add prepare/finish callbacks to vb2-dma-contig allocator.
Signed-off-by: Marek Szyprowski
---
drivers/media/video/videobuf2-dma-contig.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-con
From: Sumit Semwal
This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.
Signed-off-by: Sumit Semwal
Signed-off-by: Sumit Semwal
[author of the original patch]
This patch enhances s5p-fimc with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Acked-by: Sylwester Nawrocki
---
drivers/media/video/Kconfig |1 +
drivers/media/video/s5p-fimc/fimc-capture.c
From: Sumit Semwal
This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A s
* Mark Brown wrote:
> On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> > * Dave Airlie wrote:
> > > I get the feeling the drm can just be a virtual platform device of
> > > some sort, then it reads the device tree and binds all the information
> > > on what crtc/encoders are availa
* Mark Brown wrote:
> On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
> > * Mark Brown wrote:
>
> > > This sounds an awful lot like how ASoC hangs together...
>
> > What in particular sounds awful?
>
> Nothing - "an awful" is an English idiom for "very".
I know =) But it has a s
On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:
> On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> > * Dave Airlie wrote:
> > > I get the feeling the drm can just be a virtual platform device of
> > > some sort, then it reads the device tree and binds all the informatio
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #11 from Alex Deucher 2012-04-20 08:19:54 PDT ---
(In reply to comment #9)
>
> I never really understood this problem, not since the days of sdr. Single
> channel ddr3-1066 provides roughly 8 times the raw bandwidth of what a
> 2560x
From: Ville Syrjälä
The NV12M/YUV420M formats are identical to the already existing standard
NV12/YUV420 formats. The M variants will be removed, so convert the
driver to use the standard names.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
The NV12M/YUV420M formats are identical to the NV12/YUV420 formats.
So just remove these duplicated format names.
This might look like breaking the ABI, but the code has never actually
accepted these formats, so nothing can be using them.
Signed-off-by: Ville Syrjälä
---
i
https://bugs.freedesktop.org/show_bug.cgi?id=27541
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Em 20-04-2012 09:25, Tomasz Stanislawski escreveu:
> Hi Remi,
>> Now, I do realize that some devices cannot support USERPTR efficiently,
>> then they should not support USERPTR.
>
> The problem is not there is *NO* device that can handle USERPTR reliably.
> The can handle USERPTR generated by ma
On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> * Dave Airlie wrote:
> > I get the feeling the drm can just be a virtual platform device of
> > some sort, then it reads the device tree and binds all the information
> > on what crtc/encoders are available,
> That's pretty much wha
On Fri, Apr 20, 2012 at 05:15:18PM +0200, Sascha Hauer wrote:
> On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:
> > This sounds an awful lot like how ASoC hangs together...
> Very much, yes. In ASoC and DRM we both have several physical devices spread
> around the SoC which form a log
On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
> * Mark Brown wrote:
> > This sounds an awful lot like how ASoC hangs together...
> What in particular sounds awful?
Nothing - "an awful" is an English idiom for "very".
signature.asc
Description: Digital signature
__
On Fri, Apr 20, 2012 at 11:34:43AM +0100, Dave Airlie wrote:
> >
> > I may be reading things wrong but the initialisation does indeed hold
> > drm_global_mutex, but and back when this first occured we would have
> > been using kernel_lock() which was at least partially reentrant right?
>
> Yup if
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #12 from Alex Deucher 2012-04-20 12:01:54 PDT ---
Can you attach the xorg log and dmesg output with the DP monitor attached?
What's the modeline for the 2560x1440 mode?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.c
https://bugzilla.kernel.org/show_bug.cgi?id=43138
bugt...@hobbit.in-berlin.de changed:
What|Removed |Added
Platform|All |i386
--- Comment #2 from
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #3 from bugt...@hobbit.in-berlin.de 2012-04-20 19:46:24 ---
already tried fetching from http://people.freedesktop.org/~agd5f/radeon_ucode/
directly as well as installing standard Debian distri kernel & firmware
package, same error,
https://bugzilla.kernel.org/show_bug.cgi?id=43138
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #4 f
On Fri, Apr 20, 2012 at 8:27 AM, Dave Airlie wrote:
> Hi,
>
> So I've spent today trawling and most likely missing patches on the
> list for -next.
>
> -next before today had:
> an intel -next from Daniel
> radeon - copy optimisation, pci bus master race fix.
> two agp patches
>
> I've merged toda
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #69 from Gilles Dartiguelongue
2012-04-20 16:41:09 PDT ---
I pushed the current state of the code here:
https://github.com/EvaSDK/linux/commit/d590f8631a2421ba6bcef7041888b3aa382f87c7
I commented out dpms code for testing, but given
https://bugs.freedesktop.org/show_bug.cgi?id=49029
Bug #: 49029
Summary: [DRM,KMS,R300,laptop]Power management not working
Classification: Unclassified
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
2012년 4월 20일 오후 11:22, Rob Clark 님의 말:
> On Fri, Apr 20, 2012 at 8:49 AM, Ville Syrjälä
> wrote:
>> On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
>>> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie wrote:
>>> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
>>> > wrote:
>>> >> On Fri,
thanks for your patch but your patch set needs some codes for
identifying whether pixel format is multiplanar or not as you
mentioned. so I will add the codes and apply your patch set to
exynos-drm-fixes branch for drm-fixes.
2012년 4월 21일 오전 12:26, 님의 말:
> From: Ville Syrjälä
>
> The NV12M/YUV4
https://bugs.freedesktop.org/show_bug.cgi?id=49030
Bug #: 49030
Summary: Possible recursive locking detected in r600g
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Bad kernel: 3.4-rc3
Last known good: 3.3
Subsystem: dri-intel (guess)
Steps to reproduce:
1. Suspend to ram
2. Resume
After resume laptop works ok, but in dmesg I found:
[ 164.098113] [ cut here ]
[ 164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
gen6_gt_ch
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #5 from bugt...@hobbit.in-berlin.de 2012-04-21 06:51:09 ---
considering the age of that code I share your suspicions, but why then does a
stock debian kernel & initrd show same behavior as my self-compiled (newer)
one?
--
Configu
This includes mostly fixes for multi ring lockups and GPU resets, but it should
general improve the behavior of the kernel mode driver in case something goes
badly wrong.
On the other hand it completely rewrites the IB pool and semaphore handling, so
I think there are still a couple of problems
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 44 ++--
driver
It makes no sense at all to have more than one flag.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_devi
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a
Make the suballocator self containing to locking
and fix a overrun bug which happens with
allocations of different alignments.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c | 19 ---
2 files changed, 13 insert
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |7 ++-
drivers/gpu/drm/r
Previusly multiple ring could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 146 +
2 files changed, 75 insertions(+), 74 deletions(-)
diff
Dumping the current allocations.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_sa.c | 15 +++
3 files changed, 42 insertions(+), 0 delet
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 1a9765a..764ab7e 100644
--- a/drivers/gpu/drm/radeon/radeon_fen
With that in place clients are automatically blocking
until their memory request can be handled.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |5 +-
drivers/gpu/drm/radeon/radeon_ring.c | 18 ++--
drivers/gpu/drm/radeon/radeon_sa.c | 192 ++
1 - 100 of 195 matches
Mail list logo
