Current it's strictly checked if PVINFO version matches 1.0
for GVT-g i915 guest which doesn't help for compatibility at
all and forces GVT-g host can't extend PVINFO easily with version
bump for real compatibility check.
This fixes that to check minimal required PVINFO version instead.
v2:
- dro
== Series Details ==
Series: drm/i915: Fix GVT-g PVINFO version compatibility check (rev2)
URL : https://patchwork.freedesktop.org/series/25275/
State : success
== Summary ==
Series 25275v2 drm/i915: Fix GVT-g PVINFO version compatibility check
https://patchwork.freedesktop.org/api/1.0/series/
On Wed, Jun 07, 2017 at 04:54:53PM -0700, Eric Anholt wrote:
> CONTRIBUTING requests that people do this, but it's a lot easier if we
> just set it up by default for them.
>
> Signed-off-by: Eric Anholt
> ---
>
> I missed this step on my previous two patches, so let's just prevent
> that in the
Just when I was looking at the hell of writing a .dir-locals.el...
Editorconfig was new to me, thanks for this!
On Wed, Jun 07, 2017 at 04:45:30PM -0700, Eric Anholt wrote:
> This makes my emacs default to consistent indentation for the project.
>
> Signed-off-by: Eric Anholt
> ---
> .editor
On Wed, 07 Jun 2017, Vidya Srinivas wrote:
> This patch series is adding NV12 support for Skylake display after
> rebasing on latest drm-intel-nightly. Initial series of the patches
> can be found here:
> https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html
Please post new versio
On to, 2017-06-08 at 14:58 +0800, Zhenyu Wang wrote:
> Current it's strictly checked if PVINFO version matches 1.0
> for GVT-g i915 guest which doesn't help for compatibility at
> all and forces GVT-g host can't extend PVINFO easily with version
> bump for real compatibility check.
>
> This fixes
On ti, 2017-06-06 at 12:57 -0700, Michel Thierry wrote:
> On 6/5/2017 10:32 AM, Patchwork wrote:
> >
> > == Series Details ==
> >
> > Series: drm/i915/guc: Clear enable_guc_loading in case of init failure
> > (rev2)
> > URL : https://patchwork.freedesktop.org/series/25228/
> > State : success
From: Ander Conselvan de Oliveira
commit c34f078675f505c4437919bb1897b1351f16a050 upstream.
In the path where intel_crt_detect_ddc() detects a CRT, if would return
true without freeing the edid.
Fixes: a2bd1f541f19 ("drm/i915: check whether we actually received an edid in
detect_ddc")
Cc: Chri
On ma, 2017-06-05 at 11:26 +0100, Chris Wilson wrote:
> Settting up the irq to signal the request completion takes a finite
> amount of time, during which it is possible that the request already
> completed. Check afterwards, just in case, so that we can respond
> immediately.
>
> Signed-off-by: C
Hi,
This is first gvt-next pull for 4.13. I'd like to send as early as
possible, although there're still planned patches to merge, so will
put for next pull. Details below. This is mostly for performance
optimization and cleanups.
Thanks
--
The following changes since commit cd9f4688a3297c0df0ee
On ma, 2017-06-05 at 11:26 +0100, Chris Wilson wrote:
> Enabling the interrupt for the signaler takes a finite amount of time (a
> few microseconds) during which it is possible for the request to
> complete. Check afterwards and skip adding the request to the signal
> rbtree if it complete.
>
> Si
During cleanup we release the VMA of the previous framebuffer. This
requires taking a struct_mutex, and potential recursion when handling a
reset. A simple device here is to move that locking into its own work
and we can avoid blocking on it for the reset by waiting on the flip
completion (and not
Reduce acquisition of struct_mutex to the critical regions that must
hold it; for KMS, we need struct_mutex currently only for the purpose of
pinning/unpinning the framebuffer's VMA into the global GTT. This allows
us to avoid taking the struct_mutex when disabling the CRTC (i.e. NULL
framebuffer o
From: Tvrtko Ursulin
Most of the subtest were failing on my SKL GT2 and on the
various CI systems as well. Try to fix that by different
tweaks per subtests:
performance:
We cannot say how big the performance drop will be once the
fences are contented, just that there will be one, so modify
the
From: Tvrtko Ursulin
This is not a correctness test so move it to benchmarks and off
the extended test list.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/.gitignore| 1 +
benchmarks/Makefile.am | 3 +++
benchmarks/Makefile.sources | 1 +
{test
On ma, 2017-06-05 at 11:26 +0100, Chris Wilson wrote:
> Originally we would enable and disable the breadcrumb interrupt
> immediately on demand. This was slow enough to have a large impact
> (>30%) on tasks that hopped between engines. However, by using a shadow
> to keep the irq alive for an extra
Quoting Joonas Lahtinen (2017-06-08 11:02:40)
> On ma, 2017-06-05 at 11:26 +0100, Chris Wilson wrote:
> > Originally we would enable and disable the breadcrumb interrupt
> > immediately on demand. This was slow enough to have a large impact
> > (>30%) on tasks that hopped between engines. However,
On ma, 2017-06-05 at 11:26 +0100, Chris Wilson wrote:
> The important condition that we need to check after enabling the
> interrupt for signaling is whether the request completed in the process
> (and so we missed that interrupt). A large cost in enabling the
> signaling (rather than waiters) is i
Chris Wilson writes:
> The important condition that we need to check after enabling the
> interrupt for signaling is whether the request completed in the process
> (and so we missed that interrupt). A large cost in enabling the
> signaling (rather than waiters) is in waking up the auxiliary signa
== Series Details ==
Series: series starting with [1/2] drm/i915: Trim struct_mutex usage for kms
URL : https://patchwork.freedesktop.org/series/25465/
State : success
== Summary ==
Series 25465v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25465/revisions/1/mb
On ke, 2017-06-07 at 17:30 +0800, Zhenyu Wang wrote:
> On 2017.06.05 14:55:41 +0800, Tina Zhang wrote:
> >
> > @@ -53,12 +53,18 @@ enum vgt_g2v_type {
> > VGT_G2V_MAX,
> > };
> >
> > +/*
> > + * VGT capabilities type
> > + */
> > +#define VGT_CAPS_FULL_PPGTTBIT(2)
> > +
>
> As I th
Actually transferring from shmemfs to the physically contiguous set of
pages should be wholly guarded by its obj->mm.lock!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 43 +++--
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git
== Series Details ==
Series: drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock more
appropriately
URL : https://patchwork.freedesktop.org/series/25469/
State : warning
== Summary ==
Series 25469v1 drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock
more appropriately
ht
Setting up the irq to signal the request completion takes a finite
amount of time, during which it is possible that the request already
completed. Check afterwards, just in case, so that we can respond
immediately.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Reviewed-by:
The important condition that we need to check after enabling the
interrupt for signaling is whether the request completed in the process
(and so we missed that interrupt). A large cost in enabling the
signaling (rather than waiters) is in waking up the auxiliary signaling
thread, but we only need t
Originally we would enable and disable the breadcrumb interrupt
immediately on demand. This was slow enough to have a large impact
(>30%) on tasks that hopped between engines. However, by using a shadow
to keep the irq alive for an extra interrupt (see commit 67b807a89230
("drm/i915: Delay disablin
Enabling the interrupt for the signaler takes a finite amount of time (a
few microseconds) during which it is possible for the request to
complete. Check afterwards and skip adding the request to the signal
rbtree if it complete.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Check signaled state after
enabling signaling
URL : https://patchwork.freedesktop.org/series/25470/
State : warning
== Summary ==
Series 25470v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25
On Wed, 2017-06-07 at 10:45 -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> RGB565 Pixel format planes can now be rotated at 90 and 270 degrees
>
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 11 ---
> 1 file changed, 4 insertions(+
Geminilake is now included in CI, making it part of the pre-merge
criteria. The support should be in good enough shape, so let's remove
the alpha_support flag.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drive
I would like to send this patch to the core-for-CI branch, in order to
verify the theory I exposed in fdo#101246.
This patch also hides a potentially serious bug in the sound/hda
driver, which may improve our chances of not being affected by
bugs there. It may actually also fix some of the incompl
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Check signaled state after
enabling signaling
URL : https://patchwork.freedesktop.org/series/25470/
State : success
== Summary ==
Series 25470v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25
== Series Details ==
Series: drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock more
appropriately
URL : https://patchwork.freedesktop.org/series/25469/
State : success
== Summary ==
Series 25469v1 drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock
more appropriately
ht
== Series Details ==
Series: drm/i915/glk: Remove the alpha_support flag
URL : https://patchwork.freedesktop.org/series/25471/
State : failure
== Summary ==
Series 25471v1 drm/i915/glk: Remove the alpha_support flag
https://patchwork.freedesktop.org/api/1.0/series/25471/revisions/1/mbox/
Test
On Sun, 04 Jun 2017, Madhav Chauhan wrote:
> As per BSEPC, if device ready bit is '0' in enable IO sequence
> then its a cold boot/reset scenario eg: S3/S4 resume. In these
> conditions we need to program certain registers and prepare port
> from the middle of DSI enable sequence otherwise feature
Do you plan to merge this patch? I would like to post my
__GFP_RETRY_MAYFAIL series sometime soon and would like to cover this
one as well.
On Mon 05-06-17 11:35:12, Chris Wilson wrote:
> I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It
> struggles with handling reclaim via
== Series Details ==
Series: NOTFORUPSTREAM sound/hda: add debug information in call_hp_automute
URL : https://patchwork.freedesktop.org/series/25472/
State : success
== Summary ==
Series 25472v1 NOTFORUPSTREAM sound/hda: add debug information in
call_hp_automute
https://patchwork.freedesktop
The tests listed in XFAIL_TESTS have moved to lib/tests quite a while
ago.
Signed-off-by: Petri Latvala
---
tests/Makefile.sources | 8
1 file changed, 8 deletions(-)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b3a680e..14ea5b6 100644
--- a/tests/Makefile.sources
The separation of testcases with and without subtests in the build
system was used in the past, but now both are handled the same
way. Merge them together and finally forget about the difference
between TESTS_progs and TESTS_progs_M.
Signed-off-by: Petri Latvala
---
tests/Makefile.am | 16
On Thu, Jun 08, 2017 at 12:59:23AM +, Navare, Manasi D wrote:
> Hi,
>
> I am executing the DP compliance test suite and the only test currently
> failing with the drm-tip + my patch
> (https://patchwork.freedesktop.org/series/25191/)
> Is the power management test (4.4.3) where it expects
On Thu, Jun 08, 2017 at 10:51:34AM +0100, Chris Wilson wrote:
> Reduce acquisition of struct_mutex to the critical regions that must
> hold it; for KMS, we need struct_mutex currently only for the purpose of
> pinning/unpinning the framebuffer's VMA into the global GTT. This allows
> us to avoid ta
Quoting Ville Syrjälä (2017-06-08 14:47:27)
> On Thu, Jun 08, 2017 at 10:51:34AM +0100, Chris Wilson wrote:
> > + ret = i915_gem_object_pin_pages(obj);
> > + if (ret)
> > + return ret;
> > +
> > + ret = mutex_lock_interruptible(&dev_priv->drm.struct_mutex);
> > + if (ret
On Thu, Jun 08, 2017 at 03:23:08PM +0300, Petri Latvala wrote:
> The tests listed in XFAIL_TESTS have moved to lib/tests quite a while
> ago.
>
> Signed-off-by: Petri Latvala
Reviewed-by: Arkadiusz Hiler
--
Cheers,
Arek
___
Intel-gfx mailing list
Int
Rodrigo Vivi writes:
> Coffee Lake inherit most of Kabylake production
> workardounds.
>
> Only difference identified so far is:
> - WaDisableLSQCROPERFforOCL is marked as SIWA_NEVER
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c| 2 +
On Thu, Jun 08, 2017 at 03:23:09PM +0300, Petri Latvala wrote:
> The separation of testcases with and without subtests in the build
> system was used in the past, but now both are handled the same
> way. Merge them together and finally forget about the difference
> between TESTS_progs and TESTS_pro
I would like to send this patch to the core-for-CI branch, in order to
verify the theory I exposed in fdo#101246.
This patch also hides a potentially serious bug in the sound/hda
driver, which may improve our chances of not being affected by
bugs there. It may actually also fix some of the incompl
On Wed, Jun 07, 2017 at 04:45:07PM +0300, Jani Nikula wrote:
> On Mon, 15 May 2017, Jani Nikula wrote:
> > The following commits have been marked as Cc: stable or fixing something
> > in v4.12-rc1 or earlier, but failed to cherry-pick to
> > drm-intel-fixes. Please see if they are worth backportin
Hi Dave, fixes all around for drm/i915, half stable, half for this merge
window.
There's a last minute build warning fix on top that I failed to notice
earlier, everything else was pushed earlier.
BR,
Jani.
The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f:
Linux 4
From: Ville Syrjälä
Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface
offset in the plane check hook for SKL+") we've already rotated the src
coordinates by 270 degrees by the time we check if a scaler is needed
or not, so we must not account for the rotation a second time.
Pr
From: Ville Syrjälä
skl_check_plane_surface() already rotates the clipped plane source
coordinates to match the scanout direction because that's the way
the GTT mapping is set up. Thus we no longer need to rotate the
coordinates in the watermark code.
For cursors we use the non-clipped coordinat
On Thu, 08 Jun 2017, Ville Syrjälä wrote:
> On Wed, Jun 07, 2017 at 04:45:07PM +0300, Jani Nikula wrote:
>> On Mon, 15 May 2017, Jani Nikula wrote:
>> > The following commits have been marked as Cc: stable or fixing something
>> > in v4.12-rc1 or earlier, but failed to cherry-pick to
>> > drm-int
On to, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> By spec there is no change on force wake registers
> for Cannonlake. Let's reuse gen9 one.
>
> v2: Adding missing case for the write part. (Tvrtko)
> v3: Rebase on recent tree.
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Rodrigo Vivi
Bspec: 1
We know default values for all params and we know which params are safe
to change. Mark params that were changed when dumping them in debugfs.
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 53 --
Currently our PARAMS_FOR_EACH macro contains only param type and name.
We use this macro to define struct members, but later on we initialize
this struct using handcrafted code, which leads in some cases to use
mismatched value vs. type. Let's extend our root macro with param
default value to keep
== Series Details ==
Series: NOTFORUPSTREAM sound/hda: add debug information in call_hp_automute
(rev2)
URL : https://patchwork.freedesktop.org/series/25472/
State : success
== Summary ==
Series 25472v2 NOTFORUPSTREAM sound/hda: add debug information in
call_hp_automute
https://patchwork.fre
Earlier RFC proposed to extend param macros with default values.
This series goes step further.
Michal Wajdeczko (3):
drm/i915: Rename i915.panel_use_ssc field to lvds_use_ssc
drm/i915: Extend PARAMS_FOR_EACH macro with more data
drm/i915/debugfs: Highlight modified i915 params
drivers/gp
This is the only field from i915_params struct which name does not match
the the name of the param that it is associated with. Lets fix that now
as this will unblock us with further improvements around params defs.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_p
Quoting Michal Wajdeczko (2017-06-08 16:07:34)
> We know default values for all params and we know which params are safe
> to change. Mark params that were changed when dumping them in debugfs.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> ---
> drivers/
== Series Details ==
Series: drm/i915: Misc improvements around module params
URL : https://patchwork.freedesktop.org/series/25482/
State : success
== Summary ==
Series 25482v1 drm/i915: Misc improvements around module params
https://patchwork.freedesktop.org/api/1.0/series/25482/revisions/1/m
On 06/08/2017 04:45 AM, Szwichtenberg, Radoslaw wrote:
On Wed, 2017-06-07 at 10:45 -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
RGB565 Pixel format planes can now be rotated at 90 and 270 degrees
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 1
We know default values for all params and we know which params are safe
to change. Mark params that were changed when dumping them in debugfs.
v2: simplify is_default calculation for strings (Chris)
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/dr
The whole Display engine for Coffee Lake is pretty much
identical to the Kabylake. For this reason let's reuse
all display related production workardounds here even though
CFL is not explicit listed at Display workarounds page at Spec.
v2: moved intel_pm.c chunck to this patch in order to address
So let's force it on the virtual detection.
Also it is still the only silicon for now on this PCH,
so WARN otherwise.
v2: Rebased on top of Cannonlake and added the missed
debug message as pointed by DK.
Cc: Dhinakaran Pandiyan
Signed-off-by: Rodrigo Vivi
Reviewed-by: Anusha Srivatsa
---
Coffee Lake is a Intel® Processor containing Intel® HD Graphics
following Kabylake.
It is Gen9 graphics based platform on top of CNP PCH.
Let's start by adding the platform definition based on previous
platforms but yet as preliminary_hw_support.
On following patches we will start adding PCI IDs
On Thu, Jun 08, 2017 at 05:47:23PM +0300, Jani Nikula wrote:
> On Thu, 08 Jun 2017, Ville Syrjälä wrote:
> > On Wed, Jun 07, 2017 at 04:45:07PM +0300, Jani Nikula wrote:
> >> On Mon, 15 May 2017, Jani Nikula wrote:
> >> > The following commits have been marked as Cc: stable or fixing something
>
On Thu, Jun 08, 2017 at 03:07:32PM +, Michal Wajdeczko wrote:
> This is the only field from i915_params struct which name does not match
> the the name of the param that it is associated with. Lets fix that now
> as this will unblock us with further improvements around params defs.
Maybe we sh
Quoting Michal Hocko (2017-06-08 13:26:22)
> Do you plan to merge this patch? I would like to post my
> __GFP_RETRY_MAYFAIL series sometime soon and would like to cover this
> one as well.
Yes, just a strict policy on getting some sucker to review it first.
-Chris
_
== Series Details ==
Series: series starting with [1/3] drm/i915/cfl: Introduce Coffee Lake platform
definition.
URL : https://patchwork.freedesktop.org/series/25486/
State : success
== Summary ==
Series 25486v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/2548
On Thu, Jun 08, 2017 at 07:03:55PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 08, 2017 at 03:07:32PM +, Michal Wajdeczko wrote:
> > This is the only field from i915_params struct which name does not match
> > the the name of the param that it is associated with. Lets fix that now
> > as this wil
On Thu, Jun 08, 2017 at 12:59:23AM +, Navare, Manasi D wrote:
> Hi,
>
> I am executing the DP compliance test suite and the only test
> currently failing with the drm-tip + my patch
> (https://patchwork.freedesktop.org/series/25191/)
> Is the power management test (4.4.3) where it expects
Rodrigo Vivi writes:
> WA to disable replay buffer destination buffer arbitration optimization.
>
> Same Wa on previous platforms has a different name:
> WaToEnableHwFixForPushConstHWBug
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 4
> 1 file changed,
patches merged to dinq.
Thanks for the reviews.
On Thu, Jun 8, 2017 at 8:50 AM, Rodrigo Vivi wrote:
> The whole Display engine for Coffee Lake is pretty much
> identical to the Kabylake. For this reason let's reuse
> all display related production workardounds here even though
> CFL is not explic
In the past the magic reg_a + (reg_b - reg_a) * port
was enough because every new register that was appearing
on new platforms was respecting the same gap.
However on more recent platforms we start seeing many
registers that doesn't respect the gap. So picking from
a list of registers seems to be
Rodrigo Vivi writes:
> WA forTDS handle reallocation getting dropped by SDE,
> which may result in PS attribute corruption.
>
> Disable enhanced SBE vertex caching in COMMON_SLICE_CHICKEN2 offset.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 4
> 1 file
On Thu, 2017-06-08 at 19:54 +0300, Mika Kuoppala wrote:
> Rodrigo Vivi writes:
>
> > WA to disable replay buffer destination buffer arbitration optimization.
> >
> > Same Wa on previous platforms has a different name:
> > WaToEnableHwFixForPushConstHWBug
> >
> > Signed-off-by: Rodrigo Vivi
> >
On Thu, Jun 08, 2017 at 04:36:25PM +, Navare, Manasi D wrote:
> On Thu, Jun 08, 2017 at 12:59:23AM +, Navare, Manasi D wrote:
> > Hi,
> >
> > I am executing the DP compliance test suite and the only test
> > currently failing with the drm-tip + my patch
> > (https://patchwork.freedeskt
== Series Details ==
Series: drm/i915: Make MMIO_PORT flexible.
URL : https://patchwork.freedesktop.org/series/25491/
State : failure
== Summary ==
Series 25491v1 drm/i915: Make MMIO_PORT flexible.
https://patchwork.freedesktop.org/api/1.0/series/25491/revisions/1/mbox/
Test gem_exec_suspend:
On Fri, Jun 02, 2017 at 11:55:32AM +0300, Jani Nikula wrote:
> On Fri, 02 Jun 2017, Jani Nikula wrote:
> > On Fri, 02 Jun 2017, Manasi Navare wrote:
> >> Validate the compliance test link parameters when the compliance
> >> test dpcd registers are read. Also validate them in compute_config
> >> b
Quoting Michal Wajdeczko (2017-06-08 17:22:40)
> On Thu, Jun 08, 2017 at 07:03:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 08, 2017 at 03:07:32PM +, Michal Wajdeczko wrote:
> > > This is the only field from i915_params struct which name does not match
> > > the the name of the param that i
From: Ville Syrjälä
Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.
On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program
From: Ville Syrjälä
While reviewing the COLOR_ENCODING/COLOR_RANGE props I decided that I
might as well implement them in i915. And here is the result.
With this the user can now select between BT.601 vs. BT.709, and
limited vs. full range on every platform where we currently have
YCbCr framebuf
From: Ville Syrjälä
Bring us forward from the stone age and switch our default YCbCr->RGB
conversion matrix to BT.709 from BT.601. I would expect most matrial
to be BT.709 these days.
Cc: Jyri Sarha
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/
From: Ville Syrjälä
Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).
On CHV pipe B we w
From: Ville Syrjälä
On GLK the plane CSC controls moved into the COLOR_CTL register.
Update the code to progam the YCbCr->RGB CSC mode correctly when
faced with an YCbCr framebuffer.
The spec is rather confusing as it calls the mode "YUV601 to RGB709".
I'm going to assume that just means it's go
From: Ville Syrjälä
Use the new "COLOR_ENCODING" plane property to implement the
XV_COLORSPACE port attribute for sprite Xv adaptors.
Cc: Jyri Sarha
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
src/sna/sna.h | 1 +
src/sna/sna_display.c | 148
From: Ville Syrjälä
Add support for the COLOR_ENCODING plane property which selects
the matrix coefficients used for the YCbCr->RGB conversion. Our
hardware can generally handle BT.601 and BT.709.
CHV pipe B sprites have a fully programmable matrix, so in theory
we could handle anything, but it
This function now takes the link rate and lane ocunt to be validated
as an argument so that this can be used for validating even the
compliance test link parameters.
Signed-off-by: Manasi Navare
Cc: Ville Syrjala
Cc: Jani Nikula
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 1
Validate the compliance test link parameters when the compliance
test dpcd registers are read. Also validate them in compute_config
before using them since the max values might have been reduced
due to link training fallback.
If either the link rate or lane count is invalid, we still bail
from usi
== Series Details ==
Series: sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors
URL : https://patchwork.freedesktop.org/series/25505/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/dp: Generalize
intel_dp_link_params function to accept arguments to be validated
URL : https://patchwork.freedesktop.org/series/25506/
State : success
== Summary ==
Series 25506v1 Series without cover letter
https://patchwork
On 2017-05-31 01:52, Daniel Vetter wrote:
> On Tue, May 30, 2017 at 02:17:04PM -0700, Stefan Agner wrote:
>> On 2017-05-26 00:00, Daniel Vetter wrote:
>> > On Thu, May 25, 2017 at 10:18 AM, Stefan Agner wrote:
>> >> On 2017-05-24 07:51, Daniel Vetter wrote:
>> >>> Again cleanup before irq disablin
From: "Leo (Sunpeng) Li"
Increasing max pipe count to 6 to support AMD GPU's.
Since some tests' behavior depends on this value, small changes are made
to remove this dependency:
* kms_ccs: Early abort if wanted_pipe is out-of-bounds.
* kms_concurrent: Check if pipe is within bounds first.
* kms
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of sunpeng...@amd.com
> Sent: Thursday, June 08, 2017 3:11 PM
> To: intel-gfx@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> Wentland, Harry
> Cc: Li, Sun peng
> Subject: [PATCH i-g-t] t
From: Ville Syrjälä
Implement the CNL display init/uninit sequence as outlined in Bspec.
Quite similar to SKL/BXT. The main complicaiton is probably the extra
procmon setup we must do based on the process/voltage information we
can read out from some register.
v2: s/skl_dbuf/gen9_dbuf/ to follo
From: Ville Syrjälä
Add support for reading out the cdclk frequency from the hardware on
CNL. Very similar to BXT, with a few new twists and turns:
* the PLL is now called CDCLK PLL, not DE PLL
* reference clock can be 24 MHz in addition to the 19.2 MHz BXT had
* the ratio now lives in the PLL en
Also in a way that reuse bdw+ for all next platforms.
Signed-off-by: Rodrigo Vivi
Reviewed-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
b/drivers/gpu/drm/i915/intel_
From: Anusha Srivatsa
This patch loads the DMC on CNL.The firmware version
is 1.04.
v2: (Rodrigo) Remove MODULE_FIRMWARE.
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
Signed-off-by: Rodrigo Vivi
Reviewed-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915
From: "Kahola, Mika"
DPLL's are defined in DPCLKA_CFGCR0 register (0x6C200). Let's use these
definitions when computing dpll's for ddi ports.
v2: (Rodrigo) Remove register that was defined in another patch with
fixed name and more bits.
Signed-off-by: Kahola, Mika
Signed-off-by: Rodrigo Vi
Although CNL follows PLL initialization more like Skylake
than Broxton we have a completely different initialization
sequence and registers used.
One big difference from SKL is that CDCLK PLL is now
exclusive (ADPLL) and for DDIs and MIPI we need to use
DFGPLLs 0, 1 or 2.
v2: Accept all Ander's s
All the low level cdclk bits are present, so let's add the required
hooks to reconfigure cdclk on the fly.
v2: Rebase due to cnl_sanitize_cdclk()
v3: Rebased by Rodrigo on top of Ville's cdclk rework.
v4: Rebase moving cnl_calc_cdclk up to follow same order
as previous platforms.
v2: Squash dr
1 - 100 of 137 matches
Mail list logo
