On Thu, May 07, 2020 at 09:56:49AM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 06:15:28PM +0300, Imre Deak wrote:
> > On Wed, Mar 11, 2020 at 05:54:20PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Let's get rid of the platform if ladders in
> > >
The submit-fence adds a weak dependency to the requests, and for the
purpose of our FQ_CODEL hinting we do not want to treat as a
restriction. This is primarily because clients may treat submit-fences
as a bidirectional bonding between a pair of co-ordinating requests.
Signed-off-by: Chris Wilson
Clients may use a submit-fence as bidirectional bond between two or more
co-operating requests, and so if we bump the priority of one, we wish to
bump the priority of the set.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
1 file changed, 6
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in
On Wed, May 06, 2020 at 02:14:05PM -0700, Matt Roper wrote:
> There are a couple places in our driver that loop over transcoders A..D
> for gen11+; since RKL only has three pipes/transcoders, this can lead to
> unclaimed register reads/writes. We should add checks for transcoder
> existence where
Hi, Dave, Daniel,
this is the third pull request for drm-misc-next for what will become
v5.8. AFAICT the highlights are the new managed allocation for DRM device
structures; optimizations in drm_mm, and Lima got runtime PM support.
Best regards
Thomas
drm-misc-next-2020-05-07:
drm-misc-next for
Quoting Chris Wilson (2020-05-06 15:36:16)
> Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
> timeslicing, as we do not treat it as a preemption request but as a soft
> ordering hint. If we apply the hint, then when we recompute the ordering
> after unwinding for the timeslice, we
On Wed, May 06, 2020 at 02:23:23PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Different platforms have different max vswing/preemph settings.
> Turn that into a pair vfuncs so we can decouple intel_dp.c and
> intel_ddi.c further.
Forgot to mention that it not only depends on the
On Wed, May 06, 2020 at 06:15:28PM +0300, Imre Deak wrote:
> On Wed, Mar 11, 2020 at 05:54:20PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's get rid of the platform if ladders in
> > intel_digital_port_connected() and make it a vfunc. Now the if
> > ladders are at the
On Wed, May 06, 2020 at 07:03:41PM +0300, Imre Deak wrote:
> On Wed, Mar 11, 2020 at 05:54:21PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Instead of constnantly having to figure out which hpd status bit
> > array to use let's store them under dev_priv.
> >
> > Should perhaps
Quoting Mika Kuoppala (2020-05-06 17:53:10)
> Aux table invalidation can fail on update. So
> next access may cause memory access to be into stale entry.
>
> Proposed workaround is to invalidate entries between
> all batchbuffers.
>
> v2: correct register address (Yang)
> v3: respect the order
On Fri, Mar 06, 2020 at 05:26:00PM -0800, Lucas De Marchi wrote:
> This avoids the annoying message
> "Failed to get panel details from OpRegion (-19)" while initializing.
> On DGFX there is no access to OpRegion, so just avoid any calls related
> to it.
>
> Signed-off-by: Lucas De Marchi
> ---
101 - 112 of 112 matches
Mail list logo
