On ke, 2017-03-22 at 00:39 +, Chris Wilson wrote:
> Pass along the drm_i915_private pointer from the caller, rather than
> looking it up from each fw_domain during fw_domains_get/_put. This
> allows us to then eliminate the backpointer, in exchange for a more
> complicated unwrapping procedure
Hi all,
So yeah this takes a bit longer than I hoped, but here's a few more things split
out from drmP.h and properly documented. The vblank stuff took a bit a detour,
since I opted to refactor stuff away instead of documenting it.
What's now left in drmP.h is struct drm_device and all the variou
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.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-uapi.rst | 9
Documentation/gpu/todo.rst | 26 +
driv
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 --
1 file changed, 4 insertions(+), 47 de
It's the default storage class for functions, entirely redundant. And
a lot of these headers are a bit inconsistent due to organically
grown.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc_helper.h | 38 +++---
include/drm/drm_drv.h | 4 ++--
inclu
Doc polish will follow in the next patch.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs.c | 5 ++-
include/drm/drmP.h| 44 +
include/drm/drm_debugfs.h | 76 +++
3 files changed, 81 insertions(+), 44 d
This was missed in Tomeu's patch. Also remove the kerneldoc for the
internal function, we don't document that in general.
While at it word-smith the docs slightly for more clarity.
Cc: Tomeu Vizoso
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-uapi.rst| 3 +++
drivers/gpu/drm/drm
- remove docs for internal func, doesn't add value
- add short overview snippet instead explaining that drivers don't
have to bother themselves with reg/unreg concerns
- drop the ttm comment about drmP.h, drmP.h is disappearing ...
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-uapi.rs
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 | 61 +-
include/drm/drm_ioctl.h | 102
3 files changed, 104 insertions(+), 60 del
Discussed with Noralf on the list a bit.
An open question is tinydrm vs. drm_panel, but until we have a clear
idea what's really needed in that space, I think it's best to just
move forward with what we have.
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 70 +
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
This is going to be a bit too much, but good to have at least a small
note about where this should all head towards.
Signed-off-by: Daniel Vetter
---
include/drm/drm_drv.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 9fe6301e
- We can drop the different return value flags, the only caller only
cares about whether the scanout position is valid or not. Also, it's
entirely undefined what "accurate" means, if we'd really care we
should probably wire the max_error through. But since we never even
report this to users
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 driver-private flags in there.
Cc: Mario Kleiner
Cc: Eric Anholt
Cc: Rob
The core code doesn't care at all about this, it's entirely dead.
Cc: Mario Kleiner
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 8
include/drm/drmP.h| 1 -
2 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index
Drive-by cleanup.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_probe_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 85005d57bde6..efb5e5e8ce62 100644
--- a/drivers/gpu/drm/drm_pro
Also unify/merge with the existing stuff.
I was a bit torn where to put this, but in the end I decided to put
all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we
have a bit a split with the other uapi related stuff used internally,
like drm_file.[hc], but I think overall this makes
On Tue, 21 Mar 2017, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 04:13:45PM +0200, Jani Nikula wrote:
>> On Tue, 21 Mar 2017, Daniel Vetter wrote:
>> > Some didn't work, at least here.
>> >
>> > Signed-off-by: Daniel Vetter
>> > ---
>> > dim | 8 +++-
>> > 1 file changed, 7 insertions(+)
Hi
I know something similar is here:
https://bugs.freedesktop.org/show_bug.cgi?id=100110 too.
But this is rc3 and my machine is totally *not usable*. Let me be
annoying :) I hope I can help:
Since rc1 I get gpu hangs and resets under load: This is almost
certainly a kernel issue. 4.10 is f
On 18/03/17 05:20 AM, Chris Wilson wrote:
> Move the repeated (a - b) <= (1 << 23) to its own function.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --g
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 visibility for SKL+
> also. Previously SKL+ would check the actual visibility which now
> conflicts with the assumptions in intel_legacy_cursor_update().
>
> We al
== Series Details ==
Series: more drmP.h cleanup
URL : https://patchwork.freedesktop.org/series/21670/
State : failure
== Summary ==
Series 21670v1 more drmP.h cleanup
https://patchwork.freedesktop.org/api/1.0/series/21670/revisions/1/mbox/
Test gem_exec_suspend:
Subgroup basic-s4-dev
On ke, 2017-03-22 at 00:39 +, Chris Wilson wrote:
> Since we reuse the same values for each fw_domain, move them onto
> uncore.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_
On ke, 2017-03-22 at 00:39 +, Chris Wilson wrote:
> We can relax the requirement upon ourselves that the forcewake is
> released immediately and just allow it to occur naturally following our
> mmio request.
>
> Signed-off-by: Chris Wilson
Could use T-b.
Reviewed-by: Joonas Lahtinen
Regar
It's a good practice to use "git am" to apply the original patch and
then "git commit --amend" to it, so that the "From: " field stays
intact. Or use git commit --amend --author="John Doe " but
that is more prone to typos.
On ti, 2017-03-21 at 02:02 -0700, Oscar Mateo wrote:
> Started adding prope
Thanks for doing this.
Reviewed-by: Tomeu Vizoso
On 22 March 2017 at 09:36, Daniel Vetter wrote:
> This was missed in Tomeu's patch. Also remove the kerneldoc for the
> internal function, we don't document that in general.
>
> While at it word-smith the docs slightly for more clarity.
>
> Cc: T
On ti, 2017-03-21 at 04:24 -0700, Oscar Mateo wrote:
>
> True. I went with his second option (WARN instead of DRM_ERROR) without
> asking him first...
Without knowing more of the innards of GuC, it's hard to say which will
be more appropriate action. WARN should be enough for now.
Reviewed-by:
The advent of full-ppgtt lead to an extra indirection between the object
and its binding. That extra indirection has a noticeable impact on how
fast we can convert from the user handles to our internal vma for
execbuffer. In order to bypass the extra indirection, we use a
resizable hashtable to jum
== Series Details ==
Series: series starting with [01/15] drm/i915: Copy user requested buffers into
the error state (rev3)
URL : https://patchwork.freedesktop.org/series/21377/
State : failure
== Summary ==
from ./include/linux/mutex.h:13,
from ./include/lin
On Tue, Mar 21, 2017 at 02:02:47AM -0700, Oscar Mateo wrote:
> 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,
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 visibility for SKL+
> > also. Previously SKL+ would check the actual visibility which now
> >
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
> bandwidth to drm_atomic_state would mean that a non-core object will be
From: Tom O'Rourke
Add has_slpc capablity flag to indicate GuC firmware
supports single loop power control (SLPC). SLPC is
a replacement for some host-based power management
features.
v1: fix whitespace (Sagar)
Reviewed-by: David Weinehall
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Aru
Input string parsing used in CRC control parameter parsing is generic
and can be reused for other debugfs interfaces. Hence name it as
buffer_tokenize instead of tieing to display_crc. Also fix the function
desciption for CRC control parsing that was misplaced at tokenize function.
Cc: Tomeu Vizos
From: Tom O'Rourke
i915.enable_slpc is used to override the default for slpc usage.
The expected values are -1=auto, 0=disabled [default], 1=enabled.
Sanitize i915.enable_slpc to either 0 or 1 based on HAS_SLPC() and
GuC load and submission options.
v1: Add early call to sanitize enable_slpc in
SLPC operates based on parameters setup in shared data between
i915 and GuC SLPC. This is to be created/initialized in intel_slpc_init.
From then onwards i915 can control the SLPC operations by Enabling,
Disabling complete SLPC or changing SLPC parameters. During cleanup
SLPC shared data has to be
SLPC behavior can be changed through set of parameters.
These parameters can be updated and queried from i915 though
Host to GuC SLPC events. This patch adds parameter update
events for setting/unsetting/getting parameters. SLPC has
various tasks for controlling different controls. This patch
adds
With GuC based SLPC, frequency control will be moved to GuC and Host will
continue to control RC6 and Ring frequency setup. SLPC can be enabled in
the GuC setup path and can happen in parallel in GuC with other i915 setup.
Hence we can do away with deferred RPS enabling. This needs separate
handlin
This patch adds two debugfs interfaces:
1. i915_slpc_paramlist: List of all parameters that Host can configure.
Currently listing id and names.
2. i915_slpc_param_ctl: This allows to change the parameters. Syntax is:
echo "write " > i915_slpc_param_ctl.
echo "read " > i915_slpc_param_ctl;
SLPC (Single Loop Power Controller) is a replacement for some host-based
power management features. The SLPC implementation runs in firmware on GuC.
This series has been tested with SKL/APL/KBL GuC firmware v9.
The graphics power management features in SLPC in this version are called
GTPERF, BALAN
From: Tom O'Rourke
Send SLPC shutdown event during disable, suspend, and reset
operations. Sending shutdown event while already shutdown
is OK.
v1: Return void instead of ignored error code (Paulo)
Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
Added SLPC
When SLPC is controlling frequency requests, RPS state related to
autotuning is no longer valid. Make user aware through banner
upfront. Value read from register RPNSWREQ likely has the frequency
requested last by GuC SLPC.
v1: Replace HAS_SLPC with intel_slpc_active (Paulo)
Avoid magic number
From: Tom O'Rourke
The SLPC interface is dependent on GuC version.
Only GuC versions known to be compatible are supported here.
SLPC with GuC firmware v9 is supported with this series.
v1: Updated with modified sanitize_slpc_option in earlier patch.
v2-v3: Rebase.
v4: Updated support for GuC
From: Tom O'Rourke
i915_slpc_info shows the contents of SLPC shared data
parsed into text format.
v1: Reformat slpc info (Radek)
squashed query task state info
in slpc info, kunmap before seq_print (Paulo)
return void instead of ignored return value (Paulo)
Avoid magic numbers an
Populate SLPC shared data with required default values for
Slice count, Power source/plan, IA Perf MSRs.
v1: Update for SLPC interface version 2015.2.4
intel_slpc_active() returns 1 if slpc initialized (Paulo)
change default host_os to "Windows"
Spelling fixes (Sagar Kamble and Nick Ho
From: Tom O'Rourke
If slpc enabled, then add enable SLPC flag to guc
control parameter during guc load.
v1: Use intel_slpc_enabled() (Paulo)
v2-v4: Rebase.
v5: Changed intel_slpc_enabled() to i915.enable_slpc. (Sagar)
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers
Communication with SLPC is via Host to GuC interrupt through
shared data and parameters. This patch defines the structure of
shared data, parameters, data structure to be passed as input and
received as output from SLPC. This patch also defines the events
to be sent as input and status values outpu
From: Tom O'Rourke
Adds debugfs hooks for enabling/disabling each SLPC task.
The enable/disable debugfs files are
i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc.
Each of these can take the values:
"default", "enabled", or "disabled"
v1: update for SLPC v2015.2.4
dfps and turbo mer
From: Tom O'Rourke
This patch adds has_slpc to skylake info.
The SLPC interface has changed and could continue to
change. Only GuC versions known to be compatible are
supported here.
On Skylake, GuC firmware v6 is supported. Other
platforms and versions can be added here later.
v1: Move slpc_
Send host2guc SLPC reset event to GuC post GuC load.
Post this, i915 can ascertain if SLPC has started running successfully
through shared data. This check is done during intel_init_gt_powersave.
This allows to get initial configuration setup by SLPC and if needed
move to Host RPS if SLPC runs into
From: Tom O'Rourke
Adds has_slpc to broxton info and adds broxton firmware version check
to sanitize_slpc_option.
v1: Adjusted slpc version check for major version 8.
Added message if version mismatch happens for easier debug. (Sagar)
v2-v3: Rebase.
v4: Commit message update.
v5: Rebase.
Update sysfs and debugfs functions to set SLPC
parameters when setting max/min frequency.
v1: Update for SLPC 2015.2.4 (params for both slice and unslice)
Replace HAS_SLPC with intel_slpc_active() (Paulo)
v2-v4: Rebase.
v5: Removed typecasting the frequency values to u32. (Chris)
Changed
Adds has_slpc to kabylake info and adds kabylake firmware version check
to sanitize_slpc_option.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_slpc.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
From: Tom O'Rourke
SLPC GTPERF, BALANCER, DCC are needed for better power and
performance management with GuC based submission.
SLPC GTPERF is evaluated on SKL/APL/KBL for Linux benchmarks.
SLPC support for these platforms is added in earlier patches.
This patch makes SLPC enabled by default for
On ti, 2017-03-21 at 02:02 -0700, Oscar Mateo wrote:
> 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 differe
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
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
---
drivers/gpu/drm/drm_irq.c | 16 ++--
1 file changed, 10 insertions(+), 6 dele
Hi,
Do the small fixups I proposed (and correct patch 1 author ;) ) and
resend this with the HAX patch at the end to enable GuC submission.
If it passes CI, it's good to merge assuming you did some sanity
checking too.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corpo
== Series Details ==
Series: Add support for GuC-based SLPC (rev9)
URL : https://patchwork.freedesktop.org/series/2691/
State : success
== Summary ==
Series 2691v9 Add support for GuC-based SLPC
https://patchwork.freedesktop.org/api/1.0/series/2691/revisions/9/mbox/
Test gem_exec_flush:
On Wed, 22 Mar 2017, Daniel Vetter wrote:
> 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
On Wed, 22 Mar 2017, Martin Kepplinger wrote:
> I know something similar is here:
> https://bugs.freedesktop.org/show_bug.cgi?id=100110 too.
>
> But this is rc3 and my machine is totally *not usable*. Let me be
> annoying :) I hope I can help:
Please file a bug over at [1].
Thanks,
Jani.
[1]
== Series Details ==
Series: series starting with [v2,1/4] drm: Mark up accesses of vblank->enabled
outside of its spinlock (rev2)
URL : https://patchwork.freedesktop.org/series/21472/
State : success
== Summary ==
Series 21472v2 Series without cover letter
https://patchwork.freedesktop.org/a
On Tue, Mar 21, 2017 at 01:50:48PM +0100, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 01:15:59PM +0200, Jani Nikula wrote:
> > On Tue, 21 Mar 2017, Daniel Vetter wrote:
> > > On Tue, Mar 21, 2017 at 12:14:31PM +0200, Jani Nikula wrote:
> > >> Fix shellcheck SC2115: Use "${var:?}" to ensure this
Op 17-03-17 om 23:12 schreef Chris Wilson:
> On Fri, Mar 17, 2017 at 11:18:08PM +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> We'll maybe want just one posting read at the end? This does seem to
>> potentially shave a few usec off from the update.
> They are all superflu
On Wed, 22 Mar 2017, David Weinehall wrote:
> rm -rf / woes can be remedied by always passing "--preserve-root" to rm
> (I believe that this is the default already though).
That doesn't help with 'rm -rf /*' though.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Since gfx allocations tend to be large, unmovable and disposable, report
the allocation failure back to userspace as an ENOMEM rather than incur
the oomkiller. We have already tried to make room by purging our own
cached gfx objects, and the oomkiller doesn't attribute ownership of gfx
objects so w
== Series Details ==
Series: drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx
allocations
URL : https://patchwork.freedesktop.org/series/21681/
State : success
== Summary ==
Series 21681v1 drm/i915: Prefer to report ENOMEM rather than incur the oom for
gfx allocations
http
Hello Tina Zhang,
This is a semi-automatic email about new static checker warnings.
The patch 695fbc08d80f: "drm/i915/gvt: replace the gvt_err with
gvt_vgpu_err" from Mar 10, 2017, leads to the following Smatch
complaint:
drivers/gpu/drm/i915/gvt/kvmgt.c:1344 kvmgt_guest_exit()
warn:
Hi Dave, i915 fixes all over the place, including GVT-g.
BR,
Jani.
The following changes since commit 6aef660370a9c246956ba6d01eebd8063c4214cb:
drm/i915: Fix forcewake active domain tracking (2017-03-13 17:30:54 +0200)
are available in the git repository at:
git://anongit.freedesktop.org/
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
> enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_
Pass along the drm_i915_private pointer from the caller, rather than
looking it up from each fw_domain during fw_domains_get/_put. This
allows us to then eliminate the backpointer, in exchange for a more
complicated unwrapping procedure in the rare
intel_uncore_fw_release_timer().
Signed-off-by: C
We can relax the requirement upon ourselves that the forcewake is
released immediately and just allow it to occur naturally following our
mmio request.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_uncore.c |
The set of available structs is not protected by the spinlock, and for
the single read we can use READ_ONCE instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.
Use find-first-set bitop to quickly scan through the fw_domains mask and
skip iterating over unused domains.
v2: Move the WARN into the caller, to prevent compiler warnings in
normal builds.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
drivers/gpu/drm/i915/i915_
Since we reuse the same values for each fw_domain, move them onto
uncore.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 11 +-
drivers/gpu/drm/i915/intel_uncore.c | 40 +++--
2 files changed, 27 inserti
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 back to userspace as an ENOMEM rather than incur
> the oomkiller. We have already tried to make room by purging our own
> cached gfx objects, and
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 different ways. Replace everything with a simple copy of
> the function and inline it inside intle_ddi_pll_select().
>
> Signed-off-by: Paulo Zanoni
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 the crtc vblank stuff isn't set up is a driver
> > bug. Those places arlready DRM_ERROR.
> > - Calling this when the c
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 back to userspace as an ENOMEM rather than incur
> > the oomkiller. We hav
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 | 61 +-
> include/drm/drm_ioctl.h | 102
>
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| 44 +
> include/drm/drm_debugfs.h | 76
>
On Wed, Mar 22, 2017 at 09:36:11AM +0100, Daniel Vetter wrote:
> The core code doesn't care at all about this, it's entirely dead.
>
> Cc: Mario Kleiner
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq.c | 8
> include/drm/drmP.h| 1 -
> 2 files changed, 9 deletion
On Wed, Mar 22, 2017 at 12:53:24PM +0200, Jani Nikula wrote:
> On Wed, 22 Mar 2017, David Weinehall wrote:
> > rm -rf / woes can be remedied by always passing "--preserve-root" to rm
> > (I believe that this is the default already though).
>
> That doesn't help with 'rm -rf /*' though.
Hmmm, but
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 the crtc vblank stuff isn't set up is a driver
>> > bug. Those places
On Wed, 22 Mar 2017, David Weinehall wrote:
> On Wed, Mar 22, 2017 at 12:53:24PM +0200, Jani Nikula wrote:
>> On Wed, 22 Mar 2017, David Weinehall wrote:
>> > rm -rf / woes can be remedied by always passing "--preserve-root" to rm
>> > (I believe that this is the default already though).
>>
>> T
+ Daniel for the rsvd2
On ke, 2017-03-22 at 09:33 +, Chris Wilson wrote:
> The advent of full-ppgtt lead to an extra indirection between the object
> and its binding. That extra indirection has a noticeable impact on how
> fast we can convert from the user handles to our internal vma for
> exe
Fix sparse warning:
drivers/gpu/drm/drm_scdc_helper.c:138:6: warning: symbol
'drm_scdc_get_scrambling_status' was not declared. Should it be static?
Fixes: 62c58af32c93 ("drm/edid: detect SCDC support in HF-VSDB")
Cc: Shashank Sharma
Signed-off-by: Jani Nikula
---
include/drm/drm_scdc_helper.h
On ke, 2017-03-22 at 12:37 +, Chris Wilson wrote:
> The set of available structs is not protected by the spinlock, and for
> the single read we can use READ_ONCE instead.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology
== Series Details ==
Series: drm/scdc: declare drm_scdc_get_scrambling_status
URL : https://patchwork.freedesktop.org/series/21690/
State : success
== Summary ==
Series 21690v1 drm/scdc: declare drm_scdc_get_scrambling_status
https://patchwork.freedesktop.org/api/1.0/series/21690/revisions/1/m
Thanks for this patch, Jani.
Reviewed-by: Shashank Sharma
Regards
Shashank
On 3/22/2017 4:33 PM, Jani Nikula wrote:
Fix sparse warning:
drivers/gpu/drm/drm_scdc_helper.c:138:6: warning: symbol
'drm_scdc_get_scrambling_status' was not declared. Should it be static?
Fixes: 62c58af32c93 ("drm/
== Series Details ==
Series: series starting with [v2,1/5] drm/i915: Eliminate per-fw_domain i915
backpointer
URL : https://patchwork.freedesktop.org/series/21686/
State : warning
== Summary ==
Series 21686v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21686/r
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 IRQ around a drmWaitVblank query
dominates. And with the advent of even deeper
On Wed, Mar 22, 2017 at 03:33:38PM +0530, Sagar Arun Kamble wrote:
> From: Tom O'Rourke
>
> The SLPC interface is dependent on GuC version.
> Only GuC versions known to be compatible are supported here.
>
> SLPC with GuC firmware v9 is supported with this series.
>
> v1: Updated with modified s
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;
> > };
> >
> > +#define FIRMWARE_URL "https://01.org/linuxgraphics/intel-linux-gr
> > aphics
Hi Jani/Ville,
I need to add another quick fix which would be required for the fallback
to happen as expected. Should I respin this patch to add that fix or
should I wait for this to get landed?
I have mentioned the fix suggested below, please let me know your thoughts on
that.
On Tue, Mar 14,
On 03/22/2017 02:45 AM, Chris Wilson wrote:
On Tue, Mar 21, 2017 at 02:02:47AM -0700, Oscar Mateo wrote:
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 functio
On 03/22/2017 02:28 AM, Joonas Lahtinen wrote:
It's a good practice to use "git am" to apply the original patch and
then "git commit --amend" to it, so that the "From: " field stays
intact. Or use git commit --amend --author="John Doe " but
that is more prone to typos.
On ti, 2017-03-21 at 02:
On Wed, Mar 22, 2017 at 02:42:27AM -0700, Oscar Mateo wrote:
>
>
> On 03/22/2017 02:45 AM, Chris Wilson wrote:
> >On Tue, Mar 21, 2017 at 02:02:47AM -0700, Oscar Mateo wrote:
> >>The GuC descriptor is big in size. If we use a local definition of
> >>guc_desc we have a chance to overflow stack, so
Em Ter, 2017-03-21 às 23:05 +, Pandiyan, Dhinakaran escreveu:
> On Tue, 2017-03-21 at 18:57 -0300, Paulo Zanoni wrote:
> >
> > 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 functio
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 different ways. Replace everything with a simple copy
> > of
> > the functio
1 - 100 of 184 matches
Mail list logo
