On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote:
> On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote:
> > Silences
> >
> > src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used
> > uninitialized in this function [-Wuninitialized]
> >
> > Reported-by: Geert Uytt
== Series Details ==
Series: drm/i915: Set ctx->ppgtt to aliasing PPGTT if full PPGTT mode isn't
enabled
URL : https://patchwork.freedesktop.org/series/5261/
State : failure
== Summary ==
Series 5261v1 drm/i915: Set ctx->ppgtt to aliasing PPGTT if full PPGTT mode
isn't enabled
http://patchwo
Signed-off-by: Eric Engestrom
---
lib/gpgpu_fill.c | 4 ++--
lib/igt_aux.h| 2 +-
lib/igt_core.c | 6 +++---
lib/igt_core.h | 4 ++--
lib/intel_reg.h | 2 +-
lib/ioctl_wrappers.c | 2 +-
lib/media_fill_gen8.c| 2 +-
lib/media_fill_gen8lp.c
Signed-off-by: Eric Engestrom
---
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README b/README
index d302af3..cfb6ab2 100644
--- a/README
+++ b/README
@@ -29,7 +29,7 @@ tests/
changes. Many of the tests have subtests, which can be listed by using
the
Hi,
referring to the recent exchange here:
http://www.spinics.net/lists/intel-gfx/msg91010.html
the response only mentions correct gamma ramp support, but it looks to me as if
there is much more missing than in existence when it comes to 30-bit color depth
support in Linux using Intel Graphics.
Signed-off-by: Eric Engestrom
---
tools/intel_audio_dump.c | 14 +++---
tools/intel_bios.h| 6 +++---
tools/intel_display_poller.c | 2 +-
tools/intel_dump_decode.c | 2 +-
tools/intel_opregion_decode
Signed-off-by: Eric Engestrom
---
tests/gem_concurrent_all.c | 2 +-
tests/gem_cpu_reloc.c | 2 +-
tests/gem_flink_race.c | 2 +-
tests/gem_seqno_wrap.c | 2 +-
tests/gem_tiled_wb.c | 2 +-
tests/prime_nv_api.c | 2 +-
tests/prime_nv_pcopy.c | 2 +-
tests/prime_self_i
Signed-off-by: Eric Engestrom
---
assembler/brw_defines.h| 2 +-
assembler/brw_eu_compact.c | 2 +-
assembler/brw_eu_emit.c| 4 ++--
assembler/gen4asm.h| 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/assembler/brw_defines.h b/assembler/brw_defines.h
index
On Mon, 04 Apr 2016, Chris Wilson wrote:
> On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote:
>> On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote:
>> > Silences
>> >
>> >src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used
>> > uninitialized in this function [-
On Mon, Apr 04, 2016 at 11:45:26AM +0300, Jani Nikula wrote:
> On Mon, 04 Apr 2016, Chris Wilson wrote:
> > On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote:
> >> On su, 2016-04-03 at 21:59 +0100, Chris Wilson wrote:
> >> > Silences
> >> >
> >> > src/drivers/gpu/drm/i915/intel_ddi
Jani/Daniel,
I am working on implementing the pipe_config compare as suggested by
daniel at
https://lists.freedesktop.org/archives/intel-gfx/2016-March/091148.html
But I think this patch need not wait for that change. Either way this
patch is required. We can continue review on this and proc
On ma, 2016-04-04 at 10:00 +0100, Chris Wilson wrote:
> On Mon, Apr 04, 2016 at 11:45:26AM +0300, Jani Nikula wrote:
> >
> > On Mon, 04 Apr 2016, Chris Wilson wrote:
> > >
> > > On Mon, Apr 04, 2016 at 09:20:27AM +0300, Joonas Lahtinen wrote:
> > > >
> > > > On su, 2016-04-03 at 21:59 +0100, Ch
On 03/04/16 17:35, Eric Engestrom wrote:
Signed-off-by: Eric Engestrom
---
tests/gem_concurrent_all.c | 2 +-
tests/gem_cpu_reloc.c | 2 +-
tests/gem_flink_race.c | 2 +-
tests/gem_seqno_wrap.c | 2 +-
tests/gem_tiled_wb.c | 2 +-
tests/prime_nv_api.c | 2 +-
tes
On Mon, 04 Apr 2016, Joonas Lahtinen wrote:
> Well, enumeration values *known* not to be acceptable should cause a
> ERR_PTR(-EINVAL) or along that route, and there should be a
> MISSING_CASE for rest totally unexpected values.
In this case, they're all the same. No use returning errors when this
On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>> URL : https://patchwork.freedesktop.org/series/5044/
>> State : success
>
> I pushe
On Fri, Apr 01, 2016 at 04:02:36PM +0300, Imre Deak wrote:
> So far we only power well enabling was synchronous not disabling. Since
> we don't exactly know how the firmware (both DMC and PCU) synchronizes
> against the actual power well state during DC transitions, make the
> disabling also synchr
On Fri, Apr 01, 2016 at 04:02:37PM +0300, Imre Deak wrote:
> The display power well support and DC state management doesn't depend on
> runtime PM support, so remove the incorrect asserts about this.
>
> Also Broxton does support DC5, so the related assert in
> assert_can_enable_dc5() is incorrect
On Friday 01 April 2016 01:11 PM, Ander Conselvan De Oliveira wrote:
On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
== Series Details ==
Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
URL : https://patchwork.freedesktop.org/series/5044/
State : success
I pushed
On Mon, 04 Apr 2016, Tvrtko Ursulin wrote:
> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>> On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
>>> == Series Details ==
>>>
>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>>> URL : https://patchwork.freedeskto
From: Tvrtko Ursulin
Doing a lot of work in the interrupt handler introduces huge
latencies to the system as a whole.
Most dramatic effect can be seen by running an all engine
stress test like igt/gem_exec_nop/all where, when the kernel
config is lean enough, the whole system can be brought into
Pasted below are Bat results (don't seem to get an email from Bat anymore).
> Series 4282v3 drm/i915: implement WaClearTdlStateAckDirtyBits
> http://patchwork.freedesktop.org/api/1.0/series/4282/revisions/3/mbox/
>
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pas
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get fragmented
severely, which considerably slows down the system. In such a scenario,
Shrinker is also unable to help as lack of memory is not the actual problem,
since it has been observed that there are enough fre
On Fri, Apr 01, 2016 at 04:02:38PM +0300, Imre Deak wrote:
> On SKL/KBL suspend-to-idle (aka freeze/s0ix) is performed with DMC
> firmware assistance where the target display power state is DC6. On
> Broxton on the other hand we don't use the firmware for this, but rely
> instead on a manual DC9 fl
On Mon, Apr 04, 2016 at 12:11:56PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Doing a lot of work in the interrupt handler introduces huge
> latencies to the system as a whole.
>
> Most dramatic effect can be seen by running an all engine
> stress test like igt/gem_exec_nop/all wher
On 04/04/16 12:08, Jani Nikula wrote:
On Mon, 04 Apr 2016, Tvrtko Ursulin wrote:
On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
On Thu, 2016-03-31 at 12:38 +, Patchwork wrote:
== Series Details ==
Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
URL : http
From: Ville Syrjälä
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add
From: Ville Syrjälä
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
and take it into account when checking the port clock.
Note that as with the sink (HDMI vs. DVI) TMDS clock limit we
From: Ville Syrjälä
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we'
From: Ville Syrjälä
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
DP dual mode type 1 DVI adaptors aren't required to implement any
registers, so it's a bit hard
This patch adds support for LSPCON devices in dp++ adaptor
helper layer. LSPCON is DP++ type-2 adaptor with some customized
functionalities, to provide additional features in Intel Gen9 HW.
LSPCON needs I2C-over-aux support to read/write control and
data registers. This patch adds following:
- F
This patch adds lspcon's internal functions, which work
on the probe layer, and indicate the working status of
lspcon, which are mostly:
probe: A lspcon device is probed only once, during boot
time, as its always present with the device, next to port.
So the i2c_over_aux channel is alwyas read/wri
This patch adds a new hpd handler for lspcon.
As lspcon has its own way of reading EDID and detecting
the device, it wont be efficient to use the existing hpd
functions to handle the hot_plug scenarios. This new function
reads the EDID and checks the status of the sink device.
Signed-off-by: Shash
This patch adds lspcon structure in intel_dig_port.
These strucres will be used to check runtime status
of LSPCON device.
Signed-off-by: Shashank Sharma
Signed-off-by: Akashdeep Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 16
1 file changed, 16 insertions(+)
diff --git a/dri
lspcon is a device which acts as DP in some cases
and as HDMI in some. Here is how:
- lspcon needs DP(aux) for all the i2c_ove_aux read/write
transitions so it needs to have some DP level initializations
- lspcon is detected by userspace/sink as HDMI device, so
it needs to be detectd as HDMI de
This patch adds various lspcon connector functions. Some
of the functions are newly written, to meet the specific
needs of lspcon HW, whereas few of them are just an
abstraction layer on existing HDMI connector functions.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h |
This patch adds a hack to enable lspcon on GEN9 devices.
This should not be merged, and the hack must be replaced
by proper VBT parsing logic.
Expecting this patch to enable lspcon bits in VBT:
https://lists.freedesktop.org/archives/intel-gfx/2016-March/089541.html
Signed-off-by: Shashank Sharma
This patch adds a new file for lspcon with
some basic stuff like:
- Some read/wrire addresses for lspcon device
- Basic read/write functions, using i2c over aux channel
- Utility functions to get lspcon/encoder/connector
Signed-off-by: Shashank Sharma
Signed-off-by: Akashdeep Sharma
---
drivers
On Fri, Apr 01, 2016 at 04:02:39PM +0300, Imre Deak wrote:
> On Broxton we need to enable/disable power well 1 during the init/unit display
> sequence similarly to Skylake/Kabylake. The code for this will be added in a
> follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's
== Series Details ==
Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
URL : https://patchwork.freedesktop.org/series/4764/
State : failure
== Summary ==
Series 4764v4 drm/i915: Move execlists irq handler to a bottom half
http://patchwork.freedesktop.org/api/1.0/series/4764/
On ma, 2016-04-04 at 14:30 +0200, Patrik Jakobsson wrote:
> On Fri, Apr 01, 2016 at 04:02:39PM +0300, Imre Deak wrote:
> > On Broxton we need to enable/disable power well 1 during the
> > init/unit display
> > sequence similarly to Skylake/Kabylake. The code for this will be
> > added in a
> > foll
On 04/04/16 13:33, Patchwork wrote:
== Series Details ==
Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
URL : https://patchwork.freedesktop.org/series/4764/
State : failure
== Summary ==
Series 4764v4 drm/i915: Move execlists irq handler to a bottom half
http://patchw
On Broxton we need to enable/disable power well 1 during the init/unit display
sequence similarly to Skylake/Kabylake. The code for this will be added in a
follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's
a simple function called only from a single place and having it
On 04/04/16 12:27, Chris Wilson wrote:
On Mon, Apr 04, 2016 at 12:11:56PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Doing a lot of work in the interrupt handler introduces huge
latencies to the system as a whole.
Most dramatic effect can be seen by running an all engine
stress test l
On Mon, Apr 04, 2016 at 01:42:06PM +0100, Tvrtko Ursulin wrote:
>
>
> On 04/04/16 13:33, Patchwork wrote:
> >== Series Details ==
> >
> >Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
> >URL : https://patchwork.freedesktop.org/series/4764/
> >State : failure
> >
> >== Summ
On Mon, Apr 04, 2016 at 03:42:57PM +0300, Imre Deak wrote:
> On Broxton we need to enable/disable power well 1 during the init/unit display
> sequence similarly to Skylake/Kabylake. The code for this will be added in a
> follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's
> > Have you tried running the I-G-T testing suite on your hardware?
>
> No I haven't - do I just install intel-gpu-tools and find some test
> program to run?
I cloned the git repo for this and tried to run the tests as best I
could understand from the readme, but no luck:
intel-gpu-tools/te
On 04/04/16 13:53, Chris Wilson wrote:
On Mon, Apr 04, 2016 at 01:42:06PM +0100, Tvrtko Ursulin wrote:
On 04/04/16 13:33, Patchwork wrote:
== Series Details ==
Series: drm/i915: Move execlists irq handler to a bottom half (rev4)
URL : https://patchwork.freedesktop.org/series/4764/
State :
== Series Details ==
Series: series starting with [1/2] shmem: Support for registration of
Driver/file owner specific ops (rev3)
URL : https://patchwork.freedesktop.org/series/4780/
State : failure
== Summary ==
Series 4780v3 Series without cover letter
http://patchwork.freedesktop.org/api/1.
From: Akash Goel
On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been observed that there are enough f
From: Akash Goel
This provides support for the drivers or shmem file owners to register
a set of callbacks, which can be invoked from the address space
operations methods implemented by shmem. This allow the file owners to
hook into the shmem address space operations to do some extra/custom
oper
> That seems like a legit bug. If you can reproduce it with drm-intel-
> nightly, could you please open a bug at freedesktop.org bugzilla?
Just had this happen after running drm-intel-nightly for 18 days, so I
have opened a bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=94814
> Have you
== Series Details ==
Series: series starting with [01/12] drm: Add helper for DP++ adaptors
URL : https://patchwork.freedesktop.org/series/5273/
State : failure
== Summary ==
Series 5273v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5273/revisions/1/mbox/
Test
The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.
The RCS registers and the L3CC registers are s
vmaps are temporary kernel mappings that may be of long duration.
Reusing a vmap on an object is preferrable for a driver as the cost of
setting up the vmap can otherwise dominate the operation on the object.
However, the vmap address space is rather limited on 32bit systems and
so we add a notific
Since we only attempt to purge an object if can_release_pages() report
true, we should also only add it to the count of potential recoverable
pages when can_release_pages() is true.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Akash Goel
---
drivers/gpu/drm/i915/i915
If the core runs out of vmap address space, it will call a notifier in
case any driver can reap some of its vmaps. As i915.ko is possibily
holding onto vmap address space that could be recovered, hook into the
notifier chain and try and reap objects holding onto vmaps.
Signed-off-by: Chris Wilson
Andrew has already acked this for merge through the DRM tree, but it still
needs a review. vmalloc() is quite an extensively used interface so the key
question is have we broken anything by adding a blocking notifier into the
callchain (though we only block if gfp_t says we can).
-Chris
__
On Mon, Apr 04, 2016 at 02:43:08PM +0100, Peter Antoine wrote:
> +static void run_test(int fd, unsigned mode)
> +{
> + const int gen = intel_gen(intel_get_drm_devid(fd));
> + const struct intel_execution_engine *e;
> +
> + igt_require(gen >= 9);
> +
> + test_mocs_values(fd);
> +
> +
On ma, 2016-04-04 at 15:01 +0200, Patrik Jakobsson wrote:
> On Mon, Apr 04, 2016 at 03:42:57PM +0300, Imre Deak wrote:
> > On Broxton we need to enable/disable power well 1 during the
> > init/unit display
> > sequence similarly to Skylake/Kabylake. The code for this will be
> > added in a
> > foll
== Series Details ==
Series: drm/i915/bxt: Fix/enable display power well support/runtime PM (rev3)
URL : https://patchwork.freedesktop.org/series/5177/
State : failure
== Summary ==
CC [M] drivers/net/ethernet/realtek/8139cp.o
CC [M] drivers/net/ethernet/realtek/8139too.o
LD drive
Em Sex, 2016-04-01 às 17:45 +0300, Ville Syrjälä escreveu:
> On Thu, Mar 31, 2016 at 10:06:37PM +, Zanoni, Paulo R wrote:
> >
> > Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
> > escreveu:
> > >
> > > From: Ville Syrjälä
> > >
> > > DP dual mode type 1 DVI adaptors aren'
I caught a few errors in our current PHY/CDCLK programming by sanity
checking the actual programmed state, so I thought it would be also
useful for the future. In addition to verifying the state after
programming it also verify it after exiting DC5, to make sure DMC
restored/kept intact everything
== Series Details ==
Series: series starting with [v4,1/2] shmem: Support for registration of
driver/file owner specific ops
URL : https://patchwork.freedesktop.org/series/5274/
State : failure
== Summary ==
Series 5274v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/se
On Thu, Mar 31, 2016 at 09:07:09AM +0200, Boris Brezillon wrote:
> Hi Guenter,
>
> On Wed, 30 Mar 2016 15:52:44 -0700
> Guenter Roeck wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:31PM +0200, Boris Brezillon wrote:
> > > The PWM framework has clarified the concept of reference PWM config
> > > (the
On Thu, Mar 31, 2016 at 08:54:54PM +0200, Boris Brezillon wrote:
> Hi Dmitry,
>
> On Thu, 31 Mar 2016 10:38:58 -0700
> Dmitry Torokhov wrote:
>
> > Hi Boris,
> >
> > On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> > > Prefix those function as deprecated to encourage all exist
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/shrinker: Account for
unshrinkable unbound pages
URL : https://patchwork.freedesktop.org/series/5276/
State : success
== Summary ==
Series 5276v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/527
On Thu, Mar 31, 2016 at 08:57:35AM +0200, Boris Brezillon wrote:
> Hi Stephen,
>
> On Wed, 30 Mar 2016 15:01:49 -0700
> Stephen Boyd wrote:
>
> > On 03/30, Boris Brezillon wrote:
> > > diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> > > index ebcd738..49ec5b1 100644
> > > --- a/driv
On Thu, Mar 31, 2016 at 08:57:18PM +0200, Boris Brezillon wrote:
> On Thu, 31 Mar 2016 10:48:01 -0700
> Dmitry Torokhov wrote:
>
> > Hi Boris,
> >
> > On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> > > pwm_config/enable/disable() have been deprecated and should be replaced
>
igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
set-up.
Signed-off-by: Marius Vlad
---
lib/igt_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..30c5b7e 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@
On Thursday 31 March 2016 12:34 AM, Daniel Vetter wrote:
On Wed, Mar 30, 2016 at 07:49:40PM +0530, Ramalingam C wrote:
On Wednesday 30 March 2016 05:02 PM, Daniel Vetter wrote:
On Tue, Mar 29, 2016 at 11:04:51PM +0530, Ramalingam C wrote:
At BXT DSI, PIPE registers are inactive. So we can't g
Hi Marius,
Thanks for this. I have the same patch on a branch I haven't send yet
(oops).
In my patch I implemented this by setting src_* to 0 if fb_id == 0.
I'm not sure what makes more sense but anyway :
Reviewed-by: Lionel Landwerlin
On 04/04/16 16:47, Marius Vlad wrote:
igt_atomic_prepa
== Series Details ==
Series: drm/i915/bxt: Fix/enable display power well support/runtime PM (rev4)
URL : https://patchwork.freedesktop.org/series/5177/
State : failure
== Summary ==
Series 5177v4 drm/i915/bxt: Fix/enable display power well support/runtime PM
http://patchwork.freedesktop.org/ap
On Mon, Apr 04, 2016 at 06:47:25PM +0300, Marius Vlad wrote:
> igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
> set-up.
>
> Signed-off-by: Marius Vlad
> ---
> lib/igt_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt
On Fri, Mar 18, 2016 at 01:11:10PM +0200, Jani Nikula wrote:
> In sequence block v2, and only in v2, the gpio source (i.e. IOSF port)
> is specified separately.
>
> v2: initialize gpio_source to 0 and handle v1 and v2 in the same branch
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
From: Tvrtko Ursulin
Current implementation releases the forcewake at any time between
straight away, and one jiffie from the last put, or first automatic
grab.
This does not sound like what was desired since jiffies are typically
between 1 and 10ms depending on the kernel configuration.
Change
From: Tvrtko Ursulin
On platforms with multiple forcewake domains it seems more efficient
to request all desired ones and then to wait for acks to avoid
needlessly serializing on each domain.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 4 +++-
1 file changed, 3 inse
From: Tvrtko Ursulin
As the vast majority of users does not use the domain id variable,
we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.
For a couple of callers which do need the domain id, or the domain
mask, sto
On Fri, Mar 18, 2016 at 01:11:11PM +0200, Jani Nikula wrote:
> Define and store the pad base offset in the array, and reference the
> pconf0 and padval registers through macros. Add VLV prefixes to
> macros. Use spec nomenclature for pconf0 and padval.
>
> v2: Address Ville's review comments, squa
Response inline.
On Mon, 4 Apr 2016, Chris Wilson wrote:
On Mon, Apr 04, 2016 at 02:43:08PM +0100, Peter Antoine wrote:
+static void run_test(int fd, unsigned mode)
+{
+ const int gen = intel_gen(intel_get_drm_devid(fd));
+ const struct intel_execution_engine *e;
+
+ igt_requ
On Fri, Mar 18, 2016 at 01:11:12PM +0200, Jani Nikula wrote:
> This lets us specify the exact gpios we want to let through, without
> leaving holes in the array.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 54
> ++
> 1 file cha
On Fri, Mar 18, 2016 at 01:11:15PM +0200, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0
On Fri, Mar 18, 2016 at 01:11:17PM +0200, Jani Nikula wrote:
> Use a table similar to vlv to check for accepted gpio indexes. For now,
> add all, but this list should be trimmed down. Use managed gpio request,
> which will be automatically released when the driver is detached.
>
> Signed-off-by: J
After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loaded the GuC with
firmware, which will then cause this kernel's attempt to (re)load the
firmware to fail
This is a resend, primarily for CI purposes. All patches to be
merged have already been reviewed. The final patch (NOT to be
merged) enables GuC loading and submission for testing purposes.
Arun Siluvery (1):
drm/i915/guc: reset GuC and retry on firmware load failure
Dave Gordon (2):
drm/i915
Split the function of "enable_guc_submission" into two separate options.
The new one "enable_guc_loading" controls only the *fetching and loading*
of the GuC firmware image. The existing one is redefined to control only
the *use* of the GuC for batch submission once the firmware is loaded.
In addi
From: Arun Siluvery
Due to timing issues in the HW, some of the status bits required for GuC
authentication occasionally don't get set; when that happens, the GuC
cannot be initialized and we will be left with a wedged GPU. The W/A
suggested is to perform a soft reset of the GuC and attempt to re
With IPC(Isochronous Priority Control) enabled,
display sends requests based on the priority of each
request. To enable it, a i915 param, i915.enable_ipc
should be set to 1.
v2: corrected matched type of enable_ipc in
module_param_named_unsafe macro
Signed-off-by: Dongwon Kim
---
drivers/gp
On Fri, Mar 18, 2016 at 01:11:16PM +0200, Jani Nikula wrote:
> From: Yogesh Mohan Marimuthu
>
> Add support for CHV gpio programming in DSI gpio elements.
>
> XXX: I'd like to have a gpio table for chv as well as others.
>
> [Rewritten by Jani, based on earlier work by Yogesh and Deepak.]
>
>
On 04/04/16 17:51, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Current implementation releases the forcewake at any time between
straight away, and one jiffie from the last put, or first automatic
grab.
This does not sound like what was desired since jiffies are typically
between 1 and 10ms dep
On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Current implementation releases the forcewake at any time between
> straight away, and one jiffie from the last put, or first automatic
> grab.
That isn't the problem though. The problem is that we set the
On Mon, Apr 04, 2016 at 05:51:10PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> As the vast majority of users does not use the domain id variable,
> we can eliminate it from the iterator and also change the latter
> using the same principle as was recently done for for_each_engine.
>
On Mon, Apr 04, 2016 at 05:51:11PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> On platforms with multiple forcewake domains it seems more efficient
> to request all desired ones and then to wait for acks to avoid
> needlessly serializing on each domain.
Not convinced since we have mo
On 04/04/16 17:51, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the vast majority of users does not use the domain id variable,
"do not use"
we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.
For a couple of
On 04/04/16 19:58, Chris Wilson wrote:
On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Current implementation releases the forcewake at any time between
straight away, and one jiffie from the last put, or first automatic
grab.
That isn't the problem thoug
On Mon, Apr 04, 2016 at 06:30:21PM +0100, Peter Antoine wrote:
> >As well as checking for creating new contexts after resume, we also need
> >to check that the register values are preserved across suspend (i.e.
> >that the register state is being saved back into the context image and
> >then restor
On Mon, Apr 04, 2016 at 08:41:20PM +0100, Dave Gordon wrote:
> On 04/04/16 19:58, Chris Wilson wrote:
> >On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Current implementation releases the forcewake at any time between
> >>straight away, and one ji
i915 does not yet support the atomic modesetting interface by default;
at the moment it must be turned on explicitly via an
'i915.nuclear_pageflip' kernel command line option. We should skip
(rather than fail) this IGT test when running on kernels that don't
advertise support for atomic modesettin
From: Chris Wilson
... instead of the previous ORIGIN_GTT. This should actually
invalidate FBC once something is written on the frontbuffer using WC
mmaps. The problem with ORIGIN_GTT is that the automatic hardware
tracking is not able to detect the WC writes as it can detect the GTT
writes.
Thi
Now with the suggestion from Chris instead of the old workaround. We don't need
new DDX patches anymore, but now we need new IGT patches.
Chris Wilson (1):
drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps
Paulo Zanoni (3):
drm/i915/fbc: update busy_bits even for GTT and flip
We ignore ORIGIN_GTT because the hardware tracking can recognize GTT
writes and take care of them. We also ignore ORIGIN_FLIP because we
deal with flips without relying on the frontbuffer tracking
infrastructure. On the other hand, a flush is a flush and means we're
good to go, so we need to update
1 - 100 of 109 matches
Mail list logo
