From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> To: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org, matthew.auld@intel.com, 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 17:37:46 +0200 [thread overview] Message-ID: <0415be07-452e-d7de-ecfa-9c0f80ad5fee@linux.intel.com> (raw) In-Reply-To: <YNNOoqnFOWw1Xgrf@phenom.ffwll.local> 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 ;) > 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. I'll update the code and resend. /Thomas
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> To: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org, matthew.auld@intel.com, 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 17:37:46 +0200 [thread overview] Message-ID: <0415be07-452e-d7de-ecfa-9c0f80ad5fee@linux.intel.com> (raw) In-Reply-To: <YNNOoqnFOWw1Xgrf@phenom.ffwll.local> 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 ;) > 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. I'll update the code and resend. /Thomas _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-06-23 15:39 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 [this message] 2021-06-23 15:37 ` Thomas Hellström 2021-06-23 16:40 ` Daniel Vetter 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=0415be07-452e-d7de-ecfa-9c0f80ad5fee@linux.intel.com \ --to=thomas.hellstrom@linux.intel.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=matthew.auld@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: linkBe 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.