== Series Details ==
Series: drm: add asynchrounous plane update (rev3)
URL : https://patchwork.freedesktop.org/series/25814/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK
From: Gustavo Padovan
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)
v4: add drm_atomic_helper_async() commi
== Series Details ==
Series: drm: add asynchrounous plane update (rev2)
URL : https://patchwork.freedesktop.org/series/25814/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK
With this squashed in, the vc4 patch is:
Reviewed-by: Eric Anholt
Signed-off-by: Eric Anholt
---
Without this, the cursor never moved :)
drivers/gpu/drm/vc4/vc4_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
ind
Just a reminder.
Thanks.
On 06/09/2017 05:30 PM, Andrey Grodzovsky wrote:
Problem:
While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immidietly follwoing an atomic_commit.
After dumping the atomic state I relized that in this case there was
not even one C
On Fri, 2017-06-16 at 00:10 +0300, Jani Nikula wrote:
> On Thu, 15 Jun 2017, Rodrigo Vivi wrote:
> > On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
> > wrote:
> >> On Thu, 15 Jun 2017, Ander Conselvan De Oliveira
> >> wrote:
> >>> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
> Hi A
Patch merge to dinq.
I will try to get some logs here soon to sum to glk ones.
On Thu, 2017-06-15 at 14:01 -0700, Rodrigo Vivi wrote:
> On Thu, Jun 15, 2017 at 1:55 PM, Matt Roper wrote:
> > On Thu, Jun 15, 2017 at 01:52:02PM -0700, Rodrigo Vivi wrote:
> >> On Thu, Jun 15, 2017 at 1:13 PM, Jani
== Series Details ==
Series: drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH
URL : https://patchwork.freedesktop.org/series/25874/
State : warning
== Summary ==
Series 25874v1 drm/i915: Store 9 bits of PCI Device ID for platforms with a LP
PCH
https://patchwork.freedesktop
On 15/06/17 14:14, Chris Wilson wrote:
Quoting Michel Thierry (2017-06-15 21:18:17)
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
a
On Thu, 15 Jun 2017, Rodrigo Vivi wrote:
> What does IGT stand for nowadays? :)
IGT GPU Tools. :)
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/
Quoting Michel Thierry (2017-06-15 21:18:17)
> Users/tests relying on the total reset count will start seeing a smaller
> number since most of the hangs can be handled by engine reset.
> Note that if reset engine x, context a running on engine y will be unaware
> and unaffected.
>
> To start the d
On Thu, 15 Jun 2017, Rodrigo Vivi wrote:
> On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
> wrote:
>> On Thu, 15 Jun 2017, Ander Conselvan De Oliveira
>> wrote:
>>> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
Hi Ander,
On Wednesday 14 June 2017 05:17 PM, Ander Conse
On Thu, Jun 15, 2017 at 1:55 PM, Matt Roper wrote:
> On Thu, Jun 15, 2017 at 01:52:02PM -0700, Rodrigo Vivi wrote:
>> On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
>> wrote:
>> > On Thu, 15 Jun 2017, Ander Conselvan De Oliveira
>> > wrote:
>> >> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wr
What does IGT stand for nowadays? :)
On Thu, Jun 15, 2017 at 12:53 PM, Jani Nikula
wrote:
> On Mon, 12 Jun 2017, Paul Kocialkowski
> wrote:
>> Since IGT supports much more that testing for the Intel DRM driver, it
>> was renamed to IGT GPU Tools instead of Intel GPU Tools.
>>
>> This replaces
Although we use 9 bits of Device ID for identifying PCH, only 8 bits are
stored in dev_priv->pch_id. This makes HAS_PCH_CNP_LP() and
HAS_PCH_SPT_LP() incorrect. Fix this by storing all the 9 bits for the
platforms with LP PCH.
Also, use the extended 9 bits for detecting PCH_LPT_LP.
Cc: Rodrigo Vi
On Thu, Jun 15, 2017 at 01:52:02PM -0700, Rodrigo Vivi wrote:
> On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
> wrote:
> > On Thu, 15 Jun 2017, Ander Conselvan De Oliveira
> > wrote:
> >> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
> >>> Hi Ander,
> >>>
> >>>
> >>> On Wednesday 14 June
On Thu, 15 Jun 2017, Ville Syrjälä wrote:
> On Thu, Jun 15, 2017 at 03:53:18AM +, Anuar, Nuhairi wrote:
>> To be clear, I believe right now, GVT-g architecture on upstream still only
>> have one Virtualized DP monitor which will be on port B/D, but we have
>> patches (not yet upstream) that
Hi Dave,
Here's the final drm-misc-next request for 4.13, we'll switch over to
drm-misc-next-fixes for 4.13 with drm-misc-next now targetting 4.14. I'll send
out a separate email to -misc committers to ensure we're all on the same page.
The drm_panel_bridge change introduced a little bit of instab
On Thu, Jun 15, 2017 at 1:13 PM, Jani Nikula
wrote:
> On Thu, 15 Jun 2017, Ander Conselvan De Oliveira wrote:
>> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
>>> Hi Ander,
>>>
>>>
>>> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
>>> > On Tue, 2017-06-13 at 12:0
On Tue, 13 Jun 2017, Madhav Chauhan wrote:
> This patch divides glk_dsi_device_ready() function into
> two part. First part will program LP wake and MIPI DSI mode
> to MIPI_CTRL reg using newly defined function glk_dsi_enable_io().
> glk_dsi_enable_io() will be called from intel_dsi_pre_enable.
>
On Thu, 15 Jun 2017, Xiong Zhang wrote:
> In a IGD passthrough environment, the real ISA bridge may doesn't exist.
> then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is
> used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as
> LPT_H,then errors occur when i915
== Series Details ==
Series: Gen8+ engine-reset (rev13)
URL : https://patchwork.freedesktop.org/series/21868/
State : success
== Summary ==
Series 21868v13 Gen8+ engine-reset
https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/13/mbox/
Test kms_cursor_legacy:
Subgroup bas
On Thu, 15 Jun 2017 18:00:38 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > +struct vfio_dmabuf_mgr_plane_info {
> > > + __u64 start;
> > > + __u64 drm_format_mod;
> > > + __u32 drm_format;
> > > + __u32 width;
> > > + __u32 height;
> > > + __u32 stride;
> > > + __u32 size;
> > > + __u32 x_pos;
> >
On Tue, 13 Jun 2017, Paulo Zanoni wrote:
> Make sure all the macros are next to each other so it's easier to spot
> all the options available.
Please also move _MIPI_PORT and _MMIO_MIPI up. Btw they're another
variant...
BR,
Jani.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i
On Wed, 14 Jun 2017, Rodrigo Vivi wrote:
> On Wed, Jun 14, 2017 at 8:16 AM, Ville Syrjälä
> wrote:
>> On Tue, Jun 13, 2017 at 04:33:50PM -0300, Paulo Zanoni wrote:
>>> Do it just like we do with _PICK and _PICK3, so our code looks a
>>> little more uniform.
>>>
>>> Signed-off-by: Paulo Zanoni
>>
On Tue, 13 Jun 2017, Paulo Zanoni wrote:
> Instead of duplicating the macro everywhere, add a single definition
> for it and call it just like we do with the _PICK3 macros.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 15 ---
> 1 file changed, 8 insertion
On Tue, 13 Jun 2017, Paulo Zanoni wrote:
> All of the macros that call _PICK are named _X_3, so let's rename
> _PICK to _PICK3. The reason we're doing this is because we're going to
> have _PICK and _PICK2. Consider _PICK3 as the third variation of the
> PICK macros (well, actually it *is* the thi
From firmware v8.8, GuC provides the count of media engine resets
(watchdog timeout). This information is available in the GuC shared
context data struct, which resides in the first page of the default
(kernel) lrc context.
Since GuC handled engine resets are transparent for kernel and user,
provi
Check that we can reset specific engines, also check the fallback to
full reset if something didn't work.
v2: rebase.
v3: use RESET_ENGINE_IN_PROGRESS flag.
v4: use I915_RESET_ENGINE flag.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 150 +
intel_guc_reset sounds more like the microcontroller is the one performing
a reset, while in this case is the opposite. intel_reset_guc not only
makes it clearer, it follows the other intel_reset functions available.
v2: Print error message in English.
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursu
This feature is made available only from Gen8, for previous gen devices
driver uses legacy full gpu reset.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Tomas Elf
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_start. Request space of
So users (tests) can detect which type of reset (engine vs global) is
active.
Suggested-by: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
inde
Save the watchdog threshold (in us) as part of the engine state.
v2: Only do it for gen8+ (and prevent a missing-case warn).
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 12
2 files changed, 9 insertions(+),
From: Daniele Ceraolo Spurio
The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV
register the GuC can use to restore the provided whitelist when an
engine reset via GuC (which we still don't support) is triggered.
We're currently adding the mmio_base of the engine to the absolu
For watchdog / media reset, the firmware must know the address of the shared
data page (the first page of the default context).
This information should be in DWORD 9 of the GUC_CTL structure.
v2: Use guc_ggtt_offset (Chris).
Store the ggtt offset of the default ctx as we needed for
suspend/resume
We try to get the engines ready/idle before triggering the reset, but it
has been seen that sometimes the hw never acknowledges this.
If we miss the acknowledgment, carry on with the reset instead of
leaving the GPU in a wedged state.
The frequency of missed acknowledgment from hw is low, but it
A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they are expected to trigger reset; these counts are checked before
and after the test to ensure the same.
v2: Include reset engine count in i915_engin
This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicable (which fails at this point
because co
GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set of registers that we want GuC to save and
restore. This is not an issue in case of engine reset as driver initializes
most of
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for video engines is 6 us,
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.
To start the discussion, include just a total engine reset count. If it
Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.
A follow-up patch will provide this information in debugfs.
v2: s/engine_reset/rese
And store the active request so that we only search for it once.
v2: Check for request completion inside _prepare_engine, don't use
ECANCELED, remove unnecessary null checks (Chris).
v3: Capture active requests during reset_prepare and store it the
engine hangcheck obj.
v4: Rename commit, change
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang
In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_params.c | 6 +++---
dri
This patch adds per engine reset and recovery (TDR) support when GuC is
used to submit workloads to GPU.
In the case of i915 directly submission to ELSP, driver manages hang
detection, recovery and resubmission. With GuC submission these tasks
are shared between driver and GuC. i915 is still respo
This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported
from Gen8 onwards.
Hangchecker determines which engines are hung and invokes er
These patches add the reset-engine feature from Gen8. This is also
referred to as Timeout detection and recovery (TDR). This complements to
the full gpu reset feature available in i915 but it only allows to reset a
particular engine instead of all engines thus providing a light weight
engine reset
On Thu, 15 Jun 2017, Ander Conselvan De Oliveira wrote:
> On Thu, 2017-06-15 at 09:44 +0530, Mahesh Kumar wrote:
>> Hi Ander,
>>
>>
>> On Wednesday 14 June 2017 05:17 PM, Ander Conselvan De Oliveira wrote:
>> > On Tue, 2017-06-13 at 12:06 -0700, Rodrigo Vivi wrote:
>> > > On Tue, Jun 13, 2017 at
Hi Dave,
Here's this week's pull. Nothing worth noting beyond the onelines and summaries.
drm-misc-fixes-2017-06-15:
Driver Changes:
- dw-hdmi: Fix compilation error if REGMAP_MMIO not selected (Laurent)
- host1x: Fix incorrect return value (Christophe)
- tegra: Shore up idr API usage in tegra sta
On Mon, 12 Jun 2017, Paul Kocialkowski
wrote:
> Since IGT supports much more that testing for the Intel DRM driver, it
> was renamed to IGT GPU Tools instead of Intel GPU Tools.
>
> This replaces the remaining mentions of Intel GPU Tools in favor of
> IGT GPU tools.
There's still a bunch of "int
On Tue, 13 Jun 2017, Ville Syrjälä wrote:
> If there's lot of these and they get used a lot then I think the best
> option might be to add some kind of phy_port_offsets[] type of thing.
> Although it seems we'd need separate offsets for the group vs.
> individual lane access.
We have that for pip
On Wed, 14 Jun 2017, Michal Wajdeczko wrote:
> 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 e
On Thu, 15 Jun 2017, Lyude Paul wrote:
> This being said however, I think we should have some better functions
> for the chamelium for doing frame comparisons, mainly something that
> does fuzzy frame comparisons for stuff like VGA.
Something that takes into account dithering might be of use too.
4.11-stable review patch. If anyone has any objections, please let me know.
--
From: Kai Chen
commit 4c4c565513cca1c53a12956640b5915727431631 upstream.
The decoupled MMIO feature doesn't work as intended by HW team. Enabling
it with forcewake will only make debugging efforts m
4.11-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
This is the minimal backport for stable of the upstream commit:
commit dd19674bacba227ae5d3ce680cbc5668198894dc
Author: Chris Wilson
Date: Wed Feb 15 08:43:46 2017 +
== Series Details ==
Series: drm/i915: Actually attach the tv_format property to the SDVO connector
URL : https://patchwork.freedesktop.org/series/25860/
State : warning
== Summary ==
Series 25860v1 drm/i915: Actually attach the tv_format property to the SDVO
connector
https://patchwork.freed
== Series Details ==
Series: drm/i915: Make intel_digital_port_connected() work for any port
URL : https://patchwork.freedesktop.org/series/25859/
State : success
== Summary ==
Series 25859v1 drm/i915: Make intel_digital_port_connected() work for any port
https://patchwork.freedesktop.org/api/
On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
> On Thu, Jun 15, 2017 at 9:30 AM, Imre Deak wrote:
> > Yes, probably because i915 runtime PM as whole is disabled without DMC,
> > so we won't turn off display side power wells either; but D3 still won't
> > make a difference.
> >
> >
JFYI: Hardcoded CRCs are fine I'm pretty sure, but I might be wrong. As
well, put the chamelium in a metal box. The way the IO board is hooked
up is not really the way something running DP should be hooked up, so
it's very susceptible to electromagnetic interference. This will
usually cause CRC mis
Reviewed-by: Rodrigo Vivi
On Thu, Jun 15, 2017 at 10:23 AM, wrote:
> From: Ville Syrjälä
>
> Attach the tv_format property to the SDVO connector instead of passing
> a '0' in place of the pointer to the property. This got broken when
> the SDVO connector properties were converted to atomic.
>
From: Ville Syrjälä
Attach the tv_format property to the SDVO connector instead of passing
a '0' in place of the pointer to the property. This got broken when
the SDVO connector properties were converted to atomic.
We can thank sparse for catching this:
drivers/gpu/drm/i915/intel_sdvo.c:2742:75:
On Thu, Jun 15, 2017 at 9:30 AM, Imre Deak wrote:
> Yes, probably because i915 runtime PM as whole is disabled without DMC,
> so we won't turn off display side power wells either; but D3 still won't
> make a difference.
>
> The problem with not having DMC is that with that you'll prevent system
>
From: Ville Syrjälä
Add the missing port A handling to intel_digital_port_connected()
and also separate SPT from the CPT/LPT code a bit.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 83 ++---
1 file changed, 70 insert
Yes, we should check for features, not for some standard version that
implements some/all of those features. But not convinced we need any
featur flags for the other things you listed. Aren't we already doing
all those things anyway?
Yep, I realized you will come back with this point, while typi
On Thu, Jun 15, 2017 at 10:18:40PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/15/2017 9:42 PM, Ville Syrjälä wrote:
> > On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 6/15/2017 8:13 PM, Ville Syrjälä wrote
Op 15-06-17 om 10:25 schreef Chris Wilson:
> 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_mut
Regards
Shashank
On 6/15/2017 9:42 PM, Ville Syrjälä wrote:
On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR4
Op 15-06-17 om 10:25 schreef Chris Wilson:
> 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 th
Yes, probably because i915 runtime PM as whole is disabled without DMC,
so we won't turn off display side power wells either; but D3 still won't
make a difference.
The problem with not having DMC is that with that you'll prevent system
level power saving that is deeper package C states.
--Imre
O
On ChromeOS I've tested a couple hundred thousand iterations, during their
Power Load test (Google's battery claim test) an avg of 400 mW is saved when
RPM is turned on with DMC missing vs both turned off, So i think D3 is
definitely relevant even without DMC.
___
On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> >> CEA-861-F adds two
Quoting kbuild test robot (2017-06-15 16:23:12)
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check
> before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive
> or usb_free_urb is not needed. Maybe consider reorganizing relevant code to
> avoid passing
Hi,
> > +struct vfio_dmabuf_mgr_plane_info {
> > + __u64 start;
> > + __u64 drm_format_mod;
> > + __u32 drm_format;
> > + __u32 width;
> > + __u32 height;
> > + __u32 stride;
> > + __u32 size;
> > + __u32 x_pos;
> > + __u32 y_pos;
> > + __u32 padding;
> > +};
> > +
>
> This
If your username on fd.o differs from your local username, you'll run
into issues while setting up dim.
Let's use regexp to filter remotes so it doesn't fail.
Signed-off-by: Lionel Landwerlin
---
dim | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/dim b/dim
index
Regards
Shashank
On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 o
drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check before
freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or
usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid
passing NULL values.
NULL check before some freeing functions
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: 8c45cec48e5871f93e56650f7e476d4ea7174a0e
commit: d55495b4dcce2efb4656edfe211eb0bfb27c3387 [2/3] drm/i915: Use
vma->exec_entry as our double-entry placeholder
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/
Hi Dave, a GVT fix and a couple of rotation related fixes.
BR,
Jani.
The following changes since commit ef6c4d75e35345f8f362d6754bcd9a28292a897c:
drm/i915: fix warning for unused variable (2017-06-08 17:09:44 +0300)
are available in the git repository at:
git://anongit.freedesktop.org/git
On 6/15/2017 1:30 PM, Xiaoguang Chen wrote:
> Here we defined a new ioctl to create a fd for a vfio device based on
> the input type. Now only one type is supported that is a dma-buf
> management fd.
> Two ioctls are defined for the dma-buf management fd: query the vfio
> vgpu's plane information
On Thu, Jun 15, 2017 at 07:01:38PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/15/2017 6:59 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> >> CEA-861-F specs defines new video modes to be used with
> >> HDMI 2.0 EDIDs. The VIC
On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> to provide information about sink's YCBCR420 output capabilities.
>
> These blocks are:
>
> - YCBCR420vd
On 15/06/2017 13:38, Chris Wilson wrote:
For ease of use (i.e. avoiding a few checks and function calls), store
the object's cache coherency next to the cache is dirty bit.
Signed-off-by: Chris Wilson
Cc: Dongwon Kim
Cc: Matt Roper
Tested-by: Dongwon Kim
---
drivers/gpu/drm/i915/i915_gem.
On 15/06/2017 13:38, Chris Wilson wrote:
Currently, we only mark the CPU cache as dirty if we skip a clflush.
This leads to some confusion where we have to ask if the object is in
the write domain or missed a clflush. If we always mark the cache as
dirty, this becomes a much simply question to a
On 2017-06-13 08:55 AM, Arkadiusz Hiler wrote:
On Tue, Jun 13, 2017 at 03:41:14PM +0300, Arkadiusz Hiler wrote:
On Tue, Jun 13, 2017 at 10:35:34AM +0300, Jani Nikula wrote:
On Mon, 12 Jun 2017, Harry Wentland wrote:
The email was sent but might be stuck in the moderation queue since Leo
(Su
Hi,
So far, there are two ways of testing for pixel-perfect frames using the
Chamelium that are in IGT. The first one grabs a full frame from the Chamelium
and compares it pixel-to-pixel with the cairo reference, which works well for
DP/HDMI.
For VGA, this is probably not the case (because the li
Reviewed-by: Shashank Sharma
Regards
Shashank
On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:
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
ACK: Shashank Sharma
Regards
Shashank
On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:
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 Sar
Regards
Shashank
On 6/15/2017 6:59 PM, Ville Syrjälä wrote:
On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 mo
On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA
Regards
Shashank
On 6/15/2017 6:12 PM, Ville Syrjälä wrote:
On Thu, Jun 15, 2017 at 05:57:21PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
On GLK the plane CSC controls moved into the COLOR_CTL register.
Upda
Regards
Shashank
On 6/9/2017 2:03 AM, ville.syrj...@linux.intel.com wrote:
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
On Thu, Jun 01, 2017 at 05:36:12PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> This series eliminates the problematic load detect abuse for the
> pipe A quirk. My main motivations were to isolate these quirks
> more from atomic to avoid regressions, and to save a bit of
On Wed, Jun 14, 2017 at 02:03:05PM +0100, Tvrtko Ursulin wrote:
>
> On 13/06/2017 14:47, Colin King wrote:
> > From: Colin Ian King
> >
> > The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global
> > scope, so make it static.
> >
> > Cleans up sparse warning:
> > "symbol 'cnl_dd
On Wed, Jun 14, 2017 at 01:18:42PM -0700, Puthikorn Voravootivat wrote:
> I tested this on actual system and it is working fine.
Thank you everyone. Patch pushed to dinq.
>
> On Tue, Jun 13, 2017 at 1:03 PM, Dhinakaran Pandiyan <
> dhinakaran.pandi...@intel.com> wrote:
>
> > Maarten and Ville n
We need to keep track of the last location we ask the hw to read up to
(RING_TAIL) separately from our last write location into the ring, so
that in the event of a GPU reset we do not tell the HW to proceed into
a partially written request (which can happen if that request is waiting
for an externa
On Wed, May 24, 2017 at 04:52:08PM +0200, Daniel Vetter wrote:
> Again, doesn't seem to serve a purpose.
>
> Cc: Thierry Reding
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/tegra/drm.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
I'm assuming that you want to apply the
== Series Details ==
Series: series starting with [passive,aggressive,RESEND,1/2] drm/i915: Mark CPU
cache as dirty on every transition for CPU writes
URL : https://patchwork.freedesktop.org/series/25841/
State : success
== Summary ==
Series 25841v1 Series without cover letter
https://patchwo
On Wed, May 24, 2017 at 04:51:45PM +0200, Daniel Vetter wrote:
[...]
> -Resources allocated by :c:func:`drm_vblank_init()` must be freed
> -with a call to :c:func:`drm_vblank_cleanup()` in the driver unload
> -operation handler.
I think perhaps this is the reason why this was cargo-culted. It's
co
1 - 100 of 140 matches
Mail list logo
