Re: [Intel-gfx] [PATCH 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v6)
On Wed, Feb 09, 2022 at 01:47:01AM +, Kasireddy, Vivek wrote:
> Hi Ville,
>
> >
> > On Tue, Feb 08, 2022 at 05:10:42AM +, Kasireddy, Vivek wrote:
> > > Hi Tvrtko, Ville,
> > >
> > > > On 07/02/2022 13:24, Ville Syrjälä wrote:
> > > > > On Mon, Feb 07, 2022 at 11:47:16AM +, Tvrtko Ursulin wrote:
> > > > >>
> > > > >> On 07/02/2022 10:58, Ville Syrjälä wrote:
> > > > >>> On Thu, Feb 03, 2022 at 05:22:10PM -0800, Vivek Kasireddy wrote:
> > > > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2
> > > > or more framebuffers/scanout buffers results in only one that is
> > > > mappable/ fenceable. Therefore, pageflipping between these 2 FBs
> > > > where only one is mappable/fenceable creates latencies large enough
> > > > to miss alternate vblanks thereby producing less optimal framerate.
> > > >
> > > > This mainly happens because when
> > > > i915_gem_object_pin_to_display_plane()
> > > > is called to pin one of the FB objs, the associated vma is
> > > > identified as misplaced and therefore i915_vma_unbind() is called
> > > > which unbinds and evicts it. This misplaced vma gets subseqently
> > > > pinned only when
> > > > i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
> > > > results in a latency of ~10ms and happens every other
> > > > vblank/repaint cycle.
> > > > Therefore, to fix this issue, we try to see if there is space to
> > > > map at-least two objects of a given size and return early if there
> > > > isn't. This would ensure that we do not try with PIN_MAPPABLE for
> > > > any objects that are too big to map thereby preventing unncessary
> > > > unbind.
> > > >
> > > > Testcase:
> > > > Running Weston and weston-simple-egl on an Alderlake_S (ADLS)
> > > > platform with a 8K@60 mode results in only ~40 FPS. Since upstream
> > > > Weston submits a frame ~7ms before the next vblank, the latencies
> > > > seen between atomic commit and flip event are 7, 24 (7 + 16.66), 7,
> > > > 24. suggesting that it misses the vblank every other frame.
> > > >
> > > > Here is the ftrace snippet that shows the source of the ~10ms
> > > > latency:
> > > > i915_gem_object_pin_to_display_plane() {
> > > > 0.102 us |i915_gem_object_set_cache_level();
> > > > i915_gem_object_ggtt_pin_ww() {
> > > > 0.390 us | i915_vma_instance();
> > > > 0.178 us | i915_vma_misplaced();
> > > > i915_vma_unbind() {
> > > > __i915_active_wait() {
> > > > 0.082 us |i915_active_acquire_if_busy();
> > > > 0.475 us | }
> > > > intel_runtime_pm_get() {
> > > > 0.087 us |intel_runtime_pm_acquire();
> > > > 0.259 us | }
> > > > __i915_active_wait() {
> > > > 0.085 us |i915_active_acquire_if_busy();
> > > > 0.240 us | }
> > > > __i915_vma_evict() {
> > > > ggtt_unbind_vma() {
> > > > gen8_ggtt_clear_range() {
> > > > 10507.255 us |}
> > > > 10507.689 us | }
> > > > 10508.516 us | }
> > > >
> > > > v2: Instead of using bigjoiner checks, determine whether a scanout
> > > > buffer is too big by checking to see if it is possible to map
> > > > two of them into the ggtt.
> > > >
> > > > v3 (Ville):
> > > > - Count how many fb objects can be fit into the available holes
> > > > instead of checking for a hole twice the object size.
> > > > - Take alignment constraints into account.
> > > > - Limit this large scanout buffer check to >= Gen 11 platforms.
> > > >
> > > > v4:
> > > > - Remove existing heuristic that checks just for size. (Ville)
> > > > - Return early if we find space to map at-least two objects.
> > > > (Tvrtko)
> > > > - Slightly update the commit message.
> > > >
> > > > v5: (Tvrtko)
> > > > - Rename the function to indicate that the object may be too big to
> > > > map into the aperture.
> > > > - Account for guard pages while calculating the total size required
> > > > for the object.
> > > > - Do not subject all objects to the heuristic check and instead
> > > > consider objects only of a certain size.
> > > > - Do the hole walk using the rbtree.
> > > > - Preserve the existing PIN_NONBLOCK logic.
> > > > - Drop the PIN_MAPPABLE check while pinning the VMA.
> > > >
> > > > v6: (Tvrtko)
> > > > - Return 0 on success and the specific error code on failure to
> > > > preserve the existing behavior.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Maarten Lankhorst
> > > >
Re: [Intel-gfx] [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API
A cover letter with the changelog, the base and maybe a pointer to a git
tree would be nice.
> +static int handle_mmio_cb(struct intel_gvt_mmio_table_iter *iter, u32 offset,
> + u32 device, u32 size)
> +{
> + if (size < 1024 || offset == i915_mmio_reg_offset(GEN9_GFX_MOCS(0)))
> + return handle_mmio(iter, offset, device, size);
> + else
> + return handle_mmio_block(iter, offset, device, size);
> +}
No need for an else statement after a return statement.
> +/* XXX FIXME i915 has changed PP_XXX definition */
Btw, can someone explain this comment? I has always puzzled me.
Re: [Intel-gfx] [PATCH v6 3/3] i915/gvt: Use the initial HW state snapshot saved in i915
On Tue, Feb 08, 2022 at 06:11:51AM -0500, Zhi Wang wrote: > The code of saving initial HW state snapshot has been moved into i915. > Let the GVT-g core logic use that snapshot. Looks good: Reviewed-by: Christoph Hellwig
Re: [Intel-gfx] [PATCH v6 2/3] i915/gvt: Save the initial HW state snapshot in i915
On Tue, Feb 08, 2022 at 06:11:50AM -0500, Zhi Wang wrote:
> + struct drm_i915_private *dev_priv = iter->i915;
> + u32 *mmio, i;
> +
> + for (i = offset; i < offset + size; i += 4) {
> + mmio = iter->data + i;
> + *mmio = intel_uncore_read_notrace(to_gt(dev_priv)->uncore,
> + _MMIO(i));
This reads much stranger than:
u32 *mmio = iter->data;
for (i = offset; i < offset + size; i += 4) {
mmio[i] = intel_uncore_read_notrace(to_gt(dev_priv)->uncore,
_MMIO(i));
}
> +static int handle_mmio(struct intel_gvt_mmio_table_iter *iter,
> +u32 offset, u32 device, u32 size)
> +{
> + if (WARN_ON(!IS_ALIGNED(offset, 4)))
> + return -EINVAL;
Shouldn't this be in the caller of the method?
> + save_mmio(iter, offset, size);
> + return 0;
Now that the block callback is gone save_mmio and handle_mmio
can be merged.
> + mem = vzalloc(2 * SZ_1M);
Don't we want a driver-wide constant for this instead of a magic number?
Re: [Intel-gfx] [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API
On Tue, Feb 08, 2022 at 05:15:00PM +0200, Jani Nikula wrote: > > #ifdef CONFIG_DRM_I915_GVT > > + > > +#define D_BDW (1 << 0) > > +#define D_SKL (1 << 1) > > +#define D_KBL (1 << 2) > > +#define D_BXT (1 << 3) > > +#define D_CFL (1 << 4) > > + > > +#define D_GEN9PLUS (D_SKL | D_KBL | D_BXT | D_CFL) > > +#define D_GEN8PLUS (D_BDW | D_SKL | D_KBL | D_BXT | D_CFL) > > + > > +#define D_SKL_PLUS (D_SKL | D_KBL | D_BXT | D_CFL) > > +#define D_BDW_PLUS (D_BDW | D_SKL | D_KBL | D_BXT | D_CFL) > > + > > +#define D_PRE_SKL (D_BDW) > > +#define D_ALL (D_BDW | D_SKL | D_KBL | D_BXT | D_CFL) > > If these really need to be in a header in i915/, I think they need to be > longer with some namespacing or something. I do wish these could be > hidden though. I think we could actually kill them off entirely. They are used as arguments to the macros that setup the mmio table. Thefunctions to build these tabls are already organized by families, so we'd need relatively few conditions to just build them the right way. There also are some runtime checks in the callbacks, but they seem entirely superflous as far as I can tell. Only the cmd parser is a bit messy. So maybe we could keep these constants just for the cmd parser inside of gvt for now (and clean that up later) and remove them entirely from the mmio table.
[Intel-gfx] ✗ Fi.CI.BAT: failure for Use drm_clflush* instead of clflush (rev6)
== Series Details ==
Series: Use drm_clflush* instead of clflush (rev6)
URL : https://patchwork.freedesktop.org/series/99450/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22218
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22218 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22218, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/index.html
Participating hosts (46 -> 42)
--
Missing(4): fi-kbl-soraka fi-bsw-cyan shard-tglu fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22218:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22218 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-cfl-8109u: [PASS][3] -> [DMESG-WARN][4] ([i915#262] / [i915#295])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][5] -> [INCOMPLETE][6] ([i915#4547])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#4269])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#295]) +14
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: [DMESG-WARN][11] -> [DMESG-WARN][12] ([i915#1610])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-apl-guc/igt@debugfs_test@read_all_entries.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/fi-apl-guc/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][13] ([i915#4957]) -> [DMESG-FAIL][14]
([i915#4494] / [i915#4957])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22218/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
Build changes
-
* Linux: CI_DRM_11205 -> Patchwork_22218
CI-20190529: 20190529
CI_DRM_11205: c764a7571bebed03bec481d6fffcb23144fe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22218: 1808b1f8eb7aedff2794e6f003f3bf2809cb012c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1808b1f8eb7a drm/i915/gt: replace cache_clflush_range
315ba5405322 drm/i915/: Re-work clflush_write32
5027b028fdc4 drm/i915/gt: Re-work
Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Use a single pass to calculate regset
On Tue, Feb 08, 2022 at 05:15:02PM -0800, Daniele Ceraolo Spurio wrote: On 2/7/2022 11:01 PM, Lucas De Marchi wrote: The ADS initialitazion was using 2 passes to calculate the regset sent to GuC to initialize each engine: the first pass to just have the final object size and the second to set each register in place in the final gem object. However in order to maintain an ordered set of registers to pass to guc, each register needs to be added and moved in the final array. The second phase may actually happen in IO memory rather than system memory and accessing IO memory by simply dereferencing the pointer doesn't work on all architectures. Other places of the ADS initializaition were converted to use the iosys_map API, but here there may be a lot more accesses to IO memory. So, instead of following that same approach, convert the regset initialization to calculate the final array in 1 pass and in the second pass that array is just copied to its final location, updating the pointers for each engine written to the ADS blob. One important thing is that struct temp_regset now have different semantics: `registers` continues to track the registers of a single engine, however the other fields are updated together, according to the newly added `storage`, which tracks the memory allocated for all the registers. So rename some of these fields and add a __mmio_reg_add(): this function (possibly) allocates memory and operates on the storage pointer while guc_mmio_reg_add() continues to manage the registers pointer. On a Tiger Lake system using enable_guc=3, the following log message is now seen: [ 187.334310] i915 :00:02.0: [drm:intel_guc_ads_create [i915]] Used 4 KB for temporary ADS regset This change has also been tested on an ARM64 host with DG2 and other discrete graphics cards. v2 (Daniele): - Fix leaking tempset on error path - Add comments on struct temp_regset to document the meaning of each field Cc: Matt Roper Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi Reviewed-by: Daniele Ceraolo Spurio Thanks for the review. Applied to drm-intel-gt-next. Lucas De Marchi
Re: [Intel-gfx] [PATCH v3] drm/i915/dg2: Define GuC firmware version for DG2
On Mon, Feb 07, 2022 at 12:36:42PM -0800, john.c.harri...@intel.com wrote: From: John Harrison First release of GuC for DG2. Signed-off-by: John Harrison CC: Tomasz Mistat CC: Ramalingam C CC: Daniele Ceraolo Spurio Reviewed-by: Lucas De Marchi Lucas De Marchi --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index ba4f0970749b..efe0a6dcf9f7 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -50,6 +50,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * firmware as TGL. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \ + fw_def(DG2, 0, guc_def(dg2, 69, 0, 3)) \ fw_def(ALDERLAKE_P, 0, guc_def(adlp, 69, 0, 3)) \ fw_def(ALDERLAKE_S, 0, guc_def(tgl, 69, 0, 3)) \ fw_def(DG1, 0, guc_def(dg1, 69, 0, 3)) \ -- 2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for More GT register cleanup
== Series Details == Series: More GT register cleanup URL : https://patchwork.freedesktop.org/series/99872/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22217_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22217_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22217_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22217_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@smoketest: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb7/igt@gem_ctx_persiste...@smoketest.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-iclb6/igt@gem_ctx_persiste...@smoketest.html * igt@syncobj_timeline@invalid-transfer-non-existent-point: - shard-apl: NOTRUN -> [DMESG-WARN][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-apl7/igt@syncobj_timel...@invalid-transfer-non-existent-point.html - shard-skl: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-skl6/igt@syncobj_timel...@invalid-transfer-non-existent-point.html Known issues Here are the changes found in Patchwork_22217_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#1839]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-tglb3/igt@feature_discov...@display-4x.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#4547]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl7/igt@gem_exec_capture@p...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-skl8/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][8] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-kbl4/igt@gem_exec_f...@basic-deadline.html - shard-skl: NOTRUN -> [FAIL][9] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-skl9/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_params@no-vebox: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109283]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-iclb8/igt@gem_exec_par...@no-vebox.html * igt@gem_lmem_swapping@heavy-multi: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-apl7/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@random-engines: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-iclb8/igt@gem_lmem_swapp...@random-engines.html * igt@gem_pxp@fail-invalid-protected-context: - shard-tglb: NOTRUN -> [SKIP][18] ([i915#4270]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-tglb3/igt@gem_...@fail-invalid-protected-context.html * igt@gem_pxp@verify-pxp-stale-ctx-execution: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#4270]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/shard-iclb8/igt@gem_...@verify-pxp-stale-ctx-execution.html * igt@gem_render_copy@yf-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][20]
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Use drm_clflush* instead of clflush (rev6)
== Series Details == Series: Use drm_clflush* instead of clflush (rev6) URL : https://patchwork.freedesktop.org/series/99450/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Use drm_clflush* instead of clflush (rev6)
== Series Details == Series: Use drm_clflush* instead of clflush (rev6) URL : https://patchwork.freedesktop.org/series/99450/ State : warning == Summary == $ dim checkpatch origin/drm-tip 46bf608d395e drm: Add arch arm64 for drm_clflush_virt_range -:24: WARNING:INCLUDE_LINUX: Use #include instead of #24: FILE: drivers/gpu/drm/drm_cache.c:43: +#include -:37: WARNING:LINE_SPACING: Missing a blank line after declarations #37: FILE: drivers/gpu/drm/drm_cache.c:184: + void *end = addr + length; + dcache_clean_inval_poc((unsigned long)addr, (unsigned long)end); total: 0 errors, 2 warnings, 0 checks, 20 lines checked af1ddd5cfab1 drm/i915/gt: Re-work intel_write_status_page 2cd8842cdb4f drm/i915/gt: Drop invalidate_csb_entries -:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #52: FILE: drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2781: + drm_clflush_virt_range(>csb_status[0], + execlists->csb_size * sizeof(execlists->csb_status[0])); total: 0 errors, 0 warnings, 1 checks, 30 lines checked 5027b028fdc4 drm/i915/gt: Re-work reset_csb -:28: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #28: FILE: drivers/gpu/drm/i915/gt/intel_execlists_submission.c:2948: + drm_clflush_virt_range(execlists->csb_write, + sizeof(execlists->csb_write)); total: 0 errors, 0 warnings, 1 checks, 11 lines checked 315ba5405322 drm/i915/: Re-work clflush_write32 1808b1f8eb7a drm/i915/gt: replace cache_clflush_range -:6: WARNING:TYPO_SPELLING: 'occurance' may be misspelled - perhaps 'occurrence'? #6: Replace all occurance of cache_clflush_range with ^ total: 0 errors, 1 warnings, 0 checks, 77 lines checked
Re: [Intel-gfx] [PATCH v2 02/18] iosys-map: Add a few more helpers
On Wed, Feb 09, 2022 at 07:23:04AM +0100, Thomas Zimmermann wrote: Hi Am 08.02.22 um 11:45 schrieb Lucas De Marchi: First the simplest ones: - iosys_map_memset(): when abstracting system and I/O memory, just like the memcpy() use case, memset() also has dedicated functions to be called for using IO memory. - iosys_map_memcpy_from(): we may need to copy data from I/O memory, not only to. In certain situations it's useful to be able to read or write to an offset that is calculated by having the memory layout given by a struct declaration. Usually we are going to read/write a u8, u16, u32 or u64. As a pre-requisite for the implementation, add iosys_map_memcpy_from() to be the equivalent of iosys_map_memcpy_to(), but in the other direction. Then add 2 pairs of macros: - iosys_map_rd() / iosys_map_wr() - iosys_map_rd_field() / iosys_map_wr_field() The first pair takes the C-type and offset to read/write. The second pair uses a struct describing the layout of the mapping in order to calculate the offset and size being read/written. We could use readb, readw, readl, readq and the write* counterparts, however due to alignment issues this may not work on all architectures. If alignment needs to be checked to call the right function, it's not possible to decide at compile-time which function to call: so just leave the decision to the memcpy function that will do exactly that. Finally, in order to use the above macros with a map derived from another, add another initializer: IOSYS_MAP_INIT_OFFSET(). v2: - Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules within the union - Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to allow the struct itself to be at an offset from the mapping - Add documentation to iosys_map_rd_field() with example and expected memory layout Cc: Sumit Semwal Cc: Christian König Cc: Thomas Zimmermann Cc: Mauro Carvalho Chehab Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Lucas De Marchi --- include/linux/iosys-map.h | 202 ++ 1 file changed, 202 insertions(+) diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h index edd730b1e899..c6b223534b21 100644 --- a/include/linux/iosys-map.h +++ b/include/linux/iosys-map.h @@ -6,6 +6,7 @@ #ifndef __IOSYS_MAP_H__ #define __IOSYS_MAP_H__ +#include #include #include Alphabetically sorted, please. What requires kernel.h? Can this be reduced to another include statement? Maybe stddef.h for offsetof() ? Humn... I believe it was something in the previous implementation that is not there anymore. Because this builds fine without the include now and I don't think it is something being included by the headers already here. So this additional include can just be removed. Lucas De Marchi
[Intel-gfx] [PATCH v7 4/6] drm/i915/gt: Re-work reset_csb
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 28f2581d3046..cc561cfae808 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2944,9 +2944,8 @@ reset_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
{
struct intel_engine_execlists * const execlists = >execlists;
- mb(); /* paranoia: read the CSB pointers from after the reset */
- clflush(execlists->csb_write);
- mb();
+ drm_clflush_virt_range(execlists->csb_write,
+ sizeof(execlists->csb_write));
inactive = process_csb(engine, inactive); /* drain preemption events */
--
2.25.1
[Intel-gfx] [PATCH v7 6/6] drm/i915/gt: replace cache_clflush_range
Replace all occurance of cache_clflush_range with
drm_clflush_virt_range. This will prevent compile errors on non-x86
platforms.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..d0999e92621b 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -444,11 +444,11 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
pd = pdp->entry[gen8_pd_index(idx, 2)];
}
- clflush_cache_range(vaddr, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
vaddr = px_vaddr(i915_pt_entry(pd, gen8_pd_index(idx,
1)));
}
} while (1);
- clflush_cache_range(vaddr, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
return idx;
}
@@ -532,7 +532,7 @@ static void gen8_ppgtt_insert_huge(struct
i915_address_space *vm,
}
} while (rem >= page_size && index < I915_PDES);
- clflush_cache_range(vaddr, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
/*
* Is it safe to mark the 2M block as 64K? -- Either we have
@@ -548,7 +548,7 @@ static void gen8_ppgtt_insert_huge(struct
i915_address_space *vm,
I915_GTT_PAGE_SIZE_2M {
vaddr = px_vaddr(pd);
vaddr[maybe_64K] |= GEN8_PDE_IPS_64K;
- clflush_cache_range(vaddr, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
page_size = I915_GTT_PAGE_SIZE_64K;
/*
@@ -569,7 +569,7 @@ static void gen8_ppgtt_insert_huge(struct
i915_address_space *vm,
for (i = 1; i < index; i += 16)
memset64(vaddr + i, encode, 15);
- clflush_cache_range(vaddr, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
}
}
@@ -617,7 +617,7 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
vaddr = px_vaddr(i915_pt_entry(pd, gen8_pd_index(idx, 1)));
vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
- clflush_cache_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
+ drm_clflush_virt_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
static int gen8_init_scratch(struct i915_address_space *vm)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index cc561cfae808..bbe33794b34d 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2822,7 +2822,7 @@ static void execlists_sanitize(struct intel_engine_cs
*engine)
sanitize_hwsp(engine);
/* And scrub the dirty cachelines for the HWSP */
- clflush_cache_range(engine->status_page.addr, PAGE_SIZE);
+ drm_clflush_virt_range(engine->status_page.addr, PAGE_SIZE);
intel_engine_reset_pinned_contexts(engine);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 0d6bbc8c57f2..9b594be9102f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -255,7 +255,7 @@ fill_page_dma(struct drm_i915_gem_object *p, const u64 val,
unsigned int count)
void *vaddr = __px_vaddr(p);
memset64(vaddr, val, count);
- clflush_cache_range(vaddr, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
}
static void poison_scratch_page(struct drm_i915_gem_object *scratch)
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 48e6e2f87700..bd474a5123cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -90,7 +90,7 @@ write_dma_entry(struct drm_i915_gem_object * const pdma,
u64 * const vaddr = __px_vaddr(pdma);
vaddr[idx] = encoded_entry;
- clflush_cache_range([idx], sizeof(u64));
+ drm_clflush_virt_range([idx], sizeof(u64));
}
void
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b3a429a92c0d..89020706adc4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++
[Intel-gfx] [PATCH v7 5/6] drm/i915/: Re-work clflush_write32
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma *vma,
static void clflush_write32(u32 *addr, u32 value, unsigned int flushes)
{
if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
- if (flushes & CLFLUSH_BEFORE) {
- clflushopt(addr);
- mb();
- }
+ if (flushes & CLFLUSH_BEFORE)
+ drm_clflush_virt_range(addr, sizeof(addr));
*addr = value;
@@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr, u32 value,
unsigned int flushes)
* to ensure ordering of clflush wrt to the system.
*/
if (flushes & CLFLUSH_AFTER)
- clflushopt(addr);
+ drm_clflush_virt_range(addr, sizeof(addr));
} else
*addr = value;
}
--
2.25.1
[Intel-gfx] [PATCH v7 3/6] drm/i915/gt: Drop invalidate_csb_entries
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range. Thanks to Tvrtko for the
sugguestion.
v3(Michael Cheng): Use correct parameters for drm_clflush_virt_range.
Thanks to Tvrtko for pointing this out.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9bb7c863172f..28f2581d3046 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1646,12 +1646,6 @@ cancel_port_requests(struct intel_engine_execlists *
const execlists,
return inactive;
}
-static void invalidate_csb_entries(const u64 *first, const u64 *last)
-{
- clflush((void *)first);
- clflush((void *)last);
-}
-
/*
* Starting with Gen12, the status has a new format:
*
@@ -1999,7 +1993,7 @@ process_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
* the wash as hardware, working or not, will need to do the
* invalidation before.
*/
- invalidate_csb_entries([0], [num_entries - 1]);
+ drm_clflush_virt_range([0], num_entries * sizeof(buf[0]));
/*
* We assume that any event reflects a change in context flow
@@ -2783,8 +2777,8 @@ static void reset_csb_pointers(struct intel_engine_cs
*engine)
/* Check that the GPU does indeed update the CSB entries! */
memset(execlists->csb_status, -1, (reset_value + 1) * sizeof(u64));
- invalidate_csb_entries(>csb_status[0],
- >csb_status[reset_value]);
+ drm_clflush_virt_range(>csb_status[0],
+ execlists->csb_size * sizeof(execlists->csb_status[0]));
/* Once more for luck and our trusty paranoia */
ENGINE_WRITE(engine, RING_CONTEXT_STATUS_PTR,
--
2.25.1
[Intel-gfx] [PATCH v7 0/6] Use drm_clflush* instead of clflush
This patch series re-work a few i915 functions to use drm_clflush_virt_range instead of calling clflush or clflushopt directly. This will prevent errors when building for non-x86 architectures. v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added more patches to convert additional clflush/clflushopt to use drm_clflush*. (Michael Cheng) v3: Drop invalidate_csb_entries and directly invoke drm_clflush_virt_ran v4: Remove extra memory barriers v5: s/cache_clflush_range/drm_clflush_virt_range v6: Fix up "Drop invalidate_csb_entries" to use correct parameters. Also added in arm64 support for drm_clflush_virt_range. v7: Re-order patches, and use correct macro for dcache flush for arm64. Michael Cheng (6): drm: Add arch arm64 for drm_clflush_virt_range drm/i915/gt: Re-work intel_write_status_page drm/i915/gt: Drop invalidate_csb_entries drm/i915/gt: Re-work reset_csb drm/i915/: Re-work clflush_write32 drm/i915/gt: replace cache_clflush_range drivers/gpu/drm/drm_cache.c | 8 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 8 +++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++-- drivers/gpu/drm/i915/gt/intel_engine.h| 13 - .../drm/i915/gt/intel_execlists_submission.c | 19 ++- drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 8 files changed, 30 insertions(+), 36 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v7 2/6] drm/i915/gt: Re-work intel_write_status_page
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e353d8c2bc8..986777c2430d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -143,15 +144,9 @@ intel_write_status_page(struct intel_engine_cs *engine,
int reg, u32 value)
* of extra paranoia to try and ensure that the HWS takes the value
* we give and that it doesn't end up trapped inside the CPU!
*/
- if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
- mb();
- clflush(>status_page.addr[reg]);
- engine->status_page.addr[reg] = value;
- clflush(>status_page.addr[reg]);
- mb();
- } else {
- WRITE_ONCE(engine->status_page.addr[reg], value);
- }
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
+ WRITE_ONCE(engine->status_page.addr[reg], value);
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
}
/*
--
2.25.1
[Intel-gfx] [PATCH v7 1/6] drm: Add arch arm64 for drm_clflush_virt_range
Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/drm_cache.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index f19d9acbe959..94b3cc3fd482 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -39,6 +39,10 @@
/* A small bounce buffer that fits on the stack. */
#define MEMCPY_BOUNCE_SIZE 128
+#if defined(CONFIG_ARM64)
+#include
+#endif
+
#if defined(CONFIG_X86)
#include
@@ -176,6 +180,10 @@ drm_clflush_virt_range(void *addr, unsigned long length)
if (wbinvd_on_all_cpus())
pr_err("Timed out waiting for cache flush\n");
+
+#elif defined(CONFIG_ARM64)
+ void *end = addr + length;
+ dcache_clean_inval_poc((unsigned long)addr, (unsigned long)end);
#else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
--
2.25.1
Re: [Intel-gfx] [PATCH v2 02/18] iosys-map: Add a few more helpers
Hi
Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
- iosys_map_memcpy_from(): we may need to copy data from I/O
memory, not only to.
In certain situations it's useful to be able to read or write to an
offset that is calculated by having the memory layout given by a struct
declaration. Usually we are going to read/write a u8, u16, u32 or u64.
As a pre-requisite for the implementation, add iosys_map_memcpy_from()
to be the equivalent of iosys_map_memcpy_to(), but in the other
direction. Then add 2 pairs of macros:
- iosys_map_rd() / iosys_map_wr()
- iosys_map_rd_field() / iosys_map_wr_field()
The first pair takes the C-type and offset to read/write. The second
pair uses a struct describing the layout of the mapping in order to
calculate the offset and size being read/written.
We could use readb, readw, readl, readq and the write* counterparts,
however due to alignment issues this may not work on all architectures.
If alignment needs to be checked to call the right function, it's not
possible to decide at compile-time which function to call: so just leave
the decision to the memcpy function that will do exactly that.
Finally, in order to use the above macros with a map derived from
another, add another initializer: IOSYS_MAP_INIT_OFFSET().
v2:
- Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules
within the union
- Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to
allow the struct itself to be at an offset from the mapping
- Add documentation to iosys_map_rd_field() with example and expected
memory layout
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: Mauro Carvalho Chehab
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
include/linux/iosys-map.h | 202 ++
1 file changed, 202 insertions(+)
diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index edd730b1e899..c6b223534b21 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -6,6 +6,7 @@
#ifndef __IOSYS_MAP_H__
#define __IOSYS_MAP_H__
+#include
#include
#include
Alphabetically sorted, please.
What requires kernel.h? Can this be reduced to another include
statement? Maybe stddef.h for offsetof() ?
Best regards
Thomas
@@ -120,6 +121,45 @@ struct iosys_map {
.is_iomem = false, \
}
+/**
+ * IOSYS_MAP_INIT_OFFSET - Initializes struct iosys_map from another iosys_map
+ * @map_: The dma-buf mapping structure to copy from
+ * @offset_: Offset to add to the other mapping
+ *
+ * Initializes a new iosys_map struct based on another passed as argument. It
+ * does a shallow copy of the struct so it's possible to update the back
storage
+ * without changing where the original map points to. It is the equivalent of
+ * doing:
+ *
+ * .. code-block:: c
+ *
+ * iosys_map map = other_map;
+ * iosys_map_incr(, );
+ *
+ * Example usage:
+ *
+ * .. code-block:: c
+ *
+ * void foo(struct device *dev, struct iosys_map *base_map)
+ * {
+ * ...
+ * struct iosys_map map = IOSYS_MAP_INIT_OFFSET(base_map,
FIELD_OFFSET);
+ * ...
+ * }
+ *
+ * The advantage of using the initializer over just increasing the offset with
+ * iosys_map_incr() like above is that the new map will always point to the
+ * right place of the buffer during its scope. It reduces the risk of updating
+ * the wrong part of the buffer and having no compiler warning about that. If
+ * the assignment to IOSYS_MAP_INIT_OFFSET() is forgotten, the compiler can
warn
+ * about the use of uninitialized variable.
+ */
+#define IOSYS_MAP_INIT_OFFSET(map_, offset_) ({
\
+ struct iosys_map copy = *map_; \
+ iosys_map_incr(, offset_); \
+ copy; \
+})
+
/**
* iosys_map_set_vaddr - Sets a iosys mapping structure to an address in
system memory
* @map: The iosys_map structure
@@ -239,6 +279,26 @@ static inline void iosys_map_memcpy_to(struct iosys_map
*dst, size_t dst_offset,
memcpy(dst->vaddr + dst_offset, src, len);
}
+/**
+ * iosys_map_memcpy_from - Memcpy from iosys_map into system memory
+ * @dst: Destination in system memory
+ * @src: The iosys_map structure
+ * @src_offset:The offset from which to copy
+ * @len: The number of byte in src
+ *
+ * Copies data from a iosys_map with an offset. The dest buffer is in
+ * system memory. Depending on the mapping location, the helper picks the
+ * correct method
Re: [Intel-gfx] [PATCH v2 02/18] iosys-map: Add a few more helpers
Em Tue, 8 Feb 2022 02:45:08 -0800
Lucas De Marchi escreveu:
> First the simplest ones:
>
> - iosys_map_memset(): when abstracting system and I/O memory,
> just like the memcpy() use case, memset() also has dedicated
> functions to be called for using IO memory.
> - iosys_map_memcpy_from(): we may need to copy data from I/O
> memory, not only to.
>
> In certain situations it's useful to be able to read or write to an
> offset that is calculated by having the memory layout given by a struct
> declaration. Usually we are going to read/write a u8, u16, u32 or u64.
>
> As a pre-requisite for the implementation, add iosys_map_memcpy_from()
> to be the equivalent of iosys_map_memcpy_to(), but in the other
> direction. Then add 2 pairs of macros:
>
> - iosys_map_rd() / iosys_map_wr()
> - iosys_map_rd_field() / iosys_map_wr_field()
>
> The first pair takes the C-type and offset to read/write. The second
> pair uses a struct describing the layout of the mapping in order to
> calculate the offset and size being read/written.
>
> We could use readb, readw, readl, readq and the write* counterparts,
> however due to alignment issues this may not work on all architectures.
> If alignment needs to be checked to call the right function, it's not
> possible to decide at compile-time which function to call: so just leave
> the decision to the memcpy function that will do exactly that.
>
> Finally, in order to use the above macros with a map derived from
> another, add another initializer: IOSYS_MAP_INIT_OFFSET().
>
> v2:
> - Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules
> within the union
> - Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to
> allow the struct itself to be at an offset from the mapping
> - Add documentation to iosys_map_rd_field() with example and expected
> memory layout
>
> Cc: Sumit Semwal
> Cc: Christian König
> Cc: Thomas Zimmermann
> Cc: Mauro Carvalho Chehab
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Lucas De Marchi
LGTM.
Reviewed-by: Mauro Carvalho Chehab
Regards,
Mauro
> ---
> include/linux/iosys-map.h | 202 ++
> 1 file changed, 202 insertions(+)
>
> diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
> index edd730b1e899..c6b223534b21 100644
> --- a/include/linux/iosys-map.h
> +++ b/include/linux/iosys-map.h
> @@ -6,6 +6,7 @@
> #ifndef __IOSYS_MAP_H__
> #define __IOSYS_MAP_H__
>
> +#include
> #include
> #include
>
> @@ -120,6 +121,45 @@ struct iosys_map {
> .is_iomem = false, \
> }
>
> +/**
> + * IOSYS_MAP_INIT_OFFSET - Initializes struct iosys_map from another
> iosys_map
> + * @map_:The dma-buf mapping structure to copy from
> + * @offset_: Offset to add to the other mapping
> + *
> + * Initializes a new iosys_map struct based on another passed as argument. It
> + * does a shallow copy of the struct so it's possible to update the back
> storage
> + * without changing where the original map points to. It is the equivalent of
> + * doing:
> + *
> + * .. code-block:: c
> + *
> + * iosys_map map = other_map;
> + * iosys_map_incr(, );
> + *
> + * Example usage:
> + *
> + * .. code-block:: c
> + *
> + * void foo(struct device *dev, struct iosys_map *base_map)
> + * {
> + * ...
> + * struct iosys_map map = IOSYS_MAP_INIT_OFFSET(base_map,
> FIELD_OFFSET);
> + * ...
> + * }
> + *
> + * The advantage of using the initializer over just increasing the offset
> with
> + * iosys_map_incr() like above is that the new map will always point to the
> + * right place of the buffer during its scope. It reduces the risk of
> updating
> + * the wrong part of the buffer and having no compiler warning about that. If
> + * the assignment to IOSYS_MAP_INIT_OFFSET() is forgotten, the compiler can
> warn
> + * about the use of uninitialized variable.
> + */
> +#define IOSYS_MAP_INIT_OFFSET(map_, offset_) ({
> \
> + struct iosys_map copy = *map_; \
> + iosys_map_incr(, offset_); \
> + copy; \
> +})
> +
> /**
> * iosys_map_set_vaddr - Sets a iosys mapping structure to an address in
> system memory
> * @map: The iosys_map structure
> @@ -239,6 +279,26 @@ static inline void iosys_map_memcpy_to(struct iosys_map
> *dst, size_t dst_offset,
> memcpy(dst->vaddr + dst_offset, src, len);
> }
>
> +/**
> + * iosys_map_memcpy_from - Memcpy from iosys_map into system memory
> + * @dst: Destination in system memory
> + * @src: The iosys_map structure
> + * @src_offset: The offset from which to copy
> + * @len: The number of byte in src
> + *
> + * Copies data from a iosys_map with an offset. The dest buffer is in
> + *
[Intel-gfx] ✓ Fi.CI.BAT: success for More GT register cleanup
== Series Details == Series: More GT register cleanup URL : https://patchwork.freedesktop.org/series/99872/ State : success == Summary == CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22217 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/index.html Participating hosts (46 -> 42) -- Missing(4): fi-bsw-cyan fi-icl-u2 shard-tglu fi-pnv-d510 Known issues Here are the changes found in Patchwork_22217 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][4] -> [INCOMPLETE][5] ([i915#2940]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271]) +21 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bsw-n3050: NOTRUN -> [FAIL][9] ([fdo#109271] / [i915#1436] / [i915#3428] / [i915#4312]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-bsw-n3050/igt@run...@aborted.html - fi-bdw-5557u: NOTRUN -> [FAIL][10] ([i915#2426] / [i915#4312]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [INCOMPLETE][11] ([i915#146]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [FAIL][13] ([i915#4547]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [DMESG-FAIL][15] ([i915#4957]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-hsw-4770:[INCOMPLETE][17] ([i915#4785]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html Warnings * igt@debugfs_test@read_all_entries: - fi-apl-guc: [DMESG-WARN][19] -> [DMESG-WARN][20] ([i915#1610]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-apl-guc/igt@debugfs_test@read_all_entries.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22217/fi-apl-guc/igt@debugfs_test@read_all_entries.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#146]:
Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
On 2/7/22 07:36, Tvrtko Ursulin wrote: On 20/01/2022 22:16, Casey Bowman wrote: In this RFC I would like to ask the community their thoughts on how we can best handle splitting architecture-specific calls. I would like to address the following: 1. How do we want to split architecture calls? Different object files per platform? Separate function calls within the same object file? If we are talking about per-platform divergence of significant functions (not necessarily in size but their height position in the i915 stack) I agree with Jani that top-level per platform organisation is not the best choice. On the other hand I doubt that there should be many, if any, such functions. In practice I think it should be only low level stuff which diverges. I agree, as said with my reply to Jani, I think maybe going forward for arch-specific code, #if IS_ENABLED calls should be used sparingly, only in the cases where we do have that arch-specific implementation (like low level calls), instead of just a 'return null', as in my case. On a concrete example.. 2. How do we address dummy functions? If we have a function call that is used for one or more platforms, but is not used in another, what should we do for this case? ... depends on the situation. Sometimes a flavour of "warn on once" can be okay I guess, but also why not build bug on? Because.. True, with Jani's and your comments, I'm thinking that in the case of when we look at a potential arch-specific function where we're just returning null or something similar, we should be re-evaluating the function and seeing if we should make a different change there. I've given an example of splitting an architecture call in my patch with run_as_guest() being split into different implementations for x86 and arm64 in separate object files, sharing a single header. ... run_as_guest may be a very tricky example, given it is called from intel_vtd_active which has a number of callers. What is correct behaviour on Arm in this example? None of these call sites will run on Arm? Or that you expect the warn on added in this patch to trigger as a demonstration? If so, what is the plan going forward? We can take one example and talk about it hypothetically: ./i915_driver.c: drm_printf(p, "iommu: %s\n", enableddisabled(intel_vtd_active(i915))); What is the "fix" (refactor) for Arm here? Looks like a new top-level function is needed which does not carry the intel_vtd_ prefix but something more generic. That one could then legitimately "warn on once", while for intel_vtd_active it would be wrong to do so. Good point, run_as_guest might be a bit more challenging of an example. In my mind, I was thinking of just simply returning null for arm64 here as I don't believe arm64 would be making use of iommu for our cases (at least, in the short term). I think this example function specifically needs to get reworked, as you mentioned, in some way, possibly refactoring intel_vtd_active or something along those lines. And when I say it is needed.. well perhaps it is not strictly needed in this case, but in some other cases I think we go back to the problem I stated some months ago and that is that I suspect use of intel_vtd_active is overloaded. I think it is currently used to answer all these questions: 1. Is the IOMMU active, just for information.; 2. Is the IOMMU active and we want to counteract the performance hit by say using huge pages, adjusting the display bandwidth calculations or whatever. (In which case we also may want to distinguish between pass-through and translation modes.); 3. Is a potentially buggy IOMMU active and we need to work around it. All these under one kind of worked with one iommu implementation but does it with a different IOMMU? Which I mean leads to end conclusion that this particular function is a tricky example to answer the questions asked. :) Another suggestion from Michael (michael.ch...@intel.com) involved using a single object file, a single header, and splitting various functions calls via ifdefs in the header file. In principle, mostly what you have outlined sounds acceptable to me, with the difference that I would not use i915_platform, but for this particular example something like i915_hypervisor prefix. Then I would prepare i915 with the same scheme kernel uses, not just for source file divergence, but header file as well. That is: some_source.c: #include "i915_hypervisor.h" i915_hypervisor.h: #include "platform/i915_hypervisor.h" Then in i915 root you could have: platforms/x86/include/platform/i915_hypervisor.h platforms/arm/include/platform/i915_hypervisor.h And some kbuild stuff to make that work. Is this doable and does it make sense? Per-platform source files could live in there as well. Same scheme for i915_clflush would work as well. I like the idea of getting more specific for the calls here, but I'm somewhat afraid of obfuscating these
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for More GT register cleanup
== Series Details == Series: More GT register cleanup URL : https://patchwork.freedesktop.org/series/99872/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More GT register cleanup
== Series Details == Series: More GT register cleanup URL : https://patchwork.freedesktop.org/series/99872/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9a3768557554 drm/i915/gt: Drop duplicate register definition for VDBOX_CGCTL3F18 827feabcfa0f drm/i915/gt: Move SFC lock bits to intel_engine_regs.h c2ad90281821 drm/i915/gt: Use parameterized RING_MI_MODE da6b61418421 drm/i915/gt: Cleanup spacing of intel_gt_regs.h -:401: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #401: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:207: +#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (1 << GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT) -:405: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #405: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:211: +#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK(0x7 << GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT) -:411: WARNING:LONG_LINE: line length of 108 exceeds 100 columns #411: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:217: +#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK (0x3 << GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT) -:1217: WARNING:LONG_LINE_COMMENT: line length of 120 exceeds 100 columns #1217: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:538: +#define PXVFREQ(fstart)_MMIO(0x0 + (fstart) * 4) /* P[0-15]VIDFREQ (0x1114c) (Ironlake) */ -:1256: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #1256: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:577: +#define MEMCTL_CMD_STS (1 << 12) /* write 1 triggers command, clears +when command complete */ -:1256: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #1256: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:577: +when command complete */ -:1369: WARNING:LONG_LINE_COMMENT: line length of 150 exceeds 100 columns #1369: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:690: +#define IMPROMOEN(1 << 10) /* promo is immediate or delayed until next idle interval (only for timeout method above) */ -:1377: WARNING:LONG_LINE_COMMENT: line length of 101 exceeds 100 columns #1377: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:698: +#define REDSAVES (1 << 3) /* no context save if was idle during rs0 */ -:1464: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'cxt_reg' - possible side-effects? #1464: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:777: +#define GEN6_CXT_TOTAL_SIZE(cxt_reg) (GEN6_CXT_RING_SIZE(cxt_reg) + \ + GEN6_CXT_EXTENDED_SIZE(cxt_reg) + \ + GEN6_CXT_PIPELINE_SIZE(cxt_reg)) -:1474: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ctx_reg' - possible side-effects? #1474: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:787: +#define GEN7_CXT_TOTAL_SIZE(ctx_reg) (GEN7_CXT_EXTENDED_SIZE(ctx_reg) + \ +GEN7_CXT_VFSTATE_SIZE(ctx_reg)) -:2218: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice' - possible side-effects? #2218: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:1357: +#define GEN10_SLICE_PGCTL_ACK(slice) _MMIO(0x804c + ((slice) / 3) * 0x34 + \ + ((slice) % 3) * 0x4) -:2225: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice' - possible side-effects? #2225: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:1364: +#define GEN10_SS01_EU_PGCTL_ACK(slice) _MMIO(0x805c + ((slice) / 3) * 0x30 + \ + ((slice) % 3) * 0x8) -:2228: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice' - possible side-effects? #2228: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:1367: +#define GEN10_SS23_EU_PGCTL_ACK(slice) _MMIO(0x8060 + ((slice) / 3) * 0x30 + \ + ((slice) % 3) * 0x8) total: 0 errors, 8 warnings, 5 checks, 2393 lines checked e69f259c44a8 drm/i915/gt: Use consistent offset notation in intel_gt_regs.h 1048c366fb86 drm/i915/gt: Order GT registers by MMIO offset -:34: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #34: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:14: +#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (1 << GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT) -:38: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #38: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:18: +#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK(0x7 << GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT) -:44: WARNING:LONG_LINE: line length of 108 exceeds 100 columns #44: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:24: +#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK (0x3 << GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT) -:284:
[Intel-gfx] [PATCH 3/6] drm/i915/gt: Use parameterized RING_MI_MODE
We have both a parameterized RING_MI_MODE() macro and an RCS-specific
MI_MODE; drop the latter and use the former everywhere.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 6 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +++---
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
4 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index cafb078cdb05..0bf8b45c9319 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -70,6 +70,12 @@
#define RING_NOPID(base) _MMIO((base) + 0x94)
#define RING_HWSTAM(base) _MMIO((base) + 0x98)
#define RING_MI_MODE(base) _MMIO((base) + 0x9c)
+#define ASYNC_FLIP_PERF_DISABLE REG_BIT(14)
+#define MI_FLUSH_ENABLE REG_BIT(12)
+#define TGL_NESTED_BB_EN REG_BIT(12)
+#define MODE_IDLEREG_BIT(9)
+#define STOP_RINGREG_BIT(8)
+#define VS_TIMER_DISPATCHREG_BIT(6)
#define RING_IMR(base) _MMIO((base) + 0xa8)
#define RING_EIR(base) _MMIO((base) + 0xb0)
#define RING_EMR(base) _MMIO((base) + 0xb4)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 4cdb2cca2122..987e0e1e9c08 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -389,14 +389,6 @@
#define _3D_CHICKEN_SDE_LIMIT_FIFO_POLY_DEPTH(x) ((x) << 1) /* gen8+ */
#define _3D_CHICKEN3_SF_DISABLE_PIPELINED_ATTR_FETCH (1 << 1) /* gen6 */
-#define MI_MODE_MMIO(0x209c)
-# define VS_TIMER_DISPATCH (1 << 6)
-# define MI_FLUSH_ENABLE (1 << 12)
-# define TGL_NESTED_BB_EN (1 << 12)
-# define ASYNC_FLIP_PERF_DISABLE (1 << 14)
-# define MODE_IDLE (1 << 9)
-# define STOP_RING (1 << 8)
-
#define GEN6_GT_MODE _MMIO(0x20d0)
#define GEN7_GT_MODE _MMIO(0x7008)
#define GEN6_WIZ_HASHING(hi, lo) (((hi) << 9) | ((lo) <<
7))
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index b146a393cd79..26038066e90b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -237,7 +237,7 @@ static void gen8_ctx_workarounds_init(struct
intel_engine_cs *engine,
wa_masked_en(wal, INSTPM, INSTPM_FORCE_ORDERING);
/* WaDisableAsyncFlipPerfMode:bdw,chv */
- wa_masked_en(wal, MI_MODE, ASYNC_FLIP_PERF_DISABLE);
+ wa_masked_en(wal, RING_MI_MODE(RENDER_RING_BASE),
ASYNC_FLIP_PERF_DISABLE);
/* WaDisablePartialInstShootdown:bdw,chv */
wa_masked_en(wal, GEN8_ROW_CHICKEN,
@@ -2474,7 +2474,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv
*/
wa_masked_en(wal,
-MI_MODE,
+RING_MI_MODE(RENDER_RING_BASE),
ASYNC_FLIP_PERF_DISABLE);
if (GRAPHICS_VER(i915) == 6) {
@@ -2533,7 +2533,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
if (IS_GRAPHICS_VER(i915, 4, 6))
/* WaTimedSingleVertexDispatch:cl,bw,ctg,elk,ilk,snb */
- wa_add(wal, MI_MODE,
+ wa_add(wal, RING_MI_MODE(RENDER_RING_BASE),
0, _MASKED_BIT_ENABLE(VS_TIMER_DISPATCH),
/* XXX bit doesn't stick on Broadwater */
IS_I965G(i915) ? 0 : VS_TIMER_DISPATCH, true);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 850ebfae31af..dd8fdd5863de 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1496,7 +1496,7 @@ ilk_dummy_write(struct intel_uncore *uncore)
/* WaIssueDummyWriteToWakeupFromRC6:ilk Issue a dummy write to wake up
* the chip from rc6 before touching it for real. MI_MODE is masked,
* hence harmless to write 0 into. */
- __raw_uncore_write32(uncore, MI_MODE, 0);
+ __raw_uncore_write32(uncore, RING_MI_MODE(RENDER_RING_BASE), 0);
}
static void
--
2.34.1
[Intel-gfx] [PATCH 5/6] drm/i915/gt: Use consistent offset notation in intel_gt_regs.h
Switch all register offsets to use lowercase hex values for consistency. Also strip any unnecessary leading 0's. For example, "_MMIO(0x0D08)" becomes "_MMIO(0xd08)." Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 234 1 file changed, 117 insertions(+), 117 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index dcbf7f2f0b90..3b1cae766741 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -29,7 +29,7 @@ #define FBC_LLC_READ_CTRL _MMIO(0x9044) #define FBC_LLC_FULLY_OPEN REG_BIT(30) -#define GEN6_MBCTL _MMIO(0x0907c) +#define GEN6_MBCTL _MMIO(0x907c) #define GEN6_MBCTL_ENABLE_BOOT_FETCH (1 << 4) #define GEN6_MBCTL_CTX_FETCH_NEEDED (1 << 3) #define GEN6_MBCTL_BME_UPDATE_ENABLE (1 << 2) @@ -70,7 +70,7 @@ #define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000) -#define WAIT_FOR_RC6_EXIT _MMIO(0x20CC) +#define WAIT_FOR_RC6_EXIT _MMIO(0x20cc) /* HSW only */ #define HSW_SELECTIVE_READ_ADDRESSING_SHIFT 2 #define HSW_SELECTIVE_READ_ADDRESSING_MASK (0x3 << HSW_SLECTIVE_READ_ADDRESSING_SHIFT) @@ -176,7 +176,7 @@ #define GEN7_3DPRIM_START_VERTEX _MMIO(0x2430) #define GEN7_3DPRIM_VERTEX_COUNT _MMIO(0x2434) #define GEN7_3DPRIM_INSTANCE_COUNT _MMIO(0x2438) -#define GEN7_3DPRIM_START_INSTANCE _MMIO(0x243C) +#define GEN7_3DPRIM_START_INSTANCE _MMIO(0x243c) #define GEN7_3DPRIM_BASE_VERTEX_MMIO(0x2440) #define GEN7_GPGPU_DISPATCHDIMX_MMIO(0x2500) @@ -202,7 +202,7 @@ #define DIS_NULL_QUERY REG_BIT(10) /* RPM unit config (Gen8+) */ -#define RPM_CONFIG0_MMIO(0x0D00) +#define RPM_CONFIG0_MMIO(0xd00) #define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT3 #define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (1 << GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT) #define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ 0 @@ -216,11 +216,11 @@ #define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT 1 #define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK (0x3 << GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT) -#define RPM_CONFIG1_MMIO(0x0D04) +#define RPM_CONFIG1_MMIO(0xd04) #define GEN10_GT_NOA_ENABLE (1 << 9) /* GPM unit config (Gen9+) */ -#define CTC_MODE _MMIO(0xA26C) +#define CTC_MODE _MMIO(0xa26c) #define CTC_SOURCE_PARAMETER_MASK1 #define CTC_SOURCE_CRYSTAL_CLOCK 0 #define CTC_SOURCE_DIVIDE_LOGIC 1 @@ -228,33 +228,33 @@ #define CTC_SHIFT_PARAMETER_MASK (0x3 << CTC_SHIFT_PARAMETER_SHIFT) /* RCP unit config (Gen8+) */ -#define RCP_CONFIG _MMIO(0x0D08) +#define RCP_CONFIG _MMIO(0xd08) #define MICRO_BP0_0_MMIO(0x9800) #define MICRO_BP0_2_MMIO(0x9804) #define MICRO_BP0_1_MMIO(0x9808) -#define MICRO_BP1_0_MMIO(0x980C) +#define MICRO_BP1_0_MMIO(0x980c) #define MICRO_BP1_2_MMIO(0x9810) #define MICRO_BP1_1_MMIO(0x9814) #define MICRO_BP2_0_MMIO(0x9818) -#define MICRO_BP2_2_MMIO(0x981C) +#define MICRO_BP2_2_MMIO(0x981c) #define MICRO_BP2_1_MMIO(0x9820) #define MICRO_BP3_0_MMIO(0x9824) #define MICRO_BP3_2_MMIO(0x9828) -#define MICRO_BP3_1_MMIO(0x982C) +#define MICRO_BP3_1_MMIO(0x982c) #define MICRO_BP_TRIGGER _MMIO(0x9830) #define MICRO_BP3_COUNT_STATUS01 _MMIO(0x9834) #define MICRO_BP3_COUNT_STATUS23 _MMIO(0x9838) -#define MICRO_BP_FIRED_ARMED _MMIO(0x983C) +#define MICRO_BP_FIRED_ARMED _MMIO(0x983c) -#define GAMTARBMODE_MMIO(0x04a08) +#define GAMTARBMODE_MMIO(0x4a08) #define ARB_MODE_BWGTLB_DISABLE (1 << 9) #define ARB_MODE_SWIZZLE_BDW (1 << 1) -#define RENDER_HWS_PGA_GEN7_MMIO(0x04080) +#define RENDER_HWS_PGA_GEN7_MMIO(0x4080) #define _RING_FAULT_REG_RCS0x4094 #define _RING_FAULT_REG_VCS0x4194 @@ -278,20 +278,20 @@
[Intel-gfx] [PATCH 6/6] drm/i915/gt: Order GT registers by MMIO offset
The random order of register definitions we have today causes a lot of
confusion and unintentional duplication when new registers/bits are
added to the driver. Let's order the GT register file by MMIO offset
A couple duplicated/unused register definitions are dropped while doing
this re-order: GEN11_GT_INTR_DW{0,1}, GEN11_IIR_REG{0,1}_SELECTOR, and
GEN11_INTR_IDENTITY_REG{0,1} aren't used anywhere in the driver because
we have other parameterized macros referencing those registers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2289 ---
1 file changed, 1147 insertions(+), 1142 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 3b1cae766741..e48a2ffed4fd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -8,67 +8,95 @@
#include "i915_reg_defs.h"
-#define ILK_GDSR _MMIO(MCHBAR_MIRROR_BASE +
0x2ca4)
-#define ILK_GRDOM_FULL (0 << 1)
-#define ILK_GRDOM_RENDER (1 << 1)
-#define ILK_GRDOM_MEDIA (3 << 1)
-#define ILK_GRDOM_MASK (3 << 1)
-#define ILK_GRDOM_RESET_ENABLE (1 << 0)
+/* RPM unit config (Gen8+) */
+#define RPM_CONFIG0_MMIO(0xd00)
+#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT3
+#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (1 <<
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
+#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ 0
+#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ 1
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT 3
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK(0x7 <<
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ 0
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ1
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_38_4_MHZ2
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_25_MHZ 3
+#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT 1
+#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK (0x3 <<
GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
-#define GEN6_MBCUNIT_SNPCR _MMIO(0x900c) /* for LLC config
*/
-#define GEN6_MBC_SNPCR_SHIFT 21
-#define GEN6_MBC_SNPCR_MASK (3 << 21)
-#define GEN6_MBC_SNPCR_MAX (0 << 21)
-#define GEN6_MBC_SNPCR_MED (1 << 21)
-#define GEN6_MBC_SNPCR_LOW (2 << 21)
-#define GEN6_MBC_SNPCR_MIN (3 << 21) /* only 1/16th of the
cache is shared */
+#define RPM_CONFIG1_MMIO(0xd04)
+#define GEN10_GT_NOA_ENABLE (1 << 9)
-#define VLV_G3DCTL _MMIO(0x9024)
-#define VLV_GSCKGCTL _MMIO(0x9028)
+/* RCP unit config (Gen8+) */
+#define RCP_CONFIG _MMIO(0xd08)
-#define FBC_LLC_READ_CTRL _MMIO(0x9044)
-#define FBC_LLC_FULLY_OPEN REG_BIT(30)
+#define RC6_LOCATION _MMIO(0xd40)
+#define RC6_CTX_IN_DRAM (1 << 0)
+#define RC6_CTX_BASE _MMIO(0xd48)
+#defineRC6_CTX_BASE_MASK 0xFFF0
-#define GEN6_MBCTL _MMIO(0x907c)
-#define GEN6_MBCTL_ENABLE_BOOT_FETCH (1 << 4)
-#define GEN6_MBCTL_CTX_FETCH_NEEDED (1 << 3)
-#define GEN6_MBCTL_BME_UPDATE_ENABLE (1 << 2)
-#define GEN6_MBCTL_MAE_UPDATE_ENABLE (1 << 1)
-#define GEN6_MBCTL_BOOT_FETCH_MECH (1 << 0)
+#define FORCEWAKE_ACK_MEDIA_VDBOX_GEN11(n) _MMIO(0xd50 + (n) * 4)
+#define FORCEWAKE_ACK_MEDIA_VEBOX_GEN11(n) _MMIO(0xd70 + (n) * 4)
+#define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0xd84)
+#define FORCEWAKE_ACK_MEDIA_GEN9 _MMIO(0xd88)
-#define GEN6_GDRST _MMIO(0x941c)
-#define GEN6_GRDOM_FULL (1 << 0)
-#define GEN6_GRDOM_RENDER(1 << 1)
-#define GEN6_GRDOM_MEDIA (1 << 2)
-#define GEN6_GRDOM_BLT (1 << 3)
-#define GEN6_GRDOM_VECS (1 << 4)
-#define GEN9_GRDOM_GUC (1 << 5)
-#define GEN8_GRDOM_MEDIA2(1 << 7)
-/* GEN11 changed all bit defs except for FULL & RENDER */
-#define GEN11_GRDOM_FULL GEN6_GRDOM_FULL
-#define GEN11_GRDOM_RENDER GEN6_GRDOM_RENDER
-#define GEN11_GRDOM_BLT (1 << 2)
-#define GEN11_GRDOM_GUC (1 << 3)
-#define GEN11_GRDOM_MEDIA(1 << 5)
-#define GEN11_GRDOM_MEDIA2 (1 << 6)
-#define GEN11_GRDOM_MEDIA3 (1 << 7)
-#define GEN11_GRDOM_MEDIA4
[Intel-gfx] [PATCH 4/6] drm/i915/gt: Cleanup spacing of intel_gt_regs.h
There's a lot of inconsistent spacing and indentation in our register definitions. Let's clean things up a bit and follow some consistent rules: * "#define" always starts in column 0 * There's exactly one space between '#define' and the name of a register. * There's exactly three spaces between '#define' and the name of a bit/bitfield. * Tabs (no spaces) are used between a definition name and its value; the value starts on column 48 unless the name is too long, in which case a single tab is used. Final diff for this patch is empty if whitespace is ignored: $ git diff -w $ Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2116 +++ 1 file changed, 1058 insertions(+), 1058 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 987e0e1e9c08..dcbf7f2f0b90 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -8,162 +8,162 @@ #include "i915_reg_defs.h" -#define ILK_GDSR _MMIO(MCHBAR_MIRROR_BASE + 0x2ca4) -#define ILK_GRDOM_FULL(0 << 1) -#define ILK_GRDOM_RENDER (1 << 1) -#define ILK_GRDOM_MEDIA (3 << 1) -#define ILK_GRDOM_MASK(3 << 1) -#define ILK_GRDOM_RESET_ENABLE (1 << 0) - -#define GEN6_MBCUNIT_SNPCR _MMIO(0x900c) /* for LLC config */ -#define GEN6_MBC_SNPCR_SHIFT 21 -#define GEN6_MBC_SNPCR_MASK (3 << 21) -#define GEN6_MBC_SNPCR_MAX (0 << 21) -#define GEN6_MBC_SNPCR_MED (1 << 21) -#define GEN6_MBC_SNPCR_LOW (2 << 21) -#define GEN6_MBC_SNPCR_MIN (3 << 21) /* only 1/16th of the cache is shared */ - -#define VLV_G3DCTL _MMIO(0x9024) -#define VLV_GSCKGCTL _MMIO(0x9028) - -#define FBC_LLC_READ_CTRL _MMIO(0x9044) -#define FBC_LLC_FULLY_OPEN REG_BIT(30) - -#define GEN6_MBCTL _MMIO(0x0907c) -#define GEN6_MBCTL_ENABLE_BOOT_FETCH (1 << 4) -#define GEN6_MBCTL_CTX_FETCH_NEEDED (1 << 3) -#define GEN6_MBCTL_BME_UPDATE_ENABLE (1 << 2) -#define GEN6_MBCTL_MAE_UPDATE_ENABLE (1 << 1) -#define GEN6_MBCTL_BOOT_FETCH_MECH (1 << 0) - -#define GEN6_GDRST _MMIO(0x941c) -#define GEN6_GRDOM_FULL (1 << 0) -#define GEN6_GRDOM_RENDER (1 << 1) -#define GEN6_GRDOM_MEDIA (1 << 2) -#define GEN6_GRDOM_BLT(1 << 3) -#define GEN6_GRDOM_VECS (1 << 4) -#define GEN9_GRDOM_GUC(1 << 5) -#define GEN8_GRDOM_MEDIA2 (1 << 7) +#define ILK_GDSR _MMIO(MCHBAR_MIRROR_BASE + 0x2ca4) +#define ILK_GRDOM_FULL (0 << 1) +#define ILK_GRDOM_RENDER (1 << 1) +#define ILK_GRDOM_MEDIA (3 << 1) +#define ILK_GRDOM_MASK (3 << 1) +#define ILK_GRDOM_RESET_ENABLE (1 << 0) + +#define GEN6_MBCUNIT_SNPCR _MMIO(0x900c) /* for LLC config */ +#define GEN6_MBC_SNPCR_SHIFT 21 +#define GEN6_MBC_SNPCR_MASK (3 << 21) +#define GEN6_MBC_SNPCR_MAX (0 << 21) +#define GEN6_MBC_SNPCR_MED (1 << 21) +#define GEN6_MBC_SNPCR_LOW (2 << 21) +#define GEN6_MBC_SNPCR_MIN (3 << 21) /* only 1/16th of the cache is shared */ + +#define VLV_G3DCTL _MMIO(0x9024) +#define VLV_GSCKGCTL _MMIO(0x9028) + +#define FBC_LLC_READ_CTRL _MMIO(0x9044) +#define FBC_LLC_FULLY_OPEN REG_BIT(30) + +#define GEN6_MBCTL _MMIO(0x0907c) +#define GEN6_MBCTL_ENABLE_BOOT_FETCH (1 << 4) +#define GEN6_MBCTL_CTX_FETCH_NEEDED (1 << 3) +#define GEN6_MBCTL_BME_UPDATE_ENABLE (1 << 2) +#define GEN6_MBCTL_MAE_UPDATE_ENABLE (1 << 1) +#define GEN6_MBCTL_BOOT_FETCH_MECH (1 << 0) + +#define GEN6_GDRST _MMIO(0x941c) +#define GEN6_GRDOM_FULL (1 << 0) +#define GEN6_GRDOM_RENDER(1 << 1) +#define GEN6_GRDOM_MEDIA (1 << 2) +#define GEN6_GRDOM_BLT (1 << 3) +#define GEN6_GRDOM_VECS (1 << 4) +#define GEN9_GRDOM_GUC (1 << 5) +#define GEN8_GRDOM_MEDIA2(1 << 7) /* GEN11 changed all bit defs except for FULL & RENDER */ -#define GEN11_GRDOM_FULL GEN6_GRDOM_FULL -#define GEN11_GRDOM_RENDERGEN6_GRDOM_RENDER -#define GEN11_GRDOM_BLT (1 << 2) -#define GEN11_GRDOM_GUC (1 << 3) -#define GEN11_GRDOM_MEDIA (1 << 5) -#define GEN11_GRDOM_MEDIA2(1 << 6) -#define GEN11_GRDOM_MEDIA3(1 << 7) -#define GEN11_GRDOM_MEDIA4(1 << 8) -#define GEN11_GRDOM_MEDIA5(1 << 9) -#define
[Intel-gfx] [PATCH 2/6] drm/i915/gt: Move SFC lock bits to intel_engine_regs.h
These SFC registers were defined in an usual way, taking an engine as a parameter rather than an engine MMIO base offset. Let's adjust them to match the style used by other per-engine registers and move them to intel_engine_regs.h. While doing this move, we can drop GEN12_HCP_SFC_FORCED_LOCK completely; it was intended for use in an early version of a hardware workaround, but was no longer necessary by the time the workaround was finalized. It is not used anywhere in the driver. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_engine_regs.h | 17 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 19 --- drivers/gpu/drm/i915/gt/intel_reset.c | 14 +++--- 3 files changed, 24 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h b/drivers/gpu/drm/i915/gt/intel_engine_regs.h index e9fec6214073..cafb078cdb05 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h @@ -211,8 +211,25 @@ #define GEN8_RING_CS_GPR(base, n) _MMIO((base) + 0x600 + (n) * 8) #define GEN8_RING_CS_GPR_UDW(base, n) _MMIO((base) + 0x600 + (n) * 8 + 4) +#define GEN11_VCS_SFC_FORCED_LOCK(base)_MMIO((base) + 0x88c) +#define GEN11_VCS_SFC_FORCED_LOCK_BIT(1 << 0) +#define GEN11_VCS_SFC_LOCK_STATUS(base)_MMIO((base) + 0x890) +#define GEN11_VCS_SFC_USAGE_BIT (1 << 0) +#define GEN11_VCS_SFC_LOCK_ACK_BIT (1 << 1) + +#define GEN11_VECS_SFC_FORCED_LOCK(base) _MMIO((base) + 0x201c) +#define GEN11_VECS_SFC_FORCED_LOCK_BIT (1 << 0) +#define GEN11_VECS_SFC_LOCK_ACK(base) _MMIO((base) + 0x2018) +#define GEN11_VECS_SFC_LOCK_ACK_BIT (1 << 0) +#define GEN11_VECS_SFC_USAGE(base) _MMIO((base) + 0x2014) +#define GEN11_VECS_SFC_USAGE_BIT (1 << 0) + #define RING_HWS_PGA_GEN6(base)_MMIO((base) + 0x2080) +#define GEN12_HCP_SFC_LOCK_STATUS(base)_MMIO((base) + 0x2914) +#define GEN12_HCP_SFC_LOCK_ACK_BIT REG_BIT(1) +#define GEN12_HCP_SFC_USAGE_BIT REG_BIT(0) + #define VDBOX_CGCTL3F10(base) _MMIO((base) + 0x3f10) #define IECPUNIT_CLKGATE_DIS REG_BIT(22) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index e73c706e7f0d..4cdb2cca2122 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -68,25 +68,6 @@ #define GEN11_VCS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 << ((instance) >> 1)) #define GEN11_VECS_SFC_RESET_BIT(instance)(GEN11_GRDOM_SFC0 << (instance)) -#define GEN11_VCS_SFC_FORCED_LOCK(engine) _MMIO((engine)->mmio_base + 0x88C) -#define GEN11_VCS_SFC_FORCED_LOCK_BIT(1 << 0) -#define GEN11_VCS_SFC_LOCK_STATUS(engine) _MMIO((engine)->mmio_base + 0x890) -#define GEN11_VCS_SFC_USAGE_BIT (1 << 0) -#define GEN11_VCS_SFC_LOCK_ACK_BIT (1 << 1) - -#define GEN11_VECS_SFC_FORCED_LOCK(engine) _MMIO((engine)->mmio_base + 0x201C) -#define GEN11_VECS_SFC_FORCED_LOCK_BIT (1 << 0) -#define GEN11_VECS_SFC_LOCK_ACK(engine) _MMIO((engine)->mmio_base + 0x2018) -#define GEN11_VECS_SFC_LOCK_ACK_BIT (1 << 0) -#define GEN11_VECS_SFC_USAGE(engine) _MMIO((engine)->mmio_base + 0x2014) -#define GEN11_VECS_SFC_USAGE_BIT (1 << 0) - -#define GEN12_HCP_SFC_FORCED_LOCK(engine) _MMIO((engine)->mmio_base + 0x2910) -#define GEN12_HCP_SFC_FORCED_LOCK_BITREG_BIT(0) -#define GEN12_HCP_SFC_LOCK_STATUS(engine) _MMIO((engine)->mmio_base + 0x2914) -#define GEN12_HCP_SFC_LOCK_ACK_BIT REG_BIT(1) -#define GEN12_HCP_SFC_USAGE_BIT REG_BIT(0) - #define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000) #define WAIT_FOR_RC6_EXIT _MMIO(0x20CC) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index 59beb69ff6f2..82811df7327b 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -347,25 +347,25 @@ static void get_sfc_forced_lock_data(struct intel_engine_cs *engine, MISSING_CASE(engine->class); fallthrough; case VIDEO_DECODE_CLASS: - sfc_lock->lock_reg = GEN11_VCS_SFC_FORCED_LOCK(engine); + sfc_lock->lock_reg = GEN11_VCS_SFC_FORCED_LOCK(engine->mmio_base); sfc_lock->lock_bit = GEN11_VCS_SFC_FORCED_LOCK_BIT; - sfc_lock->ack_reg = GEN11_VCS_SFC_LOCK_STATUS(engine); + sfc_lock->ack_reg = GEN11_VCS_SFC_LOCK_STATUS(engine->mmio_base); sfc_lock->ack_bit = GEN11_VCS_SFC_LOCK_ACK_BIT; - sfc_lock->usage_reg = GEN11_VCS_SFC_LOCK_STATUS(engine); + sfc_lock->usage_reg =
[Intel-gfx] [PATCH 0/6] More GT register cleanup
Another collection of cleanup patches for intel_gt_regs.h to make it a bit less painful to work with. Cc: Jani Nikula Matt Roper (6): drm/i915/gt: Drop duplicate register definition for VDBOX_CGCTL3F18 drm/i915/gt: Move SFC lock bits to intel_engine_regs.h drm/i915/gt: Use parameterized RING_MI_MODE drm/i915/gt: Cleanup spacing of intel_gt_regs.h drm/i915/gt: Use consistent offset notation in intel_gt_regs.h drm/i915/gt: Order GT registers by MMIO offset drivers/gpu/drm/i915/gt/intel_engine_regs.h | 23 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2623 +-- drivers/gpu/drm/i915/gt/intel_reset.c | 14 +- drivers/gpu/drm/i915/gt/intel_workarounds.c |6 +- drivers/gpu/drm/i915/intel_uncore.c |2 +- 5 files changed, 1333 insertions(+), 1335 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 1/6] drm/i915/gt: Drop duplicate register definition for VDBOX_CGCTL3F18
Due to some mistaken merge conflict resolution, we wound up with a copy of VDBOX_CGCTL3F18 in both intel_engine_regs.h and intel_gt_regs.h. Since this is a per-engine register, referenced relative to an engine's base offset, drop the copy from intel_gt_regs.h Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index a6f0220c2e9f..e73c706e7f0d 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -368,9 +368,6 @@ #define NOPID _MMIO(0x2094) #define HWSTAM _MMIO(0x2098) -#define VDBOX_CGCTL3F18(base) _MMIO((base) + 0x3f18) -#define ALNUNIT_CLKGATE_DIS REG_BIT(13) - #define ERROR_GEN6 _MMIO(0x40a0) #define GEN8_FAULT_TLB_DATA0 _MMIO(0x4b10) -- 2.34.1
Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
On 2/7/22 05:02, Jani Nikula wrote: On Thu, 20 Jan 2022, Casey Bowman wrote: In this RFC I would like to ask the community their thoughts on how we can best handle splitting architecture-specific calls. I would like to address the following: 1. How do we want to split architecture calls? Different object files per platform? Separate function calls within the same object file? 2. How do we address dummy functions? If we have a function call that is used for one or more platforms, but is not used in another, what should we do for this case? I've given an example of splitting an architecture call in my patch with run_as_guest() being split into different implementations for x86 and arm64 in separate object files, sharing a single header. Another suggestion from Michael (michael.ch...@intel.com) involved using a single object file, a single header, and splitting various functions calls via ifdefs in the header file. I would appreciate any input on how we can avoid scaling issues when including multiple architectures and multiple functions (as the number of function calls will inevitably increase with more architectures). Personally I think the functionality is best kept organized by, well, functionality, not by platform. Otherwise the platform files will contain all sorts of code with the only common denominator being the platform. You're also likely to have static platform specific functions, which would needlessly have to be made non-static if the split was by files. I'd just put the implementations for different platforms next to each other: #if IS_ENABLED(CONFIG_X86) ... #elif IS_ENABLED(CONFIG_ARM64) ... #endif Usually the declarations would be identical and there'd only be one, without #ifs in the header. Thanks for the feedback, Jani. I think this is the proper takeaway for future functions that do have separate implementations for differing architectures. As for null behavior, as in the example I gave, I think Tvrtko is right about run_as_guest being a tricky example. I think I need to re-evaluate that function and think of another solution altogether for that instance. I think this will also be the precedent for null cases, where we will need to rethink implementations for cases that don't really have some arch-specific implementation other than returning null (though some exceptions may exist). BR, Jani. Casey Bowman (1): i915/drm: Split out x86 and arm64 functionality drivers/gpu/drm/i915/Makefile | 4 +++ drivers/gpu/drm/i915/i915_drv.h| 6 +--- drivers/gpu/drm/i915/i915_platform.h | 16 +++ drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++ drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++ 5 files changed, 87 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_platform.h create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
Re: [Intel-gfx] [PATCH v5 06/10] drm/i915/guc: Update GuC's log-buffer-state access for error capture.
On Tue, 2022-02-08 at 19:34 -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 02:55:07PM -0800, Teres Alexis, Alan Previn wrote:
> > On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> > > On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > > > Hi Matt, thank you for taking the time to review the codes.
> > > > Answering your question inline below.
> > > >
> > > >
> > > > On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> > > > > On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > > > > > GuC log buffer regions for debug-log-events, crash-dumps and
> > > > > > error-state-capture are all a single bo allocation that includes
> > > > > > the guc_log_buffer_state structures.
> > > > > >
> > > > > > Since the error-capture region is accessed with high priority at
> > > > > > non-
> > > > > > deterministic times (as part of gpu coredump) while the
> > > > > > debug-log-event
> > > > > > region is populated and accessed with different priorities, timings
> > > > > > and
> > > > > > consumers, let's split out separate locks for buffer-state accesses
> > > > > > of each region.
> > > > > >
> > > > > > Also, ensure a global mapping is made up front for the entire bo
> > > > > > throughout GuC operation so that dynamic mapping and unmapping isn't
> > > > > > required for error capture log access if relay-logging isn't
> > > > > > running.
> > > > > >
> > > > > > Additionally, while here, make some readibility improvements:
> > > > > > 1. change previous function names with "capture_logs" to
> > > > > >"copy_debug_logs" to help make the distinction clearer.
> > > > > > 2. Update the guc log region mapping comments to order them
> > > > > >according to the enum definition as per the GuC interface.
> > > > > >
> > > > > > Signed-off-by: Alan Previn
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> > > > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 47 ++
> > > > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
> > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 135
> > > > > > +++---
> > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 16 ++-
> > > > > > 5 files changed, 141 insertions(+), 60 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > index 4e819853ec2e..be1ad7fa2bf8 100644
> > > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > @@ -34,6 +34,8 @@ struct intel_guc {
> > > > > > struct intel_uc_fw fw;
> > > > > > /** @log: sub-structure containing GuC log related data and
> > > > > > objects */
> > > > > > struct intel_guc_log log;
> > > > > > + /** @log_state: states and locks for each subregion of GuC's
> > > > > > log buffer */
> > > > > > + struct intel_guc_log_stats log_state[GUC_MAX_LOG_BUFFER];
> > > > >
> > > > > Why move this? This still probably should be sub-structure of
> > > > > intel_guc_log. Most of the access is from functions that pass in
> > > > > intel_guc_log, then retrieve the GuC object, only to access this new
> > > > > intel_guc_log_stats object. That layering seems wrong, if the argument
> > > > > to a function is intel_guc_log it should really try to access members
> > > > > within that object or below. Obv some exceptions exist but here it
> > > > > seems
> > > > > clear to me this is in the wrong place.
> > > > >
> > > > So the reasoning i had was because because intel_guc_log module only
> > > > managed
> > > > guc-relay-logging and guc-log-dumping for log-events but allocates the
> > > > buffer
> > > > for 3 separate subregion/usages (i.e. log-events, crash-dump and
> > > > error-capture).
> > > > That said, I did not want intel_guc_capture and relay-logging (or
> > > > log-dumping)
> > > > to have to contend with the same lock because these two subregions are
> > > > completely
> > > > independant of each other in terms of when they are being accessed and
> > > > why.
> > > >
> > >
> > > All that is fine, I just think the 'struct intel_guc_log_stats' should
> > > be sub-substure of struct intel_guc_log.
> > >
> > > > However, after the redesign of rev5 (this rev), I now believe the
> > > > intel_guc_capture
> > > > module does not require a lock because its only ever accessing its log
> > > > subregion in response to the ctb handler functions that run out of the
> > > > same queue.
> > > > As we know intel_guc_capture reacts to G2H-error-capture-notification
> > > > and G2H-context-reset
> > > > (that trickles into i915_gpu_coredump). At the point of
> > > > i915_error_state dump,
> > > > intel_guc_capture module does not access the buffer - it merely dumps
> > > > the already-parsed
> > > > and engine-dump-node (that was detached from error-capture's internal
> > > > linked-list
> > > > and attached to the
Re: [Intel-gfx] [PATCH v5 06/10] drm/i915/guc: Update GuC's log-buffer-state access for error capture.
On Tue, Feb 08, 2022 at 07:34:37PM -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 02:55:07PM -0800, Teres Alexis, Alan Previn wrote:
> >
> > On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> > > On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > > > Hi Matt, thank you for taking the time to review the codes.
> > > > Answering your question inline below.
> > > >
> > > >
> > > > On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> > > > > On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > > > > > GuC log buffer regions for debug-log-events, crash-dumps and
> > > > > > error-state-capture are all a single bo allocation that includes
> > > > > > the guc_log_buffer_state structures.
> > > > > >
> > > > > > Since the error-capture region is accessed with high priority at
> > > > > > non-
> > > > > > deterministic times (as part of gpu coredump) while the
> > > > > > debug-log-event
> > > > > > region is populated and accessed with different priorities, timings
> > > > > > and
> > > > > > consumers, let's split out separate locks for buffer-state accesses
> > > > > > of each region.
> > > > > >
> > > > > > Also, ensure a global mapping is made up front for the entire bo
> > > > > > throughout GuC operation so that dynamic mapping and unmapping isn't
> > > > > > required for error capture log access if relay-logging isn't
> > > > > > running.
> > > > > >
> > > > > > Additionally, while here, make some readibility improvements:
> > > > > > 1. change previous function names with "capture_logs" to
> > > > > >"copy_debug_logs" to help make the distinction clearer.
> > > > > > 2. Update the guc log region mapping comments to order them
> > > > > >according to the enum definition as per the GuC interface.
> > > > > >
> > > > > > Signed-off-by: Alan Previn
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> > > > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 47 ++
> > > > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
> > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 135
> > > > > > +++---
> > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 16 ++-
> > > > > > 5 files changed, 141 insertions(+), 60 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > index 4e819853ec2e..be1ad7fa2bf8 100644
> > > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > > @@ -34,6 +34,8 @@ struct intel_guc {
> > > > > > struct intel_uc_fw fw;
> > > > > > /** @log: sub-structure containing GuC log related data and
> > > > > > objects */
> > > > > > struct intel_guc_log log;
> > > > > > + /** @log_state: states and locks for each subregion of GuC's
> > > > > > log buffer */
> > > > > > + struct intel_guc_log_stats log_state[GUC_MAX_LOG_BUFFER];
> > > > >
> > > > > Why move this? This still probably should be sub-structure of
> > > > > intel_guc_log. Most of the access is from functions that pass in
> > > > > intel_guc_log, then retrieve the GuC object, only to access this new
> > > > > intel_guc_log_stats object. That layering seems wrong, if the argument
> > > > > to a function is intel_guc_log it should really try to access members
> > > > > within that object or below. Obv some exceptions exist but here it
> > > > > seems
> > > > > clear to me this is in the wrong place.
> > > > >
> > > > So the reasoning i had was because because intel_guc_log module only
> > > > managed
> > > > guc-relay-logging and guc-log-dumping for log-events but allocates the
> > > > buffer
> > > > for 3 separate subregion/usages (i.e. log-events, crash-dump and
> > > > error-capture).
> > > > That said, I did not want intel_guc_capture and relay-logging (or
> > > > log-dumping)
> > > > to have to contend with the same lock because these two subregions are
> > > > completely
> > > > independant of each other in terms of when they are being accessed and
> > > > why.
> > > >
> > >
> > > All that is fine, I just think the 'struct intel_guc_log_stats' should
> > > be sub-substure of struct intel_guc_log.
> > >
> > > > However, after the redesign of rev5 (this rev), I now believe the
> > > > intel_guc_capture
> > > > module does not require a lock because its only ever accessing its log
> > > > subregion in response to the ctb handler functions that run out of the
> > > > same queue.
> > > > As we know intel_guc_capture reacts to G2H-error-capture-notification
> > > > and G2H-context-reset
> > > > (that trickles into i915_gpu_coredump). At the point of
> > > > i915_error_state dump,
> > > > intel_guc_capture module does not access the buffer - it merely dumps
> > > > the already-parsed
> > > > and engine-dump-node (that was detached from error-capture's internal
> > > > linked-list
> > > > and attached to the
Re: [Intel-gfx] [PATCH v5 06/10] drm/i915/guc: Update GuC's log-buffer-state access for error capture.
On Tue, Feb 08, 2022 at 02:55:07PM -0800, Teres Alexis, Alan Previn wrote:
>
> On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> > On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > > Hi Matt, thank you for taking the time to review the codes.
> > > Answering your question inline below.
> > >
> > >
> > > On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> > > > On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > > > > GuC log buffer regions for debug-log-events, crash-dumps and
> > > > > error-state-capture are all a single bo allocation that includes
> > > > > the guc_log_buffer_state structures.
> > > > >
> > > > > Since the error-capture region is accessed with high priority at non-
> > > > > deterministic times (as part of gpu coredump) while the
> > > > > debug-log-event
> > > > > region is populated and accessed with different priorities, timings
> > > > > and
> > > > > consumers, let's split out separate locks for buffer-state accesses
> > > > > of each region.
> > > > >
> > > > > Also, ensure a global mapping is made up front for the entire bo
> > > > > throughout GuC operation so that dynamic mapping and unmapping isn't
> > > > > required for error capture log access if relay-logging isn't running.
> > > > >
> > > > > Additionally, while here, make some readibility improvements:
> > > > > 1. change previous function names with "capture_logs" to
> > > > >"copy_debug_logs" to help make the distinction clearer.
> > > > > 2. Update the guc log region mapping comments to order them
> > > > >according to the enum definition as per the GuC interface.
> > > > >
> > > > > Signed-off-by: Alan Previn
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> > > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 47 ++
> > > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
> > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 135
> > > > > +++---
> > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 16 ++-
> > > > > 5 files changed, 141 insertions(+), 60 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > index 4e819853ec2e..be1ad7fa2bf8 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > > @@ -34,6 +34,8 @@ struct intel_guc {
> > > > > struct intel_uc_fw fw;
> > > > > /** @log: sub-structure containing GuC log related data and
> > > > > objects */
> > > > > struct intel_guc_log log;
> > > > > + /** @log_state: states and locks for each subregion of GuC's log
> > > > > buffer */
> > > > > + struct intel_guc_log_stats log_state[GUC_MAX_LOG_BUFFER];
> > > >
> > > > Why move this? This still probably should be sub-structure of
> > > > intel_guc_log. Most of the access is from functions that pass in
> > > > intel_guc_log, then retrieve the GuC object, only to access this new
> > > > intel_guc_log_stats object. That layering seems wrong, if the argument
> > > > to a function is intel_guc_log it should really try to access members
> > > > within that object or below. Obv some exceptions exist but here it seems
> > > > clear to me this is in the wrong place.
> > > >
> > > So the reasoning i had was because because intel_guc_log module only
> > > managed
> > > guc-relay-logging and guc-log-dumping for log-events but allocates the
> > > buffer
> > > for 3 separate subregion/usages (i.e. log-events, crash-dump and
> > > error-capture).
> > > That said, I did not want intel_guc_capture and relay-logging (or
> > > log-dumping)
> > > to have to contend with the same lock because these two subregions are
> > > completely
> > > independant of each other in terms of when they are being accessed and
> > > why.
> > >
> >
> > All that is fine, I just think the 'struct intel_guc_log_stats' should
> > be sub-substure of struct intel_guc_log.
> >
> > > However, after the redesign of rev5 (this rev), I now believe the
> > > intel_guc_capture
> > > module does not require a lock because its only ever accessing its log
> > > subregion in response to the ctb handler functions that run out of the
> > > same queue.
> > > As we know intel_guc_capture reacts to G2H-error-capture-notification and
> > > G2H-context-reset
> > > (that trickles into i915_gpu_coredump). At the point of i915_error_state
> > > dump,
> > > intel_guc_capture module does not access the buffer - it merely dumps the
> > > already-parsed
> > > and engine-dump-node (that was detached from error-capture's internal
> > > linked-list
> > > and attached to the gpu_coredump structure in the second G2H above).
> > >
> > > And of course, intel_guc_log only ever accesses the log-events subregion
> > > and never the error-capture regions.
> > >
> > > That said, i could revert the lock structure to the original and not have
> > > intel_guc_capture using
Re: [Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference
> -Original Message-
> From: Łukasz Bartosik
> Sent: Tuesday, February 8, 2022 8:20 AM
> To: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org; upstr...@semihalf.com; Ville Syrjälä
> ; Roper, Matthew D
> ; Srivatsa, Anusha
> Subject: Re: [PATCH v1] drm/i915: fix null pointer dereference
>
> Have you had a chance to review the patch ? The crash is still there
> on v5.17-rc3.
>
> Thanks,
> Lukasz
>
> wt., 1 lut 2022 o 16:49 Jani Nikula napisał(a):
> >
> >
> > Thanks for the patch, adding some Cc's from the commit that regressed.
> >
> > BR,
> > Jani.
> >
> > On Tue, 01 Feb 2022, Lukasz Bartosik wrote:
> > > From: Łukasz Bartosik
> > >
> > > Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
> > > The root cause is null pointer defeference of bi_next
> > > in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.
> > >
> > > BUG: kernel NULL pointer dereference, address: 002e
> > > PGD 0 P4D 0
> > > Oops: 0002 [#1] PREEMPT SMP NOPTI
> > > CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U5.17.0-rc1
> > > Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3
> 05/14/2021
> > > RIP: 0010:tgl_get_bw_info+0x2de/0x510
> > > ...
> > > [2.554467] Call Trace:
> > > [2.554467]
> > > [2.554467] intel_bw_init_hw+0x14a/0x434
> > > [2.554467] ? _printk+0x59/0x73
> > > [2.554467] ? _dev_err+0x77/0x91
> > > [2.554467] i915_driver_hw_probe+0x329/0x33e
> > > [2.554467] i915_driver_probe+0x4c8/0x638
> > > [2.554467] i915_pci_probe+0xf8/0x14e
> > > [2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c
> > > [2.554467] pci_device_probe+0xaa/0x142
> > > [2.554467] really_probe+0x13f/0x2f4
> > > [2.554467] __driver_probe_device+0x9e/0xd3
> > > [2.554467] driver_probe_device+0x24/0x7c
> > > [2.554467] __driver_attach+0xba/0xcf
> > > [2.554467] ? driver_attach+0x1f/0x1f
> > > [2.554467] bus_for_each_dev+0x8c/0xc0
> > > [2.554467] bus_add_driver+0x11b/0x1f7
> > > [2.554467] driver_register+0x60/0xea
> > > [2.554467] ? mipi_dsi_bus_init+0x16/0x16
> > > [2.554467] i915_init+0x2c/0xb9
> > > [2.554467] ? mipi_dsi_bus_init+0x16/0x16
> > > [2.554467] do_one_initcall+0x12e/0x2b3
> > > [2.554467] do_initcall_level+0xd6/0xf3
> > > [2.554467] do_initcalls+0x4e/0x79
> > > [2.554467] kernel_init_freeable+0xed/0x14d
> > > [2.554467] ? rest_init+0xc1/0xc1
> > > [2.554467] kernel_init+0x1a/0x120
> > > [2.554467] ret_from_fork+0x1f/0x30
> > > [2.554467]
> > > ...
> > > Kernel panic - not syncing: Fatal exception
> > >
> > > Fixes: c64a9a7c05be ("drm/i915: Update memory bandwidth formulae")
LGTM,
Reviewed-by: Radhakrishna Sripada
> > > Signed-off-by: Łukasz Bartosik
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.c | 16 +---
> > > 1 file changed, 9 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index 2da4aacc956b..bd0ed68b7faa 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -404,15 +404,17 @@ static int tgl_get_bw_info(struct
> drm_i915_private *dev_priv, const struct intel
> > > int clpchgroup;
> > > int j;
> > >
> > > - if (i < num_groups - 1)
> > > - bi_next = _priv->max_bw[i + 1];
> > > -
> > > clpchgroup = (sa->deburst * qi.deinterleave / num_channels)
> > > << i;
> > >
> > > - if (i < num_groups - 1 && clpchgroup < clperchgroup)
> > > - bi_next->num_planes = (ipqdepth - clpchgroup) /
> > > clpchgroup + 1;
> > > - else
> > > - bi_next->num_planes = 0;
> > > + if (i < num_groups - 1) {
> > > + bi_next = _priv->max_bw[i + 1];
> > > +
> > > + if (clpchgroup < clperchgroup)
> > > + bi_next->num_planes = (ipqdepth -
> > > clpchgroup) /
> > > +clpchgroup + 1;
> > > + else
> > > + bi_next->num_planes = 0;
> > > + }
> > >
> > > bi->num_qgv_points = qi.num_points;
> > > bi->num_psf_gv_points = qi.num_psf_points;
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/tgl+: Implement new PLL programming step
== Series Details == Series: drm/i915/display/tgl+: Implement new PLL programming step URL : https://patchwork.freedesktop.org/series/99867/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22216_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22216_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22216_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22216_full: ### IGT changes ### Possible regressions * igt@gem_mmap_gtt@fault-concurrent-x: - shard-snb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-snb4/igt@gem_mmap_...@fault-concurrent-x.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-snb2/igt@gem_mmap_...@fault-concurrent-x.html * igt@i915_selftest@mock@vma: - shard-skl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-skl7/igt@i915_selftest@m...@vma.html * igt@syncobj_timeline@invalid-transfer-non-existent-point: - shard-apl: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-apl2/igt@syncobj_timel...@invalid-transfer-non-existent-point.html - shard-skl: NOTRUN -> [DMESG-WARN][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-skl8/igt@syncobj_timel...@invalid-transfer-non-existent-point.html * igt@sysfs_heartbeat_interval@mixed@bcs0: - shard-skl: [PASS][6] -> [FAIL][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl6/igt@sysfs_heartbeat_interval@mi...@bcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-skl4/igt@sysfs_heartbeat_interval@mi...@bcs0.html Warnings * igt@i915_pm_dc@dc6-dpms: - shard-kbl: [FAIL][8] ([i915#454]) -> [INCOMPLETE][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl4/igt@i915_pm...@dc6-dpms.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-kbl6/igt@i915_pm...@dc6-dpms.html Known issues Here are the changes found in Patchwork_22216_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][10] ([i915#1839]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-tglb8/igt@feature_discov...@display-4x.html * igt@gem_eio@in-flight-immediate: - shard-tglb: [PASS][11] -> [TIMEOUT][12] ([i915#3063]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb3/igt@gem_...@in-flight-immediate.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-tglb3/igt@gem_...@in-flight-immediate.html * igt@gem_eio@kms: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#232]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb6/igt@gem_...@kms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-tglb2/igt@gem_...@kms.html * igt@gem_exec_balancer@parallel-keep-in-fence: - shard-kbl: NOTRUN -> [DMESG-WARN][15] ([i915#5076]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-kbl1/igt@gem_exec_balan...@parallel-keep-in-fence.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][16] ([i915#2846]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-kbl4/igt@gem_exec_f...@basic-deadline.html - shard-skl: NOTRUN -> [FAIL][17] ([i915#2846]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-skl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][20] -> [FAIL][21] ([i915#2842]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_lmem_swapping@heavy-multi: - shard-apl:
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v6)
Hi Ville,
>
> On Tue, Feb 08, 2022 at 05:10:42AM +, Kasireddy, Vivek wrote:
> > Hi Tvrtko, Ville,
> >
> > > On 07/02/2022 13:24, Ville Syrjälä wrote:
> > > > On Mon, Feb 07, 2022 at 11:47:16AM +, Tvrtko Ursulin wrote:
> > > >>
> > > >> On 07/02/2022 10:58, Ville Syrjälä wrote:
> > > >>> On Thu, Feb 03, 2022 at 05:22:10PM -0800, Vivek Kasireddy wrote:
> > > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2
> > > or more framebuffers/scanout buffers results in only one that is
> > > mappable/ fenceable. Therefore, pageflipping between these 2 FBs
> > > where only one is mappable/fenceable creates latencies large enough
> > > to miss alternate vblanks thereby producing less optimal framerate.
> > >
> > > This mainly happens because when
> > > i915_gem_object_pin_to_display_plane()
> > > is called to pin one of the FB objs, the associated vma is
> > > identified as misplaced and therefore i915_vma_unbind() is called
> > > which unbinds and evicts it. This misplaced vma gets subseqently
> > > pinned only when
> > > i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
> > > results in a latency of ~10ms and happens every other vblank/repaint
> > > cycle.
> > > Therefore, to fix this issue, we try to see if there is space to
> > > map at-least two objects of a given size and return early if there
> > > isn't. This would ensure that we do not try with PIN_MAPPABLE for
> > > any objects that are too big to map thereby preventing unncessary
> > > unbind.
> > >
> > > Testcase:
> > > Running Weston and weston-simple-egl on an Alderlake_S (ADLS)
> > > platform with a 8K@60 mode results in only ~40 FPS. Since upstream
> > > Weston submits a frame ~7ms before the next vblank, the latencies
> > > seen between atomic commit and flip event are 7, 24 (7 + 16.66), 7,
> > > 24. suggesting that it misses the vblank every other frame.
> > >
> > > Here is the ftrace snippet that shows the source of the ~10ms
> > > latency:
> > > i915_gem_object_pin_to_display_plane() {
> > > 0.102 us |i915_gem_object_set_cache_level();
> > > i915_gem_object_ggtt_pin_ww() {
> > > 0.390 us | i915_vma_instance();
> > > 0.178 us | i915_vma_misplaced();
> > > i915_vma_unbind() {
> > > __i915_active_wait() {
> > > 0.082 us |i915_active_acquire_if_busy();
> > > 0.475 us | }
> > > intel_runtime_pm_get() {
> > > 0.087 us |intel_runtime_pm_acquire();
> > > 0.259 us | }
> > > __i915_active_wait() {
> > > 0.085 us |i915_active_acquire_if_busy();
> > > 0.240 us | }
> > > __i915_vma_evict() {
> > > ggtt_unbind_vma() {
> > > gen8_ggtt_clear_range() {
> > > 10507.255 us |}
> > > 10507.689 us | }
> > > 10508.516 us | }
> > >
> > > v2: Instead of using bigjoiner checks, determine whether a scanout
> > > buffer is too big by checking to see if it is possible to map
> > > two of them into the ggtt.
> > >
> > > v3 (Ville):
> > > - Count how many fb objects can be fit into the available holes
> > > instead of checking for a hole twice the object size.
> > > - Take alignment constraints into account.
> > > - Limit this large scanout buffer check to >= Gen 11 platforms.
> > >
> > > v4:
> > > - Remove existing heuristic that checks just for size. (Ville)
> > > - Return early if we find space to map at-least two objects.
> > > (Tvrtko)
> > > - Slightly update the commit message.
> > >
> > > v5: (Tvrtko)
> > > - Rename the function to indicate that the object may be too big to
> > > map into the aperture.
> > > - Account for guard pages while calculating the total size required
> > > for the object.
> > > - Do not subject all objects to the heuristic check and instead
> > > consider objects only of a certain size.
> > > - Do the hole walk using the rbtree.
> > > - Preserve the existing PIN_NONBLOCK logic.
> > > - Drop the PIN_MAPPABLE check while pinning the VMA.
> > >
> > > v6: (Tvrtko)
> > > - Return 0 on success and the specific error code on failure to
> > > preserve the existing behavior.
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Maarten Lankhorst
> > > Cc: Tvrtko Ursulin
> > > Cc: Manasi Navare
> > > Signed-off-by: Vivek Kasireddy
> > > ---
> > > drivers/gpu/drm/i915/i915_gem.c | 120
> > > -
> ---
> > > 1 file changed, 90 insertions(+),
[Intel-gfx] ✗ Fi.CI.IGT: failure for GuC HWCONFIG with documentation (rev3)
== Series Details == Series: GuC HWCONFIG with documentation (rev3) URL : https://patchwork.freedesktop.org/series/99787/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22214_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22214_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22214_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22214_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@vma: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-skl2/igt@i915_selftest@m...@vma.html * igt@syncobj_timeline@invalid-transfer-non-existent-point: - shard-apl: NOTRUN -> [DMESG-WARN][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-apl7/igt@syncobj_timel...@invalid-transfer-non-existent-point.html - shard-skl: NOTRUN -> [DMESG-WARN][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-skl4/igt@syncobj_timel...@invalid-transfer-non-existent-point.html Known issues Here are the changes found in Patchwork_22214_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][4] ([i915#1839]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-tglb8/igt@feature_discov...@display-4x.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-apl7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_balancer@parallel-balancer: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#4525]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-iclb3/igt@gem_exec_balan...@parallel-balancer.html * igt@gem_exec_balancer@parallel-keep-in-fence: - shard-kbl: NOTRUN -> [DMESG-WARN][9] ([i915#5076]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-kbl6/igt@gem_exec_balan...@parallel-keep-in-fence.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-skl8/igt@gem_exec_f...@basic-deadline.html - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk1/igt@gem_exec_f...@basic-deadline.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-glk5/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_lmem_swapping@heavy-multi: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-apl7/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@heavy-verify-random: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/shard-skl2/igt@gem_lmem_swapp...@heavy-verify-random.html * igt@gem_pxp@create-protected-buffer: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#4270]) [20]:
Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Use a single pass to calculate regset
On 2/7/2022 11:01 PM, Lucas De Marchi wrote:
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
each register needs to be added and moved in the final array. The second
phase may actually happen in IO memory rather than system memory and
accessing IO memory by simply dereferencing the pointer doesn't work on
all architectures. Other places of the ADS initializaition were
converted to use the iosys_map API, but here there may be a lot more
accesses to IO memory. So, instead of following that same approach,
convert the regset initialization to calculate the final array in 1
pass and in the second pass that array is just copied to its final
location, updating the pointers for each engine written to the ADS blob.
One important thing is that struct temp_regset now have
different semantics: `registers` continues to track the registers of a
single engine, however the other fields are updated together, according
to the newly added `storage`, which tracks the memory allocated for
all the registers. So rename some of these fields and add a
__mmio_reg_add(): this function (possibly) allocates memory and operates
on the storage pointer while guc_mmio_reg_add() continues to manage the
registers pointer.
On a Tiger Lake system using enable_guc=3, the following log message is
now seen:
[ 187.334310] i915 :00:02.0: [drm:intel_guc_ads_create [i915]]
Used 4 KB for temporary ADS regset
This change has also been tested on an ARM64 host with DG2 and other
discrete graphics cards.
v2 (Daniele):
- Fix leaking tempset on error path
- Add comments on struct temp_regset to document the meaning of each
field
Cc: Matt Roper
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 7 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 128 +
2 files changed, 90 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 697d9d66acef..9d779de16613 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -150,6 +150,13 @@ struct intel_guc {
struct __guc_ads_blob *ads_blob;
/** @ads_regset_size: size of the save/restore regsets in the ADS */
u32 ads_regset_size;
+ /**
+* @ads_regset_count: number of save/restore registers in the ADS for
+* each engine
+*/
+ u32 ads_regset_count[I915_NUM_ENGINES];
+ /** @ads_regset: save/restore regsets in the ADS */
+ struct guc_mmio_reg *ads_regset;
/** @ads_golden_ctxt_size: size of the golden contexts in the ADS */
u32 ads_golden_ctxt_size;
/** @ads_engine_usage_size: size of engine usage in the ADS */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 5290253b9132..7e41175618f5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -208,14 +208,18 @@ static void guc_mapping_table_init(struct intel_gt *gt,
/*
* The save/restore register list must be pre-calculated to a temporary
- * buffer of driver defined size before it can be generated in place
- * inside the ADS.
+ * buffer before it can be copied inside the ADS.
*/
-#define MAX_MMIO_REGS 128 /* Arbitrary size, increase as needed */
struct temp_regset {
+ /*
+* ptr to the section of the storage for the engine currently being
+* worked on
+*/
struct guc_mmio_reg *registers;
- u32 used;
- u32 size;
+ /* ptr to the base of the allocated storage for all engines */
+ struct guc_mmio_reg *storage;
+ u32 storage_used;
+ u32 storage_max;
};
static int guc_mmio_reg_cmp(const void *a, const void *b)
@@ -226,18 +230,44 @@ static int guc_mmio_reg_cmp(const void *a, const void *b)
return (int)ra->offset - (int)rb->offset;
}
+static struct guc_mmio_reg * __must_check
+__mmio_reg_add(struct temp_regset *regset, struct guc_mmio_reg *reg)
+{
+ u32 pos = regset->storage_used;
+ struct guc_mmio_reg *slot;
+
+ if (pos >= regset->storage_max) {
+ size_t size = ALIGN((pos + 1) * sizeof(*slot), PAGE_SIZE);
+ struct guc_mmio_reg *r = krealloc(regset->storage,
+ size, GFP_KERNEL);
+ if (!r) {
+ WARN_ONCE(1, "Incomplete regset list: can't add register
(%d)\n",
+ -ENOMEM);
+ return ERR_PTR(-ENOMEM);
+ }
+
+
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Prepare for error propagation
On 2/7/2022 11:01 PM, Lucas De Marchi wrote:
Currently guc_mmio_reg_add() relies on having enough memory available in
the array to add a new slot. It uses
`GEM_BUG_ON(count >= regset->size);` to protect going above the
threshold.
In order to allow guc_mmio_reg_add() to handle the memory allocation by
itself, it must return an error in case of failures. Adjust return code
so this error can be propagated to the callers of guc_mmio_reg_add() and
guc_mmio_regset_init().
No intended change in behavior.
Cc: Matt Roper
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 31 +-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index e61150adcbe9..5290253b9132 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -226,8 +226,8 @@ static int guc_mmio_reg_cmp(const void *a, const void *b)
return (int)ra->offset - (int)rb->offset;
}
-static void guc_mmio_reg_add(struct temp_regset *regset,
-u32 offset, u32 flags)
+static long __must_check guc_mmio_reg_add(struct temp_regset *regset,
+ u32 offset, u32 flags)
{
u32 count = regset->used;
struct guc_mmio_reg reg = {
@@ -246,7 +246,7 @@ static void guc_mmio_reg_add(struct temp_regset *regset,
*/
if (bsearch(, regset->registers, count,
sizeof(reg), guc_mmio_reg_cmp))
- return;
+ return 0;
slot = >registers[count];
regset->used++;
@@ -259,6 +259,8 @@ static void guc_mmio_reg_add(struct temp_regset *regset,
swap(slot[1], slot[0]);
}
+
+ return 0;
}
#define GUC_MMIO_REG_ADD(regset, reg, masked) \
@@ -266,32 +268,35 @@ static void guc_mmio_reg_add(struct temp_regset *regset,
i915_mmio_reg_offset((reg)), \
(masked) ? GUC_REGSET_MASKED : 0)
-static void guc_mmio_regset_init(struct temp_regset *regset,
-struct intel_engine_cs *engine)
+static int guc_mmio_regset_init(struct temp_regset *regset,
+ struct intel_engine_cs *engine)
{
const u32 base = engine->mmio_base;
struct i915_wa_list *wal = >wa_list;
struct i915_wa *wa;
unsigned int i;
+ int ret = 0;
regset->used = 0;
- GUC_MMIO_REG_ADD(regset, RING_MODE_GEN7(base), true);
- GUC_MMIO_REG_ADD(regset, RING_HWS_PGA(base), false);
- GUC_MMIO_REG_ADD(regset, RING_IMR(base), false);
+ ret |= GUC_MMIO_REG_ADD(regset, RING_MODE_GEN7(base), true);
+ ret |= GUC_MMIO_REG_ADD(regset, RING_HWS_PGA(base), false);
+ ret |= GUC_MMIO_REG_ADD(regset, RING_IMR(base), false);
I was thinking we could modify this to break after the first error
because if a realloc fails it's unlikely a second one immediately after
will succeed, but on the other side it doesn't really matter and the
code is simpler like this, so:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
- GUC_MMIO_REG_ADD(regset, wa->reg, wa->masked_reg);
+ ret |= GUC_MMIO_REG_ADD(regset, wa->reg, wa->masked_reg);
/* Be extra paranoid and include all whitelist registers. */
for (i = 0; i < RING_MAX_NONPRIV_SLOTS; i++)
- GUC_MMIO_REG_ADD(regset,
-RING_FORCE_TO_NONPRIV(base, i),
-false);
+ ret |= GUC_MMIO_REG_ADD(regset,
+ RING_FORCE_TO_NONPRIV(base, i),
+ false);
/* add in local MOCS registers */
for (i = 0; i < GEN9_LNCFCMOCS_REG_COUNT; i++)
- GUC_MMIO_REG_ADD(regset, GEN9_LNCFCMOCS(i), false);
+ ret |= GUC_MMIO_REG_ADD(regset, GEN9_LNCFCMOCS(i), false);
+
+ return ret ? -1 : 0;
}
static int guc_mmio_reg_state_query(struct intel_guc *guc)
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
include/linux/dma-buf-map.h
between commit:
e8c1f36157ce ("dma-buf-map: Fix dot vs comma in example")
from the drm tree and commit:
7938f4218168 ("dma-buf-map: Rename to iosys-map")
from the drm-intel tree.
I fixed it up (I just removed the file - the changes from the former
commit are only on comments) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
pgp5Wl5oLwI4T.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.IGT: failure for discrete card 64K page support (rev6)
== Series Details == Series: discrete card 64K page support (rev6) URL : https://patchwork.freedesktop.org/series/99119/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22213_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22213_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22213_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22213_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@vma: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@i915_selftest@m...@vma.html * igt@kms_cursor_legacy@pipe-c-torture-bo: - shard-iclb: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@kms_cursor_leg...@pipe-c-torture-bo.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb6/igt@kms_cursor_leg...@pipe-c-torture-bo.html * igt@syncobj_timeline@invalid-transfer-non-existent-point: - shard-skl: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@syncobj_timel...@invalid-transfer-non-existent-point.html Known issues Here are the changes found in Patchwork_22213_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#1839]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@feature_discov...@display-4x.html * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl6/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_exec_capture@pi@rcs0: - shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#3371]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb6/igt@gem_exec_capture@p...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb2/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_capture@pi@vcs0: - shard-iclb: [PASS][10] -> [INCOMPLETE][11] ([i915#3371]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb1/igt@gem_exec_capture@p...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@gem_exec_capture@p...@vcs0.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@gem_exec_f...@basic-deadline.html - shard-skl: NOTRUN -> [FAIL][13] ([i915#2846]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@gem_exec_f...@basic-deadline.html - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2846]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk1/igt@gem_exec_f...@basic-deadline.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: NOTRUN -> [FAIL][18] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_params@no-vebox: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109283]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_exec_par...@no-vebox.html * igt@gem_lmem_swapping@heavy-verify-random: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@gem_lmem_swapp...@heavy-verify-random.html * igt@gem_lmem_swapping@random-engines: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#4613]) [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/tgl+: Implement new PLL programming step
== Series Details ==
Series: drm/i915/display/tgl+: Implement new PLL programming step
URL : https://patchwork.freedesktop.org/series/99867/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22216
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/index.html
Participating hosts (46 -> 43)
--
Missing(3): fi-bsw-cyan bat-jsl-2 shard-tglu
Known issues
Here are the changes found in Patchwork_22216 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][2] -> [DMESG-WARN][3] ([i915#4269])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][4] ([i915#2426] / [i915#4312])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [INCOMPLETE][5] ([i915#146]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][7] ([i915#4785]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: [DMESG-WARN][9] -> [DMESG-WARN][10] ([i915#1610])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-apl-guc/igt@debugfs_test@read_all_entries.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/fi-apl-guc/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][11] ([i915#4957]) -> [DMESG-FAIL][12]
([i915#4494] / [i915#4957])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
Build changes
-
* Linux: CI_DRM_11205 -> Patchwork_22216
CI-20190529: 20190529
CI_DRM_11205: c764a7571bebed03bec481d6fffcb23144fe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22216: 2f56199b030165ee565961de04328d967d0483d9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2f56199b0301 drm/i915/display/tgl+: Implement new PLL programming step
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22216/index.html
Re: [Intel-gfx] [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
On 2/8/22 22:08, Daniel Vetter wrote:
> This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
>
> With
>
> commit 27599aacbaefcbf2af7b06b0029459bbf682000d
> Author: Thomas Zimmermann
> Date: Tue Jan 25 10:12:18 2022 +0100
>
> fbdev: Hot-unplug firmware fb devices on forced removal
>
> this should be fixed properly and we can remove this somewhat hackish
> check here (e.g. this won't catch drm drivers if fbdev emulation isn't
> enabled).
>
Unfortunately this hack can't be reverted yet. Thomas' patch solves the issue
of platform devices matched with fbdev drivers to be properly unregistered if
a DRM driver attempts to remove all the conflicting framebuffers.
But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers if
a FB is already registered") worked around is different. It happens when the
DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
kicking out of conflicting framebuffers already happened and these drivers
will be allowed to probe even when a DRM driver is already present.
We need a clearer way to prevent it, but can't revert fb561bf9abde until that.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [Intel-gfx] [PATCH v2 06/19] fbcon: Use delayed work for cursor
Hello Daniel,
On 2/8/22 22:08, Daniel Vetter wrote:
> Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
> code we initialize the cursor_work completely when we allocate the
> fbcon_ops structure, instead of trying to cope with console
> re-initialization.
>
Maybe also make it more explicit in the commit message that the delayed
work is replacing a timer that was used before for the cursor ?
> The motiviation here is that fbcon code stops using the fb_info.queue,
motivation
[snip]
> /*
> *This is the interface between the low-level console driver and the
> @@ -68,7 +68,7 @@ struct fbcon_ops {
> int (*update_start)(struct fb_info *info);
> int (*rotate_font)(struct fb_info *info, struct vc_data *vc);
> struct fb_var_screeninfo var; /* copy of the current fb_var_screeninfo
> */
> - struct timer_list cursor_timer; /* Cursor timer */
> + struct delayed_work cursor_work; /* Cursor timer */
A delayed_work uses a timer underneath but I wonder if the comment also
needs to be updated since technically isn't a timer anymore but deferred
work that gets re-scheduled each time on fb_flashcursor().
The patch looks good to me and makes the logic much simpler than before.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display/tgl+: Implement new PLL programming step
== Series Details == Series: drm/i915/display/tgl+: Implement new PLL programming step URL : https://patchwork.freedesktop.org/series/99867/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/tgl+: Implement new PLL programming step
== Series Details == Series: drm/i915/display/tgl+: Implement new PLL programming step URL : https://patchwork.freedesktop.org/series/99867/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2f56199b0301 drm/i915/display/tgl+: Implement new PLL programming step -:50: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #50: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:2753: + pll_state->div0 = TGL_DPLL0_DIV0_AFC_STARTUP(TGL_DPLL0_DIV0_AFC_STARTUP_OVERRIDE_VAL); -:59: WARNING:LONG_LINE: line length of 116 exceeds 100 columns #59: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:2956: + pll_state->mg_pll_div0 |= DKL_PLL_DIV0_AFC_STARTUP(TGL_DPLL0_DIV0_AFC_STARTUP_OVERRIDE_VAL); -:196: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #196: FILE: drivers/gpu/drm/i915/i915_reg.h:7991: +#define TGL_DPLL0_DIV0(pll)_MMIO_PLL(pll, _TGL_DPLL0_DIV0, _TGL_DPLL1_DIV0) -:198: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #198: FILE: drivers/gpu/drm/i915/i915_reg.h:7993: +#define TGL_DPLL0_DIV0_AFC_STARTUP(val) REG_FIELD_PREP(TGL_DPLL0_DIV0_AFC_STARTUP_MASK, (val)) total: 0 errors, 4 warnings, 0 checks, 160 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for fbcon patches, take two
== Series Details ==
Series: fbcon patches, take two
URL : https://patchwork.freedesktop.org/series/99865/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22215
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22215 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22215, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/index.html
Participating hosts (46 -> 42)
--
Missing(4): fi-bsw-cyan bat-jsl-2 shard-tglu fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22215:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22215 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#109315]) +17
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
- fi-bdw-5557u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271]) +21 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][10] -> [DMESG-WARN][11] ([i915#4269])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][13] ([fdo#109271]) +13 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
* igt@runner@aborted:
- fi-icl-u2: NOTRUN -> [FAIL][14] ([i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-icl-u2/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [INCOMPLETE][15] ([i915#146]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
- {bat-rpls-1}: [INCOMPLETE][17] ([i915#4898]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22215/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [FAIL][19] ([i915#4547]) -> [PASS][20]
[19]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fbcon patches, take two
== Series Details == Series: fbcon patches, take two URL : https://patchwork.freedesktop.org/series/99865/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 0/2] drm/i915/guc: Use temporary memory for regset
It looks like for this series I forgot to Cc dri-devel, although these patches are the same as the ones in https://patchwork.freedesktop.org/series/99711/, just extracted since not dependent on the iosys-map discussion. Lucas De Marchi On Mon, Feb 07, 2022 at 11:01:39PM -0800, Lucas De Marchi wrote: Extract the 2 commits not related to iosys_map from drm/i915/guc: Refactor ADS access to use iosys_map (https://patchwork.freedesktop.org/series/99711/). The conversion of the rest of ADS initializon will take more time to review. So let's take these by themselves as suggested by Daniele. Lucas De Marchi (2): drm/i915/guc: Prepare for error propagation drm/i915/guc: Use a single pass to calculate regset drivers/gpu/drm/i915/gt/uc/intel_guc.h | 7 + drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 159 + 2 files changed, 108 insertions(+), 58 deletions(-) -- 2.35.1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fbcon patches, take two
== Series Details ==
Series: fbcon patches, take two
URL : https://patchwork.freedesktop.org/series/99865/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2d681145150e fbcon: delete a few unneeded forward decl
-:65: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 38 lines checked
19ba8aad9437 fbcon: Move fbcon_bmove(_rec) functions
-:184: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 157 lines checked
ffdf84522741 fbcon: Introduce wrapper for console->fb_info lookup
-:333: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 274 lines checked
92e96e00ac25 fbcon: delete delayed loading code
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6104c37094e7 ("fbcon: Make fbcon
a built-time depency for fbdev")'
#8:
commit 6104c37094e729f3d4ce65797002112735d49cd1
-:68: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 25 lines checked
74265731b7af fbdev/sysfs: Fix locking
-:40: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 11 lines checked
a592364a0bdb fbcon: Use delayed work for cursor
-:281: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 229 lines checked
c09c3011a9cf fbcon: Replace FBCON_FLAGS_INIT with a boolean
-:89: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 57 lines checked
807d95275bfd fb: Delete fb_info->queue
-:25: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 7 lines checked
0e6fba249ed1 fbcon: Extract fbcon_open/release helpers
-:127: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines
#127: FILE: drivers/video/fbdev/core/fbcon.c:759:
+ /*
+ If oldinfo and newinfo are driving the same hardware,
-:142: WARNING:PREFER_PR_LEVEL: Prefer [subsystem eg:
netdev]_err([subsystem]dev, ... then dev_err(dev, ... then pr_err(... to
printk(KERN_ERR ...
#142: FILE: drivers/video/fbdev/core/fbcon.c:769:
+ printk(KERN_ERR "con2fb_release_oldinfo: "
-:142: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to
using 'con2fb_release_oldinfo', this function's name, in a string
#142: FILE: drivers/video/fbdev/core/fbcon.c:769:
+ printk(KERN_ERR "con2fb_release_oldinfo: "
-:199: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 4 warnings, 0 checks, 164 lines checked
bd6d6ad767b9 fbcon: Ditch error handling for con2fb_release_oldinfo
-:101: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 75 lines checked
47a2d657d082 fbcon: move more common code into fb_open()
-:61: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*ops)...) over
kzalloc(sizeof(struct fbcon_ops)...)
#61: FILE: drivers/video/fbdev/core/fbcon.c:706:
+ ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
-:162: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 1 checks, 122 lines checked
07a98b03a1c7 fbcon: use lock_fb_info in fbcon_open/release
-:94: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 42 lines checked
1aece9d971a7 fbcon: Consistently protect deferred_takeover with console_lock()
-:43: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 17 lines checked
68aaba46c7ef fbcon: Move console_lock for register/unlink/unregister
-:87: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#87: FILE: drivers/video/fbdev/core/fbcon.c:2903:
+MODULE_PARM_DESC(lockless_register_fb,
+ "Lockless framebuffer registration for debugging
[Intel-gfx] ✓ Fi.CI.BAT: success for GuC HWCONFIG with documentation (rev3)
== Series Details ==
Series: GuC HWCONFIG with documentation (rev3)
URL : https://patchwork.freedesktop.org/series/99787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22214
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/index.html
Participating hosts (46 -> 42)
--
Missing(4): fi-bsw-cyan bat-jsl-2 shard-tglu fi-kbl-8809g
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22214:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_hangman@error-state-basic:
- {bat-adlp-6}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-adlp-6/igt@i915_hang...@error-state-basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/bat-adlp-6/igt@i915_hang...@error-state-basic.html
Known issues
Here are the changes found in Patchwork_22214 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#109315]) +17
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][4] -> [INCOMPLETE][5] ([i915#4547])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_pm_rpm@module-reload:
- fi-icl-u2: [PASS][6] -> [FAIL][7] ([i915#3049])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-icl-u2/igt@i915_pm_...@module-reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-icl-u2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@hangcheck:
- fi-icl-u2: [PASS][8] -> [DMESG-WARN][9] ([i915#2867]) +5 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#295]) +12
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][12] ([i915#2426] / [i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [INCOMPLETE][13] ([i915#146]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][15] ([i915#4785]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: [DMESG-WARN][17] -> [DMESG-WARN][18] ([i915#1610])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-apl-guc/igt@debugfs_test@read_all_entries.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/fi-apl-guc/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][19] ([i915#4957]) -> [DMESG-FAIL][20]
([i915#4494] / [i915#4957])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22214/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#1610]:
Re: [Intel-gfx] [PATCH v2 03/18] drm/i915/gt: Add helper for shmem copy to iosys_map
On Tue, Feb 08, 2022 at 02:45:09AM -0800, Lucas De Marchi wrote:
> Add a variant of shmem_read() that takes a iosys_map pointer rather
> than a plain pointer as argument. It's mostly a copy __shmem_rw() but
> adapting the api and removing the write support since there's currently
> only need to use iosys_map as destination.
>
> Reworking __shmem_rw() to share the implementation was tempting, but
> finding a good balance between reuse and clarity pushed towards a little
> code duplication. Since the function is small, just add the similar
> function with a copy/paste/adapt approach.
>
> v2: Add an offset as argument and instead of using a map iterator, use the
> offset to keep track of where we are writing data to.
>
> Cc: Matt Roper
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthew Auld
> Cc: Thomas Hellström
> Cc: Maarten Lankhorst
Reviewed-by: Matt Atwood
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/shmem_utils.c | 32 +++
> drivers/gpu/drm/i915/gt/shmem_utils.h | 3 +++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
> b/drivers/gpu/drm/i915/gt/shmem_utils.c
> index 0683b27a3890..402f085f3a02 100644
> --- a/drivers/gpu/drm/i915/gt/shmem_utils.c
> +++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
> @@ -3,6 +3,7 @@
> * Copyright © 2020 Intel Corporation
> */
>
> +#include
> #include
> #include
> #include
> @@ -123,6 +124,37 @@ static int __shmem_rw(struct file *file, loff_t off,
> return 0;
> }
>
> +int shmem_read_to_iosys_map(struct file *file, loff_t off,
> + struct iosys_map *map, size_t map_off, size_t len)
> +{
> + unsigned long pfn;
> +
> + for (pfn = off >> PAGE_SHIFT; len; pfn++) {
> + unsigned int this =
> + min_t(size_t, PAGE_SIZE - offset_in_page(off), len);
> + struct page *page;
> + void *vaddr;
> +
> + page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
> +GFP_KERNEL);
> + if (IS_ERR(page))
> + return PTR_ERR(page);
> +
> + vaddr = kmap(page);
> + iosys_map_memcpy_to(map, map_off, vaddr + offset_in_page(off),
> + this);
> + mark_page_accessed(page);
> + kunmap(page);
> + put_page(page);
> +
> + len -= this;
> + map_off += this;
> + off = 0;
> + }
> +
> + return 0;
> +}
> +
> int shmem_read(struct file *file, loff_t off, void *dst, size_t len)
> {
> return __shmem_rw(file, off, dst, len, false);
> diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.h
> b/drivers/gpu/drm/i915/gt/shmem_utils.h
> index c1669170c351..b2b04d88c6e5 100644
> --- a/drivers/gpu/drm/i915/gt/shmem_utils.h
> +++ b/drivers/gpu/drm/i915/gt/shmem_utils.h
> @@ -8,6 +8,7 @@
>
> #include
>
> +struct iosys_map;
> struct drm_i915_gem_object;
> struct file;
>
> @@ -17,6 +18,8 @@ struct file *shmem_create_from_object(struct
> drm_i915_gem_object *obj);
> void *shmem_pin_map(struct file *file);
> void shmem_unpin_map(struct file *file, void *ptr);
>
> +int shmem_read_to_iosys_map(struct file *file, loff_t off,
> + struct iosys_map *map, size_t map_off, size_t len);
> int shmem_read(struct file *file, loff_t off, void *dst, size_t len);
> int shmem_write(struct file *file, loff_t off, void *src, size_t len);
>
> --
> 2.35.1
>
Re: [Intel-gfx] [PATCH v2 02/19] fbcon: Move fbcon_bmove(_rec) functions
On 2/8/22 22:08, Daniel Vetter wrote: > Avoids two forward declarations, and more importantly, matches what > I've done in my fbcon scrolling restore patches - so I need this to > avoid a bunch of conflicts in rebasing since we ended up merging > Helge's series instead. > > Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [Intel-gfx] [PATCH v5 06/10] drm/i915/guc: Update GuC's log-buffer-state access for error capture.
On Tue, 2022-02-08 at 14:18 -0800, Matthew Brost wrote:
> On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> > Hi Matt, thank you for taking the time to review the codes.
> > Answering your question inline below.
> >
> >
> > On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> > > On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > > > GuC log buffer regions for debug-log-events, crash-dumps and
> > > > error-state-capture are all a single bo allocation that includes
> > > > the guc_log_buffer_state structures.
> > > >
> > > > Since the error-capture region is accessed with high priority at non-
> > > > deterministic times (as part of gpu coredump) while the debug-log-event
> > > > region is populated and accessed with different priorities, timings and
> > > > consumers, let's split out separate locks for buffer-state accesses
> > > > of each region.
> > > >
> > > > Also, ensure a global mapping is made up front for the entire bo
> > > > throughout GuC operation so that dynamic mapping and unmapping isn't
> > > > required for error capture log access if relay-logging isn't running.
> > > >
> > > > Additionally, while here, make some readibility improvements:
> > > > 1. change previous function names with "capture_logs" to
> > > >"copy_debug_logs" to help make the distinction clearer.
> > > > 2. Update the guc log region mapping comments to order them
> > > >according to the enum definition as per the GuC interface.
> > > >
> > > > Signed-off-by: Alan Previn
> > > > ---
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 47 ++
> > > > .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 135 +++---
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 16 ++-
> > > > 5 files changed, 141 insertions(+), 60 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > index 4e819853ec2e..be1ad7fa2bf8 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > @@ -34,6 +34,8 @@ struct intel_guc {
> > > > struct intel_uc_fw fw;
> > > > /** @log: sub-structure containing GuC log related data and objects
> > > > */
> > > > struct intel_guc_log log;
> > > > + /** @log_state: states and locks for each subregion of GuC's log
> > > > buffer */
> > > > + struct intel_guc_log_stats log_state[GUC_MAX_LOG_BUFFER];
> > >
> > > Why move this? This still probably should be sub-structure of
> > > intel_guc_log. Most of the access is from functions that pass in
> > > intel_guc_log, then retrieve the GuC object, only to access this new
> > > intel_guc_log_stats object. That layering seems wrong, if the argument
> > > to a function is intel_guc_log it should really try to access members
> > > within that object or below. Obv some exceptions exist but here it seems
> > > clear to me this is in the wrong place.
> > >
> > So the reasoning i had was because because intel_guc_log module only managed
> > guc-relay-logging and guc-log-dumping for log-events but allocates the
> > buffer
> > for 3 separate subregion/usages (i.e. log-events, crash-dump and
> > error-capture).
> > That said, I did not want intel_guc_capture and relay-logging (or
> > log-dumping)
> > to have to contend with the same lock because these two subregions are
> > completely
> > independant of each other in terms of when they are being accessed and why.
> >
>
> All that is fine, I just think the 'struct intel_guc_log_stats' should
> be sub-substure of struct intel_guc_log.
>
> > However, after the redesign of rev5 (this rev), I now believe the
> > intel_guc_capture
> > module does not require a lock because its only ever accessing its log
> > subregion in response to the ctb handler functions that run out of the same
> > queue.
> > As we know intel_guc_capture reacts to G2H-error-capture-notification and
> > G2H-context-reset
> > (that trickles into i915_gpu_coredump). At the point of i915_error_state
> > dump,
> > intel_guc_capture module does not access the buffer - it merely dumps the
> > already-parsed
> > and engine-dump-node (that was detached from error-capture's internal
> > linked-list
> > and attached to the gpu_coredump structure in the second G2H above).
> >
> > And of course, intel_guc_log only ever accesses the log-events subregion
> > and never the error-capture regions.
> >
> > That said, i could revert the lock structure to the original and not have
> > intel_guc_capture using locks. What do you think?
> >
>
> Again my comment has nothing to do with locking, it is where the
> structure lives.
>
>
IMHO, based on my understanding of the codes and the GuC interface,
i see intel_guc_log and intel_guc_capture as 2 subsystems at equal level
under the intel_guc framework.
Re: [Intel-gfx] [PATCH v2 02/18] iosys-map: Add a few more helpers
On Tue, Feb 08, 2022 at 02:45:08AM -0800, Lucas De Marchi wrote:
> First the simplest ones:
>
> - iosys_map_memset(): when abstracting system and I/O memory,
> just like the memcpy() use case, memset() also has dedicated
> functions to be called for using IO memory.
> - iosys_map_memcpy_from(): we may need to copy data from I/O
> memory, not only to.
>
> In certain situations it's useful to be able to read or write to an
> offset that is calculated by having the memory layout given by a struct
> declaration. Usually we are going to read/write a u8, u16, u32 or u64.
>
> As a pre-requisite for the implementation, add iosys_map_memcpy_from()
> to be the equivalent of iosys_map_memcpy_to(), but in the other
> direction. Then add 2 pairs of macros:
>
> - iosys_map_rd() / iosys_map_wr()
> - iosys_map_rd_field() / iosys_map_wr_field()
>
> The first pair takes the C-type and offset to read/write. The second
> pair uses a struct describing the layout of the mapping in order to
> calculate the offset and size being read/written.
>
> We could use readb, readw, readl, readq and the write* counterparts,
> however due to alignment issues this may not work on all architectures.
> If alignment needs to be checked to call the right function, it's not
> possible to decide at compile-time which function to call: so just leave
> the decision to the memcpy function that will do exactly that.
>
> Finally, in order to use the above macros with a map derived from
> another, add another initializer: IOSYS_MAP_INIT_OFFSET().
>
> v2:
> - Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules
> within the union
> - Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to
> allow the struct itself to be at an offset from the mapping
> - Add documentation to iosys_map_rd_field() with example and expected
> memory layout
>
> Cc: Sumit Semwal
> Cc: Christian König
> Cc: Thomas Zimmermann
> Cc: Mauro Carvalho Chehab
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
Reviewed-by: Matt Atwood
> Signed-off-by: Lucas De Marchi
> ---
> include/linux/iosys-map.h | 202 ++
> 1 file changed, 202 insertions(+)
>
> diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
> index edd730b1e899..c6b223534b21 100644
> --- a/include/linux/iosys-map.h
> +++ b/include/linux/iosys-map.h
> @@ -6,6 +6,7 @@
> #ifndef __IOSYS_MAP_H__
> #define __IOSYS_MAP_H__
>
> +#include
> #include
> #include
>
> @@ -120,6 +121,45 @@ struct iosys_map {
> .is_iomem = false, \
> }
>
> +/**
> + * IOSYS_MAP_INIT_OFFSET - Initializes struct iosys_map from another
> iosys_map
> + * @map_:The dma-buf mapping structure to copy from
> + * @offset_: Offset to add to the other mapping
> + *
> + * Initializes a new iosys_map struct based on another passed as argument. It
> + * does a shallow copy of the struct so it's possible to update the back
> storage
> + * without changing where the original map points to. It is the equivalent of
> + * doing:
> + *
> + * .. code-block:: c
> + *
> + * iosys_map map = other_map;
> + * iosys_map_incr(, );
> + *
> + * Example usage:
> + *
> + * .. code-block:: c
> + *
> + * void foo(struct device *dev, struct iosys_map *base_map)
> + * {
> + * ...
> + * struct iosys_map map = IOSYS_MAP_INIT_OFFSET(base_map,
> FIELD_OFFSET);
> + * ...
> + * }
> + *
> + * The advantage of using the initializer over just increasing the offset
> with
> + * iosys_map_incr() like above is that the new map will always point to the
> + * right place of the buffer during its scope. It reduces the risk of
> updating
> + * the wrong part of the buffer and having no compiler warning about that. If
> + * the assignment to IOSYS_MAP_INIT_OFFSET() is forgotten, the compiler can
> warn
> + * about the use of uninitialized variable.
> + */
> +#define IOSYS_MAP_INIT_OFFSET(map_, offset_) ({
> \
> + struct iosys_map copy = *map_; \
> + iosys_map_incr(, offset_); \
> + copy; \
> +})
> +
> /**
> * iosys_map_set_vaddr - Sets a iosys mapping structure to an address in
> system memory
> * @map: The iosys_map structure
> @@ -239,6 +279,26 @@ static inline void iosys_map_memcpy_to(struct iosys_map
> *dst, size_t dst_offset,
> memcpy(dst->vaddr + dst_offset, src, len);
> }
>
> +/**
> + * iosys_map_memcpy_from - Memcpy from iosys_map into system memory
> + * @dst: Destination in system memory
> + * @src: The iosys_map structure
> + * @src_offset: The offset from which to copy
> + * @len: The number of byte in src
> + *
> + * Copies data from a iosys_map with an offset. The dest buffer is in
> + * system memory. Depending on the
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/guc: Verify hwconfig blob matches supported format
On 08.02.2022 22:05, Jordan Justen wrote:
> i915_drm.h now defines the format of the returned
> DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
> the black box GuC software, it should verify that the data matches
> that format before sending it to user-space.
>
> The verification makes a single simple pass through the blob contents,
> so this verification step should not add a significant amount of init
> time to i915.
>
> v3:
> * Add various changes suggested by Tvrtko
>
> Signed-off-by: Jordan Justen
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 56 ++-
> 1 file changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> index ce6088f112d4..350a0517b9f0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> @@ -71,7 +71,52 @@ static int guc_hwconfig_discover_size(struct
> intel_guc_hwconfig *hwconfig)
> return 0;
> }
>
> -static int guc_hwconfig_fill_buffer(struct intel_guc_hwconfig *hwconfig)
> +static int verify_hwconfig_blob(struct drm_device *drm,
no need to pass drm as you can use:
+ struct intel_guc *guc = hwconfig_to_guc(hwconfig);
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> + const struct intel_guc_hwconfig *hwconfig)
> +{
> + struct drm_i915_query_hwconfig_blob_item *pos;
> + u32 remaining;
> +
> + if (hwconfig->size % 4 != 0 || hwconfig->ptr == NULL)
size alignment could be verified in guc_hwconfig_discover_size()
nit: instead of hardcoded 4 you may use 'sizeof(u32)'
nit: and IS_ALIGNED
and non-null ptr shall be enforced with GEM_BUG_ON as you are calling
this function after memcpy
> + return -EINVAL;
> +
> + pos = hwconfig->ptr;
add line space
and please update below multi-line comments format to
/*
* blah...
> + /* The number of dwords in the blob to validate. Each loop
> + * pass will process at least 2 dwords corresponding to the
> + * key and length fields of the item. In addition, the length
> + * field of the item indicates the length of the data array,
> + * and that number of dwords will be processed (skipped) as
> + * well.
> + */
> + remaining = hwconfig->size / 4;
> +
> + while (remaining > 0) {
> + /* Each item requires at least 2 dwords for the key
> + * and length fields. If the length field is 0, then
> + * the data array would be of length 0.
> + */
> + if (remaining < 2)
> + return -EINVAL;
> + /* remaining >= 2, so subtracting 2 is ok, whereas
> + * adding 2 to pos->length could overflow.
> + */
> + if (pos->length > remaining - 2)
> + return -EINVAL;
> + /* The length check above ensures that the adjustment
> + * of the remaining variable will not underflow, and
> + * that the adjustment of the pos variable will not
> + * pass the end of the blob data.
> + */
> + remaining -= 2 + pos->length;
> + pos = (void *)>data[pos->length];
> + }
btw, if it needs comments then it is too complicated ;)
> +
> + drm_dbg(drm, "hwconfig blob format is valid\n");
not sure if we need this since we have error message in case of failure
maybe better to add dbg message why we claim it is invalid
> + return 0;
> +}
> +
> +static int guc_hwconfig_fill_buffer(struct drm_device *drm,
no need to pass drm
> + struct intel_guc_hwconfig *hwconfig)
> {
> struct intel_guc *guc = hwconfig_to_guc(hwconfig);
> struct i915_vma *vma;
> @@ -88,8 +133,13 @@ static int guc_hwconfig_fill_buffer(struct
> intel_guc_hwconfig *hwconfig)
> ggtt_offset = intel_guc_ggtt_offset(guc, vma);
>
> ret = __guc_action_get_hwconfig(hwconfig, ggtt_offset, hwconfig->size);
> - if (ret >= 0)
> + if (ret >= 0) {
> memcpy(hwconfig->ptr, vaddr, hwconfig->size);
> + if (verify_hwconfig_blob(drm, hwconfig)) {
> + drm_err(drm, "Ignoring invalid hwconfig blob received
> from GuC!\n");
> + ret = -EINVAL;
btw, since we are about to release blob on verification failure,
shouldn't we hexdump whole (or part of) blob somewhere for investigations ?
or maybe we should expose this blob in debugfs, and do it regardless if
it is valid or not, and just fail ioctl if blob is believed to be corrupted.
~Michal
> + }
> + }
>
> i915_vma_unpin_and_release(, I915_VMA_RELEASE_MAP);
>
> @@ -141,7 +191,7 @@ int intel_guc_hwconfig_init(struct intel_guc_hwconfig
> *hwconfig)
> return -ENOMEM;
> }
>
> - ret =
Re: [Intel-gfx] [PATCH 4/4] drm/i915/guc: Verify hwconfig blob matches supported format
Tvrtko Ursulin writes: > Will GuC folks be reviewing this work? I don't know. If you mean the i915 devs interfacing with the GuC, I know John/Rodrigo seemed a bit resistant writing the patches to give userspace this trivial format guarantee on the blob. So, I hoped they would write the patches (3 & 4 in my series), but now I'm hoping they will at least accept the patches. > Quick sanity check maybe makes sense, given data is being "sent" to > userspace directly, I am just not sure if it is worth having in > non-debug builds of i915. Though I will agree not having it in > production then largely defeats the purpose so dunno. The check seems fairly trivial, and it seems like i915 should provide whatever guidance/guarantee is possible to userspace. (Thus, do it once per boot even on release builds.) See also, the commit message I added. > Effective difference if GuC load fails versus userspace libraries > failing to parse hwconfig? Lots of potential things to consider. Personally, I think for internal Intel builds, if this check fails, then it ought to cause the GuC to always fail to load, which today means the device will be wedged. For external builds, I think it should still load the GuC but not send the blob to userspace. This is what should happen with the patches in this series. (I really hope this never happens, which it why I think the internal builds should be so harsh.) Now ... if i915 ever regains the ability to drive the device without the closed source GuC, well... No reason to go off on unrealistic tangents. :) Also, later down the road for released products, userspace drivers may choose to bypass the hwconfig to limit the dependence on GuC. That is a related, but different topic. -Jordan
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GuC HWCONFIG with documentation (rev3)
== Series Details == Series: GuC HWCONFIG with documentation (rev3) URL : https://patchwork.freedesktop.org/series/99787/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GuC HWCONFIG with documentation (rev3)
== Series Details == Series: GuC HWCONFIG with documentation (rev3) URL : https://patchwork.freedesktop.org/series/99787/ State : warning == Summary == $ dim checkpatch origin/drm-tip e77bdf7a8928 drm/i915/guc: Add fetch of hwconfig table -:78: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #78: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 227 lines checked a25a127e8175 drm/i915/uapi: Add query for hwconfig blob 2acfafee266e drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item 016c4656556a drm/i915/guc: Verify hwconfig blob matches supported format -:35: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!hwconfig->ptr" #35: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:80: + if (hwconfig->size % 4 != 0 || hwconfig->ptr == NULL) total: 0 errors, 0 warnings, 1 checks, 75 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for discrete card 64K page support (rev6)
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22213
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/index.html
Participating hosts (46 -> 41)
--
Missing(5): shard-tglu fi-bsw-cyan fi-icl-u2 fi-pnv-d510 bat-jsl-2
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22213:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@workarounds:
- {bat-adlp-6}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_22213 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#109315]) +17
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][6] -> [INCOMPLETE][7] ([i915#2940])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][10] -> [DMESG-WARN][11] ([i915#4269])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: NOTRUN -> [FAIL][13] ([i915#4547])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#1436] /
[i915#3428] / [i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-bsw-nick/igt@run...@aborted.html
Possible fixes
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [FAIL][15] ([i915#4547]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][17] ([i915#4785]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: [DMESG-WARN][19] -> [DMESG-WARN][20] ([i915#1610])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-apl-guc/igt@debugfs_test@read_all_entries.html
[20]:
Re: [Intel-gfx] [PATCH v5 06/10] drm/i915/guc: Update GuC's log-buffer-state access for error capture.
On Tue, Feb 08, 2022 at 11:38:13AM -0800, Teres Alexis, Alan Previn wrote:
> Hi Matt, thank you for taking the time to review the codes.
> Answering your question inline below.
>
>
> On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> > On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > > GuC log buffer regions for debug-log-events, crash-dumps and
> > > error-state-capture are all a single bo allocation that includes
> > > the guc_log_buffer_state structures.
> > >
> > > Since the error-capture region is accessed with high priority at non-
> > > deterministic times (as part of gpu coredump) while the debug-log-event
> > > region is populated and accessed with different priorities, timings and
> > > consumers, let's split out separate locks for buffer-state accesses
> > > of each region.
> > >
> > > Also, ensure a global mapping is made up front for the entire bo
> > > throughout GuC operation so that dynamic mapping and unmapping isn't
> > > required for error capture log access if relay-logging isn't running.
> > >
> > > Additionally, while here, make some readibility improvements:
> > > 1. change previous function names with "capture_logs" to
> > >"copy_debug_logs" to help make the distinction clearer.
> > > 2. Update the guc log region mapping comments to order them
> > >according to the enum definition as per the GuC interface.
> > >
> > > Signed-off-by: Alan Previn
> > > ---
> > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> > > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 47 ++
> > > .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 135 +++---
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 16 ++-
> > > 5 files changed, 141 insertions(+), 60 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > index 4e819853ec2e..be1ad7fa2bf8 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > @@ -34,6 +34,8 @@ struct intel_guc {
> > > struct intel_uc_fw fw;
> > > /** @log: sub-structure containing GuC log related data and objects */
> > > struct intel_guc_log log;
> > > + /** @log_state: states and locks for each subregion of GuC's log
> > > buffer */
> > > + struct intel_guc_log_stats log_state[GUC_MAX_LOG_BUFFER];
> >
> > Why move this? This still probably should be sub-structure of
> > intel_guc_log. Most of the access is from functions that pass in
> > intel_guc_log, then retrieve the GuC object, only to access this new
> > intel_guc_log_stats object. That layering seems wrong, if the argument
> > to a function is intel_guc_log it should really try to access members
> > within that object or below. Obv some exceptions exist but here it seems
> > clear to me this is in the wrong place.
> >
> So the reasoning i had was because because intel_guc_log module only managed
> guc-relay-logging and guc-log-dumping for log-events but allocates the buffer
> for 3 separate subregion/usages (i.e. log-events, crash-dump and
> error-capture).
> That said, I did not want intel_guc_capture and relay-logging (or log-dumping)
> to have to contend with the same lock because these two subregions are
> completely
> independant of each other in terms of when they are being accessed and why.
>
All that is fine, I just think the 'struct intel_guc_log_stats' should
be sub-substure of struct intel_guc_log.
> However, after the redesign of rev5 (this rev), I now believe the
> intel_guc_capture
> module does not require a lock because its only ever accessing its log
> subregion in response to the ctb handler functions that run out of the same
> queue.
> As we know intel_guc_capture reacts to G2H-error-capture-notification and
> G2H-context-reset
> (that trickles into i915_gpu_coredump). At the point of i915_error_state dump,
> intel_guc_capture module does not access the buffer - it merely dumps the
> already-parsed
> and engine-dump-node (that was detached from error-capture's internal
> linked-list
> and attached to the gpu_coredump structure in the second G2H above).
>
> And of course, intel_guc_log only ever accesses the log-events subregion
> and never the error-capture regions.
>
> That said, i could revert the lock structure to the original and not have
> intel_guc_capture using locks. What do you think?
>
Again my comment has nothing to do with locking, it is where the
structure lives.
Matt
> ...alan
>
> > Another nit, I'd personally break this out into multiple patches.
> >
> > e.g. 1 to rename relay log functions, 1 introducing intel_guc_log_stats
> > + lock, and 1 adding intel_guc_capture_output_min_size_est. Maybe I'm
> > missing another patch or two in there.
> >
> > Not a blocker but it does make reviews easier.
> >
> Will do.
>
> > Matt
> >
> > > /** @ct: the command transport communication channel */
> > >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for discrete card 64K page support (rev6)
== Series Details == Series: discrete card 64K page support (rev6) URL : https://patchwork.freedesktop.org/series/99119/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for discrete card 64K page support (rev6)
== Series Details == Series: discrete card 64K page support (rev6) URL : https://patchwork.freedesktop.org/series/99119/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3661cc75d2f0 drm/i915: add needs_compact_pt flag d28e89eb3a6f drm/i915: enforce min GTT alignment for discrete cards -:304: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #304: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:457: + if (offset < hole_start + aligned_size) -:316: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #316: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:481: + if (offset + aligned_size > hole_end) -:334: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #334: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:497: + if (offset < hole_start + aligned_size) -:346: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #346: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:520: + if (offset + aligned_size > hole_end) -:364: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #364: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:536: + if (offset < hole_start + aligned_size) -:376: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #376: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:560: + if (offset + aligned_size > hole_end) -:394: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #394: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:576: + if (offset < hole_start + aligned_size) -:406: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #406: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:599: + if (offset + aligned_size > hole_end) total: 0 errors, 8 warnings, 0 checks, 438 lines checked 7c4419b395e6 drm/i915: support 64K GTT pages for discrete cards 821eba08b7a4 drm/i915: add gtt misalignment test 266421b1e797 drm/i915/uapi: document behaviour for DG2 64K support
Re: [Intel-gfx] [PATCH] drm/i915/psr: Disable PSR2 selective fetch for all TGL steps
Opened the issue at https://gitlab.freedesktop.org/drm/intel/-/issues/5077 ,
included dmesg + video. Feel free to let me know if you need any more info, or
need me to try any patches
On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> > As we've unfortunately started to come to expect from PSR on Intel
> > platforms, PSR2 selective fetch is not at all ready to be enabled on
> > Tigerlake as it results in severe flickering issues - at least on this
> > ThinkPad X1 Carbon 9th generation. The easiest way I've found of
> > reproducing these issues is to just move the cursor around the left border
> > of the screen (suspicious…).
>
> Where is the bug for that? Where is the logs?
> We can't go from enabled to disabled without any debug and because of a
> single device.
> In the mean time you have the option to set the i915 parameter to disable
> it.
>
> >
> > So, fix people's displays again and turn PSR2 selective fetch off for all
> > steppings of Tigerlake. This can be re-enabled again if someone from Intel
> > finds the time to fix this functionality on OEM machines.
> >
> > Signed-off-by: Lyude Paul
> > Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by
> > default")
> > Cc: Gwan-gyeong Mun
> > Cc: Ville Syrjälä
> > Cc: José Roberto de Souza
> > Cc: Jani Nikula
> > Cc: Rodrigo Vivi
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: # v5.16+
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index a1a663f362e7..25c16abcd9cd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -737,10 +737,14 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >
> > - /* Wa_14010254185 Wa_14010103792 */
> > - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> > + /*
> > + * There's two things stopping this from being enabled on TGL:
> > + * For steps A0-C0: workarounds Wa_14010254185 Wa_14010103792 are
> > missing
> > + * For all steps: PSR2 selective fetch causes screen flickering
> > + */
> > + if (IS_TIGERLAKE(dev_priv)) {
> > drm_dbg_kms(_priv->drm,
> > - "PSR2 sel fetch not enabled, missing the
> > implementation of WAs\n");
> > + "PSR2 sel fetch not enabled, currently broken
> > on TGL\n");
> > return false;
> > }
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: Add fetch of hwconfig table
On 08.02.2022 22:05, Jordan Justen wrote:
> From: John Harrison
>
> Implement support for fetching the hardware description table from the
> GuC. The call is made twice - once without a destination buffer to
> query the size and then a second time to fill in the buffer.
>
> Note that the table is only available on ADL-P and later platforms.
>
> Cc: Michal Wajdeczko
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: John Harrison
> Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
> .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 +
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 3 +
> .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 151 ++
> .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +
> 7 files changed, 185 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 6836b020a5be..ba9b6557d59d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -192,6 +192,7 @@ i915-y += gt/uc/intel_uc.o \
> gt/uc/intel_guc_rc.o \
> gt/uc/intel_guc_slpc.o \
> gt/uc/intel_guc_submission.o \
> + gt/uc/intel_guc_hwconfig.o \
nit: I guess ordering of files (by name) is also desired in makefiles
> gt/uc/intel_huc.o \
> gt/uc/intel_huc_debugfs.o \
> gt/uc/intel_huc_fw.o
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> index fe5d7d261797..4a61c819f32b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> @@ -137,6 +137,7 @@ enum intel_guc_action {
> INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
> INTEL_GUC_ACTION_SETUP_PC_GUCRC = 0x3004,
> INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
> + INTEL_GUC_ACTION_GET_HWCONFIG = 0x4100,
> INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
> INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
> INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> index 488b6061ee89..f9e2a6aaef4a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
> @@ -8,6 +8,10 @@
>
> enum intel_guc_response_status {
> INTEL_GUC_RESPONSE_STATUS_SUCCESS = 0x0,
> + INTEL_GUC_RESPONSE_NOT_SUPPORTED = 0x20,
> + INTEL_GUC_RESPONSE_NO_ATTRIBUTE_TABLE = 0x201,
> + INTEL_GUC_RESPONSE_NO_DECRYPTION_KEY = 0x202,
> + INTEL_GUC_RESPONSE_DECRYPTION_FAILED = 0x204,
> INTEL_GUC_RESPONSE_STATUS_GENERIC_FAIL = 0xF000,
> };
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index f9240d4baa69..ce2ff4bb0fd5 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -13,6 +13,7 @@
> #include "intel_guc_fw.h"
> #include "intel_guc_fwif.h"
> #include "intel_guc_ct.h"
> +#include "intel_guc_hwconfig.h"
> #include "intel_guc_log.h"
> #include "intel_guc_reg.h"
> #include "intel_guc_slpc_types.h"
> @@ -37,6 +38,8 @@ struct intel_guc {
> struct intel_guc_ct ct;
> /** @slpc: sub-structure containing SLPC related data and objects */
> struct intel_guc_slpc slpc;
> + /** @hwconfig: hardware configuration KLV table */
nit: "@hwconfig: data related to hardware configuration KLV blob"
> + struct intel_guc_hwconfig hwconfig;
>
> /** @sched_engine: Global engine used to submit requests to GuC */
> struct i915_sched_engine *sched_engine;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> new file mode 100644
> index ..ce6088f112d4
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> @@ -0,0 +1,151 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
2022 ?
> + */
> +
> +#include "gt/intel_gt.h"
> +#include "i915_drv.h"
> +#include "i915_memcpy.h"
> +#include "intel_guc_hwconfig.h"
> +
> +static inline struct intel_guc *hwconfig_to_guc(struct intel_guc_hwconfig
> *hwconfig)
no need for explicit "inline"
> +{
> + return container_of(hwconfig, struct intel_guc, hwconfig);
> +}
> +
> +/*
> + * GuC has a blob containing hardware configuration information (HWConfig).
> + * This is formatted as a simple and flexible KLV (Key/Length/Value) table.
> + *
> + * For example, a minimal version could be:
> + * enum device_attr {
> + * ATTR_SOME_VALUE = 0,
> + * ATTR_SOME_MASK = 1,
> + * };
> + *
> + * static const
[Intel-gfx] [PATCH] drm/i915/display/tgl+: Implement new PLL programming step
A new programming step was added to combo and TC PLL sequences.
If override_AFC_startup is set in VBT, driver should overwrite
AFC_startup value to 0x7 in PLL's div0 register.
The current understating is that only TGL needs this and all display
12 and newer platforms will have a older VBT or a newer VBT with
override_AFC_startup set to 0 but in any case there is a
drm_warn_on_once() to let us know if this is not true.
BSpec: 49204
BSpec: 20122 (pending aproval, check working copies)
BSpec: 49968
BSpec: 71360
Cc: Imre Deak
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 4 ++
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 38 +--
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 6 ++-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 8
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 13 +++
6 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index aec0efd5350ef..a4134b63f2d49 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -596,6 +596,10 @@ parse_general_features(struct drm_i915_private *i915,
} else {
i915->vbt.orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
}
+
+ if (bdb->version >= 249)
+ i915->vbt.override_afc_startup_bit =
general->override_afc_startup_bit;
+
drm_dbg_kms(>drm,
"BDB_GENERAL_FEATURES int_tv_support %d int_crt_support %d
lvds_use_ssc %d lvds_ssc_freq %d display_clock_mode %d fdi_rx_polarity_inverted
%d\n",
i915->vbt.int_tv_support,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 6723c3de5a80c..a60917b926de9 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -2748,6 +2748,9 @@ static void icl_calc_dpll_state(struct drm_i915_private
*i915,
pll_state->cfgcr1 |= TGL_DPLL_CFGCR1_CFSELOVRD_NORMAL_XTAL;
else
pll_state->cfgcr1 |= DPLL_CFGCR1_CENTRAL_FREQ_8400;
+
+ if (i915->vbt.override_afc_startup_bit)
+ pll_state->div0 =
TGL_DPLL0_DIV0_AFC_STARTUP(TGL_DPLL0_DIV0_AFC_STARTUP_OVERRIDE_VAL);
}
static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool use_ssc,
@@ -2949,6 +2952,8 @@ static bool icl_calc_mg_pll_state(struct intel_crtc_state
*crtc_state,
DKL_PLL_DIV0_PROP_COEFF(prop_coeff) |
DKL_PLL_DIV0_FBPREDIV(m1div) |
DKL_PLL_DIV0_FBDIV_INT(m2div_int);
+ if (dev_priv->vbt.override_afc_startup_bit)
+ pll_state->mg_pll_div0 |=
DKL_PLL_DIV0_AFC_STARTUP(TGL_DPLL0_DIV0_AFC_STARTUP_OVERRIDE_VAL);
pll_state->mg_pll_div1 = DKL_PLL_DIV1_IREF_TRIM(iref_trim) |
DKL_PLL_DIV1_TDC_TARGET_CNT(tdc_targetcnt);
@@ -3448,10 +3453,10 @@ static bool dkl_pll_get_hw_state(struct
drm_i915_private *dev_priv,
MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
hw_state->mg_pll_div0 = intel_de_read(dev_priv, DKL_PLL_DIV0(tc_port));
- hw_state->mg_pll_div0 &= (DKL_PLL_DIV0_INTEG_COEFF_MASK |
- DKL_PLL_DIV0_PROP_COEFF_MASK |
- DKL_PLL_DIV0_FBPREDIV_MASK |
- DKL_PLL_DIV0_FBDIV_INT_MASK);
+ val = DKL_PLL_DIV0_MASK;
+ if (dev_priv->vbt.override_afc_startup_bit)
+ val |= DKL_PLL_DIV0_AFC_STARTUP_MASK;
+ hw_state->mg_pll_div0 &= val;
hw_state->mg_pll_div1 = intel_de_read(dev_priv, DKL_PLL_DIV1(tc_port));
hw_state->mg_pll_div1 &= (DKL_PLL_DIV1_IREF_TRIM_MASK |
@@ -3513,6 +3518,10 @@ static bool icl_pll_get_hw_state(struct drm_i915_private
*dev_priv,
TGL_DPLL_CFGCR0(id));
hw_state->cfgcr1 = intel_de_read(dev_priv,
TGL_DPLL_CFGCR1(id));
+ if (dev_priv->vbt.override_afc_startup_bit) {
+ hw_state->div0 = intel_de_read(dev_priv,
TGL_DPLL0_DIV0(id));
+ hw_state->div0 &= TGL_DPLL0_DIV0_AFC_STARTUP_MASK;
+ }
} else {
if (IS_JSL_EHL(dev_priv) && id == DPLL_ID_EHL_DPLL4) {
hw_state->cfgcr0 = intel_de_read(dev_priv,
@@ -3554,7 +3563,7 @@ static void icl_dpll_write(struct drm_i915_private
*dev_priv,
{
struct intel_dpll_hw_state *hw_state = >state.hw_state;
const enum intel_dpll_id id = pll->info->id;
- i915_reg_t cfgcr0_reg, cfgcr1_reg;
+ i915_reg_t cfgcr0_reg, cfgcr1_reg, div0_reg = INVALID_MMIO_REG;
if
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/dp, drm/i915: 128b/132b updates (rev6)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev6) URL : https://patchwork.freedesktop.org/series/99324/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11203_full -> Patchwork_22212_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22212_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22212_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22212_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-skl4/igt@kms_flip@flip-vs-susp...@a-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@syncobj_timeline@transfer-timeline-point: - shard-kbl: NOTRUN -> [DMESG-WARN][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-kbl6/igt@syncobj_timel...@transfer-timeline-point.html - shard-apl: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-apl7/igt@syncobj_timel...@transfer-timeline-point.html Known issues Here are the changes found in Patchwork_22212_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#658]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-iclb2/igt@feature_discov...@psr2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-iclb6/igt@feature_discov...@psr2.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2410]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_capture@pi@bcs0: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([i915#3371]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-iclb3/igt@gem_exec_capture@p...@bcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-iclb7/igt@gem_exec_capture@p...@bcs0.html * igt@gem_exec_capture@pi@vcs0: - shard-skl: NOTRUN -> [INCOMPLETE][11] ([i915#4547]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-skl4/igt@gem_exec_capture@p...@vcs0.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842]) +5 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_params@no-vebox: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109283]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-iclb3/igt@gem_exec_par...@no-vebox.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-skl8/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-skl1/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@random-engines: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#4613]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-iclb3/igt@gem_lmem_swapp...@random-engines.html - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-apl1/igt@gem_lmem_swapp...@random-engines.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/shard-apl2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_pxp@verify-pxp-stale-ctx-execution: - shard-iclb: NOTRUN -> [SKIP][21]
[Intel-gfx] [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann
Cc: Zack Rusin
Cc: Javier Martinez Canillas
Cc: Zack Rusin
Cc: Hans de Goede
Cc: Ilya Trukhanov
Signed-off-by: Daniel Vetter
Cc: Peter Jones
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/efifb.c| 11 ---
drivers/video/fbdev/simplefb.c | 11 ---
2 files changed, 22 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ea42ba6445b2..edca3703b964 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -351,17 +351,6 @@ static int efifb_probe(struct platform_device *dev)
char *option = NULL;
efi_memory_desc_t md;
- /*
-* Generic drivers must not be registered if a framebuffer exists.
-* If a native driver was probed, the display hardware was already
-* taken and attempting to use the system framebuffer is dangerous.
-*/
- if (num_registered_fb > 0) {
- dev_err(>dev,
- "efifb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 94fc9c6d0411..0ef41173325a 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -413,17 +413,6 @@ static int simplefb_probe(struct platform_device *pdev)
struct simplefb_par *par;
struct resource *res, *mem;
- /*
-* Generic drivers must not be registered if a framebuffer exists.
-* If a native driver was probed, the display hardware was already
-* taken and attempting to use the system framebuffer is dangerous.
-*/
- if (num_registered_fb > 0) {
- dev_err(>dev,
- "simplefb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (fb_get_options("simplefb", NULL))
return -ENODEV;
--
2.34.1
[Intel-gfx] [PATCH v2 14/19] fbcon: Move console_lock for register/unlink/unregister
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Du Cheng
Cc: Claudio Suarez
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
Cc: Matthew Wilcox
Cc: Sam Ravnborg
Cc: Zheyu Ma
Cc: Guenter Roeck
Cc: Alex Deucher
Cc: Zhen Lei
Cc: Xiyu Yang
---
drivers/video/fbdev/core/fbcon.c | 33 ++--
drivers/video/fbdev/core/fbmem.c | 23 ++
2 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 4f9752ee9189..abb419a091c6 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2756,10 +2756,12 @@ void fbcon_fb_unbind(struct fb_info *info)
int i, new_idx = -1;
int idx = info->node;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (!fbcon_has_console_bind)
+ if (!fbcon_has_console_bind) {
+ console_unlock();
return;
+ }
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
@@ -2794,6 +2796,8 @@ void fbcon_fb_unbind(struct fb_info *info)
}
fbcon_unbind();
}
+
+ console_unlock();
}
/* called with console_lock held */
@@ -2801,10 +2805,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
{
int i, idx;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (deferred_takeover)
+ if (deferred_takeover) {
+ console_unlock();
return;
+ }
idx = info->node;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
@@ -2833,6 +2839,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (!num_registered_fb)
do_unregister_con_driver(_con);
+ console_unlock();
}
void fbcon_remap_all(struct fb_info *info)
@@ -2890,19 +2897,27 @@ static inline void fbcon_select_primary(struct fb_info
*info)
}
#endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
+static bool lockless_register_fb;
+module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool,
0400);
+MODULE_PARM_DESC(lockless_register_fb,
+ "Lockless framebuffer registration for debugging [default=off]");
+
/* called with console_lock held */
int fbcon_fb_registered(struct fb_info *info)
{
int ret = 0, i, idx;
- WARN_CONSOLE_UNLOCKED();
+ if (!lockless_register_fb)
+ console_lock();
+ else
+ atomic_inc(_console_lock_warning);
idx = info->node;
fbcon_select_primary(info);
if (deferred_takeover) {
pr_info("fbcon: Deferring console take-over\n");
- return 0;
+ goto out;
}
if (info_idx == -1) {
@@ -2922,6 +2937,12 @@ int fbcon_fb_registered(struct fb_info *info)
}
}
+out:
+ if (!lockless_register_fb)
+ console_unlock();
+ else
+ atomic_dec(_console_lock_warning);
+
return ret;
}
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 37656883e7bd..6f6f7a763969 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1594,14 +1594,9 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
}
}
-static bool lockless_register_fb;
-module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool,
0400);
-MODULE_PARM_DESC(lockless_register_fb,
- "Lockless framebuffer registration for debugging [default=off]");
-
static int do_register_framebuffer(struct fb_info *fb_info)
{
- int i, ret;
+ int i;
struct fb_videomode mode;
if (fb_check_foreignness(fb_info))
@@ -1670,17 +1665,7 @@ static int do_register_framebuffer(struct fb_info
*fb_info)
}
#endif
- if (!lockless_register_fb)
- console_lock();
- else
- atomic_inc(_console_lock_warning);
- ret = fbcon_fb_registered(fb_info);
-
- if (!lockless_register_fb)
- console_unlock();
- else
- atomic_dec(_console_lock_warning);
- return ret;
+ return fbcon_fb_registered(fb_info);
}
static void unbind_console(struct fb_info *fb_info)
@@ -1690,9 +1675,7 @@ static void unbind_console(struct fb_info *fb_info)
if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
return;
- console_lock();
fbcon_fb_unbind(fb_info);
- console_unlock();
}
static void unlink_framebuffer(struct fb_info *fb_info)
@@ -1735,9 +1718,7 @@ static void
[Intel-gfx] [PATCH v2 19/19] fbdev: Make registered_fb[] private to fbmem.c
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
v2: I typoed the config name (0day)
Cc: kernel test robot
Cc: Jens Frederich
Cc: Jon Nettleton
Cc: Greg Kroah-Hartman
Cc: linux-stag...@lists.linux.dev
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Helge Deller
Cc: Matthew Wilcox
Cc: Sam Ravnborg
Cc: Tetsuo Handa
Cc: Zhen Lei
Cc: Alex Deucher
Cc: Xiyu Yang
Cc: linux-fb...@vger.kernel.org
Cc: Zheyu Ma
Cc: Guenter Roeck
---
drivers/video/fbdev/core/fbmem.c | 8 ++--
include/linux/fb.h | 7 +++
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 6f6f7a763969..6f0eb596a2cd 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -49,10 +49,14 @@
static DEFINE_MUTEX(registration_lock);
struct fb_info *registered_fb[FB_MAX] __read_mostly;
-EXPORT_SYMBOL(registered_fb);
-
int num_registered_fb __read_mostly;
+#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
+EXPORT_SYMBOL(registered_fb);
EXPORT_SYMBOL(num_registered_fb);
+#endif
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++)\
+ if (!registered_fb[i]) {} else
bool fb_center_logo __read_mostly;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 23b19cf8bccd..afaa1474a283 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -623,16 +623,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo
*var,
extern int fb_get_options(const char *name, char **option);
extern int fb_new_modelist(struct fb_info *info);
+#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
extern struct fb_info *registered_fb[FB_MAX];
+
extern int num_registered_fb;
+#endif
extern bool fb_center_logo;
extern int fb_logo_count;
extern struct class *fb_class;
-#define for_each_registered_fb(i) \
- for (i = 0; i < FB_MAX; i++)\
- if (!registered_fb[i]) {} else
-
static inline void lock_fb_info(struct fb_info *info)
{
mutex_lock(>lock);
--
2.34.1
[Intel-gfx] [PATCH v2 16/19] fbcon: untangle fbcon_exit
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can deadlock)
- That also means no point in clearing deferred_takeover, we are
unloading everything anyway.
- Finally rename fbcon_exit to fbcon_release_all and move it, since
that's what's it doing when being called from consw->con_deinit
through fbcon_deinit.
To answer a question from Sam just quoting my own reply:
> We loose the call to fbcon_release_all() here [in fb_console_exit()].
> We have part of the old fbcon_exit() above, but miss the release parts.
Ah yes that's the entire point of this change. The release_all in the
fbcon exit path was only needed when fbcon was a separate module
indepedent from core fb.ko. Which means it was possible to unload fbcon
while having fbdev drivers registered.
But since we've merged them that has become impossible, so by the time the
fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
left. And hence removing them is pointless.
v2: Explain the why better (Sam)
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Tetsuo Handa
---
drivers/video/fbdev/core/fbcon.c | 63
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 685b4a9e5546..944f514c77ec 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -187,7 +187,6 @@ static void fbcon_redraw_move(struct vc_data *vc, struct
fbcon_display *p,
int line, int count, int dy);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
-static void fbcon_exit(void);
static struct device *fbcon_device;
@@ -1146,6 +1145,27 @@ static void fbcon_free_font(struct fbcon_display *p,
bool freefont)
static void set_vc_hi_font(struct vc_data *vc, bool set);
+static void fbcon_release_all(void)
+{
+ struct fb_info *info;
+ int i, j, mapped;
+
+ for_each_registered_fb(i) {
+ mapped = 0;
+ info = registered_fb[i];
+
+ for (j = first_fb_vc; j <= last_fb_vc; j++) {
+ if (con2fb_map[j] == i) {
+ mapped = 1;
+ con2fb_map[j] = -1;
+ }
+ }
+
+ if (mapped)
+ fbcon_release(info);
+ }
+}
+
static void fbcon_deinit(struct vc_data *vc)
{
struct fbcon_display *p = _display[vc->vc_num];
@@ -1185,7 +1205,7 @@ static void fbcon_deinit(struct vc_data *vc)
set_vc_hi_font(vc, false);
if (!con_is_bound(_con))
- fbcon_exit();
+ fbcon_release_all();
if (vc->vc_num == logo_shown)
logo_shown = FBCON_LOGO_CANSHOW;
@@ -3296,34 +3316,6 @@ static void fbcon_start(void)
#endif
}
-static void fbcon_exit(void)
-{
- struct fb_info *info;
- int i, j, mapped;
-
-#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
- if (deferred_takeover) {
- dummycon_unregister_output_notifier(_output_nb);
- deferred_takeover = false;
- }
-#endif
-
- for_each_registered_fb(i) {
- mapped = 0;
- info = registered_fb[i];
-
- for (j = first_fb_vc; j <= last_fb_vc; j++) {
- if (con2fb_map[j] == i) {
- mapped = 1;
- con2fb_map[j] = -1;
- }
- }
-
- if (mapped)
- fbcon_release(info);
- }
-}
-
void __init fb_console_init(void)
{
int i;
@@ -3363,10 +3355,19 @@ static void __exit fbcon_deinit_device(void)
void __exit fb_console_exit(void)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+ console_lock();
+ if (deferred_takeover)
+ dummycon_unregister_output_notifier(_output_nb);
+ console_unlock();
+
+ cancel_work_sync(_deferred_takeover_work);
+#endif
+
console_lock();
fbcon_deinit_device();
device_destroy(fb_class, MKDEV(0, 0));
- fbcon_exit();
+
do_unregister_con_driver(_con);
console_unlock();
}
--
2.34.1
[Intel-gfx] [PATCH v2 17/19] fbcon: Maintain a private array of fb_info
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need to hold a full fb_info reference, which
is nice because doing so would mean a refcount loop between the
console and the fb_info. But it's also not nice since it means
console_lock() must be held absolutely everywhere. Well strictly
speaking we could still try to do some refcounting games again by
calling get_fb_info before we drop the console_lock. But things will
get tricky.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Greg Kroah-Hartman
---
drivers/video/fbdev/core/fbcon.c | 82 +---
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 944f514c77ec..6a7d470beec7 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -86,10 +86,6 @@
* - fbcon state itself is protected by the console_lock, and the code does a
* pretty good job at making sure that lock is held everywhere it's needed.
*
- * - access to the registered_fb array is entirely unprotected. This should use
- * proper object lifetime handling, i.e. get/put_fb_info. This also means
- * switching from indices to proper pointers for fb_info everywhere.
- *
* - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
* means concurrent access to the same fbdev from both fbcon and userspace
* will blow up. To fix this all fbcon calls from fbmem.c need to be moved
out
@@ -107,6 +103,13 @@ enum {
static struct fbcon_display fb_display[MAX_NR_CONSOLES];
+struct fb_info *fbcon_registered_fb[FB_MAX];
+int fbcon_num_registered_fb;
+
+#define fbcon_for_each_registered_fb(i)\
+ for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
+ if (!fbcon_registered_fb[i]) {} else
+
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
@@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
{
WARN_CONSOLE_UNLOCKED();
- /*
-* Note that only con2fb_map is protected by the console lock,
-* registered_fb is protected by a separate mutex. This lookup can
-* therefore race.
-*/
- return registered_fb[con2fb_map[console]];
+ return fbcon_registered_fb[con2fb_map[console]];
}
static int logo_lines;
@@ -518,7 +516,7 @@ static int do_fbcon_takeover(int show_logo)
{
int err, i;
- if (!num_registered_fb)
+ if (!fbcon_num_registered_fb)
return -ENODEV;
if (!show_logo)
@@ -821,7 +819,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
{
struct vc_data *vc = vc_cons[unit].d;
int oldidx = con2fb_map[unit];
- struct fb_info *info = registered_fb[newidx];
+ struct fb_info *info = fbcon_registered_fb[newidx];
struct fb_info *oldinfo = NULL;
int found, err = 0, show_logo;
@@ -839,7 +837,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
}
if (oldidx != -1)
- oldinfo = registered_fb[oldidx];
+ oldinfo = fbcon_registered_fb[oldidx];
found = search_fb_in_map(newidx);
@@ -931,13 +929,13 @@ static const char *fbcon_startup(void)
* If num_registered_fb is zero, this is a call for the dummy part.
* The frame buffer devices weren't initialized yet.
*/
- if (!num_registered_fb || info_idx == -1)
+ if (!fbcon_num_registered_fb || info_idx == -1)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
* fbcon_fb_registered();
*/
- info = registered_fb[info_idx];
+ info = fbcon_registered_fb[info_idx];
if (!info)
return NULL;
@@ -1150,9 +1148,9 @@ static void fbcon_release_all(void)
struct fb_info *info;
int i, j, mapped;
- for_each_registered_fb(i) {
+ fbcon_for_each_registered_fb(i) {
mapped = 0;
- info = registered_fb[i];
+ info = fbcon_registered_fb[i];
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
@@ -1179,7 +1177,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (idx == -1)
goto finished;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
if (!info)
goto finished;
@@ -2098,9 +2096,9 @@ static int fbcon_switch(struct vc_data *vc)
*
* info->currcon = vc->vc_num;
[Intel-gfx] [PATCH v2 15/19] fbcon: Move more code into fbcon_release
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Tetsuo Handa
Cc: Greg Kroah-Hartman
Cc: Du Cheng
Cc: Claudio Suarez
---
drivers/video/fbdev/core/fbcon.c | 33 +---
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index abb419a091c6..685b4a9e5546 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -690,6 +690,18 @@ static void fbcon_release(struct fb_info *info)
unlock_fb_info(info);
module_put(info->fbops->owner);
+
+ if (info->fbcon_par) {
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ fbcon_del_cursor_work(info);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(info->fbcon_par);
+ info->fbcon_par = NULL;
+ }
}
static int fbcon_open(struct fb_info *info)
@@ -740,18 +752,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
struct fb_info *info,
static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
struct fb_info *newinfo)
{
- struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
fbcon_release(oldinfo);
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
/*
If oldinfo and newinfo are driving the same hardware,
the fb_release() method of oldinfo may attempt to
@@ -3315,19 +3319,8 @@ static void fbcon_exit(void)
}
}
- if (mapped) {
- if (info->fbcon_par) {
- struct fbcon_ops *ops = info->fbcon_par;
-
- fbcon_del_cursor_work(info);
- kfree(ops->cursor_src);
- kfree(ops->cursor_state.mask);
- kfree(info->fbcon_par);
- info->fbcon_par = NULL;
- }
-
+ if (mapped)
fbcon_release(info);
- }
}
}
--
2.34.1
[Intel-gfx] [PATCH v2 12/19] fbcon: use lock_fb_info in fbcon_open/release
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers over
any issues.
Note that this means we're shuffling around a bit the locking sections
for some of the console takeover and unbind paths, but not all:
- console binding/unbinding from the console layer never with
lock_fb_info
- unbind (as opposed to unlink) never bother with lock_fb_info
Also the real serialization against set_par and set_pan are still
doing by wrapping the entire ioctl code in console_lock(). So this
shuffling shouldn't be worse than what we had from a "can you trigger
races?" pov, but it's at least clearer.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Claudio Suarez
Cc: Tetsuo Handa
Cc: Thomas Zimmermann
Cc: Greg Kroah-Hartman
Cc: Du Cheng
Cc: Sam Ravnborg
Cc: Matthew Wilcox
Cc: William Kucharski
Cc: Alex Deucher
Cc: Zheyu Ma
Cc: Zhen Lei
Cc: Xiyu Yang
---
drivers/video/fbdev/core/fbcon.c | 5 +
drivers/video/fbdev/core/fbmem.c | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index f0213a0e3870..cc960bf49991 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -684,8 +684,10 @@ static int fbcon_invalid_charcount(struct fb_info *info,
unsigned charcount)
static void fbcon_release(struct fb_info *info)
{
+ lock_fb_info(info);
if (info->fbops->fb_release)
info->fbops->fb_release(info, 0);
+ unlock_fb_info(info);
module_put(info->fbops->owner);
}
@@ -697,11 +699,14 @@ static int fbcon_open(struct fb_info *info)
if (!try_module_get(info->fbops->owner))
return -ENODEV;
+ lock_fb_info(info);
if (info->fbops->fb_open &&
info->fbops->fb_open(info, 0)) {
+ unlock_fb_info(info);
module_put(info->fbops->owner);
return -ENODEV;
}
+ unlock_fb_info(info);
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops) {
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index ad9aac06427a..37656883e7bd 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1674,9 +1674,7 @@ static int do_register_framebuffer(struct fb_info
*fb_info)
console_lock();
else
atomic_inc(_console_lock_warning);
- lock_fb_info(fb_info);
ret = fbcon_fb_registered(fb_info);
- unlock_fb_info(fb_info);
if (!lockless_register_fb)
console_unlock();
@@ -1693,9 +1691,7 @@ static void unbind_console(struct fb_info *fb_info)
return;
console_lock();
- lock_fb_info(fb_info);
fbcon_fb_unbind(fb_info);
- unlock_fb_info(fb_info);
console_unlock();
}
--
2.34.1
[Intel-gfx] [PATCH v2 13/19] fbcon: Consistently protect deferred_takeover with console_lock()
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Thomas Zimmermann
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index cc960bf49991..4f9752ee9189 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3227,6 +3227,9 @@ static void fbcon_register_existing_fbs(struct
work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3244,8 +3247,6 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(_deferred_takeover_work);
--
2.34.1
[Intel-gfx] [PATCH v2 11/19] fbcon: move more common code into fb_open()
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Note that the error handling for the con2fb_acquire_newinfo() failure
case was very strange: Callers updated con2fb_map to the new value
before calling this function, but upon error con2fb_acquire_newinfo
reset it to the old value. Since I removed the call to fbcon_release
anyway that strange error path was sticking out like a sore thumb,
hence I removed it. Which also allows us to remove the oldidx
parameter from that function.
v2: Explain what's going on with oldidx and error paths (Sam)
v3: Drop unused variable (0day)
Acked-by: Sam Ravnborg (v2)
Cc: kernel test robot
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
Cc: Thomas Zimmermann
Cc: Claudio Suarez
Cc: Du Cheng
---
drivers/video/fbdev/core/fbcon.c | 75 +---
1 file changed, 30 insertions(+), 45 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index a60891005d44..f0213a0e3870 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -682,8 +682,18 @@ static int fbcon_invalid_charcount(struct fb_info *info,
unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
+
static int fbcon_open(struct fb_info *info)
{
+ struct fbcon_ops *ops;
+
if (!try_module_get(info->fbops->owner))
return -ENODEV;
@@ -693,48 +703,31 @@ static int fbcon_open(struct fb_info *info)
return -ENODEV;
}
- return 0;
-}
+ ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
+ if (!ops) {
+ fbcon_release(info);
+ return -ENOMEM;
+ }
-static void fbcon_release(struct fb_info *info)
-{
- if (info->fbops->fb_release)
- info->fbops->fb_release(info, 0);
+ INIT_DELAYED_WORK(>cursor_work, fb_flashcursor);
+ ops->info = info;
+ info->fbcon_par = ops;
+ ops->cur_blink_jiffies = HZ / 5;
- module_put(info->fbops->owner);
+ return 0;
}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
- int unit, int oldidx)
+ int unit)
{
- struct fbcon_ops *ops = NULL;
int err;
err = fbcon_open(info);
if (err)
return err;
- if (!err) {
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops)
- err = -ENOMEM;
-
- INIT_DELAYED_WORK(>cursor_work, fb_flashcursor);
- }
-
- if (!err) {
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
-
- if (vc)
- set_blitting_type(vc, info);
- }
-
- if (err) {
- con2fb_map[unit] = oldidx;
- fbcon_release(info);
- }
+ if (vc)
+ set_blitting_type(vc, info);
return err;
}
@@ -842,9 +835,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
found = search_fb_in_map(newidx);
- con2fb_map[unit] = newidx;
- if (!err && !found)
- err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
+ if (!err && !found) {
+ err = con2fb_acquire_newinfo(vc, info, unit);
+ if (!err)
+ con2fb_map[unit] = newidx;
+ }
/*
* If old fb is not mapped to any of the consoles,
@@ -941,20 +936,10 @@ static const char *fbcon_startup(void)
if (fbcon_open(info))
return NULL;
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops) {
- fbcon_release(info);
- return NULL;
- }
-
- INIT_DELAYED_WORK(>cursor_work, fb_flashcursor);
-
+ ops = info->fbcon_par;
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
p->con_rotate = initial_rotation;
if (p->con_rotate == -1)
@@ -1024,7 +1009,7 @@ static void fbcon_init(struct vc_data *vc, int init)
return;
if (!info->fbcon_par)
- con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
+ con2fb_acquire_newinfo(vc, info, vc->vc_num);
/* If we are not the first console on this
fb, copy the font from that console */
--
2.34.1
[Intel-gfx] [PATCH v2 10/19] fbcon: Ditch error handling for con2fb_release_oldinfo
It doesn't ever fail anymore.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Greg Kroah-Hartman
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Tetsuo Handa
---
drivers/video/fbdev/core/fbcon.c | 37 +++-
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 3e1a3e7bf527..a60891005d44 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -739,9 +739,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
struct fb_info *info,
return err;
}
-static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
- struct fb_info *newinfo, int unit,
- int oldidx, int found)
+static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
+ struct fb_info *newinfo)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
@@ -770,8 +769,6 @@ static int con2fb_release_oldinfo(struct vc_data *vc,
struct fb_info *oldinfo,
"detected unhandled fb_set_par error, "
"error code %d\n", ret);
}
-
- return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -825,7 +822,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
int oldidx = con2fb_map[unit];
struct fb_info *info = registered_fb[newidx];
struct fb_info *oldinfo = NULL;
- int found, err = 0;
+ int found, err = 0, show_logo;
WARN_CONSOLE_UNLOCKED();
@@ -854,18 +851,15 @@ static int set_con2fb_map(int unit, int newidx, int user)
* fbcon should release it.
*/
if (!err && oldinfo && !search_fb_in_map(oldidx))
- err = con2fb_release_oldinfo(vc, oldinfo, info, unit, oldidx,
-found);
+ con2fb_release_oldinfo(vc, oldinfo, info);
- if (!err) {
- int show_logo = (fg_console == 0 && !user &&
-logo_shown != FBCON_LOGO_DONTSHOW);
+ show_logo = (fg_console == 0 && !user &&
+logo_shown != FBCON_LOGO_DONTSHOW);
- if (!found)
- fbcon_add_cursor_work(info);
- con2fb_map_boot[unit] = newidx;
- con2fb_init_display(vc, info, unit, show_logo);
- }
+ if (!found)
+ fbcon_add_cursor_work(info);
+ con2fb_map_boot[unit] = newidx;
+ con2fb_init_display(vc, info, unit, show_logo);
if (!search_fb_in_map(info_idx))
info_idx = newidx;
@@ -2769,7 +2763,7 @@ static inline void fbcon_unbind(void) {}
/* called with console_lock held */
void fbcon_fb_unbind(struct fb_info *info)
{
- int i, new_idx = -1, ret = 0;
+ int i, new_idx = -1;
int idx = info->node;
WARN_CONSOLE_UNLOCKED();
@@ -2803,13 +2797,8 @@ void fbcon_fb_unbind(struct fb_info *info)
if (con2fb_map[i] == idx) {
con2fb_map[i] = -1;
if (!search_fb_in_map(idx)) {
- ret =
con2fb_release_oldinfo(vc_cons[i].d,
-info,
NULL, i,
-idx, 0);
- if (ret) {
- con2fb_map[i] = idx;
- return;
- }
+ con2fb_release_oldinfo(vc_cons[i].d,
+ info, NULL);
}
}
}
--
2.34.1
[Intel-gfx] [PATCH v2 09/19] fbcon: Extract fbcon_open/release helpers
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c is protected by the big console_lock()
lock (especially all the global variables), so the minor changes in
ordering of setup/cleanup do not matter.
v2: Explain a bit better why this is all correct (Sam)
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Claudio Suarez
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
Cc: Du Cheng
---
drivers/video/fbdev/core/fbcon.c | 107 +++
1 file changed, 53 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 058e885d24f6..3e1a3e7bf527 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -682,19 +682,37 @@ static int fbcon_invalid_charcount(struct fb_info *info,
unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static int fbcon_open(struct fb_info *info)
+{
+ if (!try_module_get(info->fbops->owner))
+ return -ENODEV;
+
+ if (info->fbops->fb_open &&
+ info->fbops->fb_open(info, 0)) {
+ module_put(info->fbops->owner);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
int unit, int oldidx)
{
struct fbcon_ops *ops = NULL;
- int err = 0;
-
- if (!try_module_get(info->fbops->owner))
- err = -ENODEV;
+ int err;
- if (!err && info->fbops->fb_open &&
- info->fbops->fb_open(info, 0))
- err = -ENODEV;
+ err = fbcon_open(info);
+ if (err)
+ return err;
if (!err) {
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
@@ -715,7 +733,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
struct fb_info *info,
if (err) {
con2fb_map[unit] = oldidx;
- module_put(info->fbops->owner);
+ fbcon_release(info);
}
return err;
@@ -726,45 +744,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc,
struct fb_info *oldinfo,
int oldidx, int found)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
- int err = 0, ret;
+ int ret;
- if (oldinfo->fbops->fb_release &&
- oldinfo->fbops->fb_release(oldinfo, 0)) {
- con2fb_map[unit] = oldidx;
- if (!found && newinfo->fbops->fb_release)
- newinfo->fbops->fb_release(newinfo, 0);
- if (!found)
- module_put(newinfo->fbops->owner);
- err = -ENODEV;
- }
+ fbcon_release(oldinfo);
- if (!err) {
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
- module_put(oldinfo->fbops->owner);
- /*
- If oldinfo and newinfo are driving the same hardware,
- the fb_release() method of oldinfo may attempt to
- restore the hardware state. This will leave the
- newinfo in an undefined state. Thus, a call to
- fb_set_par() may be needed for the newinfo.
- */
- if (newinfo && newinfo->fbops->fb_set_par) {
- ret = newinfo->fbops->fb_set_par(newinfo);
+ fbcon_del_cursor_work(oldinfo);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(oldinfo->fbcon_par);
+ oldinfo->fbcon_par = NULL;
+ /*
+ If oldinfo and newinfo are driving the same hardware,
+ the fb_release() method of oldinfo may attempt to
+ restore the hardware state. This will leave the
+ newinfo in an undefined state. Thus, a call to
+ fb_set_par() may be needed for the newinfo.
+ */
+ if (newinfo && newinfo->fbops->fb_set_par) {
+ ret = newinfo->fbops->fb_set_par(newinfo);
- if (ret)
- printk(KERN_ERR "con2fb_release_oldinfo: "
- "detected unhandled fb_set_par error, "
- "error code %d\n", ret);
- }
+ if (ret)
+
[Intel-gfx] [PATCH v2 07/19] fbcon: Replace FBCON_FLAGS_INIT with a boolean
It's only one flag and slightly tidier code.
Acked-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Tetsuo Handa
Cc: Greg Kroah-Hartman
Cc: Du Cheng
Cc: Thomas Zimmermann
Cc: Claudio Suarez
---
drivers/video/fbdev/core/fbcon.c | 11 +--
drivers/video/fbdev/core/fbcon.h | 4 +---
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index a368ed602e2e..058e885d24f6 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -775,7 +775,7 @@ static void con2fb_init_display(struct vc_data *vc, struct
fb_info *info,
ops->currcon = fg_console;
- if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -784,7 +784,7 @@ static void con2fb_init_display(struct vc_data *vc, struct
fb_info *info,
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
ops->graphics = 0;
fbcon_set_disp(info, >var, unit);
@@ -1103,8 +1103,7 @@ static void fbcon_init(struct vc_data *vc, int init)
* We need to do it in fbcon_init() to prevent screen corruption.
*/
if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
- if (info->fbops->fb_set_par &&
- !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -1113,7 +1112,7 @@ static void fbcon_init(struct vc_data *vc, int init)
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
}
ops->graphics = 0;
@@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (con_is_visible(vc))
fbcon_del_cursor_work(info);
- ops->flags &= ~FBCON_FLAGS_INIT;
+ ops->initialized = false;
finished:
fbcon_free_font(p, free_font);
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 6708ca0048aa..0eaf54a21151 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -18,8 +18,6 @@
#include
-#define FBCON_FLAGS_INIT 1
-
/*
*This is the interface between the low-level console driver and the
*low-level frame buffer device
@@ -79,7 +77,7 @@ struct fbcon_ops {
intblank_state;
intgraphics;
intsave_graphics; /* for debug enter/leave */
- intflags;
+ bool initialized;
introtate;
intcur_rotate;
char *cursor_data;
--
2.34.1
[Intel-gfx] [PATCH v2 06/19] fbcon: Use delayed work for cursor
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which helps with locking issues around cleanup and all that in a later
patch.
Also note that this allows us to ditch the hand-rolled work cleanup in
fbcon_exit - we already call fbcon_del_cursor_timer, which takes care
of everything. Plus this was racy anyway.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Thomas Zimmermann
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
---
drivers/video/fbdev/core/fbcon.c | 85 +---
drivers/video/fbdev/core/fbcon.h | 4 +-
2 files changed, 35 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 83f0223f5333..a368ed602e2e 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -350,8 +350,8 @@ static int get_color(struct vc_data *vc, struct fb_info
*info,
static void fb_flashcursor(struct work_struct *work)
{
- struct fb_info *info = container_of(work, struct fb_info, queue);
- struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_ops *ops = container_of(work, struct fbcon_ops,
cursor_work.work);
+ struct fb_info *info;
struct vc_data *vc = NULL;
int c;
int mode;
@@ -364,7 +364,10 @@ static void fb_flashcursor(struct work_struct *work)
if (ret == 0)
return;
- if (ops && ops->currcon != -1)
+ /* protected by console_lock */
+ info = ops->info;
+
+ if (ops->currcon != -1)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
@@ -380,42 +383,25 @@ static void fb_flashcursor(struct work_struct *work)
ops->cursor(vc, info, mode, get_color(vc, info, c, 1),
get_color(vc, info, c, 0));
console_unlock();
-}
-static void cursor_timer_handler(struct timer_list *t)
-{
- struct fbcon_ops *ops = from_timer(ops, t, cursor_timer);
- struct fb_info *info = ops->info;
-
- queue_work(system_power_efficient_wq, >queue);
- mod_timer(>cursor_timer, jiffies + ops->cur_blink_jiffies);
+ queue_delayed_work(system_power_efficient_wq, >cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_add_cursor_timer(struct fb_info *info)
+static void fbcon_add_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if ((!info->queue.func || info->queue.func == fb_flashcursor) &&
- !(ops->flags & FBCON_FLAGS_CURSOR_TIMER) &&
- !fbcon_cursor_noblink) {
- if (!info->queue.func)
- INIT_WORK(>queue, fb_flashcursor);
-
- timer_setup(>cursor_timer, cursor_timer_handler, 0);
- mod_timer(>cursor_timer, jiffies + ops->cur_blink_jiffies);
- ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
- }
+ if (!fbcon_cursor_noblink)
+ queue_delayed_work(system_power_efficient_wq, >cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_del_cursor_timer(struct fb_info *info)
+static void fbcon_del_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if (info->queue.func == fb_flashcursor &&
- ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
- del_timer_sync(>cursor_timer);
- ops->flags &= ~FBCON_FLAGS_CURSOR_TIMER;
- }
+ cancel_delayed_work_sync(>cursor_work);
}
#ifndef MODULE
@@ -714,6 +700,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
struct fb_info *info,
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops)
err = -ENOMEM;
+
+ INIT_DELAYED_WORK(>cursor_work, fb_flashcursor);
}
if (!err) {
@@ -751,7 +739,7 @@ static int con2fb_release_oldinfo(struct vc_data *vc,
struct fb_info *oldinfo,
}
if (!err) {
- fbcon_del_cursor_timer(oldinfo);
+ fbcon_del_cursor_work(oldinfo);
kfree(ops->cursor_state.mask);
kfree(ops->cursor_data);
kfree(ops->cursor_src);
@@ -867,7 +855,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
logo_shown != FBCON_LOGO_DONTSHOW);
if (!found)
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
con2fb_map_boot[unit] = newidx;
con2fb_init_display(vc, info, unit, show_logo);
}
@@ -964,6 +952,8 @@ static const char *fbcon_startup(void)
return NULL;
}
+
[Intel-gfx] [PATCH v2 08/19] fb: Delete fb_info->queue
It was only used by fbcon, and that now switched to its own,
private work.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3d7306c9a706..23b19cf8bccd 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -449,7 +449,6 @@ struct fb_info {
struct fb_var_screeninfo var; /* Current var */
struct fb_fix_screeninfo fix; /* Current fix */
struct fb_monspecs monspecs;/* Current Monitor specs */
- struct work_struct queue; /* Framebuffer event queue */
struct fb_pixmap pixmap;/* Image hardware mapper */
struct fb_pixmap sprite;/* Cursor hardware mapper */
struct fb_cmap cmap;/* Current cmap */
--
2.34.1
[Intel-gfx] [PATCH v2 05/19] fbdev/sysfs: Fix locking
fb_set_var requires we hold the fb_info lock. Or at least this now matches what the ioctl does ... Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here, but I will not fix them up. Also in practice this isn't a big deal, because really variable fbdev state is actually protected by console_lock (because fbcon just doesn't bother with lock_fb_info() at all), and lock_fb_info protecting anything is really just a neat lie. But that's a much bigger fish to fry. Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Helge Deller Cc: Daniel Vetter Cc: Qing Wang Cc: Sam Ravnborg --- drivers/video/fbdev/core/fbsysfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c index 26892940c213..8c1ee9ecec3d 100644 --- a/drivers/video/fbdev/core/fbsysfs.c +++ b/drivers/video/fbdev/core/fbsysfs.c @@ -91,9 +91,11 @@ static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var) var->activate |= FB_ACTIVATE_FORCE; console_lock(); + lock_fb_info(fb_info); err = fb_set_var(fb_info, var); if (!err) fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL); + unlock_fb_info(fb_info); console_unlock(); if (err) return err; -- 2.34.1
[Intel-gfx] [PATCH v2 04/19] fbcon: delete delayed loading code
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev drivers where
already registered.
This is no longer possible, hence delete that code.
Note that the exit case is a bit more complex and will be done in a
separate patch.
Since I had to audit the entire fbcon load code I also spotted a wrong
function name in a comment in fbcon_startup(), which this patch also
fixes.
v2: Explain why we also fix the comment (Sam)
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Claudio Suarez
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
Cc: Du Cheng
---
drivers/video/fbdev/core/fbcon.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b75e638cb83d..83f0223f5333 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -944,7 +944,7 @@ static const char *fbcon_startup(void)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
-* fb_console_init();
+* fbcon_fb_registered();
*/
info = registered_fb[info_idx];
if (!info)
@@ -3299,17 +3299,6 @@ static void fbcon_start(void)
return;
}
#endif
-
- if (num_registered_fb) {
- int i;
-
- for_each_registered_fb(i) {
- info_idx = i;
- break;
- }
-
- do_fbcon_takeover(0);
- }
}
static void fbcon_exit(void)
--
2.34.1
[Intel-gfx] [PATCH v2 03/19] fbcon: Introduce wrapper for console->fb_info lookup
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
Cc: Du Cheng
Cc: Claudio Suarez
Cc: Thomas Zimmermann
---
drivers/video/fbdev/core/fbcon.c | 76 ++--
1 file changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index e925bb608e25..b75e638cb83d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -110,6 +110,18 @@ static struct fbcon_display fb_display[MAX_NR_CONSOLES];
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
+static struct fb_info *fbcon_info_from_console(int console)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ /*
+* Note that only con2fb_map is protected by the console lock,
+* registered_fb is protected by a separate mutex. This lookup can
+* therefore race.
+*/
+ return registered_fb[con2fb_map[console]];
+}
+
static int logo_lines;
/* logo_shown is an index to vc_cons when >= 0; otherwise follows FBCON_LOGO
enums. */
@@ -199,7 +211,7 @@ static void fbcon_rotate(struct fb_info *info, u32 rotate)
if (!ops || ops->currcon == -1)
return;
- fb_info = registered_fb[con2fb_map[ops->currcon]];
+ fb_info = fbcon_info_from_console(ops->currcon);
if (info == fb_info) {
struct fbcon_display *p = _display[ops->currcon];
@@ -226,7 +238,7 @@ static void fbcon_rotate_all(struct fb_info *info, u32
rotate)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
vc = vc_cons[i].d;
if (!vc || vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[i]] != info)
+ fbcon_info_from_console(i) != info)
continue;
p = _display[vc->vc_num];
@@ -356,7 +368,7 @@ static void fb_flashcursor(struct work_struct *work)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
- registered_fb[con2fb_map[vc->vc_num]] != info ||
+ fbcon_info_from_console(vc->vc_num) != info ||
vc->vc_deccm != 1) {
console_unlock();
return;
@@ -791,7 +803,7 @@ static void con2fb_init_display(struct vc_data *vc, struct
fb_info *info,
if (show_logo) {
struct vc_data *fg_vc = vc_cons[fg_console].d;
struct fb_info *fg_info =
- registered_fb[con2fb_map[fg_console]];
+ fbcon_info_from_console(fg_console);
fbcon_prepare_logo(fg_vc, fg_info, fg_vc->vc_cols,
fg_vc->vc_rows, fg_vc->vc_cols,
@@ -1014,7 +1026,7 @@ static void fbcon_init(struct vc_data *vc, int init)
if (con2fb_map[vc->vc_num] == -1)
con2fb_map[vc->vc_num] = info_idx;
- info = registered_fb[con2fb_map[vc->vc_num]];
+ info = fbcon_info_from_console(vc->vc_num);
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
logo_shown = FBCON_LOGO_DONTSHOW;
@@ -1231,7 +1243,7 @@ static void fbcon_deinit(struct vc_data *vc)
static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
int width)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = _display[vc->vc_num];
@@ -1269,7 +1281,7 @@ static void fbcon_clear(struct vc_data *vc, int sy, int
sx, int height,
static void fbcon_putcs(struct vc_data *vc, const unsigned short *s,
int count, int ypos, int xpos)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = _display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1289,7 +1301,7 @@ static void fbcon_putc(struct vc_data *vc, int c, int
ypos, int xpos)
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
if (!fbcon_is_inactive(vc, info))
@@ -1298,7 +1310,7 @@ static void fbcon_clear_margins(struct vc_data *vc, int
bottom_only)
static void fbcon_cursor(struct vc_data *vc, int mode)
{
- struct fb_info *info =
[Intel-gfx] [PATCH v2 01/19] fbcon: delete a few unneeded forward decl
I didn't bother with any code movement to fix the others, these just got a bit in the way. v2: Rebase on top of Helge's reverts. Acked-by: Sam Ravnborg (v1) Reviewed-by: Geert Uytterhoeven (v1) Signed-off-by: Daniel Vetter Cc: Helge Deller Cc: Daniel Vetter Cc: Thomas Zimmermann Cc: Du Cheng Cc: Tetsuo Handa Cc: Claudio Suarez Cc: Greg Kroah-Hartman --- drivers/video/fbdev/core/fbcon.c | 17 + 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 2fc1b80a26ad..235eaab37d84 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -163,29 +163,14 @@ static int fbcon_cursor_noblink; * Interface used by the world */ -static const char *fbcon_startup(void); -static void fbcon_init(struct vc_data *vc, int init); -static void fbcon_deinit(struct vc_data *vc); -static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height, - int width); -static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos); -static void fbcon_putcs(struct vc_data *vc, const unsigned short *s, - int count, int ypos, int xpos); static void fbcon_clear_margins(struct vc_data *vc, int bottom_only); -static void fbcon_cursor(struct vc_data *vc, int mode); static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx, int height, int width); -static int fbcon_switch(struct vc_data *vc); -static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch); static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table); /* * Internal routines */ -static __inline__ void ywrap_up(struct vc_data *vc, int count); -static __inline__ void ywrap_down(struct vc_data *vc, int count); -static __inline__ void ypan_up(struct vc_data *vc, int count); -static __inline__ void ypan_down(struct vc_data *vc, int count); static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy, int sx, int dy, int dx, int height, int width, u_int y_break); static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var, @@ -194,8 +179,8 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p, int line, int count, int dy); static void fbcon_modechanged(struct fb_info *info); static void fbcon_set_all_vcs(struct fb_info *info); -static void fbcon_start(void); static void fbcon_exit(void); + static struct device *fbcon_device; #ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION -- 2.34.1
[Intel-gfx] [PATCH v2 02/19] fbcon: Move fbcon_bmove(_rec) functions
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Greg Kroah-Hartman
---
drivers/video/fbdev/core/fbcon.c | 134 +++
1 file changed, 65 insertions(+), 69 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 235eaab37d84..e925bb608e25 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -164,15 +164,11 @@ static int fbcon_cursor_noblink;
*/
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only);
-static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
- int height, int width);
static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
/*
* Internal routines
*/
-static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int
sy, int sx,
- int dy, int dx, int height, int width, u_int
y_break);
static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
@@ -1667,6 +1663,71 @@ static void fbcon_redraw(struct vc_data *vc, struct
fbcon_display *p,
}
}
+static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int
sy, int sx,
+ int dy, int dx, int height, int width, u_int
y_break)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ u_int b;
+
+ if (sy < y_break && sy + height > y_break) {
+ b = y_break - sy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+
+ if (dy < y_break && dy + height > y_break) {
+ b = y_break - dy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+ ops->bmove(vc, info, real_y(p, sy), sx, real_y(p, dy), dx,
+ height, width);
+}
+
+static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
+ int height, int width)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = _display[vc->vc_num];
+
+ if (fbcon_is_inactive(vc, info))
+ return;
+
+ if (!width || !height)
+ return;
+
+ /* Split blits that cross physical y_wrap case.
+* Pathological case involves 4 blits, better to use recursive
+* code rather than unrolled case
+*
+* Recursive invocations don't need to erase the cursor over and
+* over again, so we use fbcon_bmove_rec()
+*/
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, height, width,
+ p->vrows - p->yscroll);
+}
+
static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
enum con_scroll dir, unsigned int count)
{
@@ -1867,71 +1928,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned
int t, unsigned int b,
}
-static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
- int height, int width)
-{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
- struct fbcon_display *p = _display[vc->vc_num];
-
- if (fbcon_is_inactive(vc, info))
- return;
-
- if (!width || !height)
- return;
-
- /* Split blits that cross physical y_wrap case.
-*
[Intel-gfx] [PATCH v2 00/19] fbcon patches, take two
Hi all, Second round, mostly just compile fixed and some minor polish to commit messages. Also MAINTAINERS patch and fbcon scrolling patches are out because they landed already. There's still a handful here that need review (and somehow intel-gfx-ci just keeled over on this). Cheers, Daniel Daniel Vetter (19): fbcon: delete a few unneeded forward decl fbcon: Move fbcon_bmove(_rec) functions fbcon: Introduce wrapper for console->fb_info lookup fbcon: delete delayed loading code fbdev/sysfs: Fix locking fbcon: Use delayed work for cursor fbcon: Replace FBCON_FLAGS_INIT with a boolean fb: Delete fb_info->queue fbcon: Extract fbcon_open/release helpers fbcon: Ditch error handling for con2fb_release_oldinfo fbcon: move more common code into fb_open() fbcon: use lock_fb_info in fbcon_open/release fbcon: Consistently protect deferred_takeover with console_lock() fbcon: Move console_lock for register/unlink/unregister fbcon: Move more code into fbcon_release fbcon: untangle fbcon_exit fbcon: Maintain a private array of fb_info Revert "fbdev: Prevent probing generic drivers if a FB is already registered" fbdev: Make registered_fb[] private to fbmem.c drivers/video/fbdev/core/fbcon.c | 692 ++--- drivers/video/fbdev/core/fbcon.h | 8 +- drivers/video/fbdev/core/fbmem.c | 35 +- drivers/video/fbdev/core/fbsysfs.c | 2 + drivers/video/fbdev/efifb.c| 11 - drivers/video/fbdev/simplefb.c | 11 - include/linux/fb.h | 8 +- 7 files changed, 342 insertions(+), 425 deletions(-) -- 2.34.1
Re: [Intel-gfx] [PATCH 0/1] Ensure zero alignment on gens < 4
On 24/11/2021 18:07, Zbigniew Kempczyński wrote: On Wed, Nov 24, 2021 at 08:45:50AM +, Tvrtko Ursulin wrote: On 24/11/2021 08:04, Zbigniew Kempczyński wrote: On Tue, Nov 23, 2021 at 09:49:04AM +, Tvrtko Ursulin wrote: On 22/11/2021 19:13, Zbigniew Kempczyński wrote: In short - we want to enforce alignment == 0 for gen4+ GEM object settings. Before we merge this we need to inspect all UMD we expect can use this. My investigation was narrowed to UMD code: 1. IGT 2. Mesa 3. Media-Driver 4. NEO 5. libdrm 6. xf86-intel-video I would like to ask subsystem developers / maintainers to confirm my analysis. 1. IGT: We've already removed / fixed most of the code where alignment != 0. What left was few multi-card subtests I'm not able to rewrite due to lack of such hw (nv + intel on the board). 2. Mesa: gallium/drivers/iris/iris_batch.c,iris_bufmgr.c - it uses softpinning only with alignment handled by allocator, so drm_i915_gem_exec_object2 alignment field == 0. drivers/dri/i965/brw_batch.c,brw_screen.c - it uses relocations but it is supported by allocator, there're no direct alignment settings to value != 0. vulcan/anv_batch_chain.c: drm_i915_gem_exec_object2 objects are initialized within anv_execbuf_add_bo() and .alignment field is set to 0 there. There's no other place where I've found vulcan driver touches it both for softpinning / relocations. 3. Media-Driver: It contains modified libdrm code and three functions which do allocations, all of them uses mos_gem_bo_alloc_internal(): - mos_gem_bo_alloc() - internally uses alignment == 0, that's ok - mos_gem_bo_alloc_tiled() - same as mos_gem_bo_alloc() - mos_gem_bo_alloc_for_render() - this one passes alignment from the caller and it may be != 0. But I haven't found practical usage of this function externally (using mos_bo_alloc_for_render() wrapper). There's another userptr allocation function: mos_bo_alloc_userptr() but it doesn't use alignment. 4. NEO: Uses softpinning only with alignment == 0: source/os_interface/linux/drm_buffer_object.cpp: void BufferObject::fillExecObject() has execObject.alignment = 0; 5. libdrm: Corresponding functions to Media-Driver: drm_intel_bo_alloc(), drm_intel_bo_alloc_for_render(), drm_intel_bo_alloc_userptr() and drm_intel_bo_alloc_tiled(). Alignment field is used in drm_intel_bo_alloc_for_render() so couple not rewritten IGTs may encounter issue here (alignment passed in IGTs which still uses libdrm == 4096). 6. xf86-intel-video: src/sna/kgem.c: _kgem_submit() - alignment is set to 0 so this shouldn't be a problem. You also need to figure out not only what codebase currently uses this, but what maybe has an older version in the field which used to, right? Otherwise kernel upgrade can break someones old userspace which is not allowed. Just raising this for consideration if it isn't already on your radar. Do you mean should I for example check each Ubuntu LTS (14.04, 16.04 and so on), find commit id used to build above and examine above source code again? And also do this for other distros? I think from another direction, for each of the above listed libraries see in their git history (inputs from owners should help) if they ever used non-zero alignment and if they have map it to released versions. Then see is those released versions shipped in any distro, maybe via distro watch, if they have a database going far enough. I don't know what would be the best plan of looking through codebase history. Maybe git log -S/-G with strings which would catch assignemnts to alignments, or passing in those parameters? Or just git log at first instance. In the ideal world each userspace library above can say they never ever used it and then it's simpler. Unless there is some obscure thing linking directly to libdrm out in the wild? Maybe check distro packages to see all that depend on it. Thanks for hints, you're right. I should walk over rev-list history and find any problematic code. Problematic I mean direct obj alignment setting or usage of libdrm bo_alloc_for_render() where alignment can be passed as an argument. I've missed UXA also uses libdrm and bo_alloc_for_render() but alignment was set to 0 in whole history so this driver shouldn't be a problem. If anyone knows which project would directly use libdrm with intel bo bufmgr I would appreciate. -- Zbigniew I performed some code archaeology across the various userland projects. See below for notes on each project. From what I could find, there appears to be only 1 historical use of alignment != 0: mesa intel winsys driver used 4K alignments from 2012-2017, but was only actullay passed through from 2015-2017. Only gallium ilo driver appeared to ever use it. Given this, we could either not care about that and go ahead with the
[Intel-gfx] [PATCH v3 4/4] drm/i915/guc: Verify hwconfig blob matches supported format
i915_drm.h now defines the format of the returned
DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
the black box GuC software, it should verify that the data matches
that format before sending it to user-space.
The verification makes a single simple pass through the blob contents,
so this verification step should not add a significant amount of init
time to i915.
v3:
* Add various changes suggested by Tvrtko
Signed-off-by: Jordan Justen
---
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 56 ++-
1 file changed, 53 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index ce6088f112d4..350a0517b9f0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -71,7 +71,52 @@ static int guc_hwconfig_discover_size(struct
intel_guc_hwconfig *hwconfig)
return 0;
}
-static int guc_hwconfig_fill_buffer(struct intel_guc_hwconfig *hwconfig)
+static int verify_hwconfig_blob(struct drm_device *drm,
+ const struct intel_guc_hwconfig *hwconfig)
+{
+ struct drm_i915_query_hwconfig_blob_item *pos;
+ u32 remaining;
+
+ if (hwconfig->size % 4 != 0 || hwconfig->ptr == NULL)
+ return -EINVAL;
+
+ pos = hwconfig->ptr;
+ /* The number of dwords in the blob to validate. Each loop
+* pass will process at least 2 dwords corresponding to the
+* key and length fields of the item. In addition, the length
+* field of the item indicates the length of the data array,
+* and that number of dwords will be processed (skipped) as
+* well.
+*/
+ remaining = hwconfig->size / 4;
+
+ while (remaining > 0) {
+ /* Each item requires at least 2 dwords for the key
+* and length fields. If the length field is 0, then
+* the data array would be of length 0.
+*/
+ if (remaining < 2)
+ return -EINVAL;
+ /* remaining >= 2, so subtracting 2 is ok, whereas
+* adding 2 to pos->length could overflow.
+*/
+ if (pos->length > remaining - 2)
+ return -EINVAL;
+ /* The length check above ensures that the adjustment
+* of the remaining variable will not underflow, and
+* that the adjustment of the pos variable will not
+* pass the end of the blob data.
+*/
+ remaining -= 2 + pos->length;
+ pos = (void *)>data[pos->length];
+ }
+
+ drm_dbg(drm, "hwconfig blob format is valid\n");
+ return 0;
+}
+
+static int guc_hwconfig_fill_buffer(struct drm_device *drm,
+ struct intel_guc_hwconfig *hwconfig)
{
struct intel_guc *guc = hwconfig_to_guc(hwconfig);
struct i915_vma *vma;
@@ -88,8 +133,13 @@ static int guc_hwconfig_fill_buffer(struct
intel_guc_hwconfig *hwconfig)
ggtt_offset = intel_guc_ggtt_offset(guc, vma);
ret = __guc_action_get_hwconfig(hwconfig, ggtt_offset, hwconfig->size);
- if (ret >= 0)
+ if (ret >= 0) {
memcpy(hwconfig->ptr, vaddr, hwconfig->size);
+ if (verify_hwconfig_blob(drm, hwconfig)) {
+ drm_err(drm, "Ignoring invalid hwconfig blob received
from GuC!\n");
+ ret = -EINVAL;
+ }
+ }
i915_vma_unpin_and_release(, I915_VMA_RELEASE_MAP);
@@ -141,7 +191,7 @@ int intel_guc_hwconfig_init(struct intel_guc_hwconfig
*hwconfig)
return -ENOMEM;
}
- ret = guc_hwconfig_fill_buffer(hwconfig);
+ ret = guc_hwconfig_fill_buffer(>drm, hwconfig);
if (ret < 0) {
intel_guc_hwconfig_fini(hwconfig);
return ret;
--
2.34.1
[Intel-gfx] [PATCH v3 3/4] drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
v3:
* Add various changes suggested by Tvrtko
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
---
include/uapi/drm/i915_drm.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 069d2fadfbd9..c3faee3b3f70 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3276,6 +3276,38 @@ struct drm_i915_gem_create_ext_protected_content {
__u32 flags;
};
+/**
+ * DOC: GuC HWCONFIG blob uAPI
+ *
+ * The GuC produces a blob with information about the current device.
+ * i915 reads this blob from GuC and makes it available via this uAPI.
+ *
+ * The returned blob is a sequence of items of variable length
+ * described by struct drm_i915_query_hwconfig_blob_item. The
+ * drm_i915_query_hwconfig_blob_item length field gives the length of
+ * the drm_i915_query_hwconfig_blob_item data[] array for the item and
+ * thereby determines the length of that item. The key and length
+ * fields are required, so the minimum item size is 2 x __u32, or 8
+ * bytes.
+ *
+ * The overall blob returned by DRM_I915_QUERY_HWCONFIG_BLOB will end
+ * at the same location as the end of the final
+ * drm_i915_query_hwconfig_blob_item. In other words, walking through
+ * the individual items is guaranteed to eventually arrive at the
+ * exact end of the entire blob.
+ *
+ * The meaning of the key field and the data values are documented in
+ * the Programmer's Reference Manual.
+ */
+struct drm_i915_query_hwconfig_blob_item {
+ /** @key: Enum which defines how to interpret @data values. */
+ __u32 key;
+ /** @length: Length of the @data array. */
+ __u32 length;
+ /** @key: Array of values with meaning defined by @key */
+ __u32 data[];
+};
+
/* ID of the protected content session managed by i915 when PXP is active */
#define I915_PROTECTED_CONTENT_DEFAULT_SESSION 0xf
--
2.34.1
[Intel-gfx] [PATCH v3 2/4] drm/i915/uapi: Add query for hwconfig blob
From: Rodrigo Vivi
The DRM_I915_QUERY_HWCONFIG_BLOB query item returns a blob of data
which it receives from the GuC software. This blob provides some
useful data about the hardware for drivers.
Although the blob is not fully documented at this time, the basic
format is an array of u32 values. The array is a simple and flexible
KLV (Key/Length/Value) formatted table. For example, it could be just:
enum device_attr { ATTR_SOME_VALUE = 0, ATTR_SOME_MASK = 1, };
static const u32 hwconfig[] = {
ATTR_SOME_VALUE,
1, // Value Length in DWords
8, // Value
ATTR_SOME_MASK,
3,
0x00, 0x, 0xFF00,
};
The attribute ids and meaning of the values will be documented in the
Programmer Reference Manuals when released.
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
Cc: Michal Wajdeczko
Cc: Slawomir Milczarek
Cc: Joonas Lahtinen
Signed-off-by: Rodrigo Vivi
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
Acked-by: Jordan Justen
Tested-by: Jordan Justen
---
drivers/gpu/drm/i915/i915_query.c | 23 +++
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..195524e9a369 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private
*i915,
return total_length;
}
+static int query_hwconfig_blob(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct intel_gt *gt = to_gt(i915);
+ struct intel_guc_hwconfig *hwconfig = >uc.guc.hwconfig;
+
+ if (!hwconfig->size || !hwconfig->ptr)
+ return -ENODEV;
+
+ if (query_item->length == 0)
+ return hwconfig->size;
+
+ if (query_item->length < hwconfig->size)
+ return -EINVAL;
+
+ if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+hwconfig->ptr, hwconfig->size))
+ return -EFAULT;
+
+ return hwconfig->size;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
query_engine_info,
query_perf_config,
query_memregion_info,
+ query_hwconfig_blob,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 914ebd9290e5..069d2fadfbd9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
#define DRM_I915_QUERY_ENGINE_INFO 2
#define DRM_I915_QUERY_PERF_CONFIG 3
#define DRM_I915_QUERY_MEMORY_REGIONS 4
+#define DRM_I915_QUERY_HWCONFIG_BLOB 5
/* Must be kept compact -- no holes and well documented */
/**
--
2.34.1
[Intel-gfx] [PATCH v3 1/4] drm/i915/guc: Add fetch of hwconfig table
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Michal Wajdeczko
Signed-off-by: Rodrigo Vivi
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
.../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 3 +
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 151 ++
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +
7 files changed, 185 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6836b020a5be..ba9b6557d59d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -192,6 +192,7 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_guc_rc.o \
gt/uc/intel_guc_slpc.o \
gt/uc/intel_guc_submission.o \
+ gt/uc/intel_guc_hwconfig.o \
gt/uc/intel_huc.o \
gt/uc/intel_huc_debugfs.o \
gt/uc/intel_huc_fw.o
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index fe5d7d261797..4a61c819f32b 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -137,6 +137,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_SETUP_PC_GUCRC = 0x3004,
INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
+ INTEL_GUC_ACTION_GET_HWCONFIG = 0x4100,
INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index 488b6061ee89..f9e2a6aaef4a 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -8,6 +8,10 @@
enum intel_guc_response_status {
INTEL_GUC_RESPONSE_STATUS_SUCCESS = 0x0,
+ INTEL_GUC_RESPONSE_NOT_SUPPORTED = 0x20,
+ INTEL_GUC_RESPONSE_NO_ATTRIBUTE_TABLE = 0x201,
+ INTEL_GUC_RESPONSE_NO_DECRYPTION_KEY = 0x202,
+ INTEL_GUC_RESPONSE_DECRYPTION_FAILED = 0x204,
INTEL_GUC_RESPONSE_STATUS_GENERIC_FAIL = 0xF000,
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index f9240d4baa69..ce2ff4bb0fd5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -13,6 +13,7 @@
#include "intel_guc_fw.h"
#include "intel_guc_fwif.h"
#include "intel_guc_ct.h"
+#include "intel_guc_hwconfig.h"
#include "intel_guc_log.h"
#include "intel_guc_reg.h"
#include "intel_guc_slpc_types.h"
@@ -37,6 +38,8 @@ struct intel_guc {
struct intel_guc_ct ct;
/** @slpc: sub-structure containing SLPC related data and objects */
struct intel_guc_slpc slpc;
+ /** @hwconfig: hardware configuration KLV table */
+ struct intel_guc_hwconfig hwconfig;
/** @sched_engine: Global engine used to submit requests to GuC */
struct i915_sched_engine *sched_engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
new file mode 100644
index ..ce6088f112d4
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "gt/intel_gt.h"
+#include "i915_drv.h"
+#include "i915_memcpy.h"
+#include "intel_guc_hwconfig.h"
+
+static inline struct intel_guc *hwconfig_to_guc(struct intel_guc_hwconfig
*hwconfig)
+{
+ return container_of(hwconfig, struct intel_guc, hwconfig);
+}
+
+/*
+ * GuC has a blob containing hardware configuration information (HWConfig).
+ * This is formatted as a simple and flexible KLV (Key/Length/Value) table.
+ *
+ * For example, a minimal version could be:
+ * enum device_attr {
+ * ATTR_SOME_VALUE = 0,
+ * ATTR_SOME_MASK = 1,
+ * };
+ *
+ * static const u32 hwconfig[] = {
+ * ATTR_SOME_VALUE,
+ * 1, // Value Length in DWords
+ * 8, // Value
+ *
+ * ATTR_SOME_MASK,
+ * 3,
+ * 0x00, 0x, 0xFF00,
+ * };
+ *
+ * The attribute ids are defined in a hardware spec.
+ */
+
+static int __guc_action_get_hwconfig(struct intel_guc_hwconfig *hwconfig,
+u32
[Intel-gfx] [PATCH v3 0/4] GuC HWCONFIG with documentation
This is John/Rodrigo's 2 patches with some minor changes, and I added 2 patches. "drm/i915/uapi: Add query for hwconfig blob" was changed: * Rename DRM_I915_QUERY_HWCONFIG_TABLE to DRM_I915_QUERY_HWCONFIG_BLOB as requested by Joonas. * Reword commit message * I added Acked-by to this patch, but this only applies in the context of this version of the patchset. If my changes are rejected, then please *do not* add my Acked-by to the other series. In particular, I do not want my Acked-by on the patch if the patch mentions the HWCONFIG format, but is not willing to add that to the actual uAPI. I also do not want my Acked-by on it if it mentions "consolidation" of this data. Since we are dealing with open source projects (aside from GuC), this doesn't seem appropriate. "drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item" adds a struct to the uAPI and documents the return value for DRM_I915_QUERY_HWCONFIG_BLOB. (Except, keys / values are still deferred to the PRM.) "drm/i915/guc: Verify hwconfig blob matches supported format" does the simple verification of the blob to make sure it matches what the uAPI documents. v2: * Fix -Werror errors. * Rebase to drm-intel/for-linux-next instead of drm-intel/for-linux-next-gt, as this seems to be what CI wants. * Fix u32 -> __u32. (Sorry, I was first testing in Mesa tree.) * Add commit message for "Verify hwconfig blob" patch as requested by Tvrtko. * Reword text added to i915_drm.h as requested by Tvrtko. (Attempting to indicate the overall blob ends right at the last blob item.) v3: * Add several changes suggested by Tvrtko in the "Verify hwconfig blob", along with some tweaks to i915_drm.h from the feedback for the same patch. John Harrison (1): drm/i915/guc: Add fetch of hwconfig table Jordan Justen (2): drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item drm/i915/guc: Verify hwconfig blob matches supported format Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig blob drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.h| 3 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 201 ++ .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 ++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 + drivers/gpu/drm/i915/i915_query.c | 23 ++ include/uapi/drm/i915_drm.h | 33 +++ 9 files changed, 291 insertions(+) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h -- 2.34.1
Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
On Tue, Feb 08, 2022 at 03:04:51PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> > Hi Daniel,
> >
> > Thanks for your patch!
> >
> > On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote:
> > > Well except when the olpc dcon fbdev driver is enabled, that thing
> > > digs around in there in rather unfixable ways.
> >
> > Can't the actual frame buffer driver (which one?) used on olpc export
> > a pointer to its fb_info?
>
> Yeah that might be the right thing to do, I'll add that as a stagin TODO
> in the next iteration.
Well I tried to do that and noticed I've done that already in 2019:
commit af1440368837f19ac7d5dec05d929d91308f5a90
Author: Daniel Vetter
Date: Tue May 28 11:03:03 2019 +0200
staging/olpc_dcon: Add drm conversion to TODO
TODO already explains how this should be done correctly in drm. Well maybe
we should add that stitching the drivers together should be done with
component.c or something like that.
-Daniel
>
> >
> > > --- a/drivers/video/fbdev/core/fbmem.c
> > > +++ b/drivers/video/fbdev/core/fbmem.c
> > > @@ -48,10 +48,14 @@
> > > static DEFINE_MUTEX(registration_lock);
> > >
> > > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > > -EXPORT_SYMBOL(registered_fb);
> > > -
> > > int num_registered_fb __read_mostly;
> > > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> >
> > CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
> > by the robot.
>
> Yeah realized that too and fixed it locally.
>
> Cheers, Daniel
>
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > ge...@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like
> > that.
> > -- Linus Torvalds
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
On Tue, Feb 08, 2022 at 08:00:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
> >
> > Cc oldc_dcon maintainers as fyi.
> >
> > Cc: Jens Frederich
> > Cc: Jon Nettleton
> > Cc: Greg Kroah-Hartman
> > Cc: linux-stag...@lists.linux.dev
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Helge Deller
> > Cc: Matthew Wilcox
> > Cc: Sam Ravnborg
> > Cc: Tetsuo Handa
> > Cc: Zhen Lei
> > Cc: Alex Deucher
> > Cc: Xiyu Yang
> > Cc: linux-fb...@vger.kernel.org
> > Cc: Zheyu Ma
> > Cc: Guenter Roeck
>
> with the build thingy fixed:
> Acked-by: Sam Ravnborg
>
> I do wonder if there is a more clean way to trigger a blank
> in the main fbdev driver from the olpc driver.
>
> The current hack is not nice and it would be good to see it gone.
Yeah this is just badly engineered. In drm we'd do this with the self
refresh helpers, which pretty much give you this exact functionality, but
in the helpers, while not randomly breaking actual visible behaviour of
the display driver.
Well ok the illusion is not perfect, since if the display is suspended the
next page flip will take a tad longer. But that's it.
I'll also add this to the TODO.
-Daniel
>
> Sam
>
> > ---
> > drivers/video/fbdev/core/fbmem.c | 8 ++--
> > include/linux/fb.h | 7 +++
> > 2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index 904ef1250677..dad6572942fa 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > +EXPORT_SYMBOL(registered_fb);
> > EXPORT_SYMBOL(num_registered_fb);
> > +#endif
> > +#define for_each_registered_fb(i) \
> > + for (i = 0; i < FB_MAX; i++)\
> > + if (!registered_fb[i]) {} else
> >
> > bool fb_center_logo __read_mostly;
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index a8a00d2ba1f3..e236817502c2 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct
> > fb_var_screeninfo *var,
> > extern int fb_get_options(const char *name, char **option);
> > extern int fb_new_modelist(struct fb_info *info);
> >
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > extern struct fb_info *registered_fb[FB_MAX];
> > +
> > extern int num_registered_fb;
> > +#endif
> > extern bool fb_center_logo;
> > extern int fb_logo_count;
> > extern struct class *fb_class;
> >
> > -#define for_each_registered_fb(i) \
> > - for (i = 0; i < FB_MAX; i++)\
> > - if (!registered_fb[i]) {} else
> > -
> > static inline void lock_fb_info(struct fb_info *info)
> > {
> > mutex_lock(>lock);
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [RFC 0/2] Compile out integrated
On Tue, Feb 08, 2022 at 10:31:10AM +, Tvrtko Ursulin wrote: On 02/02/2022 16:26, Lucas De Marchi wrote: On Wed, Feb 02, 2022 at 10:26:46AM +, Tvrtko Ursulin wrote: On 01/02/2022 17:28, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote: On Tue, 01 Feb 2022, Lucas De Marchi wrote: On Tue, Feb 01, 2022 at 11:15:31AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Quicky and dirty hack based on some old ideas. Thought maybe the approach might interest the Arm port guys. But with IS_GEN_RANGE removed easy gains are not so big so meh.. Maybe some more easy wins with IS_DISPLAY_VER but I haven't looked into that side. 3884664 449681 6720 4341065 423d49 i915.ko.tip 3599989 429034 6688 4035711 3d947f i915.ko.noigp By these numbers probably it's hard to justify. Another thing to consider is that it's very common to have on the same system both integrated and discrete - doing this would remove at compile time any chance of driving the integrated one. I guess the point was, the arm systems won't have integrated, and it's anyway going to be a separate build. so probably the focus and argument here should not be about size reduction. From patch 1 I see: +config DRM_I915_INTEGRATED_GPU_SUPPORT + bool "Support integrated GPUs" + default y + depends on DRM_I915 + help + Include support for integrated GPUs. If it's something that depends on arch rather than providing an option in menuconfig, then I think it could be some interesting investigation. However, I can't see how it would help with removing some code paths in the driver (e.g. the clflush() calls we were talking about in another patch series) since the code elimination would all happen at link time. Clflush class of problems is yet another orthogonal set of problems. Yes, idea was that the Kconfig option would be selected by Arm, or deselected by x86, whatever. But there is also a case for letting it be user visible. In general, I thought at least, we should look into not building/deploying binary code for irrelevant hardware on Arm builds. If that is clear and agreeable then I think the approach how to get there is really multi-pronged. 1) What you are partly doing with "clflush" type series. Make Arm relevant code paths actually compile on Arm. to be clear, the goal is to be more architecture independent and this is being tested with arm64. 2a) What I sent in this series - it's simple/easy dead code elimination from a single compilation unit. 2b) *If* we resurrected GRAPHICS_VER check where "ver" is part of the macro, eg. not doing "if (GRAPHICS_VER <=> N)" but "if (GRAPHICS_VERN)", or "if IS_GRAPHICS_VER(N, FOREVER)", then the same approach would be more effective. Because if N or range is the macro parameter, we can make it dead code based on Kconfig. yes I remember that. But when it was done the IS_GRAPHICS_VER() was already not much used. I doubt the handful places it was used in would change much of the overall picture we had at that point. Right, I was referring to the time when N is inside the macro. Like before IS_GEN(p, N) was replaced with GRAPHICS_VER, when N went outside the macro. This is what I demonstrated few years ago by being able to compile out ~3rd of a driver when selecting only execlists platforms, AFAIR. And which is why I was a bit unhappy this was getting removed not so long ago. 3) Complex step is putting LTO into use to allow dead code elimination between compilation units. Think: file1.c: RUNTIME_INFO->needs_blah = IS_PLATFORM && blah file2.c if (RUNTIME_INFO->needs_blah) ..dead code eliminated by LTO only.. Few years ago Andi Kleen had a proof of concept of KBuild LTO but I don't know what is the status of that. If LTO can be enabled then work from steps 2a automatically works much much better. 4) If LTO is not there yet maybe see how to slightly refactor the code so that we can completely drop compilation units from the Makefile. Drop files like gt/intel_ring_submission.c, or similar if we have or can create candidates. I think this is something we have to do and to go after. I think it's more future-proof to organize the code to have a better separation of platforms, instead of relying on the linker to do the dead code elimination based on user selection. Yes, definitely high level refactor. I just think it can't be fully done and some dead code elimination is cheap enough to have to handle the remaining parts. I'm fine with compiling out stuff on i915 right now because "this can only and will ever (as far as we know) work on x86". I'm more reluctant about adding a build option though. For the same reasons Jani mentioned and that it suddenly may open the doors for a matrix of configuration (e.g. build with/without display, or rc6, or dsi, or name-the-feature-you-dont-want). Yeah okay, I was not saying it absolutely needs to be user visible. Just that it
[Intel-gfx] [PATCH v8 4/5] drm/i915: add gtt misalignment test
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use i915_vma_unbind_unlocked in misalignment test
v8:
* handle stolen smem region returning -ENODEV due to
uninitialized on some setups
* avoid trying to test bad alignments on single page hole regions
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 126 ++
1 file changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..4de86e0f33e4 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include
#include
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,118 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct
intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+ bool is_stolen = mr->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+mr->type == INTEL_MEMORY_STOLEN_LOCAL;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj)) {
+ /* if iGVT-g or DMAR is active, stolen mem will be
uninitialized */
+ if (PTR_ERR(obj) == -ENODEV && is_stolen)
+ return 0;
+ return PTR_ERR(obj);
+ }
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(>node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 <<
(ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* compact-pt should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size !=
expected_node_size) {
+ err = i915_vma_unbind_unlocked(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind_unlocked(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(>node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, (enum
intel_memory_type)id);
+ u64 size = min_alignment;
+ u64 addr = round_down(hole_start + (hole_size / 2),
min_alignment);
+
+ /* avoid -ENOSPC on very small hole setups */
+ if (hole_size < 3 * min_alignment)
+ continue;
+
+ /* we can't test < 4k alignment due to flags being encoded in
lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr,
