Xe_HP is more modular than its predecessors and as a consequence it has
more types of replicated registers. As with l3bank regions on previous
platforms, we may need to explicitly re-steer accesses to these new
types of ranges at runtime if we can't find a single default steering
value that satisfies the fusing of all types.
v2:
- Add a local 'i915' variable to reduce gt->i915 usage. (Caz)
- Drop unused 'intel_gt_read_register' prototype. (Caz)
v3:
- Drop unnecessary comment text. (Lucas)
- Drop unused register bit definition. (Lucas)
Bspec: 66534
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Caz Yokoyama <caz.yokoyama@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210729170008.2836648-2-matthew.d.roper@intel.com
As we begin applying XeHP and DG2 patches, the basic platform
definitions and macros (like IS_DG2()) will be needed in both
drm-intel-next and drm-intel-gt-next. Those initial definition patches
are applied to a topic branch and merged to both trees.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Besides the arch version returned by GRAPHICS_VER(), new platforms
contain a "release id" to make clear the difference from one platform to
another.
The release id number is not formally defined by hardware until future
platforms that will expose it via a new GMD_ID register. For the
platforms we support before that register becomes available we will set
the values in software and we can set them as we please. So the plan is
to set them so we can group different features under a single
GRAPHICS_VER_FULL() check.
After GMD_ID is used, the usefulness of a "full version check" will be
greatly reduced and will be mostly used for deciding workarounds and a
few code paths. So it makes sense to keep it as a separate field from
graphics_ver. Also, as a platform with `release == n` may be closer
feature-wise to `n - 2` than to `n - 1`, use the word "release" rather
than the more common "minor" for this
This is a mix of 2 independent changes: one by me and the other by Matt
Roper.
v2:
- Reword commit message to make it clearer why we don't call it
"minor" (Matt Roper and Tvrtko)
- Rename variables s/*_ver_release/*_rel/ and print them in a single
line formatted as {ver}.{rel:2} (Jani and Matt Roper)
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210707235921.2416911-2-lucas.demarchi@intel.com
(cherry picked from commit ca6374e267)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Besides the arch version returned by GRAPHICS_VER(), new platforms
contain a "release id" to make clear the difference from one platform to
another.
The release id number is not formally defined by hardware until future
platforms that will expose it via a new GMD_ID register. For the
platforms we support before that register becomes available we will set
the values in software and we can set them as we please. So the plan is
to set them so we can group different features under a single
GRAPHICS_VER_FULL() check.
After GMD_ID is used, the usefulness of a "full version check" will be
greatly reduced and will be mostly used for deciding workarounds and a
few code paths. So it makes sense to keep it as a separate field from
graphics_ver. Also, as a platform with `release == n` may be closer
feature-wise to `n - 2` than to `n - 1`, use the word "release" rather
than the more common "minor" for this
This is a mix of 2 independent changes: one by me and the other by Matt
Roper.
v2:
- Reword commit message to make it clearer why we don't call it
"minor" (Matt Roper and Tvrtko)
- Rename variables s/*_ver_release/*_rel/ and print them in a single
line formatted as {ver}.{rel:2} (Jani and Matt Roper)
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210707235921.2416911-2-lucas.demarchi@intel.com
Now that it's not used anywhere, remove it from struct
intel_device_info. To allow a period in which code will be converted to
the new macro, keep IS_GEN_RANGE() around, just redefining it to use
the new fields. The size advantage from IS_GEN_RANGE() using a mask is
not that big as it has pretty limited use througout the driver:
text data bss dec hex filename
2758497 95965 6496 2860958 2ba79e drivers/gpu/drm/i915/i915.ko.old
2758586 95953 6496 2861035 2ba7eb drivers/gpu/drm/i915/i915.ko.new
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor code comment change while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-9-lucas.demarchi@intel.com
Like it was done in
commit 01eb15c916 ("drm/i915: Add DISPLAY_VER() and related macros")
add the correspondent macros for graphics and media. Going forward we
will prefer checking the versions for the specific IPs (graphics, media
and display) rather than grouping everything under a "gen" version.
For consistency and to make the maintenance easier, it'd be preferred
not to mix the *GEN* macros with the new ones. For older platforms we
can simply consider that the previous "gen" number will extend to all
3 IPs. Then we can start replacing its use in the driver. Right now this
replacement is not done and only the infrastructure is put in place.
We also leave gen and gen_mask inside struct intel_device_info while
it's still being used throughout the code.
v2: Repurpose IS_{GRAPHICS,MEDIA}_VER() macros to work with a range
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[Jani: Minor code comment change while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-5-lucas.demarchi@intel.com
The macro we use to check is called DISPLAY_VER(). While using this
macro and the new ones being added in following changes I made the
mistake multiple times when mixing both "ver" and "version". Although
it's usually better to prefer the complete name, the shorhand
DISPLAY_VER() / GRAPHICS_VER / MEDIA_VER are clear and cause less
visual polution.
Another issue is when copying the variable to other places.
"display.version" would be copied to a "display_version" variable which
is long and would make people abbreviate as "version", or "display_ver".
In the first case it's not always clear what version refers to, and in
the second case it just hints it should be the name in the first place.
So, in the same way use used "gen" rather than "generation", use "ver"
instead of "version".
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-3-lucas.demarchi@intel.com
Add new runtime info field for stepping. Add new helpers for accessing
them. As we'll be switching platforms over to the new scheme
incrementally, check for non-initialized steppings.
In case a platform does not have separate display and gt steppings, it's
okay to use a common shorthand. However, in this case the display
stepping must not be initialized, and gt stepping is the single point of
truth.
v3: Remove IS_STEP() (José)
v2: Rename stepping->step
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bb4275733fa390ea3dbf6f62794d55b616665230.1616764798.git.jani.nikula@intel.com
Although we've long referred to platforms by a single "GEN" number, the
hardware teams have recommended that we stop doing this since the
various component IP blocks are going to start using independent number
schemes with varying cadence. To support this, hardware platforms a bit
down the road are going to start providing MMIO registers that the
driver can read to obtain the "graphics version," "media version," and
"display version" without needing to do a PCI ID -> platform -> version
translation.
Although our current platforms don't yet expose these registers (and the
next couple we release probably won't have them yet either), the
hardware teams would still like to see us move to this independent
numbering scheme now in preparation. For i915 that means we should try
to eliminate all usage of INTEL_GEN() throughout our code and instead
replace it with separate GRAPHICS_VER(), MEDIA_VER(), and DISPLAY_VER()
constructs in the code. For old platforms, these will all usually give
the same value for each IP block (aside from a few special cases like
GLK which we can no more accurately represent as graphics=9 +
display=10), but future platforms will have more flexibility to bump IP
version numbers independently.
The upcoming ADL-P platform will have a display version of 13 and a
graphics version of 12, so let's just the first step of breaking out
DISPLAY_VER(), but leaving the rest of INTEL_GEN() untouched for now.
For now we'll automatically derive the display version from the
platform's INTEL_GEN() value except in cases where an alternative
display version is explicitly provided in the device info structure.
We also add some helper macros IS_DISPLAY_VER(i915, ver) and
IS_DISPLAY_RANGE(i915, from, until) that match the behavior of the
existing gen-based macros. However unlike IS_GEN(), we will implement
those macros with direct comparisons rather than trying to maintain a
mask to help compiler optimization. In practice the optimization winds
up not being used in very many places (since the vast majority of our
platform checks are of the form "gen >= x") so there is pretty minimal
size reduction in the final driver binary[1]. We're also likely going
to need to extend these version numbers to non-integer major.minor
values at some point in the future, so the mask approach won't work at
all once we get to platforms like that.
[1] The results before/after the next patch in this series, which
switches our code over to the new display macros:
$ size i915.ko.{orig,new}
text data bss dec hex filename
2940291 102944 5384 3048619 2e84ab i915.ko.orig
2940723 102956 5384 3049063 2e8667 i915.ko.new
v2:
- Move version into device info's display sub-struct. (Jani)
- Add extra parentheses to macros. (Jani)
- Note the lack of genmask optimization in the display-based macros and
give size data. (Lucas)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-3-matthew.d.roper@intel.com
Although the bspec's description doesn't make it very clear, the
hardware architects have confirmed that the FPGA_DBG register that we
use to check for unclaimed MMIO accesses is display-specific and will
only properly flag unclaimed MMIO transactions for registers in the
display range. If a platform doesn't have display, FPGA_DBG itself will
not be available and should not be checked. Let's move the feature flag
into intel_device_info.display to more accurately reflect this.
Given that we now know FPGA_DBG is display-specific, it could be argued
that we should only check it on out intel_de_*() functions. However
let's not make that change right now; keeping the checks in all of the
existing locations still helps us catch cases where regular
intel_uncore_*() functions use bad MMIO offset math / base addresses and
accidentally wind up landing within an unused area within the display
MMIO range. It will also help catch cases where userspace-initiated
MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the
display range.
v2: Add missing hunk with the update to the HAS_FPGA_DBG_UNCLAIMED
macro. (CI)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210212222049.3516344-1-matthew.d.roper@intel.com
- Add the initial platform information for Alderlake-S.
- Specify ppgtt_size value
- Add dma_mask_size
- Add ADLS REVIDs
- HW tracking(Selective Update Tracking Enable) has been
removed from ADLS. Disable PSR2 till we enable software/
manual tracking.
v2:
- Add support for different ADLS SOC steppings to select
correct GT/DISP stepping based on Bspec 53655 based on
feedback from Matt Roper.(aswarup)
v3:
- Make display/gt steppings info generic for reuse with TGL and ADLS.
- Modify the macros to reuse tgl_revids_get()
- Add HTI support to adls device info.(mdroper)
v4:
- Rebase on TGL patch for applying WAs based on stepping info from
Matt Roper's feedback.(aswarup)
v5:
- Replace macros with PCI IDs in revid to stepping table.
v6: remove stray adls_revids (Lucas)
Bspec: 53597
Bspec: 53648
Bspec: 53655
Bspec: 48028
Bspec: 53650
BSpec: 50422
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119192931.1116500-2-lucas.demarchi@intel.com
The reason why we did not enable preemption on Broadwater was due to
missing GPGPU workarounds. Since this only applies to rcs0, only
restrict rcs0 (and our global capabilities).
While this does not affect exposing a preemption capability to
userspace, it does affect our internal decisions on whether to use
timeslicing and semaphores between individual engines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-6-chris@chris-wilson.co.uk
If HTI (also sometimes called HDPORT) is enabled at startup, it may be
using some of the PHYs and DPLLs making them unavailable for general
usage. Let's read out the HDPORT_STATE register and avoid making use of
resources that HTI is already using.
v2:
- Fix minor checkpatch warnings
v3:
- Just readout HDPORT_STATE register once during init and then parse it
later as needed.
- Add a 'has_hti' device info flag to track whether we should readout
HDPORT_STATE or not. We can skip the platform/flag tests later since
the hti_state in dev_priv will remain 0 for platforms it does not
apply to.
- Move PLL masking into icl_get_combo_phy_dpll() since at the moment
RKL is the only platform that has HTI. (Jose)
Bspec: 49189
Bspec: 53707
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-5-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rocket Lake uses the same 'abox0' mechanism to handle pixel data
transfers from memory that gen11 platforms used, rather than the
abox1/abox2 interfaces used by TGL/DG1. For the most part this is a
hardware implementation detail that's transparent to driver software,
but we do have to program a couple of tuning registers (MBUS_ABOX_CTL
and BW_BUDDY registers) according to which ABOX instances are used by a
platform. Let's track the platform's ABOX usage in the device info
structure and use that to determine which instances of these registers
to program.
As an exception to this rule is that even though TGL/DG1 use ABOX1+ABOX2
for data transfers, we're still directed to program the ABOX_CTL
register for ABOX0; so we'll handle that as a special case.
v2:
- Store the mask of platform-specific abox registers in the device
info structure.
- Add a TLB_REQ_TIMER() helper macro. (Aditya)
v3:
- Squash ABOX and BW_BUDDY patches together and use a single mask for
both of them, plus a special-case for programming the ABOX0 instance
on all gen12. (Ville)
Bspec: 50096
Bspec: 49218
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200606025740.3308880-2-matthew.d.roper@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP
which will be useful for us in cases when we are not able to track context
busyness ourselves (like with GuC). Keep a copy of this in struct
intel_context from where it can be easily read even if the context is not
pinned.
v2:
(Chris)
* Do not store pphwsp address in intel_context.
* Log CS wrap-around.
* Simplify calculation by relying on integer wraparound.
v3:
* Include total/avg in traces and error state for debugging
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200216133620.394962-1-chris@chris-wilson.co.uk
Start manipulating DBuf slices as a mask,
but not as a total number, as current approach
doesn't give us full control on all combinations
of slices, which we might need(like enabling S2
only can't enabled by setting enabled_slices=1).
Removed wrong code from intel_get_ddb_size as
it doesn't match to BSpec. For now still just
use DBuf slice until proper algorithm is implemented.
Other minor code refactoring to get prepared
for major DBuf assignment changes landed:
- As now enabled slices contain a mask
we still need some value which should
reflect how much DBuf slices are supported
by the platform, now device info contains
num_supported_dbuf_slices.
- Removed unneeded assertion as we are now
manipulating slices in a more proper way.
v2: Start using enabled_slices in dev_priv
v3: "enabled_slices" is now "enabled_dbuf_slices_mask",
as this now sits in dev_priv independently.
v4: - Fixed debug print formatting to hex(Matt Roper)
- Optimized dbuf slice updates to be used only
if slice union is different from current conf(Matt Roper)
- Fixed some functions to be static(Matt Roper)
- Created a parameterized version for DBUF_CTL to
simplify DBuf programming cycle(Matt Roper)
- Removed unrequred field from GEN10_FEATURES(Matt Roper)
v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä)
- Started to use parameterized loop for hw readout to get slices
(Ville Syrjälä)
- Added back assertion checking amount of DBUF slices enabled
after DC states 5/6 transition, also added new assertion
as starting from ICL DMC seems to restore the last DBuf
power state set, rather than power up all dbuf slices
as assertion was previously expecting(Ville Syrjälä)
v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä)
- Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled
back, as we really need to have a single unified assert here
however currently enabling always slice 1 is enforced by BSpec,
so we will have to OR enabled slices mask with 1 in order
to be consistent with BSpec, that way we can unify that
assertion and against the actual state from the driver, but
not some hardcoded value.(concluded with Ville)
- Remove parameterized DBUF_CTL version, to extract it to another
patch.(Ville Syrjälä)
v7:
- Removed unneeded hardcoded return value for older gens from
intel_enabled_dbuf_slices_mask - this now is handled in a
unified manner since device info anyway returns max dbuf slices
as 1 for older platforms(Matthew Roper)
- Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead
of intel_dbuf_max_slices function as it is trivial(Matthew Roper)
v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä)
v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä)
- Now using power_domain mutex to protect from race condition, which
can occur because intel_dbuf_slices_update might be running in
parallel to gen9_dc_off_power_well_enable being called from
intel_dp_detect for instance, which causes assertion triggered by
race condition, as gen9_assert_dbuf_enabled might preempt this
when registers were already updated, while dev_priv was not.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-6-stanislav.lisovskiy@intel.com
