== Series Details ==
Series: Support for sustained capturing of GuC firmware logs (rev4)
URL : https://patchwork.freedesktop.org/series/7910/
State : failure
== Summary ==
Applying: drm/i915: Add GuC ukernel logging related fields to fw interface file
Applying: drm/i915: New structure to conta
From: Sagar Arun Kamble
If GuC logs are being captured, there should be a force log buffer flush
action sent to GuC before proceeding with GPU reset and re-initializing
GUC. Those logs would be useful to understand why the GPU reset was
initiated.
Signed-off-by: Sagar Arun Kamble
Signed-off-by:
From: Akash Goel
So far PM IER/IIR/IMR registers were being used only for Turbo related
interrupts. But interrupts coming from GuC also use the same set.
As a precursor to supporting GuC interrupts, added new low level routines
so as to allow sharing the programming of PM IER/IIR/IMR registers be
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs generated by ukernel.
This patch adds support to receive interrupts from GuC but currently
enables &
From: Akash Goel
On recieving the log buffer flush interrupt from GuC firmware, Driver
stores the snapshot of the log buffer in a local buffer, from which
Userspace can pull the logs. By default Driver store, up to, 4 snapshots
of the log buffer in a local buffer (managed by relay).
Added a new m
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it becomes
half full, so Driver doesn't really need to sample the complete buffer
and can just copy only the newly written data by GuC into the local
buffer, i.e. as per the read & write pointer values.
Moreover the flu
From: Akash Goel
Host needs to sample the GuC log buffer on every flush interrupt from GuC.
To ensure that we always get the up-to-date data from log buffer, its
better to access the buffer through an uncached CPU mapping. Also the way
buffer is accessed from GuC & Host side, manually doing cache
From: Akash Goel
Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
User to capture GuC firmware logs. Availed relay framework to implement
the interface, where Driver will have to just use a relay API to store
snapshots of the GuC log buffer in the buffer managed by relay.
The
From: Chris Wilson
vmaps has a provision for controlling the page protection bits, with which
we can use to control the mapping type, e.g. WB, WC, UC or even WT.
To allow the caller to choose their mapping type, we add a parameter to
i915_gem_object_pin_map - but we still only allow one vmap to b
From: Akash Goel
GuC firmware sends an interrupt to flush the log buffer when it
becomes half full. GuC firmware also tracks how many times the
buffer overflowed.
It would be useful to maintain a statistics of how many flush
interrupts were received and for which type of log buffer,
along with th
From: Akash Goel
With the addition of new Host2GuC actions related to GuC logging, there
is a need of a lock to serialize them, as they can execute concurrently
with each other and also with other existing actions.
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_guc_submission.c | 3 ++
From: Sagar Arun Kamble
GuC ukernel sends an interrupt to Host to flush the log buffer
and expects Host to correspondingly update the read pointer
information in the state structure, once it has consumed the
log buffer contents by copying them to a file or buffer.
Even if Host couldn't copy the c
From: Sagar Arun Kamble
This patch provides debugfs interface i915_guc_output_control for
on the fly enabling/disabling of logging in GuC firmware and controlling
the verbosity level of logs.
The value written to the file, should have bit 0 set to enable logging and
bits 4-7 should contain the ve
From: Sagar Arun Kamble
The first page of the GuC log buffer contains state info or meta data
which is required to parse the logs contained in the subsequent pages.
The structure representing the state info is added to interface file
as Driver would need to handle log buffer flush interrupts from
From: Akash Goel
GuC firmware log its debug messages into a Host-GuC shared memory buffer
and when the buffer is half full it sends a Flush interrupt to Host.
GuC firmware expects that while it is writing to 2nd half of the buffer,
first half would get consumed by Host and then get a flush comple
From: Akash Goel
So far there were 2 fields related to GuC logs in 'intel_guc' structure.
For the support of capturing GuC logs & storing them in a local buffer,
multiple new fields would have to be added. This warrants a separate
structure to contain the fields related to GuC logging state.
Adde
On Sat, Jul 02, 2016 at 07:09:21PM +0100, Matthew Auld wrote:
> Reviewed-by: Matthew Auld
Thanks for the review, tempted to look at s/dev->dev_private/to_i915/?
:)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
== Series Details ==
Series: series starting with [1/9] drm/i915: Fix random indent in
i915_drm_resume()
URL : https://patchwork.freedesktop.org/series/9413/
State : failure
== Summary ==
Series 9413v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/9413/revisions/
smatch complains:
drivers/gpu/drm/i915/i915_debugfs.c:1390 i915_frequency_info() Function
too hairy. Giving up.
drivers/gpu/drm/i915/i915_debugfs.c:1985 i915_gem_framebuffer_info()
warn: inconsistent indenting
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 +++
smatch complains:
drivers/gpu/drm/i915/intel_pm.c:4745 gen6_set_rps_thresholds() warn:
inconsistent indenting
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_pm.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --gi
smatch complains:
drivers/gpu/drm/i915/i915_gpu_error.c:503 i915_error_state_to_str()
warn: inconsistent indenting
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_g
smatch complain:
drivers/gpu/drm/i915/intel_dsi_pll.c:101 dsi_calc_mnp() error: buffer
overflow 'lfsr_converts' 39 <= 4294967234
and looks justified in doing so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 17 +
1 file changed, 9 inser
smatch complains:
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c:657 vbt_panel_init() warn:
inconsistent indenting
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i91
smatch complains:
drivers/gpu/drm/i915/i915_drv.c:1616 i915_drm_resume() warn:
inconsistent indenting
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu
smatch complains of:
drivers/gpu/drm/i915/intel_fbdev.c:403
intel_fb_initial_config() warn: should '1 << i' be a 64 bit type?
drivers/gpu/drm/i915/intel_fbdev.c:422 intel_fb_initial_config() warn:
should '1 << i' be a 64 bit type?
drivers/gpu/drm/i915/intel_f
smatch spotted that:
drivers/gpu/drm/i915/intel_display.c:11986
intel_plane_atomic_calc_changes() warn: variable dereferenced before
check 'crtc_state' (see line 11972)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
1 file changed, 1 insert
smatch complains:
drivers/gpu/drm/i915/intel_lvds.c:187 intel_pre_enable_lvds() warn:
inconsistent indenting
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lvds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.
On Fri, Jul 01, 2016 at 03:47:56PM -0700, Manasi Navare wrote:
> Intel_dp_check_link_status() function reads the Link status registers
> and returns a boolean to indicate link is good or bad.
> If the link is bad, it is retrained outside the function based
> on the return value.
>
> Signed-off-by:
-intel_dp_check_link_status-should-only-return-status-of-link/20160702-124153
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH
38 matches
Mail list logo
