All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Update object placement flags to be mutable
Date: Wed, 23 Jun 2021 18:40:20 +0200	[thread overview]
Message-ID: <CAKMK7uGnyGSqXjuMFid4vFkgQMhjRDt+1HdoLTsE3aSqp6A4Yw@mail.gmail.com> (raw)
In-Reply-To: <0415be07-452e-d7de-ecfa-9c0f80ad5fee@linux.intel.com>

On Wed, Jun 23, 2021 at 5:38 PM Thomas Hellström
<thomas.hellstrom@linux.intel.com> wrote:
>
> Thanks for reviewing, Daniel.
>
> On 6/23/21 5:09 PM, Daniel Vetter wrote:
> >
> >>
> >> +    unsigned int mem_flags:2;
> > Is the entire bitfield array all protected by dma_resv_lock? If not I'd
> > just go with a full field, avoids headaches and all that.
> >
> > Also kerneldoc for this would be really sweet. Means some work to get it
> > going,
>
> Yeah, late documentation review comments after v9 ought to be forbidden ;)

Well I think we should have locking and all that documented from the
start maybe :-P

But yeah I know it's a bit late, so totally fine if that's done as a
follow up on top. But for new stuff or revised stuff we need to start
somewhere, and "maybe later when we have time" just never cuts it ...

>
> > but somewhere we need to stop hacking together undocumented ad-hoc
> > locking schemes :-/
>
> Hmm, this was intended to replace the change of and access of object ops
> *without* the lock held and with proper asserts added in the accessors,
> so it was not really intended to be an ad-hoc locking scheme, It's
> simply placement related things are updated under the lock.

Yeah this was more meant as a general comment. E.g. in struct i915_vma
we now have the situation that we have 2 overlapping locking schemes,
and it's almost impossible to figure out which is infect for which
pieces. I'd like to avoid that if at all possible.

> I'll update the code and resend.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Update object placement flags to be mutable
Date: Wed, 23 Jun 2021 18:40:20 +0200	[thread overview]
Message-ID: <CAKMK7uGnyGSqXjuMFid4vFkgQMhjRDt+1HdoLTsE3aSqp6A4Yw@mail.gmail.com> (raw)
In-Reply-To: <0415be07-452e-d7de-ecfa-9c0f80ad5fee@linux.intel.com>

On Wed, Jun 23, 2021 at 5:38 PM Thomas Hellström
<thomas.hellstrom@linux.intel.com> wrote:
>
> Thanks for reviewing, Daniel.
>
> On 6/23/21 5:09 PM, Daniel Vetter wrote:
> >
> >>
> >> +    unsigned int mem_flags:2;
> > Is the entire bitfield array all protected by dma_resv_lock? If not I'd
> > just go with a full field, avoids headaches and all that.
> >
> > Also kerneldoc for this would be really sweet. Means some work to get it
> > going,
>
> Yeah, late documentation review comments after v9 ought to be forbidden ;)

Well I think we should have locking and all that documented from the
start maybe :-P

But yeah I know it's a bit late, so totally fine if that's done as a
follow up on top. But for new stuff or revised stuff we need to start
somewhere, and "maybe later when we have time" just never cuts it ...

>
> > but somewhere we need to stop hacking together undocumented ad-hoc
> > locking schemes :-/
>
> Hmm, this was intended to replace the change of and access of object ops
> *without* the lock held and with proper asserts added in the accessors,
> so it was not really intended to be an ad-hoc locking scheme, It's
> simply placement related things are updated under the lock.

Yeah this was more meant as a general comment. E.g. in struct i915_vma
we now have the situation that we have 2 overlapping locking schemes,
and it's almost impossible to figure out which is infect for which
pieces. I'd like to avoid that if at all possible.

> I'll update the code and resend.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-06-23 16:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 19:36 [PATCH v6 0/3] drm/i915: Move system memory to TTM for discrete Thomas Hellström
2021-06-21 19:36 ` [Intel-gfx] " Thomas Hellström
2021-06-21 19:36 ` [PATCH v6 1/3] drm/i915: Update object placement flags to be mutable Thomas Hellström
2021-06-21 19:36   ` [Intel-gfx] " Thomas Hellström
2021-06-23 15:09   ` Daniel Vetter
2021-06-23 15:09     ` Daniel Vetter
2021-06-23 15:37     ` Thomas Hellström
2021-06-23 15:37       ` Thomas Hellström
2021-06-23 16:40       ` Daniel Vetter [this message]
2021-06-23 16:40         ` Daniel Vetter
2021-06-21 19:36 ` [PATCH v6 2/3] drm/i915/ttm: Adjust gem flags and caching settings after a move Thomas Hellström
2021-06-21 19:36   ` [Intel-gfx] " Thomas Hellström
2021-06-21 19:36 ` [PATCH v6 3/3] drm/i915/ttm: Use TTM for system memory Thomas Hellström
2021-06-21 19:36   ` [Intel-gfx] " Thomas Hellström
2021-06-21 20:39 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move system memory to TTM for discrete (rev6) Patchwork
2021-06-21 20:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-21 22:56 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=CAKMK7uGnyGSqXjuMFid4vFkgQMhjRDt+1HdoLTsE3aSqp6A4Yw@mail.gmail.com \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=thomas.hellstrom@linux.intel.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.