Age | Commit message (Collapse) | Author |
|
With display code using the struct drm_device based pcode interface, we
can drop the old pcode compat interface.
We can also drop the __compat_uncore_to_tile() helper from
intel_uncore.h compat header.
Turns out a couple of headers depended on the intel_uncore.h include via
intel_pcode.h. Fix them.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/948016a031dcb2acef0c97071aac09fa49613e07.1750678991.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
With the struct drm_device based pcode interface in place in both i915
and xe, we can switch dram code to use that.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/e0d74a3317cc61d1cbb096b962cfbd7c60f038d4.1750678991.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Allocate struct drm_info dynamically, and convert the struct
drm_i915_private and struct xe_device dram_info member into a const
pointer. Move the struct definition to intel_dram.h, and keep it opaque
to everyone not needing it. This also removes the duplication of the
struct definition.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://lore.kernel.org/r/73625095157346ea0e8614108c9b369208e5df66.1748337870.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
We'll want to start returning errors from intel_dram_detect(). As the
first step, add the return value and error handling, even if we still
only return 0.
Do no functional changes, but leave a comment about whether we should
bail out on dram detection failures.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://lore.kernel.org/r/be2c31c459fb95d8161b719d499403eea5ec17b7.1748337870.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Figure out the struct dram_info pointer in one place, and pass that
around to be filled in, instead of all places poking at i915->dram_info
directly.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://lore.kernel.org/r/8ac6b308b210cf4a429d5abfb9bf32737dcab51f.1748337870.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add a function to get the (const) pointer to struct dram_info, and use
that to obtain the pointer instead of poking at i915->dram_info
directly.
Clean up a couple of local variables while at it.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://lore.kernel.org/r/4174edf649e2f6805dab6fd6ce2ec10f4e5f2498.1748337870.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Make i915->display pointer opaque to most of core i915 driver. Lots of
places now need explicit include of intel_display_core.h, or a more
specific header.
With this dependency broken, changes in display should cause radically
less recompilation of i915.
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://lore.kernel.org/r/b381b59acb7e4f600e0282935a68aedf77768109.1747907216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
With users both in i915 core and display, struct drm_device is the
common denominator for the VLV IOSF SB users. Also use drm_device for
the helpers on the display side to keep the static inlines as simple as
possible.
We can drop a number of dependencies on i915_drv.h with this.
v2,v3: Rebase
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/c1d013ed88ce2e3e5bdc15ce3bf01a3960b1e817.1747061743.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
We'll want to relocate the unit specific functions to display, making
them inaccessible to i915 core. As there aren't that many users in i915
core, we can just convert them to the generic VLV IOSF SB read/write
functions.
v2: Use BIT(unit) for get/put
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/3162c8768eeeba928bbc3d4aa2ddfc6a1030a451.1747061743.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Be more specific in the naming, and follow the existing function naming
pattern of vlv_iosf_sb_*() in the file.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/d3d97d34a197ba801c558c3fd72b29f9e5c783af.1747061743.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Instead of logging the dram type in the per version/platform function,
do it in the generic one. This fixes a few discrepancies depending on
the platform:
- There was no DRAM type logging for graphics version 12 and
above
- For graphics version 11, it would log the DRAM type in
skl_get_dram_info(), but could possibly override it later
without any log in icl_pcode_read_mem_global_info()
For bxt_get_dram_info(), there's no need to log the type for each dimm,
as the drm_WARN_ON() already covers the case they are not all the same.
This maintains the behavior of skl_get_dram_info() that would log the
DRAM type even on failures.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20250324-dram-type-v1-2-bf60ef33ac01@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Some new dram types were added without adding the corresponding string
conversion, probably because it's not being used by recent platforms.
Add them, together with a BUILD_BUG_ON() to ensure it keeps in sync, in
preparation to make use of them in recent platforms.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20250324-dram-type-v1-1-bf60ef33ac01@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Some SKUs of Xe2_HPD platforms (such as BMG) have GDDR memory type
with ECC enabled. We need to identify this scenario and add a new
case in xelpdp_get_dram_info() to handle it. In addition, the
derating value needs to be adjusted accordingly to compensate for
the limited bandwidth.
Bspec: 64602
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 3adcf970dc7e ("drm/xe/bmg: Drop force_probe requirement")
Cc: stable@vger.kernel.org
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324-tip-v2-1-38397de319f8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Replace IS_GEN9_LP() and IS_GEN9_BC() with direct platform checks. This
lets us remove their compat counterparts, as neither soc/ nor /display
now no longer needs them.
v2: Use !A && !B instead of !(A || B) (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> # v1
Link: https://patchwork.freedesktop.org/patch/msgid/20240930124056.3541988-2-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Move the comment about FSB straps to where the relevant register is
read.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8a5b6cd3db80259c30263861f1a9ff04fea2e7f0.1718356614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Reuse i9xx_fsb_freq() for GT clock frequency initialization instead of
depending on rawclk_freq.
Note: If the init order was changed, we could use i915->fsb_freq
directly. However, GT clock initialization is done in
i915_driver_mmio_probe(), but intel_dram_detect() later in
i915_driver_hw_probe(), with a dependency on intel_pcode_init().
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0678d8ec9772725b47d4fa5b14e3b3a34256d5cf.1718356614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Initialize fsb frequency for more platforms to be able to use it for GT
clock and rawclk frequency initialization.
Note: There's a discrepancy between existing pnv_fsb_freq() and
i9xx_hrawclk() regarding CLKCFG interpretation. Presume all PNV is
mobile.
Default to 1333 MHz for unknown values, similar to i9xx_hrawclk().
v2:
- Add MISSING_CASE() (Ville)
- Default to the same frequency for both branches (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7cd6dbd4dafb900ac1dd12be0ec096ff1d5fc6cf.1718356614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
We'll want to use fsb frequency for deriving GT clock and rawclk
frequencies in the future. Increase the accuracy by converting to
kHz. Do the same for mem freq to be aligned.
Round the frequencies ending in 666 to 667.
v2: Also handle mem_freq in gen5_rps_init() (Ville)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/17fe2544b876549f63fac0f956273f5f282081b3.1718356614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Follow the same style in mem freq init as in fsb freq init, returning
the value instead of assigning in multiple places.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f098ccdbb0c42016d5dad81e0b089bb4babe29f0.1718356614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Split out the PNV DDR3 detection to a distinct step instead of
conflating it with mem freq detection.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c4bf9d32479ab5024e9daa37a996508f543f05e9.1718356614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
To simplify further changes, add separate functions for reading the fsb
frequency.
This ends up reading CLKCFG register twice, but it's not a big deal.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7582651aa21ac2c1472111c4e81ba8fee182f80e.1718356614.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Unlike DG2, Xe2_HPD does support multiple GV points with different
maximum memory bandwidths, but uses a much simpler algorithm than igpu
platforms use.
Bspec: 64631
CC: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-12-radhakrishna.sripada@intel.com
|
|
For debug purposes we need those - error path won't flood the log,
however there has been already numerous cases, when due to lack
of debugs, we couldn't immediately tell what was the problem on
customer machine, which slowed down the investigation, requiring
to get access to target device and adding those traces manually.
v2: - Make the debug more generic and move it to intel_dram_detect
(Gustavo Sousa)
v3: - Use %u for unsigned variable in debug prints (Gustavo)
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-2-vinod.govindapillai@intel.com
|
|
The __raw_uncore_* interface is supposed to be intel_uncore.[ch]
internal only. Replace the remaining outside user with
intel_uncore_read_fw(), which is essentially the same thing.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230627105849.274263-1-jani.nikula@intel.com
|
|
The memory frequency detection is a bit spread out here and
there. Consolidate to intel_dram.c.
v2:
- Remove inaccurate comment (Ville)
- Call detect_mem_freq() unconditionally (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8a862eeca8b42a98e04b3c52637851d33531abb6.1676317696.git.jani.nikula@intel.com
|
|
Add a new sub-directory for things that aren't specifically about the
GPU and don't really belong in the i915 driver top level, but also don't
belong under any of the existing sub-directories either.
Name it "soc", and move the PCH and DRAM code there.
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208142347.602726-1-jani.nikula@intel.com
|