[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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.

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

ns. 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>

[PATCH] drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

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

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

gle 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>

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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 >

Hangcheck timer elapsed..

r_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>

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121220/32497360/attachment.html>

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/e2ae666f/attachment.html>

Fan control in nouveau driver with geforce 9600gt

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 >

[PATCH 3/8] drm/exynos: fixed vflip, hflip case at the same time.

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

[PATCH 3/8] drm/exynos: fixed vflip, hflip case at the same time.

> -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

[pull] radeon drm-fixes-3.8

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

[PATCH 8/8] drm/exynos: cleanup needless parenthesis.

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

[PATCH 7/8] drm/exynos: fixed unnormal interrupt in m2m operation.

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

[PATCH 6/8] drm/exynos: removed color bar pattern display.

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

[PATCH 5/8] drm/exynos: cleanup comment of abbreviation.

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

[PATCH 4/8] drm/exynos: fixed warnning in GSC build.

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

[PATCH 3/8] drm/exynos: fixed vflip, hflip case at the same time.

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 ---

[PATCH 2/8] drm/exynos: removed needless error handling about property.

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

[PATCH 1/8] drm/exynos: cleanup current command name.

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

[PATCH 0/8] drm/exynos: fixed and cleanup ipp subsystem drivers

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.

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

;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

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121220/4e918cc8/attachment.html>

[PATCH 2/2] drm/omap: fix flags in dma buf exporting

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

[PATCH 1/2] drm/exynos: fix flags in dma buf exporting

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

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

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

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2)

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

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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 >>>

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2)

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

Fan control in nouveau driver with geforce 9600gt

> 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

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

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 > > > > >

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

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 >

[PATCH 1/2] drm/exynos: hdmi: add support for extra permissable resolutions

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

[PATCH] drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex

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

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

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

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2)

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

[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset

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 >> >>

[Bug 58568] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/8f4b6b12/attachment.html>

[PATCH] dma-buf: Add debugfs support

ctet-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 Type: applica

[GIT PULL]: dma-buf updates for 3.8

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

[Bug 58568] New: [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

86349e5530027 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/dri-devel/atta

[Bug 44499] r280 and xbmc - choppy menu and video playback

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>

[PATCH] dma-buf: Add debugfs support

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?:

[PATCH] drm/i915: fix flags in dma buf exporting

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.

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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

[PATCH 02/10] drm/doc: integrate drm_crtc.c kerneldoc

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 >> --- >>

System freezes with radeon DRM driver since kernel 3.6

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

[Bug 44499] r280 and xbmc - choppy menu and video playback

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121220/48936a49/attachment.html>

[Bug 44499] r280 and xbmc - choppy menu and video playback

are 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>

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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)

[PATCH] drm/i915: fix flags in dma buf exporting

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

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

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

[PATCH 5/6] drm: tegra: clean out old gem prototypes

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 > --- >

[PATCH] drm/prime: drop reference on imported dma-buf come from gem

> 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, _dmabuf_ops, obj->base.size, 0600); Oops, nice catch, radeon and

[PATCH 3/6] drm: tegra: protect DC register access with mutex

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

[PATCH 1/2] drm/exynos: hdmi: add support for extra permissable resolutions

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:

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf

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

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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

[PATCH 3/6] drm: tegra: protect DC register access with mutex

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

[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

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

[PATCH 2/2] drm/omap: fix flags in dma buf exporting

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).

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

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

[Bug 43751] [TTM] Out of kernel memory

https://bugzilla.kernel.org/show_bug.cgi?id=43751 Alexey Neyman changed: What|Removed |Added CC||stilor at att.net --- Comment #5

Fan control in nouveau driver with geforce 9600gt

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

[RFC 0/6] Common Display Framework-T

rt 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>

Re: [PATCH 1/2] drm/exynos: hdmi: add support for extra permissable resolutions

On Wed, Dec 19, 2012 at 12:06 AM, Rahul Sharma r.sh.o...@gmail.com wrote: On Tue, Dec 18, 2012 at 8:35 PM, Sean Paul seanp...@google.com wrote: On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma rahul.sha...@samsung.com wrote: Program the core and timing generator registers using the timing data

Re: [RFC 0/6] Common Display Framework-T

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. While my CDF

Re: [RFC v2 0/5] Common Display Framework

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 display

Re: [RFC v2 0/5] Common Display Framework

On 2012-12-19 17:26, Rob Clark wrote: On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula jani.nik...@linux.intel.com wrote: Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jani, On Monday 17 December 2012 18:53:37 Jani Nikula wrote: I can see

[GIT PULL]: dma-buf updates for 3.8

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

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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

[PATCH 1/8] drm/exynos: cleanup current command name.

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 chulspro@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimc.c|8

[PATCH 2/8] drm/exynos: removed needless error handling about property.

This patch removed property error handling. property couldn't be NULL. so, I removed it. Signed-off-by: Eunchul Kim chulspro@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 12 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12

[PATCH 3/8] drm/exynos: fixed vflip, hflip case at the same time.

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 chulspro@samsung.com ---

[PATCH 4/8] drm/exynos: fixed warnning in GSC build.

This patch fixed warnning in GSC build. Signed-off-by: Eunchul Kim chulspro@samsung.com --- 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

[PATCH 5/8] drm/exynos: cleanup comment of abbreviation.

This patch cleanup comment of abbreviation. Signed-off-by: Eunchul Kim chulspro@samsung.com --- 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

[PATCH 6/8] drm/exynos: removed color bar pattern display.

From: JoongMock Shin jmock.s...@samsung.com 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 jmock.s...@samsung.com Signed-off-by: Eunchul Kim chulspro@samsung.com ---

[PATCH 7/8] drm/exynos: fixed unnormal interrupt in m2m operation.

From: Jinyoung Jeon jy0.j...@samsung.com 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

[PATCH 8/8] drm/exynos: cleanup needless parenthesis.

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 chulspro@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

RE: [PATCH 3/8] drm/exynos: fixed vflip, hflip case at the same time.

-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;

Re: [PATCH 02/10] drm/doc: integrate drm_crtc.c kerneldoc

On Wed, Dec 19, 2012 at 7:19 PM, Ville Syrjälä ville.syrj...@linux.intel.com 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

Re: [PATCH 3/8] drm/exynos: fixed vflip, hflip case at the same time.

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;

Re: [PATCH] drm/i915: fix flags in dma buf exporting

On Thu, Dec 20, 2012 at 10:51:09AM +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com 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 airl...@redhat.com Picked up for -fixes,

[Bug 44499] r280 and xbmc - choppy menu and video playback

https://bugs.freedesktop.org/show_bug.cgi?id=44499 --- Comment #12 from smoki smoki00...@gmail.com --- 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

[Bug 44499] r280 and xbmc - choppy menu and video playback

https://bugs.freedesktop.org/show_bug.cgi?id=44499 --- Comment #13 from smoki smoki00...@gmail.com --- 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

[Bug 58568] New: [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

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

[PATCH] drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex

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

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

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

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On Wed, Dec 19, 2012 at 9:33 AM, Markus Trippelsdorf mar...@trippelsdorf.de 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

[Bug 58568] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

https://bugs.freedesktop.org/show_bug.cgi?id=58568 --- Comment #1 from Alex Deucher ag...@yahoo.com --- 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.

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

On 2012.12.20 at 08:30 -0500, Alex Deucher wrote: On Wed, Dec 19, 2012 at 9:33 AM, Markus Trippelsdorf mar...@trippelsdorf.de 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

Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

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 mar...@trippelsdorf.de wrote: On 2012.12.19 at 15:18 +0100, Maarten Lankhorst wrote: Fix regression introduced by 85b144f860176

Re: [PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2)

On Thu, Dec 20, 2012 at 01:39:07PM +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com 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

Re: [PATCH 2/2] drm/omap: fix flags in dma buf exporting

On Thu, Dec 20, 2012 at 1:39 AM, Seung-Woo Kim sw0312@samsung.com wrote: This patch fixes flags passed to dma buf exporting. Signed-off-by: Seung-Woo Kim sw0312@samsung.com Cc: Rob Clark rob.cl...@linaro.org Probably should go to GregKH, unless he doesn't mind this going in via drm

Re: [PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2)

On Thu, Dec 20, 2012 at 01:39:07PM +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com 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

Re: [PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

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.

Re: [PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

On Thu, Dec 20, 2012 at 7:14 AM, Daniel Vetter daniel.vet...@ffwll.ch 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

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

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 of

  1   2   >