All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <deathsimple@vodafone.de>
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>,
	Dave Airlie <airlied@redhat.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [PULL REQUEST] ttm fence conversion
Date: Mon, 01 Sep 2014 18:21:45 +0200	[thread overview]
Message-ID: <54049D19.30802@vodafone.de> (raw)
In-Reply-To: <540475A6.2020603@canonical.com>

Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
> Hey,
>
> Op 01-09-14 om 14:31 schreef Christian König:
>> Please wait a second with that.
>>
>> I didn't had a chance to test this yet and nobody has yet given it's rb on at least the radeon changes in this branch.
> Ok, my fault. I thought it was implicitly acked. I haven't made any functional changes to these patches,
> just some small fixups and a fix to make it apply after the upstream removal of  RADEON_FENCE_SIGNALED_SEQ.

Yeah, but the resulting patch looks to complex for my taste and should 
be simplified a bit more. Here is a more detailed review:

> +    wait_queue_t fence_wake;
Only a nitpick, but please fix the indention and maybe add a comment.

> +    struct work_struct delayed_irq_work;
Just drop that, the new fall back work item should take care of this 
when the unfortunate case happens that somebody tries to 
enable_signaling in the middle of a GPU reset.

>  /*
> - * Cast helper
> - */
> -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
> -
> -/*
Please define the new cast helper in radeon.h as well.

>      if (!rdev->needs_reset) {
> -        up_write(&rdev->exclusive_lock);
> +        downgrade_write(&rdev->exclusive_lock);
> +        wake_up_all(&rdev->fence_queue);
> +        up_read(&rdev->exclusive_lock);
>          return 0;
>      }
Just drop that as well, no need to wake up anybody here.

>  downgrade_write(&rdev->exclusive_lock);
> +    wake_up_all(&rdev->fence_queue);
Same here, the IB test will wake up all fences for recheck anyway.

> + * radeon_fence_read_seq - Returns the current fence value without 
> updating
> + *
> + * @rdev: radeon_device pointer
> + * @ring: ring index to return the seqno of
> + */
> +static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int 
> ring)
> +{
> +    uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
> +    uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
> +    uint64_t seq = radeon_fence_read(rdev, ring);
> +
> +    seq = radeon_fence_read(rdev, ring);
> +    seq |= last_seq & 0xffffffff00000000LL;
> +    if (seq < last_seq) {
> +        seq &= 0xffffffff;
> +        seq |= last_emitted & 0xffffffff00000000LL;
> +    }
> +    return seq;
> +}
Completely drop that and just check the last_seq signaled as set by 
radeon_fence_activity.

> +        if (!ret)
> +            FENCE_TRACE(&fence->base, "signaled from irq context\n");
> +        else
> +            FENCE_TRACE(&fence->base, "was already signaled\n");
Is all that text tracing necessary? Probably better define a trace point 
here.

> +    if (atomic64_read(&rdev->fence_drv[fence->ring].last_seq) >= 
> fence->seq ||
> +        !rdev->ddev->irq_enabled)
> +        return false;
Checking irq_enabled here might not be such a good idea if the fence 
code don't has a fall back on it's own. What exactly happens if 
enable_signaling returns false?

> +static signed long radeon_fence_default_wait(struct fence *f, bool intr,
> +                         signed long timeout)
> +{
> +    struct radeon_fence *fence = to_radeon_fence(f);
> +    struct radeon_device *rdev = fence->rdev;
> +    bool signaled;
> +
> +    fence_enable_sw_signaling(&fence->base);
> +
> +    /*
> +     * This function has to return -EDEADLK, but cannot hold
> +     * exclusive_lock during the wait because some callers
> +     * may already hold it. This means checking needs_reset without
> +     * lock, and not fiddling with any gpu internals.
> +     *
> +     * The callback installed with fence_enable_sw_signaling will
> +     * run before our wait_event_*timeout call, so we will see
> +     * both the signaled fence and the changes to needs_reset.
> +     */
> +
> +    if (intr)
> +        timeout = wait_event_interruptible_timeout(rdev->fence_queue,
> +                               ((signaled = 
> (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->base.flags))) || 
> rdev->needs_reset),
> +                               timeout);
> +    else
> +        timeout = wait_event_timeout(rdev->fence_queue,
> +                         ((signaled = 
> (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->base.flags))) || 
> rdev->needs_reset),
> +                         timeout);
> +
> +    if (timeout > 0 && !signaled)
> +        return -EDEADLK;
> +    return timeout;
> +}
This at least needs to be properly formated, but I think since we now 
don't need extra handling any more we don't need an extra wait function 
as well.

Regards,
Christian.

  reply	other threads:[~2014-09-01 16:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-01 11:34 [PULL REQUEST] ttm fence conversion Maarten Lankhorst
2014-09-01 12:31 ` Christian König
2014-09-01 13:33   ` Maarten Lankhorst
2014-09-01 16:21     ` Christian König [this message]
2014-09-01 18:43       ` Maarten Lankhorst
2014-09-02  8:51         ` Christian König
2014-09-02  9:12           ` Maarten Lankhorst
2014-09-02  9:52             ` Christian König
2014-09-02 12:29               ` Maarten Lankhorst
2014-09-02 13:47                 ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54049D19.30802@vodafone.de \
    --to=deathsimple@vodafone.de \
    --cc=airlied@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maarten.lankhorst@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.