From: Francisco Jerez <currojerez@riseup.net>
To: Matt Roper <matthew.d.roper@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH v3 1/2] Revert "drm/i915/ehl: Update MOCS table for EHL"
Date: Tue, 12 Nov 2019 15:15:28 -0800 [thread overview]
Message-ID: <87h838znxr.fsf@riseup.net> (raw)
In-Reply-To: <20191112224757.25116-1-matthew.d.roper@intel.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2250 bytes --]
Matt Roper <matthew.d.roper@intel.com> writes:
> This reverts commit f4071997f1de016780ec6b79c63d90cd5886ee83.
>
> These extra EHL entries won't behave as expected without a bit more work
> on the kernel side so let's drop them until that kernel work has had a
> chance to land. Userspace trying to use these new entries won't get the
> advantage of the new functionality these entries are meant to provide,
> but at least it won't misbehave.
>
> When we do add these back in the future, we'll probably want to
> explicitly use separate tables for ICL and EHL so that userspace
> software that mistakenly uses these entries (which are undefined on ICL)
> sees the same behavior it sees with all the other undefined entries.
>
> Cc: Francisco Jerez <francisco.jerez.plata@intel.com>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
I think f4071997f1de016780ec6b79c63d90cd5886ee83 has hit a few kernel
releases already. Wouldn't it make sense to CC stable?
Patch is:
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 6e881c735b20..06e2adbf27be 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -200,14 +200,6 @@ static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
> MOCS_ENTRY(15, \
> LE_3_WB | LE_TC_1_LLC | LE_LRUM(2) | LE_AOM(1), \
> L3_3_WB), \
> - /* Bypass LLC - Uncached (EHL+) */ \
> - MOCS_ENTRY(16, \
> - LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
> - L3_1_UC), \
> - /* Bypass LLC - L3 (Read-Only) (EHL+) */ \
> - MOCS_ENTRY(17, \
> - LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
> - L3_3_WB), \
> /* Self-Snoop - L3 + LLC */ \
> MOCS_ENTRY(18, \
> LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_SSE(3), \
> --
> 2.21.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Francisco Jerez <currojerez@riseup.net>
To: Matt Roper <matthew.d.roper@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [Intel-gfx] [PATCH v3 1/2] Revert "drm/i915/ehl: Update MOCS table for EHL"
Date: Tue, 12 Nov 2019 15:15:28 -0800 [thread overview]
Message-ID: <87h838znxr.fsf@riseup.net> (raw)
Message-ID: <20191112231528.fcsKBHqJX5vBo4t86VumB6NkZY5u1LvMzwqOS1gsKtI@z> (raw)
In-Reply-To: <20191112224757.25116-1-matthew.d.roper@intel.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2250 bytes --]
Matt Roper <matthew.d.roper@intel.com> writes:
> This reverts commit f4071997f1de016780ec6b79c63d90cd5886ee83.
>
> These extra EHL entries won't behave as expected without a bit more work
> on the kernel side so let's drop them until that kernel work has had a
> chance to land. Userspace trying to use these new entries won't get the
> advantage of the new functionality these entries are meant to provide,
> but at least it won't misbehave.
>
> When we do add these back in the future, we'll probably want to
> explicitly use separate tables for ICL and EHL so that userspace
> software that mistakenly uses these entries (which are undefined on ICL)
> sees the same behavior it sees with all the other undefined entries.
>
> Cc: Francisco Jerez <francisco.jerez.plata@intel.com>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
I think f4071997f1de016780ec6b79c63d90cd5886ee83 has hit a few kernel
releases already. Wouldn't it make sense to CC stable?
Patch is:
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 6e881c735b20..06e2adbf27be 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -200,14 +200,6 @@ static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
> MOCS_ENTRY(15, \
> LE_3_WB | LE_TC_1_LLC | LE_LRUM(2) | LE_AOM(1), \
> L3_3_WB), \
> - /* Bypass LLC - Uncached (EHL+) */ \
> - MOCS_ENTRY(16, \
> - LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
> - L3_1_UC), \
> - /* Bypass LLC - L3 (Read-Only) (EHL+) */ \
> - MOCS_ENTRY(17, \
> - LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
> - L3_3_WB), \
> /* Self-Snoop - L3 + LLC */ \
> MOCS_ENTRY(18, \
> LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_SSE(3), \
> --
> 2.21.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-11-12 23:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-12 22:47 [PATCH v3 1/2] Revert "drm/i915/ehl: Update MOCS table for EHL" Matt Roper
2019-11-12 22:47 ` [Intel-gfx] " Matt Roper
2019-11-12 22:47 ` [PATCH v3 2/2] drm/i915/tgl: MOCS table update Matt Roper
2019-11-12 22:47 ` [Intel-gfx] " Matt Roper
2019-11-12 23:20 ` Francisco Jerez
2019-11-12 23:20 ` [Intel-gfx] " Francisco Jerez
2019-11-13 1:09 ` Lucas De Marchi
2019-11-13 1:09 ` [Intel-gfx] " Lucas De Marchi
2019-11-13 12:58 ` Lis, Tomasz
2019-11-13 12:58 ` [Intel-gfx] " Lis, Tomasz
2019-11-12 23:15 ` Francisco Jerez [this message]
2019-11-12 23:15 ` [Intel-gfx] [PATCH v3 1/2] Revert "drm/i915/ehl: Update MOCS table for EHL" Francisco Jerez
2019-11-13 0:32 ` ✓ Fi.CI.BAT: success for series starting with [v3,1/2] " Patchwork
2019-11-13 0:32 ` [Intel-gfx] " Patchwork
2019-11-13 11:49 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-11-13 11:49 ` [Intel-gfx] " Patchwork
2019-11-13 16:39 ` Matt Roper
2019-11-13 16:39 ` [Intel-gfx] " Matt Roper
2019-11-13 16:51 ` [PATCH i-g-t] i915/gem_mocs_settings: Update TGL MOCS table Matt Roper
2019-11-13 16:51 ` [Intel-gfx] " Matt Roper
2019-11-13 21:25 ` Lucas De Marchi
2019-11-13 21:25 ` [Intel-gfx] " Lucas De Marchi
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=87h838znxr.fsf@riseup.net \
--to=currojerez@riseup.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox