WARNING: at drivers/gpu/drm/i915/intel_display.c:1009 ironlake_crtc_disable+0xaf/0x8e0

> I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The > computer last ran 3.6.0 without any warnings. Second reboot showed the > same warning plus a couple of EDID warnings (also below). Still there with 3.7.0-rc7-00113-gcc19528 and 100% reproducible: [0.646574] WARNING:

[RFC v1] drm: add reference count of gem object name

h drm_gem_object_init or > +* drm_gem_private_object_init call. After that, this count is > +* increased if the name of this object exists already > +* otherwise is set to 1 at flink. And finally, the name of > +* this object will be released when this count reaches 0 > +* by gem close. > +*/ > + atomic_t obj_name_count; > + > /** Related drm device */ > struct drm_device *dev; > > -- > 1.7.4.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121130/8df39b7e/attachment-0001.html>

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/30/2012 10:07 PM, Jerome Glisse wrote: > On Fri, Nov 30, 2012 at 09:35:49PM +0100, Thomas Hellstrom wrote: >> On 11/30/2012 08:25 PM, Jerome Glisse wrote: >>> On Fri, Nov 30, 2012 at 07:31:04PM +0100, Thomas Hellstrom wrote: On 11/30/2012 07:07 PM, Jerome Glisse wrote: > On Fri, Nov

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On 11/30/2012 09:25 PM, Luis R. Rodriguez wrote: > On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez > wrote: >> On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel >> wrote: >>> So what is the rationale here. During mainlining our drivers we had to >>> remove all uses of 'typedef struct foo

WARNING: at drivers/gpu/drm/i915/intel_display.c:1009 ironlake_crtc_disable+0xaf/0x8e0

On Fri, Nov 30, 2012 at 9:49 PM, Meelis Roos wrote: >> I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The >> computer last ran 3.6.0 without any warnings. Second reboot showed the >> same warning plus a couple of EDID warnings (also below). > > Still there with

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/30/2012 08:25 PM, Jerome Glisse wrote: > On Fri, Nov 30, 2012 at 07:31:04PM +0100, Thomas Hellstrom wrote: >> On 11/30/2012 07:07 PM, Jerome Glisse wrote: >>> On Fri, Nov 30, 2012 at 06:43:36PM +0100, Thomas Hellstrom wrote: On 11/30/2012 06:18 PM, Jerome Glisse wrote: > On Fri, Nov

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/30/2012 07:07 PM, Jerome Glisse wrote: > On Fri, Nov 30, 2012 at 06:43:36PM +0100, Thomas Hellstrom wrote: >> On 11/30/2012 06:18 PM, Jerome Glisse wrote: >>> On Fri, Nov 30, 2012 at 12:08 PM, Thomas Hellstrom >>> wrote: On 11/30/2012 05:30 PM, Jerome Glisse wrote: > On Fri, Nov

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/30/2012 06:18 PM, Jerome Glisse wrote: > On Fri, Nov 30, 2012 at 12:08 PM, Thomas Hellstrom > wrote: >> On 11/30/2012 05:30 PM, Jerome Glisse wrote: >>> On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom >>> wrote: On 11/29/2012 10:58 PM, Marek Ol??k wrote: > > What I tried to

[RFC v1] drm: add reference count of gem object name

Hello, all. This patch introduces reference count of gem object name and resolves the below issue. In case that proces A shares its own gem object with process B, process B opens a gem object name from process A to get its own gem handle. But if process A closes the gem handle, the gem object

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/30/2012 05:30 PM, Jerome Glisse wrote: > On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom > wrote: >> On 11/29/2012 10:58 PM, Marek Ol??k wrote: >>> >>> What I tried to point out was that the synchronization shouldn't be >>> needed, because the CPU shouldn't do anything with the contents

[GIT PULL v2] exynos-drm-next

On Fri, Nov 30, 2012 at 6:27 AM, Inki Dae wrote: > I agree with you and also I think it's better to use common infoframe > helpers. > But Rahul'a patch set had been posted prior to the common infoframe helpers > so > first we could merge this patch and then change it to common infoframe > helpers

[RFC v1] drm: add reference count of gem object name

Hi, tbh I don't follow what exactly you're trying to fix, but the rules is: The flink name stays around as long as there's a userspace handle, and will be deleted once the last userspace handle is closed. Which means that for process->process gem passing the sender _must_ keep the bo handle

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On Fri, Nov 30, 2012 at 10:36:01PM +0100, Thomas Hellstrom wrote: > On 11/30/2012 10:07 PM, Jerome Glisse wrote: > >On Fri, Nov 30, 2012 at 09:35:49PM +0100, Thomas Hellstrom wrote: > >>On 11/30/2012 08:25 PM, Jerome Glisse wrote: > >>>On Fri, Nov 30, 2012 at 07:31:04PM +0100, Thomas Hellstrom

[PATCH 0/6] drm/ttm: lru lock atomicity removal

On 11/30/2012 01:11 PM, Maarten Lankhorst wrote: > With all the previous patches there shouldn't be anything lying on the > reservations being atomic > with removal of the bo's from the lru lists any more. > > As such we can finally fix the locking primitives and make it act like normal > mutex

[Bug 42627] Hibernation fails to resume - Toshiba Satellite L755-161 notebook

https://bugzilla.kernel.org/show_bug.cgi?id=42627 --- Comment #25 from Harald Brennich 2012-11-30 16:41:04 --- After installing openSuse 12.2 with kernel 3.4.11-2.16-desktop, resume from s2disk works with the nouveau driver. There is one (small) drawback compared to the nvidia driver:

[Bug 57741] [regression] Resolution crippled for HD4870X2

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121130/0323b622/attachment.html>

[Bug 57741] New: [regression] Resolution crippled for HD4870X2

he bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121130/c9ffa7ee/attachment.html>

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On Fri, Nov 30, 2012 at 09:35:49PM +0100, Thomas Hellstrom wrote: > On 11/30/2012 08:25 PM, Jerome Glisse wrote: > >On Fri, Nov 30, 2012 at 07:31:04PM +0100, Thomas Hellstrom wrote: > >>On 11/30/2012 07:07 PM, Jerome Glisse wrote: > >>>On Fri, Nov 30, 2012 at 06:43:36PM +0100, Thomas Hellstrom

[GIT PULL v2] exynos-drm-next

gt; -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121130/4ef44130/attachment.html>

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On Fri, Nov 30, 2012 at 07:31:04PM +0100, Thomas Hellstrom wrote: > On 11/30/2012 07:07 PM, Jerome Glisse wrote: > >On Fri, Nov 30, 2012 at 06:43:36PM +0100, Thomas Hellstrom wrote: > >>On 11/30/2012 06:18 PM, Jerome Glisse wrote: > >>>On Fri, Nov 30, 2012 at 12:08 PM, Thomas Hellstrom

[RFC,v2,3/8] video: tegra: host: Add channel and client support

On 11/29/2012 06:46 PM, Terje Bergstr?m wrote: > On 29.11.2012 12:01, Mark Zhang wrote: >> >> Just for curious, why "pb->mapped + 1K" is the end of a 4K pushbuffer? > > pb->mapped is u32 *, so compiler will take care of multiplying by > sizeof(u32). > Ah, yes. Sorry, I must be insane at that

[RFC v2 3/5] video: display: Add MIPI DBI bus support

bbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121130/21120530/attachment-0001.pgp>

[PATCH 6/6] drm/ttm: unexport ttm_bo_wait_unreserved

All legitimate users of this function outside ttm_bo.c are gone, now it's only an implementation detail. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ttm/ttm_bo.c| 4 ++-- include/drm/ttm/ttm_bo_driver.h | 12 2 files changed, 2 insertions(+), 14 deletions(-) diff

[PATCH 5/6] drm/nouveau: use ttm_bo_reserve_slowpath in validate_init

Similar rationale to the identical commit in drm/ttm. Instead of only waiting for unreservation, we make sure we actually own the reservation, then retry to get the rest. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_gem.c | 19 +++ 1 file changed, 15

[PATCH 4/6] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers

This requires re-use of the seqno, which increases fairness slightly. Instead of spinning with a new seqno every time we keep the current one, but still drop all other reservations we hold. Only when we succeed, we try to get back our other reservations again. This should increase fairness

[PATCH 3/6] drm/ttm: add ttm_bo_reserve_slowpath

Instead of dropping everything, waiting for the bo to be unreserved and trying over, a better strategy would be to do a blocking wait. This can be mapped a lot better to a mutex_lock-like call. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ttm/ttm_bo.c| 47

[PATCH 2/6] drm/ttm: cleanup ttm_eu_reserve_buffers handling

With the lru lock no longer required for protecting reservations we can just do a ttm_bo_reserve_nolru on -EBUSY, and handle all errors in a single path. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ttm/ttm_execbuf_util.c | 53 ++ 1 file changed, 21

[PATCH 1/6] drm/ttm: remove lru_lock around ttm_bo_reserve

There should no longer be assumptions that reserve will always succeed with the lru lock held, so we can safely break the whole atomic reserve/lru thing. As a bonus this fixes most lockdep annotations for reservations. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ttm/ttm_bo.c

[PATCH 0/6] drm/ttm: lru lock atomicity removal

With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the lru lists any more. As such we can finally fix the locking primitives and make it act like normal mutex calls. Patch 1 is the actual removal of the guarantee in

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On Fri, Nov 30, 2012 at 06:43:36PM +0100, Thomas Hellstrom wrote: > On 11/30/2012 06:18 PM, Jerome Glisse wrote: > >On Fri, Nov 30, 2012 at 12:08 PM, Thomas Hellstrom > >wrote: > >>On 11/30/2012 05:30 PM, Jerome Glisse wrote: > >>>On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom > >>>wrote: >

[PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

On 11/30/2012 11:16 AM, Maarten Lankhorst wrote: > Op 30-11-12 10:04, Thomas Hellstrom schreef: >> On 11/30/2012 09:05 AM, Maarten Lankhorst wrote: >>> Just use the return error from ttm_mem_evict_first instead. >>> >>> Changes since v1: >>> - Add warning if list is not empty, nothing else we can

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez wrote: > On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel > wrote: >> So what is the rationale here. During mainlining our drivers we had to >> remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle >> (chapter 5 Typedefs) is

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On Fri, Nov 30, 2012 at 12:08 PM, Thomas Hellstrom wrote: > On 11/30/2012 05:30 PM, Jerome Glisse wrote: >> >> On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom >> wrote: >>> >>> On 11/29/2012 10:58 PM, Marek Ol??k wrote: What I tried to point out was that the synchronization

[RFC v2 1/8] video: tegra: Add nvhost driver

exported for. But I don't see how that's relevant here. Let me quote what you said originally: > This is actually the only interface to read the max value to user space, > which can be useful for doing some comparisons that take wrapping into > account. But we could just add IOCTLs and remo

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom wrote: > On 11/29/2012 10:58 PM, Marek Ol??k wrote: >> >> >> What I tried to point out was that the synchronization shouldn't be >> needed, because the CPU shouldn't do anything with the contents of >> evicted buffers. The GPU moves the buffers,

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel wrote: > So what is the rationale here. During mainlining our drivers we had to > remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle > (chapter 5 Typedefs) is spending a number of lines explaining why. > > So is spinlock_t an

[PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

Op 30-11-12 10:04, Thomas Hellstrom schreef: > On 11/30/2012 09:05 AM, Maarten Lankhorst wrote: >> Just use the return error from ttm_mem_evict_first instead. >> >> Changes since v1: >> - Add warning if list is not empty, nothing else we can do here. > > Marten, when this function is called, all

some drm cleanups to pull

Hi Dave, I've rebased the patch series to remove usage of and drop the legacy connector-property functions and replace w/ object-property which can be pulled from: git://github.com/robclark/kernel-omap4.git connector-to-object-prop There was one additional connector->object rename needed in

[RFC v2 1/8] video: tegra: Add nvhost driver

On 29.11.2012 13:47, Thierry Reding wrote: > On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergstr?m wrote: >> Tegra20 and Tegra30 are compatible, but future chips are not. I was >> hoping we would be ready in upstream kernel for future chips. > > I think we should ignore that problem for now.

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/29/2012 10:58 PM, Marek Ol??k wrote: > > What I tried to point out was that the synchronization shouldn't be > needed, because the CPU shouldn't do anything with the contents of > evicted buffers. The GPU moves the buffers, not the CPU. What does the > CPU do besides updating some kernel

[RFC v2 2/5] video: panel: Add DPI panel support

Hi Laurent, Am Donnerstag, den 22.11.2012, 22:45 +0100 schrieb Laurent Pinchart: > From: Laurent Pinchart > > Signed-off-by: Laurent Pinchart > --- > drivers/video/display/Kconfig | 13 +++ > drivers/video/display/Makefile|1 + >

[PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

On 11/30/2012 09:05 AM, Maarten Lankhorst wrote: > Just use the return error from ttm_mem_evict_first instead. > > Changes since v1: > - Add warning if list is not empty, nothing else we can do here. Marten, when this function is called, all cross-device reservers have been shut out with the TTM

[PATCH, FIXED] drm/vmwgfx: always use ttm_bo_is_reserved

Reviewed-by: Thomas Hellstrom On 11/30/2012 09:18 AM, Maarten Lankhorst wrote: > This was missed during the initial conversion, most likely due to the > refactoring here. > > Signed-off-by: Maarten Lankhorst > --- > Woops, forgot to stg refresh before sending, fixed. :-) > > diff --git

[RFC v2 1/8] video: tegra: Add nvhost driver

Am Donnerstag, den 29.11.2012, 11:38 -0700 schrieb Stephen Warren: > On 11/29/2012 04:47 AM, Thierry Reding wrote: > > I agree. But I also fear that there will be changes eventually and > > having both go in via different tree requires those trees to be > > merged in a specific order to avoid

[RFC v2 8/8] drm: tegra: Add gr2d device

On 29.11.2012 14:14, Thierry Reding wrote: > On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote: >> This way you would also be able to construct different handles (like GEM >> obj or V4L2 buffers) from the same backing nvhost object. Note that I'm >> not sure how useful this would be, but

[RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

Just replying to part of your mail. On 30.11.2012 09:22, Thierry Reding wrote: > Actually for the display controller we want just a notification when the > VBLANK happens. I'm not sure if we want to do that with syncpoints at > all since it works quite well using regular interrupts. VBLANK isn't

[PATCH] drm/ttm: add minimum residency constraint for bo eviction

On 11/29/2012 10:58 PM, Marek Ol??k wrote: > On Thu, Nov 29, 2012 at 9:33 PM, Thomas Hellstrom > wrote: >> On 11/29/2012 01:52 PM, Marek Ol??k wrote: >>> On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom >>> wrote: On 11/29/2012 03:15 AM, Marek Ol??k wrote: > On Thu, Nov 29, 2012 at

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On 11/29/2012 09:45 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Turns out a few drivers have strayed away from using the > spinlock_t typedef and decided to use struct spinlock > directly. This series converts these drivers to use > spinlock_t. Each change has been compile

[PATCH, FIXED] drm/vmwgfx: always use ttm_bo_is_reserved

This was missed during the initial conversion, most likely due to the refactoring here. Signed-off-by: Maarten Lankhorst --- Woops, forgot to stg refresh before sending, fixed. :-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index

[PATCH] drm/vmwgfx: always use ttm_bo_is_reserved

This was missed during the initial conversion, most likely due to the refactoring here. Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index 93dffe3..783a448 100644 ---

[PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

Just use the return error from ttm_mem_evict_first instead. Changes since v1: - Add warning if list is not empty, nothing else we can do here. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ttm/ttm_bo.c | 30 +++--- 1 file changed, 15 insertions(+), 15

[RFC v2 1/8] video: tegra: Add nvhost driver

On 29.11.2012 20:34, Stephen Warren wrote: > On 11/29/2012 03:21 AM, Terje Bergstr?m wrote: >> True. I might also as well delete the general interrupt altogether, as >> we don't use it for any real purpose. > > Do make sure the interrupts still are part of the DT binding though, so > that the

[RFC v2 8/8] drm: tegra: Add gr2d device

Am Freitag, den 30.11.2012, 09:44 +0200 schrieb Terje Bergstr?m: > On 29.11.2012 14:14, Thierry Reding wrote: > > On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote: > >> This way you would also be able to construct different handles (like GEM > >> obj or V4L2 buffers) from the same

[RFC v2 3/8] video: tegra: host: Add channel and client support

collected a massive amount of feedback already. v3 will > take quite a while to appear after we've finished all the reviews of v2. Yes, that should keep you busy for quite a while. =) But I also think we've made good progress so far. 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/20121130/b507fe64/attachment.pgp>

[RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

t;< 2" with "* > REGISTER_STRIDE" here. Given that it is a very common pattern, << 2 seems enough documentation to me, but sure, if you prefer to be extra explicit that's fine with me. 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/20121130/1109d9de/attachment-0001.pgp>

[RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

_int_status_r() + reg); > >> +} > > > > So this disables all interrupts and is called from the syncpt interrupt > > handler. Where are the interrupts reenabled? Do host1x clients have to > > do that manually? > > The thread re-enables once it's done. It checks the next value we're > interested in, and programs that to host1x syncpt threshold. Okay, that does make sense now. I think I'm indeed beginning to understand how the hardware works... > > Okay, so this is where syncpoint interrupts are reenabled. The rest of > > this whole wait queue code looks overly complex. I'll need to go through > > that separately and more thoroughly. > > Thanks. If we move responsibility of managing the workqueue out of host1x as I proposed above, maybe a lot of this code can be removed. Maybe you can explain a bit what they are used for exactly in your write-up. 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/20121130/fd1e020b/attachment.pgp>

[RFC v2 1/8] video: tegra: Add nvhost driver

th all proposals. Yes, that sounds good to me. 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/20121130/6b030934/attachment.pgp>

[RFC v2 1/8] video: tegra: Add nvhost driver

> require this. Yes, that's true. But it still makes things more complicated since each of the maintainers will have to do extra work to test the changes. Anyway we'll see how this plays out. The ideal case would of course be to get the API right from the start. =) 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/20121130/6cb2861d/attachment.pgp>

[RESEND][RFC v1] drm: add reference count of gem object name

From: Inki Dae Hello, all. This patch introduces reference count of gem object name and resolves the below issue. In case that proces A shares its own gem object with process B, process B opens a gem object name from process A to get its own gem handle. But if process A

[RFC] improve memory placement for radeon

On Thu, Nov 29, 2012 at 4:35 PM, wrote: > So as a followup is 2 patch. The first one just stop trying to move > object at each cs ioctl i believe it could be included in 3.7 as it > improve performances (especialy with vram change from userspace). > > The second one implement a vram eviction

Re: [RFC v2 1/8] video: tegra: Add nvhost driver

On 29.11.2012 20:34, Stephen Warren wrote: On 11/29/2012 03:21 AM, Terje Bergström wrote: True. I might also as well delete the general interrupt altogether, as we don't use it for any real purpose. Do make sure the interrupts still are part of the DT binding though, so that the binding

Re: [RFC v2 1/8] video: tegra: Add nvhost driver

On Thu, Nov 29, 2012 at 11:38:11AM -0700, Stephen Warren wrote: On 11/29/2012 04:47 AM, Thierry Reding wrote: On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote: On 28.11.2012 23:23, Thierry Reding wrote: This could be problematic. Since drivers/video and drivers/gpu/drm are

Re: [RFC v2 1/8] video: tegra: Add nvhost driver

On Fri, Nov 30, 2012 at 08:54:32AM +0200, Terje Bergström wrote: On 29.11.2012 20:34, Stephen Warren wrote: On 11/29/2012 03:21 AM, Terje Bergström wrote: True. I might also as well delete the general interrupt altogether, as we don't use it for any real purpose. Do make sure the

Re: [RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

On Thu, Nov 29, 2012 at 12:39:23PM +0200, Terje Bergström wrote: On 29.11.2012 10:44, Thierry Reding wrote: diff --git a/drivers/video/tegra/host/dev.c b/drivers/video/tegra/host/dev.c index 98c9c9f..025a820 100644 --- a/drivers/video/tegra/host/dev.c +++

Re: [RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

On Thu, Nov 29, 2012 at 11:41:50AM -0700, Stephen Warren wrote: On 11/29/2012 01:44 AM, Thierry Reding wrote: On Mon, Nov 26, 2012 at 03:19:08PM +0200, Terje Bergstrom wrote: diff --git a/drivers/video/tegra/host/host1x/host1x_intr.c b/drivers/video/tegra/host/host1x/host1x_intr.c [...]

Re: [RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

Just replying to part of your mail. On 30.11.2012 09:22, Thierry Reding wrote: Actually for the display controller we want just a notification when the VBLANK happens. I'm not sure if we want to do that with syncpoints at all since it works quite well using regular interrupts. VBLANK isn't

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On 29.11.2012 14:14, Thierry Reding wrote: On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote: This way you would also be able to construct different handles (like GEM obj or V4L2 buffers) from the same backing nvhost object. Note that I'm not sure how useful this would be, but it

Re: [RFC v2 3/8] video: tegra: host: Add channel and client support

On Thu, Nov 29, 2012 at 01:00:40PM +0200, Terje Bergström wrote: On 29.11.2012 12:04, Thierry Reding wrote: Looking some more at how this is used, I'm starting to think that it might be easier to export the various handlers and allow them to be passed to the nvhost_intr_add_action()

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

Am Freitag, den 30.11.2012, 09:44 +0200 schrieb Terje Bergström: On 29.11.2012 14:14, Thierry Reding wrote: On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote: This way you would also be able to construct different handles (like GEM obj or V4L2 buffers) from the same backing nvhost

[PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

Just use the return error from ttm_mem_evict_first instead. Changes since v1: - Add warning if list is not empty, nothing else we can do here. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/ttm/ttm_bo.c | 30 +++--- 1 file changed,

[PATCH] drm/vmwgfx: always use ttm_bo_is_reserved

This was missed during the initial conversion, most likely due to the refactoring here. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index 93dffe3..783a448 100644 ---

[PATCH, FIXED] drm/vmwgfx: always use ttm_bo_is_reserved

This was missed during the initial conversion, most likely due to the refactoring here. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- Woops, forgot to stg refresh before sending, fixed. :-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c

Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction

On 11/29/2012 10:58 PM, Marek Olšák wrote: On Thu, Nov 29, 2012 at 9:33 PM, Thomas Hellstrom tho...@shipmail.org wrote: On 11/29/2012 01:52 PM, Marek Olšák wrote: On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom tho...@shipmail.org wrote: On 11/29/2012 03:15 AM, Marek Olšák wrote: On Thu,

Re: [RFC v2 1/8] video: tegra: Add nvhost driver

Am Donnerstag, den 29.11.2012, 11:38 -0700 schrieb Stephen Warren: On 11/29/2012 04:47 AM, Thierry Reding wrote: I agree. But I also fear that there will be changes eventually and having both go in via different tree requires those trees to be merged in a specific order to avoid breakage

Re: [RFC v2 1/8] video: tegra: Add nvhost driver

On 29.11.2012 13:47, Thierry Reding wrote: On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote: Tegra20 and Tegra30 are compatible, but future chips are not. I was hoping we would be ready in upstream kernel for future chips. I think we should ignore that problem for now.

Re: [PATCH, FIXED] drm/vmwgfx: always use ttm_bo_is_reserved

Reviewed-by: Thomas Hellstrom thellst...@vmware.com On 11/30/2012 09:18 AM, Maarten Lankhorst wrote: This was missed during the initial conversion, most likely due to the refactoring here. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- Woops, forgot to stg refresh before

[RFC v1] drm: add reference count of gem object name

Hello, all. This patch introduces reference count of gem object name and resolves the below issue. In case that proces A shares its own gem object with process B, process B opens a gem object name from process A to get its own gem handle. But if process A closes the gem handle, the gem object

Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/29/2012 10:58 PM, Marek Olšák wrote: What I tried to point out was that the synchronization shouldn't be needed, because the CPU shouldn't do anything with the contents of evicted buffers. The GPU moves the buffers, not the CPU. What does the CPU do besides updating some kernel

Re: [PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

On 11/30/2012 09:05 AM, Maarten Lankhorst wrote: Just use the return error from ttm_mem_evict_first instead. Changes since v1: - Add warning if list is not empty, nothing else we can do here. Marten, when this function is called, all cross-device reservers have been shut out with the TTM

Re: [PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

Op 30-11-12 10:04, Thomas Hellstrom schreef: On 11/30/2012 09:05 AM, Maarten Lankhorst wrote: Just use the return error from ttm_mem_evict_first instead. Changes since v1: - Add warning if list is not empty, nothing else we can do here. Marten, when this function is called, all cross-device

Re: [RFC v2 1/8] video: tegra: Add nvhost driver

On Fri, Nov 30, 2012 at 10:56:39AM +0200, Terje Bergström wrote: On 29.11.2012 13:47, Thierry Reding wrote: On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote: Tegra20 and Tegra30 are compatible, but future chips are not. I was hoping we would be ready in upstream kernel for

Re: [PATCH] drm/ttm: do not check if list is empty in ttm_bo_force_list_clean, v2

On 11/30/2012 11:16 AM, Maarten Lankhorst wrote: Op 30-11-12 10:04, Thomas Hellstrom schreef: On 11/30/2012 09:05 AM, Maarten Lankhorst wrote: Just use the return error from ttm_mem_evict_first instead. Changes since v1: - Add warning if list is not empty, nothing else we can do here.

[PATCH 0/6] drm/ttm: lru lock atomicity removal

With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the lru lists any more. As such we can finally fix the locking primitives and make it act like normal mutex calls. Patch 1 is the actual removal of the guarantee in

[PATCH 1/6] drm/ttm: remove lru_lock around ttm_bo_reserve

There should no longer be assumptions that reserve will always succeed with the lru lock held, so we can safely break the whole atomic reserve/lru thing. As a bonus this fixes most lockdep annotations for reservations. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com ---

[PATCH 2/6] drm/ttm: cleanup ttm_eu_reserve_buffers handling

With the lru lock no longer required for protecting reservations we can just do a ttm_bo_reserve_nolru on -EBUSY, and handle all errors in a single path. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/ttm/ttm_execbuf_util.c | 53

[PATCH 3/6] drm/ttm: add ttm_bo_reserve_slowpath

Instead of dropping everything, waiting for the bo to be unreserved and trying over, a better strategy would be to do a blocking wait. This can be mapped a lot better to a mutex_lock-like call. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/ttm/ttm_bo.c

[PATCH 4/6] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers

This requires re-use of the seqno, which increases fairness slightly. Instead of spinning with a new seqno every time we keep the current one, but still drop all other reservations we hold. Only when we succeed, we try to get back our other reservations again. This should increase fairness

[PATCH 5/6] drm/nouveau: use ttm_bo_reserve_slowpath in validate_init

Similar rationale to the identical commit in drm/ttm. Instead of only waiting for unreservation, we make sure we actually own the reservation, then retry to get the rest. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_gem.c | 19

[PATCH 6/6] drm/ttm: unexport ttm_bo_wait_unreserved

All legitimate users of this function outside ttm_bo.c are gone, now it's only an implementation detail. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/ttm/ttm_bo.c| 4 ++-- include/drm/ttm/ttm_bo_driver.h | 12 2 files changed, 2

Re: [RFC v1] drm: add reference count of gem object name

2012/11/30 Inki Dae inki@samsung.com Hello, all. This patch introduces reference count of gem object name and resolves the below issue. In case that proces A shares its own gem object with process B, process B opens a gem object name from process A to get its own gem handle. But if

[RESEND][RFC v1] drm: add reference count of gem object name

From: Inki Dae inki@samsung.com Hello, all. This patch introduces reference count of gem object name and resolves the below issue. In case that proces A shares its own gem object with process B, process B opens a gem object name from process A to get its own gem handle. But if process A

Re: [PATCH 0/6] drm/ttm: lru lock atomicity removal

On 11/30/2012 01:11 PM, Maarten Lankhorst wrote: With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the lru lists any more. As such we can finally fix the locking primitives and make it act like normal mutex calls.

[Bug 57741] New: [regression] Resolution crippled for HD4870X2

https://bugs.freedesktop.org/show_bug.cgi?id=57741 Priority: medium Bug ID: 57741 Assignee: dri-devel@lists.freedesktop.org Summary: [regression] Resolution crippled for HD4870X2 Severity: major Classification: Unclassified

[Bug 57741] [regression] Resolution crippled for HD4870X2

https://bugs.freedesktop.org/show_bug.cgi?id=57741 --- Comment #1 from Alex Deucher ag...@yahoo.com --- SHould be fixed with: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.7id=fc58acdbf153f12783b80cb19c04cc9de121b518 Which will be upstream soon. -- You are receiving this mail

Re: [RFC v1] drm: add reference count of gem object name

Hi, tbh I don't follow what exactly you're trying to fix, but the rules is: The flink name stays around as long as there's a userspace handle, and will be deleted once the last userspace handle is closed. Which means that for process-process gem passing the sender _must_ keep the bo handle open

Re: [GIT PULL v2] exynos-drm-next

On Fri, Nov 30, 2012 at 6:27 AM, Inki Dae inki@samsung.com wrote: I agree with you and also I think it's better to use common infoframe helpers. But Rahul'a patch set had been posted prior to the common infoframe helpers so first we could merge this patch and then change it to common

Re: Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom tho...@shipmail.org wrote: On 11/29/2012 10:58 PM, Marek Olšák wrote: What I tried to point out was that the synchronization shouldn't be needed, because the CPU shouldn't do anything with the contents of evicted buffers. The GPU moves the

[Bug 42627] Hibernation fails to resume - Toshiba Satellite L755-161 notebook

https://bugzilla.kernel.org/show_bug.cgi?id=42627 --- Comment #25 from Harald Brennich harald.brenn...@gmx.de 2012-11-30 16:41:04 --- After installing openSuse 12.2 with kernel 3.4.11-2.16-desktop, resume from s2disk works with the nouveau driver. There is one (small) drawback compared to

Re: Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction]

On 11/30/2012 05:30 PM, Jerome Glisse wrote: On Fri, Nov 30, 2012 at 4:39 AM, Thomas Hellstrom tho...@shipmail.org wrote: On 11/29/2012 10:58 PM, Marek Olšák wrote: What I tried to point out was that the synchronization shouldn't be needed, because the CPU shouldn't do anything with the

some drm cleanups to pull

Hi Dave, I've rebased the patch series to remove usage of and drop the legacy connector-property functions and replace w/ object-property which can be pulled from: git://github.com/robclark/kernel-omap4.git connector-to-object-prop There was one additional connector-object rename needed in

  1   2   >