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 2012-12-19 15:21, Laurent Pinchart wrote:
> 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. Whil
On 2012-12-19 16:57, Jani Nikula wrote:
> It just seems to me that, at least from a DRM/KMS perspective, adding
> another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> overengineering it. They are pretty well standardized, and I don't see
> there would be a need to write multiple disp
On 2012-12-19 17:26, Rob Clark wrote:
> 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 panel
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
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 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
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.
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_
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 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 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 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
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
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
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
> -Original Message-
> From: Eunchul Kim [mailto:chulspro@samsung.com]
> Sent: Thursday, December 20, 2012 6:32 PM
> To: dri-devel@lists.freedesktop.org; inki@samsung.com
> Cc: jy0.j...@samsung.com; yj44@samsung.com; jmock.s...@samsung.com;
> jaejoon@samsung.com; kyungmin.
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
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@samsung.com]
Sent: Thursday, December 20, 2012 6:32 PM
To: dri-devel@lists.freedesktop.org; inki@
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: sta...@vger.kernel.org
> Signed-off-by: Dave Airlie
Picked up for -fixes, thanks for the patch.
-Daniel
-
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #12 from smoki ---
OK on the main bug to mention... Good example is gliv - opengl image viewer
http://guichaz.free.fr/gliv/
Seems like airlied code tries to hide alpha blended transitions between
images,
and because of that ther
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #13 from smoki ---
So yeah, making gliv to work fast as before, but without coruptions in alpha
blended transitions, and this bug can be closed :).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #14 from smoki ---
Created attachment 71848
--> https://bugs.freedesktop.org/attachment.cgi?id=71848&action=edit
Two example images which show coruptions in alpha blended transitions with gliv
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=58568
Priority: medium
Bug ID: 58568
Assignee: dri-devel@lists.freedesktop.org
Summary: [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS
ROM
Severity: normal
Classificatio
> 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
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 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
https://bugs.freedesktop.org/show_bug.cgi?id=58568
--- Comment #1 from Alex Deucher ---
Make sure pci quirks are enabled in your kernel config. Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel ma
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 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 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 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). Either
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 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 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 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 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
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: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
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
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
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 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
>> >>
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.
___
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:
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
>
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 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.
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
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 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 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
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
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
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]
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 #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
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
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
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
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_
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 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 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
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
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
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
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
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,
t
> > display_entity_port instances.
> >
> > Video stream operations will be exposed by the display entity as function
> > pointers and will take a port reference as argument (this could take the
> > form of struct display_entity * and port index, or struct
> > display_entity_port *).
>
> I'd very much like to have only one parameter to pass, as there may be lots
> of ops for some busses. Having two parameters to refer to the source is just
> extra code that has no extra benefit when using video source ops. Then
> again, having separate port index parameter could be 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.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/3f5b05cd/attachment.pgp>
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 w
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
> 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
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 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
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
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
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
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://bugzilla.kernel.org/show_bug.cgi?id=43751
Alexey Neyman changed:
What|Removed |Added
CC||stilor at att.net
--- Comment #5 from
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
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
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
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 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
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
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.
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_
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 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 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 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
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
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
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
> -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 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
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
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
1 - 100 of 137 matches
Mail list logo
