Re: [PULL] topic/intel-gen-to-ver -> drm-intel-next and drm-intel-gt-next
Quoting Jani Nikula (2021-04-19 12:53:11)
>
> Hi Joonas and Rodrigo -
>
> Here's the gen to ver conversion topic branch to be merged to both
> drm-intel-next and drm-intel-gt-next.
Pulled.
Regards, Joonas
> Lots of Cc's for heads up.
>
>
> BR,
> Jani.
>
>
> topic/intel-gen-to-ver-2021-04-19:
> Gen to ver conversions across the driver
>
> The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
> cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
> conflicts.
>
> [1] https://patchwork.freedesktop.org/series/88825/
> [2] https://patchwork.freedesktop.org/series/88938/
> [3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}")
>
> BR,
> Jani.
>
> The following changes since commit 9c0fed84d5750e1eea6c664e073ffa2534a17743:
>
> Merge tag 'drm-intel-next-2021-04-01' of
> git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-04-08
> 14:02:21 +1000)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-intel
> tags/topic/intel-gen-to-ver-2021-04-19
>
> for you to fetch changes up to 425390c5dce6da76578389629d19517fcd79c959:
>
> drm/i915: split dgfx features from gen 12 (2021-04-14 13:05:06 +0300)
>
>
> Gen to ver conversions across the driver
>
> The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
> cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
> conflicts.
>
> [1] https://patchwork.freedesktop.org/series/88825/
> [2] https://patchwork.freedesktop.org/series/88938/
> [3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}")
>
>
> Lucas De Marchi (12):
> drm/i915/display: use DISPLAY_VER() on remaining users
> drm/i915: rename display.version to display.ver
> drm/i915/display: rename display version macros
> drm/i915: add macros for graphics and media versions
> drm/i915/gt: replace gen use in intel_engine_cs
> drm/i915/selftests: replace unused mask with simple version
> drm/i915/selftests: eliminate use of gen_mask
> drm/i915: finish removal of gen_mask
> drm/i915: eliminate remaining uses of intel_device_info->gen
> drm/i915: finish removal of gen from intel_device_info
> drm/i915: add media and display versions to device_info print
> drm/i915: split dgfx features from gen 12
>
> Matt Roper (1):
> drm/i915/display: Eliminate IS_GEN9_{BC,LP}
>
> Ville Syrjälä (5):
> drm/i915: Restore lost glk FBC 16bpp w/a
> drm/i915: Restore lost glk ccs w/a
> drm/i915: Disable LTTPR detection on GLK once again
> drm/i915: Don't use {skl, cnl}_hpd_pin() for bxt/glk
> drm/i915: Remove a few redundant glk checks
>
> drivers/gpu/drm/i915/display/i9xx_plane.c | 2 +-
> drivers/gpu/drm/i915/display/icl_dsi.c | 4 +-
> drivers/gpu/drm/i915/display/intel_atomic.c| 2 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 4 +-
> drivers/gpu/drm/i915/display/intel_bios.c | 9 +--
> drivers/gpu/drm/i915/display/intel_bw.c| 8 +--
> drivers/gpu/drm/i915/display/intel_cdclk.c | 42 +++---
> drivers/gpu/drm/i915/display/intel_color.c | 6 +-
> drivers/gpu/drm/i915/display/intel_crt.c | 6 +-
> drivers/gpu/drm/i915/display/intel_crtc.c | 4 +-
> drivers/gpu/drm/i915/display/intel_csr.c | 4 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 53 +-
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 10 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 64
> +++---
> .../gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display_power.c | 57 ++-
> drivers/gpu/drm/i915/display/intel_dp.c| 10 ++--
> .../gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c| 2 +-
> drivers/gpu/drm/i915/display/intel_dpll.c | 8 +--
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 6 +-
> drivers/gpu/drm/i915/display/intel_fb.c| 2 +-
> drivers/gpu/drm/i915/display/intel_fbc.c | 21 +++
> drivers/gpu/drm/i915/display/intel_fifo_underrun.c | 4 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_hdcp.c | 9 +--
> drivers/gpu/drm/i915/display/intel_hdmi.c | 9 +--
> drivers/gpu/drm/i915/display/intel_lvds.c | 2 +-
> drivers/gpu/drm/i915/display/intel_overlay.c | 10 ++--
> drivers/gpu/drm/i915/display/intel_panel.c | 10 ++--
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 4 +-
> drivers/gpu/drm/i915/display/intel_pps.c | 14 ++---
> drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
> drivers/gpu/drm/i
Re: linux-next: Signed-off-by missing for commit in the drm-intel tree
Hi Matt,
Always use the dim tooling when applying patches, it will do the right
thing with regards to adding the S-o-b.
Regards, Joonas
Quoting Stephen Rothwell (2021-07-15 07:18:54)
> Hi all,
>
> Commit
>
> db47fe727e1f ("drm/i915/step: s/_revid_tbl/_revids")
>
> is missing a Signed-off-by from its committer.
>
> --
> Cheers,
> Stephen Rothwell
[PULL] drm-intel-gt-next
a bit drm/i915: Ditch i915 globals shrink infrastructure drm/i915: Check for nomodeset in i915_init() first drm/i915: move i915_active slab to direct module init/exit drm/i915: move i915_buddy slab to direct module init/exit drm/i915: move intel_context slab to direct module init/exit drm/i915: move gem_context slab to direct module init/exit drm/i915: move gem_objects slab to direct module init/exit drm/i915: move request slabs to direct module init/exit drm/i915: move scheduler slabs to direct module init/exit drm/i915: move vma slab to direct module init/exit drm/i915: Remove i915_globals drm/i915: Extract i915_module.c drm/i915: Disable gpu relocations drm/i915: delete gpu reloc code Daniele Ceraolo Spurio (3): drm/i915: extract steered reg access to common function drm/i915/guc: Unblock GuC submission on Gen11+ drm/i915/xehp: handle new steering options Jason Ekstrand (46): drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE drm/i915: Stop storing the ring size in the ring pointer (v3) drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2) drm/i915/gem: Return void from context_apply_all drm/i915: Drop the CONTEXT_CLONE API (v2) drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4) drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES drm/i915/gem: Disallow bonding of virtual engines (v3) drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT (v2) drm/i915/request: Remove the hook from await_execution drm/i915/gem: Disallow creating contexts with too many engines drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2) drm/i915/gem: Add a separate validate_priority helper drm/i915: Add gem/i915_gem_context.h to the docs drm/i915/gem: Add an intermediate proto_context struct (v5) drm/i915/gem: Rework error handling in default_engines drm/i915/gem: Optionally set SSEU in intel_context_set_gem drm/i915: Add an i915_gem_vm_lookup helper drm/i915/gem: Make an alignment check more sensible drm/i915/gem: Use the proto-context to handle create parameters (v5) drm/i915/gem: Return an error ptr from context_lookup drm/i915/gt: Drop i915_address_space::file (v2) drm/i915/gem: Delay context creation (v3) drm/i915/gem: Don't allow changing the VM on running contexts (v4) drm/i915/gem: Don't allow changing the engine set on running contexts (v3) drm/i915/selftests: Take a VM in kernel_context() i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec drm/i915/gem: Roll all of context creation together drm/i915: Finalize contexts in GEM_CONTEXT_CREATE on version 13+ drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser" Revert "drm/i915: Propagate errors on awaiting already signaled fences" drm/i915: Remove allow_alloc from i915_gem_object_get_sg* drm/i915: Drop error handling from dma_fence_work Revert "drm/i915: Skip over MI_NOOP when parsing" drm/i915: Correct the docs for intel_engine_cmd_parser drm/i915: Call i915_globals_exit() after i915_pmu_exit() drm/i915: Call i915_globals_exit() if pci_register_device() fails drm/i915: Use a table for i915_init/exit (v2) drm/i915: Make the kmem slab for i915_buddy_block a global drm/i915/gem: Check object_can_migrate from object_migrate drm/i915/gem: Refactor placement setup for i915_gem_object_create* (v2) drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create() drm/i915/gem: Unify user object creation (v3) drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails John Harrison (19): drm/i915/huc: Update TGL and friends to HuC 7.9.3 drm/i915/adlp: Add ADL-P GuC/HuC firmware files drm/i915/guc: Module load failure test for CT buffer creation drm/i915/selftests: Allow for larger engine counts drm/i915/xehp: Extra media engines - Part 1 (engine definitions) drm/i915/xehp: Extra media engines - Part 2 (interrupts) drm/i915/xehp: Extra media engines - Part 3 (reset) drm/i915/guc: Make hangcheck work with GuC virtual engines drm/i915/guc: Provide mmio list to be saved/restored on engine reset drm/i915/guc: Don't complain about reset races drm/i915/guc: Enable GuC engine reset drm/i915/guc: Fix for error capture after full GPU reset with GuC drm/i915/guc: Hook GuC scheduling policies up drm/i915/guc: Connect reset modparam updates to GuC policy flags drm/i915/guc: Include scheduling policies in the debugfs state dump drm/i915/guc: Add golden context to GuC ADS
Re: [PULL] drm-intel-gt-next
Quoting Joonas Lahtinen (2021-08-06 13:06:17) > Hi Dave & Daniel, > > Sorry for the big PR in advance. Had the summer vacations and did not > notice until tool late how many patches were in already before leaving. > > As requested, there is a lot of refactoring to increase the use of TTM > allocator and prep for DRM scheduler. Note that at times the patches trade > simplicity for performance and revert optimizations not seen as critical. > So some performance regressions are expected. > > As an example is dropping of faster GPU relocation path for older platforms, > which should be mitigated by updating to the latest UMD versions to regain > the perf. > > This PR drops various bits of uAPI where userspace has dropped the ball after > reviews > have been completed on both sides (Thanks Jason for doing the > due-diligence!). [1] > Due to the complexity of tracing back who used what, I think we could do > better in the > future to avoid such situations to begin with. See below for my suggestion > [2]. > > In addition to the refactoring and uAPI cleanup there is preliminay code for > ADL-P/XeHP and DG2 platforms. Fixes for ADL-S and removal of CNL code. > A couple of fixes that have been Cc: stable already. Removing unnecessary > workarounds per stepping and adding missing for Gen12 iGFX. > > I915_MMAP_OFFSET_FIXED is also added to to align with the static/fixed caching > mode per BO instead of per-mapping mode (for dGFX only). There is GuC firmware > interface update and backend code major rework that unblock enabling GuC on > Gen11 > (not on by default). Then there is the addition of the GuCRC power management > feature which can be enabled for Gen12+ when submission is enabled. There is also addition of I915_USERPTR_PROBE with userspace changes in: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044 Regards, Joonas > > Then there is finally the drm-next backmerge and 3 topic branch merges. > > I think that is mostly all. I tried to summarize much in the tag description > so > it should hopefully not be horribly long... > > Regards, Joonas > > [1] Given that Jason is only human and there is no way to automate this > analysis, we > may have to bring something back as fixes if we find breakage (like with the > MMAP IOCTL). > > [2] As we first require to merge the kernel code, should we introduce some > further rules > that the userspace has to land their code before the final kernel version > release? If > that is not followed through, we would neuter the new uAPI with as small > patch as possible > in the final release candidate and then remove it in next release. Thoughts? > > *** > > drm-intel-gt-next-2021-08-06-1: > > UAPI Changes: > > - Add I915_MMAP_OFFSET_FIXED > > On devices with local memory `I915_MMAP_OFFSET_FIXED` is the only valid > type. On devices without local memory, this caching mode is invalid. > > As caching mode when specifying `I915_MMAP_OFFSET_FIXED`, WC or WB will > be used, depending on the object placement on creation. WB will be used > when the object can only exist in system memory, WC otherwise. > > Userspace: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11888 > > - Reinstate the mmap ioctl for (already released) integrated Gen12 platforms > > Rationale: Otherwise media driver breaks eg. for ADL-P. Long term goal is > still to sunset the IOCTL even for integrated and require using mmap_offset. > > - Reject caching/set_domain IOCTLs on discrete > > Expected to become immutable property of the BO > > - Disallow changing context parameters after first use on Gen12 and earlier > - Require setting context parameters at creation on platforms after Gen12 > > Rationale (for both): Allow less dynamic changes to the context to simplify > the implementation and avoid user shooting theirselves in the foot. > > - Drop I915_CONTEXT_PARAM_RINGSIZE > > Userspace PR for compute-driver has not been merged > > - Drop I915_CONTEXT_PARAM_NO_ZEROMAP > > Userspace PR for libdrm / Beignet was never landed > > - Drop CONTEXT_CLONE API > > Userspace PR for Mesa was never landed > > - Drop getparam support for I915_CONTEXT_PARAM_ENGINES > > Only existed for symmetry wrt. setparam, never used. > > - Disallow bonding of virtual engines > > Drop the prep work, no hardware has been released needing it. > > - (Implicit) Disable gpu relocations > > Media userspace was the last userspace to still use them. They > have converted so performance can be regained with an update. > > Core Changes: > > - Merge topic branch 'topic/i915-ttm-2021-06-11' (f
Re: [PATCH 04/21] drm/i915/gvt: move the gvt code into kvmgt.ko
Quoting Christoph Hellwig (2021-07-21 18:53:38) > Instead of having an option to build the gvt code into the main i915 > module, just move it into the kvmgt.ko module. This only requires > a new struct with three entries that the main i915 module needs to > request before enabling VGPU passthrough operations. > > This also conveniently streamlines the GVT initialization and avoids > the need for the global device pointer. > > Signed-off-by: Christoph Hellwig Hi, Thanks for putting the work into this. This conversion has been requested for a long time. For clarity, should we call the module i915_kvmgt? How far would we be from dynamically modprobing/rmmoding the kvmgt module in order to eliminate the enable_gvt parameter? > + > +/* > + * Exported here so that the exports only get created when GVT support is > + * actually enabled. > + */ > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_alloc, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_create_shmem, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_init, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_ggtt_pin_ww, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_pin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_set_to_cpu_domain, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_flush_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_set_pages, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_gtt_insert, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_prime_export, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_init, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_backoff, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_fini, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_ppgtt_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_add, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_wait, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_reserve_fence, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_unreserve_fence, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_vm_release, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_vma_move_to_active, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_context_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_context_unpin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_put, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(shmem_pin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(shmem_unpin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__px_dma, I915_GVT); This list is also a concern. At the least the double underscore functions should be eliminated from being exported. Zhi and Zhenyu, can we have some further patches to clean that up? Regards, Joonas
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
+ Dave as FYI
Quoting Daniel Vetter (2021-08-10 09:27:25)
> On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> > On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > > > Hi Matt,
> > > >
> > > > Always use the dim tooling when applying patches, it will do the right
> > > > thing with regards to adding the S-o-b.
> > >
> > > fd.o server rejects any pushes that haven't been done by dim, so how did
> > > this get through?
> >
> > I definitely used dim for all of these patches, but I'm not sure how I
> > lost my s-o-b on this one. Maybe when I edited the commit message after
> > 'dim extract-tags' I accidentally deleted an extra line when I removed
> > the extract-tags marker? It's the only patch where the line is missing,
> > so it's almost certainly human error on my part rather than something
> > dim did wrong.
>
> Yeah that's an expected failure model, and dim is supposed to catch that
> by rechecking for sobs when you push. See dim_push_branch ->
> checkpatch_commit_push_range in dim. So you can hand-edit stuff however
> you want, dim /should/ catch it when pushing. That it didn't is kinda
> confusing and I'd like to know why that slipped through.
>
> > > Matt, can you pls figure out and type up the patch to
> > > plug that hole?
> >
> > Are you referring to a patch for dim here? The i915 patch has already
> > landed, so we can't change its commit message now.
>
> Yeah dim, not drm-intel, that can't be fixed anymore because it's all
> baked in.
> -Daniel
>
> >
> >
> > Matt
> >
> > >
> > > Thanks, Daniel
> > >
> > > >
> > > > Regards, Joonas
> > > >
> > > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
> > > > > Hi all,
> > > > >
> > > > > Commit
> > > > >
> > > > > db47fe727e1f ("drm/i915/step:
> > > > > s/_revid_tbl/_revids")
> > > > >
> > > > > is missing a Signed-off-by from its committer.
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Stephen Rothwell
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > VTT-OSGC Platform Enablement
> > Intel Corporation
> > (916) 356-2795
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: missing signoff on drm-intel-gt-next pull
Quoting Dave Airlie (2021-08-11 06:48:39)
> dim: db47fe727e1f ("drm/i915/step:
> s/_revid_tbl/_revids"): committer Signed-off-by
> missing.
>
> I'm not sure how much pain it is to fix that up, but
> commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54
> Author: Anusha Srivatsa
> Commit: Matt Roper
>
> drm/i915/step: s/_revid_tbl/_revids
>
> Simplify the stepping info array name.
>
> Cc: Jani Nikula
> Signed-off-by: Anusha Srivatsa
> Reviewed-by: Jani Nikula
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.ro...@intel.com
>
> It's definitely missing an S-o-b by anyone who handled the patch.
>
> Let me know if it's insanely painful to fix that.
Added you to the earlier mail thread that discussed the incident.
There are now 277 patches on top of that patch, so means rebasing all of
those and changing the hashes and trying to fixup all the Fixes:.
So it's painful but not insanely so. Let me know if you want the tree
rebased.
Regards, Joonas
Re: refactor the i915 GVT support
Quoting Zhenyu Wang (2021-08-19 11:29:29)
> On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > Any updates on this? I'd really hate to miss this merge window.
> > >
> > > I'm still waiting for our validation team's report on this. I'm afraid
> > > it might be missing for next version as i915 merge window is mostly
> > > till rc5...and for any change outside of gvt, it still needs to be
> > > acked by i915 maintainers.
> >
> > Looks our validation team did have problem against recent i915 change.
> > If you like to try, we have a gvt-staging branch on
> > https://github.com/intel/gvt-linux which is generated against drm-tip
> > with gvt changes for testing, currently it's broken.
> >
> > One issue is with i915 export that intel_context_unpin has been
> > changed into static inline function. Another is that intel_gvt.c
> > should be part of i915 for gvt interface instead of depending on KVMGT
> > config.
>
> I'm working on below patch to resolve this. But I met a weird issue in
> case when building i915 as module and also kvmgt module, it caused
> busy wait on request_module("kvmgt") when boot, it doesn't happen if
> building i915 into kernel. I'm not sure what could be the reason?
>
> > But the problem I see is that after moving gvt device model (gvt/*.c
> > except kvmgt.c) into kvmgt module, we'll have issue with initial mmio
> > state which current gvt relies on, that is in design supposed to get
> > initial HW state before i915 driver has taken any operation.
As mentioned in some past discussions, I think it would be best rely on
golden MMIO located in /lib/firmware or elsewhere. This way we will better
isolate the guest system from host system updates/changes.
This should also hopefully allow enabling kvmgt module after i915 has
already loaded, as the initialization would not be conditional to
capture the MMIO.
Regards, Joonas
> > Before
> > we can ensure that, I think we may only remove MPT part first but
> > still keep gvt device model as part of i915 with config. I'll try to
> > split that out.
>
> Sorry I misread the code that as we always request kvmgt module when
> gvt init, so it should still apply original method that this isn't a
> problem. Our current validation result has shown no regression as well.
>
> ---8<---
> From 58ff84572f1a0f9d79ca1d7ec0cff5ecbe78d280 Mon Sep 17 00:00:00 2001
> From: Zhenyu Wang
> Date: Thu, 19 Aug 2021 16:36:33 +0800
> Subject: [PATCH] TESTONLY:drm/i915/gvt: potential fix for refactor against
> current tip
>
> ---
> drivers/gpu/drm/i915/Makefile | 4 +++-
> drivers/gpu/drm/i915/gt/intel_context.c | 5 +
> drivers/gpu/drm/i915/gt/intel_context.h | 3 ++-
> drivers/gpu/drm/i915/i915_trace.h | 1 +
> 4 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c4f953837f72..2248574428a1 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -296,7 +296,9 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
>
> # virtual gpu code
> i915-y += i915_vgpu.o
> -i915-$(CONFIG_DRM_I915_GVT_KVMGT) += intel_gvt.o
> +ifneq ($(CONFIG_DRM_I915_GVT_KVMGT),)
> +i915-y += intel_gvt.o
> +endif
>
> kvmgt-y += gvt/kvmgt.o \
> gvt/gvt.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 745e84c72c90..20e7522fed84 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -328,6 +328,11 @@ void __intel_context_do_unpin(struct intel_context *ce,
> int sub)
> intel_context_put(ce);
> }
>
> +void intel_context_unpin(struct intel_context *ce)
> +{
> + _intel_context_unpin(ce);
> +}
> +
> static void __intel_context_retire(struct i915_active *active)
> {
> struct intel_context *ce = container_of(active, typeof(*ce), active);
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index c41098950746..f942cbf6300a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -131,7 +131,7 @@ static inline void
> intel_context_sched_disable_unpin(struct intel_context *ce)
> __intel_context_do_unpin(ce, 2);
> }
>
> -static inline void intel_context_unpin(struct intel_context *ce)
> +static inline void _intel_context_unpin(struct intel_context *ce)
> {
> if (!ce->ops->sched_disable) {
> __intel_context_do_unpin(ce, 1);
> @@ -150,6 +150,7 @@ static inline void intel_context_unpin(struct
> intel_context *ce)
> }
> }
> }
> +void intel_context_unpin(struct intel_context *ce);
>
> void intel_context_enter_engine(struct intel_context *ce);
> void intel_context_exit_engine(struct intel_context *ce);
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index 806ad688274
Re: [Intel-gfx] [PATCH] drm/i915/selftest: Fix use of err in igt_reset_{fail, nop}_engine()
Quoting Nathan Chancellor (2021-08-23 22:08:37)
> Ping? This is a pretty clear bug and it is not fixed in -next or
> drm-intel at this point.
Pushed to drm-intel-gt-next with my R-b.
Regards, Joonas
> On Fri, Aug 13, 2021 at 10:11:58AM -0700, Nathan Chancellor wrote:
> > Clang warns:
> >
> > In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514:
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62: warning: variable
> > 'err' is uninitialized when used here [-Wuninitialized]
> > pr_err("[%s] Create context failed: %d!\n", engine->name, err);
> > ^~~
> > ...
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c:580:62: warning: variable
> > 'err' is uninitialized when used here [-Wuninitialized]
> > pr_err("[%s] Create context failed: %d!\n", engine->name, err);
> > ^~~
> > ...
> > 2 warnings generated.
> >
> > This appears to be a copy and paste issue. Use ce directly using the %pe
> > specifier to pretty print the error code so that err is not used
> > uninitialized in these functions.
> >
> > Fixes: 3a7b72665ea5 ("drm/i915/selftest: Bump selftest timeouts for
> > hangcheck")
> > Reported-by: Dan Carpenter
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > index 08f011f893b2..2c1ed32ca5ac 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > @@ -462,7 +462,7 @@ static int igt_reset_nop_engine(void *arg)
> >
> > ce = intel_context_create(engine);
> > if (IS_ERR(ce)) {
> > - pr_err("[%s] Create context failed: %d!\n",
> > engine->name, err);
> > + pr_err("[%s] Create context failed: %pe!\n",
> > engine->name, ce);
> > return PTR_ERR(ce);
> > }
> >
> > @@ -577,7 +577,7 @@ static int igt_reset_fail_engine(void *arg)
> >
> > ce = intel_context_create(engine);
> > if (IS_ERR(ce)) {
> > - pr_err("[%s] Create context failed: %d!\n",
> > engine->name, err);
> > + pr_err("[%s] Create context failed: %pe!\n",
> > engine->name, ce);
> > return PTR_ERR(ce);
> > }
> >
> >
> > base-commit: 927dfdd09d8c03ba100ed0c8c3915f8e1d1f5556
> > --
> > 2.33.0.rc2
[PULL] drm-intel-gt-next
Hi Dave & Daniel,
Bit late PR due to Easter break.
Prep work for local memory support as requested. Hard hang
fix for Sandybridge. Sanitize dma-buf size on import and
avoid GPU reset if heartbeat callback runs before timeout.
The rest is mostly small fixes and code/checkpatch cleanups.
Regards, Joonas
***
drm-intel-gt-next-2021-04-06:
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
The following changes since commit 06debd6e1b28029e6e77c41e59a162868f377897:
Merge tag 'drm-intel-next-2021-03-16' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-03-18 08:06:34
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2021-04-06
for you to fetch changes up to 2da21daa7d93817fa82f703c29adfcb5eed7f77d:
drm/i915/gt: Always flush the submission queue on checking for idle
(2021-03-24 19:31:59 +0100)
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
Abdiel Janulgue (1):
drm/i915: introduce mem->reserved
CQ Tang (1):
drm/i915: reserve stolen for LMEM region
Chris Wilson (22):
drm/i915: Strip out internal priorities
drm/i915: Remove I915_USER_PRIORITY_SHIFT
drm/i915/gt: Call stop_ring() from ring resume, again
drm/i915/gt: SPDX cleanup
drm/i915/gt: Add some missing blank lines after declaration
drm/i915/gt: Remove repeated words from comments
drm/i915/gt: Fixup misaligned function parameters
drm/i915/gt: Remove a bonus newline
drm/i915/gt: Wrap macro arg in ()
drm/i915/gt: Insert spaces into GEN3_L3LOG_SIZE/4
drm/i915/gt: Replace unnecessary ',' with '; '
drm/i915/gt: Add a space before '('
drm/i915/gt: Replace 'return' with a fall-through
drm/i915/selftests: Check for engine-reset errors in the middle of
workarounds
drm/i915/gt: Move the defer_request waiter active assertion
drm/i915: Protect against request freeing during cancellation on wedging
drm/i915/selftests: Use a single copy of the mocs table
drm/i915/gt: Retire unexpected starting state error dumping
drm/i915/selftests: Restore previous heartbeat interval
drm/i915/gt: Double check heartbeat timeout before resetting
drm/i915/selftest: Synchronise with the GPU timestamp
drm/i915/gt: Always flush the submission queue on checking for idle
Emil Renner Berthing (1):
drm/i915/gt: use new tasklet API for execution list
Imre Deak (1):
drm/i915/dg1: Reserve first 1MB of local memory
Matthew Auld (11):
drm/i915/gem: don't trust the dma_buf->size
drm/i915/gem: consolid
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here is the first PR for v5.12. There are quite a few patches accumulated after the holidays as usual: Most importantly there are fixes to the clear residual security mitigations to avoid GPU hangs caused by them. Further there is option to allow the user to decide to disable such mitigations similar to CPU side (i915.mitigations=auto,!residuals), if they are an expert user and wish to do so. Of course, usual caveats apply to disabling any security mitigations! For Tigerlake, a fix to reduce the likelihood of DMAR errors when IOMMU is enabled (MTBF bump from 10 secs to hours) and correction to detecting the device stepping. Addition of W/As for DG1 and TGL. Tuning the RPS algorithm further to limit to RPe on parking an engine. Plenty of refactoring, cleanups and optimizing code in preparation of upcoming series. The usual amount of selftest and documentation fixes. Then there are 3 other fixes for user reported/visible bugs; GPU hang due to wrong MOCS caching for index used by HW, false error message for case where GuC firmware doesn't load on first instance of the retry-loop and supplementing the GuC firmware table for Cometlake SKUs. Fixes for pre-emption on Gen8-era devices. Build and runtime fixes for 32-bit machines. Regards, Joonas PS. After you merge this, I will proceed to backmerge drm-next so that we can have a common topic branches for din and dign as requested by Jani and Rodrigo. *** drm-intel-gt-next-2021-01-14: UAPI Changes: - Deprecate I915_PMU_LAST and optimize state tracking (Tvrtko) Avoid relying on last item ABI marker in i915_drm.h, add a comment to mark as deprecated. Driver Changes: - Restore clear residuals security mitigations for Ivybridge and Baytrail (Chris) - Close #1858: Allow sysadmin to choose applied GPU security mitigations through i915.mitigations=... similar to CPU (Chris) - Fix for #2024: GPU hangs on HSW GT1 (Chris) - Fix for #2707: Driver hang when editing UVs in Blender (Chris, Ville) - Fix for #2797: False positive GuC loading error message (Chris) - Fix for #2859: Missing GuC firmware for older Cometlakes (Chris) - Lessen probability of GPU hang due to DMAR faults [reason 7, next page table ptr is invalid] on Tigerlake (Chris) - Fix REVID macros for TGL to fetch correct stepping (Aditya) - Limit frequency drop to RPe on parking (Chris, Edward) - Limit W/A 1406941453 to TGL, RKL and DG1 (Swathi) - Make W/A 22010271021 permanent on DG1 (Lucas) - Implement W/A 16011163337 to prevent a HS/DS hang on DG1 (Swathi) - Only disable preemption on gen8 render engines (Chris) - Disable arbitration around Braswell's PDP updates (Chris) - Disable arbitration on no-preempt requests (Chris) - Check for arbitration after writing start seqno before busywaiting (Chris) - Retain default context state across shrinking (Venkata, CQ) - Fix mismatch between misplaced vma check and vma insert for 32-bit addressing userspaces (Chris, CQ) - Propagate error for vmap() failure instead kernel NULL deref (Chris) - Propagate error from cancelled submit due to context closure immediately (Chris) - Fix RCU race on HWSP tracking per request (Chris) - Clear CMD parser shadow and GPU reloc batches (Matt A) - Populate logical context during first pin (Maarten) - Optimistically prune dma-resv from the shrinker (Chris) - Fix for virtual engine ownership race (Chris) - Remove timeslice suppression to restore fairness for virtual engines (Chris) - Rearrange IVB/HSW workarounds properly between GT and engine (Chris) - Taint the reset mutex with the shrinker (Chris) - Replace direct submit with direct call to tasklet (Chris) - Multiple corrections to virtual engine dequeue and breadcrumbs code (Chris) - Avoid wakeref from potentially hard IRQ context in PMU (Tvrtko) - Use raw clock for RC6 time estimation in PMU (Tvrtko) - Differentiate OOM failures from invalid map types (Chris) - Fix Gen9 to have 64 MOCS entries similar to Gen11 (Chris) - Ignore repeated attempts to suspend request flow across reset (Chris) - Remove livelock from "do_idle_maps" VT-d W/A (Chris) - Cancel the preemption timeout early in case engine reset fails (Chris) - Code flow optimization in the scheduling code (Chris) - Clear the execlists timers upon reset (Chris) - Drain the breadcrumbs just once (Chris, Matt A) - Track the overall GT awake/busy time (Chris) - Tweak submission tasklet flushing to avoid starvation (Chris) - Track timelines created using the HWSP to restore on resume (Chris) - Use cmpxchg64 for 32b compatilibity for active tracking (Chris) - Prefer recycling an idle GGTT fence to avoid GPU wait (Chris) - Restructure GT code organization for clearer split between GuC and execlists (Chris, Daniele, John, Matt A) - Remove GuC code that will remain unused by new interfaces (Matt B) - Restructure the CS timestamp clocks code to local to GT (Chris) - Fix error return paths in perf code (Zhang) - Replace idr_init() by idr_init_base() in perf (Deepak) - Fix shmem_pin_map error p
[PULL] drm-intel-gt-next
uest_submit() (Chris) - Mark up protected uses of 'i915_request_completed' (Chris) - Remove extraneous inline modifiers (Chris) - Add function to define defaults for GuC/HuC enable (John) - Improve code locality by moving closer to single user (Matt A, Chris) - Compiler warning fixes (Matt A, Chris) - Selftest / CI improvements (Chris) CQ Tang (1): drm/i915/error: Fix object page offset within a region Chris Wilson (34): drm/i915/gt: Reapply ppgtt enabling after engine resets drm/i915/gt: Prune 'inline' from execlists drm/i915/gt: Prune inlines drm/i915: Mark up protected uses of 'i915_request_completed' drm/i915: Drop i915_request.lock serialisation around await_start drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source drm/i915/gem: Reduce ctx->engines_mutex for get_engines() drm/i915: Reduce test_and_set_bit to set_bit in i915_request_submit() drm/i915/gt: Drop atomic for engine->fw_active tracking drm/i915/gt: Extract busy-stats for ring-scheduler drm/i915/gt: Convert stats.active to plain unsigned int drm/i915/gt: Clear CACHE_MODE prior to clearing residuals drm/i915/gt: Add arbitration check before semaphore wait drm/i915: Add DEBUG_GEM to the recommended CI config drm/i915: Make GEM errors non-fatal by default drm/i915/gt: One more flush for Baytrail clear residuals drm/i915/selftests: Prepare the selftests for engine resets with ring submission drm/i915/gt: Lift stop_ring() to reset_prepare drm/i915/gt: Disable the ring before resetting HEAD/TAIL drm/i915/gt: Pull ring submission resume under its caller forcewake drm/i915: Mark per-engine-reset as supported on gen7 drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects drm/i915/gem: Make i915_gem_object_flush_write_domain() static drm/i915/display: Apply interactive priority to explicit flip fences drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs drm/i915/gem: Almagamate clflushes on suspend drm/i915/gem: Almagamate clflushes on freeze drm/i915/gem: Move stolen node into GEM object union drm/i915/gem: Use shrinkable status for unknown swizzle quirks drm/i915/gem: Protect used framebuffers from casual eviction drm/i915/gem: Drop lru bumping on display unpinning drm/i915/gt: Do not suspend bonded requests if one hangs drm/i915/gt: Skip over completed active execlists, again drm/i915/gvt: Add missing forward decl of intel_vgpu for HDRTEST John Harrison (1): drm/i915/uc: Add function to define defaults for GuC/HuC enable Joonas Lahtinen (2): Merge drm/drm-next into drm-intel-gt-next Merge tag 'gvt-gt-next-2021-01-18' of https://github.com/intel/gvt-linux into drm-intel-gt-next Kui Wen (1): drm/i915: Fix the sgt.pfn sanity check Matthew Auld (7): drm/i915/gem: split gem_create into own file drm/i915/gem: sanity check object size in gem_create drm/i915/region: convert object_create into object_init drm/i915: add back static declaration drm/i915: move i915_map_type into i915_gem_object_types.h drm/i915/pool: constrain pool objects by mapping type drm/i915/region: don't leak the object on error Yan Zhao (11): drm/i915/gvt: parse init context to update cmd accessible reg whitelist drm/i915/gvt: scan VM ctx pages drm/i915/gvt: filter cmds "srm" and "lrm" in cmd_handler drm/i915/gvt: filter cmds "lrr-src" and "lrr-dst" in cmd_handler drm/i915/gvt: filter cmd "pipe-ctrl" in cmd_handler drm/i915/gvt: export find_mmio_info drm/i915/gvt: make width of mmio_attribute bigger drm/i915/gvt: introduce a new flag F_CMD_WRITE_PATCH drm/i915/gvt: statically set F_CMD_WRITE_PATCH flag drm/i915/gvt: update F_CMD_WRITE_PATCH flag when parsing init ctx drm/i915/gvt: unify lri cmd handler and mmio handlers drivers/gpu/drm/i915/Kconfig.debug | 22 +- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_display.c | 23 +- drivers/gpu/drm/i915/display/intel_fbdev.c | 4 +- drivers/gpu/drm/i915/display/intel_frontbuffer.c | 4 +- drivers/gpu/drm/i915/display/intel_overlay.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_context.c| 65 ++-- drivers/gpu/drm/i915/gem/i915_gem_create.c | 113 +++ drivers/gpu/drm/i915/gem/i915_gem_domain.c | 104 +++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 15 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 8 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 47 --- drivers/gpu/drm/i915/ge
Re: [RFC PATCH 7/9] drmcg: Add initial support for tracking gpu time usage
Quoting Brian Welty (2021-01-26 23:46:24)
> Single control below is added to DRM cgroup controller in order to track
> user execution time for GPU devices. It is up to device drivers to
> charge execution time to the cgroup via drm_cgroup_try_charge().
>
> sched.runtime
> Read-only value, displays current user execution time for each DRM
> device. The expectation is that this is incremented by DRM device
> driver's scheduler upon user context completion or context switch.
> Units of time are in microseconds for consistency with cpu.stats.
Were not we also planning for a percentage style budgeting?
Capping the maximum runtime is definitely useful, but in order to
configure a system for peaceful co-existence of two or more workloads we
must also impose a limit on how big portion of the instantaneous
capacity can be used.
Regards, Joonas
> Signed-off-by: Brian Welty
> ---
> Documentation/admin-guide/cgroup-v2.rst | 9 +
> include/drm/drm_cgroup.h| 2 ++
> include/linux/cgroup_drm.h | 2 ++
> kernel/cgroup/drm.c | 20
> 4 files changed, 33 insertions(+)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst
> b/Documentation/admin-guide/cgroup-v2.rst
> index ccc25f03a898..f1d0f333a49e 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -2205,6 +2205,15 @@ thresholds are hit, this would then allow the DRM
> device driver to invoke
> some equivalent to OOM-killer or forced memory eviction for the device
> backed memory in order to attempt to free additional space.
>
> +The below set of control files are for time accounting of DRM devices. Units
> +of time are in microseconds.
> +
> + sched.runtime
> +Read-only value, displays current user execution time for each DRM
> +device. The expectation is that this is incremented by DRM device
> +driver's scheduler upon user context completion or context switch.
> +
> +
> Misc
>
>
> diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
> index 9ba0e372..315dab8a93b8 100644
> --- a/include/drm/drm_cgroup.h
> +++ b/include/drm/drm_cgroup.h
> @@ -22,6 +22,7 @@ enum drmcg_res_type {
> DRMCG_TYPE_MEM_CURRENT,
> DRMCG_TYPE_MEM_MAX,
> DRMCG_TYPE_MEM_TOTAL,
> + DRMCG_TYPE_SCHED_RUNTIME,
> __DRMCG_TYPE_LAST,
> };
>
> @@ -79,5 +80,6 @@ void drm_cgroup_uncharge(struct drmcg *drmcg,struct
> drm_device *dev,
> enum drmcg_res_type type, u64 usage)
> {
> }
> +
> #endif /* CONFIG_CGROUP_DRM */
> #endif /* __DRM_CGROUP_H__ */
> diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
> index 3570636473cf..0fafa663321e 100644
> --- a/include/linux/cgroup_drm.h
> +++ b/include/linux/cgroup_drm.h
> @@ -19,6 +19,8 @@
> */
> struct drmcg_device_resource {
> struct page_counter memory;
> + seqlock_t sched_lock;
> + u64 exec_runtime;
> };
>
> /**
> diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
> index 08e75eb67593..64e9d0dbe8c8 100644
> --- a/kernel/cgroup/drm.c
> +++ b/kernel/cgroup/drm.c
> @@ -81,6 +81,7 @@ static inline int init_drmcg_single(struct drmcg *drmcg,
> struct drm_device *dev)
> /* set defaults here */
> page_counter_init(&ddr->memory,
> parent_ddr ? &parent_ddr->memory : NULL);
> + seqlock_init(&ddr->sched_lock);
> drmcg->dev_resources[minor] = ddr;
>
> return 0;
> @@ -287,6 +288,10 @@ static int drmcg_seq_show_fn(int id, void *ptr, void
> *data)
> seq_printf(sf, "%d:%d %llu\n", DRM_MAJOR, minor->index,
>minor->dev->drmcg_props.memory_total);
> break;
> + case DRMCG_TYPE_SCHED_RUNTIME:
> + seq_printf(sf, "%d:%d %llu\n", DRM_MAJOR, minor->index,
> + ktime_to_us(ddr->exec_runtime));
> + break;
> default:
> seq_printf(sf, "%d:%d\n", DRM_MAJOR, minor->index);
> break;
> @@ -384,6 +389,12 @@ struct cftype files[] = {
> .private = DRMCG_TYPE_MEM_TOTAL,
> .flags = CFTYPE_ONLY_ON_ROOT,
> },
> + {
> + .name = "sched.runtime",
> + .seq_show = drmcg_seq_show,
> + .private = DRMCG_TYPE_SCHED_RUNTIME,
> + .flags = CFTYPE_NOT_ON_ROOT,
> + },
> { } /* terminate */
> };
>
> @@ -440,6 +451,10 @@ EXPORT_SYMBOL(drmcg_device_early_init);
> * choose to enact some form of memory reclaim, but the exact behavior is
> left
> * to the DRM device driver to define.
> *
> + * For @res type of DRMCG_TYPE_SCHED_RUNTIME:
> + * For GPU time accounting, add @usage amount of GPU time to @drmcg for
> + * the given device.
> + *
> * Returns 0 on success. Otherwise, an error code is returned.
> */
> int drm_cgroup_try_ch
Re: [PATCH 07/15] drm/i915: Remove references to struct drm_device.pdev
Quoting Thomas Zimmermann (2020-11-24 13:38:16)
> Using struct drm_device.pdev is deprecated. Convert i915 to struct
> drm_device.dev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
Any chance of sharing used a cocci script(s)? think this will
hit many in-flight series, so life would made easier :)
Or is this done manually? I notice a few places hoist the pdev
variable and others repeat the call. Regardless, using the cocci
script as baseline would make review bit more comforting.
The gvt changes would go in through the gvt tree, and we also
probably need to split between drm-intel-next/drm-intel-gt-next,
too.
Jani or Rodrigo, any thoughts?
Regards, Joonas
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c| 14 ++---
> drivers/gpu/drm/i915/display/intel_csr.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c| 2 +-
> .../gpu/drm/i915/display/intel_lpe_audio.c| 5 +++--
> drivers/gpu/drm/i915/display/intel_opregion.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
> drivers/gpu/drm/i915/display/intel_panel.c| 4 ++--
> drivers/gpu/drm/i915/display/intel_quirks.c | 2 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vga.c | 8
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 10 +-
> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_reset.c | 6 +++---
> drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++--
> drivers/gpu/drm/i915/gvt/firmware.c | 10 +-
> drivers/gpu/drm/i915/gvt/gtt.c| 12 +--
> drivers/gpu/drm/i915/gvt/gvt.c| 6 +++---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 20 +--
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
> drivers/gpu/drm/i915/i915_getparam.c | 5 +++--
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> drivers/gpu/drm/i915/i915_irq.c | 6 +++---
> drivers/gpu/drm/i915/i915_pmu.c | 5 +++--
> drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
> drivers/gpu/drm/i915/i915_switcheroo.c| 4 ++--
> drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> drivers/gpu/drm/i915/intel_region_lmem.c | 8
> drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
> drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
> .../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +-
> 42 files changed, 99 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 4cc949b228f2..8879676372a3 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2088,7 +2088,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
> size)
>
> static struct vbt_header *oprom_get_vbt(struct drm_i915_private *dev_priv)
> {
> - struct pci_dev *pdev = dev_priv->drm.pdev;
> + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> void __iomem *p = NULL, *oprom;
> struct vbt_header *vbt;
> u16 vbt_size;
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index c449d28d0560..a6e13208dc50 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -96,7 +96,7 @@ static void fixed_450mhz_get_cdclk(struct drm_i915_private
> *dev_priv,
> static void i85x_get_cdclk(struct drm_i915_private *dev_priv,
>struct intel_cdclk_config *cdclk_config)
> {
> - struct pci_dev *pdev = dev_priv->drm.pdev;
> + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> u16 hpllcc = 0;
>
> /*
> @@ -138,7 +138,7 @@ static void i85x_get_cdclk(struct drm_i915_private
> *dev_priv,
> static void i9
Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count
+ Tvrtko and Chris for comments
Code seems to be added in:
commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5
Author: Tvrtko Ursulin
Date: Tue Nov 21 18:18:50 2017 +
drm/i915/pmu: Add interrupt count metric
I think later in the thread there was a suggestion to replace this with
simple counter increment in IRQ handler.
Regards, Joonas
Quoting Thomas Gleixner (2020-12-06 18:38:44)
> On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
>
> > Now that kstat_irqs is exported, get rid of count_interrupts in
> > i915_pmu.c
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer
> > *hrtimer)
> > return HRTIMER_RESTART;
> > }
> >
> > -static u64 count_interrupts(struct drm_i915_private *i915)
> > -{
> > - /* open-coded kstat_irqs() */
> > - struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
> > - u64 sum = 0;
> > - int cpu;
> > -
> > - if (!desc || !desc->kstat_irqs)
> > - return 0;
> > -
> > - for_each_possible_cpu(cpu)
> > - sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
> > -
> > - return sum;
> > -}
>
> May I ask why this has been merged in the first place?
>
> Nothing in a driver has ever to fiddle with the internals of an irq
> descriptor. We have functions for properly accessing them. Just because
> C allows to fiddle with everything is not a justification. If the
> required function is not exported then adding the export with a proper
> explanation is not asked too much.
>
> Also this lacks protection or at least a comment why this can be called
> safely and is not subject to a concurrent removal of the irq descriptor.
> The same problem exists when calling kstat_irqs(). It's even documented
> at the top of the function.
>
> Thanks,
>
> tglx
>
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Improve debug Kconfig texts a bit
Quoting Daniel Vetter (2021-07-02 23:17:08) > We're not consistently recommending these for developers only. > > I stumbled over this due to DRM_I915_LOW_LEVEL_TRACEPOINTS, which was > added in > > commit 354d036fcf70654cff2e2cbdda54a835d219b9d2 > Author: Tvrtko Ursulin > Date: Tue Feb 21 11:01:42 2017 + > > drm/i915/tracepoints: Add request submit and execute tracepoints > > to "alleviate the performance impact concerns." > > Which is nonsense. I think that was the original reason why the patch was developed and it got merged primarily for the latter reason. Unfortunately the patch commit messages don't always get rewritten. > Tvrtko and Joonas pointed out on irc that the real (but undocumented > reason) was stable abi concerns for tracepoints, see > > https://lwn.net/Articles/705270/ > > and the specific change that was blocked around tracepoints: > > https://lwn.net/Articles/442113/ > > Anyway to make it a notch clearer why we have this Kconfig option > consistly add the "Recommended for driver developers only." to it and > all the other debug options we have. > > Cc: Tvrtko Ursulin > Cc: Joonas Lahtinen > Cc: Matthew Brost > Signed-off-by: Daniel Vetter Reviewed-by: Joonas Lahtinen Regards, Joonas > --- > drivers/gpu/drm/i915/Kconfig.debug | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 2ca88072d30f..f27c0b5873f7 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -215,6 +215,8 @@ config DRM_I915_LOW_LEVEL_TRACEPOINTS > This provides the ability to precisely monitor engine utilisation > and also analyze the request dependency resolving timeline. > > + Recommended for driver developers only. > + > If in doubt, say "N". > > config DRM_I915_DEBUG_VBLANK_EVADE > @@ -228,6 +230,8 @@ config DRM_I915_DEBUG_VBLANK_EVADE > is exceeded, even if there isn't an actual risk of missing > the vblank. > > + Recommended for driver developers only. > + > If in doubt, say "N". > > config DRM_I915_DEBUG_RUNTIME_PM > @@ -240,4 +244,6 @@ config DRM_I915_DEBUG_RUNTIME_PM > runtime PM functionality. This may introduce overhead during > driver loading, suspend and resume operations. > > + Recommended for driver developers only. > + > If in doubt, say "N" > -- > 2.32.0.rc2 >
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes the drm-intel-gt-next PR for 5.11. Most importantly there is a healthy chunk of Tigerlake related fixes and a fix for user reported issue #2381 where graphics output would stop at "switching to inteldrmfb from simple". Fixes to DMA mapped sg usage in i915 to unblock intel iommu rework. Fixes to previously introduced WW mutex rework. We're enabling eLLC for displayable buffers on SKL+. Plenty of fixes to driver unbind/bind cycle. The GuC firmware version is being updated (that just loads HuC for now). The usual amount of fixes for CI found corner cases. Expect a few conflicts with drm-intel-next (resolved in rerere) as the platform enabling ones go there. I'll backmerge drm-next once you've accepted this to pull all the changes to gt-next. The -next-fixes and -fixes would come from Jani after this is accepted, too. Regards, Joonas *** drm-intel-gt-next-2020-11-12-1: Cross-subsystem Changes: - DMA mapped scatterlist fixes in i915 to unblock merging of https://lkml.org/lkml/2020/9/27/70 (Tvrtko, Tom) Driver Changes: - Fix for user reported issue #2381 (Graphical output stops with "switching to inteldrmfb from simple"): Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init (Ville, Chris) - Fix for Tigerlake (and earlier) to avoid spurious empty CSB events leading to hang (Chris, Bruce) - Delay execlist processing for Tigerlake to avoid hang (Chris) - Fix for Tigerlake RCS engine health check through heartbeat (Chris) - Fix for Tigerlake reserved MOCS entries (Ayaz, Chris) - Fix Media power gate sequence on Tigerlake (Rodrigo) - Enable eLLC caching of display buffers for SKL+ (Ville) - Support parsing of oversize batches on Gen9 (Matt, Chris) - Exclude low pages (128KiB) of stolen from use to avoid thrashing during reset (Chris) - Flush engines before Tigerlake breadcrumbs (Chris) - Use the local HWSP offset during submission (Chris) - Flush coherency domains on first set-domain-ioctl (Chris, Zbigniew) - Use the active reference on the vma while capturing to avoid use-after-free (Chris) - Fix MOCS PTE setting for gen9+ (Ville) - Avoid NULL dereference on IPS driver callback while unbinding i915 (Chris) - Avoid NULL dereference from PT/PD stash allocation error (Matt) - Hold request reference for canceling an active context (Chris) - Avoid infinite loop on x86-32 when mapping a lot of objects (Chris) - Disallow WC mappings when processor doesn't support them (Chris) - Return correct error in i915_gem_object_copy_blt() error path (Dan) - Return correct error in intel_context_create_request() error path (Maarten) - Tune down GuC communication enabled/disabled messages to debug (Jani) - Fix rebased commit "Remove i915_request.lock requirement for execution callbacks" (Chris) - Cancel outstanding work after disabling heartbeats on an engine (Chris) - Signal cancelled requests (Chris) - Retire cancelled requests on unload (Chris) - Scrub HW state on driver remove (Chris) - Undo forced context restores after trivial preemptions (Chris) - Handle PCI unbind in PMU code (Tvrtko) - Fix CPU hotplug with multiple GPUs in PMU code (Trtkko) - Correctly set SFC capability for video engines (Venkata) - Update GuC code to use firmware v49.0.1 (John, Matthew B., Daniele, Oscar, Michel, Rodrigo, Michal) - Improve GuC warnings on loading failure (John) - Avoid ownership race in buffer pool by clearing age (Chris) - Use MMIO to read CSB in case of failure (Chris, Mika) - Show engine properties in engine state dump to indicate changes (Chris, Joonas) - Break up error capture compression loops with cond_resched() (Chris) - Reduce GPU error capture mutex hold time to avoid khungtaskd (Chris) - Serialise debugfs i915_gem_objects with ctx->mutex (Chris) - Always test execution status on closing the context and close if not persistent (Chris) - Avoid mixing integer types during batch copies (Chris, Jared) - Skip over MI_NOOP when parsing to avoid overhead (Chris) - Hold onto an explicit ref to i915_vma_work.pinned (Chris) - Perform all asynchronous waits prior to marking payload start (Chris) - Pull phys pread/pwrite implementations to the backend (Matt) - Improve record of hung engines in error state (Tvrtko) - Allow backends to override pread implementation (Matt) - Reinforce LRC poisoning checks to confirm context survives execution (Chris) - Fix memory region max size calculation (Matt) - Fix order when adding blocks to memory region (Matt) - Eliminate unused intel_virtual_engine_get_sibling func (Chris) - Cleanup kasan warning for on-stack (unsigned long) casting (Chris) - Onion unwind for scratch page allocation failure (Chris) - Poison stolen pages before use (Chris) - Selftest improvements (Chris) The following changes since commit e0ee152fce25dc9269c7ea5280c98aa4b3682759: drm/i915: Unlock the shared hwsp_gtt object after pinning (2020-09-07 15:08:11 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-inte
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Here's a batch of -next-fixes from drm-intel-next/drm-intel-gt-next. On GT side just a fix to relax GGTT alignment down 64K from 2M. Addition of missing "name" attribute for GVT mdev device. On display side async flip fixes and a static checker fix. CI results had some display errors on TGL, the display has been rebooted to fix those so should cause no worries. Regards, Joonas *** drm-intel-next-fixes-2022-03-10: - Reduce overzealous alignment constraints for GGTT - Add missing mdev attribute "name" for GVT - Async flip fixes (Ville) - Static checker fix (Ville) The following changes since commit 6de7e4f02640fba2ffa6ac04e2be13785d614175: Merge tag 'drm-msm-next-2022-03-01' of https://gitlab.freedesktop.org/drm/msm into drm-next (2022-03-04 14:39:00 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-03-10 for you to fetch changes up to 5e7f44b5c2c035fe2e5458193c2bbee56db6a090: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (2022-03-09 08:34:55 +0200) - Reduce overzealous alignment constraints for GGTT - Add missing mdev attribute "name" for GVT - Async flip fixes (Ville) - Static checker fix (Ville) ---- Joonas Lahtinen (1): Merge tag 'gvt-next-2022-03-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Matthew Auld (1): drm/i915/gtt: reduce overzealous alignment constraints for GGTT Ville Syrjälä (4): drm/i915: Avoid negative shift due to bigjoiner_pipes==0 drm/i915: Don't skip ddb allocation if data_rate==0 drm/i915: Check async flip capability early on drm/i915: Fix the async flip wm0/ddb optimization Zhi Wang (1): drm/i915/gvt: add the missing mdev attribute "name" drivers/gpu/drm/i915/display/intel_atomic.c| 1 + drivers/gpu/drm/i915/display/intel_atomic_plane.c | 7 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 122 + drivers/gpu/drm/i915/display/intel_display_types.h | 6 +- drivers/gpu/drm/i915/gt/intel_gtt.c| 3 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 15 +++ drivers/gpu/drm/i915/intel_pm.c| 30 ++--- 8 files changed, 136 insertions(+), 52 deletions(-)
Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Quoting Tvrtko Ursulin (2022-03-14 17:35:17)
>
> On 12/03/2022 04:16, Matt Atwood wrote:
> > On Thu, Mar 10, 2022 at 12:26:12PM +, Tvrtko Ursulin wrote:
> >>
> >> On 10/03/2022 05:18, Matt Atwood wrote:
> >>> Newer platforms have DSS that aren't necessarily available for both
> >>> geometry and compute, two queries will need to exist. This introduces
> >>> the first, when passing a valid engine class and engine instance in the
> >>> flags returns a topology describing geometry.
> >>>
> >>> v2: fix white space errors
> >>>
> >>> Cc: Ashutosh Dixit
> >>> Cc: Matt Roper
> >>> Cc: Joonas Lahtinen
> >>> UMD (mesa):
> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
> >>> Signed-off-by: Matt Atwood
> >>> @@ -2714,6 +2715,9 @@ struct drm_i915_query_item {
> >>> * - DRM_I915_QUERY_PERF_CONFIG_LIST
> >>> * - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
> >>> * - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
> >>> +*
> >>> +* When query_id == DRM_I915_QUERY_GEOMETRY_SUBSLICES must have bits
> >>> 0:7 set
> >>> +* as a valid engine class, and bits 8:15 must have a valid engine
> >>> instance.
> >>
> >> Alternatively, all other uapi uses struct i915_engine_class_instance to
> >> address engines which uses u16:u16.
> >>
> >> How ugly it is to stuff a struct into u32 flags is the question... But you
> >> could at least use u16:u16 for consistency. Unless you wanted to leave some
> >> bits free for the future?
> > Originally when I wrote this I was wanting to leave space in case it was
> > ever needed. I'm not particularly for or against keeping the space now.
>
> Yes, shrug... Neither I can't guess if we are ever likely to hit a
> problem by having fewer bits for class:instance here compared to other
> uapi, or if stuffing struct i915_engine_class_instance into flags would
> just be too ugly. I mean there is option to define a new struct and not
> use flags at all but that's probably to complicated for what it is.
>
> Anyone else with an opinion? Consistency or should be fine even like it is?
Stuffing a full i915_engine_class_instance was definitely intended when
putting it into the flags was suggested.
If that is hit with a complication, the next proposed alternative was a
new struct. That's why the query interface was made easily extensible,
after all...
Regards, Joonas
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Fix for vm_access() out-of-bounds access and PSR not staying disabled during fastset once determined not reliable. Then a naming fix to avoid conflicts for potential future fixes. Regards, Joonas *** drm-intel-next-fixes-2022-03-17: - Do not re-enable PSR after it was marked as not reliable (Jose) - Add missing boundary check in vm_access to avoid out-of-bounds access (Mastan) - Naming fix for HPD short pulse handling for eDP (Jose) The following changes since commit 5e7f44b5c2c035fe2e5458193c2bbee56db6a090: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (2022-03-09 08:34:55 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-03-17 for you to fetch changes up to 278da06c03655c2bb9bc36ebdf45b90a079b3bfd: drm/i915/display: Do not re-enable PSR after it was marked as not reliable (2022-03-16 08:17:40 +0200) - Do not re-enable PSR after it was marked as not reliable (Jose) - Add missing boundary check in vm_access to avoid out-of-bounds access (Mastan) - Naming fix for HPD short pulse handling for eDP (Jose) José Roberto de Souza (2): drm/i915/display: Fix HPD short pulse handling for eDP drm/i915/display: Do not re-enable PSR after it was marked as not reliable Mastan Katragadda (1): drm/i915/gem: add missing boundary check in vm_access drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/display/intel_pps.c | 6 +++--- drivers/gpu/drm/i915/display/intel_pps.h | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 4 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 5 files changed, 10 insertions(+), 6 deletions(-)
Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface
Quoting Andi Shyti (2022-02-17 17:53:58) > Hi Tvrtko, > > > > Now tiles have their own sysfs interfaces under the gt/ > > > directory. Because RC6 is a property that can be configured on a > > > tile basis, then each tile should have its own interface > > > > > > The new sysfs structure will have a similar layout for the 4 tile > > > case: > > > > > > /sys/.../card0 > > > \u251c\u2500\u2500 gt > > > \u2502 \u251c\u2500\u2500 gt0 > > > \u2502 \u2502 \u251c\u2500\u2500 id > > > \u2502 \u2502 \u251c\u2500\u2500 rc6_enable > > > \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms > > > . . . > > > . . . > > > . . > > > \u2502 \u2514\u2500\u2500 gtN > > > \u2502 \u251c\u2500\u2500 id > > > \u2502 \u251c\u2500\u2500 rc6_enable > > > \u2502 \u251c\u2500\u2500 rc6_residency_ms > > > \u2502 . > > > \u2502 . > > > \u2502 > > > \u2514\u2500\u2500 power/-+ > > >\u251c\u2500\u2500 rc6_enable|Original > > > interface > > >\u251c\u2500\u2500 rc6_residency_ms +-> kept as existing > > > ABI; > > >. |it multiplexes over > > >. |the GTs > > > -+ > > > > > > The existing interfaces have been kept in their original location > > > to preserve the existing ABI. They act on all the GTs: when > > > reading they provide the average value from all the GTs. > > > > Average feels very odd to me. I'd ask if we can get away providing an errno > > instead? Or tile zero data? Tile zero data is always wrong, in my opinion. If we have round-robin scaling workloads like some media cases, part of the system load might just disappear when it goes to tile 1. > Real multiplexing would be providing something when reading and > when writing. The idea of average came while revieweing with > Chris the write multiplexing. Indeed it makes sense to provide > some common value, but I don't know how useful it can be to the > user (still if the user needs any average). I think all read/write controls like min/max/boost_freq should return an error from the global interface if all the tiles don't return same value. Write will always overwrite per-tile values. When we have frequency readbacks without control, returning MAX() across tiles would be the logical thing. The fact that parts of the hardware can be clocked lower when one part is fully utilized is the "new feature". After that we're only really left with the rc6_residency_ms. And that is the tough one. I'm inclined that MIN() across tiles would be the right answer. If you are fully utilizing a single tile, you should be able to see it. This all would be what feels natural for an user who has their setup tuned for single-tile device. And would allow simple round-robing balancing across the tiles in somewhat coherent manner. Regards, Joonas > > Joonas, Chris... any idea? > > > Case in point, and please correct me if I am wrong, legacy rc6_enable > > returns tile zero, while residency returns average. > > As the interface is done now, the rc6_enable is just returning > whether the gpu (i.e. i915, not gt) supports RC6 or not. I think > there is a patch later. > > > Even the deprecated message gets logged with every access right? > > > > Btw is the deperecated message limited to multi-tile platforms (can't see > > that it is) and what is the plan for that? > > yes, at this point the message would need to be removed and I > forgot to do it. > > > It's a tough problem, no easy answers even after all this time. :D > > yeah! quite hard to get it conceptually right! > > Thanks Tvrtko, > Andi
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here is the last feature PR for v5.18. For new platforms we have got more DG2 enabling: small BAR foundations, 64K page support and accelerated migration. For XeHP SDV we've got flat CCS detection and compute command streamer being added. Disabling i915 build on PREEMPT_RT for now due to deadlocks and warnings. Fixes to GuC data structure accesses on ARM platforms. A couple of other GuC init and SLPC fixes. Then the usual bits of cleanup and smaller fixes. Regards, Joonas *** drm-intel-gt-next-2022-03-03: Cross-subsystem Changes: - drm-next backmerge for buddy allocator changes Driver Changes: - Skip i915_perf init for DG2 as it is not yet enabled (Ram) - Add missing workarounds for DG2 (Clint) - Add 64K page/align support for platforms like DG2 that require it (Matt A, Ram, Bob) - Add accelerated migration support for DG2 (Matt A) - Add flat CCS support for XeHP SDV (Abdiel, Ram) - Add Compute Command Streamer (CCS) engine support for XeHP SDV (Michel, Daniele, Aravind, Matt R) - Don't support parallel submission on compute / render (Matt B, Matt R) - Disable i915 build on PREEMPT_RT until RT behaviour fixed (Sebastian) - Remove RPS interrupt support for TGL+ (Jose) - Fix S/R with PM_EARLY for non-GTT mappable objects on DG2 (Matt, Lucas) - Skip stolen memory init if it is fully reserved (Jose) - Use iosys_map for GuC data structures that may be in LMEM BAR or SMEM (Lucas) - Do not complain about stale GuC reset notifications for banned contexts (John) - Move context descriptor fields to intel_lrc.h (Matt R) - Start adding support for small BAR (Matt A) - Clarify vma lifetime (Thomas) - Simplify subplatform detection on TGL (Jose) - Correct the param count for unset GuC SLPC param (Vinay, Umesh) - Read RP_STATE_CAP correctly on Gen12 with GuC SLPC (Vinay) - Initialize GuC submission locks and queues early (Daniele) - Fix GuC flag query helper function to not modify state (John) - Drop fake lmem support now we have real hardware available (Lucas) - Move misplaced W/A to their correct locations (Srinivasan) - Use get_reset_domain() helper (Tejas) - Move context descriptor fields to intel_lrc.h (Matt R) - Selftest improvements (Matt A) The following changes since commit 54f43c17d681f6d9523fcfaeefc9df77993802e1: Merge tag 'drm-misc-next-2022-02-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2022-02-25 05:50:18 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-03-03 for you to fetch changes up to b2006061ae28fe7e84af6c9757ee89c4e505e92b: drm/i915/xehpsdv: Move render/compute engine reset domains related workarounds (2022-03-02 06:52:42 -0800) Cross-subsystem Changes: - drm-next backmerge for buddy allocator changes Driver Changes: - Skip i915_perf init for DG2 as it is not yet enabled (Ram) - Add missing workarounds for DG2 (Clint) - Add 64K page/align support for platforms like DG2 that require it (Matt A, Ram, Bob) - Add accelerated migration support for DG2 (Matt A) - Add flat CCS support for XeHP SDV (Abdiel, Ram) - Add Compute Command Streamer (CCS) engine support for XeHP SDV (Michel, Daniele, Aravind, Matt R) - Don't support parallel submission on compute / render (Matt B, Matt R) - Disable i915 build on PREEMPT_RT until RT behaviour fixed (Sebastian) - Remove RPS interrupt support for TGL+ (Jose) - Fix S/R with PM_EARLY for non-GTT mappable objects on DG2 (Matt, Lucas) - Skip stolen memory init if it is fully reserved (Jose) - Use iosys_map for GuC data structures that may be in LMEM BAR or SMEM (Lucas) - Do not complain about stale GuC reset notifications for banned contexts (John) - Move context descriptor fields to intel_lrc.h - Start adding support for small BAR (Matt A) - Clarify vma lifetime (Thomas) - Simplify subplatform detection on TGL (Jose) - Correct the param count for unset GuC SLPC param (Vinay, Umesh) - Read RP_STATE_CAP correctly on Gen12 with GuC SLPC (Vinay) - Initialize GuC submission locks and queues early (Daniele) - Fix GuC flag query helper function to not modify state (John) - Drop fake lmem support now we have real hardware available (Lucas) - Move misplaced W/A to their correct locations (Srinivasan) - Use get_reset_domain() helper (Tejas) - Move context descriptor fields to intel_lrc.h (Matt R) - Selftest improvements (Matt A) Abdiel Janulgue (1): drm/i915/lmem: Enable lmem for platforms with Flat CCS CQ Tang (1): drm/i915/xehpsdv: Add has_flat_ccs to device info Clint Taylor (1): drm/i915/dg2: add Wa_14014947963 Daniele Ceraolo Spurio (4): drm/i915/guc: Initialize GuC submission locks and queues early drm/i915/xehp: compute engine pipe_control drm/i915/xehp/guc: enable compute engine inside GuC drm/i915/xehp: handle fused off CCS engines John Harrison (2):
[PULL] drm-intel-gt-next
es range-based (Matt R) - Ditch the i915_gem_ww_ctx loop member (Thomas, Maarten) - Use NULL instead of 0 where appropriate (Ville) - Rename pci/debugfs functions to respect file prefix (Jani, Lucas) - Drop guc_communication_enabled (Daniele) - Selftest fixes (Thomas, Daniel, Matt A, Maarten) - Clean up inconsistent indenting (Colin) - Use direction definition DMA_BIDIRECTIONAL instead of PCI_DMA_BIDIRECTIONAL (Cai) - Add "intel_" as prefix in set_mocs_index() (Ayaz) Akeem G Abodunrin (1): drm/i915/dg2: Add new LRI reg offsets Akira Yokosawa (1): drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid Anshuman Gupta (2): drm/i915/pxp: Add plane decryption support drm/i915/pxp: black pixels on pxp disabled Ayaz A Siddiqui (6): drm/i915/gt: Add support of mocs propagation drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward drm/i915/gt: Set BLIT_CCTL reg to un-cached drm/i915/gt: Initialize unused MOCS entries with device specific values drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL drm/i915/gt: Add "intel_" as prefix in set_mocs_index() Cai Huoqing (1): drm/i915: Use direction definition DMA_BIDIRECTIONAL instead of PCI_DMA_BIDIRECTIONAL Colin Ian King (1): drm/i915: clean up inconsistent indenting Dan Carpenter (1): drm/i915/gt: Potential error pointer dereference in pinned_context() Daniel Vetter (14): drm/doc/rfc: drop lmem uapi section drm/i915: Use locked access to ctx->engines in set_priority drm/i915: Actually delete gpu reloc selftests drm/i915: Release i915_gem_context from a worker drm/i915: Release ctx->syncobj on final put, not on ctx close drm/i915: Keep gem ctx->vm alive until the final put drm/i915: Drop code to handle set-vm races from execbuf drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm drm/i915: Use i915_gem_context_get_eb_vm in ctx_getparam drm/i915: Add i915_gem_context_is_full_ppgtt drm/i915: Use i915_gem_context_get_eb_vm in intel_context_set_gem drm/i915: Drop __rcu from gem_context->vm drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups drm/i915: Stop rcu support for i915_address_space Daniele Ceraolo Spurio (12): drm/i915/guc: drop guc_communication_enabled drm/i915/guc: put all guc objects in lmem when available drm/i915/guc: Add DG1 GuC / HuC firmware defs drm/i915/pxp: Define PXP component interface drm/i915/pxp: define PXP device flag and kconfig drm/i915/pxp: allocate a vcs context for pxp usage drm/i915/pxp: set KCR reg init drm/i915/pxp: interfaces for using protected objects drm/i915/pxp: start the arb session on demand drm/i915/pxp: add pxp debugfs drm/i915/pxp: add PXP documentation drm/i915/pxp: enable PXP for integrated Gen12 Huang, Sean Z (5): drm/i915/pxp: Implement funcs to create the TEE channel drm/i915/pxp: Create the arbitrary session after boot drm/i915/pxp: Implement arb session teardown drm/i915/pxp: Implement PXP irq handler drm/i915/pxp: Enable PXP power management Jani Nikula (1): drm/i915/pci: rename functions to have i915_pci prefix Janusz Krzysztofik (2): drm/i915: Mark GPU wedging on driver unregister unrecoverable drm/i915: Flush buffer pools on driver remove Joonas Lahtinen (2): Merge drm/drm-next into drm-intel-gt-next Merge remote-tracking branch 'tip/locking/wwmutex' into drm-intel-gt-next Kees Cook (1): drm/i915: Use designated initializers for init/exit table Lucas De Marchi (8): drm/i915/xehpsdv: factor out function to read RP_STATE_CAP drm/i915/dg1: remove __maybe_unused leftover drm/i915/xehpsdv: Define MOCS table for XeHP SDV drm/i915: rename debugfs_gt files drm/i915: rename debugfs_engines files drm/i915: rename debugfs_gt_pm files drm/i915: deduplicate frequency dump on debugfs drm/i915: remove IS_ACTIVE Maarten Lankhorst (5): drm/i915: Add pci ids and uapi for DG1 drm/i915: Add mmap lock around vma_lookup() in the mman selftest. drm/i915: Move __i915_gem_free_object to ttm_bo_destroy kernel/locking: Add context to ww_mutex_trylock() drm/i915: Fix runtime pm handling in i915_gem_shrink Matt Roper (21): drm/i915: correct name of GT forcewake domain in error messages drm/i915: Re-use gen11 forcewake read functions on gen12 drm/i915: Make shadow tables range-based drm/i915/gen11: Update shadowed register table drm/i915/gen12: Update shadowed register table drm/i915/xehp: Xe_HP shadowed registers are a strict superset of gen12 drm/i915/xehp: Loop over all gslices for INSTDONE processing drm/i915/dg2: Report INSTDONE_GEOM
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here comes the final feature PR for 5.16. As the biggest thing it adds multi-LRC (parallel) submission implementation for GuC and a simplified parallel submission uAPI to go with that (only works with GuC for now). It is has a similar mission to the bonded submission uAPI, take a look at the kerneldocs for full detail. Then there are some improvements to making sure old pages are flushed from caches before making them available to userspaces. Those extra flushes may be visible in corner case scenarios if application is frequently importing new dmabufs on non-LLC hardware. The better approach would anyway be to recycle a pool of dmabufs than destroy and recreate. In addition to that, it's only minor changes with mainly developer impact and those can be seen in shortlog. Regards, Joonas PS. There has been request to backmerge drm-next after you merge this PR, to bring in dma-resv iterators. I'll do that. PPS. Will send out the dim patches for the "for-linux-next-gt" branch updating to make sure we avoid the future conflicts. *** drm-intel-gt-next-2021-10-21: UAPI Changes: - Expose multi-LRC submission interface Similar to the bonded submission interface but simplified. Comes with GuC only implementation for now. See kerneldoc for more details. Userspace changes: https://github.com/intel/media-driver/pull/1252 - Expose logical engine instance to user Needed by the multi-LRC submission interface for GuC Userspace changes: https://github.com/intel/media-driver/pull/1252 Driver Changes: - Fix blank screen booting crashes when CONFIG_CC_OPTIMIZE_FOR_SIZE=y (Hugh) - Add support for multi-LRC submission in the GuC backend (Matt B) - Add extra cache flushing before making pages userspace visible (Matt A, Thomas) - Mark internal GPU object pages dirty so they will be flushed properly (Matt A) - Move remaining debugfs interfaces i915_wedged/i915_forcewake_user into gt (Andi) - Replace the unconditional clflushes with drm_clflush_virt_range() (Ville) - Remove IS_ACTIVE macro completely (Lucas) - Improve kerneldocs for cache_dirty (Matt A) - Add missing includes (Lucas) - Selftest improvements (Matt R, Ran, Matt A) The following changes since commit 1a839e016e4964b5c8384e5d82e5e5ac02a23f52: drm/i915: remove IS_ACTIVE (2021-10-07 11:04:05 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2021-10-21 for you to fetch changes up to ab5d964c001b9efffcbfa4d67a30186b67d79771: drm/i915/selftests: mark up hugepages object with start_cpu_write (2021-10-20 16:50:42 +0100) UAPI Changes: - Expose multi-LRC submission interface Similar to the bonded submission interface but simplified. Comes with GuC only implementation for now. See kerneldoc for more details. Userspace changes: https://github.com/intel/media-driver/pull/1252 - Expose logical engine instance to user Needed by the multi-LRC submission interface for GuC Userspace changes: https://github.com/intel/media-driver/pull/1252 Driver Changes: - Fix blank screen booting crashes when CONFIG_CC_OPTIMIZE_FOR_SIZE=y (Hugh) - Add support for multi-LRC submission in the GuC backend (Matt B) - Add extra cache flushing before making pages userspace visible (Matt A, Thomas) - Mark internal GPU object pages dirty so they will be flushed properly (Matt A) - Move remaining debugfs interfaces i915_wedged/i915_forcewake_user into gt (Andi) - Replace the unconditional clflushes with drm_clflush_virt_range() (Ville) - Remove IS_ACTIVE macro completely (Lucas) - Improve kerneldocs for cache_dirty (Matt A) - Add missing includes (Lucas) - Selftest improvements (Matt R, Ran, Matt A) Andi Shyti (1): drm/i915/gt: move remaining debugfs interfaces into gt Hugh Dickins (1): drm/i915: fix blank screen booting crashes Lucas De Marchi (2): drm/i915/gt: include tsc.h where used drm/i915/gt: add asm/cacheflush.h for use of clflush() Matt Roper (1): drm/i915: Stop using I915_TILING_* in client blit selftest Matthew Auld (9): drm/i915: mark dmabuf objects as ALLOC_USER drm/i915: mark userptr objects as ALLOC_USER drm/i915: extract bypass-llc check into helper drm/i915/dmabuf: add paranoid flush-on-acquire drm/i915/userptr: add paranoid flush-on-acquire drm/i915/shmem: ensure flush during swap-in on non-LLC drm/i915: expand on the kernel-doc for cache_dirty drm/i915: mark up internal objects with start_cpu_write drm/i915/selftests: mark up hugepages object with start_cpu_write Matthew Brost (24): drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct drm/i915/guc: Take GT PM ref when deregistering context drm/i915/guc: Take engine PM when a context is pinned with GuC submission drm/i915/gu
Re: [PATCH 00/47] GuC submission support
Hi Matt & John, Can you please queue patches with the right Fixes: references to convert all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS protection for now. Please do so before next Wednesday so we get it queued in drm-intel-next-fixes. There's the orthogonal track to discuss what would be the stable set of tracepoints we could expose. However, before that discussion is closed, let's keep a rather strict line to avoid potential maintenance burned. We can then relax in the future as needed. Regards, Joonas Quoting Matthew Brost (2021-06-24 10:04:29) > As discussed in [1], [2] we are enabling GuC submission support in the > i915. This is a subset of the patches in step 5 described in [1], > basically it is absolute to enable CI with GuC submission on gen11+ > platforms. > > This series itself will likely be broken down into smaller patch sets to > merge. Likely into CTBs changes, basic submission, virtual engines, and > resets. > > A following series will address the missing patches remaining from [1]. > > Locally tested on TGL machine and basic tests seem to be passing. > > Signed-off-by: Matthew Brost > > [1] https://patchwork.freedesktop.org/series/89844/ > [2] https://patchwork.freedesktop.org/series/91417/ > > Daniele Ceraolo Spurio (1): > drm/i915/guc: Unblock GuC submission on Gen11+ > > John Harrison (10): > drm/i915/guc: Module load failure test for CT buffer creation > drm/i915: Track 'serial' counts for virtual engines > drm/i915/guc: Provide mmio list to be saved/restored on engine reset > drm/i915/guc: Don't complain about reset races > drm/i915/guc: Enable GuC engine reset > drm/i915/guc: Fix for error capture after full GPU reset with GuC > drm/i915/guc: Hook GuC scheduling policies up > drm/i915/guc: Connect reset modparam updates to GuC policy flags > drm/i915/guc: Include scheduling policies in the debugfs state dump > drm/i915/guc: Add golden context to GuC ADS > > Matthew Brost (36): > drm/i915/guc: Relax CTB response timeout > drm/i915/guc: Improve error message for unsolicited CT response > drm/i915/guc: Increase size of CTB buffers > drm/i915/guc: Add non blocking CTB send function > drm/i915/guc: Add stall timer to non blocking CTB send function > drm/i915/guc: Optimize CTB writes and reads > drm/i915/guc: Add new GuC interface defines and structures > drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor > drm/i915/guc: Add lrc descriptor context lookup array > drm/i915/guc: Implement GuC submission tasklet > drm/i915/guc: Add bypass tasklet submission path to GuC > drm/i915/guc: Implement GuC context operations for new inteface > drm/i915/guc: Insert fence on context when deregistering > drm/i915/guc: Defer context unpin until scheduling is disabled > drm/i915/guc: Disable engine barriers with GuC during unpin > drm/i915/guc: Extend deregistration fence to schedule disable > drm/i915: Disable preempt busywait when using GuC scheduling > drm/i915/guc: Ensure request ordering via completion fences > drm/i915/guc: Disable semaphores when using GuC scheduling > drm/i915/guc: Ensure G2H response has space in buffer > drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC > drm/i915/guc: Update GuC debugfs to support new GuC > drm/i915/guc: Add several request trace points > drm/i915: Add intel_context tracing > drm/i915/guc: GuC virtual engines > drm/i915: Hold reference to intel_context over life of i915_request > drm/i915/guc: Disable bonding extension with GuC submission > drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs > drm/i915/guc: Reset implementation for new GuC interface > drm/i915: Reset GPU immediately if submission is disabled > drm/i915/guc: Add disable interrupts to guc sanitize > drm/i915/guc: Suspend/resume implementation for new interface > drm/i915/guc: Handle context reset notification > drm/i915/guc: Handle engine reset failure notification > drm/i915/guc: Enable the timer expired interrupt for GuC > drm/i915/guc: Capture error state on context reset > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 30 +- > drivers/gpu/drm/i915/gem/i915_gem_context.h |1 + > drivers/gpu/drm/i915/gem/i915_gem_mman.c |3 +- > drivers/gpu/drm/i915/gt/gen8_engine_cs.c |6 +- > drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 41 +- > drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 14 +- > .../gpu/drm/i915/gt/intel_breadcrumbs_types.h |7 + > drivers/gpu/drm/i915/gt/intel_context.c | 41 +- > drivers/gpu/drm/i915/gt/intel_context.h | 31 +- > drivers/gpu/drm/i915/gt/intel_context_types.h | 49 + > drivers/gpu/drm/i915/gt/intel_engine.h| 72 +- > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 182 +- > .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 71 +- > .../gpu/drm/i915/gt/intel_engine_heartbeat.h |4 + > drivers/gpu/drm/i915/gt/intel_engine_types
Re: [PATCH 00/47] GuC submission support
Quoting Matthew Brost (2021-10-22 19:42:19) > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: > > Hi Matt & John, > > > > Can you please queue patches with the right Fixes: references to convert > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS > > protection for now. Please do so before next Wednesday so we get it > > queued in drm-intel-next-fixes. > > > > Don't we already do that? I checked i915_trace.h and every tracepoint I > added (intel_context class, i915_request_guc_submit) is protected by > LOW_LEVEL_TRACEPOINTS. > > The only thing I changed outside of that protection is adding the guc_id > field to existing i915_request class tracepoints. It's the first search hit for "guc" inside the i915_trace.h file :) > Without the guc_id in > those tracepoints these are basically useless with GuC submission. We > could revert that if it is a huge deal but as I said then they are > useless... Let's eliminate it for now and restore the tracepoint exactly as it was. If there is an immediate need, we should instead have an auxilary tracepoint which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the information of the basic tracepoint. For the longer term solution we should align towards the dma fence tracepoints. When those are combined with the OA information, one should be able to get a good understanding of both the software and hardware scheduling decisions. Regards, Joonas > > Matt > > > There's the orthogonal track to discuss what would be the stable set of > > tracepoints we could expose. However, before that discussion is closed, > > let's keep a rather strict line to avoid potential maintenance burned. > > > > We can then relax in the future as needed. > > > > Regards, Joonas > > > > Quoting Matthew Brost (2021-06-24 10:04:29) > > > As discussed in [1], [2] we are enabling GuC submission support in the > > > i915. This is a subset of the patches in step 5 described in [1], > > > basically it is absolute to enable CI with GuC submission on gen11+ > > > platforms. > > > > > > This series itself will likely be broken down into smaller patch sets to > > > merge. Likely into CTBs changes, basic submission, virtual engines, and > > > resets. > > > > > > A following series will address the missing patches remaining from [1]. > > > > > > Locally tested on TGL machine and basic tests seem to be passing. > > > > > > Signed-off-by: Matthew Brost > > > > > > [1] https://patchwork.freedesktop.org/series/89844/ > > > [2] https://patchwork.freedesktop.org/series/91417/ > > > > > > Daniele Ceraolo Spurio (1): > > > drm/i915/guc: Unblock GuC submission on Gen11+ > > > > > > John Harrison (10): > > > drm/i915/guc: Module load failure test for CT buffer creation > > > drm/i915: Track 'serial' counts for virtual engines > > > drm/i915/guc: Provide mmio list to be saved/restored on engine reset > > > drm/i915/guc: Don't complain about reset races > > > drm/i915/guc: Enable GuC engine reset > > > drm/i915/guc: Fix for error capture after full GPU reset with GuC > > > drm/i915/guc: Hook GuC scheduling policies up > > > drm/i915/guc: Connect reset modparam updates to GuC policy flags > > > drm/i915/guc: Include scheduling policies in the debugfs state dump > > > drm/i915/guc: Add golden context to GuC ADS > > > > > > Matthew Brost (36): > > > drm/i915/guc: Relax CTB response timeout > > > drm/i915/guc: Improve error message for unsolicited CT response > > > drm/i915/guc: Increase size of CTB buffers > > > drm/i915/guc: Add non blocking CTB send function > > > drm/i915/guc: Add stall timer to non blocking CTB send function > > > drm/i915/guc: Optimize CTB writes and reads > > > drm/i915/guc: Add new GuC interface defines and structures > > > drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor > > > drm/i915/guc: Add lrc descriptor context lookup array > > > drm/i915/guc: Implement GuC submission tasklet > > > drm/i915/guc: Add bypass tasklet submission path to GuC > > > drm/i915/guc: Implement GuC context operations for new inteface > > > drm/i915/guc: Insert fence on context when deregistering > > > drm/i915/guc: Defer context unpin until scheduling is disabled > > > drm/i915/guc: Disable engine barriers with GuC during unpin > > > drm/i915/guc: E
Re: [PATCH] drm/i915/guc: Fix recursive lock in GuC submission
Quoting Thomas Hellström (2021-10-21 08:39:48)
> On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > pinned with GuC submission")
> > Signed-off-by: Matthew Brost
> > Cc: sta...@vger.kernel.org
This Cc: stable annotation is unnecessary.
Please always use "dim fixes 1a52faed31311" for helping to decide which
Cc's are needed. In this case stable is not needed. If it was, there
would be an indication of kernel version. In this case this is fine to
be picked up by in drm-intel-next-fixes PR.
Let's pay attention to the right Fixes: annotation while submitting and
reviewing patches.
Regards, Joonas
[PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver. Tvrtko will bring added bandwidth and focus to the GT/GEM domain (drm-intel-gt-next). This will help with the increased driver maintenance efforts, allows alternating the drm-intel-gt-next pull requests and also should increase the coverage for the maintenance in general. Signed-off-by: Joonas Lahtinen Cc: David Airlie Cc: Daniel Vetter Acked-by: Jani Nikula Acked-by: Rodrigo Vivi Acked-by: Tvrtko Ursulin Cc: Sean Paul Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: dri-devel@lists.freedesktop.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 98aa1f55ed41..07553156a1c2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9361,6 +9361,7 @@ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) M: Jani Nikula M: Joonas Lahtinen M: Rodrigo Vivi +M: Tvrtko Ursulin L: intel-...@lists.freedesktop.org S: Supported W: https://01.org/linuxgraphics/ -- 2.31.1
Re: [PATCH 00/47] GuC submission support
Quoting Matthew Brost (2021-10-25 18:15:09) > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote: > > Quoting Matthew Brost (2021-10-22 19:42:19) > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: > > > > Hi Matt & John, > > > > > > > > Can you please queue patches with the right Fixes: references to convert > > > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS > > > > protection for now. Please do so before next Wednesday so we get it > > > > queued in drm-intel-next-fixes. > > > > > > > > > > Don't we already do that? I checked i915_trace.h and every tracepoint I > > > added (intel_context class, i915_request_guc_submit) is protected by > > > LOW_LEVEL_TRACEPOINTS. > > > > > > The only thing I changed outside of that protection is adding the guc_id > > > field to existing i915_request class tracepoints. > > > > It's the first search hit for "guc" inside the i915_trace.h file :) > > > > > Without the guc_id in > > > those tracepoints these are basically useless with GuC submission. We > > > could revert that if it is a huge deal but as I said then they are > > > useless... > > > > Let's eliminate it for now and restore the tracepoint exactly as it was. > > > > Don't really agree - let's render tracepoints to be useless? Are > tracepoints ABI? I googled this and couldn't really find a definie > answer. If tracepoints are ABI, then OK I can revert this change but > still this is a poor technical decision (tracepoints should not be ABI). Thats a very heated discussion in general. But the fact is that if tracepoint changes have caused regressions to applications, they have been forced to be remain untouched. You are free to raise the discussion with Linus/LKML if you feel that should not be the case. So the end result is that tracepoints are effectively in limbo, not ABI unless some application uses them like ABI. Feel free to search the intel-gfx/lkml for "tracepoints" keyword and look for threads with many replies. It's not that I would not agree, it's more that I'm not in the mood for repeating that discussion over and over again and always land in the same spot. So for now, we don't add anything new to tracepoints we can't guarantee to always be there untouched. Similarly, we don't guarantee any of them to remain stable. So we try to be compatible with the limbo. I'm long overdue waiting for some stable consumer to step up for the tracepoints, so we can then start discussion what would actually be the best way of getting that information out for them. In ~5 years that has not happened. > > If there is an immediate need, we should instead have an auxilary tracepoint > > which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the > > information of the basic tracepoint. > > > > Regardless of what I said above, I'll post 2 patches. The 1st just > remove the GuC, the 2nd modify the tracepoint to include guc_id if > LOW_LEVEL_TRACEPOINTS is defined. Thanks. Let's get a patch merged which simply drops the guc_id for now to unblock things. For the second, an auxilary tracepoint will be preferred instead of mutating the existing one (regardless of the LOW_LEVEL_TRACEPOINTS). I only noticed a patch that mutates the tracepoints, can you double-check sending the first patch? Regards, Joonas > > > For the longer term solution we should align towards the dma fence > > tracepoints. When those are combined with the OA information, one should > > be able to get a good understanding of both the software and hardware > > scheduling decisions. > > > > Not sure about this either. I use these tracepoins to correlate things > to the GuC log. Between the 2, if you know what you are doing you > basically can figure out everything that is happening. Fields in the > trace translate directly to fields in the GuC log. Some of these fields > are backend specific, not sure how these could be pushed the dma fence > tracepoints. For what it is worth, without these tracepoints we'd likely > still have a bunch of bugs in the GuC firmware. I understand these > points, several other i915 developers do, and several of the GuC > firmware developers do too. > > Matt > > > Regards, Joonas > > > > > > > > Matt > > > > > > > There's the orthogonal track to discuss what would be the stable set of > > > > tracepoints we could expose. However, before that discussion is closed, > > > > let's keep a rather st
Re: [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig
Quoting John Harrison (2021-10-26 00:06:54)
> On 10/25/2021 09:34, Matthew Brost wrote:
> > Hide the guc_id and tail fields, for request trace points, behind
> > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> > are ABI (maybe?) so don't change them without kernel developers Kconfig
> > options.
> The i915 sw arch team have previously hard blocked requests for changes
> to trace points from user land tool developers on the grounds that trace
> points are not ABI and are free to change at whim as and when the i915
> internal implementation changes. They are purely for use of developers
> to debug the i915 driver as the i915 driver currently stands at any
> given instant.
Correct. That is indicated by the LOW_LEVEL_TRACEPOINTS.
All the discussions about stable usage really revolve around the low level
backend specific scheduling tracepoints to analyze hardware utilization.
And those even become infeasible to expose when GuC scheduling is enabled
as the information really goes to GuC log.
Luckily we have added the mechanism to get the actual utilization
through OA via gpuvis tool, so we don't have to guesstimate it from the
KMD scheduling tracepoints (which are for KMD debugging).
> So I don't see how it can be argued that we must not update any trace
> points to allow for debugging of i915 scheduling issues on current
> platforms. And having to enable extra config options just to keep
> existing higher level trace points usable seems broken.
We can update them (even outside LOW_LEVEL_TRACEPOINTS) but there should
not be any backend specific data added outside the LOW_LEVEL_TRACEPOINTS,
just to prevent anyone from starting to use them in some
visualization/analysis tooling.
If you have the energy to drive the general LKML/Linux Plumbers level
discussion about tracepoint stability limbo into a conclusion, I'll be
more than happy to see it resolved :)
Regards, Joonas
>
> John.
>
>
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/i915_trace.h | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_trace.h
> > b/drivers/gpu/drm/i915/i915_trace.h
> > index 9795f456cccf..4f5238d02b51 100644
> > --- a/drivers/gpu/drm/i915/i915_trace.h
> > +++ b/drivers/gpu/drm/i915/i915_trace.h
> > @@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
> > __entry->ctx, __entry->seqno, __entry->flags)
> > );
> >
> > +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
> > DECLARE_EVENT_CLASS(i915_request,
> > TP_PROTO(struct i915_request *rq),
> > TP_ARGS(rq),
> > @@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
> > __entry->guc_id, __entry->ctx, __entry->seqno,
> > __entry->tail)
> > );
> > +#else
> > +DECLARE_EVENT_CLASS(i915_request,
> > + TP_PROTO(struct i915_request *rq),
> > + TP_ARGS(rq),
> > +
> > + TP_STRUCT__entry(
> > + __field(u32, dev)
> > + __field(u64, ctx)
> > + __field(u16, class)
> > + __field(u16, instance)
> > + __field(u32, seqno)
> > + ),
> > +
> > + TP_fast_assign(
> > +__entry->dev =
> > rq->engine->i915->drm.primary->index;
> > +__entry->class = rq->engine->uabi_class;
> > +__entry->instance = rq->engine->uabi_instance;
> > +__entry->ctx = rq->fence.context;
> > +__entry->seqno = rq->fence.seqno;
> > +),
> > +
> > + TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
> > + __entry->dev, __entry->class, __entry->instance,
> > + __entry->ctx, __entry->seqno)
> > +);
> > +#endif
> >
> > DEFINE_EVENT(i915_request, i915_request_add,
> >TP_PROTO(struct i915_request *rq),
>
Re: [PATCH] drm/i915/guc: Fix recursive lock in GuC submission
Quoting Matthew Brost (2021-10-25 20:13:22)
> On Mon, Oct 25, 2021 at 03:23:00PM +0300, Joonas Lahtinen wrote:
> > Quoting Thomas Hellström (2021-10-21 08:39:48)
> > > On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> >
> >
> >
> > > > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > > > pinned with GuC submission")
> > > > Signed-off-by: Matthew Brost
> > > > Cc: sta...@vger.kernel.org
> >
> > This Cc: stable annotation is unnecessary.
> >
> > Please always use "dim fixes 1a52faed31311" for helping to decide which
> > Cc's are needed. In this case stable is not needed. If it was, there
> > would be an indication of kernel version. In this case this is fine to
> > be picked up by in drm-intel-next-fixes PR.
> >
> > Let's pay attention to the right Fixes: annotation while submitting and
> > reviewing patches.
> >
>
> Will do. Working on getting push rights. Is there any documentation with
> all the rules when pushing as it seems like there are a lot of rules.
Yes, we have the documentation here:
https://drm.pages.freedesktop.org/maintainer-tools/committer-guidelines.html
And more specifically this topic:
https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-intel.html#labeling-fixes-before-pushing
I could even recommend to at least do a cursory read through the wider
documentation about how the different trees interact:
https://drm.pages.freedesktop.org/maintainer-tools/index.html
Makes it easier to understand how the tags are used.
Regards, Joonas
>
> Matt
>
> > Regards, Joonas
Re: [PATCH 00/47] GuC submission support
Quoting Matthew Brost (2021-10-26 18:51:17) > On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote: > > Quoting Matthew Brost (2021-10-25 18:15:09) > > > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote: > > > > Quoting Matthew Brost (2021-10-22 19:42:19) > > > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: > > > > > > Hi Matt & John, > > > > > > > > > > > > Can you please queue patches with the right Fixes: references to > > > > > > convert > > > > > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS > > > > > > protection for now. Please do so before next Wednesday so we get it > > > > > > queued in drm-intel-next-fixes. > > > > > > > > > > > > > > > > Don't we already do that? I checked i915_trace.h and every tracepoint > > > > > I > > > > > added (intel_context class, i915_request_guc_submit) is protected by > > > > > LOW_LEVEL_TRACEPOINTS. > > > > > > > > > > The only thing I changed outside of that protection is adding the > > > > > guc_id > > > > > field to existing i915_request class tracepoints. > > > > > > > > It's the first search hit for "guc" inside the i915_trace.h file :) > > > > > > > > > Without the guc_id in > > > > > those tracepoints these are basically useless with GuC submission. We > > > > > could revert that if it is a huge deal but as I said then they are > > > > > useless... > > > > > > > > Let's eliminate it for now and restore the tracepoint exactly as it was. > > > > > > > > > > Don't really agree - let's render tracepoints to be useless? Are > > > tracepoints ABI? I googled this and couldn't really find a definie > > > answer. If tracepoints are ABI, then OK I can revert this change but > > > still this is a poor technical decision (tracepoints should not be ABI). > > > > Thats a very heated discussion in general. But the fact is that if > > tracepoint changes have caused regressions to applications, they have > > been forced to be remain untouched. You are free to raise the discussion > > with Linus/LKML if you feel that should not be the case. So the end > > result is that tracepoints are effectively in limbo, not ABI unless some > > application uses them like ABI. > > > > Feel free to search the intel-gfx/lkml for "tracepoints" keyword and look > > for threads with many replies. It's not that I would not agree, it's more > > that I'm not in the mood for repeating that discussion over and over again > > and always land in the same spot. > > > > So for now, we don't add anything new to tracepoints we can't guarantee > > to always be there untouched. Similarly, we don't guarantee any of them > > to remain stable. So we try to be compatible with the limbo. > > > > I'm long overdue waiting for some stable consumer to step up for the > > tracepoints, so we can then start discussion what would actually be the > > best way of getting that information out for them. In ~5 years that has > > not happened. > > > > > > If there is an immediate need, we should instead have an auxilary > > > > tracepoint > > > > which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the > > > > information of the basic tracepoint. > > > > > > > > > > Regardless of what I said above, I'll post 2 patches. The 1st just > > > remove the GuC, the 2nd modify the tracepoint to include guc_id if > > > LOW_LEVEL_TRACEPOINTS is defined. > > > > Thanks. Let's get a patch merged which simply drops the guc_id for now > > to unblock things. > > > > For the second, an auxilary tracepoint will be preferred instead of > > mutating the existing one (regardless of the LOW_LEVEL_TRACEPOINTS). > > > > I only noticed a patch that mutates the tracepoints, can you > > double-check sending the first patch? > > Sorry for the double reply - missed this one in the first. > > I changed my plans / mind after I send the original email. I only sent a > patch which includes guc_id when LOW_LEVEL_TRACEPOINTS is enabled. That > is the bear minimum I live with. Without it any time there is a problem > results in hacking the kernel. I can't do t
Re: [PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
Quoting Dave Airlie (2021-10-26 03:34:52) > On Mon, 25 Oct 2021 at 23:51, Daniel Vetter wrote: > > > > On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen > > wrote: > > > > > > Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver. > > > Tvrtko will bring added bandwidth and focus to the GT/GEM domain > > > (drm-intel-gt-next). > > > > > > This will help with the increased driver maintenance efforts, allows > > > alternating the drm-intel-gt-next pull requests and also should increase > > > the coverage for the maintenance in general. > > > > > > Signed-off-by: Joonas Lahtinen > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Acked-by: Jani Nikula > > > Acked-by: Rodrigo Vivi > > > Acked-by: Tvrtko Ursulin > > > Cc: Sean Paul > > > Cc: Maarten Lankhorst > > > Cc: Maxime Ripard > > > Cc: dri-devel@lists.freedesktop.org > > > > Acked-by: Daniel Vetter > > Acked-by: Dave Airlie Thanks for the Acks, this is now merged. Regards, Joonas
Re: [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig
Quoting Matthew Brost (2021-10-25 19:34:04)
> Hide the guc_id and tail fields, for request trace points, behind
> CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> are ABI (maybe?) so don't change them without kernel developers Kconfig
> options.
I've pushed the simple fix to eliminate the 'guc_id' field.
In my opinion a separate tracepoint with more information would be a
better choice here compared to mutating an existing one.
The idea with LOW_LEVEL_TRACEPOINTS is to make sure there are two sets
of tracepoints: one that is quasi stable and the other that is unstable.
Mutating the other set when the unstable set is enabled kind of breaks
that clean split.
Regards, Joonas
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/i915_trace.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index 9795f456cccf..4f5238d02b51 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
> __entry->ctx, __entry->seqno, __entry->flags)
> );
>
> +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
> DECLARE_EVENT_CLASS(i915_request,
> TP_PROTO(struct i915_request *rq),
> TP_ARGS(rq),
> @@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
> __entry->guc_id, __entry->ctx, __entry->seqno,
> __entry->tail)
> );
> +#else
> +DECLARE_EVENT_CLASS(i915_request,
> + TP_PROTO(struct i915_request *rq),
> + TP_ARGS(rq),
> +
> + TP_STRUCT__entry(
> +__field(u32, dev)
> +__field(u64, ctx)
> +__field(u16, class)
> +__field(u16, instance)
> +__field(u32, seqno)
> +),
> +
> + TP_fast_assign(
> + __entry->dev =
> rq->engine->i915->drm.primary->index;
> + __entry->class = rq->engine->uabi_class;
> + __entry->instance = rq->engine->uabi_instance;
> + __entry->ctx = rq->fence.context;
> + __entry->seqno = rq->fence.seqno;
> + ),
> +
> + TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
> + __entry->dev, __entry->class, __entry->instance,
> + __entry->ctx, __entry->seqno)
> +);
> +#endif
>
> DEFINE_EVENT(i915_request, i915_request_add,
> TP_PROTO(struct i915_request *rq),
> --
> 2.32.0
>
Re: linux-next: build warning after merge of the drm tree
(+ Tvrtko who was recently added as a drm/i915 co-maintainer) Quoting Daniel Vetter (2021-01-22 10:40:48) > On Fri, Jan 22, 2021 at 8:29 AM Stephen Rothwell > wrote: > > > > Hi Daniel, > > > > On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote: > > > > > > Hm that has been in drm-intel-gt-next for a few days, is that tree not > > > in linux-next? > > > > It is not. Hi Stephen, We should be now good to go and add drm-intel-gt-next to linux-next. The branch would be as follows: drm-intel-gt-next git://anongit.freedesktop.org/drm-intel for-linux-next-gt Notice the "-gt" and the end of the for-linux-next branch name. This should eliminate the gap we have been having. The change to add it to the DIM tool is here: https://gitlab.freedesktop.org/drm/maintainer-tools/-/commit/7b5c2c29cdbc054e8c8fce38f095c56290fc4833 So once all developers have updated their tooling (for which they will get an automatic nag message) we should be all up-to-date for future merge windows. Regards, Joonas > Adding -intel maintainers to get that sorted. > -Daniel > > > These are the drm branches currently in linux-next: > > Oh for ordering maybe put drm-misc ahead of the other subtrees, -misc > is where nowadays a lot of refactorings and core changes land. > Probably doesn't matter in practice. > -Daniel > > > drm-fixes git://git.freedesktop.org/git/drm/drm.git drm-fixes > > amdgpu-fixesgit://people.freedesktop.org/~agd5f/linux drm-fixes > > drm-intel-fixes git://anongit.freedesktop.org/drm-intel > > for-linux-next-fixes > > drm-misc-fixes git://anongit.freedesktop.org/drm/drm-misc > > for-linux-next-fixes > > drm git://git.freedesktop.org/git/drm/drm.git drm-next > > amdgpu https://gitlab.freedesktop.org/agd5f/linux drm-next > > drm-intel git://anongit.freedesktop.org/drm-intel > > for-linux-next > > drm-tegra git://anongit.freedesktop.org/tegra/linux.git > > drm/tegra/for-next > > drm-miscgit://anongit.freedesktop.org/drm/drm-misc > > for-linux-next > > drm-msm https://gitlab.freedesktop.org/drm/msm.git msm-next > > imx-drm https://git.pengutronix.de/git/pza/linuximx-drm/next > > etnaviv https://git.pengutronix.de/git/lst/linuxetnaviv/next > > > > -- > > Cheers, > > Stephen Rothwell > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.
Quoting Peter Zijlstra (2021-09-17 16:13:19) > On Thu, Sep 16, 2021 at 03:28:11PM +0200, Peter Zijlstra wrote: > > On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote: > > > > > > For merge logistics, can we pls have a stable branch? I expect that the > > > > i915 patches will be ready for 5.16. > > > > > > > > Or send it in for -rc2 so that the interface change doesn't cause > > > > needless > > > > conflicts, whatever you think is best. > > > > > Yeah, some central branch drm could pull from, would make upstreaming > > > patches that depends on it easier. :) > > > > I think I'll make tip/locking/wwmutex and include that in > > tip/locking/core, let me have a poke. > > This is now so. Enjoy! This is now merged to drm-intel-gt-next. Regards, Joonas
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Quoting Tvrtko Ursulin (2022-01-17 18:02:50) > > On 17/01/2022 15:09, Andi Shyti wrote: > > The GT has its own properties and in sysfs they should be grouped > > in the 'gt/' directory. > > > > Create a 'gt/' directory in sysfs which will contain gt0...gtN > > directories related to each tile configured in the GPU. Move the > > power management files inside those directories. > > > > The previous power management files are kept in their original > > root directory to avoid breaking the ABI. They point to the tile > > '0' and a warning message is printed whenever accessed to. This is wrong. They should act as multiplexers to all the tiles. Needs to be fixed before merging. > > The > > deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2 > > flag in order to be generated. > > CONFIG_SYSFS_DEPRECATED_V2 idea was abandoned, no? This patch at least > does not appear to contain it so please update the commit message to > reflect current state. > > Adding Joonas to help address the question of how strict are userspace > requirements for sysfs additions. Personally sysadmin use sounds fine to > me, although it needs to be mentioned/documented as Matt requested, but > I fear it may not be enough to upstream. Is Level0 at the stage where we > can upstream for it I am also not sure. Sysadmin usage is fine for the simple interfaces that can truly be used from the command line. This patch seems to just expose the existing interface in per-tile manner, so should not be a concern. However, the controls not under gt directories, need to be converted to apply to all tiles. (I've definitely given that feedback multiple times). Otherwise it will be very unexpected to the end user when what previously applied to whole device would only apply to part of it. Regards, Joonas > > While I am here I also left some nits below (not full review). > > > > > The new sysfs structure will have a similar layout for the 4 tile > > case: > > > > /sys/.../card0 > > \u251c\u2500\u2500 gt > > \u2502 \u251c\u2500\u2500 gt0 > > \u2502 \u2502 \u251c\u2500\u2500 id > > \u2502 \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > >. . > >. . > >. . > > \u2502 \u2514\u2500\u2500 gt3 > > \u2502 \u251c\u2500\u2500 id > > \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > > \u251c\u2500\u2500 gt_act_freq_mhz -+ > > \u251c\u2500\u2500 gt_boost_freq_mhz | > > \u251c\u2500\u2500 gt_cur_freq_mhz|Original interface > > \u251c\u2500\u2500 gt_max_freq_mhz+\u2500-> kept as existing > > ABI; > > \u251c\u2500\u2500 gt_min_freq_mhz|it points to gt0/ > > \u251c\u2500\u2500 gt_RP0_freq_mhz| > > \u2514\u2500\u2500 gt_RP1_freq_mhz| > > \u2514\u2500\u2500 gt_RPn_freq_mhz -+ > > > > As soon as multitile platforms will start being supported, this > > interface will allow to control the power (either manually or > > with tools) on each tile, instead of affecting only tile 0 and > > getting incomplete results. > > > > Signed-off-by: Andi Shyti > > Signed-off-by: Lucas De Marchi > > Cc: Matt Roper > > Cc: Sujaritha Sundaresan > > Cc: Tvrtko Ursulin > > Reviewed-by: Sujaritha Sundaresan > > --- > > drivers/gpu/drm/i915/Makefile | 4 +- > > drivers/gpu/drm/i915/gt/intel_gt.c| 2 + > > drivers/gpu/drm/i915/gt/sysfs_gt.c| 126 + > > drivers/gpu/drm/i915/gt/sysfs_gt.h| 44 +++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 393 ++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++ > > drivers/gpu/drm/i915/i915_drv.h | 2 + > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > drivers/gpu/drm/i915/i915
Re: linux-next: build warning after merge of the drm tree
Quoting Stephen Rothwell (2021-10-27 23:51:55) > Hi Joonas, > > On Wed, 27 Oct 2021 15:12:44 +0300 Joonas Lahtinen > wrote: > > > > We should be now good to go and add drm-intel-gt-next to linux-next. > > > > The branch would be as follows: > > > > drm-intel-gt-next git://anongit.freedesktop.org/drm-intel > > for-linux-next-gt > > > > Notice the "-gt" and the end of the for-linux-next branch name. This should > > eliminate > > the gap we have been having. > > I have added it to linux-next from today. Thanks! > I called it just > "drm-intel-gt" for consistency with the other drm trees in linux-next. We use the drm-intel-gt-next as the branch name in repo and DIM tolling, so if we are after consistenty consistency, using the full name probably makes sense. drm-intel-gt-next for name keeps open the option for separating the drm-intel-gt-fixes too, if we decide to do so in the future. > Currently I just have you listed as a contact, is there anyone else (or > a list) that I should add? Please do add Tvrtko (Cc'd). I guess it might make sense adding Jani and Rodrigo too, as backups. Similarly Tvrtko could be added to the other drm-intel-* trees. Doesn't hurt to have more eyes especially if some folks are on a vacation. Regards, Joonas > Thanks for adding your subsystem tree as a participant of linux-next. As > you may know, this is not a judgement of your code. The purpose of > linux-next is for integration testing and to lower the impact of > conflicts between subsystems in the next merge window. > > You will need to ensure that the patches/commits in your tree/series have > been: > * submitted under GPL v2 (or later) and include the Contributor's > Signed-off-by, > * posted to the relevant mailing list, > * reviewed by you (or another maintainer of your subsystem tree), > * successfully unit tested, and > * destined for the current or next Linux merge window. > > Basically, this should be just what you would send to Linus (or ask him > to fetch). It is allowed to be rebased if you deem it necessary. > > -- > Cheers, > Stephen Rothwell > s...@canb.auug.org.au > > -- > Cheers, > Stephen Rothwell
Re: linux-next: manual merge of the drm tree with Linus' tree
Quoting Stephen Rothwell (2021-10-29 03:48:40)
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_trace.h
>
> between commit:
>
> 9a4aa3a2f160 ("drm/i915: Revert 'guc_id' from i915_request tracepoint")
>
> from Linus' tree and commit:
>
> 3cb3e3434b9f ("drm/i915/guc: Move fields protected by guc->contexts_lock
> into sub structure")
>
> from the drm tree.
>
> I fixed it up (I used the former version) and can carry the fix as
> necessary.
The resolution for the conflict is to drop the guc_id field completely
in linux-next.
Regards, Joonas
> 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
Re: [PATCH 02/29] drm/i915/gvt: integrate into the main Makefile
Quoting Christoph Hellwig (2021-11-02 09:05:34) > Remove the separately included Makefile and just use the relative > reference from the main i915 Makefile as for source files in other > subdirectories. The thinking behind the split is to avoid any merge conflicts as the gvt/ subdirectory is handled through separate pull request flow and are note part of drm-tip. The other subdirectories are part of drm-intel-next/drm-intel-gt-next and are part of drm-tip. So I would rather still see the Makefile live in gvt/ directory. Regards, Joonas > Signed-off-by: Christoph Hellwig > --- > drivers/gpu/drm/i915/Makefile | 29 - > drivers/gpu/drm/i915/gvt/Makefile | 9 - > drivers/gpu/drm/i915/gvt/trace.h | 2 +- > 3 files changed, 25 insertions(+), 15 deletions(-) > delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 335ba9f43d8f7..63523032eea26 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -295,11 +295,30 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \ > > # virtual gpu code > i915-y += i915_vgpu.o > - > -ifeq ($(CONFIG_DRM_I915_GVT),y) > -i915-y += intel_gvt.o > -include $(src)/gvt/Makefile > -endif > +i915-$(CONFIG_DRM_I915_GVT) += \ > + intel_gvt.o \ > + gvt/gvt.o \ > + gvt/aperture_gm.o \ > + gvt/handlers.o \ > + gvt/vgpu.o \ > + gvt/trace_points.o \ > + gvt/firmware.o \ > + gvt/interrupt.o \ > + gvt/gtt.o \ > + gvt/cfg_space.o \ > + gvt/opregion.o \ > + gvt/mmio.o \ > + gvt/display.o \ > + gvt/edid.o \ > + gvt/execlist.o \ > + gvt/scheduler.o \ > + gvt/sched_policy.o \ > + gvt/mmio_context.o \ > + gvt/cmd_parser.o \ > + gvt/debugfs.o \ > + gvt/fb_decoder.o \ > + gvt/dmabuf.o \ > + gvt/page_track.o > > obj-$(CONFIG_DRM_I915) += i915.o > obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o > diff --git a/drivers/gpu/drm/i915/gvt/Makefile > b/drivers/gpu/drm/i915/gvt/Makefile > deleted file mode 100644 > index ea8324abc784a..0 > --- a/drivers/gpu/drm/i915/gvt/Makefile > +++ /dev/null > @@ -1,9 +0,0 @@ > -# SPDX-License-Identifier: GPL-2.0 > -GVT_DIR := gvt > -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o > firmware.o \ > - interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \ > - execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o > debugfs.o \ > - fb_decoder.o dmabuf.o page_track.o > - > -ccflags-y += -I $(srctree)/$(src) -I > $(srctree)/$(src)/$(GVT_DIR)/ > -i915-y += $(addprefix $(GVT_DIR)/, > $(GVT_SOURCE)) > diff --git a/drivers/gpu/drm/i915/gvt/trace.h > b/drivers/gpu/drm/i915/gvt/trace.h > index 6d787750d279f..348f57f8301db 100644 > --- a/drivers/gpu/drm/i915/gvt/trace.h > +++ b/drivers/gpu/drm/i915/gvt/trace.h > @@ -379,5 +379,5 @@ TRACE_EVENT(render_mmio, > #undef TRACE_INCLUDE_PATH > #define TRACE_INCLUDE_PATH . > #undef TRACE_INCLUDE_FILE > -#define TRACE_INCLUDE_FILE trace > +#define TRACE_INCLUDE_FILE gvt/trace > #include > -- > 2.30.2 >
Re: [PATCH 06/29] drm/i915/gvt: move the gvt code into kvmgt.ko
+ Thomas, Maarten and Matt (Also, Zhi and Zhenyu, please see down) Quoting Christoph Hellwig (2021-11-02 09:05:38) > Instead of having an option to build the gvt code into the main i915 > module, just move it into the kvmgt.ko module. This only requires > a new struct with three entries that the KVMGT modules needs to register > with the main i915 module, and a proper list of GVT-enabled devices > instead of global device pointer. > > Signed-off-by: Christoph Hellwig > +/* > + * Exported here so that the exports only get created when GVT support is > + * actually enabled. > + */ > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_alloc, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_create_shmem, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_init, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_ggtt_pin_ww, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_pin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_object_set_to_cpu_domain, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_flush_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_set_pages, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_gtt_insert, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_prime_export, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_init, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_backoff, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_fini, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_ppgtt_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_add, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_request_wait, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_reserve_fence, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_unreserve_fence, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_vm_release, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(i915_vma_move_to_active, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_context_create, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_put, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(shmem_pin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(shmem_unpin_map, I915_GVT); > +EXPORT_SYMBOL_NS_GPL(__px_dma, I915_GVT); This is where the module conversion got stuck last time. Conditionally exporting is kind of a partial remedy. Previously the intention for the rewrite was to define a clear interface between the two modules which would be well defined enough that we could avoid frequent clashes and hopefully get GVT into drm-tip, too. The absolute minimum requirement is not to have any of the double underscore symbols in this list. As that convention is specifically used to mark functions which are expected to have reduced error checking because of the exact point they are being called from. With that done we should be where we can enable the exports by default and modprobe would be all that is required. I think Zhenyu and Zhi took an AR back in time to see how small they could shrink this list. Would we have some followup patches available to shrink this interface? Also, the golden MMIO state capture remains something that leaks the hypervisor state into the guests. For example the fact which bug W/A are applied in hypervisor, and I would rather have that code path isolated before enabling by default. Regards, Joonas
Re: refactor the i915 GVT support and move to the modern mdev API v2
Hi Zhenyu and Zhi, Can you have somebody from the GVT team to review the patches that are fully contained in gvt/ ? I also started discussion on patch 6 which is about defining the interface between the modules. I remember there is prior work to shrink the interface. Do you have links to such patches? The minimal we should do is to eliminate the double underscore prefixed functions. But I would prefer to have the symbol exports by default so that we can enable the functionality just by loading the module. Regards, Joonas Quoting Christoph Hellwig (2021-11-02 09:05:32) > Hi all, > > the GVT code in the i915 is a bit of a mess right now due to strange > abstractions and lots of indirect calls. This series refactors various > bits to clean that up. The main user visible change is that almost all > of the GVT code moves out of the main i915 driver and into the kvmgt > module. > > Tested on my Thinkpad with a Kaby Lake CPU and integrated graphics. > > Git tree: > > git://git.infradead.org/users/hch/misc.git i915-gvt > > Gitweb: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-gvt > > Changes since v1: > - rebased on Linux 5.15 > - allow the kvmgvt module to be loaded at any time and thus solve >the deadlock when both i915 amd kvmgvt are modular > - include the conversion to the modern mdev API > > Note that I do expect to rebased this again against 5.16-rc1 once > released, but I'd like to get this out for review ASAP. > > Diffstat: > b/drivers/gpu/drm/i915/Kconfig | 33 > b/drivers/gpu/drm/i915/Makefile | 31 > b/drivers/gpu/drm/i915/gvt/cfg_space.c | 89 -- > b/drivers/gpu/drm/i915/gvt/cmd_parser.c |4 > b/drivers/gpu/drm/i915/gvt/dmabuf.c | 36 - > b/drivers/gpu/drm/i915/gvt/execlist.c | 12 > b/drivers/gpu/drm/i915/gvt/gtt.c| 55 + > b/drivers/gpu/drm/i915/gvt/gvt.h| 125 ++- > b/drivers/gpu/drm/i915/gvt/interrupt.c | 38 + > b/drivers/gpu/drm/i915/gvt/kvmgt.c | 1099 > +++- > b/drivers/gpu/drm/i915/gvt/mmio.c |4 > b/drivers/gpu/drm/i915/gvt/opregion.c | 148 > b/drivers/gpu/drm/i915/gvt/page_track.c |8 > b/drivers/gpu/drm/i915/gvt/scheduler.c | 37 - > b/drivers/gpu/drm/i915/gvt/trace.h |2 > b/drivers/gpu/drm/i915/gvt/vgpu.c | 22 > b/drivers/gpu/drm/i915/i915_drv.c |7 > b/drivers/gpu/drm/i915/i915_drv.h |1 > b/drivers/gpu/drm/i915/i915_trace.h |1 > b/drivers/gpu/drm/i915/intel_gvt.c | 162 +++- > b/drivers/gpu/drm/i915/intel_gvt.h | 17 > drivers/gpu/drm/i915/gvt/Makefile |9 > drivers/gpu/drm/i915/gvt/gvt.c | 340 - > drivers/gpu/drm/i915/gvt/hypercall.h| 82 -- > drivers/gpu/drm/i915/gvt/mpt.h | 400 --- > 25 files changed, 929 insertions(+), 1833 deletions(-)
Re: refactor the i915 GVT support and move to the modern mdev API v2
Quoting Christoph Hellwig (2021-11-09 09:59:57) > On Thu, Nov 04, 2021 at 02:59:18PM +0200, Joonas Lahtinen wrote: > > The minimal we should do is to eliminate the double underscore > > prefixed functions. But I would prefer to have the symbol exports by > > default so that we can enable the functionality just by loading the > > module. > > I'm fine with exporting by default, but just loading won't really work > even with that: > > - there are a bunch of IS_ENABLED conditionals in the i915 (although >they look like minor optimizations to me). I'd assume the golden state capture being the one with biggest impact. > - the enable_gvt needs to be set, although after this refactor this >option is completely pointless and should probably be enabled Indeed. Hope is that modprobe/rmmod would be enough to enable/disable. This should help any distros intending to enable the feature, too. So mostly about making sure the IS_ENABLED portions in base i915 operation are not too invasive. > - the enable_guc option needs to be disable for gvt to work. On the GVT supported platforms GuC is disabled by default, so it should be fine. We can change the logic to opposite to disable the feature if the enable_guc unsafe modparam is used. Regards, Joonas
Re: [PATCH] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()
(Switching to my @linux.intel.com address)
Quoting Christian König (2021-11-29 14:55:37)
> Am 29.11.21 um 13:46 schrieb Thomas Hellström:
> > On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
> >> Am 29.11.21 um 13:23 schrieb Thomas Hellström:
> >>> Hi, Christian,
> >>>
> >>> On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
> Am 29.11.21 um 08:35 schrieb Thomas Hellström:
> > If a dma_fence_array is reported signaled by a call to
> > dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
> >
> > Fix this by clearing the PENDING_ERROR status if we return true
> > in
> > dma_fence_array_signaled().
> >
> > Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-
> > array container")
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: Christian König
> > Cc: Chris Wilson
> > Signed-off-by: Thomas Hellström
> >
> Reviewed-by: Christian König
> >>> How are the dma-buf / dma-fence patches typically merged? If i915
> >>> is
> >>> the only fence->error user, could we take this through drm-intel to
> >>> avoid a backmerge for upcoming i915 work?
> >> Well that one here looks like a bugfix to me, so either through
> >> drm-misc-fixes ore some i915 -fixes branch sounds fine to me.
> >>
> >> If you have any new development based on that a backmerge of the -
> >> fixes
> >> into your -next branch is unavoidable anyway.
> > Ok, I'll check with Joonas if I can take it through
> > drm-intel-gt-next, since fixes are cherry-picked from that one. Patch
> > will then appear in both the -fixes and the -next branch.
>
> Well exactly that's the stuff Daniel told me to avoid :)
>
> But maybe your i915 workflow is somehow better handling that than the
> AMD workflow.
If it's a bugfix to a patch that merged through drm-misc-next, I'd
always be inclined to merge the fixup using the same process (which
would be drm-next-fixes).
In i915 we do always merge the patches to -next first, and never do a
backmerge of -fixes (as it's a cherry-picked branch) so the workflows
differ there.
Here the time between the fixup and the previous patch is so long that
either way is fine with. So feel free to apply to drm-intel-gt-next.
Regards, Joonas
> Christian.
>
> >
> > Thanks,
> > /Thomas
> >
> >
> >> Regards,
> >> Christian.
> >>
> >>> /Thomas
> >>>
> >>>
> > ---
> > drivers/dma-buf/dma-fence-array.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-
> > buf/dma-fence-array.c
> > index d3fbd950be94..3e07f961e2f3 100644
> > --- a/drivers/dma-buf/dma-fence-array.c
> > +++ b/drivers/dma-buf/dma-fence-array.c
> > @@ -104,7 +104,11 @@ static bool
> > dma_fence_array_signaled(struct
> > dma_fence *fence)
> > {
> > struct dma_fence_array *array =
> > to_dma_fence_array(fence);
> >
> > - return atomic_read(&array->num_pending) <= 0;
> > + if (atomic_read(&array->num_pending) > 0)
> > + return false;
> > +
> > + dma_fence_array_clear_pending_error(array);
> > + return true;
> > }
> >
> > static void dma_fence_array_release(struct dma_fence *fence)
> >
>
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, A quick fix to unbreak media driver, worthy inclusion before the merge window. Best Regards, Joonas *** drm-intel-next-fixes-2019-05-02: - Whitelist a register to avoid media driver from hanging The following changes since commit 879a4e70f96a26a9368a3caed2f552aa67105852: drm/i915: Fix ICL output CSC programming (2019-04-29 09:49:21 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-05-02 for you to fetch changes up to 9628e15ca9d5f7595ba886173e98a139d0a56cd1: drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 +0300) - Whitelist a register to avoid media driver from hanging Tvrtko Ursulin (1): drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 drivers/gpu/drm/i915/intel_workarounds.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm-tip:drm-tip 5/8] drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 'i915_request_await_start'
This was caused by a silent merge conflict, and is now fixed.
Regards, Joonas
Quoting kbuild test robot (2019-05-07 13:53:48)
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 73db4ec12f05160528884c0b2c845b1c6b7c6718
> commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Merge remote-tracking
> branch 'drm-intel/drm-intel-next-queued' into drm-tip
> config: x86_64-rhel (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout b9a2acf7709f52c77dc752ec99e3873e392d8df6
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>):
>
> >> drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of
> >> 'i915_request_await_start'
> i915_request_await_start(struct i915_request *rq, struct i915_request
> *signal)
> ^~~~
>drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of
> 'i915_request_await_start' was here
> i915_request_await_start(struct i915_request *rq, struct i915_request
> *signal)
> ^~~~
>drivers/gpu/drm/i915/i915_request.c:794:1: warning:
> 'i915_request_await_start' defined but not used [-Wunused-function]
>
> vim +/i915_request_await_start +827 drivers/gpu/drm/i915/i915_request.c
>
> ca6e56f65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04
> 825
> a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson 2016-09-09
> 826 static int
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> @827 i915_request_await_start(struct i915_request *rq, struct i915_request
> *signal)
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 828 {
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 829 if (list_is_first(&signal->ring_link,
> &signal->ring->request_list))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 830 return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 831
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 832 signal = list_prev_entry(signal, ring_link);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 833 if (i915_timeline_sync_is_later(rq->timeline, &signal->fence))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 834 return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 835
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 836 return i915_sw_fence_await_dma_fence(&rq->submit,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 837 &signal->fence, 0,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 838 I915_FENCE_GFP);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 839 }
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01
> 840
>
> :: The code at line 827 was first introduced by commit
> :: e766fde6511e2be83acbca1d603035e08de23f3b drm/i915: Delay semaphore
> submission until the start of the signaler
>
> :: TO: Chris Wilson
> :: CC: Joonas Lahtinen
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm-tip:drm-tip /8] drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 'already_busywaiting'
This too was caused by a merge conflict and one missing Fixes:.
Regards, Joonas
Quoting kbuild test robot (2019-05-07 14:08:25)
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
> commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Merge remote-tracking
> branch 'drm-intel/drm-intel-next-queued' into drm-tip
> config: x86_64-rhel (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout 47f4a14297839cb4cedd725fb916a5da5eb9b5ba
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> Note: the drm-tip/drm-tip HEAD ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
> builds fine.
> It only hurts bisectibility.
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of
> 'i915_request_await_start'
> i915_request_await_start(struct i915_request *rq, struct i915_request
> *signal)
> ^~~~
>drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of
> 'i915_request_await_start' was here
> i915_request_await_start(struct i915_request *rq, struct i915_request
> *signal)
> ^~~~
> >> drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of
> >> 'already_busywaiting'
> already_busywaiting(struct i915_request *rq)
> ^~~
>drivers/gpu/drm/i915/i915_request.c:809:1: note: previous definition of
> 'already_busywaiting' was here
> already_busywaiting(struct i915_request *rq)
> ^~~
>drivers/gpu/drm/i915/i915_request.c:809:1: warning: 'already_busywaiting'
> defined but not used [-Wunused-function]
>drivers/gpu/drm/i915/i915_request.c:794:1: warning:
> 'i915_request_await_start' defined but not used [-Wunused-function]
> i915_request_await_start(struct i915_request *rq, struct i915_request
> *signal)
> ^~~~
>
> vim +/already_busywaiting +842 drivers/gpu/drm/i915/i915_request.c
>
> 47f4a1429 drivers/gpu/drm/i915/i915_request.c Joonas Lahtinen 2019-05-07
> 825
> a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson2016-09-09
> 826 static int
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> @827 i915_request_await_start(struct i915_request *rq, struct i915_request
> *signal)
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 828 {
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 829 if (list_is_first(&signal->ring_link, &signal->ring->request_list))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 830 return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 831
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 832 signal = list_prev_entry(signal, ring_link);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 833 if (i915_timeline_sync_is_later(rq->timeline, &signal->fence))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 834 return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 835
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 836 return i915_sw_fence_await_dma_fence(&rq->submit,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 837&signal->fence, 0,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 838I915_FENCE_GFP);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 839 }
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01
> 840
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
> 841 static intel_engine_mask_t
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
> @842 already_busywaiting(struct i915_request *rq)
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
> 843 {
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
> 844 /*
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04
> 845
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Still rather quiet, most issues seem to have been fixed during CI testing. For i915, just two fixes to the request semaphore ordering code. For GVT a couple regression and static checker fixes. Best Regards, Joonas *** drm-intel-next-fixes-2019-05-09: - Two fixes for the freshly enabled semaphore ordering code - Includes gvt-next-fixes-2019-05-07 The following changes since commit 9628e15ca9d5f7595ba886173e98a139d0a56cd1: drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-05-09 for you to fetch changes up to 23372cce8fe7ee98a6458fd3d035a55b87f0c6fe: Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2019-05-07 15:29:15 +0300) - Two fixes for the freshly enabled semaphore ordering code - Includes gvt-next-fixes-2019-05-07 Aleksei Gimbitskii (4): drm/i915/gvt: Remove typedef and let the enumeration starts from zero drm/i915/gvt: Do not copy the uninitialized pointer from fb_info drm/i915/gvt: Use snprintf() to prevent possible buffer overflow. drm/i915/gvt: Check if get_next_pt_type() always returns a valid value Chris Wilson (2): drm/i915: Delay semaphore submission until the start of the signaler drm/i915: Disable semaphore busywaits on saturated systems Colin Xu (1): drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list Joonas Lahtinen (1): Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Xiong Zhang (1): drm/i915/gvt: Change fb_info->size from pages to bytes Zhao Yakui (1): drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 MCHBAR to optimize gvt-g boot time" drivers/gpu/drm/i915/gvt/debugfs.c | 4 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 19 -- drivers/gpu/drm/i915/gvt/gtt.c | 15 +--- drivers/gpu/drm/i915/gvt/gtt.h | 16 drivers/gpu/drm/i915/gvt/handlers.c| 4 +- drivers/gpu/drm/i915/gvt/mmio_context.c| 1 + drivers/gpu/drm/i915/gvt/reg.h | 3 -- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_request.c| 59 +- drivers/gpu/drm/i915/intel_context.c | 1 + drivers/gpu/drm/i915/intel_context_types.h | 3 ++ 11 files changed, 93 insertions(+), 34 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, A fix to close a race opportunity between IRQ handler and RCU. Two fixes that are also stable, disabling FBC on GLK and HSW EDP fastset correction. These patches definitely caused conflicts when merged, resolutions should be all good. Regards, Joonas *** drm-intel-next-fixes-2019-05-15: - Disable framebuffer compression on Geminilake - Fixes for HSW EDP fastset and a IRQ handler vs. RCU race The following changes since commit 23372cce8fe7ee98a6458fd3d035a55b87f0c6fe: Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2019-05-07 15:29:15 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-05-15 for you to fetch changes up to c36beba6b296b3c05a0f29753b04775e5ae23886: drm/i915: Seal races between async GPU cancellation, retirement and signaling (2019-05-13 13:53:35 +0300) - Disable framebuffer compression on Geminilake - Fixes for HSW EDP fastset and a IRQ handler vs. RCU race Chris Wilson (1): drm/i915: Seal races between async GPU cancellation, retirement and signaling Daniel Drake (1): drm/i915/fbc: disable framebuffer compression on GeminiLake Ville Syrjälä (1): drm/i915: Fix fastset vs. pfit on/off on HSW EDP transcoder drivers/dma-buf/dma-fence.c | 1 + drivers/gpu/drm/i915/i915_request.c | 1 + drivers/gpu/drm/i915/intel_breadcrumbs.c| 78 + drivers/gpu/drm/i915/intel_display.c| 9 drivers/gpu/drm/i915/intel_fbc.c| 4 ++ drivers/gpu/drm/i915/intel_guc_submission.c | 1 - drivers/gpu/drm/i915/intel_pipe_crc.c | 13 +++-- 7 files changed, 82 insertions(+), 25 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Fixes tag needs some work in the drm-intel tree
Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
>
> In commit
>
> 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
> signaler")
>
> Fixes tag
>
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
>
> has these problem(s):
>
> - Subject has leading but no trailing parentheses
> - Subject has leading but no trailing quotes
>
> Please don't split Fixes tags across more than one line.
Thanks for the report.
This was a copy'n paste mishap, detected by our tooling (and fixed by
me) at the time of creating a PR. Unfortunately the check was not being
enforced by tooling at commit time. We'll fix that.
Regards, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Comments in Fixes: line (Was: Re: linux-next: Fixes tag needs some work in the drm-intel tree)
We also have an incoming patch where the Fixes: line has a comment in it. Does your tooling account for this when checking the Fixes: line? Regards, Joonas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, Two scheduling fixes for to oversaturated (media transcoding scenarios) and their dependencies. On GVT side a reset robustness fix and context state restoring fix + error path fix caught by static checker. Regards, Joonas PS. As you are aware, -rc1 caused an explosion on the CI due to the ext4 regression, which in turn let other regressions creep in momentarily. Now there is huge backlog, so the CI results are interpreted from multiple runs. I have a good confidence on the PR, so decided to send anyway. *** drm-intel-fixes-2019-05-23: - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-05-23 for you to fetch changes up to 57cb853d1d5b07ed4e4647ad61b0c16a9c21996e: Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes (2019-05-21 14:37:38 +0300) - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 Chris Wilson (5): drm/i915: Rearrange i915_scheduler.c drm/i915: Pass i915_sched_node around internally drm/i915: Bump signaler priority on adding a waiter drm/i915: Downgrade NEWCLIENT to non-preemptive drm/i915: Truly bump ready tasks ahead of busywaits Dan Carpenter (1): drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry() Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Weinan (1): drm/i915/gvt: emit init breadcrumb for gvt request Yan Zhao (4): drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+ drm/i915/gvt: add 0x4dfc to gen9 save-restore list drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware drivers/gpu/drm/i915/gvt/cmd_parser.c | 14 +- drivers/gpu/drm/i915/gvt/gtt.c | 4 +- drivers/gpu/drm/i915/gvt/handlers.c | 15 -- drivers/gpu/drm/i915/gvt/mmio_context.c | 23 ++- drivers/gpu/drm/i915/gvt/scheduler.c| 23 ++- drivers/gpu/drm/i915/i915_priolist_types.h | 5 +- drivers/gpu/drm/i915/i915_request.c | 42 ++--- drivers/gpu/drm/i915/i915_scheduler.c | 255 +++- drivers/gpu/drm/i915/i915_scheduler_types.h | 3 +- drivers/gpu/drm/i915/intel_lrc.c| 2 +- drivers/gpu/drm/i915/selftests/intel_lrc.c | 12 +- 11 files changed, 202 insertions(+), 196 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
l_frontbuffer.h self-contained
drm/i915: extract intel_audio.h from intel_drv.h
drm/i915: extract intel_crt.h from intel_drv.h
drm/i915: extract intel_ddi.h from intel_drv.h
drm/i915: extract intel_connector.h from intel_drv.h
drm/i915: extract intel_csr.h from intel_drv.h
drm/i915: extract intel_fbc.h from intel_drv.h
drm/i915: extract intel_psr.h from intel_drv.h
drm/i915: extract intel_color.h from intel_drv.h
drm/i915: extract intel_lspcon.h from intel_drv.h
drm/i915: extract intel_sdvo.h from intel_drv.h
drm/i915: extract intel_hdcp.h from intel_drv.h
drm/i915: extract intel_panel.h from intel_drv.h
drm/i915: extract intel_pm.h from intel_drv.h
drm/i915: extract intel_fbdev.h from intel_drv.h
drm/i915: extract intel_dp.h from intel_drv.h
drm/i915: extract intel_hdmi.h from intel_drv.h
drm/i915: extract intel_atomic_plane.h from intel_drv.h
drm/i915: extract intel_pipe_crc.h from intel_drv.h
drm/i915: extract intel_tv.h from intel_drv.h
drm/i915: extract intel_lvds.h from intel_drv.h
drm/i915: extract intel_dvo.h from intel_drv.h
drm/i915: extract intel_sprite.h from intel_drv.h
drm/i915: extract intel_cdclk.h from intel_drv.h
drm/i915/cdclk: have only one init/uninit function
drm/i915/dp: revert back to max link rate and lane count on eDP
drm/i915/ehl: inherit icl cdclk init/uninit
Janusz Krzysztofik (1):
drm/i915: Mark GEM wedged right after marking device unplugged
Joonas Lahtinen (3):
drm/i915: Update DRIVER_DATE to 20190404
Merge tag 'gvt-next-2019-04-16' of https://github.com/intel/gvt-linux
into drm-intel-next-queued
drm/i915: Update DRIVER_DATE to 20190417
José Roberto de Souza (4):
drm/i915/psr: Update PSR2 SU corruption workaround comment
drm/i915: Remove unused VLV/CHV PSR registers
drm/i915/psr: Initialize PSR mutex even when sink is not reliable
drm/i915/psr: Do not enable PSR in interlaced mode for all GENs
Manasi Navare (2):
drm/i915/dp: Expose force_dsc_enable through debugfs
drm/i915: Nuke drm_crtc_state and use intel_atomic_state instead
Mika Kuoppala (12):
drm/i915/icl: Handle rps interrupts without irq lock
drm/i915/icl: Don't warn on spurious interrupts
drm/i915: Use dedicated rc6 enabling sequence for gen11
drm/i915/icl: Apply a recommended rc6 threshold
drm/i915/icl: Enable media sampler powergate
drm/i915/icl: Disable video turbo mode for rp control
drm/i915: Use Engine1 instance for gen11 pm interrupts
drm/i915: Prepare for larger CSB status FIFO size
drm/i915/icl: Switch to using 12 deep CSB status FIFO
drm/i915: Disable read only ppgtt support for gen11
drm/i915: Shortcut readiness to reset check
drm/i915: Handle catastrophic error on engine reset
Paulo Zanoni (5):
drm/i915: refactor the IRQ init/reset macros
drm/i915: don't specify the IRQ register in the gen2 macros
drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
drm/i915: convert the IRQ initialization functions to intel_uncore
drm/i915: fully convert the IRQ initialization macros to intel_uncore
Radhakrishna Sripada (2):
drm/i915: Rename skl_wa_clkgating to the actual WA
drm/i915: Fix the inconsistent RMW in WA 827
Robert M. Fosha (1):
drm/i915/guc: Retry GuC load for all load failures
Rodrigo Vivi (1):
x86/gpu: add ElkhartLake to gen11 early quirks
Takashi Iwai (1):
ALSA: hda: Fix racy display power access
Tvrtko Ursulin (5):
drm/i915: Split Pineview device info into desktop and mobile
drm/i915: Remove redundant device id from IS_IRONLAKE_M macro
drm/i915: Split some PCI ids into separate groups
drm/i915: Introduce concept of a sub-platform
drm/i915: Fix uninitialized mask in intel_device_info_subplatform_init
Uma Shankar (2):
drm/i915: Fix GCMAX color register programming
drm/i915: Program EXT2 GC MAX registers
Vandita Kulkarni (2):
drm/i915/icl: Ungate ddi clocks before IO enable
drm/i915/icl: Fix port disable sequence for mipi-dsi
Ville Syrjälä (25):
drm/i915: Extract check_luts()
drm/i915: Turn intel_color_check() into a vfunc
drm/i915: Extract i9xx_color_check()
drm/i915: Extract chv_color_check()
drm/i915: Extract icl_color_check()
drm/i915: Extract glk_color_check()
drm/i915: Extract bdw_color_check()
drm/i915: Extract ilk_color_check()
drm/i915: Drop the pointless linear legacy LUT load on CHV
drm/i915: Skip the linear degamma LUT load on ICL+
drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
drm/i915: Skip modeset for cdclk changes if possible
drm/i915: Extract ilk_lut_10()
drm/i915: Don't use split gamma when we don't have to
drm/i915: Implement split/10bit gamma
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Just one use-after-free fix and Icelake DP programming fix. Best Regards, Joonas *** drm-intel-next-fixes-2019-04-25: - Use after free fix during GEM_CREATE when reporting back object size - Icelake DP register programming order fix The following changes since commit 6ecac85eadb9d4065b9038fa3d3c66d49038e14b: drm/udl: move to embedding drm device inside udl device. (2019-04-24 13:48:45 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-04-25 for you to fetch changes up to 447811a686e8da7325516a78069ccfbd139ef1a7: drm/i915/icl: Fix MG_DP_MODE() register programming (2019-04-24 09:39:11 +0300) - Use after free fix during GEM_CREATE when reporting back object size - Icelake DP register programming order fix Chris Wilson (1): drm/i915: Avoid use-after-free in reporting create.size Imre Deak (1): drm/i915/icl: Fix MG_DP_MODE() register programming drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/intel_ddi.c | 18 -- 2 files changed, 9 insertions(+), 11 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Just one fix to fix Icelake CSC programming (fixes loss of blue channel). Best Regards, Joonas *** drm-intel-next-fixes-2019-04-30: - Fix to Icelake CSC losing blue channel The following changes since commit 447811a686e8da7325516a78069ccfbd139ef1a7: drm/i915/icl: Fix MG_DP_MODE() register programming (2019-04-24 09:39:11 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-04-30 for you to fetch changes up to 879a4e70f96a26a9368a3caed2f552aa67105852: drm/i915: Fix ICL output CSC programming (2019-04-29 09:49:21 +0300) - Fix to Icelake CSC losing blue channel Ville Syrjälä (1): drm/i915: Fix ICL output CSC programming drivers/gpu/drm/i915/intel_color.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
Quoting Joerg Roedel (2019-01-22 13:01:09) > Hi Daniel, > > On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote: > > Note that the string of platforms which have various issues with iommu > > and igfx is very long, thus far we only disabled it where there's no > > workaround to stop it from hanging the box, but otherwise left it > > enabled. So if we make a policy change to also disable it anywhere > > where it doesn't work well (instead of not at all), there's a pile > > more platforms to switch. > > I think its best to just disable iommu for the igfx devices on these > platforms. Can you pick up Eric's patch and extend it with the list of > affected platforms? We've been discussing this again more actively since a few months ago, and the discussion is still ongoing internally. According to our IOMMU folks there exists some desire to be able to assign the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off due to how the devices might be grouped in IOMMU groups. Even when you would not be using the iGFX device. So for some uses, the fact that the device (group) is assignable seems to be more important than the iGFX device to be working. I'm afraid that retroactively disabling the assignment for such an old platform might break those usage scenarios. By my quick reading of the code, there's no way for user to turn the iGFX DMAR on once the quirk disables it. I guess one solution would be to default to intel_iommu=igfx_off for platforms that are older than certain threshold. But still allow user to enable. But that then requires duplicating the PCI ID database into iommu code. I don't really have winning moves to present, but I'm open to hearing how we can avoid more damage than starting to default to intel_iommu=on did already. Regards, Joonas > > Thanks, > > Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
Quoting Joerg Roedel (2019-01-22 18:51:35) > On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote: > > According to our IOMMU folks there exists some desire to be able to assign > > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off > > due to how the devices might be grouped in IOMMU groups. Even when you > > would not be using the iGFX device. > > You can force the igfx device into a SI domain, or does that also > trigger the iommu issues on the chipset? To be honest, we've had a mixture different issues on different SKUs that have not been hit in the past when intel_iommu was just disabled by default. I know that in one group of the problems, the issue has been debugged into the GPU having its own set of virtualization mapping translation hardware with caching and it fails to track changes to the mapping. So if a identity mapping was established and never changed, I'd assume that to fix at least that class of problems. Would just passing intel_iommu=on already cause a non-identity mapping to possibly be used for the integrated GPU? If it did, then it would explain quite few of the issues. We have many reports where just having intel_iommu=on (and using the system normally, without any virtualization stuff going on) will cause unexplained GPU hangs. For those users, simply switching to intel_iommu=igfx_off solves the problems, and the debug often ends there. Regards, Joonas > In any case, if iommu=on breaks these systems I want to make them work > again with opt-out, even at the cost of breaking assignability. > > Regards, > > Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 8/9] gpu/drm/i915: optimize out the case when a range is updated to read only
Hi Jerome,
This patch seems to have plenty of Cc:s, but none of the right ones :)
For further iterations, I guess you could use git option --cc to make
sure everyone gets the whole series, and still keep the Cc:s in the
patches themselves relevant to subsystems.
This doesn't seem to be on top of drm-tip, but on top of your previous
patches(?) that I had some comments about. Could you take a moment to
first address the couple of question I had, before proceeding to discuss
what is built on top of that base.
My reply's Message-ID is:
154289518994.19402.3481838548028068...@jlahtine-desk.ger.corp.intel.com
Regards, Joonas
PS. Please keep me Cc:d in the following patches, I'm keen on
understanding the motive and benefits.
Quoting jgli...@redhat.com (2019-01-24 00:23:14)
> From: Jérôme Glisse
>
> When range of virtual address is updated read only and corresponding
> user ptr object are already read only it is pointless to do anything.
> Optimize this case out.
>
> Signed-off-by: Jérôme Glisse
> Cc: Christian König
> Cc: Jan Kara
> Cc: Felix Kuehling
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: Matthew Wilcox
> Cc: Ross Zwisler
> Cc: Dan Williams
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Michal Hocko
> Cc: Ralph Campbell
> Cc: John Hubbard
> Cc: k...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-r...@vger.kernel.org
> Cc: linux-fsde...@vger.kernel.org
> Cc: Arnd Bergmann
> ---
> drivers/gpu/drm/i915/i915_gem_userptr.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 9558582c105e..23330ac3d7ea 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -59,6 +59,7 @@ struct i915_mmu_object {
> struct interval_tree_node it;
> struct list_head link;
> struct work_struct work;
> + bool read_only;
> bool attached;
> };
>
> @@ -119,6 +120,7 @@ static int
> i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> container_of(_mn, struct i915_mmu_notifier, mn);
> struct i915_mmu_object *mo;
> struct interval_tree_node *it;
> + bool update_to_read_only;
> LIST_HEAD(cancelled);
> unsigned long end;
>
> @@ -128,6 +130,8 @@ static int
> i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> /* interval ranges are inclusive, but invalidate range is exclusive */
> end = range->end - 1;
>
> + update_to_read_only = mmu_notifier_range_update_to_read_only(range);
> +
> spin_lock(&mn->lock);
> it = interval_tree_iter_first(&mn->objects, range->start, end);
> while (it) {
> @@ -145,6 +149,17 @@ static int
> i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> * object if it is not in the process of being destroyed.
> */
> mo = container_of(it, struct i915_mmu_object, it);
> +
> + /*
> +* If it is already read only and we are updating to
> +* read only then we do not need to change anything.
> +* So save time and skip this one.
> +*/
> + if (update_to_read_only && mo->read_only) {
> + it = interval_tree_iter_next(it, range->start, end);
> + continue;
> + }
> +
> if (kref_get_unless_zero(&mo->obj->base.refcount))
> queue_work(mn->wq, &mo->work);
>
> @@ -270,6 +285,7 @@ i915_gem_userptr_init__mmu_notifier(struct
> drm_i915_gem_object *obj,
> mo->mn = mn;
> mo->obj = obj;
> mo->it.start = obj->userptr.ptr;
> + mo->read_only = i915_gem_object_is_readonly(obj);
> mo->it.last = obj->userptr.ptr + obj->base.size - 1;
> INIT_WORK(&mo->work, cancel_userptr);
>
> --
> 2.17.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 8/9] gpu/drm/i915: optimize out the case when a range is updated to read only
Quoting Jerome Glisse (2019-01-24 17:30:32)
> On Thu, Jan 24, 2019 at 02:09:12PM +0200, Joonas Lahtinen wrote:
> > Hi Jerome,
> >
> > This patch seems to have plenty of Cc:s, but none of the right ones :)
>
> So sorry, i am bad with git commands.
>
> > For further iterations, I guess you could use git option --cc to make
> > sure everyone gets the whole series, and still keep the Cc:s in the
> > patches themselves relevant to subsystems.
>
> Will do.
>
> > This doesn't seem to be on top of drm-tip, but on top of your previous
> > patches(?) that I had some comments about. Could you take a moment to
> > first address the couple of question I had, before proceeding to discuss
> > what is built on top of that base.
>
> It is on top of Linus tree so roughly ~ rc3 it does not depend on any
> of the previous patch i posted.
You actually managed to race a point in time just when Chris rewrote much
of the userptr code in drm-tip, which I didn't remember of. My bad.
Still interested to hearing replies to my questions in the previous
thread, if the series is still relevant. Trying to get my head around
how the different aspects of HMM pan out for devices without fault handling.
> I still intended to propose to remove
> GUP from i915 once i get around to implement the equivalent of GUP_fast
> for HMM and other bonus cookies with it.
>
> The plan is once i have all mm bits properly upstream then i can propose
> patches to individual driver against the proper driver tree ie following
> rules of each individual device driver sub-system and Cc only people
> there to avoid spamming the mm folks :)
Makes sense, as we're having tons of changes in this field in i915, the
churn to rebase on top of them will be substantial.
Regards, Joonas
PS. Are you by any chance attending FOSDEM? Would be nice to chat about
this.
>
>
> >
> > My reply's Message-ID is:
> > 154289518994.19402.3481838548028068...@jlahtine-desk.ger.corp.intel.com
> >
> > Regards, Joonas
> >
> > PS. Please keep me Cc:d in the following patches, I'm keen on
> > understanding the motive and benefits.
> >
> > Quoting jgli...@redhat.com (2019-01-24 00:23:14)
> > > From: Jérôme Glisse
> > >
> > > When range of virtual address is updated read only and corresponding
> > > user ptr object are already read only it is pointless to do anything.
> > > Optimize this case out.
> > >
> > > Signed-off-by: Jérôme Glisse
> > > Cc: Christian König
> > > Cc: Jan Kara
> > > Cc: Felix Kuehling
> > > Cc: Jason Gunthorpe
> > > Cc: Andrew Morton
> > > Cc: Matthew Wilcox
> > > Cc: Ross Zwisler
> > > Cc: Dan Williams
> > > Cc: Paolo Bonzini
> > > Cc: Radim Krčmář
> > > Cc: Michal Hocko
> > > Cc: Ralph Campbell
> > > Cc: John Hubbard
> > > Cc: k...@vger.kernel.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-r...@vger.kernel.org
> > > Cc: linux-fsde...@vger.kernel.org
> > > Cc: Arnd Bergmann
> > > ---
> > > drivers/gpu/drm/i915/i915_gem_userptr.c | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > index 9558582c105e..23330ac3d7ea 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > @@ -59,6 +59,7 @@ struct i915_mmu_object {
> > > struct interval_tree_node it;
> > > struct list_head link;
> > > struct work_struct work;
> > > + bool read_only;
> > > bool attached;
> > > };
> > >
> > > @@ -119,6 +120,7 @@ static int
> > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > struct i915_mmu_object *mo;
> > > struct interval_tree_node *it;
> > > + bool update_to_read_only;
> > > LIST_HEAD(cancelled);
> > > unsigned long end;
> > >
> > > @@ -128,6 +130,8 @@ static int
> > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > /* interval ranges are inclusive, but invalidate range is
> > > exclusive */
> > > end = range->end - 1;
> > >
> > > + update_to_read_only =
>
Re: [PULL] drm-intel-next
Quoting Dave Airlie (2019-02-04 07:02:07) > On Sat, 2 Feb 2019 at 18:29, Rodrigo Vivi wrote: > > > > Hi Dave and Daniel, > > > > Here goes another pull request for 5.1. > > dim complained: > > Chris committed this without an S-O-B, now because it's all Intel this > probably doesn't matter, so I'll pull it, put please try and let it > not happen again. It's a tooling issue. It even has the Link: tag, so it is applied with dim, which automatically should apply the S-o-b of committer. The issue should already have a fix. And we also concluded that as it's all Intel, it should be legally OK, and not worthy force pushing the history (as it was noticed rather late). But looks like the communication back to you fell short. Apologies for that. Regards, Joonas > Dave. > > commit 8e525cb4a622148fbe30134ee3a1a34ad839a43a > Author: Tvrtko Ursulin > Commit: Chris Wilson > > drm/i915/execlists: Move RPCS setup to context pin > > Configuring RPCS in context image just before pin is sufficient and will > come extra handy in one of the following patches. > > v2: > * Split image setup a bit differently. (Chris Wilson) > > v3: > * Update context image after reset as well - otherwise the application >of pinned default state clears the RPCS. > > v4: > * Use local variable throughout the function. (Chris Wilson) > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Chris Wilson > Cc: Chris Wilson > Reviewed-by: Chris Wilson > Reviewed-by: Joonas Lahtinen > Link: > https://patchwork.freedesktop.org/patch/msgid/20190125023005.1007-1-ch...@chris-wilson.co.uk > > > > > Maybe I will still send another next week. > > > > This pull also include a GVT one with: > > " > > Here is gvt-next stuff. This includes Coffeelake support for GVT, > > making kvmgt as self load module to have better dependence with > > vfio/mdev, with some const treatment and kernel type change. > > " > > > > And also it includes a drm change for constify drm_color_lut_check. > > > > Rest of details are on the tags below. > > > > drm-intel-next-2019-02-02: > > - Make background color and LUT more robust (Matt) > > - Icelake display fixes (Ville, Imre) > > - Workarounds fixes and reorg (Tvrtko, Talha) > > - Enable fastboot by default on VLV and CHV (Hans) > > - Add another PCI ID for Coffee Lake (Rodrigo) > > > > drm-intel-next-2019-01-29: > > - MOCS table rework for simplification and to add ICL (Lucas, Tomasz) > > - Move RPCS setup to context pin (Tvrtko) > > - Breadcrumb simplification and GPU Reset improvements (Chris) > > - Many fixes for TV modeset (Ville) > > - Clean up on atomic plane checks (Ville) > > - NV12 pich check fix (Raviraj) > > - Disable -Wuninitialized (Nathan) > > - Sanitize DPLL state for broken BIOSes on SNB (Ville) > > - Rework on vma locking and counting and introduce a concept of per-timeline > > HWSP (Chris) > > - Enable fastboot by default on Skylake and newer platforms (Hans) > > - Fix slk srckey mask bits (Ville) > > - Selftests fixes (Chris) > > - Execlists and preemption improvements and fixes (Chris) > > - drm consitify drm_color_lut_check (Ville) > > - Ice Lake clock fixes (Lucas) > > > > Thanks, > > Rodrigo. > > > > The following changes since commit 85baa5dbf79163026dcb78f742294c522e176432: > > > > drm/i915: Update DRIVER_DATE to 20190124 (2019-01-24 15:00:59 -0800) > > > > are available in the Git repository at: > > > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-02-02 > > > > for you to fetch changes up to 46c0cd8c562bc3e4a99cbaa4ba0904b6871b7b4b: > > > > drm/i915: Update DRIVER_DATE to 20190202 (2019-02-02 00:14:28 -0800) > > > > > > - Make background color and LUT more robust (Matt) > > - Icelake display fixes (Ville, Imre) > > - Workarounds fixes and reorg (Tvrtko, Talha) > > - Enable fastboot by default on VLV and CHV (Hans) > > - Add another PCI ID for Coffee Lake (Rodrigo) > > > > > > Chris Wilson (27): > > drm/i915: Measure the required reserved size for request emission > > drm/i915: Remove manual breadcumb counting > > drm/i915: Compute the HWS offsets explicitly > > drm/i915: Make all GPU resets atomic > > drm/i915/guc: Disable global reset > > drm/i915: Remove
Re: [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Quoting Joonas Lahtinen (2019-01-15 16:47:27) > Hi all, > > I would like to have some Acked-by's from you, the distro media > folks Cc'd here, to document your intent to start using Intel's > new media driver[1]. So if you recognize yourself (or are otherwise > interested), please read on. > > TL;DR Distro folks, please give your Acked-by on patch [5/6] A gentle reminder, I'm still looking to hear back from Stephane and Dave. We'd like to have this included in the final 5.1 drm-intel-next pull request this week. If there are no further comments by Wed, I will conclude that we have reached a silent agreement, and merge this to give enough time for Rodrigo to send the PR. Regards, Joonas > I believe most are already aware of the situation that Intel > is moving to the new codebase for libva backend to support new Intel > integrated graphics devices. The existing intel-libva-driver will > be continue to be be supported for pre-Icelake platforms ( Icelake and further platforms will only be supported from the > new codebase. > > There's the complication that some Icelake features of the new > driver will require new kernel uAPIs to work... But the new driver > has not yet been well-established in the community from perspective > of fulfilling [2]. This is very much due to the demand being low > as Icelake is not widely available yet. So it's bit of a chicken > and egg problem as we have a new platform *and* a new codebase for > it simultaneously. > > Ahead of that community adoption, to ensure that Icelake has good > kernel support from day one, we'd like to merge kernel support for > the parts that have functional effect (this series). This is to > avoid the scenario where end users have to update their distro > kernels, like happened with Skylake. > > So if I could get Acked-by's from distro folks on the patch [5/6] that > adds the new uAPI. That would document their intent to become an active > user of the media-driver[1]. If that happens in the next week or two, > it would mean that Icelake hardware features would be supported in > kernel version 5.1 fully from kernel driver point of view. > > The new uAPI is needed to make VME feature functionally work > on Icelake. It's pretty much a simple enable/disable switch for > hardware configuration that only includes hardware slices compatible > with the VME workload. So it's currently limited to the required on/off > choice to keep things straightforward. The uAPI can be extended in the > future for possible performance gains for more fine-grained control. > > VME is shared function to handle motion estimation. One intended > usercase is in Hierarchical Motion Estimation (HME) media kernel. It > provides a bigger search range with reduced cost for the search. HME > should improve the encode quality with scenarios where the video has > a lot of motion in it. Carl (Cc'd) can provide more details if needed. > > The respective IGT tests are reviewed and can be found at: > > https://patchwork.freedesktop.org/series/49190/ > > The userspace changes are reviewed and rebased here: > > https://github.com/intel/media-driver/pull/271 > https://github.com/intel/media-driver/pull/463 > > Best Regards, Joonas Lahtinen > > Cc: dri-devel@lists.freedesktop.org > Cc: Timo Aaltonen > Cc: Takashi Iwai > Cc: Stephane Marchesin > Cc: Dave Airlie > Cc: Daniel Vetter > > PS. This series might result in some CI failures reported as it adds new uAPI > and Patchwork / CI synchronization of tests and kernel is currently WIP. > > [1] https://github.com/intel/media-driver > [2] > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > Lionel Landwerlin (2): > drm/i915: Record the sseu configuration per-context & engine > drm/i915/perf: lock powergating configuration to default when active > > Tvrtko Ursulin (4): > drm/i915/execlists: Move RPCS setup to context pin > drm/i915: Add timeline barrier support > drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) > drm/i915/selftests: Context SSEU reconfiguration tests > > drivers/gpu/drm/i915/i915_drv.h | 14 + > drivers/gpu/drm/i915/i915_gem_context.c | 354 - > drivers/gpu/drm/i915/i915_gem_context.h | 10 + > drivers/gpu/drm/i915/i915_perf.c | 13 +- > drivers/gpu/drm/i915/i915_request.c | 13 + > drivers/gpu/drm/i915/i915_request.h | 10 + > drivers/gpu/drm/i915/i915_timeline.c | 3 + > drivers/gpu/drm/i915/i915_timeline.h | 27 + > drivers/gpu/drm/i915/intel_lrc.c
Re: [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Quoting Stéphane Marchesin (2019-02-05 06:16:48) > On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote: > > > Quoting Joonas Lahtinen (2019-01-15 16:47:27) > > > > Hi all, > > > > > > > > I would like to have some Acked-by's from you, the distro media > > > > folks Cc'd here, to document your intent to start using Intel's > > > > new media driver[1]. So if you recognize yourself (or are otherwise > > > > interested), please read on. > > > > > > > > TL;DR Distro folks, please give your Acked-by on patch [5/6] > > > > > > A gentle reminder, I'm still looking to hear back from Stephane > > > and Dave. > > > > > > We'd like to have this included in the final 5.1 drm-intel-next > > > pull request this week. > > > > > > If there are no further comments by Wed, I will conclude that we > > > have reached a silent agreement, and merge this to give enough > > > time for Rodrigo to send the PR. > > > > Maybe should add that ubunut/suse folks seem ok. Also, it's for libva, in > > the past that's been very far down the list of contentious topics. Mostly > > positive meh seems plenty good enough feedback I think. > > FWIW I think the API changes are fine. Sure it feels a bit odd at > first, but there's no better alternative that I can see either. > > Acked-by: Stéphane Marchesin > Dave commented on IRC that he's fine with us proceeding to merge with these Acks in place. Thank you all for looking into the matter, this will now find its way into Kernel version 5.1. Regards, Joonas > > > -Daniel > > > > > > > > Regards, Joonas > > > > > > > I believe most are already aware of the situation that Intel > > > > is moving to the new codebase for libva backend to support new Intel > > > > integrated graphics devices. The existing intel-libva-driver will > > > > be continue to be be supported for pre-Icelake platforms ( > > > Icelake and further platforms will only be supported from the > > > > new codebase. > > > > > > > > There's the complication that some Icelake features of the new > > > > driver will require new kernel uAPIs to work... But the new driver > > > > has not yet been well-established in the community from perspective > > > > of fulfilling [2]. This is very much due to the demand being low > > > > as Icelake is not widely available yet. So it's bit of a chicken > > > > and egg problem as we have a new platform *and* a new codebase for > > > > it simultaneously. > > > > > > > > Ahead of that community adoption, to ensure that Icelake has good > > > > kernel support from day one, we'd like to merge kernel support for > > > > the parts that have functional effect (this series). This is to > > > > avoid the scenario where end users have to update their distro > > > > kernels, like happened with Skylake. > > > > > > > > So if I could get Acked-by's from distro folks on the patch [5/6] that > > > > adds the new uAPI. That would document their intent to become an active > > > > user of the media-driver[1]. If that happens in the next week or two, > > > > it would mean that Icelake hardware features would be supported in > > > > kernel version 5.1 fully from kernel driver point of view. > > > > > > > > The new uAPI is needed to make VME feature functionally work > > > > on Icelake. It's pretty much a simple enable/disable switch for > > > > hardware configuration that only includes hardware slices compatible > > > > with the VME workload. So it's currently limited to the required on/off > > > > choice to keep things straightforward. The uAPI can be extended in the > > > > future for possible performance gains for more fine-grained control. > > > > > > > > VME is shared function to handle motion estimation. One intended > > > > usercase is in Hierarchical Motion Estimation (HME) media kernel. It > > > > provides a bigger search range with reduced cost for the search. HME > > > > should improve the encode quality with scenarios where the video has > > > > a lot of motion in it. Carl (Cc'd) can provide more details if needed. > > > > > > > > The respective IGT tests are reviewed and can
Re: iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip
Quoting Eric Wong (2018-12-27 13:49:48)
> I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> chipset) and hit some kernel panics while trying to view
> image/animation-intensive stuff in Firefox (X11) unless I use
> "iommu_intel=igfx_off".
>
> With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
> (4.17.17-1~bpo9+1) has no problems. But "linux-image-4.18.0-0.bpo.3-amd64"
> (4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
> and run startx.
Could you open a new bug at (and attach relevant information there):
https://01.org/linuxgraphics/documentation/how-report-bugs
Most confusing about this is that 4.17 would have worked to begin with,
without intel_iommu=igfx_off (unless it was the default for older
kernel?)
Did you maybe update other parts of the system while updating the
kernel?
If you could attach full boot dmesg from working and non-working kernel +
have config file of both kernel's in Bugzilla. That'd be a good start!
Regards, Joonas
> Building 4.19.12 myself got me into X11 and able to start
> Firefox to panic the kernel. I also updated to the latest BIOS
> (1.40), but it's an EOL laptop (but it's still the most powerful
> laptop I use). I intend to replace the BIOS with Coreboot soon...
>
> Initially, I thought I was hitting another GPU hang from 4.18+:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=107945
>
> But building drm-tip @ commit 28bb1fc015cedadf3b099b8bd0bb27609849f362
> ("drm-tip: 2018y-12m-25d-08h-12m-37s UTC integration manifest")
> I was still able to reproduce the panic unless I use iommu_intel=igfx_off
> "i915.reset=1" did not help matters, either.
>
> Below is what I got from netconsole while on drm-tip:
>
> Kernel panic - not syncing: DMAR hardware is malfunctioning
> Shutting down cpus with NMI
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
> [ cut here ]
> sched: Unexpected reschedule of offline CPU#3!
> WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
> Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant
> snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass
> crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel
> aes_x86_64 crypto_simd cryptd mac80211 glue_helper intel_cstate iwlwifi
> intel_uncore i915 intel_gtt i2c_algo_bit iosf_mbi drm_kms_helper cfbfillrect
> syscopyarea intel_ips cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea
> thinkpad_acpi prime_numbers cfg80211 ledtrig_audio i2c_i801 sg snd_hda_intel
> led_class snd_hda_codec drm ac drm_panel_orientation_quirks snd_hwdep battery
> e1000e agpgart snd_hda_core snd_pcm snd_timer ptp snd soundcore pps_core
> ehci_pci ehci_hcd lpc_ich video mfd_core button acpi_cpufreq ecryptfs
> ip_tables x_tables ipv6 evdev thermal [last unloaded: netconsole]
> CPU: 0 PID: 105 Comm: kworker/u8:3 Not tainted 4.20.0-rc7b1+ #1
> Hardware name: LENOVO 3680FBU/3680FBU, BIOS 6QET70WW (1.40 ) 10/11/2012
> Workqueue: i915 __i915_gem_free_work [i915]
> RIP: 0010:native_smp_send_reschedule+0x34/0x40
> Code: 05 69 c6 c9 00 73 15 48 8b 05 18 2d b3 00 be fd 00 00 00 48 8b 40 30 e9
> 9a 58 7d 00 89 fe 48 c7 c7 78 73 af 81 e8 dc c2 01 00 <0f> 0b c3 66 0f 1f 84
> 00 00 00 00 00 66 66 66 66 90 8b 05 0d 7d df
> RSP: 0018:888075003d98 EFLAGS: 00010092
> RAX: 002e RBX: 8880751a0740 RCX: 0006
> RDX: 0007 RSI: 0082 RDI: 888075015440
> RBP: 88806e823700 R08: R09: 888072fc07c0
> R10: 888075003d60 R11: fff5c002 R12: 8880751a0740
> R13: 8880751a0740 R14: R15: 0003
> FS: () GS:88807500() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7fdb1f53f000 CR3: 01c0a004 CR4: 000206f0
> Call Trace:
>
> ? check_preempt_curr+0x4e/0x90
> ? ttwu_do_wakeup.isra.19+0x14/0xf0
> ? try_to_wake_up+0x323/0x410
> ? autoremove_wake_function+0xe/0x30
> ? __wake_up_common+0x8d/0x140
> ? __wake_up_common_lock+0x6c/0x90
> ? irq_work_run_list+0x49/0x80
> ? tick_sched_handle.isra.6+0x50/0x50
> ? update_process_times+0x3b/0x50
> ? tick_sched_handle.isra.6+0x30/0x50
> ? tick_sched_timer+0x3b/0x80
> ? __hrtimer_run_queues+0xea/0x270
> ? hrtimer_interrupt+0x101/0x240
> ? smp_apic_timer_interrupt+0x6a/0x150
> ? apic_timer_interrupt+0xf/0x20
>
> ? panic+0x1ca/0x212
> ? panic+0x1c7/0x212
> ? __iommu_flush_iotlb+0x19e/0x1c0
> ? iommu_flush_iotlb_psi+0x96/0xf0
> ? intel_unmap+0xbf/0xf0
> ? i915_gem_object_put_pages_gtt+0x36/0x220 [i915]
> ? drm_ht_remove+0x20/0x20 [drm]
> ? drm_mm_remove_node+0x1ad/0x310 [drm]
> ? __pm_runtime_resume+0x54/0x70
> ? __i915_gem_object_unset_pages+0x129/0x170 [i915]
> ? __i915_gem_object_put_pages+0x70/0xa0 [i915]
> ? __i915_gem_free_objects+0x245/0x4e0 [i915]
> ? __switch_to_a
Re: iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip
Quoting Eric Wong (2019-01-04 03:06:26)
> Joonas Lahtinen wrote:
> > Quoting Eric Wong (2018-12-27 13:49:48)
> > > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > > chipset) and hit some kernel panics while trying to view
> > > image/animation-intensive stuff in Firefox (X11) unless I use
> > > "iommu_intel=igfx_off".
> > >
> > > With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
> > > (4.17.17-1~bpo9+1) has no problems. But
> > > "linux-image-4.18.0-0.bpo.3-amd64"
> > > (4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
> > > and run startx.
>
> > Most confusing about this is that 4.17 would have worked to begin with,
> > without intel_iommu=igfx_off (unless it was the default for older
> > kernel?)
>
> Yeah, so the Debian bpo 4.17(.17) kernel did not set
> CONFIG_INTEL_IOMMU_DEFAULT_ON, so I didn't encounter problems.
> My self-built kernels all set CONFIG_INTEL_IOMMU_DEFAULT_ON.
So it's the case that IOMMU never worked on your machine.
My recommendation would be to simply use intel_iommu=igfx_off if you
need IOMMU.
Old hardware is known to have issues with IOMMU, and retroactively
enabling IOMMU on those machines just brings them up :/
Regards, Joonas
> Booting the Debian 4.17 kernel with "intel_iommu=on" gives the
> same hanging problem I hit with self-built 4.19.{12,13} kernels.
>
> I'm not sure how far back the problem goes (maybe forever),
> since I only got this hardware. Not sure what's the problem
> with Debian 4.18, either; but (self-built) 4.19.13 is fine w/o
> CONFIG_INTEL_IOMMU_DEFAULT_ON.
>
> Debian backports doesn't have kernels for 4.19 or 4.20, yet.
>
> > Did you maybe update other parts of the system while updating the
> > kernel?
>
> Definitely not; just the kernel + headers ("make bindeb-pkg)".
>
> > If you could attach full boot dmesg from working and non-working kernel +
> > have config file of both kernel's in Bugzilla. That'd be a good start!
>
> Sorry, I get anxiety attacks when it comes to logins and forms.
> Anyways, I managed to get the Debian kernel dmesg output uploaded
> with and without iommu_intel=on:
> https://bugs.freedesktop.org/attachment.cgi?bugid=109219
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Hi all, I would like to have some Acked-by's from you, the distro media folks Cc'd here, to document your intent to start using Intel's new media driver[1]. So if you recognize yourself (or are otherwise interested), please read on. TL;DR Distro folks, please give your Acked-by on patch [5/6] I believe most are already aware of the situation that Intel is moving to the new codebase for libva backend to support new Intel integrated graphics devices. The existing intel-libva-driver will be continue to be be supported for pre-Icelake platforms (https://patchwork.freedesktop.org/series/49190/ The userspace changes are reviewed and rebased here: https://github.com/intel/media-driver/pull/271 https://github.com/intel/media-driver/pull/463 Best Regards, Joonas Lahtinen Cc: dri-devel@lists.freedesktop.org Cc: Timo Aaltonen Cc: Takashi Iwai Cc: Stephane Marchesin Cc: Dave Airlie Cc: Daniel Vetter PS. This series might result in some CI failures reported as it adds new uAPI and Patchwork / CI synchronization of tests and kernel is currently WIP. [1] https://github.com/intel/media-driver [2] https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (4): drm/i915/execlists: Move RPCS setup to context pin drm/i915: Add timeline barrier support drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) drm/i915/selftests: Context SSEU reconfiguration tests drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_gem_context.c | 354 - drivers/gpu/drm/i915/i915_gem_context.h | 10 + drivers/gpu/drm/i915/i915_perf.c | 13 +- drivers/gpu/drm/i915/i915_request.c | 13 + drivers/gpu/drm/i915/i915_request.h | 10 + drivers/gpu/drm/i915/i915_timeline.c | 3 + drivers/gpu/drm/i915/i915_timeline.h | 27 + drivers/gpu/drm/i915/intel_lrc.c | 100 ++-- drivers/gpu/drm/i915/intel_lrc.h | 2 + .../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++ .../gpu/drm/i915/selftests/mock_timeline.c| 2 + include/uapi/drm/i915_drm.h | 64 +++ 13 files changed, 1056 insertions(+), 37 deletions(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
+ dri-devel mailing list, especially for the buddy allocator part Quoting Dave Airlie (2019-02-15 02:47:07) > On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote: > > > > In preparation for upcoming devices with device local memory, introduce the > > concept of different memory regions, and a simple buddy allocator to manage > > them. > > This is missing the information on why it's not TTM. > > Nothing against extending i915 gem off into doing stuff we already > have examples off in tree, but before you do that it would be good to > have a why we can't use TTM discussion in public. Glad that you asked. It's my fault that it was not included in the cover letter. I anticipated the question, but was travelling for a couple of days at the time this was sent. I didn't want to write a hasty explanation and then disappear, leaving others to take the heat. So here goes the less-hasty version: We did an analysis on the effort needed vs benefit gained of using TTM when this was started initially. The conclusion was that we already share the interesting bits of code through core DRM, really. Re-writing the memory handling to TTM would buy us more fine-grained locking. But it's more a trait of rewriting the memory handling with the information we have learned, than rewriting it to use TTM :) And further, we've been getting rid of struct_mutex at a steady phase in the past years, so we have a clear path to the fine-grained locking already in the not-so-distant future. With all this we did not see much gained from converting over, as the code sharing is already substantial. We also wanted to have the buddy allocator instead of a for loop making drm_mm allocations to make sure we can keep the memory fragmentation at bay. The intent is to move the buddy allocator to core DRM, to the benefit of all the drivers, if there is interest from community. It has been written as a strictly separate component with that in mind. And if you take the buddy allocator out of the patch set, the rest is mostly just vfuncing things up to be able to have different backing storages for objects. We took the opportunity to move over to the more valgrind friendly mmap while touching things, but it's something we have been contemplating anyway. And yeah, loads of selftests. That's really all that needed adding, and most of it is internal to i915 and not to do with uAPI. This means porting over an userspace driver doesn't require a substantial rewrite, but adding new a few new IOCTLs to set the preferred backing storage placements. All the previous GEM abstractions keep applying, so we did not see a justification to rewrite the kernel driver and userspace drivers. It would have just to made things look like TTM, when we already have the important parts of the code shared with TTM drivers behind the GEM interfaces which all our drivers sit on top of. I hope this answered the question to some extent, and feel free to ask more details or provide suggestion to what we could have done differently. Regards, Joonas > > Dave. > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/mei-hdcp
Quoting Daniel Vetter (2019-02-19 09:55:27)
> Hi all,
>
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
>
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
>
> Plus one small static inline in the drm_hdcp.h header that both i915
> and mei_hdcp will need.
>
> Joonas, please pull into drm-intel-next-queued so I can apply the i915
> hdcp patches.
This is now pulled.
Regards, Joonas
>
> Greg/Arnd, I think there's two options to get the mei-hdcp patches landed
> into drivers-misc:
> - You pull this topic pull and then apply the mei-hdcp patches on top in
> char-misc-next.
> - I also pull in char-misc-next to get at 32ea33a04484 ("mei: bus: export
> to_mei_cl_device for mei client devices drivers") and then apply all the
> mei-hdcp stuff into a new topic branch.
>
> I think 2nd option would be better, allows us to integration test easier,
> and we'll have a topic branch in case we need a fixup spanning mei-hdcp
> and i915. Also would allow me to start merging the patches, since I think
> it's too late for 5.1.
>
> Cheers, Daniel
>
> The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
>
> Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-intel tags/topic/mei-hdcp-2019-02-19
>
> for you to fetch changes up to 35c0272502cca0a1b461d310c23aac94a503983d:
>
> drm/audio: declaration of struct device (2019-02-18 20:19:28 +0100)
>
>
> Prep patches + headers for the mei-hdcp/i915 component interfaces
>
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
>
> Plus one small static inline in the drm_hdcp.h header that both i915
> and mei_hdcp will need.
>
>
> Daniel Vetter (3):
> component: Add documentation
> components: multiple components for a device
> i915/snd_hdac: I915 subcomponent for the snd_hdac
>
> Ramalingam C (5):
> drm/i915: enum port definition is moved into i915_drm.h
> drm/i915: header for i915 - MEI_HDCP interface
> drm/i915: MEI interface definition
> drm: helper functions for hdcp2 seq_num to from u32
> drm/audio: declaration of struct device
>
> Documentation/driver-api/component.rst | 17 +++
> Documentation/driver-api/device_link.rst | 3 +
> Documentation/driver-api/index.rst | 1 +
> drivers/base/component.c | 206
> +--
> drivers/gpu/drm/i915/intel_audio.c | 4 +-
> drivers/gpu/drm/i915/intel_display.h | 16 +--
> include/drm/drm_audio_component.h| 1 +
> include/drm/drm_hdcp.h | 18 +++
> include/drm/i915_component.h | 5 +
> include/drm/i915_drm.h | 15 +++
> include/drm/i915_mei_hdcp_interface.h| 149 ++
> include/linux/component.h| 76
> include/sound/hda_component.h| 5 +-
> sound/hda/hdac_component.c | 4 +-
> sound/hda/hdac_i915.c| 6 +-
> 15 files changed, 493 insertions(+), 33 deletions(-)
> create mode 100644 Documentation/driver-api/component.rst
> create mode 100644 include/drm/i915_mei_hdcp_interface.h
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
Quoting Dave Airlie (2019-02-25 12:24:48) > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > wrote: > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote: > > > > > > > > In preparation for upcoming devices with device local memory, introduce > > > > the > > > > concept of different memory regions, and a simple buddy allocator to > > > > manage > > > > them. > > > > > > This is missing the information on why it's not TTM. > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > have examples off in tree, but before you do that it would be good to > > > have a why we can't use TTM discussion in public. > > > > Glad that you asked. It's my fault that it was not included in > > the cover letter. I anticipated the question, but was travelling > > for a couple of days at the time this was sent. I didn't want > > to write a hasty explanation and then disappear, leaving others to > > take the heat. > > > > So here goes the less-hasty version: > > > > We did an analysis on the effort needed vs benefit gained of using > > TTM when this was started initially. The conclusion was that we > > already share the interesting bits of code through core DRM, really. > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > locking. But it's more a trait of rewriting the memory handling with > > the information we have learned, than rewriting it to use TTM :) > > > > And further, we've been getting rid of struct_mutex at a steady phase > > in the past years, so we have a clear path to the fine-grained locking > > already in the not-so-distant future. With all this we did not see > > much gained from converting over, as the code sharing is already > > substantial. > > > > We also wanted to have the buddy allocator instead of a for loop making > > drm_mm allocations to make sure we can keep the memory fragmentation > > at bay. The intent is to move the buddy allocator to core DRM, to the > > benefit of all the drivers, if there is interest from community. It has > > been written as a strictly separate component with that in mind. > > > > And if you take the buddy allocator out of the patch set, the rest is > > mostly just vfuncing things up to be able to have different backing > > storages for objects. We took the opportunity to move over to the more > > valgrind friendly mmap while touching things, but it's something we > > have been contemplating anyway. And yeah, loads of selftests. > > > > That's really all that needed adding, and most of it is internal to > > i915 and not to do with uAPI. This means porting over an userspace > > driver doesn't require a substantial rewrite, but adding new a few > > new IOCTLs to set the preferred backing storage placements. > > > > All the previous GEM abstractions keep applying, so we did not see > > a justification to rewrite the kernel driver and userspace drivers. > > It would have just to made things look like TTM, when we already > > have the important parts of the code shared with TTM drivers > > behind the GEM interfaces which all our drivers sit on top of. > > a) you guys should be the community as well, if the buddy allocator is > useful in the core DRM get out there and try and see if anyone else > has a use case for it, like the GPU scheduler we have now (can i915 > use that yet? :-) Well, the buddy allocator should be useful for anybody wishing to have as continuous physical allocations as possible. I have naively assumed that would be almost everyone. So it would be only a question if others see the amount of work required to convert over is justified for them. For the common DRM scheduler, I think a solid move from the beginning would have been to factor out the i915 scheduler as it was most advanced in features :) Now there is a way more trivial common scheduler core with no easy path to transition without a feature regression. We'd have to rewrite many of the more advanced features for that codebase before we could transition over. It's hard to justify such work, for that it would buy us very little compared to amount of work. Situation would be different if there was something gained from switching over. This would be the situation if the more advanced scheduler was picked as the shared codebase. > b) however this last two paragraphs fill me with no confidence that > you've looked
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
Quoting Alex Deucher (2019-02-25 21:31:43) > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > wrote: > > > > Quoting Dave Airlie (2019-02-25 12:24:48) > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > > > wrote: > > > > > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld > > > > > wrote: > > > > > > > > > > > > In preparation for upcoming devices with device local memory, > > > > > > introduce the > > > > > > concept of different memory regions, and a simple buddy allocator > > > > > > to manage > > > > > > them. > > > > > > > > > > This is missing the information on why it's not TTM. > > > > > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > > > have examples off in tree, but before you do that it would be good to > > > > > have a why we can't use TTM discussion in public. > > > > > > > > Glad that you asked. It's my fault that it was not included in > > > > the cover letter. I anticipated the question, but was travelling > > > > for a couple of days at the time this was sent. I didn't want > > > > to write a hasty explanation and then disappear, leaving others to > > > > take the heat. > > > > > > > > So here goes the less-hasty version: > > > > > > > > We did an analysis on the effort needed vs benefit gained of using > > > > TTM when this was started initially. The conclusion was that we > > > > already share the interesting bits of code through core DRM, really. > > > > > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > > > locking. But it's more a trait of rewriting the memory handling with > > > > the information we have learned, than rewriting it to use TTM :) > > > > > > > > And further, we've been getting rid of struct_mutex at a steady phase > > > > in the past years, so we have a clear path to the fine-grained locking > > > > already in the not-so-distant future. With all this we did not see > > > > much gained from converting over, as the code sharing is already > > > > substantial. > > > > > > > > We also wanted to have the buddy allocator instead of a for loop making > > > > drm_mm allocations to make sure we can keep the memory fragmentation > > > > at bay. The intent is to move the buddy allocator to core DRM, to the > > > > benefit of all the drivers, if there is interest from community. It has > > > > been written as a strictly separate component with that in mind. > > > > > > > > And if you take the buddy allocator out of the patch set, the rest is > > > > mostly just vfuncing things up to be able to have different backing > > > > storages for objects. We took the opportunity to move over to the more > > > > valgrind friendly mmap while touching things, but it's something we > > > > have been contemplating anyway. And yeah, loads of selftests. > > > > > > > > That's really all that needed adding, and most of it is internal to > > > > i915 and not to do with uAPI. This means porting over an userspace > > > > driver doesn't require a substantial rewrite, but adding new a few > > > > new IOCTLs to set the preferred backing storage placements. > > > > > > > > All the previous GEM abstractions keep applying, so we did not see > > > > a justification to rewrite the kernel driver and userspace drivers. > > > > It would have just to made things look like TTM, when we already > > > > have the important parts of the code shared with TTM drivers > > > > behind the GEM interfaces which all our drivers sit on top of. > > > > > > a) you guys should be the community as well, if the buddy allocator is > > > useful in the core DRM get out there and try and see if anyone else > > > has a use case for it, like the GPU scheduler we have now (can i915 > > > use that yet? :-) > > > > Well, the buddy allocator should be useful for anybody wishing to have > > as continuous physical allocations as possible. I have naively assumed > > that would be almost ever
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
Quoting Christian König (2019-02-27 04:17:01) > Am 27.02.19 um 00:04 schrieb Dave Airlie: > >>> At the end of the day, I don't really care that much. I get it, we > >>> all have large projects with scarce resources. I just think a few > >>> years down the road we'll all regret it as a community. > >> AMD and others have also spent years tuning TTM for both UMA and VRAM, > >> but especially VRAM. It comes across a bit daft to complain about the > >> effort to move to TTM, but say nothing about the effort to tune GEM > >> for optimal VRAM performance. Effort that has already been expended > >> that you could take advantage of. > > I'm with Alex here, the patches you have now are just the start, I > > realise you think they are all you'll need, but I expect once Chris > > gets going with real VRAM hardware he'll generate reams for stuff. > > > > People have been tuning and making TTM run on VRAM using GPUs for > > longer than you've been making VRAM using GPUs, there had better be > > good and well thought out reasons for avoiding using it, and so far > > you haven't made that argument to me all. In fact your scheduler > > arguments works against you. If we should have abstracted i915 > > scheduler out and used it because it had more features and > > pre-existed, then i915 should be using TTM since it's already > > abstracted out and has more features. > > > > Like we've pulled other stuff out of TTM like reservation objects, I > > don't think i915 uses those yet either when it clearly could be. Maybe > > if we started by fixing that, moving to TTM would be less of a > > problem. > > Just to make it extra clear: At least I absolutely won't mind if we > decommission TTM further! > > We have optimized TTM as much as we could without a fundamental design > change, but essentially there are a couple of problem we can't fix > without touching all drivers at once. > > For example the layered design where TTM calls back into the driver to > move stuff around or allocate something from a domain really needs to go > away. > > So my suggestion is that we filleting TTM into multiple independent > components which a) can be used to implement the existing TTM interface > and b) implement a clean and encapsulated functionality. > > Those components can then be used by drivers independently of TTM to > implement the necessary MM. This is exactly what I was hoping we could do, too. So I'm glad to hear this suggestion. Incrementally extracting and sharing the components would lead to less disruptions than halting the progress while doing a major rewrite of the driver. As I mentioned in IRC, one good step for both the scheduler and memory management would be to actually map out the feature sets. It is clear that we have confusion about what the feature set of the respective components are (at least I do seem to have about TTM / DRM scheduler). Then when we understand what it is that we actually have, it should be easier to start discussing which are the components that could be reused. I think one good way to take on this would be to look into sharing as much of the test assets as possible. We have plenty of testcases excercising the low-on-memory conditions and scheduling corner cases that we've had to tackle. And I'm sure there are tests for the above mentioned TTM VRAM tuning, too. I'll look into and discuss the reservation objects Dave mentioned, and I'm happy to hear about other suggestions. I'd also like to hear comments about the buddy allocator suggestion. It should help in enabling >4K page support for pretty much any driver. Regards, Joonas > Regards, > Christian. > > > > > Anyways, I expect moving to TTM is a big change for i915, and probably > > more than you are able to bite off at present, but I'm going to be > > watching closely what stuff you add on top of this sort of thing, and > > if it starts getting large and messier as you tune it, I'll have to > > start reconsidering how big a NO I have to use. > > > > Dave. > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/selftests/mm: Switch to bitmap_zalloc()
I take it that both instances are supposed to call bitmap_zalloc? If you can send a v2 that compiles, I can merge it after it passes the CI. Regards, Joonas Quoting Andy Shevchenko (2019-03-04 11:03:20) > Switch to bitmap_zalloc() to show clearly what we are allocating. > Besides that it returns pointer of bitmap type instead of opaque void *. > > Signed-off-by: Andy Shevchenko > --- > drivers/gpu/drm/selftests/test-drm_mm.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c > b/drivers/gpu/drm/selftests/test-drm_mm.c > index fbed2c90fd51..d1206aef26af 100644 > --- a/drivers/gpu/drm/selftests/test-drm_mm.c > +++ b/drivers/gpu/drm/selftests/test-drm_mm.c > @@ -1615,7 +1615,7 @@ static int igt_topdown(void *ignored) > DRM_RND_STATE(prng, random_seed); > const unsigned int count = 8192; > unsigned int size; > - unsigned long *bitmap = NULL; > + unsigned long *bitmap; > struct drm_mm mm; > struct drm_mm_node *nodes, *node, *next; > unsigned int *order, n, m, o = 0; > @@ -1631,8 +1631,7 @@ static int igt_topdown(void *ignored) > if (!nodes) > goto err; > > - bitmap = kcalloc(count / BITS_PER_LONG, sizeof(unsigned long), > -GFP_KERNEL); > + bitmap = bitmap_zalloc(count, GFP_KERNEL); > if (!bitmap) > goto err_nodes; > > @@ -1717,7 +1716,7 @@ static int igt_topdown(void *ignored) > drm_mm_takedown(&mm); > kfree(order); > err_bitmap: > - kfree(bitmap); > + bitmap_free(bitmap); > err_nodes: > vfree(nodes); > err: > @@ -1745,8 +1744,7 @@ static int igt_bottomup(void *ignored) > if (!nodes) > goto err; > > - bitmap = kcalloc(count / BITS_PER_LONG, sizeof(unsigned long), > -GFP_KERNEL); > + bitmap = bitmap_zcalloc(count, GFP_KERNEL); > if (!bitmap) > goto err_nodes; > > @@ -1818,7 +1816,7 @@ static int igt_bottomup(void *ignored) > drm_mm_takedown(&mm); > kfree(order); > err_bitmap: > - kfree(bitmap); > + bitmap_free(bitmap); > err_nodes: > vfree(nodes); > err: > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/hdr-formats
Quoting Maarten Lankhorst (2019-03-07 11:48:24) > Hi Sean and Joonas, > > Here's a pull request for HDR format enabling in i915. Can this be pulled to > drm-misc-next and dinq? I was travelling on Fri, so sorry for delay. This is now pulled to dinq, too. Regards, Joonas > > Cheers, > Maarten > > topic/hdr-formats-2019-03-07: > Add support for Y21x and Y41x to drm core and i915, and P01x support to i915. > The following changes since commit 4b057e73f28f1df13b77b77a52094238ffdf8abd: > > Merge tag 'drm-misc-fixes-2019-02-22' of > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-03-05 08:14:22 > +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdr-formats-2019-03-07 > > for you to fetch changes up to 296e9b19eff6157e1e4f130fa436e105c45725e9: > > drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal > planes (2019-03-05 12:49:00 +0100) > > > Add support for Y21x and Y41x to drm core and i915, and P01x support to i915. > > > Juha-Pekka Heikkila (3): > drm/i915: Add P010, P012, P016 plane control definitions > drm/i915: Preparations for enabling P010, P012, P016 formats > drm/i915: Enable P010, P012, P016 formats for primary and sprite planes > > Swati Sharma (3): > drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc > drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions > drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for > universal planes > > drivers/gpu/drm/drm_fourcc.c | 6 ++ > drivers/gpu/drm/i915/i915_reg.h | 9 +++ > drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +- > drivers/gpu/drm/i915/intel_display.c | 57 ++-- > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 14 ++-- > drivers/gpu/drm/i915/intel_sprite.c | 108 > -- > include/uapi/drm/drm_fourcc.h | 16 + > 8 files changed, 194 insertions(+), 19 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM-based Oops viewer
Quoting Ahmed S. Darwish (2019-03-10 03:31:42) > Hello DRM/UEFI maintainers, > > Several years ago, I wrote a set of patches to dump the kernel > log to disk upon panic -- through BIOS INT 0x13 services. [1] > > The overwhelming response was that it's unsafe to do this in a > generic manner. Linus proposed a video-based viewer instead: [2] > > If you want to do the BIOS services thing, do it for video: copy the > oops to low RAM, return to real mode, re-run the graphics card POST > routines to initialize text-mode, and use the BIOS to print out the > oops. That is WAY less scary than writing to disk. > > Of course it's 2019 now though, and it's quite known that > Intel is officially obsoleting the PC/AT BIOS by 2020.. [3] > > Researching whether this can be done from UEFI, it was also clear > that UEFI "Runtime Services" do not provide any re-initialization > routines. [4] > > The maximum possible that UEFI can provide is a GOP-provided > framebuffer that's ready to use by the OS -- even after the UEFI > boot phase is marked as done through ExitBootServices(). [5] > > Of course, once native drivers like i915 or radeon take over, > such a framebuffer is toast... [6] > > Thus a possible remaining option, is to display the oops through > "minimal" DRM drivers provided for each HW variant... Since > these special drivers will run only and fully under a panic() > context though, several constraints exist: > > - The code should be fully synchronous (irqs are disabled) > - It should not allocate any dynamic memory > - It should make minimal assumptions about HW state > - It should not chain into any other kernel subsystem > - It has ample freedom to use delay-based loops and the > like, the kernel is already dead. > > How feasible is it to have such a special "DRM viewoops" > framework + its minimal drivers in the kernel? There is already (efi-)pstore, and I believe it could be already integrated to distros so that the captured error is displayed on next boot. So the user experience difference would only be seeing the error immediately vs. on boot? For that gain, it might be bit much work to create failsafe mode to each driver, but others may disagree. Regards, Joonas > The target is to start from i915, since that's what in my > laptop now, and work from there.. > > Some final notes: > > - The NT kernel has a similar concept, but for storage instead. > They're used to dump core under kernel panic() situations, > and are called "Minoport storage drivers". [7] > > - Since Windows 7+, a very fancy Blue Screen of Death is > displayed, with Unicode and whatnot, implying GPU drivers > involvement. [8] > > - Mac OS X also does something similar [9] > > - On Linux laptops, the current situation is _really_ bad. > > In any graphical session, type "echo c > /proc/sysrq-trigger"; > the screen will just completely freeze... > > Desired first goal: just print the panic() log > > Thanks a lot, > > [1] https://lore.kernel.org/lkml/20110125134748.GA10051@laptop > [2] > https://lore.kernel.org/lkml/AANLkTinU0KYiCd4p=z+=ojbkeeot2g+cayvdru02k...@mail.gmail.com > > [3] > https://uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf > > [4] UEFI v2.7 spec, Chapter 8, "Services — Runtime Services" > [5] UEFI v2.7 spec, Section 12.9, "Graphics Output Protocol" > "The Graphics Output Protocol supports this capability by > providing the EFI OS loader access to a hardware frame buffer > and enough information to allow the OS to draw directly to > the graphics output device." > > [6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() > > [7] > https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/restrictions-on-miniport-drivers-that-manage-the-boot-drive > > [8] > https://upload.wikimedia.org/wikipedia/commons/archive/5/56/20181019151937%21Bsodwindows10.png > [9] > https://upload.wikimedia.org/wikipedia/commons/4/4a/Mac_OS_X_10.2_Kernel_Panic.jpg > > --darwi > http://darwish.chasingpointers.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/22] gpu: i915.rst: Fix references to renamed files
Quoting Mauro Carvalho Chehab (2019-05-30 02:23:43)
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with
> return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> Logical Rings, Logical Ring Contexts and Execlists
> ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
> ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
>
> Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/gpu/i915.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 055df45596c1..38fefeb99bba 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
> Workarounds
> ---
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/selftest_workarounds.c
This should be gt/intel_workarounds.c
Do you want me to merge this, or do you plan on merging through
documentation tree?
Regards, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, Missed last week's window of opportunity due to trouble getting CI results for Icelake. So this is against -rc2 still to avoid re-doing the GVT pull third time. Just a single Icelake W/A for i915. For GVT a fix for recently seen arbitrary DMA map fault and more enforcement fixes. I'll be on my summer vacation starting end of this week, so Jani/Rodrigo will cover for the rest of the -rcs. Regards, Joonas *** drm-intel-fixes-2019-06-03: - Add missing Icelake W/A to disable GPU hang on cache ECC error The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-06-03 for you to fetch changes up to afb286bcae85ee816e8497596bf8e7f83347f47b: Merge tag 'gvt-fixes-2019-05-30' of https://github.com/intel/gvt-linux into drm-intel-fixes (2019-05-31 10:51:59 +0300) - Add missing Icelake W/A to disable GPU hang on cache ECC error Colin Xu (3): drm/i915/gvt: Update force-to-nonpriv register whitelist drm/i915/gvt: Fix GFX_MODE handling drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handler Gao, Fred (1): drm/i915/gvt: Fix cmd length of VEB_DI_IECP Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-30' of https://github.com/intel/gvt-linux into drm-intel-fixes Tina Zhang (1): drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack Tvrtko Ursulin (1): drm/i915/icl: Add WaDisableBankHangMode Xiong Zhang (1): drm/i915/gvt: refine ggtt range validation drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 26 +++ drivers/gpu/drm/i915/gvt/handlers.c | 36 +++- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_workarounds.c | 6 ++ 5 files changed, 62 insertions(+), 11 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, No i915 fixes this week, but forwarding the GVT pull request still. One GVT regression fix for debug build of i915 guest, guest ring state fix after execution for hang check and a couple of static checker fixes. CI is being clogged curently, but we really don't have that much GVT coverage anyway, so sending the PR before leaving. Git log is confused/wrong here, dim status indicates 5 unmerged patches at the time of sending, and those are the GVT patches. See the tag gvt-fixes-2019-06-05 for details. Once you pull this, Jani gets to move DIF to -rc4 next week. Regards, Joonas PS. At the time of pulling, you can check if CI_DIF_380 full IGT run results have appeared in: https://intel-gfx-ci.01.org/tree/drm-intel-fixes/combined-alt.html *** drm-intel-fixes-2019-06-06: - Include gvt-fixes-2019-06-05 The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-06-06 for you to fetch changes up to fa2eb819ddf9bf671077f3711441208532118a5c: Merge tag 'gvt-fixes-2019-06-05' of https://github.com/intel/gvt-linux into drm-intel-fixes (2019-06-05 12:27:50 +0300) - Include gvt-fixes-2019-06-05 Aleksei Gimbitskii (2): drm/i915/gvt: Check if cur_pt_type is valid drm/i915/gvt: Assign NULL to the pointer after memory free. Colin Xu (3): drm/i915/gvt: Update force-to-nonpriv register whitelist drm/i915/gvt: Fix GFX_MODE handling drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handler Gao, Fred (1): drm/i915/gvt: Fix cmd length of VEB_DI_IECP Joonas Lahtinen (2): Merge tag 'gvt-fixes-2019-05-30' of https://github.com/intel/gvt-linux into drm-intel-fixes Merge tag 'gvt-fixes-2019-06-05' of https://github.com/intel/gvt-linux into drm-intel-fixes Tina Zhang (1): drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack Tvrtko Ursulin (1): drm/i915/icl: Add WaDisableBankHangMode Weinan Li (1): drm/i915/gvt: add F_CMD_ACCESS flag for wa regs Xiaolin Zhang (1): drm/i915/gvt: save RING_HEAD into vreg when vgpu switched out Xiong Zhang (1): drm/i915/gvt: refine ggtt range validation drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 38 ++--- drivers/gpu/drm/i915/gvt/handlers.c | 49 +++- drivers/gpu/drm/i915/gvt/reg.h | 2 ++ drivers/gpu/drm/i915/gvt/scheduler.c | 25 drivers/gpu/drm/i915/gvt/scheduler.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 3 ++ drivers/gpu/drm/i915/intel_workarounds.c | 6 8 files changed, 108 insertions(+), 18 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/hdr-formats
Quoting Maarten Lankhorst (2019-03-13 13:21:46) > Hey Sean and Joonas, > > One more pull request for the hdr-formats topic branch. FP16 support > is now also implemented. > > Can this be pulled to drm-misc-next and dinq? Pulled to drm-intel-next-queued. Regards, Joonas > > ~Maarten > > topic/hdr-formats-2019-03-13: > Add support for floating point half-width formats. > The following changes since commit 296e9b19eff6157e1e4f130fa436e105c45725e9: > > drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal > planes (2019-03-05 12:49:00 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdr-formats-2019-03-13 > > for you to fetch changes up to a94bed60cb73962f344ead14b2ee7613280432c6: > > drm/i915/icl: Implement half float formats (2019-03-13 11:23:12 +0100) > > > Add support for floating point half-width formats. > > > Kevin Strasser (3): > drm/fourcc: Add 64 bpp half float formats > drm/i915: Refactor icl_is_hdr_plane > drm/i915/icl: Implement half float formats > > drivers/gpu/drm/drm_fourcc.c | 4 ++ > drivers/gpu/drm/i915/intel_atomic.c | 3 +- > drivers/gpu/drm/i915/intel_display.c | 29 +- > drivers/gpu/drm/i915/intel_drv.h | 7 ++-- > drivers/gpu/drm/i915/intel_sprite.c | 78 > +--- > include/uapi/drm/drm_fourcc.h| 11 + > 6 files changed, 120 insertions(+), 12 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
es just to check if they are idle drm/i915: Compute the global scheduler caps Revert "drm/i915: Avoid waking the engines just to check if they are idle" drm/i915: Report engines are idle if already parked drm/i915: Make request allocation caches global drm/i915: Make object/vma allocation caches global drm/i915: Remove second level open-coded rcu work drm/i915: Use __ffs() in for_each_priolist for more compact code drm/i915/execlists: Suppress mere WAIT preemption drm/i915: Introduce i915_timeline.mutex drm/i915/selftests: Check that whitelisted registers are accessible drm/i915/execlists: Suppress redundant preemption drm/i915: Keep timeline HWSP allocated until idle across the system drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ drm/i915: Prioritise non-busywait semaphore workloads drm/i915: Fix I915_EXEC_RING_MASK drm/i915: Acquire breadcrumb ref before cancelling drm/i915/gtt: Use optimised memset32/64 for clearing PTE drm/i915/gtt: Store scratch page size alongside not in the common struct drm/i915: Just check the vebox IIR regardless drm/i915: Stop capturing semaphore registers for gen6/7 GPU hangs drm/i915: Remove last traces of exec-id (GEM_BUSY) drm/i915: Store the BIT(engine->id) as the engine's mask drm/i915/gtt: Mark ALL_ENGINES as dirty on ppGTT modification drm/i915: Move find_active_request() to the engine drm/i915: Use i915_global_register() drm/i915: Pass around the intel_context drm/i915/selftests: Fix MI_STORE_DWORD_IMM alignment drm/i915: Make I915_GEM_IDLE_TIMEOUT into a macro drm/i915: Force GPU idle on suspend drm/i915/selftests: Improve switch-to-kernel-context checking drm/i915/selftests: Check preemption support on each engine drm/i915: Do a synchronous switch-to-kernel-context on idling drm/i915: Refactor common code to load initial power context drm/i915: Reduce presumption of request ordering for barriers drm/i915: Remove has-kernel-context drm/i915: Track active engines within a context drm/i915: Split struct intel_context definition to its own header drm/i915: Store the intel_context_ops in the intel_engine_cs drm/i915: Move over to intel_context_lookup() drm/i915: Make context pinning part of intel_context_ops drm/i915: Track the pinned kernel contexts on each engine drm/i915: Introduce intel_context.pin_mutex for pin management drm/i915: Suppress the "Failed to idle" warning for gem_eio drm/i915: Introduce a context barrier callback drm/i915: Consolidate reset-request debug message drm/i915/selftests: Improve error detection of reset failure drm/i915/selftests: Disable preemption while setting up fence-timers drm/i915: Refactor to common helpers for prepare/finish between reset & wedge drm/i915: Mark up vGPU support for full-ppgtt drm/i915: Record platform specific ppGTT size in intel_device_info drm/i915: Drop address size from ppgtt_type drm/i915/gtt: Rename i915_vm_is_48b to i915_vm_is_4lvl drm/i915/gtt: Refactor common ppgtt initialisation drm/i915: Always kick the execlists tasklet after reset drm/i915: Fix off-by-one in reporting hanging process drm/i915: Sanity check mmap length against object size drm/i915: Stop needlessly acquiring wakeref for debugfs/drop_caches_set drm/i915: Switch to use HWS indices rather than addresses drm/i915: Hold a ref to the ring while retiring drm/i915: Lock the gem_context->active_list while dropping the link drm/i915: Hold a reference to the active HW context Daniele Ceraolo Spurio (1): drm/i915: do not pass dev_priv to low-level forcewake functions Imre Deak (1): drm/i915/icl: Prevent incorrect DBuf enabling Jani Nikula (9): drm/i915/opregion: fix version check drm/i915/opregion: rvda is relative from opregion base in opregion 2.1+ drm/i915/dp: deconflate PPS unlock from divisor register drm/i915/dp: use single point of truth for PPS divisor register drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors drm/i915: use REG_FIELD_PREP() to define register bitfield values drm/i915: stick to kernel fixed size types drm/i915/psr: remove drmP.h include that crept in Joonas Lahtinen (8): Merge drm/drm-next into drm-intel-next-queued Merge tag 'topic/mei-hdcp-2019-02-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued drm/i915: Update DRIVER_DATE to 20190220 drm/i915: Update DRIVER_DATE to 20190311 Merge drm/drm-next into drm-intel-next-queued Merge tag 'topic/hdr-formats-2019-03-07' of
Re: linux-next: build failure after merge of the drm-intel tree
Quoting Stephen Rothwell (2019-03-27 04:59:04)
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (i386
> defconfig) failed like this:
We had a CI reporting mishap, where a failed 32-bit build resulted in
a misleading success e-mail being sent.
The tree is now fixed and we'll investigate the problem to avoid such
a false report in the future.
Regards, Joonas
>
> In file included from drivers/gpu/drm/i915/intel_guc.h:28:0,
> from drivers/gpu/drm/i915/intel_uc.h:27,
> from drivers/gpu/drm/i915/intel_uc.c:25:
> drivers/gpu/drm/i915/intel_uncore.h: In function '__raw_uncore_read64':
> drivers/gpu/drm/i915/intel_uncore.h:257:9: error: implicit declaration of
> function 'readq'; did you mean 'readl'?
> [-Werror=implicit-function-declaration]
> return read##s__(uncore->regs + i915_mmio_reg_offset(reg)); \
> ^
> drivers/gpu/drm/i915/intel_uncore.h:269:1: note: in expansion of macro
> '__raw_read'
> __raw_read(64, q)
> ^~
> drivers/gpu/drm/i915/intel_uncore.h: In function '__raw_uncore_write64':
> drivers/gpu/drm/i915/intel_uncore.h:264:2: error: implicit declaration of
> function 'writeq'; did you mean 'writel'?
> [-Werror=implicit-function-declaration]
> write##s__(val, uncore->regs + i915_mmio_reg_offset(reg)); \
> ^
> drivers/gpu/drm/i915/intel_uncore.h:274:1: note: in expansion of macro
> '__raw_write'
> __raw_write(64, q)
> ^~~
>
> Caused by commit
>
> 6cc5ca768825 ("drm/i915: rename raw reg access functions")
>
> I have reverted that commit and the following ones in the tree up to
>
> 9511cb6481af ("drm/i915: Adding missing '; ' to ENGINE_INSTANCES")
>
> --
> Cheers,
> Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/21] drm/i915: Use drm_fb_helper_fill_info
Quoting Daniel Vetter (2019-03-26 15:19:58) > This changes the fb name from "inteldrmfb" to "i915drmfb". I'm fairly sure I already commented that is is Acked-by in the case the other drivers are doing the same consolidation. Just have to make sure we don't break any IGTs that might depend on the module name. Regards, Joonas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
l_engine_cs drm/i915: Move over to intel_context_lookup() drm/i915: Make context pinning part of intel_context_ops drm/i915: Track the pinned kernel contexts on each engine drm/i915: Introduce intel_context.pin_mutex for pin management drm/i915: Suppress the "Failed to idle" warning for gem_eio drm/i915: Introduce a context barrier callback drm/i915: Consolidate reset-request debug message drm/i915/selftests: Improve error detection of reset failure drm/i915/selftests: Disable preemption while setting up fence-timers drm/i915: Refactor to common helpers for prepare/finish between reset & wedge drm/i915: Mark up vGPU support for full-ppgtt drm/i915: Record platform specific ppGTT size in intel_device_info drm/i915: Drop address size from ppgtt_type drm/i915/gtt: Rename i915_vm_is_48b to i915_vm_is_4lvl drm/i915/gtt: Refactor common ppgtt initialisation drm/i915: Always kick the execlists tasklet after reset drm/i915: Fix off-by-one in reporting hanging process drm/i915: Sanity check mmap length against object size drm/i915: Stop needlessly acquiring wakeref for debugfs/drop_caches_set drm/i915: Switch to use HWS indices rather than addresses drm/i915: Hold a ref to the ring while retiring drm/i915: Lock the gem_context->active_list while dropping the link drm/i915: Hold a reference to the active HW context drm/i915/selftests: Provide stub reset functions drm/i915: Use __is_constexpr() drm/i915: Separate GEM context construction and registration to userspace drm/i915: Introduce a mutex for file_priv->context_idr drm/i915: Stop storing ctx->user_handle drm/i915: Stop storing the context name as the timeline name drm/i915: Flush pages on acquisition drm/i915: Skip object locking around a no-op set-domain ioctl drm/i915/selftests: Calculate maximum ring size for preemption chain drm/i915/selftests: Mark up preemption tests for hang detection drm/i915: Introduce the i915_user_extension_method drm/i915: Create/destroy VM (ppGTT) for use with contexts drm/i915: Extend CONTEXT_CREATE to set parameters upon construction drm/i915: Allow contexts to share a single timeline across all engines drm/i915: Remove defunct intel_suspend_gt_powersave() drm/i915: Report the correct errno from i915_gem_context_open() drm/i915: Adding missing '; ' to ENGINE_INSTANCES drm/i915: Drop new chunks of context creation ABI (for now) Dan Carpenter (2): drm/i915/selftests: fix NULL vs IS_ERR() check in mock_context_barrier() drm/i915/selftests: Fix an IS_ERR() vs NULL check Daniele Ceraolo Spurio (21): drm/i915: do not pass dev_priv to low-level forcewake functions drm/i915/selftests: add test to verify get/put fw domains drm/i915: always use masks on FW regs drm/i915: use intel_uncore in fw get/put internal paths drm/i915: use intel_uncore for all forcewake get/put drm/i915: make more uncore function work on intel_uncore drm/i915: make find_fw_domain work on intel_uncore drm/i915: reduce the dev_priv->uncore dance in uncore.c drm/i915: move regs pointer inside the uncore structure drm/i915: make raw access function work on uncore drm/i915: stop storing the media fuse drm/i915: rename raw reg access functions drm/i915: add HAS_FORCEWAKE flag to uncore drm/i915: add uncore flags for unclaimed mmio drm/i915: take a ref to the rpm in the uncore structure drm/i915: switch uncore mmio funcs to use intel_uncore drm/i915: switch intel_uncore_forcewake_for_reg to intel_uncore drm/i915: intel_wait_for_register_fw to uncore drm/i915: switch intel_wait_for_register to uncore drm/i915: take a reference to uncore in the engine and use it drm/i915: fix i386 build of 64b raw_uncore functions Imre Deak (1): drm/i915/icl: Prevent incorrect DBuf enabling James Ausmus (1): drm/i915/ehl: Add EHL platform info and PCI IDs Jani Nikula (10): drm/i915/opregion: fix version check drm/i915/opregion: rvda is relative from opregion base in opregion 2.1+ drm/i915/dp: deconflate PPS unlock from divisor register drm/i915/dp: use single point of truth for PPS divisor register drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors drm/i915: use REG_FIELD_PREP() to define register bitfield values drm/i915: stick to kernel fixed size types drm/i915/psr: remove drmP.h include that crept in drm/i915/bios: iterate over child devices to initialize ddi_port_info Joonas Lahtinen (12): Merge drm/drm-next into drm-intel-next-queued Merge tag 'topic/mei-hdcp-2019-02-19' of git://anongit.fre
Re: [PULL] drm-intel-next
Quoting Dave Airlie (2019-03-28 04:09:56) > On Mon, 25 Mar 2019 at 22:49, Joonas Lahtinen > wrote: > > > > Hi Dave & Daniel, > > > > First batch of features for 5.2, tagged last week. > > I asked on irc, but got no answer I saw, > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/i915_gem_context.c:698:12: > warning: ‘context_barrier_task’ defined but not used > [-Wunused-function] > static int context_barrier_task(struct i915_gem_context *ctx, > ^~~~ > > Is there a fix for this I can throw on top of the merge? > > I don't like warnings in my builds. As discussed in IRC, I sent a followup PR that has the patches that fix the build warning. Regards, Joonas > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, Some rather important fixes that appeared after -rc6 and missed v5.2. As a PR by request of Daniel. These avoid one WARN and potential dirty pointer deref, fix a regression on saturated media loads and add missing Icelake W/As. I've manually added Cc: stable to all of them. There's also one patch that is dependency to the Icelake W/A code. Regards, Joonas *** drm-intel-fixes-2019-07-10: - Userptr/ext4 interplay WARN fix (https://bugzilla.kernel.org/show_bug.cgi?id=203317) - Fix a regression on saturated media transcoding system - Invalid pointer deref fix in error capture (triggered by hang) - Missing Icelake W/As The following changes since commit 0ecfebd2b52404ae0c54a878c872bb93363ada36: Linux 5.2 (2019-07-07 15:41:56 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-07-10 for you to fetch changes up to d7e8a19b38c8ac1a32b6b03af049e2c88d4155db: drm/i915: Don't dereference request if it may have been retired when printing (2019-07-09 16:16:18 +0300) - Userptr/ext4 interplay WARN fix (https://bugzilla.kernel.org/show_bug.cgi?id=203317) - Fix a regression on saturated media transcoding system - Invalid pointer deref fix in error capture (triggered by hang) - Missing Icelake W/As Chris Wilson (3): drm/i915: Make the semaphore saturation mask global drm/i915/userptr: Acquire the page lock around set_page_dirty() drm/i915: Don't dereference request if it may have been retired when printing John Harrison (1): drm/i915: Support flags in whitlist WAs Kenneth Graunke (1): drm/i915: Disable SAMPLER_STATE prefetching on all Gen11 steppings. Lionel Landwerlin (3): drm/i915/perf: fix ICL perf register offsets drm/i915: whitelist PS_(DEPTH|INVOCATION)_COUNT drm/i915/icl: whitelist PS_(DEPTH|INVOCATION)_COUNT drivers/gpu/drm/i915/i915_gem_userptr.c| 10 ++- drivers/gpu/drm/i915/i915_perf.c | 10 --- drivers/gpu/drm/i915/i915_reg.h| 7 + drivers/gpu/drm/i915/i915_request.c| 4 +-- drivers/gpu/drm/i915/intel_context.c | 1 - drivers/gpu/drm/i915/intel_context_types.h | 2 -- drivers/gpu/drm/i915/intel_engine_cs.c | 17 +++- drivers/gpu/drm/i915/intel_engine_types.h | 2 ++ drivers/gpu/drm/i915/intel_workarounds.c | 43 +++--- 9 files changed, 77 insertions(+), 19 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/34] drm/i915: convert put_page() to put_user_page*()
Quoting john.hubb...@gmail.com (2019-08-02 05:19:37)
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Note that this effectively changes the code's behavior in
> i915_gem_userptr_put_pages(): it now calls set_page_dirty_lock(),
> instead of set_page_dirty(). This is probably more accurate.
We've already fixed this in drm-tip where the current code uses
set_page_dirty_lock().
This would conflict with our tree. Rodrigo is handling
drm-intel-next for 5.4, so you guys want to coordinate how
to merge.
Regards, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, Tvrtko is out today, so sending the -rc3 -fixes PR on behalf of him (picked and CI tested by Tvtko). Major items are fix for GitLab #4698 (Dell DA310 Type-C dock issue) and engine busyness inconsitent value/timeout fixes when running with GuC. Then two fixes for error paths and a smatch detected divide by zero fix. Regards, Joonas *** drm-intel-fixes-2022-02-03: Fix GitLab issue #4698: DP monitor through Type-C dock(Dell DA310) doesn't work. Fixes for inconsistent engine busyness value and read timeout with GuC. Fix to use ALLOW_FAIL for error capture buffer allocation. Don't use interruptible lock on error path. Smatch fix to reject zero sized overlays. The following changes since commit 26291c54e111ff6ba87a164d85d4a4e134b7315c: Linux 5.17-rc2 (2022-01-30 15:37:07 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-02-03 for you to fetch changes up to 7d73c602154df56802a9e75ac212505fc1e9a2b6: drm/i915/pmu: Fix KMD and GuC race on accessing busyness (2022-02-01 08:59:25 +) Fix GitLab issue #4698: DP monitor through Type-C dock(Dell DA310) doesn't work. Fixes for inconsistent engine busyness value and read timeout with GuC. Fix to use ALLOW_FAIL for error capture buffer allocation. Don't use interruptible lock on error path. Smatch fix to reject zero sized overlays. Dan Carpenter (1): drm/i915/overlay: Prevent divide by zero bugs in scaling Imre Deak (1): drm/i915/adlp: Fix TypeC PHY-ready status readout Matthew Brost (2): drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline Umesh Nerlige Ramappa (2): drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for reference drm/i915/pmu: Fix KMD and GuC race on accessing busyness drivers/gpu/drm/i915/display/intel_overlay.c | 3 + drivers/gpu/drm/i915/display/intel_tc.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 + drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 ++ drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 3 +- 7 files changed, 117 insertions(+), 22 deletions(-)
Re: [PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
Quoting Jani Nikula (2022-02-07 12:48:08) > On Mon, 07 Feb 2022, Christoph Hellwig wrote: > > On Mon, Feb 07, 2022 at 08:28:13AM +, Wang, Zhi A wrote: > >> 1) About having the mmio_table.h, I would like to keep the stuff in a > >> dedicated header as putting them in intel_gvt.h might needs i915 guys > >> to maintain it. > >> 2) The other one is about if we should move the mmio_table.c into > >> i915 folder. I guess we need the some comments from Jani. In the > >> current version that I am testing, it's still in GVT folder. Guess we > >> can submit a patch to move it to i915 folder later if Jani is ok > >> about that. > > > > Yes, let's have Jani chime in on these. They're basically one and the > > same issue. This code will have to be built into into the core i915 > > driver even with my planned split, which is kindof the point of this > > exercise. I think it makes sense to use the subdirectories as boundaries > > for where the code ends up and not to declarare maintainership boundaries, > > but it will be up to the i915 and gvt maintainers to decide that. > > Agreed. If there's going to be a gvt.ko, I think all of gvt/ should be > part of that module, nothing more, nothing less. > > The gvt related files in i915/ should probably be named intel_gvt* or > something, ditto for function naming, and we'll probably want patches > touching them be Cc'd to intel-gfx list. > > Joonas, Rodrigo, Tvrtko, thoughts? Agreed on above. I don't think we expect much changes on the golden MMIO state capture set. Regards, Joonas
[PULL] drm-intel-gt-next
move errors instead of trying memcpy move (Thomas) - Fix a race between vma / object destruction and unbinding (Thomas) - Remove short-term pins from execbuf (Maarten) - Update to GuC version 69.0.3 (John, Michal Wa.) - Improvements to GT reset paths in GuC backend (Matt B.) - Use shrinker_release_pages instead of writeback in shmem object hooks (Matt A., Tvrtko) - Use trylock instead of blocking lock when freeing GEM objects (Maarten) - Allocate intel_engine_coredump_alloc with ALLOW_FAIL (Matt B.) - Fixes to object unmapping and purging (Matt A) - Check for wedged device in GuC backend (John) - Avoid lockdep splat by locking dpt_obj around set_cache_level (Maarten) - Allow dead vm to unbind vma's without lock (Maarten) - s/engine->i915/i915/ for DG2 engine workarounds (Matt R) - Use to_gt() helper for GGTT accesses (Michal Wi.) - Selftest improvements (Matt B., Thomas, Ram) - Coding style and compiler warning fixes (Matt B., Jasmine, Andi, Colin, Gustavo, Dan) Andi Shyti (2): drm/i915: Remove unused i915->ggtt drm/i915: fix header file inclusion for might_alloc() Anusha Srivatsa (1): drm/i915/rpl-s: Add stepping info Bruce Chang (1): drm/i915/dg2: Add Wa_22011100796 Colin Ian King (1): i915: make array flex_regs static const Dan Carpenter (1): drm/i915: delete shadow "ret" variable Daniele Ceraolo Spurio (2): drm/i915/wopcm: Handle pre-programmed WOPCM registers drm/i915/guc: Update guc shim control programming on newer platforms Gustavo A. R. Silva (1): drm/i915/guc: Use struct_size() helper in kmalloc() Jasmine Newsome (1): drm/i915/gem: Use local pointer ttm for __i915_ttm_move John Harrison (5): drm/i915/guc: Report error on invalid reset notification drm/i915/guc: Check for wedged before doing stuff drm/i915/guc: Temporarily bump the GuC load timeout drm/i915/guc: Update to GuC version 69.0.3 drm/i915/guc: Improve GuC loading status check/error reports Joonas Lahtinen (1): Merge drm/drm-next into drm-intel-gt-next Juston Li (1): drm/i915/pxp: Hold RPM wakelock during PXP unbind Lucas De Marchi (2): drm/i915/guc: Prepare for error propagation drm/i915/guc: Use a single pass to calculate regset Maarten Lankhorst (8): drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors, v2. drm/i915: Add locking to i915_gem_evict_vm(), v3. drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something, v2. drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind, v2. drm/i915: Remove support for unlocked i915_vma unbind drm/i915: Remove short-term pins from execbuf, v6. drm/i915: Lock dpt_obj around set_cache_level, v2. drm/i915: Allow dead vm to unbind vma's without lock. Matt Roper (4): drm/i915/dg2: Add Wa_18018781329 drm/i915/dg2: Add Wa_14015227452 drm/i915/dg2: s/engine->i915/i915/ for engine workarounds drm/i915: Introduce G12 subplatform of DG2 Matthew Auld (7): drm/i915: remove writeback hook drm/i915: clean up shrinker_release_pages drm/i915: don't call free_mmap_offset when purging drm/i915/ttm: only fault WILLNEED objects drm/i915/ttm: add unmap_virtual callback drm/i915/ttm: ensure we unmap when purging drm/i915/ttm: tweak priority hint selection Matthew Brost (11): drm/i915/execlists: Weak parallel submission support for execlists drm/i915: Fix possible uninitialized variable in parallel extension drm/i915: Increment composite fence seqno drm/i915/selftests: Add a cancel request selftest that triggers a reset drm/i915/guc: Remove hacks for reset and schedule disable G2H being received out of order drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL drm/i915/guc: Add work queue to trigger a GT reset drm/i915/guc: Flush G2H handler during a GT reset drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct drm/i915/selftests: Use less in contexts steal guc id test Michał Winiarski (5): drm/i915/gt: Use to_gt() helper for GGTT accesses drm/i915: Use to_gt() helper for GGTT accesses drm/i915/gem: Use to_gt() helper for GGTT accesses drm/i915/display: Use to_gt() helper for GGTT accesses drm/i915/selftests: Use to_gt() helper for GGTT accesses Ramalingam C (3): drm/i915/dg2: Add Wa_22011450934 drm/i915: align the plane_vma to min_page_size of stolen mem drm/i915: More gt idling time with guc submission Thomas Hellström (9): drm/i915: Initial introduction of vma resources drm/i915: Use the vma resource as argument for gtt binding / unbinding drm/i915: Don't pin the object pag
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here go drm-intel-fixes for v5.18-rc4. Two display fixes: Disable VRR if user disables it from panel settings and avoid claiming PSR2 is enabled when it is not supported by config. Regards, Joonas *** drm-intel-fixes-2022-04-20: - Unset enable_psr2_sel_fetch if PSR2 detection fails - Fix to detect when VRR is turned off from panel settings The following changes since commit b2d229d4ddb17db541098b83524d901257e93845: Linux 5.18-rc3 (2022-04-17 13:57:31 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-20 for you to fetch changes up to bb02330408a7bde33b5f46aa14fd5d7bfe6093b7: drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in intel_psr2_config_valid() fails (2022-04-20 07:51:14 +0300) - Unset enable_psr2_sel_fetch if PSR2 detection fails - Fix to detect when VRR is turned off from panel settings José Roberto de Souza (1): drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in intel_psr2_config_valid() fails Manasi Navare (1): drm/i915/display/vrr: Reset VRR capable property on a long hpd drivers/gpu/drm/i915/display/intel_dp.c | 17 +- drivers/gpu/drm/i915/display/intel_psr.c | 38 ++-- 2 files changed, 32 insertions(+), 23 deletions(-)
Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile
+ Tvrtko Quoting Jason Gunthorpe (2022-04-13 17:45:48) > On Wed, Apr 13, 2022 at 02:26:23PM +, Wang, Zhi A wrote: > > On 4/13/22 1:43 PM, Jason Gunthorpe wrote: > > > On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote: > > > > > >> It seems Jani's makefile clean patch has already included this one, I can > > >> just simply drop this one so that Christoph won't need to re-send > > >> everything. > > >> > > >> For the branch to move on, I am merging the patches and will re-generate > > >> the > > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and > > >> other > > >> gvt branches. > > >> > > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you > > >> can use > > >> gvt-staging branch until my pull request landed in drm-intel-next. > > >> > > >> Also our QA will test gvt-staging-branch before the pull request. I > > >> suppose > > >> it will take one or two days. > > > > > > When you are wrangling the branches it would be great if Christoph's > > > series and it's minimal dependencies could be on a single branch that > > > could reasonably be pulled to the VFIO tree too, thanks > > > > > > Jason > > > > > > > Hi Jason: > > > > I am thinking about the process of merging process. Here are the dependence: > > > > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to > > go through drm. > > My patches of GVT-g will go through drm-intel-next -> drm -> upstream. > > > > 2) Christoph's patches depends on my patches, but part of them are for VFIO. > > > > a. If they are fully going through VFIO repo, they might have to wait my > > patches to get landed first. > > > > b. If only the GVT-g parts goes through GVT repo, and rest of them goes > > through VFIO, the rest part still needs to wait. > > > > What would be a better process? > > You should organize everything onto one simple branch based on a rc to > make this all work. > > Make your #1 patch as a single patch PR based on rc to drm-intel so it > gets to the right tree > > Make your MMIO series as PR on the branch above that first PR and merge to > the gvt tree > > Make Christoph's series as a PR on the branch above the second PR's > MMIO series and merge to the gvt tree > > Merge the gvt toward DRM in the normal way - ie the main merge path for > this should be through DRM. > > Then ask Alex to merge the 3rd PR as well. > > I don't see any intel-next stuff in linux-next yet so hopefully it is > early enough to get #1 OK. > > Jason
Re: [PULL v2] gvt-next
+ Tvrtko Quoting Christoph Hellwig (2022-04-21 08:47:38) > On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote: > > Is it possible that I can send two different pull based on the same branch? > > I was thinking I can remove this line in the original patch and then add a > > small patch to add this line back on the top. Then make two different tags > > before and after that small patch, send one pull with tag that includes that > > small patch to i915 and the other pull with tag that doesn't includes it to > > VFIO? > > Yes, you can do that as long as the small fixup commit is the very last > one.
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here goes drm-intel-fixes PR for v5.18-rc5. Fixes for backlight control on XMG Core 15 e21 (#5284, regression since 5.15) and black display plane on Acer One AO532h. Then two smaller display fixes picked up by tooling. Regards, Joonas *** drm-intel-fixes-2022-04-28: - Fix #5284: Backlight control regression on XMG Core 15 e21 - Fix black display plane on Acer One AO532h - Two smaller display fixes - The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b: Linux 5.18-rc4 (2022-04-24 14:51:22 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-28 for you to fetch changes up to f7e1089f43761ca221914aea9a755b23dc7cbc33: drm/i915/fbc: Consult hw.crtc instead of uapi.crtc (2022-04-26 10:12:36 +0300) - Fix #5284: Backlight control regression on XMG Core 15 e21 - Fix black display plane on Acer One AO532h - Two smaller display fixes - Hans de Goede (1): drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines Imre Deak (1): drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses Jouni Högander (1): drm/i915: Check EDID for HDR static metadata when choosing blc Ville Syrjälä (1): drm/i915/fbc: Consult hw.crtc instead of uapi.crtc .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 34 +- drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- drivers/gpu/drm/i915/i915_reg.h| 6 ++-- 3 files changed, 30 insertions(+), 12 deletions(-)
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
NACK on this one. Let's get this reverted or fixed to eliminate
new module parameters.
What prevents us just from using the maximum sizes? Or alternatively
we could check the already existing drm.debug variable or anything else
but addding 3 new module parameters.
For future reference, please do Cc maintainers when adding new uAPI
like module parameters.
Regards, Joonas
Quoting john.c.harri...@intel.com (2022-07-28 05:20:27)
> From: John Harrison
>
> The GuC log buffer sizes had to be configured statically at compile
> time. This can be quite troublesome when needing to get larger logs
> out of a released driver. So re-organise the code to allow a boot time
> module parameter override.
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 42 +++--
> drivers/gpu/drm/i915/i915_params.c| 12 ++
> drivers/gpu/drm/i915/i915_params.h| 3 +
> 6 files changed, 226 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index ab4aacc516aa4..01f2705cb94a3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -224,53 +224,22 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
>
> static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
> {
> - u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
> - u32 flags;
> -
> - #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
> - #define LOG_UNIT SZ_1M
> - #define LOG_FLAG GUC_LOG_LOG_ALLOC_UNITS
> - #else
> - #define LOG_UNIT SZ_4K
> - #define LOG_FLAG 0
> - #endif
> -
> - #if (((CAPTURE_BUFFER_SIZE) % SZ_1M) == 0)
> - #define CAPTURE_UNIT SZ_1M
> - #define CAPTURE_FLAG GUC_LOG_CAPTURE_ALLOC_UNITS
> - #else
> - #define CAPTURE_UNIT SZ_4K
> - #define CAPTURE_FLAG 0
> - #endif
> -
> - BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, LOG_UNIT));
> - BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, LOG_UNIT));
> - BUILD_BUG_ON(!CAPTURE_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(CAPTURE_BUFFER_SIZE, CAPTURE_UNIT));
> -
> - BUILD_BUG_ON((CRASH_BUFFER_SIZE / LOG_UNIT - 1) >
> - (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
> - BUILD_BUG_ON((DEBUG_BUFFER_SIZE / LOG_UNIT - 1) >
> - (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
> - BUILD_BUG_ON((CAPTURE_BUFFER_SIZE / CAPTURE_UNIT - 1) >
> - (GUC_LOG_CAPTURE_MASK >> GUC_LOG_CAPTURE_SHIFT));
> + struct intel_guc_log *log = &guc->log;
> + u32 offset, flags;
> +
> + GEM_BUG_ON(!log->sizes_initialised);
> +
> + offset = intel_guc_ggtt_offset(guc, log->vma) >> PAGE_SHIFT;
>
> flags = GUC_LOG_VALID |
> GUC_LOG_NOTIFY_ON_HALF_FULL |
> - CAPTURE_FLAG |
> - LOG_FLAG |
> - ((CRASH_BUFFER_SIZE / LOG_UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
> - ((DEBUG_BUFFER_SIZE / LOG_UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
> - ((CAPTURE_BUFFER_SIZE / CAPTURE_UNIT - 1) <<
> GUC_LOG_CAPTURE_SHIFT) |
> + log->sizes[GUC_LOG_SECTIONS_DEBUG].flag |
> + log->sizes[GUC_LOG_SECTIONS_CAPTURE].flag |
> + (log->sizes[GUC_LOG_SECTIONS_CRASH].count <<
> GUC_LOG_CRASH_SHIFT) |
> + (log->sizes[GUC_LOG_SECTIONS_DEBUG].count <<
> GUC_LOG_DEBUG_SHIFT) |
> + (log->sizes[GUC_LOG_SECTIONS_CAPTURE].count <<
> GUC_LOG_CAPTURE_SHIFT) |
> (offset << GUC_LOG_BUF_ADDR_SHIFT);
>
> - #undef LOG_UNIT
> - #undef LOG_FLAG
> - #undef CAPTURE_UNIT
> - #undef CAPTURE_FLAG
> -
> return flags;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index b54b7883320b1..d2ac53d4f3b6e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -656,16 +656,17 @@ static void check_guc_capture_size(struct intel_guc
> *guc)
> struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> int min_size = guc_capture_output_min_size_est(guc);
> int spare_size = min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER;
> + u32 buffer_size = intel_guc_log_section_size_capture(&guc->log);
>
> if (min_size < 0)
> drm_warn(&i915->drm, "Failed to calculate GuC error state
> capture buffer minimum size: %d!\n",
> min_size);
> - else if (min_size > CAPTURE_BUFFER_SIZE)
> + else if (min_size > bu
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes the first drm-intel-gt-next PR towards 6.1. Quite a small one. As primary things, there's the parallel support of GuC v69 and v70 which already went in via -fixes, improvements to the TLB invalidation performance regressions, further DG2 enabling and improved debugging for GuC errors. On top of that, locking simplification for freeing objects to avoid potential system freeze, addition of gt/gtN/.defaults (including freq to start), silencing some messages that are not errors. Regards, Joonas PS. I left a few commits out from top of drm-intel-gt-next as there is fixup needed for at least one. I will include those in the next PR. *** drm-intel-gt-next-2022-08-24: UAPI Changes: - Create gt/gtN/.defaults/ for per gt sysfs defaults Create a gt/gtN/.defaults/ directory (similar to engine//.defaults/) to expose default parameter values for each gt in sysfs. This allows userspace to restore default parameter values after they have changed. Driver Changes: - Support GuC v69 in parallel to v70 (Daniele) - Improve TLB invalidation to limit performance regression (Chris, Mauro) - Expose per-gt RPS defaults in sysfs (Ashutosh) - Suppress OOM warning for shmemfs object allocation failure (Chris, Nirmoy) - Disable PCI resize on 32-bit machines (Nirmoy) - Update DG2 to GuC v70.4.1 (John) - Fix CCS data copying on DG2 during swapping (Matt A) - Add DG2 performance tuning setting recommended by spec (Matt R) - Add GuC <-> kernel time stamp translation information to error logs (John) - Record GuC CTB info in error logs (John) - Route semaphores to GuC for Gen12+ when enabled (Michal Wi, John) - Improve resilency to bug #3575: Handle reset timeouts under unrelated kernel hangs (Chris, Ashutosh) - Avoid system freeze by removing shared locking on freeing objects (Chris, Nirmoy) - Demote GuC error "No response for request" into debug when expected (Zhanjun) - Fix GuC capture size warning and bump the size (John) - Use streaming loads to speed up dumping the GuC log (Chris, John) - Don't abort on CTB_UNUSED status from GuC (John) - Don't send spurious policy update for GuC child contexts (Daniele) - Don't leak the CCS state (Matt A) - Prefer drm_err over pr_err (John) - Eliminate unused calc_ctrl_surf_instr_size (Matt A) - Add dedicated function for non-ctx register tuning settings (Matt R) - Style and typo fixes, documentation improvements (Jason Wang, Mauro) - Selftest improvements (Matt B, Rahul, John) The following changes since commit 17cd10a44a8962860ff4ba351b2a290e752dbbde: drm/i915: Add lmem_bar_size modparam (2022-07-13 17:47:51 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-08-24 for you to fetch changes up to 5ece208ab05e4042c80ed1e6fe6d7ce236eee89b: drm/i915/guc: Use streaming loads to speed up dumping the guc log (2022-08-17 10:07:03 -0700) UAPI Changes: - Create gt/gtN/.defaults/ for per gt sysfs defaults Create a gt/gtN/.defaults/ directory (similar to engine//.defaults/) to expose default parameter values for each gt in sysfs. This allows userspace to restore default parameter values after they have changed. Driver Changes: - Support GuC v69 in parallel to v70 (Daniele) - Improve TLB invalidation to limit performance regression (Chris, Mauro) - Expose per-gt RPS defaults in sysfs (Ashutosh) - Suppress OOM warning for shmemfs object allocation failure (Chris, Nirmoy) - Disable PCI resize on 32-bit machines (Nirmoy) - Update DG2 to GuC v70.4.1 (John) - Fix CCS data copying on DG2 during swapping (Matt A) - Add DG2 performance tuning setting recommended by spec (Matt R) - Add GuC <-> kernel time stamp translation information to error logs (John) - Record GuC CTB info in error logs (John) - Route semaphores to GuC for Gen12+ when enabled (Michal Wi, John) - Improve resilency to bug #3575: Handle reset timeouts under unrelated kernel hangs (Chris, Ashutosh) - Avoid system freeze by removing shared locking on freeing objects (Chris, Nirmoy) - Demote GuC error "No response for request" into debug when expected (Zhanjun) - Fix GuC capture size warning and bump the size (John) - Use streaming loads to speed up dumping the GuC log (Chris, John) - Don't abort on CTB_UNUSED status from GuC (John) - Don't send spurious policy update for GuC child contexts (Daniele) - Don't leak the CCS state (Matt A) - Prefer drm_err over pr_err (John) - Eliminate unused calc_ctrl_surf_instr_size (Matt A) - Add dedicated function for non-ctx register tuning settings (Matt R) - Style and typo fixes, documentation improvements (Jason Wang, Mauro) - Selftest improvements (Matt B, Rahul, John) Alan Previn (1): drm/i915/guc: Add a helper for log buffer size Ashutosh Dixit (2): drm/i915/gt: Create gt/gtN/.defaults/ for per gt sysfs defaults drm/i915/
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
Quoting John Harrison (2022-08-24 21:45:09)
> On 8/24/2022 02:01, Joonas Lahtinen wrote:
> > NACK on this one. Let's get this reverted or fixed to eliminate
> > new module parameters.
> >
> > What prevents us just from using the maximum sizes? Or alternatively
> > we could check the already existing drm.debug variable or anything else
> > but addding 3 new module parameters.
> We don't want to waste 24MB of memory for all users when 99.999% of them
> don't care about GuC logs.
It is not exactly wasting memory if it is what is needed to capture
the error logs to properly debug a system. And it's definitely not much
on any modern system where you will have a GPU. You can always leave
the Kconfig options in place for the cases where it matters.
On the other hand, if 99.999% don't need this, then it could just stay
as a kernel config time option as well?
> We also don't want to tie the GuC logging buffer size to the DRM
> debugging output. Enabling kernel debug output can change timings and
> prevent the issue that one is trying to capture in the GuC log. And it
> seems unlikely we could add an entire new top level DRM debug flag just
> for an internal i915 only log buffer size. Plus drm.debug is explicitly
> stated as being dynamically changeable via sysfs at any time. The GuC
> log buffer size cannot be changed without reloading the i915 driver. Or
> at least, not without reloading the GuC, but we definitely don't want to
> create a UAPI for arbitrarily reloading the GuC.
>
> We can make these parameters 'unsafe' so that they taint the kernel if
> used. But this is exactly what module parameters are for - configuration
> that we don't want to hardcode as CONFIG options but which must be set
> at module load time.
It's better to have sane defaults. And if somebody wants something
strange, they can have a Kconfig behind EXPERT option. But even then
there should really be need for it.
So for now, let's get the module parameters reverted and go with
reasonable default buffer sizes when GuC is enabled. The compile time
options can be left in place.
Thank you in advance.
Regards, Joonas
>
> John.
>
> >
> > For future reference, please do Cc maintainers when adding new uAPI
> > like module parameters.
> >
> > Regards, Joonas
> >
> > Quoting john.c.harri...@intel.com (2022-07-28 05:20:27)
> >> From: John Harrison
> >>
> >> The GuC log buffer sizes had to be configured statically at compile
> >> time. This can be quite troublesome when needing to get larger logs
> >> out of a released driver. So re-organise the code to allow a boot time
> >> module parameter override.
> >>
> >> Signed-off-by: John Harrison
> >> ---
> >> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++
> >> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +-
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176 +-
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 42 +++--
> >> drivers/gpu/drm/i915/i915_params.c| 12 ++
> >> drivers/gpu/drm/i915/i915_params.h| 3 +
> >> 6 files changed, 226 insertions(+), 74 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> index ab4aacc516aa4..01f2705cb94a3 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> @@ -224,53 +224,22 @@ static u32 guc_ctl_feature_flags(struct intel_guc
> >> *guc)
> >>
> >> static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
> >> {
> >> - u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >>
> >> PAGE_SHIFT;
> >> - u32 flags;
> >> -
> >> - #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
> >> - #define LOG_UNIT SZ_1M
> >> - #define LOG_FLAG GUC_LOG_LOG_ALLOC_UNITS
> >> - #else
> >> - #define LOG_UNIT SZ_4K
> >> - #define LOG_FLAG 0
> >> - #endif
> >> -
> >> - #if (((CAPTURE_BUFFER_SIZE) % SZ_1M) == 0)
> >> - #define CAPTURE_UNIT SZ_1M
> >> - #define CAPTURE_FLAG GUC_LOG_CAPTURE_ALLOC_UNITS
> >> - #else
> >> - #define CAPTURE_UNIT SZ_4K
> >> - #define CAPTURE_FLAG 0
> >> - #endif
> >> -
> >> - BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
> >> - BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, LOG_UNIT));
> >> -
[PULL] drm-intel-fixes
Hi Dave & Daniel, One fix for memory corruption under heavy load (#5732, Cc: stable). Regards, Joonas *** drm-intel-fixes-2022-05-12: Fix for #5732: (Cc stable) kernel memory corruption when running a lot of OpenCL tests in parallel The following changes since commit c5eb0a61238dd6faf37f58c9ce61c9980aaffd7a: Linux 5.18-rc6 (2022-05-08 13:54:17 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-05-12 for you to fetch changes up to 3220c3b2115102bb35f8f07d90d2989a3f5eb452: drm/i915: Fix race in __i915_vma_remove_closed (2022-05-09 10:36:49 +0300) Fix for #5732: (Cc stable) kernel memory corruption when running a lot of OpenCL tests in parallel Karol Herbst (1): drm/i915: Fix race in __i915_vma_remove_closed drivers/gpu/drm/i915/i915_vma.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, Two final -fixes for v5.18. One is to reject DMC with out-of-spec MMIO (Cc: stable) and another to correctly mark guilty contexts on GuC reset. Regards, Joonas *** drm-intel-fixes-2022-05-19: - Reject DMC firmware with out-of-spec MMIO addresses. - Correctly mark guilty context on GuC reset The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-05-19 for you to fetch changes up to 89e96d822bd51f7afe2d3e95a34099480b5c3d55: i915/guc/reset: Make __guc_reset_context aware of guilty engines (2022-05-16 10:13:39 +0300) - Reject DMC firmware with out-of-spec MMIO addresses. - Correctly mark guilty context on GuC reset Anusha Srivatsa (1): drm/i915/dmc: Add MMIO range restrictions Umesh Nerlige Ramappa (1): i915/guc/reset: Make __guc_reset_context aware of guilty engines drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++ drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 16 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +- drivers/gpu/drm/i915/i915_reg.h | 16 + 7 files changed, 72 insertions(+), 12 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, Here's the previous PR + additional fix for regression #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45. Was also discussed here: https://lore.kernel.org/all/CAHk-=wj0ghsg6iw3d8ufptm9a_dvtsqrrofy9wopobbybyu...@mail.gmail.com/ Regards, Joonas *** drm-intel-fixes-2022-05-20: - Previous PR + fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45 The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-05-20 for you to fetch changes up to 7b1d6924f27ba24b9e47abb9bd53d0bbc430a835: drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap (2022-05-19 12:49:49 +0300) - Previous PR + fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45 Anusha Srivatsa (1): drm/i915/dmc: Add MMIO range restrictions Maarten Lankhorst (1): drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap Umesh Nerlige Ramappa (1): i915/guc/reset: Make __guc_reset_context aware of guilty engines drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++-- drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 16 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +- drivers/gpu/drm/i915/i915_reg.h | 16 + 8 files changed, 74 insertions(+), 16 deletions(-)
[PULL] drm-intel-fixes
Hi Dave & Daniel, Just one fix towards v5.18-rc3. Fix to align code with drm-tip to make sure full graphics IP version is used for legacy mmap disable check. Regards, Joonas *** drm-intel-fixes-2022-04-13: - Correct legacy mmap disabling to use GRAPHICS_VER_FULL The following changes since commit ce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e: Linux 5.18-rc2 (2022-04-10 14:21:36 -1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-13 for you to fetch changes up to 1acb34e7dd7720a1fff00cbd4d000ec3219dc9d6: drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL (2022-04-11 09:11:21 +0300) - Correct legacy mmap disabling to use GRAPHICS_VER_FULL Matt Roper (1): drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH v7 7/9] drm/ttm: Add a parameter to add extra pages into ttm_tt
(+ Tvrtko and Jani)
Quoting Ramalingam C (2022-04-02 06:02:38)
> On 2022-04-01 at 16:31:19 +0200, Christian König wrote:
> > I would be nicer to push this through drm-misc-next, but the intel branch
> > works for me as well.
> Hi Christian
>
> I have pushed this patch into drm-misc-next.
I've now backmerged drm-next containing this commit to drm-intel-gt-next
in order to unblock merging the rest of the series.
> Regards,
> Ram.
> >
> > Regards,
> > Christian.
> >
> > Am 01.04.22 um 16:28 schrieb Ramalingam C:
> > > Christian, Joonas and vivi
> > >
> > > Once the premerge results are greeen, if this patch can be merged into
> > > drm-intel-gt-next along with other patches could you please ack the
> > > request to merge into drm-intel-gt-next?
For future reference, when in doubt who are the right ones to handle,
add all the maintainers and wait for them to reply before proceeding.
Then we can avoid some unnecessary churn where there are more
straightforward options like here: merge via drm-intel-gt-next as
nobody else needs the new functions yet.
Regards, Joonas
> > > Thanks
> > > Ram
> > >
> > > On 2022-04-01 at 18:07:49 +0530, Ramalingam C wrote:
> > > > Add a parameter called "extra_pages" for ttm_tt_init, to indicate that
> > > > driver needs extra pages in ttm_tt.
> > > >
> > > > v2:
> > > >Used imperative wording [Thomas and Christian]
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > cc: Christian Koenig
> > > > cc: Hellstrom Thomas
> > > > Reviewed-by: Thomas Hellstrom
> > > > Reviewed-by: Christian Konig
> > > > Reviewed-by: Nirmoy Das
> > > > ---
> > > > drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
> > > > drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> > > > drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
> > > > drivers/gpu/drm/ttm/ttm_tt.c | 12 +++-
> > > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
> > > > include/drm/ttm/ttm_tt.h | 4 +++-
> > > > 7 files changed, 15 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > index dc7f938bfff2..123045b58fec 100644
> > > > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > @@ -867,7 +867,7 @@ static struct ttm_tt
> > > > *bo_driver_ttm_tt_create(struct ttm_buffer_object *bo,
> > > > if (!tt)
> > > > return NULL;
> > > > - ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
> > > > + ret = ttm_tt_init(tt, bo, page_flags, ttm_cached, 0);
> > > > if (ret < 0)
> > > > goto err_ttm_tt_init;
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > index c40aca99442f..a878910a563c 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > @@ -293,7 +293,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct
> > > > ttm_buffer_object *bo,
> > > > i915_tt->is_shmem = true;
> > > > }
> > > > - ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching);
> > > > + ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching, 0);
> > > > if (ret)
> > > > goto err_free;
> > > > diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > index 95df5750f47f..9ba871bd19b1 100644
> > > > --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > @@ -113,7 +113,7 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
> > > > ttm_buffer_object *bo,
> > > > ttm = kzalloc(sizeof(struct ttm_tt), GFP_KERNEL);
> > > > if (ttm == NULL)
> > > > return NULL;
> > > > - if (ttm_tt_init(ttm, bo, page_flags, ttm_cached)) {
> > > > + if (ttm_tt_init(ttm, bo, page_flags, ttm_cached, 0)) {
> > > > kfree(ttm);
> > > > return NULL;
> > > > }
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > index 6ddc16f0fe2b..d27691f2e451 100644
> > > > --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > @@ -134,7 +134,7 @@ struct ttm_tt *ttm_agp_tt_create(struct
> > > > ttm_buffer_object *bo,
> > > > agp_be->mem = NULL;
> > > > agp_be->bridge = bridge;
> > > > - if (ttm_tt_init(&agp_be->ttm, bo, page_flags, ttm_write_combined)) {
> > > > + if (ttm_tt_init(&agp_be->ttm, bo, page_flags, ttm_write_combined, 0))
> > > > {
> > > > kfree(agp_be);
> > > > return NULL;
> > > > }
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > > > index d234aab800a0..1a66d9fc589a 100644
> > > > --- a/drivers/gpu/drm/ttm/ttm_tt.c
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
Quoting John Harrison (2022-08-25 19:31:39) > On 8/25/2022 00:15, Joonas Lahtinen wrote: > > Quoting John Harrison (2022-08-24 21:45:09) > >> On 8/24/2022 02:01, Joonas Lahtinen wrote: > >>> NACK on this one. Let's get this reverted or fixed to eliminate > >>> new module parameters. > >>> > >>> What prevents us just from using the maximum sizes? Or alternatively > >>> we could check the already existing drm.debug variable or anything else > >>> but addding 3 new module parameters. > >> We don't want to waste 24MB of memory for all users when 99.999% of them > >> don't care about GuC logs. > > It is not exactly wasting memory if it is what is needed to capture > > the error logs to properly debug a system. And it's definitely not much > > on any modern system where you will have a GPU. You can always leave > > the Kconfig options in place for the cases where it matters. > > > > On the other hand, if 99.999% don't need this, then it could just stay > > as a kernel config time option as well? > No. The point is that we need to able to ask customers to increase the > log size, repro an issue and send us the results. Or we could just ask them to provide the logs for each bug report and save one round trip time. > All on a pre-installed > system where they do not have the option to build a custom kernel. If you argue that way, they don't always have an easy way to change the kernel cmdline options either. Accounting for initrd, update-grub etc. > Either we always allocate the maximum and waste the memory for all end > users or we have a runtime configuration option. Doesn't have to be maximum (as there seems to be limitations in log readback speeds also), just something that is useful for most of the debug scenarios. > Compile time is not > acceptable for some important customers/situations. Yet spending the time discussing how to make the debug logs useful with the issue reporter wouldn't be an issue in such urgency? One can argue what is most convenient way, but there's no way to beat sane default. If somebody has problem with that extra memory usage, then we have the config options to reduce/disable. > >> We also don't want to tie the GuC logging buffer size to the DRM > >> debugging output. Enabling kernel debug output can change timings and > >> prevent the issue that one is trying to capture in the GuC log. And it > >> seems unlikely we could add an entire new top level DRM debug flag just > >> for an internal i915 only log buffer size. Plus drm.debug is explicitly > >> stated as being dynamically changeable via sysfs at any time. The GuC > >> log buffer size cannot be changed without reloading the i915 driver. Or > >> at least, not without reloading the GuC, but we definitely don't want to > >> create a UAPI for arbitrarily reloading the GuC. > >> > >> We can make these parameters 'unsafe' so that they taint the kernel if > >> used. But this is exactly what module parameters are for - configuration > >> that we don't want to hardcode as CONFIG options but which must be set > >> at module load time. > > It's better to have sane defaults. And if somebody wants something > > strange, they can have a Kconfig behind EXPERT option. But even then > > there should really be need for it. > Define sane. I was hoping you would be the expert on that as you've suggested the patch to begin with. Try to aim to cover >90% of the debug scenarios (that are only 0.001%) and we're already only needing to recompile kernel in 1 per million cases. We can live with that. I will push a fixup to remove the module parameters, please figure the rest out in a timely manner. Regards, Joonas > > Sane for most users is to not allocate 24MB of memory for an internal > debug only buffer they will never use. And which completely swamps any > error capture log with the ASCII encoding of said buffer. > > But as above, we need a way to (very occasionally) get larger GuC logs > from customers without rebuilding the kernel. > > John. > > > > > So for now, let's get the module parameters reverted and go with > > reasonable default buffer sizes when GuC is enabled. The compile time > > options can be left in place. > > > > Thank you in advance. > > > > Regards, Joonas > > > >> John. > >> > >>> For future reference, please do Cc maintainers when adding new uAPI > >>> like module parameters. > >>> > >>> Regards, Joonas > >>> > >>> Quotin
