On Wed, Mar 22, 2017 at 02:40:01PM -0300, Paulo Zanoni wrote:
> Em Qua, 2017-03-22 às 15:21 +0200, Ville Syrjälä escreveu:
> > On Tue, Mar 21, 2017 at 06:57:10PM -0300, Paulo Zanoni wrote:
> > >
> > > Because {hsw,skl,bxt}_ddi_pll_select all pretty much do the same
> > > thing
> > > in slightly di
On Wed, Mar 22, 2017 at 04:05:59PM +0200, Jani Nikula wrote:
> On Wed, 22 Mar 2017, Daniel Vetter wrote:
> > On Wed, Mar 22, 2017 at 12:33:35PM +0200, Jani Nikula wrote:
> >> On Wed, 22 Mar 2017, Daniel Vetter wrote:
> >> > There's really no reason for anything more:
> >> > - Calling this while t
On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > To match the drm_ioctl.c we already have.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 1 +
> > include/drm/drmP.h | 6
On Wed, Mar 22, 2017 at 06:56:32PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > > To match the drm_ioctl.c we already have.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> >
On Wed, Mar 22, 2017 at 09:36:13AM +0100, Daniel Vetter wrote:
> It's overkill to have a flag parameter which is essentially used just
> as a boolean. This takes care of core + adjusting drivers.
>
> Adjusting the scanout position callback is a bit harder, since radeon
> also supplies it's own dri
Daniel Vetter writes:
> Just drive-by, but we have gsoc running so better to update it now.
>
> Great news is that two entries can be removed because essentially all
> done.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 51
> -
On Tue, Mar 21, 2017 at 01:26:23PM -0700, Ben Widawsky wrote:
> On 17-03-21 20:12:15, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >Allow framebuffers dimesions to be misaligned w.r.t. the subsampling
> >factors. No real reason the core should have to enforce this, and
> >it definitely starts
Because {hsw,skl,bxt}_ddi_pll_select all pretty much do the same thing
in slightly different ways. Replace everything with a simple copy of
the function and inline it inside intle_ddi_pll_select().
v2: s/return pll/return pll != NULL/ (Ville)
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanon
All it does is pick the encoder and call intel_get_shared_dpll(). We
can just do this in the caller. One less indirection level during code
reading.
As another plus, now the two callers of intel_get_shared_dpll() are
{ironlake,haswell}_crtc_compute_clock().
Reported-by: Ville Syrjälä
Signed-off-
On Wed, Mar 22, 2017 at 03:58:45PM -0300, Paulo Zanoni wrote:
> All it does is pick the encoder and call intel_get_shared_dpll(). We
> can just do this in the caller. One less indirection level during code
> reading.
>
> As another plus, now the two callers of intel_get_shared_dpll() are
> {ironla
Daniel Vetter writes:
> It's the default storage class for functions, entirely redundant. And
> a lot of these headers are a bit inconsistent due to organically
> grown.
>
Reviewed-by: Gabriel Krisman Bertazi
--
Gabriel Krisman Bertazi
___
Intel-gf
On Wed, Mar 22, 2017 at 02:24:51PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:11:58PM +0200, Joonas Lahtinen wrote:
> > On ke, 2017-03-22 at 11:05 +, Chris Wilson wrote:
> > > Since gfx allocations tend to be large, unmovable and disposable, report
> > > the allocation failure bac
Daniel Vetter writes:
> I've decided to not document drm_debugfs_remove_files, it's on the way
> out.
>
> The biggest part is a huge todor.rst entry with what all should be
> improved.
todo.rst
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-uapi.rst | 9
> Documentat
Hi,
Any idea what's going on?
>
> For now, I had to go back:
> saruman:/var/cache/apt/archives# dpkg -i xserver-xorg-video-intel_2%
> 3a2.99.917+git20160218-1_amd64.deb xserver-xorg-video-intel-dbg_
> 2%3a2.99.917+git20160218-1_amd64.deb xserver-common_2%3a1.18.1-1_all.deb
> xserver-xorg-core_2%3a
On Wed, Mar 22, 2017 at 04:06:32PM +0100, Mario Kleiner wrote:
> On 03/15/2017 10:00 PM, Ville Syrjälä wrote:
> > On Wed, Mar 15, 2017 at 08:40:25PM +, Chris Wilson wrote:
> >> On vblank instant-off systems, we can get into a situation where the cost
> >> of enabling and disabling the vblank IR
On Wed, Mar 22, 2017 at 03:34:10PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:03AM +0100, Daniel Vetter wrote:
> > Doc polish will follow in the next patch.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_debugfs.c | 5 ++-
> > include/drm/drmP.h
On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > To match the drm_ioctl.c we already have.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 1 +
> > include/drm/drmP.h | 6
On Wed, Mar 22, 2017 at 11:51:56AM +0200, Ander Conselvan De Oliveira wrote:
> On Wed, 2017-03-22 at 10:01 +0100, Maarten Lankhorst wrote:
> > Op 14-03-17 om 16:10 schreef ville.syrj...@linux.intel.com:
> > > From: Ville Syrjälä
> > >
> > > Use intel_wm_plane_visible() to determine cursor visibil
On Wed, Mar 22, 2017 at 09:15:23PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > > To match the drm_ioctl.c we already have.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> >
On Wed, Mar 22, 2017 at 03:31:00PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter writes:
>
> > Just drive-by, but we have gsoc running so better to update it now.
> >
> > Great news is that two entries can be removed because essentially all
> > done.
> >
> > Signed-off-by: Daniel Vetter
On Wed, 2017-03-22 at 13:30 +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
> > From: "Pandiyan, Dhinakaran"
> >
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
On Wed, Mar 22, 2017 at 01:30:30PM +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
> Is there any issue into attempting to release vcpi slots when they're already
> released? If not, for patches 1-3 5-8
>
> Reviewed-by: Maarten Lankhorst
Merged patches 1-3 to
Doc polish will follow in the next patch.
v2: Put the include guard #endif at the end (Ville).
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs.c | 5 ++-
include/drm/drmP.h| 44 +
include/drm/drm_debugfs.h | 77 +++
I've decided to not document drm_debugfs_remove_files, it's on the way
out.
The biggest part is a huge todo.rst entry with what all should be
improved.
v2: Nits from Gabriel.
Cc: Gabriel Krisman Bertazi
Reviewed-by: Gabriel Krisman Bertazi
Signed-off-by: Daniel Vetter
---
Documentation/gpu/d
To match the drm_ioctl.c we already have.
v2: Remove spurious space (Ville).
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 1 +
include/drm/drmP.h | 61 +-
include/drm/drm_ioctl.h | 102 +
Just drive-by, but we have gsoc running so better to update it now.
Great news is that two entries can be removed because essentially all
done.
v2: Keep a bunch of the todos, Gabriel is working on them.
Cc: Gabriel Krisman Bertazi
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst |
There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
bug. Those places arlready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (callin
drm_crtc_handle_vblank at the wrong time) or a core bug (for
anything else).
If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:
- All legacy drivers look at crtc->hwmode. But that is update already
at the beginning of the modeset helper, which means when we disable
a pipe. Hence th
Commit e8a9c58fcd9a ("drm/i915: Unify active context tracking between
legacy/execlists/guc") converted the legacy intel_ringbuffer submission
to the same context pinning mechanism as execlists - that is to pin the
context until the subsequent request is retired. Previously it used the
vma retiremen
On Wed, Mar 22, 2017 at 09:53:36PM +0100, Daniel Vetter wrote:
> Doc polish will follow in the next patch.
>
> v2: Put the include guard #endif at the end (Ville).
>
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_debugfs.c | 5 ++-
Why have both hw_flags and flags, when just one will do?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
i
On Wed, 2017-03-22 at 11:00 +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
> > From: "Pandiyan, Dhinakaran"
> >
> > It is necessary to track states for objects other than connector, crtc
> > and plane for atomic modesets. But adding objects like DP MST link
> >
On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
[...]
> > @@ -2437,11 +2476,16 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config
On Wed, Mar 22, 2017 at 10:06 PM, Thierry Reding
wrote:
> On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
>> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
> [...]
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> > b/drivers/gpu/drm/drm_fb_helper.c
> [...]
>> >
Hi all,
This is something I kinda had on my todo list ever since atomic landed. The
legacy_backoff() hack really doesn't work if you need to acquire additional
locks, which does restrict drivers in how they handle and protect legacy paths,
and kinda forces us to be overzealous with taking locks fo
This way I can explain why it'll be fine to pass a NULL acquire ctx
here in the next patch.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 8a4e75929810..67119
This is just prep work to get an acquire ctx into every place where we
call ->update_plane or ->disable_plane.
v2: Keep the hidden acquire_ctx pointers valid while transitioning.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 52 -
1 f
Just rolling it out, no code change here.
Cc: Ben Skeggs
Cc: Russell King
Cc: Rob Clark
Cc: Laurent Pinchart
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_overlay.c| 3 ++-
drivers/gpu/drm/drm_atomic_helper.c| 4 +++-
drivers/gpu/drm/drm_plane.c
We can now properly retry at the top level, yay!
v2: Also remove the temporary acquire_ctx hack again, no longer
needed!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 49 ++---
drivers/gpu/drm/drm_plane.c | 2 --
2 files changed,
Again this is an internal helper, not the official way to lock a crtc.
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
Yes the help text is unhelpful, but atomic drivers should never use
this. Just grab the lock without context or anything.
Also an aside: Checking ->active like this doesn't protect against
nonblocking commits, this is rather bogus.
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gp
This is only for legacy paths that need to grab the crtc/plane lock
combo. If you want to lock a crtc, just use drm_modeset_lock().
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 3 +++
drivers/gpu/drm/drm_modeset_lock.c | 14 --
include/drm/drm_modeset_lock
Nouveau had a few direct calls to ->disable_plane, I replaced those
with drm_plane_force_disable. Same story for shmob.
Otherwise no code changes.
Cc: Ben Skeggs
Cc: Russell King
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_overlay.c| 3 ++-
driver
It's been around forever, no one bothered to address the FIXME, so I
presume it's all fine.
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/v
Again just prep work.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 8535dc17db7e..62e833ffeffd 100644
--- a/drivers/gpu/drm/dr
The last user, the cursor ioctl, can just open-code this too. We
simply have to move the acquire ctx dance from the universal function
up into the top-level ioctl handler.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 3 --
drivers/gpu/drm/drm_modeset_lock.c | 67 -
Again just going through the motions, no functional changes in here.
Cc: Gerd Hoffmann
Cc: Ben Skeggs
Cc: Russell King
Cc: Laurent Pinchart
Cc: Eric Anholt
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Daniel Vetter t
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++-
drivers/g
Surprisingly a lot of legacy drivers roll their own, for
runtime pm and because vmwgfx.
Also make nouveau's set_config static while at it.
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Cc: Ben Skeggs
Cc: Patrik Jakobsson
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drive
This is another case where we really can't reconstruct a acquire ctx
in any useful fashion because all the callers are legacy drivers. So
like drm_plane_force_disable simply restrict it to non-atomic drivers
so that it's clear we're ok with passing a NULL ctx.
Signed-off-by: Daniel Vetter
---
dr
Another one bites the dust.
Again let's not forget to remove the temporary hidden acquire_ctx
assignment, now that we pass this all around explicitly it can go
away again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 21 ++---
drivers/gpu/drm/drm_crtc.c
No need to grab both plane and crtc locks at the same time, we can do
them one after the other. If userspace races it'll get what it
deserves either way.
This removes another user of drm_modeset_lock_crtc. There's only one
left.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 6 ++
Just the groundwork to have something to feed into ->set_config.
Again we need a temporary hack to still fill out the legacy
ctx in mode_config.acquire_ctx.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(
Yay, we can now properly retry in case of deadlocks or whatever!
Also don't forget to remove the transitional crtc->acquire_ctx
assignment again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 40 ++---
drivers/gpu/drm/drm_plane.c
With all the callers of drm_modeset_lock_crtc gone, and all the places
it was formerly used properly wiring the acquire ctx through, we can
remove this.
The only hidden context magic we still have is now the global one.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 14
From: "Pandiyan, Dhinakaran"
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and cle
Words cannot describe the embarrassment at creating a new gfp_t relaim to
only prevent the oomkiller but allow direct|kswapd reclaim, and then not
use it in the shmem_read_mapping_page_gfp().
Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the
oom for gfx allocations")
S
This patch enables dynamic backlight by default for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.
Cc: Jani Nikula
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 31 +
This patch adds the following definition
- Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap
register which only use bit 0:4
- Base frequency (27 MHz) for backlight PWM frequency
generator.
Cc: Jani Nikula
Signed-off-by: Puthikorn Voravootivat
---
include/drm/drm_dp_helper.h | 2 ++
1 file
Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to match
that frequency as close as possible.
Cc: Jani Nikula
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 56 +++
1
intel_dp_aux_enable_backlight() assumed that the register
BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
(DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.
This patch fixed that by handling all cases of that register.
Cc: Jani Nikula
Signed-off-by: Puthikorn Voravootivat
---
driv
Some panel will default to zero brightness when turning the
panel off and on again. This patch stores last brightness level
before turning off and set them back when panel is turning on.
Cc: Jani Nikula
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 2
Rebase since this is not applied cleanly now.
This patch set contain 6 patches.
- First two patches allow enable DPCD backlight control when panel
can also do that via PWM pin and fix the usage of enable register.
- Next patch adds enable DBC by default
- Next patch makes the driver restore last
Currently the intel_dp_aux_backlight driver requires eDP panel
to not also support backlight adjustment via PWM pin to use
this driver.
This force the eDP panel that support both ways of backlight
adjustment to do it via PWM pin.
This patch adds the new prefer DPCD mode in the i915_param
to make
From: Clint Taylor
Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
signal if the Data Link N is greater than 0x8.
Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum
value 20 bit instead of the maximum specification supported 24 bit value.
When initializing the GuC log struct, there is an object we need to
allocate always, since the GuC needs its address at fw load time.
The rest is only needed during runtime, in the sense that we only
create if we actually enable GuC logging. Make that distinction
explicit by subdividing further the
We are going to need it for future platforms.
Cc: Joonas Lahtinen
Signed-off-by: Oscar Mateo
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_guc_submission.c | 4 ++--
drivers/gpu/drm/i915/intel_guc_fwif.h | 15 ---
2 files changed, 10 insertions(+), 9 delet
Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go
to zero after updating db_status before we call the GuC to release the
doorbell.
Kudos to Daniele for finding this out.
v2: WARN instead of DRM_ERROR (Joonas)
Signed-off-by: Oscar Mateo
Reviewed-by: Daniele Ceraolo Spurio
It's mandatory and it gets created if and only if GuC submission is enabled, so
that should be
the condition for informing the GuC about it.
Also s/guc_addon_create/guc_ads_create and s/guc_addon_destroy/guc_ads_destroy
and, while
at it, add an explanation of what things go inside the ADS object
Some recent refactoring patches have left the doorbell creation outside
the GuC client allocation, which does not make a lot of sense (a client
without a doorbell is something useless). Move it back there, and
refactor the init_doorbell_hw consequently.
Thanks to this, we can do some other improve
While at it, fix a typo (s/ring_lcra/ring_lrca) and improve the naming of one
firware interface field (s/ring_tail/submit_element_info, since it can contain
more than just the ring tail).
No change in functionality.
v2:
- Remove reference to "unique user" of the GuC (Daniele)
- Keep mention t
This is just for CI testing, do not merge.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_params.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..abd2894 100644
--- a/dr
Another go at it.
Joonas Lahtinen (1):
drm/i915/guc: Sanitize GuC client initialization
Oscar Mateo (12):
drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access
drm/i915/guc: Add onion teardown to the GuC setup
drm/i915/guc: The Additional Data Struct (ADS) should get enabled
t
The GuC descriptor is big in size. If we use a local definition of
guc_desc we have a chance to overflow stack, so avoid it.
Also, Chris abhors scatterlists :)
v2: Rebased, helper function to retrieve the context descriptor,
s/ctx_pool_vma/ctx_pool/
v3: Zero out guc_context_desc before initializ
A GuC context and a HW context are in no way related, so the name "GuC context
descriptor"
is very unfortunate, because a new reader of the code gets overwhelmed very
quickly with
a lot of things called "context" that refer to different things. We can improve
legibility
a lot by simply renaming
Prepare for an alternate GuC communication interface.
v2: Make a few functions static and name them correctly while we are at it
(Oscar), but
leave an intel_guc_send_mmio interface for users that require old-style
communication.
v3: Send intel_uc_init_early back to the top (Michal).
Signed-off
Starting with intel_guc_loader, down to intel_guc_submission
and finally to intel_guc_log.
v2:
- Null execbuf client outside guc_client_free (Daniele)
- Assert if things try to get allocated twice (Daniele/Joonas)
- Null guc->log.buf_addr when destroyed (Daniele)
- Newline between returnin
They go better together.
Cc: Joonas Lahtinen
Signed-off-by: Oscar Mateo
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_guc_submission.c | 48 +++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submissi
From: Joonas Lahtinen
Started adding proper teardown to guc_client_alloc, ended up removing
quite a few dead ends where errors communicating with the GuC were
silently ignored. There also seemed to be quite a few erronous
teardown actions performed in case of an error (ordering wrong).
v2:
- I
>-Original Message-
>From: Taylor, Clinton A
>Sent: Wednesday, March 22, 2017 4:28 PM
>To: Intel-gfx@lists.freedesktop.org
>Cc: Taylor, Clinton A ; Nikula, Jani
>; Srivatsa, Anusha
>Subject: [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi
>converters
>
>From: Clint Taylor
On Wed, Mar 22, 2017 at 04:27:36PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
> signal if the Data Link N is greater than 0x8.
> Patch detects when 1 lane 5.4 GHz signal is being used and makes
On 22/03/17 07:06 PM, Chris Wilson wrote:
> Move the repeated (a - b) <= (1 << 23) to its own function.
>
> v2: Catch the '1<<23' inside drm_handle_vblank() as well
>
> Signed-off-by: Chris Wilson
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www
Thanks Joonas, Michal. Will update this patch.
On 3/22/2017 9:00 PM, Joonas Lahtinen wrote:
On ke, 2017-03-22 at 16:18 +0100, Michal Wajdeczko wrote:
On Wed, Mar 22, 2017 at 03:33:38PM +0530, Sagar Arun Kamble wrote:
@@ -130,6 +130,8 @@ struct intel_uc_fw {
uint32_t ucode_offset;
};
Ping for review. GVT relies on the notification before a request submitted and
after a request completed, just like when using execlist mode submission.
> -Original Message-
> From: Dong, Chuanxiao
> Sent: Wednesday, March 22, 2017 2:35 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel
On 03/22/2017 10:50 PM, Daniel Vetter wrote:
> It's been around forever, no one bothered to address the FIXME, so I
> presume it's all fine.
>
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Signed-off-by: Daniel Vetter
NAK. We need to properly address this. Probably as part of the atomic
update.
/
101 - 184 of 184 matches
Mail list logo
