On Wed, Nov 16, 2016 at 6:55 AM, Hugh Dickins wrote:
> On Mon, 14 Nov 2016, akash goel wrote:
>> On Thu, Nov 10, 2016 at 1:00 PM, Goel, Akash wrote:
>> > On 11/10/2016 12:09 PM, Hugh Dickins wrote:
>> >> On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
>&
of unsafe_drop_pages (Chris)
>>>
>>> v4:
>>> - Minor tidy
>>>
>>> v5:
>>> - Fix unsafe usage of unsafe_drop_pages()
>>> - Rebase onto vmap-notifier
>>>
>>> v6:
>>> - Remove i915_gem_object_get/put across
shmem_set_dev_info() to be consistent
with shmem_dev_info structure. (Joonas)
Cc: Hugh Dickins
Cc: linux...@kvack.org
Cc: linux-ker...@vger.linux.org
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
Reviewed-by: Chris Wilson
---
include/linux/shmem_fs.h | 13 +
mm/shmem.c
ned-off-by: Sourab Gupta
Signed-off-by: Akash Goel
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 9 ++-
drivers/gpu/drm/i915/i915_gem_shrink
onto vmap-notifier
Testcase: igt/gem_shrink
Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
Cc: Hugh Dickins
Cc: linux...@kvack.org
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Chris W
shmem_set_dev_info() to be consistent
with shmem_dev_info structure. (Joonas)
Cc: Hugh Dickins
Cc: linux...@kvack.org
Cc: linux-ker...@vger.linux.org
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
Reviewed-by: Chris Wilson
---
include/linux/shmem_fs.h | 13 +
mm/shmem.c
From: Akash Goel
This patch provides the testcase to exercise the TRTT hardware.
Some platforms have an additional address translation hardware support in
form of Tiled Resource Translation Table (TR-TT) which provides an extra level
of abstraction over PPGTT.
This is useful for mapping Sparse
From: Akash Goel
Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
pinned in mappable aperture portion of GGTT and for ringbuffer pages
allocated from Stolen memory, access can only be done through GMADR BAR.
In case of GuC based submission, updates done in ringbuffer via
with fragmentation.
>> And therefore the need for such a provision for initiating driver specific
>> actions during address space operations.
>>
>> Cc: Hugh Dickins
>> Cc: linux...@kvack.org
>> Signed-off-by: Sourab Gupta
>> Signed-off-by: Akash Goel
>
From: Akash Goel
Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
pinned in mappable aperture portion of GGTT and for ringbuffer pages
allocated from Stolen memory, access can only be done through GMADR BAR.
In case of GuC based submission, updates done in ringbuffer via
From: Akash Goel
With the possibility of addition of many more number of rings in future,
the drm_i915_private structure could bloat as an array, of type
intel_engine_cs, is embedded inside it.
struct intel_engine_cs engine[I915_NUM_ENGINES];
Though this is still fine as generally there
From: Akash Goel
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 flush may
not be effective always if cached CPU mapping is used. In o
rtko)
v5:
- Lock struct_mutex after the NULL check for guc log buffer vma. (Chris)
- Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 41 -
drivers/gpu/drm/i915/i915_guc_submission.c
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver could miss capturing the boot-time logs of GuC
From: Akash Goel
The GuC log buffer flush work item has to do a register access to send the
ack to GuC and this work item, if not synced before suspend, can potentially
get executed after the GFX device is suspended. This work item function uses
rpm get/put calls around the Hw access, which
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.
Mor
captured and those logs would be particularly useful to understand
that why the reset was initiated.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 30 ++
drivers/gpu/drm/i915
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages,
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
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
From: Akash Goel
Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determine that why the GPU reset
was triggered.
v2:
- For uniformity use existing helper function print_error_obj() to
dump out contents of GuC log buffer, pretty
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 manage
nst the work queued by irq handler will be done by caller disabling
the interrupt.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++
drivers/
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.
v2: Use mutex in place of spinlock to serialize, as sleep can happen
while
for better readability. (Tvrtko)
v8:
- Make the dedicated wq as a high priority one to further reduce the
turnaround time of handing log buffer flush event from GuC.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/
From: Akash Goel
relay essentially needs to maintain the per CPU array of channel buffer
pointers but it manually creates that array.
Instead its better to avail the per CPU constructs, provided by the
kernel, to allocate & access the array of pointer to channel buffers.
This patch is qu
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 follows the half-full draining protocol where it expects that
while it is writing to 2nd half of the buffer, 1st half would
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
buffer state structure more elaborate &
rename LOGBUFFERFLUSH action to LOG_BUFFER_FLUSH for consistency.(Tvrtko)
v3: Add GuC log buffer layout diagram for more clarity.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
d on
the value of module parameter guc_log_level.
v2: Update commit message to describe the constraint with allocation of
log buffer at runtime. (Tvrtko)
v3: Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware logs and
then dump them to file.
The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and
by default stored into a file 'guc_log_dump.dat'. The name, including the
location
From: Akash Goel
With the possibility of addition of many more number of rings in future,
the drm_i915_private structure could bloat as an array, of type
intel_engine_cs, is embedded inside it.
struct intel_engine_cs engine[I915_NUM_ENGINES];
Though this is still fine as generally there
On Fri, Oct 7, 2016 at 4:19 PM, Joonas Lahtinen
wrote:
> On pe, 2016-10-07 at 15:03 +0530, akash.g...@intel.com wrote:
>> > From: Akash Goel
>>
>> With the possibility of addition of many more number of rings in future,
>> the drm_i915_private structure co
From: Akash Goel
With the possibility of addition of many more number of rings in future,
the drm_i915_private structure could bloat as an array, of type
intel_engine_cs, is embedded inside it.
struct intel_engine_cs engine[I915_NUM_ENGINES];
Though this is still fine as generally there
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware logs and
then dump them to file.
The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and
by default stored into a file 'guc_log_dump.dat'. The name, including the
location
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver could miss capturing the boot-time logs of GuC
From: Akash Goel
relay essentially needs to maintain the per CPU array of channel buffer
pointers but it manually creates that array.
Instead its better to avail the per CPU constructs, provided by the
kernel, to allocate & access the array of pointer to channel buffers.
This patch is qu
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages,
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
buffer state structure more elaborate &
rename LOGBUFFERFLUSH action to LOG_BUFFER_FLUSH for consistency.(Tvrtko)
v3: Add GuC log buffer layout diagram for more clarity.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
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.
Mor
rtko)
v5:
- Lock struct_mutex after the NULL check for guc log buffer vma. (Chris)
- Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 41 -
drivers/gpu/drm/i915/i915_guc_submission.c
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.
v2: Use mutex in place of spinlock to serialize, as sleep can happen
while
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 manage
better readability. (Tvrtko)
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 186 +
drivers/gpu/drm/i915/i915_irq.c| 28 -
drivers/gpu/drm/i915/intel_guc.h
From: Akash Goel
Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determine that why the GPU reset
was triggered.
v2:
- For uniformity use existing helper function print_error_obj() to
dump out contents of GuC log buffer, pretty
From: Akash Goel
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 flush may
not be effective always if cached CPU mapping is used. In o
From: Akash Goel
The GuC log buffer flush work item has to do a register access to send the
ack to GuC and this work item, if not synced before suspend, can potentially
get executed after the GFX device is suspended. This work item function uses
rpm get/put calls around the Hw access, which
captured and those logs would be particularly useful to understand
that why the reset was initiated.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 30 ++
drivers/gpu/drm/i915
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
nst the work queued by irq handler will be done by caller disabling
the interrupt.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++
drivers/
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
d on
the value of module parameter guc_log_level.
v2: Update commit message to describe the constraint with allocation of
log buffer at runtime. (Tvrtko)
v3: Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
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 follows the half-full draining protocol where it expects that
while it is writing to 2nd half of the buffer, 1st half would
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware logs and
then dump them to file.
The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and
stored into a file '/tmp/guc_log_dump.dat', the name of the output file can
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware logs and
then dump them to file.
The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and
stored into a file '/tmp/guc_log_dump.dat', the name of the output file can
rtko)
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 44 -
drivers/gpu/drm/i915/i915_guc_submission.c | 62 ++
drivers/gpu/drm/i915/intel_guc.h | 1
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 d
From: Akash Goel
relay essentially needs to maintain the per CPU array of channel buffer
pointers but it manually creates that array.
Instead its better to avail the per CPU constructs, provided by the
kernel, to allocate & access the array of pointer to channel buffers.
v2: Include in rel
From: Akash Goel
In order to have fast reads from the GuC log buffer, used SSE4.1 movntdqa
based memcpy function i915_memcpy_from_wc.
GuC log buffer has a WC type vmalloc mapping and copying using movntqda
from WC type memory is almost as fast as reading from WB memory.
This will further reduce
particularly useful to
understand that why the GPU reset was initiated.
v2:
- Avoid the wait via flush_work, to serialize against an ongoing log
buffer flush, from the error state capture path. (Chris)
- Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko
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.
Mor
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver could miss capturing the boot-time logs of GuC
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
From: Akash Goel
The GuC log buffer flush work item has to do a register access to send the
ack to GuC and this work item, if not synced before suspend, can potentially
get executed after the GFX device is suspended. This work item function uses
rpm get/put calls around the Hw access, which
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.
v2: Use mutex in place of spinlock to serialize, as sleep can happen
while
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages,
buffer state structure more elaborate &
rename LOGBUFFERFLUSH action to LOG_BUFFER_FLUSH for consistency.(Tvrtko)
v3: Add GuC log buffer layout diagram for more clarity.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
From: Akash Goel
Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determine that why the GPU reset
was triggered.
v2:
- For uniformity use existing helper function print_error_obj() to
dump out contents of GuC log buffer, pretty
nst the work queued by irq handler will be done by caller disabling
the interrupt.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++
drivers/
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 manage
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
d on
the value of module parameter guc_log_level.
v2: Update commit message to describe the constraint with allocation of
log buffer at runtime. (Tvrtko)
v3: Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
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 follows the half-full draining protocol where it expects that
while it is writing to 2nd half of the buffer, 1st half would
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
better readability. (Tvrtko)
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_guc_submission.c | 189 +
drivers/gpu/drm/i915/i915_irq.c| 28 -
drivers/gpu/drm/i915/intel_guc.h | 4 +
3 files changed, 22
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 d
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver could miss capturing the boot-time logs of GuC
From: Akash Goel
The GuC log buffer flush work item does a register access to send the ack
to GuC and this work item, if not synced before suspend, can potentially
get executed after the GFX device is suspended.
The work item function uses rpm_get/rpm_put calls around the Hw access,
this covers
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
From: Akash Goel
In order to have fast reads from the GuC log buffer, used SSE4.1 movntdqa
based memcpy function i915_memcpy_from_wc.
GuC log buffer has a WC type vmalloc mapping and copying using movntqda
from WC type memory is almost as fast as reading from WB memory.
This will further reduce
rtko)
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 44 -
drivers/gpu/drm/i915/i915_guc_submission.c | 62 ++
drivers/gpu/drm/i915/intel_guc.h | 1
particularly useful to
understand that why the GPU reset was initiated.
v2:
- Avoid the wait via flush_work, to serialize against an ongoing log
buffer flush, from the error state capture path. (Chris)
- Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915
From: Akash Goel
In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages,
From: Akash Goel
Added the dump of GuC log buffer to i915 error state, as the contents of
GuC log buffer would also be useful to determine that why the GPU reset
was triggered.
v2:
- For uniformity use existing helper function print_error_obj() to
dump out contents of GuC log buffer, pretty
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.
Mor
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.
v2: Use mutex in place of spinlock to serialize, as sleep can happen
while
nst the work queued by irq handler will be done by caller disabling
the interrupt.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++
drivers/gpu/drm/i915/i915_irq.c
From: Akash Goel
relay essentially needs to maintain the per CPU array of channel buffer
pointers but it manually creates that array.
Instead its better to avail the per CPU constructs, provided by the
kernel, to allocate & access the array of pointer to channel buffers.
v2: Include in rel
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 manage
buffer state structure more elaborate &
rename LOGBUFFERFLUSH action to LOG_BUFFER_FLUSH for consistency.(Tvrtko)
v3: Add GuC log buffer layout diagram for more clarity.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
the log packet,
as much possible and let Userspace parser detect the anomaly. (Chris)
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_guc_submission.c | 186 +
drivers/gpu/drm/i915/i915_irq.c| 28 -
driver
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
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
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 follows the half-full draining protocol where it expects that
while it is writing to 2nd half of the buffer, 1st half would
d on
the value of module parameter guc_log_level.
v2: Update commit message to describe the constraint with allocation of
log buffer at runtime. (Tvrtko)
v3: Rebase.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is done
at the end and so the relay channel debugfs file is also created after that
but the GuC firmware is loaded much earlier in the sequence.
As a result Driver could miss capturing the boot-time logs of GuC
rtko)
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_debugfs.c| 44 -
drivers/gpu/drm/i915/i915_guc_submission.c | 62 ++
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 106 insert
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.
Mor
buffer state structure more elaborate &
rename LOGBUFFERFLUSH action to LOG_BUFFER_FLUSH for consistency.(Tvrtko)
v3: Add GuC log buffer layout diagram for more clarity.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Akash Goel
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/
1 - 100 of 462 matches
Mail list logo
