This patch fixes flags passed to dma buf exporting.
Signed-off-by: Seung-Woo Kim
Cc: Rob Clark
---
I found omap drm also sends wrong flag for dma buf exporting. So I send this
based on drm-fixes branch.
drivers/staging/omapdrm/omap_gem_dmabuf.c |2 +-
1 files changed, 1 insertions(+), 1 de
This patch fixes flags passed to dma buf exporting.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin.park
---
I found exynos drm also sends wrong flag for dma buf exporting. So I send this
based on drm-fixes branch.
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
1 files changed, 1 i
https://bugzilla.kernel.org/show_bug.cgi?id=43751
Alexey Neyman changed:
What|Removed |Added
CC||sti...@att.net
--- Comment #5 from Al
The intention is to program exactly WIN_A, not WIN_A and possibly
others.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/dc.c | 3 +--
1 Datei ge?ndert, 1 Zeile hinzugef?gt(+), 2 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b256574..3475bd9
There is no gem.c anymore, those functions are implemented by the
drm_cma_helpers now.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/drm.h | 18 --
1 Datei ge?ndert, 18 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index eae1f56
The 720p and 1080p entries are completely redundant, as we are matching
the table entries against <=pclk.
Also generalize the comment, as we are using those table entries even
when driving other modes than the standard TV ones.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/hdmi.c | 19 +++
Window properties are programmed through a shared aperture and have to
happen atomically. Also we do the read-update-write dance on some of the
shared regs.
To make sure that different functions don't stumble over each other
protect the register access with a mutex.
Signed-off-by: Lucas Stach
---
No real problem for now, as nothing is using this, but leaving it
unitialized is asking for trouble later on.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/host1x.c | 2 ++
1 Datei ge?ndert, 2 Zeilen hinzugef?gt(+)
diff --git a/drivers/gpu/drm/tegra/host1x.c b/drivers/gpu/drm/tegra/host1
Fixes wrong picture offset observed when using HDMI output with a
Technisat HD TV.
Signed-off-by: Lucas Stach
Acked-by: Mark Zhang
Tested-by: Mark Zhang
---
Captions are a bit confusing here. As the porch is always relative to
the sync pulse, the left picture margin is actually the back_porch.
Some small fixes and cleanups for the tegradrm driver.
This is potentially 3.8-fixes material.
Lucas Stach (6):
drm: tegra: fix front_porch <-> back_porch mixup
drm: tegra: don't leave clients host1x member uninitialized
drm: tegra: protect DC register access with mutex
drm: tegra: remove
Hi Linus,
just a single urgent regression fix, seeing a few wierd behaviours I'd
like not to persist.
Dave.
The following changes since commit 55bde6b1442fed8af67b92d21acce67db454c9f9:
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-12-1
> Here you go :)
>
> I managed to reproduce the issue. Please test this patch!
Okay switching to automatic mode when pwm1 == 100 now gradually (in a
few seconds, it is not cut down to 35 suddenly) lowers it down to 35.
Switching to automatic mode while in manual mode doesn't make the pwm
increase
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/b27ef553/attachment.html>
On Tue, Dec 18, 2012 at 10:25:05PM +0100, Daniel Vetter wrote:
> And do a quick pass to adjust them to the last few (years?) of changes
> ...
>
> This time actually compile-tested ;-)
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl |4 ++
> drivers/gpu/drm/drm_crtc.c
spin_unlock(&bdev->fence_lock);
>
> atomic_set(&bo->reserved, 0);
Acked-by: Paul Menzel
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/1a1d7db2/attachment.pgp>
From: Dave Airlie
This is likely the simplest solution to the problem, and seems
to work fine.
When we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the r
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/d0c955d8/attachment.html>
On Thu, Dec 20, 2012 at 11:26 AM, Dave Airlie wrote:
> On Fri, Dec 14, 2012 at 7:36 PM, wrote:
>> From: Sumit Semwal
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
I've attached two patches that make it work on my system, and fix the war
We must forget about that. I believe no one read the header files while
review. So thanks. :)
Mark
On 12/20/2012 05:38 AM, Lucas Stach wrote:
> There is no gem.c anymore, those functions are implemented by the
> drm_cma_helpers now.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/tegra/d
OK, you add a mutex in a tegra_dc structure. But I think there is no
parallel scenario while we operate on a dc. AFAIK, the functions which
you add mutex protection are called by drm sequentially(except for
function "tegra_crtc_load_lut" I'm not very clear about that).
So could you give us an exam
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/de5e10d9/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/d84f23c1/attachment-0001.html>
Op 19-12-12 15:18, Maarten Lankhorst schreef:
> Fix regression introduced by 85b144f860176
>
> Signed-off-by: Maarten Lankhorst
> Reported-by: Markus Trippelsdorf
>
Hey Paul Menzel,
I just wanted to have the fix out asap, and had to leave right after.
Updated commit message below:
Fix regressi
for other purposes than with DRM.
He had an example of a board, that (if I understood right) gets video
signal from somewhere outside the board, processes the signal with some
IPs/chips, and then outputs the signal. So there's no framebuffer, and
the image is not stored anywhere. I think the
On Fri, Dec 14, 2012 at 7:36 PM, wrote:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
I like thie idea,
/home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: In function
‘dma_buf_describe’:
/home/airlied/devel/kern
s scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/4f2f77d6/attachment-0001.pgp>
On 2012.12.19 at 15:54 +0100, Markus Trippelsdorf wrote:
> On 2012.12.19 at 09:47 -0500, Alex Deucher wrote:
>
> And the pictures get distorted on the test-webpage when I scroll up and
> down, see:
> http://trippelsdorf.de/bad.png
The picture distortion issue is caused by:
commit dd54fee7d440c4a
Hi Laurent -
On Tue, 18 Dec 2012, Laurent Pinchart
wrote:
> Hi Jani,
>
> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
>> I can see the need for a framework for DSI panels and such (in fact Tomi
>> and I have talked about it like 2-3 years ago already!) but what is the
>> story for HDM
e
perhaps simpler to implement for the one handling the video source ops,
so...
> The DVI and DSI operations model proposed by Tomi in this patch series will
> be
> kept.
>
> Points that we forgot to discuss
>
>
> - DISPLAY_ENTITY_STREAM_SINGLE_SHOT vs. update() operation
Ah, yes, we missed that. I think it's possible to use SINGLE_SHOT, but
then it requires some kind of system to inform about finished update. Or
we could, of course, decide that informing about the update is done in
dispc-specific code, like handling VSYNC.
Hmm, except that won't probably work, as the panel (or any DSI device)
may need to know if the DSI bus is currently used or not.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/03f53d95/attachment-0001.pgp>
From: Dave Airlie
As pointed out by Seung-Woo Kim this should have been
passing flags like nouveau/radeon have.
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas
> In drm_prime_handle_to_fd_ioctl(), flags is cleared to only support
> DRM_CLOEXEC but in gem_prime_export() callbacks of each driver, it uses
> 0600 as flags for dma_buf_export() like following.
>
> return dma_buf_export(obj, &i915_dmabuf_ops, obj->base.size, 0600);
Oops, nice catch, radeon and
From: Dave Airlie
This is likely the simplest solution to the problem, and seems
to work fine.
When we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the r
On 19/12/2012 20:39, Ozan Çağlayan wrote:
Here you go :)
I managed to reproduce the issue. Please test this patch!
Okay switching to automatic mode when pwm1 == 100 now gradually (in a
few seconds, it is not cut down to 35 suddenly) lowers it down to 35.
Switching to automatic mode while in man
On 12/17/2012 03:58 PM, Daniel Vetter wrote:
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. Bu
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas
On 12/17/2012 03:58 PM, Daniel Vetter wrote:
> All drivers which implement this need to have some sort of refcount to
> allow concurrent vmap usage. Hence implement this in the dma-buf core.
>
> To protect against concurrent calls we need a lock, which potentially
> causes new funny locking inversi
On 2012.12.19 at 09:47 -0500, Alex Deucher wrote:
> On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel
> wrote:
> > Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst:
> >> Fix regression introduced by 85b144f860176
> >
> > Thanks for the catch and patch.
> >
> > Also please add the comm
nks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/44239f1a/attachment.pgp>
op.org/archives/dri-devel/attachments/20121219/c3f691a0/attachment-0001.jpg>
Op 19-12-12 15:20, Markus Trippelsdorf schreef:
> On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote:
>> Op 18-12-12 17:12, Markus Trippelsdorf schreef:
>>> With your supposed debugging BUG_ONs added I still get:
>>>
>>> Dec 18 17:01:15 x4 kernel: [ cut here ]
>>> Dec 18
On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote:
> Op 18-12-12 17:12, Markus Trippelsdorf schreef:
> > With your supposed debugging BUG_ONs added I still get:
> >
> > Dec 18 17:01:15 x4 kernel: [ cut here ]
> > Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.
Fix regression introduced by 85b144f860176
Signed-off-by: Maarten Lankhorst
Reported-by: Markus Trippelsdorf
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0bf66f9..9f85418 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -579,
On 12/18/2012 04:33 PM, Paul Menzel wrote:
> I am sorry for the trouble caused by this. As a work around, you could
> also specify the QUIRKS on the Linux command line.
Those patches never made it in. I gave up when I was asked to rewrite
everything without using unions.
--
Hi Tomi,
On Wednesday 19 December 2012 16:53:10 Tomi Valkeinen wrote:
> On 2012-12-19 15:21, Laurent Pinchart wrote:
> > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> I have been testing Common Display Framework on OMAP, and making changes
> >> that I've discussed i
Op 18-12-12 17:12, Markus Trippelsdorf schreef:
> On 2012.12.18 at 16:24 +0100, Maarten Lankhorst wrote:
>> Op 18-12-12 14:38, Markus Trippelsdorf schreef:
>>> On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote:
On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote:
> On 2012.12.17
Add support for OMAP5 processor. The main differences are that the OMAP5
has 2 containers, one for 1D and one for 2D. Each container is 128MiB in
size.
Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_dmm_priv.h |5 +
drivers/staging/omapdrm/omap_dmm_ti
Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT. We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.
On resume, the DMM resume ha
First patch adds PM capabilities for omapdrm. Second patch adds
OMAP5 support to DMM driver component.
Series was build tested and based on linux-next.
v2: Updated commit msg for PM patch
Andy Gross (2):
drm/omap: Add PM capabilities
drm/omap: Add OMAP5 support
drivers/staging/omapdrm/oma
From: Dave Airlie
This adds the support for drivers that use the gem mmap call, they need
to specify DRIVER_GEM_MMAP in their feature set, so they get this behaviour.
This saves me adding 10 open/close handlers for now, if someone would like
to do that instead of midlayer, then I'd be happy to w
From: Dave Airlie
So instead of creating a whole set of per-file address spaces, and having
some sort of melt down in my understanding of the inode/address_space code,
I realised we could just keep a lot of filps that the object has been attached
to, or has had a handle created on.
At the moment
From: Dave Airlie
This is just a cleanup, can probably do better, but at least it makes
the calls to the unmap_mapping_range consistent.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_vma_offset_man.c | 11 +++
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/ttm/
The 2+3 patches are actually the code, the first was just a cleanup.
Anyways the second patch describes it best, but I've taken the approach
that we just need to keep track of what filp this object has had a handle
created on, and block mmaps on it. We could also probably block a bit
more explicit
Hi Tomi,
On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
> Hi,
>
> I have been testing Common Display Framework on OMAP, and making changes
> that I've discussed in the posts I've sent in reply to the CDF series from
> Laurent. While my CDF code is rather hacky and not at all ready, I w
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/07e1aaec/attachment.html>
Hi Linus,
just a single urgent regression fix, seeing a few wierd behaviours I'd
like not to persist.
Dave.
The following changes since commit 55bde6b1442fed8af67b92d21acce67db454c9f9:
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-12-1
The intention is to program exactly WIN_A, not WIN_A and possibly
others.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/dc.c | 3 +--
1 Datei geändert, 1 Zeile hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b256574..3475bd9
There is no gem.c anymore, those functions are implemented by the
drm_cma_helpers now.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/drm.h | 18 --
1 Datei geändert, 18 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index eae1f56
The 720p and 1080p entries are completely redundant, as we are matching
the table entries against <=pclk.
Also generalize the comment, as we are using those table entries even
when driving other modes than the standard TV ones.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/hdmi.c | 19 +++
Window properties are programmed through a shared aperture and have to
happen atomically. Also we do the read-update-write dance on some of the
shared regs.
To make sure that different functions don't stumble over each other
protect the register access with a mutex.
Signed-off-by: Lucas Stach
---
No real problem for now, as nothing is using this, but leaving it
unitialized is asking for trouble later on.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/host1x.c | 2 ++
1 Datei geändert, 2 Zeilen hinzugefügt(+)
diff --git a/drivers/gpu/drm/tegra/host1x.c b/drivers/gpu/drm/tegra/host1
Fixes wrong picture offset observed when using HDMI output with a
Technisat HD TV.
Signed-off-by: Lucas Stach
Acked-by: Mark Zhang
Tested-by: Mark Zhang
---
Captions are a bit confusing here. As the porch is always relative to
the sync pulse, the left picture margin is actually the back_porch.
Some small fixes and cleanups for the tegradrm driver.
This is potentially 3.8-fixes material.
Lucas Stach (6):
drm: tegra: fix front_porch <-> back_porch mixup
drm: tegra: don't leave clients host1x member uninitialized
drm: tegra: protect DC register access with mutex
drm: tegra: remove
On 12/18/2012 04:33 PM, Paul Menzel wrote:
> I am sorry for the trouble caused by this. As a work around, you could
> also specify the QUIRKS on the Linux command line.
Those patches never made it in. I gave up when I was asked to rewrite
everything without using unions.
--
On Wed, Dec 19, 2012 at 12:26 PM, wrote:
> From: Jerome Glisse
>
> To make it easier to debug some lockup from userspace add support
> to MEM_WRITE packet.
>
> Signed-off-by: Jerome Glisse
Looks good to me. Added to my fixes queue.
Alex
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 29 ++
Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT. We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.
On resume, the DMM resume ha
Add support for OMAP5 processor. The main differences are that the OMAP5
has 2 containers, one for 1D and one for 2D. Each container is 128MiB in
size.
Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_dmm_priv.h |5 +
drivers/staging/omapdrm/omap_dmm_ti
First patch adds PM capabilities for omapdrm. Second patch adds
OMAP5 support to DMM driver component.
Series was build tested and based on linux-next.
v2: Updated commit msg for PM patch
Andy Gross (2):
drm/omap: Add PM capabilities
drm/omap: Add OMAP5 support
drivers/staging/omapdrm/oma
https://bugs.freedesktop.org/show_bug.cgi?id=44327
--- Comment #2 from Pavel Ondračka ---
(In reply to comment #1)
> Is this still an issue?
This is still an issue with latest mesa git.
--
You are receiving this mail because:
You are the assignee for the bug.
__
From: Jerome Glisse
To make it easier to debug some lockup from userspace add support
to MEM_WRITE packet.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen_cs.c | 29 +
drivers/gpu/drm/radeon/r600_cs.c | 29 +
driver
On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae wrote:
>
>
> 2012/12/18 Daniel Vetter
>>
>> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
>> >> The other thing I'd like you guys to do is kill the idea of fbdev and
>> >> v4l drivers that are "shared" with the drm codebase, really just
>> >> impleme
On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
>>>
>>> Many developers showed interest in the first RFC, and I've had the
>>> opportunity
>>> to discuss it with most of them. I would like to thank (in no particular
>>> order) Tomi Valkei
On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae wrote:
>
>
> 2012/12/18 Daniel Vetter
>>
>> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
>> >> The other thing I'd like you guys to do is kill the idea of fbdev and
>> >> v4l drivers that are "shared" with the drm codebase, really just
>> >> impleme
> Here you go :)
>
> I managed to reproduce the issue. Please test this patch!
Okay switching to automatic mode when pwm1 == 100 now gradually (in a
few seconds, it is not cut down to 35 suddenly) lowers it down to 35.
Switching to automatic mode while in manual mode doesn't make the pwm
increase
On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
>>>
>>> Many developers showed interest in the first RFC, and I've had the
>>> opportunity
>>> to discuss it with most of them. I would like to thank (in no particular
>>> order) Tomi Valkei
From: Dave Airlie
This uses the drm vm accessor to access the address space offset
rather than storing it separately.
When I boot tested this, it threw up a problem in the virtual unmapping code
where we unmap a mapping range from 0 unnecessairly, so this patch also
checks we have a mapping befo
From: Dave Airlie
We currently don't need map_lists to store this information, with the new
encapsulation, just move the vma_offset object into the gem object.
In the future I'd guess we need per-filp vma offsets so this might make
it a bit cleaner to start from.
Signed-off-by: Dave Airlie
---
From: Dave Airlie
So we have to offset manager implementations for dealing with VMA offsets.
GEM had one using the hash table, TTM had one using an rbtree,
I'd rather we just had one to rule them all, since ttm is using the rbtree
variant to allow sub mappings, to keep ABI we need to use that on
So a passing comment on irc from Daniel made me look at this, and cleaning
up some surrounding things. This unifies the GEM/TTM vma offset managers
around a single one based on the TTM one.
There is also a patch to cleanup the GEM code after this, and one to clean
up some bits of TTM also.
I've t
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/6e441ef0/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=44327
--- Comment #1 from Fabio Pedretti ---
Is this still an issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/44f7a7e5/attachment.html>
On Wed, Dec 19, 2012 at 09:22:26AM +, Chris Wilson wrote:
> On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > So we have to offset manager implementations for dealing with VMA offsets.
> > GEM had one using the hash table, TTM had one using an rbtree,
> >
https://bugs.freedesktop.org/show_bug.cgi?id=41659
--- Comment #9 from Fabio Pedretti ---
Is this still an issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
https://bugs.freedesktop.org/show_bug.cgi?id=35396
--- Comment #1 from Fabio Pedretti ---
Is this still an issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
Dear Maarten,
Am Mittwoch, den 19.12.2012, 18:21 +0100 schrieb Maarten Lankhorst:
> Op 19-12-12 15:18, Maarten Lankhorst schreef:
> > Fix regression introduced by 85b144f860176
> >
> > Signed-off-by: Maarten Lankhorst
> > Reported-by: Markus Trippelsdorf
> I just wanted to have the fix out asa
On Tue, Dec 18, 2012 at 8:35 PM, Sean Paul wrote:
> On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma
> wrote:
>> Program the core and timing generator registers using the timing data
>> provided in drm_display_mode instead of using hardcoded configurations.
>> This allows us to support more standar
On Tue, Dec 18, 2012 at 10:25:05PM +0100, Daniel Vetter wrote:
> And do a quick pass to adjust them to the last few (years?) of changes
> ...
>
> This time actually compile-tested ;-)
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl |4 ++
> drivers/gpu/drm/drm_crtc.c
On Wed, Dec 19, 2012 at 12:26 PM, wrote:
> From: Jerome Glisse
>
> To make it easier to debug some lockup from userspace add support
> to MEM_WRITE packet.
>
> Signed-off-by: Jerome Glisse
Looks good to me. Added to my fixes queue.
Alex
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 29 ++
On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen
wrote:
> On 2012-12-19 17:26, Rob Clark wrote:
>>
>> And, there are also external HDMI encoders (for example connected over
>> i2c) that can also be shared between boards. So I think there will be
>> a number of cases where CDF is appropriate for H
From: Chris Wilson
Subject: Re: [proof-of-concept/rfc] per object file mmaps
To: Dave Airlie , dri-devel at lists.freedesktop.org
In-Reply-To: <1355892119-13926-1-git-send-email-airlied at gmail.com>
References: <1355892119-13926-1-git-send-email-airlied at gmail.com>
On Wed, 19 Dec 2012 14:41:56
On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel
wrote:
> Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst:
>> Fix regression introduced by 85b144f860176
>
> Thanks for the catch and patch.
>
> Also please add the commit summary to make the commit message self
> contained?
>
> The pr
On Wed, Dec 19, 2012 at 12:06 AM, Rahul Sharma wrote:
> On Tue, Dec 18, 2012 at 8:35 PM, Sean Paul wrote:
>> On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma
>> wrote:
>>> Program the core and timing generator registers using the timing data
>>> provided in drm_display_mode instead of using hardco
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula
wrote:
>
> Hi Laurent -
>
> On Tue, 18 Dec 2012, Laurent Pinchart
> wrote:
>> Hi Jani,
>>
>> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
>>> I can see the need for a framework for DSI panels and such (in fact Tomi
>>> and I have talked abou
Op 19-12-12 15:18, Maarten Lankhorst schreef:
> Fix regression introduced by 85b144f860176
>
> Signed-off-by: Maarten Lankhorst
> Reported-by: Markus Trippelsdorf
>
Hey Paul Menzel,
I just wanted to have the fix out asap, and had to leave right after.
Updated commit message below:
Fix regressi
On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> So we have to offset manager implementations for dealing with VMA offsets.
> GEM had one using the hash table, TTM had one using an rbtree,
>
> I'd rather we just had one to rule them all, since ttm is using the rbtr
From: Jerome Glisse
To make it easier to debug some lockup from userspace add support
to MEM_WRITE packet.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen_cs.c | 29 +
drivers/gpu/drm/radeon/r600_cs.c | 29 +
driver
Avoid clobbering adjacent blocks if they happen to expire earlier and
amalgamate together to form the requested hole.
In passing this fixes a regression from
commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
Author: Daniel Vetter
Date: Fri Feb 18 17:59:12 2011 +0100
drm: mm: track free areas
On Wed, 2012-12-19 at 08:11 +1300, Tony Prisk wrote:
> On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote:
> > I don't care either way, but being different from the documentation
> > is less bad than crashing which is what your patch does. Please
> > be more careful in the future.
> >
> > reg
On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote:
> I don't care either way, but being different from the documentation
> is less bad than crashing which is what your patch does. Please
> be more careful in the future.
>
> regards,
> dan carpenter
Critism accepted.
Given that the driver d
1 - 100 of 127 matches
Mail list logo
