[PATCH 6/6] drm: tegra: program only one window during modeset

The intention is to program exactly WIN_A, not WIN_A and possibly others. Signed-off-by: Lucas Stach --- drivers/gpu/drm/tegra/dc.c | 3 +-- 1 Datei ge?ndert, 1 Zeile hinzugef?gt(+), 2 Zeilen entfernt(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index

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

There is no gem.c anymore, those functions are implemented by the drm_cma_helpers now. Signed-off-by: Lucas Stach --- drivers/gpu/drm/tegra/drm.h | 18 -- 1 Datei ge?ndert, 18 Zeilen entfernt(-) diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h index

[PATCH 4/6] drm: tegra: remove redundant tegra2_tmds_config entry

The 720p and 1080p entries are completely redundant, as we are matching the table entries against <=pclk. Also generalize the comment, as we are using those table entries even when driving other modes than the standard TV ones. Signed-off-by: Lucas Stach --- drivers/gpu/drm/tegra/hdmi.c | 19

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

Window properties are programmed through a shared aperture and have to happen atomically. Also we do the read-update-write dance on some of the shared regs. To make sure that different functions don't stumble over each other protect the register access with a mutex. Signed-off-by: Lucas Stach

[PATCH 2/6] drm: tegra: don't leave clients host1x member uninitialized

No real problem for now, as nothing is using this, but leaving it unitialized is asking for trouble later on. Signed-off-by: Lucas Stach --- drivers/gpu/drm/tegra/host1x.c | 2 ++ 1 Datei ge?ndert, 2 Zeilen hinzugef?gt(+) diff --git a/drivers/gpu/drm/tegra/host1x.c

[PATCH 1/6] drm: tegra: fix front_porch <-> back_porch mixup

Fixes wrong picture offset observed when using HDMI output with a Technisat HD TV. Signed-off-by: Lucas Stach Acked-by: Mark Zhang Tested-by: Mark Zhang --- Captions are a bit confusing here. As the porch is always relative to the sync pulse, the left picture margin is actually the back_porch.

[PATCH 0/6] tegradrm fixes and cleanups

Some small fixes and cleanups for the tegradrm driver. This is potentially 3.8-fixes material. Lucas Stach (6): drm: tegra: fix front_porch <-> back_porch mixup drm: tegra: don't leave clients host1x member uninitialized drm: tegra: protect DC register access with mutex drm: tegra: remove

[git pull] drm urgent fix

Hi Linus, just a single urgent regression fix, seeing a few wierd behaviours I'd like not to persist. Dave. The following changes since commit 55bde6b1442fed8af67b92d21acce67db454c9f9: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Fan control in nouveau driver with geforce 9600gt

> Here you go :) > > I managed to reproduce the issue. Please test this patch! Okay switching to automatic mode when pwm1 == 100 now gradually (in a few seconds, it is not cut down to 35 suddenly) lowers it down to 35. Switching to automatic mode while in manual mode doesn't make the pwm increase

[Bug 44327] [r300g] Unigine Sanctuary: thin lines across textures are present when parallax mapping is enabled

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

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

On Tue, Dec 18, 2012 at 10:25:05PM +0100, Daniel Vetter wrote: > And do a quick pass to adjust them to the last few (years?) of changes > ... > > This time actually compile-tested ;-) > > Signed-off-by: Daniel Vetter > --- > Documentation/DocBook/drm.tmpl |4 ++ >

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

fence_lock); > > atomic_set(>reserved, 0); Acked-by: Paul Menzel Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/1a1d7db2/attachment.pgp>

[Bug 44327] [r300g] Unigine Sanctuary: thin lines across textures are present when parallax mapping is enabled

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/d0c955d8/attachment.html>

[Bug 41659] Weird unit rendering on SpringRTS

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/de5e10d9/attachment.html>

[Bug 35396] [mesa] black window when running glxgears after resume from suspend on ATI Radeon X800 SE

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/d84f23c1/attachment-0001.html>

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

Op 19-12-12 15:18, Maarten Lankhorst schreef: > Fix regression introduced by 85b144f860176 > > Signed-off-by: Maarten Lankhorst > Reported-by: Markus Trippelsdorf > Hey Paul Menzel, I just wanted to have the fix out asap, and had to leave right after. Updated commit message below: Fix

[RFC v2 0/5] Common Display Framework

t (if I understood right) gets video signal from somewhere outside the board, processes the signal with some IPs/chips, and then outputs the signal. So there's no framebuffer, and the image is not stored anywhere. I think the framework used in these cases is always v4l2. The IPs/chips in the above model

[RFC v2 0/5] Common Display Framework

n/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/4f2f77d6/attachment-0001.pgp>

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

On 2012.12.19 at 15:54 +0100, Markus Trippelsdorf wrote: > On 2012.12.19 at 09:47 -0500, Alex Deucher wrote: > > And the pictures get distorted on the test-webpage when I scroll up and > down, see: > http://trippelsdorf.de/bad.png The picture distortion issue is caused by: commit

[RFC v2 0/5] Common Display Framework

Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart wrote: > Hi Jani, > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >> I can see the need for a framework for DSI panels and such (in fact Tomi >> and I have talked about it like 2-3 years ago already!) but what is the >> story for

[RFC 0/6] Common Display Framework-T

s will > be > kept. > > Points that we forgot to discuss > > > - DISPLAY_ENTITY_STREAM_SINGLE_SHOT vs. update() operation Ah, yes, we missed that. I think it's possible to use SINGLE_SHOT, but then it requires some kind of system to inform about finished update. Or we could, of course, decide that informing about the update is done in dispc-specific code, like handling VSYNC. Hmm, except that won't probably work, as the panel (or any DSI device) may need to know if the DSI bus is currently used or not. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/03f53d95/attachment-0001.pgp>

[PATCH] drm: Only evict the blocks required to create the requested hole

Avoid clobbering adjacent blocks if they happen to expire earlier and amalgamate together to form the requested hole. In passing this fixes a regression from commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c Author: Daniel Vetter Date: Fri Feb 18 17:59:12 2011 +0100 drm: mm: track free

[PATCH] drm: Only evict the blocks required to create the requested hole

Avoid clobbering adjacent blocks if they happen to expire earlier and amalgamate together to form the requested hole. In passing this fixes a regression from commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c Author: Daniel Vetter Date: Fri Feb 18 17:59:12 2011 +0100 drm: mm: track free

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

On 12/17/2012 03:58 PM, Daniel Vetter wrote: > All drivers which implement this need to have some sort of refcount to > allow concurrent vmap usage. Hence implement this in the dma-buf core. > > To protect against concurrent calls we need a lock, which potentially > causes new funny locking

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

On 2012.12.19 at 09:47 -0500, Alex Deucher wrote: > On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel > wrote: > > Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: > >> Fix regression introduced by 85b144f860176 > > > > Thanks for the catch and patch. > > > > Also please add the

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

ext part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/44239f1a/attachment.pgp>

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

op.org/archives/dri-devel/attachments/20121219/c3f691a0/attachment-0001.jpg>

GPU lockup CP stall for more than 10000msec on latest vanilla git

Op 19-12-12 15:20, Markus Trippelsdorf schreef: > On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: >> Op 18-12-12 17:12, Markus Trippelsdorf schreef: >>> With your supposed debugging BUG_ONs added I still get: >>> >>> Dec 18 17:01:15 x4 kernel: [ cut here ] >>> Dec 18

GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: > Op 18-12-12 17:12, Markus Trippelsdorf schreef: > > With your supposed debugging BUG_ONs added I still get: > > > > Dec 18 17:01:15 x4 kernel: [ cut here ] > > Dec 18 17:01:15 x4 kernel: WARNING: at

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

Fix regression introduced by 85b144f860176 Signed-off-by: Maarten Lankhorst Reported-by: Markus Trippelsdorf --- diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 0bf66f9..9f85418 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@

[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

On 12/18/2012 04:33 PM, Paul Menzel wrote: > I am sorry for the trouble caused by this. As a work around, you could > also specify the QUIRKS on the Linux command line. Those patches never made it in. I gave up when I was asked to rewrite everything without using unions. --

GPU lockup CP stall for more than 10000msec on latest vanilla git

Op 18-12-12 17:12, Markus Trippelsdorf schreef: > On 2012.12.18 at 16:24 +0100, Maarten Lankhorst wrote: >> Op 18-12-12 14:38, Markus Trippelsdorf schreef: >>> On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote: On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote: > On 2012.12.17

[PATCH 2/2] drm/omap: Add OMAP5 support

Add support for OMAP5 processor. The main differences are that the OMAP5 has 2 containers, one for 1D and one for 2D. Each container is 128MiB in size. Signed-off-by: Andy Gross Signed-off-by: Rob Clark --- drivers/staging/omapdrm/omap_dmm_priv.h |5 +

[PATCH 1/2] drm/omap: Add PM capabilities

Added power management capabilities into the omapdrm and DMM drivers. During suspend, we don't need to do anything to maintain the state of the LUT. We have all the necessary information to recreate the mappings of the GEM object list maintained by the omapdrm driver. On resume, the DMM resume

[PATCH v2 0/2] drm/omap: Add PM and OMAP5 support

First patch adds PM capabilities for omapdrm. Second patch adds OMAP5 support to DMM driver component. Series was build tested and based on linux-next. v2: Updated commit msg for PM patch Andy Gross (2): drm/omap: Add PM capabilities drm/omap: Add OMAP5 support

[PATCH 3/3] drm/gem: start adding support for per-file object mmaps

From: Dave Airlie This adds the support for drivers that use the gem mmap call, they need to specify DRIVER_GEM_MMAP in their feature set, so they get this behaviour. This saves me adding 10 open/close handlers for now, if someone would like to do that instead of midlayer,

[PATCH 2/3] drm/ttm: add object per-file mmap validation

From: Dave Airlie So instead of creating a whole set of per-file address spaces, and having some sort of melt down in my understanding of the inode/address_space code, I realised we could just keep a lot of filps that the object has been attached to, or has had a handle

[PATCH 1/3] drm/vma/gem/ttm: consolide unmapping range

From: Dave Airlie This is just a cleanup, can probably do better, but at least it makes the calls to the unmap_mapping_range consistent. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_vma_offset_man.c | 11 +++ drivers/gpu/drm/i915/i915_gem.c | 7 ++-

[proof-of-concept/rfc] per object file mmaps

The 2+3 patches are actually the code, the first was just a cleanup. Anyways the second patch describes it best, but I've taken the approach that we just need to keep track of what filp this object has had a handle created on, and block mmaps on it. We could also probably block a bit more

[RFC 0/6] Common Display Framework-T

Hi Tomi, On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: > Hi, > > I have been testing Common Display Framework on OMAP, and making changes > that I've discussed in the posts I've sent in reply to the CDF series from > Laurent. While my CDF code is rather hacky and not at all ready, I

[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)

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

[PATCH] drm/radeon: add support for MEM_WRITE packet

On Wed, Dec 19, 2012 at 12:26 PM, wrote: > From: Jerome Glisse > > To make it easier to debug some lockup from userspace add support > to MEM_WRITE packet. > > Signed-off-by: Jerome Glisse Looks good to me. Added to my fixes queue. Alex > --- > drivers/gpu/drm/radeon/evergreen_cs.c | 29

[PATCH] drm/radeon: add support for MEM_WRITE packet

From: Jerome Glisse To make it easier to debug some lockup from userspace add support to MEM_WRITE packet. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/evergreen_cs.c | 29 + drivers/gpu/drm/radeon/r600_cs.c | 29

[RFC v2 0/5] Common Display Framework

On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae wrote: > > > 2012/12/18 Daniel Vetter >> >> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote: >> >> The other thing I'd like you guys to do is kill the idea of fbdev and >> >> v4l drivers that are "shared" with the drm codebase, really just >> >>

[RFC v2 0/5] Common Display Framework

On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote: >>> >>> Many developers showed interest in the first RFC, and I've had the >>> opportunity >>> to discuss it with most of them. I would like to thank (in no particular >>> order) Tomi

[PATCH 3/3] drm/ttm: drop addr_space_offset, use accessor

From: Dave Airlie This uses the drm vm accessor to access the address space offset rather than storing it separately. When I boot tested this, it threw up a problem in the virtual unmapping code where we unmap a mapping range from 0 unnecessairly, so this patch also checks

[PATCH 2/3] drm/gem: drop maplist from gem objects.

From: Dave Airlie We currently don't need map_lists to store this information, with the new encapsulation, just move the vma_offset object into the gem object. In the future I'd guess we need per-filp vma offsets so this might make it a bit cleaner to start from.

[PATCH 1/3] drm: create unified vma offset manager

From: Dave Airlie So we have to offset manager implementations for dealing with VMA offsets. GEM had one using the hash table, TTM had one using an rbtree, I'd rather we just had one to rule them all, since ttm is using the rbtree variant to allow sub mappings, to keep ABI

unifying the vma offset managers

So a passing comment on irc from Daniel made me look at this, and cleaning up some surrounding things. This unifies the GEM/TTM vma offset managers around a single one based on the TTM one. There is also a patch to cleanup the GEM code after this, and one to clean up some bits of TTM also. I've

[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/6e441ef0/attachment.html>

[Bug 58491] regression : r600g: work around ddx over alignment

gnee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/44f7a7e5/attachment.html>

[PATCH 1/3] drm: create unified vma offset manager

On Wed, Dec 19, 2012 at 09:22:26AM +, Chris Wilson wrote: > On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote: > > From: Dave Airlie > > > > So we have to offset manager implementations for dealing with VMA offsets. > > GEM had one using the hash table, TTM had one using an rbtree, > >

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

On Tue, Dec 18, 2012 at 8:35 PM, Sean Paul wrote: > On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma > wrote: >> Program the core and timing generator registers using the timing data >> provided in drm_display_mode instead of using hardcoded configurations. >> This allows us to support more

[RFC v2 0/5] Common Display Framework

On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for

[PATCH 3/3] drm/gem: start adding support for per-file object mmaps

From: Chris Wilson Subject: Re: [proof-of-concept/rfc] per object file mmaps To: Dave Airlie , dri-devel at lists.freedesktop.org In-Reply-To: <1355892119-13926-1-git-send-email-airlied at gmail.com> References: <1355892119-13926-1-git-send-email-airlied at gmail.com>

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

On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel wrote: > Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: >> Fix regression introduced by 85b144f860176 > > Thanks for the catch and patch. > > Also please add the commit summary to make the commit message self > contained? > > The

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

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

[RFC v2 0/5] Common Display Framework

On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote: > > Hi Laurent - > > On Tue, 18 Dec 2012, Laurent Pinchart > wrote: >> Hi Jani, >> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>> I can see the need for a framework for DSI panels and such (in fact Tomi >>> and I have talked

[PATCH 1/3] drm: create unified vma offset manager

On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie wrote: > From: Dave Airlie > > So we have to offset manager implementations for dealing with VMA offsets. > GEM had one using the hash table, TTM had one using an rbtree, > > I'd rather we just had one to rule them all, since ttm is using the

[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

On Wed, 2012-12-19 at 08:11 +1300, Tony Prisk wrote: > On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: > > I don't care either way, but being different from the documentation > > is less bad than crashing which is what your patch does. Please > > be more careful in the future. > > > >

[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: > I don't care either way, but being different from the documentation > is less bad than crashing which is what your patch does. Please > be more careful in the future. > > regards, > dan carpenter Critism accepted. Given that the driver

[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

On Tue, 2012-12-18 at 21:39 +0300, Dan Carpenter wrote: > On Wed, Dec 19, 2012 at 06:34:05AM +1300, Tony Prisk wrote: > > Resend to include mailing lists. > > > > Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. > > > > The original code is correct. clk_get() can return NULL depending >

[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

Resend to include mailing lists. Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. Signed-off-by: Tony Prisk CC: Inki Dae CC: Joonyoung Shim CC: Seung-Woo Kim CC: Kyungmin Park CC: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +- 1 file

[PATCH RESEND 2/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

Resend to include mailing lists. Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. In the fail: path of mixer_resources_init() and vp_resources_init() the first clk tested cannot be NULL either, so IS_ERR_OR_NULL is removed from these as well. Other clocks may still be NULL as they haven't

[PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

Resend to include mailing lists. Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. Signed-off-by: Tony Prisk li...@prisktech.co.nz CC: Inki Dae inki@samsung.com CC: Joonyoung Shim jy0922.s...@samsung.com CC: Seung-Woo Kim sw0312@samsung.com CC: Kyungmin Park

[PATCH RESEND 2/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

Resend to include mailing lists. Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. In the fail: path of mixer_resources_init() and vp_resources_init() the first clk tested cannot be NULL either, so IS_ERR_OR_NULL is removed from these as well. Other clocks may still be NULL as they haven't

Re: [PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

On Tue, 2012-12-18 at 21:39 +0300, Dan Carpenter wrote: On Wed, Dec 19, 2012 at 06:34:05AM +1300, Tony Prisk wrote: Resend to include mailing lists. Replace IS_ERR_OR_NULL with IS_ERR on clk_get results. The original code is correct. clk_get() can return NULL depending on the

Re: [PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: I don't care either way, but being different from the documentation is less bad than crashing which is what your patch does. Please be more careful in the future. regards, dan carpenter Critism accepted. Given that the driver

Re: [PATCH RESEND 3/6] clk: exynos: Fix incorrect usage of IS_ERR_OR_NULL

On Wed, 2012-12-19 at 08:11 +1300, Tony Prisk wrote: On Tue, 2012-12-18 at 22:03 +0300, Dan Carpenter wrote: I don't care either way, but being different from the documentation is less bad than crashing which is what your patch does. Please be more careful in the future. regards,

Re: [PATCH 1/3] drm: create unified vma offset manager

On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com So we have to offset manager implementations for dealing with VMA offsets. GEM had one using the hash table, TTM had one using an rbtree, I'd rather we just had one to rule them

Re: [PATCH 3/3] drm/gem: start adding support for per-file object mmaps

From: Chris Wilson ch...@chris-wilson.co.uk Subject: Re: [proof-of-concept/rfc] per object file mmaps To: Dave Airlie airl...@gmail.com, dri-devel@lists.freedesktop.org In-Reply-To: 1355892119-13926-1-git-send-email-airl...@gmail.com References: 1355892119-13926-1-git-send-email-airl...@gmail.com

Re: [PATCH 1/3] drm: create unified vma offset manager

On Wed, Dec 19, 2012 at 09:22:26AM +, Chris Wilson wrote: On Wed, 19 Dec 2012 11:56:18 +1000, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com So we have to offset manager implementations for dealing with VMA offsets. GEM had one using the hash table, TTM had

[Bug 58491] regression : r600g: work around ddx over alignment

https://bugs.freedesktop.org/show_bug.cgi?id=58491 --- Comment #9 from Andy Furniss li...@andyfurniss.entadsl.com --- (In reply to comment #8) (In reply to comment #7) Indeed, the resolution is the problem, running any application in my system resolution (1680x1050) breaks rendering,

[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown

https://bugs.freedesktop.org/show_bug.cgi?id=56634 --- Comment #6 from Andy Furniss li...@andyfurniss.entadsl.com --- (In reply to comment #5) Using kernel from linus's repo fixes this issue. Not sure if it is a proper fix, so I'll let you close the repoer if it should be closed. (now I'm

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

Hi Tomi, On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: Hi, I have been testing Common Display Framework on OMAP, and making changes that I've discussed in the posts I've sent in reply to the CDF series from Laurent. While my CDF code is rather hacky and not at all ready, I

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

Op 18-12-12 17:12, Markus Trippelsdorf schreef: On 2012.12.18 at 16:24 +0100, Maarten Lankhorst wrote: Op 18-12-12 14:38, Markus Trippelsdorf schreef: On 2012.12.18 at 12:20 +0100, Michel Dänzer wrote: On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote: On 2012.12.17 at 23:25

[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)

https://bugs.freedesktop.org/show_bug.cgi?id=41086 Jochen j...@fahrner.name changed: What|Removed |Added Status|RESOLVED|REOPENED

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: Op 18-12-12 17:12, Markus Trippelsdorf schreef: With your supposed debugging BUG_ONs added I still get: Dec 18 17:01:15 x4 kernel: [ cut here ] Dec 18 17:01:15 x4 kernel: WARNING: at include/linux/kref.h:42

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

Op 19-12-12 15:20, Markus Trippelsdorf schreef: On 2012.12.19 at 14:57 +0100, Maarten Lankhorst wrote: Op 18-12-12 17:12, Markus Trippelsdorf schreef: With your supposed debugging BUG_ONs added I still get: Dec 18 17:01:15 x4 kernel: [ cut here ] Dec 18 17:01:15 x4

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

On Wed, Dec 19, 2012 at 9:41 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Mittwoch, den 19.12.2012, 15:18 +0100 schrieb Maarten Lankhorst: Fix regression introduced by 85b144f860176 Thanks for the catch and patch. Also please add the commit summary to make the commit message

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

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 the need for a framework for DSI panels and such (in fact Tomi and I have talked about it like 2-3 years ago already!) but

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

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 the need for a framework for DSI panels

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

On 2012.12.19 at 15:54 +0100, Markus Trippelsdorf wrote: On 2012.12.19 at 09:47 -0500, Alex Deucher wrote: And the pictures get distorted on the test-webpage when I scroll up and down, see: http://trippelsdorf.de/bad.png The picture distortion issue is caused by: commit

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

On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2012-12-19 17:26, Rob Clark wrote: And, there are also external HDMI encoders (for example connected over i2c) that can also be shared between boards. So I think there will be a number of cases where CDF is

[PATCH] drm: Only evict the blocks required to create the requested hole

Avoid clobbering adjacent blocks if they happen to expire earlier and amalgamate together to form the requested hole. In passing this fixes a regression from commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Feb 18 17:59:12 2011 +0100

[PATCH] drm: Only evict the blocks required to create the requested hole

Avoid clobbering adjacent blocks if they happen to expire earlier and amalgamate together to form the requested hole. In passing this fixes a regression from commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Feb 18 17:59:12 2011 +0100

[PATCH] drm/radeon: add support for MEM_WRITE packet

From: Jerome Glisse jgli...@redhat.com To make it easier to debug some lockup from userspace add support to MEM_WRITE packet. Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/evergreen_cs.c | 29 + drivers/gpu/drm/radeon/r600_cs.c | 29

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

Op 19-12-12 15:18, Maarten Lankhorst schreef: Fix regression introduced by 85b144f860176 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Reported-by: Markus Trippelsdorf mar...@trippelsdorf.de Hey Paul Menzel, I just wanted to have the fix out asap, and had to leave right

Re: [PATCH] drm/radeon: add support for MEM_WRITE packet

On Wed, Dec 19, 2012 at 12:26 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com To make it easier to debug some lockup from userspace add support to MEM_WRITE packet. Signed-off-by: Jerome Glisse jgli...@redhat.com Looks good to me. Added to my fixes queue. Alex ---

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

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 daniel.vet...@ffwll.ch --- Documentation/DocBook/drm.tmpl |4 ++

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

Dear Maarten, Am Mittwoch, den 19.12.2012, 18:21 +0100 schrieb Maarten Lankhorst: Op 19-12-12 15:18, Maarten Lankhorst schreef: Fix regression introduced by 85b144f860176 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Reported-by: Markus Trippelsdorf

[Bug 35396] [mesa] black window when running glxgears after resume from suspend on ATI Radeon X800 SE

https://bugs.freedesktop.org/show_bug.cgi?id=35396 --- Comment #1 from Fabio Pedretti fabio@libero.it --- Is this still an issue? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list

[Bug 41659] Weird unit rendering on SpringRTS

https://bugs.freedesktop.org/show_bug.cgi?id=41659 --- Comment #9 from Fabio Pedretti fabio@libero.it --- Is this still an issue? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list

[Bug 44327] [r300g] Unigine Sanctuary: thin lines across textures are present when parallax mapping is enabled

https://bugs.freedesktop.org/show_bug.cgi?id=44327 --- Comment #1 from Fabio Pedretti fabio@libero.it --- Is this still an issue? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list

Re: Fan control in nouveau driver with geforce 9600gt

Here you go :) I managed to reproduce the issue. Please test this patch! Okay switching to automatic mode when pwm1 == 100 now gradually (in a few seconds, it is not cut down to 35 suddenly) lowers it down to 35. Switching to automatic mode while in manual mode doesn't make the pwm increase

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

On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark rob.cl...@linaro.org wrote: On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie airl...@gmail.com wrote: Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no

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

On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae inki@samsung.com wrote: 2012/12/18 Daniel Vetter dan...@ffwll.ch On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark rob.cl...@linaro.org wrote: The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are shared with the

[Bug 44327] [r300g] Unigine Sanctuary: thin lines across textures are present when parallax mapping is enabled

https://bugs.freedesktop.org/show_bug.cgi?id=44327 --- Comment #2 from Pavel Ondračka pavel.ondra...@email.cz --- (In reply to comment #1) Is this still an issue? This is still an issue with latest mesa git. -- You are receiving this mail because: You are the assignee for the bug.

[PATCH v2 0/2] drm/omap: Add PM and OMAP5 support

First patch adds PM capabilities for omapdrm. Second patch adds OMAP5 support to DMM driver component. Series was build tested and based on linux-next. v2: Updated commit msg for PM patch Andy Gross (2): drm/omap: Add PM capabilities drm/omap: Add OMAP5 support

[PATCH 2/2] drm/omap: Add OMAP5 support

Add support for OMAP5 processor. The main differences are that the OMAP5 has 2 containers, one for 1D and one for 2D. Each container is 128MiB in size. Signed-off-by: Andy Gross andy.gr...@ti.com Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_dmm_priv.h |5 +

  1   2   >