On Thu, 2015-06-25 at 11:56 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 25-06-15 om 11:25 schreef Liu, Hong:
> > atomic commit only frees the state if no error met, caller needs to
> > free the allocated state if atomic commit failed.
> >
> > Signed-off-by: Hong Liu
> > ---
> > drivers/gpu/dr
Sure, that's an implementation details, but make sure we do recompute
the mean when we add a new value.
Signed-off-by: Damien Lespiau
---
lib/tests/igt_stats.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/lib/tests/igt_stats.c b/lib/tests/igt_stats.c
index 172e4
Sure, it'll be freed at exit(), but might as well be a bit pedantic.
Signed-off-by: Damien Lespiau
---
lib/tests/igt_stats.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/tests/igt_stats.c b/lib/tests/igt_stats.c
index 3f45314..c20b453 100644
--- a/lib/tests/igt_stats.c
+++ b/lib/tes
Suggested-by: Chris Wilson
Signed-off-by: Damien Lespiau
---
lib/igt_stats.c | 42 +-
lib/igt_stats.h | 3 +++
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/lib/igt_stats.c b/lib/igt_stats.c
index e6babde..20db806 100644
--- a/lib/igt_st
Signed-off-by: Damien Lespiau
---
lib/igt_stats.c | 9 +
lib/igt_stats.h | 1 +
lib/tests/Makefile.am| 2 +-
lib/tests/igt_stats.c| 33 +
tools/Makefile.am| 2 +-
tools/quick_dump/Makefile.am | 1 +
There are several types of averages eg. mean, median and mode.
Signed-off-by: Damien Lespiau
---
lib/igt_stats.c | 2 +-
lib/igt_stats.h | 2 +-
lib/tests/igt_stats.c | 10 +-
tools/skl_compute_wrpll.c | 3 ++-
4 files changed, 9 insertions(+), 8 deletions(-)
·
> On Thu, 25 Jun 2015, Philipp Gesang wrote:
> > Nice tool. With a vanilla kernel I get a value of 0x8000
> > before suspend and 0x after resume. With the patched
> > kernel it’s 0x8000 before and after.
> >
> > On the vanilla kernel, issuing ``intel_reg write 0x61260 0x
Broxton is using a different register and different bit ordering
for rps status capabilities.
Also GT perf freqency register is different for Broxton so update
that.
Signed-off-by: Bob Paauwe
---
drivers/gpu/drm/i915/i915_debugfs.c | 21 -
drivers/gpu/drm/i915/i915_reg.h
Each bo attachment point (so each data plane on planar yuv if we'd
support that) needs its own frontbuffer tracking bit, otherwise the
collisions could result in invalide/flush getting out of sync.
We have more than one sprite plane, and had (on vlv) 1 year before
I've even written the frontbuffer
We can't elide the fb tracking invalidate if the buffer is already in
the right domain since that would lead to missed screen updates. I'm
pretty sure I've written this already before but must have gotten lost
unfortunately :(
Reported-by: Paulo Zanoni
Cc: Paulo Zanoni
Signed-off-by: Daniel Vett
·
> On Wed, 24 Jun 2015, Philipp Gesang wrote:
> > Hi,
> >
> > suspend/resume results in the backlight not coming back to life
> > on my X40 laptop with an “Display controller: Intel Corporation
> > 82852/855GM Integrated Graphics Device”.
> >
> > I bisected the issue. Apparently, commit
On Thu, 25 Jun 2015, Philipp Gesang wrote:
> Nice tool. With a vanilla kernel I get a value of 0x8000
> before suspend and 0x after resume. With the patched
> kernel it’s 0x8000 before and after.
>
> On the vanilla kernel, issuing ``intel_reg write 0x61260 0x8000``
> after res
On 06/17/2015 08:19 AM, Peter Antoine wrote:
> This change adds the programming of the MOCS registers to the gen 9+
> platforms. This change set programs the MOCS register values to a set
> of values that are defined to be optimal.
>
> It creates a fixed register set that is programmed across th
On 06/25/2015 07:40 AM, Dave Gordon wrote:
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to prepare a context for submission via the
GuC, we need some of the same functions used in execlist
On Thu, Jun 25, 2015 at 12:52:22PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I often run "sudo ./test 2>&1 | tee output.txt", and when we're
> succeeding - never printing to stderr - the output gets buffered and
> is never flushed (because it doesn't point to a terminal), so I never
> k
On Thu, Jun 25, 2015 at 12:53:19PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> With this, we don't need to worry about what happened to the buffer
> before.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Jun 25, 2015 at 07:11:21PM +0100, Chris Wilson wrote:
> On Thu, Jun 25, 2015 at 11:01:44AM -0700, Ben Widawsky wrote:
> > On Wed, Jun 24, 2015 at 08:28:13AM +0100, Chris Wilson wrote:
> > > On Tue, Jun 23, 2015 at 04:44:52PM -0700, Anuj Phogat wrote:
> > > > On Mon, Jun 22, 2015 at 1:04 PM,
From: Paulo Zanoni
With this, we don't need to worry about what happened to the buffer
before.
Signed-off-by: Paulo Zanoni
---
lib/igt_draw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 51dce4b..fb9294d 100644
--- a/lib/igt_draw.c
+++ b/lib/ig
From: Paulo Zanoni
I often run "sudo ./test 2>&1 | tee output.txt", and when we're
succeeding - never printing to stderr - the output gets buffered and
is never flushed (because it doesn't point to a terminal), so I never
know which test is running. With this fflush, I'm able to know when
each te
On 24/06/2015 18:03, john.c.harri...@intel.com wrote:
From: John Harrison
An earlier patch was added to reserve space in the ring buffer for the
commands issued during 'add_request()'. The initial version was
pessimistic in the way it handled buffer wrapping and would cause
premature wraps and
On Thu, Jun 25, 2015 at 06:37:18PM +0100, Chris Wilson wrote:
> On Thu, Jun 25, 2015 at 06:31:52PM +0100, Robert Bragg wrote:
> > Thinking about the details of waiting for the last RPC command before
> > destroying the dest buffer and disabling OACONTROL these are the
> > requirements I see:
> > -
On Thu, Jun 25, 2015 at 11:01:44AM -0700, Ben Widawsky wrote:
> On Wed, Jun 24, 2015 at 08:28:13AM +0100, Chris Wilson wrote:
> > On Tue, Jun 23, 2015 at 04:44:52PM -0700, Anuj Phogat wrote:
> > > On Mon, Jun 22, 2015 at 1:04 PM, Chris Wilson
> > > wrote:
> > > > On Mon, Jun 22, 2015 at 09:51:08P
On Wed, Jun 24, 2015 at 08:28:13AM +0100, Chris Wilson wrote:
> On Tue, Jun 23, 2015 at 04:44:52PM -0700, Anuj Phogat wrote:
> > On Mon, Jun 22, 2015 at 1:04 PM, Chris Wilson
> > wrote:
> > > On Mon, Jun 22, 2015 at 09:51:08PM +0200, Daniel Vetter wrote:
> > >> On Mon, Jun 22, 2015 at 11:47:02AM
On Thu, Jun 25, 2015 at 06:35:14PM +0300, Mika Kuoppala wrote:
> During review of dynamic page tables series, I was able
> to hit a lite restore bug with execlists. I assume that
> due to incorrect pd, the batch run out of legit address space
> and into the scratch page area. The ACTHD was increasi
On 6/25/2015 4:35 PM, Mika Kuoppala wrote:
We can have exactly 4GB sized ppgtt with 32bit system.
size_t is inadequate for this.
v2: Convert a lot more places (Daniel)
Looks good to me.
The only possible remaining size_t are the return values in the
*_pte_count functions in i915_gem_gtt.h, b
On Thu, Jun 25, 2015 at 06:31:52PM +0100, Robert Bragg wrote:
> Thinking about the details of waiting for the last RPC command before
> destroying the dest buffer and disabling OACONTROL these are the
> requirements I see:
> - we want free the dest buffer in a finite time, since it's large
> (i.e.
On Thu, Jun 25, 2015 at 9:02 AM, Chris Wilson wrote:
> On Thu, Jun 25, 2015 at 06:02:35AM +, Gupta, Sourab wrote:
>> On Mon, 2015-06-22 at 16:09 +, Daniel Vetter wrote:
>> > On Mon, Jun 22, 2015 at 02:22:54PM +0100, Chris Wilson wrote:
>> > > On Mon, Jun 22, 2015 at 03:25:07PM +0530, soura
We can't improve a 0 deviation, so when we find such a divider, skip the
remaining ones they won't be better.
This short-circuit the search for 34 of the 373 test frequencies in the
corresponding i-g-t test (tools/skl_compute_wrpll)
Suggested-by: Paulo Zanoni
Signed-off-by: Damien Lespiau
---
T
Paulo suggested that we could short-circuit the search for a good
divider if we find a 0 deviation of the DCO frequency from the central
frequency.
Out of the 373 test frequencies, 34 hit that fast path.
Suggested-by: Paulo Zanoni
Signed-off-by: Damien Lespiau
---
tools/skl_compute_wrpll.c | 2
Might as well try to keep the code in both this test and the kernel as
close as possible.
Signed-off-by: Damien Lespiau
---
tools/skl_compute_wrpll.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/skl_compute_wrpll.c b/tools/skl_compute_wrpll.c
index 5468b58..1cc2343 100644
--- a/tool
We cannot let IPS enabled with no plane on the pipe:
BSpec: "IPS cannot be enabled until after at least one plane has
been enabled for at least one vertical blank." and "IPS must be
disabled while there is still at least one plane enabled on the
same pipe as IPS." This restriction apply to HSW and
On Thu, 25 Jun 2015, Rodrigo Vivi wrote:
> On Thu, Jun 25, 2015 at 4:58 AM Jani Nikula
> wrote:
>
>> On Thu, 18 Jun 2015, Jani Nikula wrote:
>> > On Thu, 18 Jun 2015, Jani Nikula wrote:
>> >> On Thu, 18 Jun 2015, Ander Conselvan De Oliveira
>> wrote:
>> >>> On Fri, 2015-06-05 at 12:11 +0300, V
On Thu, Jun 25, 2015 at 4:58 AM Jani Nikula
wrote:
> On Thu, 18 Jun 2015, Jani Nikula wrote:
> > On Thu, 18 Jun 2015, Jani Nikula wrote:
> >> On Thu, 18 Jun 2015, Ander Conselvan De Oliveira
> wrote:
> >>> On Fri, 2015-06-05 at 12:11 +0300, Ville Syrjälä wrote:
> On Fri, Jun 05, 2015 at 1
On Thu, Jun 25, 2015 at 06:39:30PM +0300, Mika Kuoppala wrote:
> Michel Thierry writes:
>
> > If for some reason [1], the page directory/table does not exist, clear_range
> > would end up in an infinite while loop.
> >
> > Introduced by commit 06fda602dbca ("drm/i915: Create page table
> > alloc
On Thu, Jun 25, 2015 at 04:21:40PM +0100, Damien Lespiau wrote:
> The master plan would be to get a bit more stats in it, at least the
> standard deviation and confidence interval. Just need the average for
> now.
Definitely, I wouldn't even print the average without the std.dev and
how normal the
Michel Thierry writes:
> If for some reason [1], the page directory/table does not exist, clear_range
> would end up in an infinite while loop.
>
> Introduced by commit 06fda602dbca ("drm/i915: Create page table allocators").
>
> [1] This is already being addressed in one of Mika's patches:
> htt
On 06/25/2015 12:33 AM, Daniel Vetter wrote:
>> In the specific case of bitfields it seems like it would be sufficient
>> > to mark the local variables as volatile? Or maybe just use open coded
>> > compiler barrier() functions instead, with accompanying documentation.
>> >
>> > Documentation/mem
Write page directory entry without using superfluous
indirect function. Also remove unused device parameter
from the encode function.
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 19 +--
1 file changed, 5 insertions(+), 14 de
V3 of the ppgtt cleanup series. I dropped the preallocation
of pdps as Michel has patch with updating pdps through ring LRIs
in his 48bit series.
All except 3/18 and 12/18 have Reviewed-bys.
Tomas Elf had concern with 12/18 that the gen9+ hw
cmd parser will NOOP out the commands. Even if it so,
w
When we setup page directories and tables, we point the entries
to a to the next level scratch structure. Make this generic
by introducing a fill_page_dma which maps and flushes. We also
need 32 bit variant for legacy gens.
v2: Fix flushes and handle valleyview (Ville)
v3: Now really fix flushes (
All the paging structures are now similar and mapped for
dma. The unmapping is taken care of by common accessors, so
don't overload the reader with such details.
v2: Be consistent with goto labels (Michel)
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_g
This has slipped in somewhere but it was harmless
as we check the page pointer before teardown.
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/
Scratch page is part of struct i915_address_space. Move other
scratch entities into the same struct. This is a preparatory patch
for having only one instance of each scratch_pt/pd.
v2: make commit msg more readable
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry (v1)
---
drivers/gpu/d
Lay out scratch page structure in similar manner than other
paging structures. This allows us to use the same tools for
setup and teardown.
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 89 -
drivers/gpu/dr
During review of dynamic page tables series, I was able
to hit a lite restore bug with execlists. I assume that
due to incorrect pd, the batch run out of legit address space
and into the scratch page area. The ACTHD was increasing
due to scratch being all zeroes (MI_NOOPs). And as gen8
address spac
There is no need for atomicity here. Convert all bitmap
operations to nonatomic variants.
Cc: Ville Syrjälä
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/
As there is flushing involved when we have done the cpu
write, make functions for mapping for cpu space. Make macros
to map any type of paging structure.
v2: Make it clear tha flushing kunmap is only for ppgtt (Ville)
v3: Flushing fixed (Ville, Michel). Removed superfluous semicolon
Cc: Ville Syr
We can have exactly 4GB sized ppgtt with 32bit system.
size_t is inadequate for this.
v2: Convert a lot more places (Daniel)
Signed-off-by: Mika Kuoppala
---
drivers/char/agp/intel-gtt.c| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 42 ++---
drivers/gp
Check the allocation area against the known end
of address space instead of against fixed value.
v2: Return ENODEV on internal bugs (Chris)
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +++---
1 file changed, 11 insertions(+)
Maintain base page handling functions in order of
alloc, free, init. No functional changes.
v2: s/Introduce/Maintain (Michel)
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 54 ++---
1 file changed, 27 insertio
Make paging structure type agnostic *_px macros to access
page dma struct, the backing page and the dma address.
This makes the code less cluttered on internals of
i915_page_dma.
v2: Superfluous const -> nonconst removed
v3: Rebased
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry (v2)
Dynamic page table allocation might wake the shrinker
when memory is requested for page table structures.
As this happens when we try to allocate the virtual address
during binding, our vma might be among the targets for eviction.
We should do i915_vma_pin() and do pin early in there like Chris
sug
The legacy mode mm switch and the execlist context assignment
needs dma address for the page directories.
Introduce a function that encapsulates the scratch_pd dma
fallback if no pd is found.
v2: Rebase, s/ring/req
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry (v1)
---
drivers/gpu/
As we use one scratch page for all ppgtt instances, we can
use one scratch page table and scratch directory across
all ppgtt instances, saving 2 pages + structs per ppgtt.
v2: Rebase
v3: Rebase
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry (v2)
---
drivers/gpu/drm/i915/i915_gem_gtt.
When we touch gen8+ page maps, mark them dirty like we
do with previous gens.
v2: Update comment (Joonas)
Signed-off-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git
All our paging structures have struct page and dma address
for that page.
Add struct for page/dma address pairs and use it to make
the setup and teardown for different paging structures
identical.
Include the page directory offset also in the struct for legacy
gens. Rename it to clearly point out
Paulo noticed that, because we were only comparing positive deviations
with positive deviations and negative deviations with negative
deviations, we weren't actually always using the absolute minimal
deviation at all.
This improves the average deviation across all tested frequencies (373):
before
It's interesting to watch the effect of some algorithm tweaks on the
average deviation between the central freq and the dco freq. A metric
we'd like to minimize.
Signed-off-by: Damien Lespiau
---
tools/skl_compute_wrpll.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/skl_
Follow Paulo's comment on the corresponding kernel patch.
This means we also have to move the break when we have cycled through
the even dividers as well.
This improves the number of even dividers used across the tested
frequencies (373) (at the expense of a slightly worse average deviation,
but
The master plan would be to get a bit more stats in it, at least the
standard deviation and confidence interval. Just need the average for
now.
Signed-off-by: Damien Lespiau
---
lib/Makefile.sources | 2 ++
lib/igt_stats.c| 56 ++
li
Currently, if an odd divider improves the deviation (minimizes it), we
take that divider. The recommendation is to prefer even dividers.
v2: Move the check at the right place after having inverted the two for
loops in the previous patch.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i91
On Wed, May 27, 2015 at 07:08:38PM -0300, Paulo Zanoni wrote:
> 2015-05-27 18:39 GMT-03:00 Paulo Zanoni :
> > 2015-05-07 14:38 GMT-03:00 Damien Lespiau :
> >> Currently, if an odd divider improves the deviation (minimizes it), we
> >> take that divider. The recommendation is to prefer even dividers
The HW validation team came back from further testing with a slightly
changed constraint on the deviation between the DCO frequency and the
central frequency. Instead of +-4%, it's now +1%/-6%.
Unfortunately, the previous algorithm didn't quite cope with these new
constraints, the reason being tha
On Wed, May 27, 2015 at 06:51:13PM -0300, Paulo Zanoni wrote:
> >> +static void skl_wrpll_try_divider(struct skl_wrpll_context *ctx,
> >> + uint64_t central_freq,
> >> + uint64_t dco_freq,
> >> + unsigne
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index a8f48dd..479c97b 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/driver
Turn on interrupt steering to route necessary interrupts to GuC.
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +++
2 files changed, 60 ins
From: Alex Dai
Add overview design of GuC, plus some key points related to
the implementation.
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
Documentation/DocBook/drm.tmpl | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Docu
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_debugfs.c | 40 +++
1 file c
From: Alex Dai
Two new module parameters: "enable_guc_submission" which will turn
on submission of batchbuffers via the GuC (when implemented), and
"guc_log_level" which controls the level of debugging logged by the
GuC and captured by the host.
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordo
From: Alex Dai
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i
From: Alex Dai
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes
This function was restructured by two recent patches:
drm/i915: Add explicit request management to i915_gem_init_hw()
drm/i915: Moved the for_each_ring loop outside of i915_gem_context_enable()
Now we need to move the entire loop into a separate function
i915_gem_init_hw_late(), replacing
From: Alex Dai
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address that is NOT in the
In order to fully initialise the default contexts, we have to execute
batchbuffer commands on the GPU engines. But in the case of GuC-based
batch submission, we can't do that until any required firmware has
been loaded, which may not be possible during driver load, because the
filesystem(s) contain
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use; doorbel
From: Alex Dai
The new node provides access to the status of the common uC loader
code and the GuC-specific loader; also the scratch registers used
for communication between the i915 driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
Issue: VIZ-4884
Si
From: Alex Dai
This uses the unified firmware loader to fetch the firmware image,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky. It has been reconstructed to accord
with the unified firmw
i915_gem_object_create_from_data() is a generic function to save data
from a plain linear buffer in a new pageable gem object that can later
be accessed by the CPU and/or GPU.
We will need this for the microcontroller firmware loading support code.
Derived from i915_gem_object_write(), originally
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to prepare a context for submission via the
GuC, we need some of the same functions used in execlist mode.
This commit exposes two such functions,
intel_guc_fwif.h contains the subset of the GuC interface that we
will need for submission of commands through the GuC. These MUST
be kept in sync with the definitions used by the GuC firmware, and
updates to this file will (or should) be autogenerated from the
source files used to build the firmwa
Current devices may contain one or more programmable microcontrollers
that need to have a firmware image (aka "binary blob") loaded from an
external medium and transferred to the device's memory.
This file provides generic support functions for doing this; they can
then be used by each uC-specific
This patch series enables command submission via the GuC. In this mode,
instead of the host CPU driving the execlist port directly, it hands
over work items to the GuC, using a doorbell mechanism to tell the GuC
that new items have been added to its work queue. The GuC then dispatches
contexts to t
Thanks! :D
Thanks,
Zhi.
于 06/25/15 21:42, Chris Wilson 写道:
On Thu, Jun 25, 2015 at 05:56:58AM +0800, Zhi Wang wrote:
Hi Chris:
Thanks for the reply! I just dig the code. It looks there is no
special code path for execlist shutdown. It has init_rings(), but
doesn't have cleanup_rings(), on
On Thu, Jun 25, 2015 at 05:56:58AM +0800, Zhi Wang wrote:
> Hi Chris:
> Thanks for the reply! I just dig the code. It looks there is no
> special code path for execlist shutdown. It has init_rings(), but
> doesn't have cleanup_rings(), only clean_ring(), which are called
> for each ring one by
On Thu, Jun 25, 2015 at 04:23:43PM +0300, Joonas Lahtinen wrote:
> On to, 2015-06-25 at 13:49 +0100, Chris Wilson wrote:
> > On Thu, Jun 25, 2015 at 03:04:44PM +0300, Joonas Lahtinen wrote:
> > > Add forking subtests to gem_ringfill. Tests cause consistent GPU
> > > hangs on SKL.
> > >
> > > Cc: M
Hi Chris:
Thanks for the reply! I just dig the code. It looks there is no
special code path for execlist shutdown. It has init_rings(), but
doesn't have cleanup_rings(), only clean_ring(), which are called for
each ring one by one when i915_gem_cleanup_ringbuffer() gets called.
Do you hav
On Thu, Jun 25, 2015 at 6:17 PM, Ville Syrjälä
wrote:
> On Thu, Jun 25, 2015 at 05:38:50PM +0530, Shobhit Kumar wrote:
>> On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
>> wrote:
>> > On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
>> >> Use the CRC PWM device in intel_panel.c and
On to, 2015-06-25 at 13:49 +0100, Chris Wilson wrote:
> On Thu, Jun 25, 2015 at 03:04:44PM +0300, Joonas Lahtinen wrote:
> > Add forking subtests to gem_ringfill. Tests cause consistent GPU
> > hangs on SKL.
> >
> > Cc: Mika Kuoppala
> > Signed-off-by: Joonas Lahtinen
> > Bugzilla: https://bugs.
On Thu, Jun 25, 2015 at 09:13:13AM +0100, Chris Wilson wrote:
> On Thu, Jun 25, 2015 at 10:40:15PM +0800, bing@intel.com wrote:
> > From: "Niu,Bing"
> >
> > It is found that i915 will not reset gpu under execlist mode when
> > unload module. that will lead to some issues when unload/load modu
On Thu, Jun 25, 2015 at 02:18:06PM +0300, David Weinehall wrote:
> On Thu, Jun 25, 2015 at 09:37:22AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 25, 2015 at 09:14:09AM +0300, David Weinehall wrote:
> > > Looks good.
> > >
> > > Reviewed-by: David Weinehall
> > >
> > > On Thu, Jun 18, 2015 at 02
On 6/24/2015 4:51 AM, Ben Widawsky wrote:
Hi. Feel free to Cc me on patches of this nature. I am far behind on mesa-dev,
and no longer read intel-gfx. I'm probably one of the sensible people to look at
this...
On Tue, Jun 23, 2015 at 01:21:27PM +0100, Michel Thierry wrote:
Gen8+ supports 48-bit
>> Robert, any thoughts?
>>
>
> I think a few pertinent details here that inform how we need to handle this
> are:
>
> 1) Almost all the pmu methods are called in atomic context (except
> event_init) as they are invoked via events/core.c via an
> inter-processor interrupt so waiting for a completi
On Thu, Jun 25, 2015 at 7:02 AM, Gupta, Sourab wrote:
> On Mon, 2015-06-22 at 16:09 +, Daniel Vetter wrote:
>> On Mon, Jun 22, 2015 at 02:22:54PM +0100, Chris Wilson wrote:
>> > On Mon, Jun 22, 2015 at 03:25:07PM +0530, sourab.gu...@intel.com wrote:
>> > > From: Sourab Gupta
>> > >
>> > > To
Peter Antoine writes:
> This change adds the programming of the MOCS registers to the gen 9+
> platforms. This change set programs the MOCS register values to a set
> of values that are defined to be optimal.
>
> It creates a fixed register set that is programmed across the different
> engines so
On Thu, Jun 25, 2015 at 12:24:59PM +, Wang, Zhi A wrote:
> Hi Chris:
> Thanks for the comments that extends our knowledge about this
> modification. Really appreciate the help. But is it possible that we still
> need an ordinary gpu reset here? Consider that we may modprobe i915 with
> i
On Thu, Jun 25, 2015 at 04:22:38PM +0800, Raymond Yau wrote:
> > >
> > > Shall we move or cc this discussion on audio driver side to ALSA ML?
> >
> > Oops I thought I had cc'ed these patches to alsa-devel as well when I
> sent them.
> >
> > > I think we also need to decide how to manage PCM devices
On Thu, Jun 25, 2015 at 03:04:44PM +0300, Joonas Lahtinen wrote:
> Add forking subtests to gem_ringfill. Tests cause consistent GPU
> hangs on SKL.
>
> Cc: Mika Kuoppala
> Signed-off-by: Joonas Lahtinen
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
> ---
> tests/gem_ringfill.c
On Thu, Jun 25, 2015 at 05:38:50PM +0530, Shobhit Kumar wrote:
> On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
> wrote:
> > On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
> >> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
> >> specififc callbacks
> >>
> >> v2:
On Tue, Jun 23, 2015 at 12:49 PM, Lee Jones wrote:
> On Mon, 22 Jun 2015, Daniel Vetter wrote:
>
>> On Mon, Jun 22, 2015 at 04:33:22PM +0530, Varka Bhadram wrote:
>> > Hi Shobhit Kumar,
>> >
>> > On 06/22/2015 04:24 PM, Shobhit Kumar wrote:
>> >
>> > >On some BYT PLatform the PWM is controlled usi
On 24/06/15 10:32, Daniel Vetter wrote:
> On Thu, Jun 18, 2015 at 07:28:26PM +0100, Dave Gordon wrote:
>> On 18/06/15 15:31, Daniel Vetter wrote:
>>> On Thu, Jun 18, 2015 at 12:49:55PM +0100, Dave Gordon wrote:
On 17/06/15 13:02, Daniel Vetter wrote:
> On Wed, Jun 17, 2015 at 08:23:40AM +0
1 - 100 of 134 matches
Mail list logo
