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 poli
Inki Dae
-Daniel
> --
> 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>
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 tim
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 bind
a module shouldn't
> 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>
.
>
> So I think we have a solution that resonates with 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>
gt;> + writel(BIT_MASK(id), sync_regs +
> >> + host1x_sync_syncpt_thresh_cpu0_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>
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>
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
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
) would
be clearer.
> Thanks. I've 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>
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 backin
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 deletions(
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
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resourc
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 93dffe3..d
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 12:
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 brea
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. G
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 a/driver
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
nam
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 stru
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
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 cr
s, as they have the means to
> enable it.
>
> sysfs is a place for actual APIs as you mention, and user space can rely
> on them as proper APIs. That's what the values were exported for.
But I don't see how that's relevant here. Let me quote what you said
originally:
>
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 d
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 ttm
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 |
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 insert
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 +++
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 slightl
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 inser
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 --gi
c_t handle_count; /* number of handles on this object */
>
> + /*
> +* Name count of this object.
> +*
> +* This count is initialized as 0 with 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>
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 closes the gem handle, t
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 c
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121130/c9ffa7ee/attachment.html>
You 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>
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
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
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, n
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: durin
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 o
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 i9
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 shou
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
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:
> >
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 30
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 >>>shipmail
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
> 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: a
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 3.7.0-rc7-00113-g
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 wrot
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
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 wrot
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 tested
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 +
> drivers/video/display/panel-dpi.c | 147
> ++
t 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/20121130/21120530/attachment-0001.pgp>
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 e
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 s
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 fo
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 bind
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
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 su
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
> >> +++ b/drivers/video
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.
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
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
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() e
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 backin
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 deletions(
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
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resourc
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 93dffe3..d
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 12:44 AM, Alan Swanson
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 brea
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. G
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 a/drivers/gpu/drm/vm
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
nam
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 structures?
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 lock
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 cr
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 kerne
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.
Marten,
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 ttm
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 |
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 insert
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 +++
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 slightl
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 inser
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 --gi
2012/11/30 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 close
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 closes the gem handle, t
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.
Pa
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
O
https://bugs.freedesktop.org/show_bug.cgi?id=57741
--- Comment #1 from Alex Deucher ---
SHould be fixed with:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.7&id=fc58acdbf153f12783b80cb19c04cc9de121b518
Which will be upstream soon.
--
You are receiving this mail because:
You are
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
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
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, no
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: durin
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 of
evicted buffe
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 i9
1 - 100 of 117 matches
Mail list logo
