Regards
Shashank
On 7/15/2017 12:32 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote:
Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format,
which is currently supported on HDMI 2.0 sources/sinks. Due to lower
chroma sub-sampling rate, YCB
Regards
Shashank
On 7/15/2017 12:06 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correcti
Regards
Shashank
On 7/15/2017 12:03 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in
Regards
Shahank
On 7/15/2017 12:00 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycb
Regards
Shashank
On 7/15/2017 12:00 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 outp
The current code uses two different enum types for PCH transcoders and
performs implicit conversions between the two types. This is error prone
and causes clang to raise warnings like this:
drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
from enumeration type 'enum pipe' to
El Fri, Jul 14, 2017 at 03:43:35PM -0700 Grant Grundler ha dit:
> On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote:
> > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler
> > wrote:
> >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
> >> wrote:
> >>> On Thu, 13 Jul 2017, Stéphane Marchesin
>
FYI: The latest version of the CCS modifier patches for mesa are now
reviewed:
https://patchwork.freedesktop.org/series/27213/
I'll be landing the prep-work patches soon. The final couple of patches
are just waiting on the I915_FORMAT_MOD_Y_TILED_CCS in drm_fourcc.h to land
in the kernel.
On S
== Series Details ==
Series: series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
URL : https://patchwork.freedesktop.org/series/27337/
State : success
== Summary ==
Series 27337v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27337/revisions/1/m
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the clea
The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().
In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
again, which means the plane->fb pointer won't change, hence can't
leak.
- Drivers using drm_atomi
On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote:
> On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote:
>> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
>> wrote:
>>> On Thu, 13 Jul 2017, Stéphane Marchesin
>>> wrote:
So, if you think this is wrong, can you fix this warning in a way
On Fri, Jul 14, 2017 at 10:17:52PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-07-14 22:03:05)
> > On Fri, Jul 14, 2017 at 09:32:13PM +0100, Chris Wilson wrote:
> > > Quoting Patchwork (2017-07-14 21:18:04)
> > > > == Series Details ==
> > > >
> > > > Series: series starting with [1/3
On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote:
> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
> wrote:
>> On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
>>> So, if you think this is wrong, can you fix this warning in a way that
>>> you'd like?
>>
>> As I replied previously [1], with more
On Fri, Jul 14, 2017 at 11:03 PM, Pandiyan, Dhinakaran
wrote:
> On Fri, 2017-07-14 at 19:14 +0200, Daniel Vetter wrote:
>> I can live without those logs, and it avoids a kernel
>> recompile&reboot.
>>
>
> Sounds reasonable, having hda dynamic debug does not feel like a
> necessity for module_reloa
Quoting Daniel Vetter (2017-07-14 22:03:05)
> On Fri, Jul 14, 2017 at 09:32:13PM +0100, Chris Wilson wrote:
> > Quoting Patchwork (2017-07-14 21:18:04)
> > > == Series Details ==
> > >
> > > Series: series starting with [1/3] drm/atomic-helper: Fix leak in
> > > disable_all
> > > URL : https://
On Fri, 2017-07-14 at 19:14 +0200, Daniel Vetter wrote:
> I can live without those logs, and it avoids a kernel
> recompile&reboot.
>
Sounds reasonable, having hda dynamic debug does not feel like a
necessity for module_reload testing.
Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: Danie
On Fri, Jul 14, 2017 at 09:32:13PM +0100, Chris Wilson wrote:
> Quoting Patchwork (2017-07-14 21:18:04)
> > == Series Details ==
> >
> > Series: series starting with [1/3] drm/atomic-helper: Fix leak in
> > disable_all
> > URL : https://patchwork.freedesktop.org/series/27327/
> > State : failur
On Fri, Jul 14, 2017 at 04:38:22PM -0300, Paulo Zanoni wrote:
> I wrote this code an year and a half ago and I couldn't exactly
> remember the main differences of these two structures when reviewing a
> new FBC patch. Add some comments to help explain what's the purpose of
> each struct.
>
> For t
On 28/06/17 01:54, Tvrtko Ursulin wrote:
On 14/06/2017 00:19, Kelvin Gardiner wrote:
It is sometimes useful for debug purposes to be able to set GuC timeout
lengths.
This patch adds GuC load and request timeouts values to Kconfig.debug,
which can then be optionally set as required for debug
I hate to spam, but I'm still getting half a gig of errors in my logs
per day, to the point that I need to prune them aggressively, and
obviously Xorg with the new kernel and new intel driver, is not working
right.
If this is not the right place to get support, where is it?
If it's the place bari
On Fri, Jul 14, 2017 at 07:34:15PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 14, 2017 at 05:24:03PM +0100, Chris Wilson wrote:
> > Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27)
> > > From: Ville Syrjälä
> > >
> > > Turns out that just writing CURPOS isn't sufficient to move the curs
== Series Details ==
Series: drm/i915/fbc: add comments to the FBC auxiliary structs
URL : https://patchwork.freedesktop.org/series/27330/
State : success
== Summary ==
Series 27330v1 drm/i915/fbc: add comments to the FBC auxiliary structs
https://patchwork.freedesktop.org/api/1.0/series/27330
Quoting Patchwork (2017-07-14 21:18:04)
> == Series Details ==
>
> Series: series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
> URL : https://patchwork.freedesktop.org/series/27327/
> State : failure
>
> == Summary ==
>
> Series 27327v1 Series without cover letter
> https://
== Series Details ==
Series: series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
URL : https://patchwork.freedesktop.org/series/27327/
State : failure
== Summary ==
Series 27327v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27327/revisions/1/m
I wrote this code an year and a half ago and I couldn't exactly
remember the main differences of these two structures when reviewing a
new FBC patch. Add some comments to help explain what's the purpose of
each struct.
For the record, the original commits are:
b183b3f14395 ("drm/i915/fbc: introdu
Quoting Daniel Vetter (2017-07-14 20:14:39)
> We first need to make sure no one else can get at us anymore,
> before we can proceed to tear down all the datastructures.
>
> Just a small step towards eventually the perfect unload code ...
>
> Signed-off-by: Daniel Vetter
Just some concern from t
Em Sex, 2017-03-24 às 17:12 +0530, Praveen Paneri escreveu:
> When FBC is enabled for linear, legacy Y-tiled and Yf-tiled
> surfaces on gen9, the cfb stride must be programmed by SW as
>
> cfb_stride = ceiling[(at least plane width in pixels)/
> (32 * compression limit factor)]
Quoting Daniel Vetter (2017-07-14 20:14:38)
Second nit:
> +void intel_fbdev_fini(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbdev *ifbdev = dev_priv->fbdev;
> +
> + if (!ifbdev)
> + return;
> +
> intel_fbdev_destroy(ifbdev);
> dev_priv->fbdev
Quoting Daniel Vetter (2017-07-14 20:14:38)
> First thing we need to do is unregister the fbdev instance, but we
> can't just go ahead and kfree it. That must wait until the hotplug and
> polling work are stopped, since they can race with the with the
> teardown. That means we need to split up the
Quoting Daniel Vetter (2017-07-14 20:14:37)
> The legacy plane->fb pointer is refcounted by calling
> drm_atomic_clean_old_fb().
>
> In practice this isn't a real problem because:
> - The caller in the i915 gpu reset code restores the original state
> again, which means the plane->fb pointer won
2017-07-11 Chris Wilson :
> Quoting Chris Wilson (2017-02-14 12:40:01)
> > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> > memory (8802538683d0)
> > [ 236.828642]
> > 42001e7f0008
> > [ 236.839543] i i i i u
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 de
The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().
In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
again, which means the plane->fb pointer won't change, hence can't
leak.
- Drivers using drm_atomi
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the clea
On Fri, Jul 14, 2017 at 11:41:49AM -0700, Ben Widawsky wrote:
> On 17-06-29 22:49:44, Ville Syrjälä wrote:
>
> [snip]
>
> >
> >... but here it's ALIGN(formats_offset+formats_size). I think we should
> >be aligning the same thing in both cases, or we add a BUILD_BUG_ON to
> >make sure the header s
On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote:
> Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format,
> which is currently supported on HDMI 2.0 sources/sinks. Due to lower
> chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half
> the pixel clock
On 17-06-29 22:49:44, Ville Syrjälä wrote:
[snip]
... but here it's ALIGN(formats_offset+formats_size). I think we should
be aligning the same thing in both cases, or we add a BUILD_BUG_ON to
make sure the header size always stays a multiple of 8 bytes.
That's mainly because the design of the
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
> To support ycbcr output, we need a pipe CSC block to do
> RGB->YCBCR conversion.
>
> Current Intel platforms have only one pipe CSC unit, so
> we can either do color correction using it, or we can perform
> RGB->YCBCR conversion.
>
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
>
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for ycbcr
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
> This patch checks encoder level support for YCBCR420 outputs.
> The logic goes as simple as this:
> If the input mode is YCBCR420-only mode: prepare HDMI for
> YCBCR420 output, else continue with RGB output mode.
>
> It checks if t
On 14 July 2017 at 18:57, Lionel Landwerlin
wrote:
> On 14/07/17 18:09, Matthew Auld wrote:
>>
>> On 13 July 2017 at 12:16, Lionel Landwerlin
>> wrote:
>>>
>>> v2: Add tests regarding removing configs (Matthew)
>>> Add tests regarding adding/removing configs without permissions
>>> (Mat
oh! I believe you had warned me about this beforehand but I forgot... sorry
Reviewed-by: Rodrigo Vivi
On Fri, Jul 14, 2017 at 10:52 AM, Paulo Zanoni wrote:
> * Don't define it twice.
> * Define MSBs first, like the rest of i915_reg.h.
> * Add CNL_ prefix to the bit that arrived in CNL.
>
>
== Series Details ==
Series: drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions
URL : https://patchwork.freedesktop.org/series/27321/
State : success
== Summary ==
Series 27321v1 drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions
https://patchwork.freedesktop.org/api/1.0/series/27321/revis
On 14/07/17 18:09, Matthew Auld wrote:
On 13 July 2017 at 12:16, Lionel Landwerlin
wrote:
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
Signed-off-by: Lionel Landwerlin
---
tests/perf.c | 201 ++
On 07/12/2017 04:47 PM, Rodrigo Vivi wrote:
Version 1.05 is now available for CNL.
According to its release notes the only difference is:
- Change from aux A pwrreq always turn on during restore,
to saving and restoring aux A pwrreq.
Reviewed-by: Clinton Taylor
-Clint
Anusha Sriv
* Don't define it twice.
* Define MSBs first, like the rest of i915_reg.h.
* Add CNL_ prefix to the bit that arrived in CNL.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 8 +++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
Hi,
I'm a bit late to the party, but as I already mentioned at [1] the CNL
render ctx size is smaller than the gen9 one according to the specs. The
ctx format in the specs contains 16752 dwords, i.e. 17 pages, to which
we need to add 1 page for the PPHWSP, so 18 pages total. If we re-use
the
On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
wrote:
> On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
>> So, if you think this is wrong, can you fix this warning in a way that
>> you'd like?
>
> As I replied previously [1], with more background, fixing the warnings
> properly, in a way that actual
I can live without those logs, and it avoids a kernel
recompile&reboot.
Signed-off-by: Daniel Vetter
---
tests/drv_module_reload.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
index db2ad2cf0f43..be831851dec2 100644
On 13 July 2017 at 12:16, Lionel Landwerlin
wrote:
> v2: Add tests regarding removing configs (Matthew)
> Add tests regarding adding/removing configs without permissions
> (Matthew)
>
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 201
> +++
== Series Details ==
Series: PSR clean-up, new vfuncs and more use of HW tracking. (rev4)
URL : https://patchwork.freedesktop.org/series/27194/
State : success
== Summary ==
Series 27194v4 PSR clean-up, new vfuncs and more use of HW tracking.
https://patchwork.freedesktop.org/api/1.0/series/27
Tested by: Elio Martinez
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Manasi Navare
Sent: Friday, July 7, 2017 6:13 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [RESEND v2 2/2] drm/i915/dp: Validate the compliance test
li
Tested by: Elio Martinez
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Patchwork
Sent: Friday, July 7, 2017 6:25 PM
To: nav...@emeril.freedesktop.org; Navare, Manasi D
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] ✓ Fi.CI.BAT:
Let's move the activation calls together after enable is done.
No real functional change should be expected here. Just an attempt
to get it clear when we are really activating PSR after enabling it.
v2: Add braces on if/else because commit message there is too long
as suggested by Jani.
Cc:
== Series Details ==
Series: PSR clean-up, new vfuncs and more use of HW tracking. (rev3)
URL : https://patchwork.freedesktop.org/series/27194/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/uts
This sequence is part of enable source anyways, but they
only need to be executed once and not on every activation,
So let's re-create hsw_enable_source.
v2: Avoid changing order here to avoid changing behaviour
as suggested by Jani.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
No functional change is expected here since at this point
PSR is not allowed to go to any active state. In other
words, not really enabled.
However let's do in a separated patch so it gets clear
on what is change and specially it can helps on bisect
case if we figure something has caused changes i
On Fri, Jul 14, 2017 at 05:24:03PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27)
> > From: Ville Syrjälä
> >
> > Turns out that just writing CURPOS isn't sufficient to move the cursor
> > on some platforms. My 830 works just fine, but eg. 945 and PNV don
Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27)
> From: Ville Syrjälä
>
> Turns out that just writing CURPOS isn't sufficient to move the cursor
> on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
> On those platforms we need to arm even the CURPOS update with a
>
On 14 July 2017 at 16:15, Lionel Landwerlin
wrote:
> We were reserving fewer dwords in the ring than necessary. Indeed
> we're always writing all registers once, so discard the actual number
> of registers given by the user and just program the whitelisted ones
> once.
>
> Reported-by: Matthew Aul
== Series Details ==
Series: drm/i915: Fix cursor updates on some platforms
URL : https://patchwork.freedesktop.org/series/27314/
State : success
== Summary ==
Series 27314v1 drm/i915: Fix cursor updates on some platforms
https://patchwork.freedesktop.org/api/1.0/series/27314/revisions/1/mbox/
On Fri, Jul 14, 2017 at 12:46:08PM +0300, Jani Nikula wrote:
> On Tue, 11 Jul 2017, Jim Bride wrote:
> > According to the eDP spec, when the count field in TEST_SINK_MISC
> > increments then the six bytes of sink CRC information in the DPCD
> > should be valid. Unfortunately, this doesn't seem to
Reviewed-by: Lionel Landwerlin
On 14/07/17 16:12, Imre Deak wrote:
1acfc104cdf8 missed to convert this one caller to be lockless. The side
effect of that was that the error check in lookup_context() became
incorrect. Convert now this caller too.
Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only c
From: Ville Syrjälä
Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.
Even worse, a write to any of the cursor register apart
== Series Details ==
Series: Add support for loadable OA configs
URL : https://patchwork.freedesktop.org/series/27310/
State : success
== Summary ==
Series 27310v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27310/revisions/1/mbox/
Test gem_exec_suspen
Quoting Patchwork (2017-07-14 16:28:47)
> e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s
> UTC integration manifest
> 090da8a drm/i915: Fix user ptr check size in eb_relocate_vma()
> 84be7c7 drm/i915: Fix error checking/locking in perf/lookup_context()
And because pw
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix error checking/locking in
perf/lookup_context()
URL : https://patchwork.freedesktop.org/series/27309/
State : success
== Summary ==
Series 27309v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
From: Brian Starkey
Separate out the CRC code for better compartmentalisation. Should ease
the addition of more/different CRC sources in the future.
Signed-off-by: Brian Starkey
---
lib/Makefile.sources | 2 +
lib/igt_chamelium.h | 1 +
lib/igt_crc.c
We're trying to introduce support for writeback connectors, a way to
expose in DRM the hardware functionality from display engines that
allows to write back into memory the result of the DE's composition
of supported planes.
Generic DRM support is available here [1] and will be merged once
this pa
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 6 +-
lib/igt_kms.h | 7 +
tests/Makefile.s
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 90 +--
lib/igt_kms.h | 3 ++
2 files changed, 59 insertions(+
From: Brian Starkey
Add support in igt_kms for Writeback connectors, with the ability to
attach framebuffers and retrieve fences.
Signed-off-by: Brian Starkey
---
lib/igt_aux.c | 1 +
lib/igt_kms.c | 76 ++-
lib/igt_kms.h | 16 ++
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 123 ++
1 file changed,
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 63 +++
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
From: Matthew Auld
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
av
Quoting Imre Deak (2017-07-14 16:12:42)
> Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
>
> Fixes: 2889caa92321 - ("drm/i915: Eliminate lots of iterations over the
> execobjects array")
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by: Imre Deak
/o\ Oops.
Reviewed-by: Chris Wilson
-Chri
Hi again,
Here is a v4 that uncovered an issue in the existing code.
Thanks to Matthew for his in-depth review!
Cheers,
Lionel Landwerlin (2):
drm/i915/perf: fix flex eu registers programming
drm/i915/perf: prune OA configs
Matthew Auld (1):
drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.
Reported-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Cc: # v4.12+
---
drivers
1acfc104cdf8 missed to convert this one caller to be lockless. The side
effect of that was that the error check in lookup_context() became
incorrect. Convert now this caller too.
Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only context lookups")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by:
Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
Fixes: 2889caa92321 - ("drm/i915: Eliminate lots of iterations over the
execobjects array")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Quoting Oscar Mateo (2017-07-14 15:52:59)
>
>
>
> On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:
> > On Wed, May 3, 2017 at 9:31 AM, Chris Wilson
> > wrote:
> >> On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote:
> >>> On 05/03/2017 08:52 AM, Mika Kuoppala wrote:
> >>>
> >>> Oscar
On Tue, Jul 11, 2017 at 04:33:14PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_
On Tue, Jul 11, 2017 at 04:33:13PM +0200, Maarten Lankhorst wrote:
> Now that all drivers check the return value, convert swap_state to
> __must_check. This is done separately to force build warnings if we
> missed a driver.
>
> Signed-off-by: Maarten Lankhorst
Maybe squash in with the next comm
On Tue, Jul 11, 2017 at 04:33:12PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> VC4 has its own nonblocking modeset tracking through the vc4->async_m
On Tue, Jul 11, 2017 at 04:33:10PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Thierry Reding
> Cc: Jonatha
On Tue, Jul 11, 2017 at 04:33:09PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> MSM has its own busy tracking, which means the swap_state call can be
On Tue, Jul 11, 2017 at 04:33:02PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state could previously never fail, in order to still
> continue it would set a limit of 10s on waiting for previous updates to
> complete,
> then it moved forward. This can be very bad when ignoring previou
On Fri, Jul 14, 2017 at 04:30:30PM +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> > We want to change swap_state to wait indefinitely, but to do this
> > swap_state should wait interruptibly. This requires propagating
> > the error to each driver.
On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:
On Wed, May 3, 2017 at 9:31 AM, Chris Wilson wrote:
On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote:
On 05/03/2017 08:52 AM, Mika Kuoppala wrote:
Oscar Mateo [1] writes:
On 05/02/2017 09:17 AM, Mika Kuoppala wrote:
Chris
On 14/07/17 13:20, Matthew Auld wrote:
On 07/14, Lionel Landwerlin wrote:
In the following commit we'll introduce loadable userspace
configs. This change reworks how configurations are handled in the
perf driver and retains only the test configurations in kernel space.
We now store the test con
On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kerne
On Tue, Jul 11, 2017 at 04:33:03PM +0200, Maarten Lankhorst wrote:
> Make it more clear that post commit return ret is really return 0,
>
> and add a missing drm_atomic_helper_cleanup_planes when
> drm_atomic_helper_wait_for_fences fails.
>
> Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition
Em Sex, 2017-07-14 às 19:25 +0530, Praveen Paneri escreveu:
> Hi Paulo,
>
> On Thursday 13 July 2017 02:31 AM, Paulo Zanoni wrote:
> > Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
> > > Now that we have support for Y-tiled buffers, add another
> > > iteration of tests for Y-tiled bu
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE - C
On Friday 14 July 2017 03:03 AM, Paulo Zanoni wrote:
Em Sex, 2017-06-09 às 15:48 +0530, Praveen Paneri escreveu:
This patch adds Y-tiling support for igt_draw_rect function.
v2: Use helper function to get tile sizes (Ville)
v3: Moved igt_get_fb_tile_size() out of the for loop
for better per
On Friday 14 July 2017 01:49 AM, Paulo Zanoni wrote:
Em Qua, 2017-07-12 às 13:45 +0530, Praveen Paneri escreveu:
Hi Paulo,
On Wednesday 12 July 2017 12:33 AM, Paulo Zanoni wrote:
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
From: Paulo Zanoni
This is the program that's supp
1 - 100 of 138 matches
Mail list logo
