On Tue, Jun 20, 2017 at 05:46:03PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Tue, 2017-06-20 at 11:03 +0200, Daniel Vetter wrote:
> > On Mon, Jun 05, 2017 at 02:56:04PM -0700, Puthikorn Voravootivat wrote:
> > > This patch set contain 3 patches which are already reviewed by DK.
> > > Another
Hi,
> We don't support cursor for console vnc. Ideally console vnc should
> be
> used by admin for configuration or during maintenance, which refresh
> primary surface at low refresh rate, 10 fps.
But you surely want a mouse pointer for the admin?
You render it directly to the primary surface t
On 2017.06.20 21:12:19 +0800, Tina Zhang wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 4ff854e..d777405 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -141,14 +141,20 @@ int intel_sanit
Hi,
> We already have VFIO_DEVICE_GET_INFO which returns:
>
> struct vfio_device_info {
> __u32 argsz;
> __u32 flags;
> #define VFIO_DEVICE_FLAGS_RESET (1 << 0)/* Device supports
> reset */
> #define VFIO_DEVICE_FLAGS_PCI (1 << 1)/* vfio-pci device */
> #de
On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> totally obsolete.
>
> I think the gamma_store can end up invalid on error. But the way I read
> it, that can happen in drm_mode_gamma_set_ioctl as well, so why
On Tue, Jun 20, 2017 at 09:25:24PM +0200, Peter Rosin wrote:
> Hi!
>
> While trying to get CLUT support for the atmel_hlcdc driver, and
> specifically for the emulated fbdev interface, I received some
> push-back that my feeble in-driver attempts should be solved
> by the core. This is my attempt
On Tue, Jun 20, 2017 at 05:40:25PM -0400, Sean Paul wrote:
> On Tue, Jun 20, 2017 at 10:28:37PM +0200, Daniel Vetter wrote:
> > In
> >
> > commit 91eefc05f0ac71902906b2058360e61bd25137fe
> > Author: Daniel Vetter
> > Date: Wed Dec 14 00:08:10 2016 +0100
> >
> > drm: Tighten locking in drm_
On 21/06/17 04:38 PM, Daniel Vetter wrote:
> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
>> totally obsolete.
>>
>> I think the gamma_store can end up invalid on error. But the way I read
>> it, that can ha
Idleness DRRS:
By default the DRRS state will be at DRRS_HIGH_RR. When a Display
content is Idle for more than 1Sec Idleness will be declared and
DRRS_LOW_RR will be invoked, changing the refresh rate to the
lower most refresh rate supported by the panel. As soon as
On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
> On 21/06/17 04:38 PM, Daniel Vetter wrote:
> > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> >> totally obsolete.
> >>
> >> I think the gam
Hi all,
This is the resend of the driver patches which haven't seen and ack/r-b yet and
so aren't merged yet. I'd really like to get them all merged. Review/acks very
much appreciated.
Thanks, Daniel
Daniel Vetter (13):
drm/amd|radeon: Drop drm_vblank_cleanup
drm/hibmc: Drop drm_vblank_clean
So this seems to be the first driver that does it the right way round,
so fix it up by calling drm_atomic_helper_shutdown instead. We need to
do that before the last kms user is gone (fbdev emulation), but before
we start shutting down hw stuff like interrupts.
Cc: Xinliang Liu
Cc: Rongrong Zou
Seems entirely cargo-culted.
Cc: CK Hu
Cc: Philipp Zabel
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index f6c8ec4c7dbc..56f802d0a51c
Again we probably want a drm_atomic_helper_shutdown somewhere, but
that's a bit more analysis.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/d
Both drivers shut down all crtc beforehand already, which will shut up
any pending vblank (the only thing vblank_cleanup really does is
disable the disable timer). Hence we don't need this here and can
remove it.
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu
On the load error path we can't have pending vblank interrupts, and on
unload we already call drm_atomic_helper_shutdown beforehand! So all
good to nuke it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/d
nouveau_display_vblank_fini is called in the load error path (where it
doesn't matter) and module unload (where vblanks have been shut down
correctly already through drm_vblank_off), we can drop it.
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/dr
Almost right but still racy, it's called before the interrupts are
uninstalled. So let's just drop it.
Cc: Marek Vasut
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb
udl doesn't shut down the display, so stopping the vblank isn't going
to do much good either. Just drop it.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/udl/udl_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/u
Either not relevant (in the load error paths) or done better already
(in the unload code, by calling drm_atomic_helper_shutdown). Drop it.
Cc: Mark Yao
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/d
It doesn't do anything in the driver load error paths that the drm
core doesn't also do.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
It again looks all cargo-culted for no good reasons.
Cc: Shawn Guo
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index f46c855d274b..fe1aa5315e19 100644
-
There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
calling drm_crtc_vblank_off(), which is best done by shutting down
the entire display engine with drm_atomic_helper_shutdown.
- Releasing
Again stopping the vblank before uninstalling the irq handler is kinda
the wrong way round, but the fb_off stuff should take care of
disabling the dsiplay at least in most cases. So drop the
drm_vblank_cleanup code since it's not really doing anything, it looks
all cargo-culted.
v2: Appease gcc be
On 21/06/17 05:14 PM, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
>> On 21/06/17 04:38 PM, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
>>
== Series Details ==
Series: RESEND: remove drm_vblank_cleanup from drivers
URL : https://patchwork.freedesktop.org/series/26118/
State : warning
== Summary ==
Series 26118v1 RESEND: remove drm_vblank_cleanup from drivers
https://patchwork.freedesktop.org/api/1.0/series/26118/revisions/1/mbox/
On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote:
> kbuild test robot found a build failure when building with thin
> archives:
>
> http://marc.info/?l=linux-kbuild&m=149802285009737&w=2
>
> Signed-off-by: Nicholas Piggin
Pushed to drm-intel for 4.14, thanks.
-Daniel
> ---
> dr
From: Tvrtko Ursulin
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection uAPI.
This is primarily interesting for the VCS engine selection which
is a) currently done via disjoint set
From: Tvrtko Ursulin
This is a lighter-weight alternative to the previously posted
RFC titled "drm/i915: Engine discovery uAPI" which still allows
some engine configuration probing without depending on PCI ids.
Signed-off-by: Tvrtko Ursulin
Cc: Ben Widawsky
Cc: Chris Wilson
Cc: Daniel Vetter
Quoting Daniel Vetter (2017-06-21 10:13:41)
> On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote:
> > kbuild test robot found a build failure when building with thin
> > archives:
> >
> > http://marc.info/?l=linux-kbuild&m=149802285009737&w=2
> >
> > Signed-off-by: Nicholas Piggin
>
The crtc->commit_lock only protects commit_list and commit_entry. If
we chase the pointer from the drm_atomic_state update structure, then
we don't need any locks (since we hold a reference already).
Simplify the locking accordingly.
Noticed while reviewing a patch from Boris.
Cc: Boris Brezillo
On 20/06/2017 17:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-20 16:55:12)
On 20/06/2017 13:43, Chris Wilson wrote:
Since we may track unfenced access (GPU access to the vma that
explicitly requires no fence), vma->last_fence may be set without any
Is this the gen < 4 code path?
Hi Daniel,
Thank you for the patch.
On Wednesday 21 Jun 2017 10:28:46 Daniel Vetter wrote:
> It doesn't do anything in the driver load error paths that the drm
> core doesn't also do.
If I understand the code correctly, this patch is fine because drm_dev_fini(),
called ultimately from drm_dev_r
Thanks for all the comments. I'm planning to cook the next version of this
patch set which I'd like to include all the comments and ideas. Here is the
summary:
1. How to figure the device capabilities
struct vfio_device_info {
__u32 argsz;
__u32 flags;
#define VFIO_DEVICE_FL
On 17/06/2017 12:57, Chris Wilson wrote:
As we walk the obj->vma_list in per_file_stats(), we need to hold
struct_mutex to prevent alteration of that list.
Fixes: 1d2ac403ae3b ("drm: Protect dev->filelist with its own mutex")
Fixes: c84455b4bacc ("drm/i915: Move debug only per-request pid track
Quoting Tvrtko Ursulin (2017-06-21 10:22:00)
>
> On 17/06/2017 12:57, Chris Wilson wrote:
> > @@ -476,6 +478,8 @@ static int i915_gem_object_info(struct seq_file *m,
> > void *data)
> > struct drm_i915_gem_request *request;
> > struct task_struct *task;
> >
> > +
When looking at 101518 I've noticed that piglit's html summary correctly
identifies warnings that are from stderr and dmesg. However CI doesn't
handle this correctly yet and doesn't get the dmesg errors.
Cc: Marta Löfstedt
Cc: Petri Latvala
Cc: Martin Peres
Bugzilla: https://bugs.freedesktop.or
Quoting Tvrtko Ursulin (2017-06-21 10:17:49)
>
> On 20/06/2017 17:05, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-06-20 16:55:12)
> >>
> >> On 20/06/2017 13:43, Chris Wilson wrote:
> >>> Since we may track unfenced access (GPU access to the vma that
> >>> explicitly requires no fence), vm
Mahesh Kumar schreef op wo 21-06-2017 om 11:44 [+0530]:
> This patch introduce addition wrapper for fixed point 16.16
> operations.
> Which will be used by later patches to avoid direct member variables
> access of fixed_16_16_t structure.
>
> add_fixed16 : takes 2 fixed_16_16_t variable & returns
Quoting Tvrtko Ursulin (2017-06-21 10:13:57)
> From: Tvrtko Ursulin
>
> This is a lighter-weight alternative to the previously posted
> RFC titled "drm/i915: Engine discovery uAPI" which still allows
> some engine configuration probing without depending on PCI ids.
>
> Signed-off-by: Tvrtko Ursu
On Tue, Jun 20, 2017 at 06:15:52PM +0300, Arkadiusz Hiler wrote:
> On Tue, Jun 20, 2017 at 01:54:54PM +, Szwichtenberg, Radoslaw wrote:
> > On Wed, 2017-06-14 at 12:44 -0700, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > This completes the change started by:
> > >
> > > comm
From: Vivek Kasireddy
In addition to adding the registers asscociated with MIPI DSI
encoder/connector, we also ensure intel_bios_init() function
gets called before intel_gvt_init() so that we can detect the presence
of MIPI DSI from the VBT and decide whether to read the releveant
registers or no
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Select engines via class and
instance in execbuffer2
URL : https://patchwork.freedesktop.org/series/26126/
State : success
== Summary ==
Series 26126v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
Quoting Tvrtko Ursulin (2017-06-20 12:26:44)
>
> On 16/06/2017 17:02, Chris Wilson wrote:
> > -static void resize_vma_ht(struct work_struct *work)
> > +static void lut_close(struct i915_gem_context *ctx)
> > {
> > - struct i915_gem_context_vma_lut *lut =
> > - container_of(work,
This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.
First 2 patches, comple
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 modes using the existing methods, we have
to complete the modedb (VIC=65 onw
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
structure. While handling the EDID from HDMI 2.0 sinks, its important to
know if the source is capable of handling YCBCR 420 outputs or not, so that
a lot of work can be done/bypassed based on this information. One such
exampl
This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 mode.
- get the highest subsamled ycbcr output.
- get the lowest subsamled ycbcr outpu
This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
V2
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 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.
This patch moves the
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc
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:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which c
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI i
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 ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
sc
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
V2: Rebase
V3: Rebase
V4: Rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
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.
This function adds a csc handler, t
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference, f
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
Signed-off-by: Shashank Sharma
Since we keep the context around across the slow lookup where we may
drop the struct_mutex, we should double check that the context is still
valid upon reacquisition.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_execbuf
When reading all debugfs files on a system with DP-MST the kernel panics
on a null pointer dereference because intel_dp is null for a DP-MST
connector. Detect this case and skip those connectors.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 ++
When I was doing a grep . -r /sys/kernel/debug/dri/0 I noticed a WARN
appearing when I aborted the grep with ^C.
After investigating I've also noticed that the error handling was
lacking and there are race conditions involving multiple calls to
open/close simultaneously.
Fix this by setting the o
On Wed, 2017-06-21 at 09:20 +, Zhang, Tina wrote:
> Thanks for all the comments. I'm planning to cook the next version of
> this patch set
How about posting only this patch instead of the whole series until
we've settled the interfaces?
> Could the following two works?
> #define VFIO_DEVICE_F
== Series Details ==
Series: drm/atomic-helper: Simplify commit tracking locking
URL : https://patchwork.freedesktop.org/series/26127/
State : success
== Summary ==
Series 26127v1 drm/atomic-helper: Simplify commit tracking locking
https://patchwork.freedesktop.org/api/1.0/series/26127/revisio
On 20/06/2017 20:55, Chris Wilson wrote:
Trying to do a modeset from within a reset is fraught with danger. We
can fall into a cyclic deadlock where the modeset is waiting on a
previous modeset that is waiting on a request, and since the GPU hung
that request completion is waiting on the reset.
Quoting Tvrtko Ursulin (2017-06-21 12:30:15)
>
> On 20/06/2017 20:55, Chris Wilson wrote:
> > Trying to do a modeset from within a reset is fraught with danger. We
> > can fall into a cyclic deadlock where the modeset is waiting on a
> > previous modeset that is waiting on a request, and since the
== Series Details ==
Series: drm/i915: Check context status before looking up our obj/vma
URL : https://patchwork.freedesktop.org/series/26137/
State : success
== Summary ==
Series 26137v1 drm/i915: Check context status before looking up our obj/vma
https://patchwork.freedesktop.org/api/1.0/se
On Wed, Jun 21, 2017 at 10:28:49AM +0200, Daniel Vetter wrote:
> It again looks all cargo-culted for no good reasons.
>
> Cc: Shawn Guo
> Signed-off-by: Daniel Vetter
Acked-by: Shawn Guo
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
== Series Details ==
Series: drm/i915: Prevent kernel panic on reading out compliance debugfs files
URL : https://patchwork.freedesktop.org/series/26139/
State : success
== Summary ==
Series 26139v1 drm/i915: Prevent kernel panic on reading out compliance debugfs
files
https://patchwork.freed
== Series Details ==
Series: drm/crc: Handle opening and closing crc better
URL : https://patchwork.freedesktop.org/series/26140/
State : success
== Summary ==
Series 26140v1 drm/crc: Handle opening and closing crc better
https://patchwork.freedesktop.org/api/1.0/series/26140/revisions/1/mbox/
Quoting Chris Wilson (2017-06-21 12:46:51)
> Quoting Tvrtko Ursulin (2017-06-21 12:30:15)
> >
> > On 20/06/2017 20:55, Chris Wilson wrote:
> > > + i915_gem_set_wedged(w->i915);
> >
> > Is it safe to do the execlist_port manipulation at this point? Couldn't
> > we receive an interrupt for one
Highly unlikely, but if the stop_machine() did suspend the tasklet, we
want to make sure that when it wakes it finds there is nothing to do.
Otherwise, it will loudly complain that the ELSP port tracking no longer
matches the hardware, and we will be mightly confused.
Signed-off-by: Chris Wilson
I've failed to remember that we have virtual drivers like vgem which
have no underlying struct device. Fix this asap.
Reported-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Fixes: 5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
Cc: Thierry Reding
Cc: Daniel Vetter
Signed
== Series Details ==
Series: drm/i915: Cancel pending execlist tasklet upon wedging
URL : https://patchwork.freedesktop.org/series/26146/
State : success
== Summary ==
Series 26146v1 drm/i915: Cancel pending execlist tasklet upon wedging
https://patchwork.freedesktop.org/api/1.0/series/26146/r
== Series Details ==
Series: drm: Check for drm_device->dev in drm_set_busid
URL : https://patchwork.freedesktop.org/series/26149/
State : success
== Summary ==
Series 26149v1 drm: Check for drm_device->dev in drm_set_busid
https://patchwork.freedesktop.org/api/1.0/series/26149/revisions/1/mbo
On 21/06/2017 13:48, Chris Wilson wrote:
Highly unlikely, but if the stop_machine() did suspend the tasklet, we
want to make sure that when it wakes it finds there is nothing to do.
Otherwise, it will loudly complain that the ELSP port tracking no longer
matches the hardware, and we will be migh
On 21/06/2017 12:46, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-21 12:30:15)
On 20/06/2017 20:55, Chris Wilson wrote:
Trying to do a modeset from within a reset is fraught with danger. We
can fall into a cyclic deadlock where the modeset is waiting on a
previous modeset that is waiti
On Wed, Mar 29, 2017 at 04:44:01PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The expression &private->fbdev_helper can never be NULL, so the check is
> completely unnecessary.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Thierry Reding
I just noticed that these two patches at
On 06/21/2017 12:33 PM, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
>
On 06/21/2017 12:34 PM, Shashank Sharma wrote:
> This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
> structure. While handling the EDID from HDMI 2.0 sinks, its important to
> know if the source is capable of handling YCBCR 420 outputs or not, so that
> a lot of work can be d
On 06/21/2017 12:34 PM, 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 modes using the e
On Wed, Jun 21, 2017 at 03:04:29PM +0200, Daniel Vetter wrote:
> I've failed to remember that we have virtual drivers like vgem which
> have no underlying struct device. Fix this asap.
>
> Reported-by: Chris Wilson
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson
> Fixes: 5c484cee7ef9 ("drm: Remo
On 25 April 2017 at 23:32, Lionel Landwerlin
wrote:
> When debugging unstable tests on new platforms we currently we don't
> cleanup everything well in between different tests. Since only a
> single OA stream fd can be opened at a time, having the stream_fd as a
> global variable helps us cleanup
Quoting Tvrtko Ursulin (2017-06-21 14:37:33)
>
> On 21/06/2017 12:46, Chris Wilson wrote:
> > It's the replacement for the removed idle_work, but now I realise that we
> > are guaranteed a i915_gem_retire_requests() as part of the reset procedure.
>
> So will be respinning with this removed?
I w
Quoting Tvrtko Ursulin (2017-06-21 14:33:59)
>
> On 21/06/2017 13:48, Chris Wilson wrote:
> > Highly unlikely, but if the stop_machine() did suspend the tasklet, we
> > want to make sure that when it wakes it finds there is nothing to do.
> > Otherwise, it will loudly complain that the ELSP port t
Quoting Tvrtko Ursulin (2017-06-21 14:33:59)
>
> On 21/06/2017 13:48, Chris Wilson wrote:
> > Highly unlikely, but if the stop_machine() did suspend the tasklet, we
> > want to make sure that when it wakes it finds there is nothing to do.
> > Otherwise, it will loudly complain that the ELSP port t
On 21/06/2017 14:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-21 14:33:59)
On 21/06/2017 13:48, Chris Wilson wrote:
Highly unlikely, but if the stop_machine() did suspend the tasklet, we
want to make sure that when it wakes it finds there is nothing to do.
Otherwise, it will loudly
vgem is a nasty test case for various parts of the core as it is a
virtual device with drm_device.dev == NULL; this includes drm_setversion
for example.
Signed-off-by: Chris Wilson
---
tests/intel-ci/fast-feedback.testlist | 1 +
tests/vgem_basic.c| 31 ++
Quoting Tvrtko Ursulin (2017-06-21 15:06:34)
>
> On 21/06/2017 14:53, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-06-21 14:33:59)
> >>
> >> On 21/06/2017 13:48, Chris Wilson wrote:
> >>> Highly unlikely, but if the stop_machine() did suspend the tasklet, we
> >>> want to make sure that wh
Trying to do a modeset from within a reset is fraught with danger. We
can fall into a cyclic deadlock where the modeset is waiting on a
previous modeset that is waiting on a request, and since the GPU hung
that request completion is waiting on the reset. As modesetting doesn't
allow its locks to be
Hi,
Thanks for review :)
-Mahesh
On Wednesday 21 June 2017 03:10 PM, Lankhorst, Maarten wrote:
Mahesh Kumar schreef op wo 21-06-2017 om 11:44 [+0530]:
This patch introduce addition wrapper for fixed point 16.16
operations.
Which will be used by later patches to avoid direct member variables
On Wed, Jun 21, 2017 at 11:16:27AM +0200, Daniel Vetter wrote:
> The crtc->commit_lock only protects commit_list and commit_entry. If
> we chase the pointer from the drm_atomic_state update structure, then
> we don't need any locks (since we hold a reference already).
>
> Simplify the locking acco
So back when the i915 power well support landed in
commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
Author: Wang Xingchao
Date: Thu May 30 22:07:10 2013 +0800
ALSA: hda - Add power-welll support for haswell HDA
the logic to handle the cross-module depencies was hand-rolled using a
async wo
Quoting Daniel Vetter (2017-06-21 16:08:54)
> So back when the i915 power well support landed in
>
> commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> Author: Wang Xingchao
> Date: Thu May 30 22:07:10 2013 +0800
>
> ALSA: hda - Add power-welll support for haswell HDA
>
> the logic to hand
On Wed, 21 Jun 2017 17:23:57 +0200,
Chris Wilson wrote:
>
> Quoting Daniel Vetter (2017-06-21 16:08:54)
> > So back when the i915 power well support landed in
> >
> > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > Author: Wang Xingchao
> > Date: Thu May 30 22:07:10 2013 +0800
> >
> >
== Series Details ==
Series: drm/i915: Break modeset deadlocks on reset (rev3)
URL : https://patchwork.freedesktop.org/series/26059/
State : success
== Summary ==
Series 26059v3 drm/i915: Break modeset deadlocks on reset
https://patchwork.freedesktop.org/api/1.0/series/26059/revisions/3/mbox/
Regards
Shashank
On 6/20/2017 7:50 PM, Ander Conselvan De Oliveira wrote:
On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote:
This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HD
== Series Details ==
Series: BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
URL : https://patchwork.freedesktop.org/series/26154/
State : failure
== Summary ==
Series 26154v1 BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
https://patchwork.freedesktop.org/api/1.0/series/2
Op 21-06-17 om 16:24 schreef Chris Wilson:
> Trying to do a modeset from within a reset is fraught with danger. We
> can fall into a cyclic deadlock where the modeset is waiting on a
> previous modeset that is waiting on a request, and since the GPU hung
> that request completion is waiting on the
1 - 100 of 177 matches
Mail list logo
