On 20.12.2012 22:30, Thierry Reding wrote:
> The problem with your proposed solution is that, even any of Stephen's
> valid objections aside, it won't work. Once the tegra-drm module is
> unloaded, the driver's data will be left in the current state and the
> link to the dummy device will be lost.
ing it host1x_get_drm_device()
may make it more obvious about what it returns.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/585c9686/attachment.pgp>
On 21.12.2012 00:28, Stephen Warren wrote:
> On 12/20/2012 02:34 PM, Terje Bergström wrote:
>> On 20.12.2012 22:30, Thierry Reding wrote:
>>> The problem with your proposed solution is that, even any of Stephen's
>>> valid objections aside, it won't work. Once the tegra-drm module is
>>> unloaded,
From: Alex Deucher
It's used in a recent mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
and there may be some other cases in the future where it's required.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/rad
rious host1x components are
interlinked I think having a single function that gets the DRM dummy
device for DRM-related clients isn't that bad.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/e8b4be4e/attachment.pgp>
This patch cleanup needless parenthesis. we got the comment from GSC.
but we missed fimc side. so, we cleanup the code.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos
Changelog v2:
This patch added EXYNOS_DRM_FLIP_BOTH enum value for warnning.
Changelog v1:
This patch fixed vflip, hflip at the same time. If we want to change 180 degree
about buffer,
then we can use h,vflip or 180 degree. we supports 180 degree using h,vflip.
but we make error handling in this
From: Jinyoung Jeon
This patch fixed unnormal interrupt at m2m operation sometimes.
m2m operation called s/w reset during every frame.
but m2m occured interrupt after s/w reset sometimes.
so, we cleared dma operation and capture operation.
Signed-off-by: Jinyoung Jeon
Signed-off-by: Eunchul Kim
From: JoongMock Shin
This patch removed color bar pattern register. we not use color bar
any more. and don't support color bar at writeback operation.
Signed-off-by: JoongMock Shin
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |9 +++--
1 files changed, 3 ins
This patch removed property error handling. property couldn't be NULL.
so, I removed it.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 12
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12
drivers/gpu/drm/exynos/exynos_drm_ipp.c |5
This patch cleanup comment of abbreviation.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dr
This patch fixed warnning in GSC build.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 3e5b456..410175a 10064
This patch changed current command name from cmd to c_node.
because we already use cmd for command control ioctl in another structure.
so, this name make some confusion.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c|8
drivers/gpu/drm/exynos/exynos_drm_
Hi All.
This patch set fixed some issue and cleanup code.
please check my commit and let me know about your comment.
Changelog v2:
- This patch set fixes the following:
* fixed vflip, hflip case at the same time: we use vflip, hflip set at the
same time for 180 degree supporting.
so, we add
On 20.12.2012 19:55, Stephen Warren wrote:
> So it's fine for the tegradrm driver to manipulate the tegradrm
> (virtual) device's drvdata pointer.
>
> It's not fine for tegradrm to manipulate the drvdata pointer of other
> devices; the host1x children. The drvdata pointer for other devices is
> re
t --
A non-text attachment was scrubbed...
Name: error_state.gz
Type: application/x-gzip
Size: 198436 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/324d074d/attachment-0001.bin>
On 20.12.2012 19:14, Stephen Warren wrote:
> I'm not sure that sounds right. drvdata is something that a driver
> should manage itself.
>
> What's wrong with just having each device ask the host1x (its parent)
> for a pointer to the (dummy) tegradrm device. That seems extremely
> simple, and doesn
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121220/32497360/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/e2ae666f/attachment.html>
Le 20/12/2012 14:07, Ozan ?a?layan a ?crit :
>> So, we had some discussions within the nouveau community about
>> this and we decided that 0 would mean, no updates on the current status.
>>
>> Anything against it?
> So if I switch automatic mode on and then disable it then do some heavy GPU
> proce
Thank's for comment.
Oops, sorry that is my fault.
I will resend it.
BR
Eunchul Kim
On 12/20/2012 06:48 PM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Eunchul Kim [mailto:chulspro.kim at samsung.com]
>> Sent: Thursday, December 20, 2012 6:32 PM
>> To: dri-devel at lists.freedeskt
> -Original Message-
> From: Eunchul Kim [mailto:chulspro.kim at samsung.com]
> Sent: Thursday, December 20, 2012 6:32 PM
> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> Cc: jy0.jeon at samsung.com; yj44.cho at samsung.com; jmock.shin at
> samsung.com;
> jaejoon.seo a
On Fri, Dec 21, 2012 at 11:49 AM, Dave Airlie wrote:
> As we talked on irc, I decided to write a test case and it actually
> seems to trigger the race.
>
> Really its insane userspace behaviour and I'm not really sure we
> should care to fix, I can't see it causing an oops, more userspace
> does s
From: Alex Deucher
Hi Dave,
Just a few fixes from the last week or so.
Alex
The following changes since commit 0953e76e91f4b6206cef50bd680696dc6bf1ef99:
drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
(2012-12-20 07:46:20 +1000)
are available in the git repository a
From: Alex Deucher
It's used in a recent mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
and there may be some other cases in the future where it's required.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon
This patch cleanup needless parenthesis. we got the comment from GSC.
but we missed fimc side. so, we cleanup the code.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos
From: Jinyoung Jeon
This patch fixed unnormal interrupt at m2m operation sometimes.
m2m operation called s/w reset during every frame.
but m2m occured interrupt after s/w reset sometimes.
so, we cleared dma operation and capture operation.
Signed-off-by: Jinyoung Jeon
Signed-off-by: Eunchul Kim
From: JoongMock Shin
This patch removed color bar pattern register. we not use color bar
any more. and don't support color bar at writeback operation.
Signed-off-by: JoongMock Shin
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |9 +++--
1 files changed, 3 ins
This patch cleanup comment of abbreviation.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dr
This patch fixed warnning in GSC build.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index ba5fefd..4546833 10064
This patch fixed vflip, hflip at the same time. If we want to change 180 degree
about buffer,
then we can use h,vflip or 180 degree. we supports 180 degree using h,vflip.
but we make error handling in this case. so, fixed it.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc
This patch removed property error handling. property couldn't be NULL.
so, I removed it.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 12
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12
drivers/gpu/drm/exynos/exynos_drm_ipp.c |5
This patch changed current command name from cmd to c_node.
because we already use cmd for command control ioctl in another structure.
so, this name make some confusion.
Signed-off-by: Eunchul Kim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c|8
drivers/gpu/drm/exynos/exynos_drm_
Hi All.
This patch set fixed some issue and cleanup code.
please check my commit and let me know about your comment.
- This patch set fixes the following:
* fixed vflip, hflip case at the same time: we use vflip, hflip set at the
same time for 180 degree supporting.
so, we added this case.
;a=commitdiff;h=6253e4c75d96006c06b9ac8f417eba873de2497b
--
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/20121220/b30cd
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/4e918cc8/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=58372
--- Comment #8 from Alex Deucher ---
(In reply to comment #7)
> Created attachment 71883 [details]
> dmesg with drm-fixes-3.8
>
> The dmesg message changed after merging in drm-fixes-3.8:
>
> [drm:evergreen_vm_reg_valid] *ERROR* Invalid registe
As we talked on irc, I decided to write a test case and it actually
seems to trigger the race.
Really its insane userspace behaviour and I'm not really sure we
should care to fix, I can't see it causing an oops, more userspace
does something insane, it gets a bad result, but I'll contemplate it a
https://bugs.freedesktop.org/show_bug.cgi?id=58372
--- Comment #7 from Serkan Hosca ---
Created attachment 71883
--> https://bugs.freedesktop.org/attachment.cgi?id=71883&action=edit
dmesg with drm-fixes-3.8
The dmesg message changed after merging in drm-fixes-3.8:
[drm:evergreen_vm_reg_valid]
Hi Dave
Some fixes for 3.8:
- Watermark fixups from Chris Wilson (4 pieces).
- 2 snb workarounds, seem to be recently added to our internal DB.
- workaround for the infamous i830/i845 hang, seems now finally solid!
Based on Chris' fix for SNA, now also for UXA/mesa&old SNA.
- Some more fixlets f
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
On Thu, Dec 20, 2012 at 10:50 AM, Rob Clark wrote:
> On Thu, Dec 20, 2012 at 7:14 AM, 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 cal
From: Alex Deucher
Hi Dave,
Just a few fixes from the last week or so.
Alex
The following changes since commit 0953e76e91f4b6206cef50bd680696dc6bf1ef99:
drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
(2012-12-20 07:46:20 +1000)
are available in the git repository a
On Thu, Dec 20, 2012 at 01:39:07PM +1000, Dave Airlie wrote:
> 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 c
On 12/20/2012 02:50 PM, Thierry Reding wrote:
> On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergstr?m wrote:
>> On 20.12.2012 22:30, Thierry Reding wrote:
>>> The problem with your proposed solution is that, even any of
>>> Stephen's valid objections aside, it won't work. Once the
>>> tegra-drm
On 12/20/2012 02:34 PM, Terje Bergstr?m wrote:
> On 20.12.2012 22:30, Thierry Reding wrote:
>> The problem with your proposed solution is that, even any of Stephen's
>> valid objections aside, it won't work. Once the tegra-drm module is
>> unloaded, the driver's data will be left in the current sta
On Thu, Dec 20, 2012 at 01:39:07PM +1000, Dave Airlie wrote:
> 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 c
> So, we had some discussions within the nouveau community about
> this and we decided that 0 would mean, no updates on the current status.
>
> Anything against it?
So if I switch automatic mode on and then disable it then do some heavy GPU
processing, the fan power will stay at what it was in the
On 2012.12.20 at 14:45 +0100, Markus Trippelsdorf wrote:
> On 2012.12.20 at 08:30 -0500, Alex Deucher wrote:
> > On Wed, Dec 19, 2012 at 9:33 AM, Markus Trippelsdorf
> > wrote:
> > > On 2012.12.19 at 15:18 +0100, Maarten Lankhorst wrote:
> > >> Fix regression introduced by 85b144f860176
> > >
> >
On 2012.12.20 at 08:30 -0500, Alex Deucher wrote:
> On Wed, Dec 19, 2012 at 9:33 AM, Markus Trippelsdorf
> wrote:
> > On 2012.12.19 at 15:18 +0100, Maarten Lankhorst wrote:
> >> Fix regression introduced by 85b144f860176
> >
> > Thanks. This fixes the kernel BUG, but now I get this errors in my
>
On 12/20/2012 02:50 PM, Thierry Reding wrote:
> On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergström wrote:
>> On 20.12.2012 22:30, Thierry Reding wrote:
>>> The problem with your proposed solution is that, even any of
>>> Stephen's valid objections aside, it won't work. Once the
>>> tegra-drm
On 12/20/2012 02:34 PM, Terje Bergström wrote:
> On 20.12.2012 22:30, Thierry Reding wrote:
>> The problem with your proposed solution is that, even any of Stephen's
>> valid objections aside, it won't work. Once the tegra-drm module is
>> unloaded, the driver's data will be left in the current sta
On Wed, Dec 19, 2012 at 8:14 PM, Sean Paul wrote:
> 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
With per-crtc locks modeset operations can run in parallel, and the
cursor code uses the device-global evo master channel for hw frobbing.
But the pageflip code can also sync with the master under some
circumstances. Hence just wrap things up in a mutex to ensure that
pushbuf access doesn't intermi
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. But this shouldn't be a problem
for exporters wit
On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergström wrote:
> On 20.12.2012 22:30, Thierry Reding wrote:
> > The problem with your proposed solution is that, even any of Stephen's
> > valid objections aside, it won't work. Once the tegra-drm module is
> > unloaded, the driver's data will be le
On Thu, Dec 20, 2012 at 10:50 AM, Rob Clark wrote:
> On Thu, Dec 20, 2012 at 7:14 AM, 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
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 Tue, Dec 18, 2012 at 12:28 PM, Paul Bolle wrote:
> On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote:
>> On Tue, Dec 18, 2012 at 5:36 AM, Christian K?nig
>> wrote:
>> > On 17.12.2012 22:31, Paul Bolle wrote:
>> >> 1) Sent as an RFC because I do not understand why this laptop (almost
>> >>
On 20.12.2012 22:30, Thierry Reding wrote:
> The problem with your proposed solution is that, even any of Stephen's
> valid objections aside, it won't work. Once the tegra-drm module is
> unloaded, the driver's data will be left in the current state and the
> link to the dummy device will be lost.
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/8f4b6b12/attachment.html>
ion/octet-stream
Size: 1065 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/1f7d11fd/attachment-0002.obj>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-dma-buf-fix-warning-in-seq_printf.patch
Typ
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
head: e03a89ed11fc77b78135ae473725fbfa876c1d95
commit: b3d6da16e97f181bca681e486adfcc6632bae2de Merge remote-tracking branch
'origin/drm-intel-fixes' into drm-intel-nightly
date: 16 minutes ago
config: make ARCH=i386
On Thu, Dec 20, 2012 at 08:01:43PM +0200, Terje Bergström wrote:
> On 20.12.2012 19:55, Stephen Warren wrote:
> > So it's fine for the tegradrm driver to manipulate the tegradrm
> > (virtual) device's drvdata pointer.
> >
> > It's not fine for tegradrm to manipulate the drvdata pointer of other
>
Hi Linus,
A fairly small dma-buf pull request for 3.8 - only 2 patches. Could
you please pull?
Thanks!
~Sumit.
The following changes since commit f01af9f85855e38fbd601e033a8eac204cc4cc1c:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc
(2012-12-19 20:31:02 -0800)
are availabl
b83b61926d5304d86349e5530027 mm: dmapool: use provided gfp flags
for all dma_alloc_coherent() calls
--
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
https://bugs.freedesktop.org/show_bug.cgi?id=49418
--- Comment #8 from Bastien Dejean ---
Sorry, I meant rEFInd.
--
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=49418
--- Comment #7 from Bastien Dejean ---
I don't use grub (I boot through rEFIt thanks to EFISTUB).
I'll try 3.8 ASAP.
Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
___
is 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/20121220/06901dca/attachment.html>
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
On Thu, Dec 20, 2012 at 10:51:09AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> As pointed out by Seung-Woo Kim this should have been
> passing flags like nouveau/radeon have.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Dave Airlie
Picked up for -fixes, thanks for the patch.
-Danie
On 16.12.2012 14:16, Thierry Reding wrote:
> Okay, so we're back on the topic of using globals. I need to assert
> again that this is not an option. If we were to use globals, then we
> could just as well leave out the dummy device and just do all of that in
> the tegra-drm driver's initialization
On Wed, Dec 19, 2012 at 7:19 PM, Ville Syrj?l?
wrote:
> 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
>> ---
>> Documen
frame buffer device 200x75
<6>1 2012-12-18T07:39:00.164491+01:00 osgiliath kernel - - [ 1207.815356] fb0:
radeondrmfb frame buffer device
<6>1 2012-12-18T07:39:00.164493+01:00 osgiliath kernel - - [ 1207.815356] drm:
registered panic notifier
<6>1 2012-12-18T07:39:00.164495+01:00 os
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/48936a49/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/d1e470a8/attachment.html>
On 12/20/2012 10:46 AM, Terje Bergstr?m wrote:
> On 20.12.2012 19:14, Stephen Warren wrote:
>> I'm not sure that sounds right. drvdata is something that a driver
>> should manage itself.
>>
>> What's wrong with just having each device ask the host1x (its parent)
>> for a pointer to the (dummy) tegr
From: Dave Airlie
As pointed out by Seung-Woo Kim this should have been
passing flags like nouveau/radeon have.
Cc: stable at 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/dr
On Thu, Dec 20, 2012 at 7:14 AM, 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 lock
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
> 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
On Tue, Dec 18, 2012 at 12:28 PM, Paul Bolle wrote:
> On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote:
>> On Tue, Dec 18, 2012 at 5:36 AM, Christian König
>> wrote:
>> > On 17.12.2012 22:31, Paul Bolle wrote:
>> >> 1) Sent as an RFC because I do not understand why this laptop (almost
>> >>
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
Le 20/12/2012 14:07, Ozan Çağlayan a écrit :
So, we had some discussions within the nouveau community about
this and we decided that 0 would mean, no updates on the current status.
Anything against it?
So if I switch automatic mode on and then disable it then do some heavy GPU
processing, the f
On Thu, Dec 20, 2012 at 3:51 AM, Rahul Sharma wrote:
> On Wed, Dec 19, 2012 at 8:14 PM, Sean Paul wrote:
>> 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 >>> samsung.com> wrote:
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
https://bugs.freedesktop.org/show_bug.cgi?id=49418
--- Comment #6 from Alex Deucher ---
Are you using gfxpayload=keep in your grub config? If so does it help if you
remove it? Can you also try a 3.8 kernel? Specifically this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a
On 12/20/2012 02:17 AM, Terje Bergstr?m wrote:
> On 16.12.2012 14:16, Thierry Reding wrote:
>> Okay, so we're back on the topic of using globals. I need to assert
>> again that this is not an option. If we were to use globals, then we
>> could just as well leave out the dummy device and just do all
https://bugs.freedesktop.org/show_bug.cgi?id=49418
--- Comment #5 from Bastien Dejean ---
I'm still willing to help.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
On 20.12.2012 19:55, Stephen Warren wrote:
> So it's fine for the tegradrm driver to manipulate the tegradrm
> (virtual) device's drvdata pointer.
>
> It's not fine for tegradrm to manipulate the drvdata pointer of other
> devices; the host1x children. The drvdata pointer for other devices is
> re
On 12/20/2012 10:46 AM, Terje Bergström wrote:
> On 20.12.2012 19:14, Stephen Warren wrote:
>> I'm not sure that sounds right. drvdata is something that a driver
>> should manage itself.
>>
>> What's wrong with just having each device ask the host1x (its parent)
>> for a pointer to the (dummy) tegr
On 20.12.2012 19:14, Stephen Warren wrote:
> I'm not sure that sounds right. drvdata is something that a driver
> should manage itself.
>
> What's wrong with just having each device ask the host1x (its parent)
> for a pointer to the (dummy) tegradrm device. That seems extremely
> simple, and doesn
Am Donnerstag, den 20.12.2012, 10:36 +0800 schrieb Mark Zhang:
> 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_
On 12/20/2012 02:17 AM, Terje Bergström wrote:
> On 16.12.2012 14:16, Thierry Reding wrote:
>> Okay, so we're back on the topic of using globals. I need to assert
>> again that this is not an option. If we were to use globals, then we
>> could just as well leave out the dummy device and just do all
On Thu, Dec 20, 2012 at 7:14 AM, 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 locki
On Wed, Dec 19, 2012 at 9:33 AM, Markus Trippelsdorf
wrote:
> On 2012.12.19 at 15:18 +0100, Maarten Lankhorst wrote:
>> Fix regression introduced by 85b144f860176
>
> Thanks. This fixes the kernel BUG, but now I get this errors in my
> Xorg.log:
>
> [23.092] [mi] Increasing EQ size to 512 to p
On Thu, Dec 20, 2012 at 1:39 AM, Seung-Woo Kim
wrote:
> This patch fixes flags passed to dma buf exporting.
>
> Signed-off-by: Seung-Woo Kim
> Cc: Rob Clark
Probably should go to GregKH, unless he doesn't mind this going in via
drm tree (it won't conflict with any other recent patches). Eithe
On 12/20/2012 05:14 AM, 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
On 12/20/2012 05:14 AM, 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
1 - 100 of 137 matches
Mail list logo
