On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
Plenty acks, also merged for 4.12.
Thanks, Daniel
> ---
> driver
Op 01-03-17 om 01:49 schreef Laurent Pinchart:
> Hi Maarten,
>
> Thank you for the patch.
>
> On Thursday 16 Feb 2017 15:47:06 Maarten Lankhorst wrote:
>> There are new iterator macros that annotate whether the new or old
>> state should be used. This is better than using a state that depends on
>>
There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.
Changes since v1:
- Use old/n
This is a straightforward conversion that converts all the users of
get_existing_state in atomic core to use get_old_state or get_new_state
Changes since v1:
- Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state.
Changes since v2:
- Use the correct state in disable_outputs()
GVT-g (Intel® Graphics Virtualization Technology) is a full GPU
virtualization solution with mediated pass-through support.
This tool is for create basic Linux guest based on KVMGT with
VFIO framework, it including create vgpu, create guest, check IP
address, destroy guest, remove vgpu,check dmesg
On Tue, Feb 28, 2017 at 05:00:28PM +0200, Jani Nikula wrote:
> On Tue, 28 Feb 2017, Chris Wilson wrote:
> > drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’:
> > drivers/gpu/drm/i915/intel_dsi.c:1308:1: error: the frame size of 2488
> > bytes is larger than 2048 bytes [-Werror=fr
One case where I nuked a now unecessary locking, otherwise all just
boring stuff.
v2: Rebase onto the iter_get/put->iter_begin/end rename.
Cc: Thierry Reding
Cc: Maarten Lankhorst
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_opregion.c | 15 ---
1 f
This gets rid of the last users of for_each_intel_connector(), remove
that too.
At first I wasn't sure whether the 2 loops in the modeset state
checker should instead only loop over the connectors in the atomic
commit. But we never add connectors to an atomic update if they don't
(or won't have) a
The trouble here is that looking at all connector->state in the
verifier isn't good, because that's run from the commit work, which
doesn't hold the connection_mutex. Which means we're only allowed to
look at states in our atomic update.
The simple fix for future proofing would be to switch over t
Drive-by fixup while looking at all the connector_list walkers -
holding connection_mutex does actually _not_ give you locking to look
at the legacy drm_connector->encoder->crtc pointer chain. That one is
solely owned by the atomic commit workers. Instead we must inspect the
atomic state.
Signed-o
Nothing special, just rote conversion.
v2: Rebase onto the iter_get/put->iter_begin/end rename.
Cc: Thierry Reding
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hotplug.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
While at it also try to reduce the locking a bit to what's really just
needed instead of everything that we could possibly lock.
Added a new for_each_intel_connector_iter which includes the cast to
intel_connector.
Otherwise just plain transformation with nothing special going on.
v2: Review fro
On Wed, 01 Mar 2017, Hans de Goede wrote:
> Hi,
>
> On 28-02-17 17:31, Jani Nikula wrote:
>>
>> Cc: Hans, this probably applies to you as well.
>
> I'm already always using git-send-email, so whatever the
> reason why the CI system is not picking up my patches, this
> aint it.
It doesn't look lik
Hi Maarten,
Thank you for the resend.
For the whole series,
Tested-by: Laurent Pinchart
On Wednesday 01 Mar 2017 10:21:26 Maarten Lankhorst wrote:
> There are new iterator macros that annotate whether the new or old
> state should be used. This is better than using a state that depends on
> wh
Hi,
On 01-03-17 10:57, Jani Nikula wrote:
On Wed, 01 Mar 2017, Hans de Goede wrote:
Hi,
On 28-02-17 17:31, Jani Nikula wrote:
Cc: Hans, this probably applies to you as well.
I'm already always using git-send-email, so whatever the
reason why the CI system is not picking up my patches, thi
On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote:
> /**
> + * enum drm_link_status - connector's link_status property value
> + *
> + * This enum is used as the connector's link status property value.
> + * It is set to the values defined in uapi.
> + */
> +enum drm_link_status {
> +
Hi all,
topic/designware-baytrail-2017-03-01:
Baytrail PMIC vs. PMU race fixes from Hans de Goede
I opted to put all the patches for all subsystems into the topic branches,
so that if needed, each subsystem can apply refactorings to the entire
thing. Which might be needed since we're very early i
On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> On 17-02-28 12:18:39, Jason Ekstrand wrote:
> >I've said it before but reading through Ben's patches again make me want to
> >be peskier about it. I would really like the UABI to treat the CCS as if
> >it's Y-tiled with a tile size o
== Series Details ==
Series: series starting with [1/6] drm/i915: Use drm_connector_list_iter in
debugfs
URL : https://patchwork.freedesktop.org/series/20441/
State : failure
== Summary ==
Series 20441v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20441/revisi
Similar to fast-feedback test list. The point of the generic test list is to
gather
pass-rate when running generic tests - i.e., tests that don't rely on specific
GPUs.
Again, this test list is dynamic and will either shrink or grow over time.
Signed-off-by: Abdiel Janulgue
Cc: Petri Latvala
C
On Wed, 01 Mar 2017, Madhav Chauhan wrote:
> From: Deepak M
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
> v3: Jani's Review comment for aligning code to platforms and added
> wrapper functions.
> v4: Corrected enable/disable seuqence as per BSPEC
> v5: Corrected waiting twi
On Fri, Feb 24, 2017 at 03:52:15PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2)
> URL : https://patchwork.freedesktop.org/series/19961/
> State : success
>
> == Summary ==
>
> Series 19961v2 drm/i915/gen9: Increase PCO
I915_EXEC_FENCE_OUT was added in libdrm commit a3d715ee14b2 ("Import
uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9") and released in
libdrm-2.4.75.
Signed-off-by: Jani Nikula
---
I'm probably doing something wrong. This passes configure for me, but
build still fails with:
gem_latency.c: In
On 03/01/2017 01:34 PM, Jani Nikula wrote:
I915_EXEC_FENCE_OUT was added in libdrm commit a3d715ee14b2 ("Import
uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9") and released in
libdrm-2.4.75.
Signed-off-by: Jani Nikula
Reviewed-by: Petri Latvala
---
I'm probably doing something wrong.
The spam of every context initialisation saying the same thing is annoying
me! Move the information to the setup of the engine.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 38 +-
1 file changed, 19 insertions(+), 19
On ma, 2017-02-27 at 13:50 +0100, Arkadiusz Hiler wrote:
> Let intel_guc_init_fw() focus on determining and fetching the correct
> firmware.
>
> This patch introduces intel_uc_sanitize_options() that is called from
> intel_sanitize_options().
>
> Then, if we have GuC, we can call intel_guc_init_f
On pe, 2017-02-24 at 06:01 -0800, Oscar Mateo wrote:
> Starting with intel_guc_loader, down to intel_guc_submission
> and finally to intel_guc_log.
>
> v2:
> - Null execbuf client outside guc_client_free (Daniele)
> - Assert if things try to get allocated twice (Daniele/Joonas)
> - Null guc-
On pe, 2017-02-24 at 06:01 -0800, Oscar Mateo wrote:
> When initializing the GuC log struct, there is an object we need to
> allocate always, since the GuC needs its address at fw load time.
> The rest are "extras", in the sense that we only need them if we
> actually enable GuC logging. Make that
On Thu, Feb 23, 2017 at 08:14:20PM +0100, Michał Winiarski wrote:
> We should probably do this conditionally, based on whether preemption is
> actually enabled.
>
> Signed-off-by: Michał Winiarski
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-
On Thu, Feb 23, 2017 at 08:14:15PM +0100, Michał Winiarski wrote:
> +static void unsubmit_inflight_requests(struct intel_engine_cs *engine,
> + struct list_head *resubmit)
> +{
> + struct drm_i915_gem_request *rq, *prev;
> +
> + assert_spin_locked(&engin
On 02/22, Robert Bragg wrote:
> These are auto generated from an XML description of metric sets,
> currently maintained in gputop, ref:
>
> https://github.com/rib/gputop
> > gputop-data/oa-*.xml
> > scripts/i915-perf-kernelgen.py
>
> $ make -C gputop-data -f Makefile.xml
>
> Signed-off-by: R
On Tue, Feb 28, 2017 at 04:22:32PM +, Chris Wilson wrote:
> No more direct return -EINVAL as we have to unwind the
> obj->framebuffer_references.
>
> Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating
> the framebuffer")
> Signed-off-by: Chris Wilson
> Cc: Ville Syrj
On Tue, Feb 28, 2017 at 04:22:33PM +, Chris Wilson wrote:
> Reintroduce a lock around tiling vs framebuffer creation to prevent
> modification of the obj->tiling_and_stride whilst the framebuffer is
> being created. Rather than use struct_mutex once again, use the
> per-object lock - this will
From: Hans de Goede
Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code and the spec.
Signed-off-by: Hans de Goede
Acked-by: Jani Nikula
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 37 +++
Resending again to get CI...
BR,
Jani.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Hans de Goede
Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.
From: Hans de Goede
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 4 ++--
From: Hans de Goede
For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF,
v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 2 ++
1 file cha
From: Hans de Goede
Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 10 --
1 file changed, 4 insertions(
From: Hans de Goede
intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET,
will always be called at some point before intel_dsi_pre_enable()
making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant.
In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes
against t
From: Hans de Goede
Move the DPOunit clock gate workaround to directly after the PLL enable.
The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:
1) This moves it out of the middle of the init sequence from the spec,
making it easier t
From: Hans de Goede
According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikul
From: Hans de Goede
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.
Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.
Signed-off-by: Hans de Goed
From: Hans de Goede
For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 19 ++
== Series Details ==
Series: drm/i915: Move w/a LRI debug message from context-init to driver load
URL : https://patchwork.freedesktop.org/series/20452/
State : warning
== Summary ==
Series 20452v1 drm/i915: Move w/a LRI debug message from context-init to driver
load
https://patchwork.freedes
On Wed, 15 Feb 2017, Seth Forshee wrote:
> Maybe it would be good to have something like MODULE_OPTIONAL_FIRMWARE
> to identify firmware that isn't required but will be used by the driver
> if available. Then mkinitramfs can try to copy those files along with
> the module but know that there's no
On Tue, 28 Feb 2017, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 01:11:43PM +0200, Jani Nikula wrote:
>> Leave the runtime check in place in case the platform variable itself
>> comes from bogus sources.
>>
>> Signed-off-by: Jani Nikula
>
> Neat.
> Reviewed-by: Chris Wilson
Pushed, thanks fo
== Series Details ==
Series: series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the
panel enable / disable sequences from the spec
URL : https://patchwork.freedesktop.org/series/20456/
State : failure
== Summary ==
Series 20456v1 Series without cover letter
https://patchwork.fr
On Wed, 01 Mar 2017, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the
> panel enable / disable sequences from the spec
> URL : https://patchwork.freedesktop.org/series/20456/
> State : failure
>
> == Summary ==
>
> Series
On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> 1.1.
>
> When a sink that supports deep color is connected to the output, the
> receiver will send EDIDs that advertise this capability, even if it
> isn't possi
Using crtc->config directly is being removed in favor of passing a
pipe_config. Follow the trend and pass pipe_config to pch_enable()
functions.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 18 ++
1 file changed, 10 insertions(+), 8 delet
The function intel_lpt_pch_enable() needs an intel_crtc so pass that
instead of the generic crtc type.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915
The implementation of the fdi_link_train() hooks need an intel_crtc so
just pass that instead of the generic crtc type.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 13
drivers/gpu/drm/i915/intel_dis
Hi,
Here's a v2 of the fix for the regression caused by the recent DDI IO
power domain changes. This time with moar patches and actual testing.
The new patches remove the usage of crtc->config from intel_ddi.c and
that also removes the oops with encoder->crtc being NULL.
Ander Conselvan de Olivei
Pass intel_crtc to functions intel_ddi_enable_transcoder_func(),
intel_ddi_set_pipe_settings() and intel_ddi_set_vc_payload_alloc(),
instead of the generic crtc type. By changing the functions
intel_ddi_get_crtc_encoder() so that it receives an intel_crtc
parameter, there is no need for the drm_crt
Remove direct usages of intel_crtc->config from the DDI code. Functions
that didn't yet take a pipe_config as an argument were coverted to do
so.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_ddi.c | 61 +++-
drivers/gpu/drm/i915/i
It is preferred to pass pipe_config to functions instead of accessing
crtc->config directly. Follow suit and pass pipe_config to the fdi link
train functions.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_ddi.c | 9
On 2/27/2017 1:35 AM, Daniel Vetter wrote:
On Thu, Feb 09, 2017 at 09:34:49AM +0200, Joonas Lahtinen wrote:
On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote:
Bring the test/set/clear bit functions we have into a single place.
Signed-off-by: Michel Thierry
Reviewed-by: Joonas Lahtine
On Wed, Mar 01, 2017 at 03:23:06PM +0200, Jani Nikula wrote:
> On Wed, 15 Feb 2017, Seth Forshee wrote:
> > Maybe it would be good to have something like MODULE_OPTIONAL_FIRMWARE
> > to identify firmware that isn't required but will be used by the driver
> > if available. Then mkinitramfs can try
The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
by calling the post_disable hook on the intel_dig_port instead of
duplicating that code.
v2: Don't oops because of a NULL encoder->crtc. (Ville)
Cc: Imre Dea
On Wed, 01 Mar 2017, Madhav Chauhan wrote:
> From: Deepak M
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
> v3: Jani's Review comment for aligning code to platforms and added
> wrapper functions.
> v4: Corrected enable/disable seuqence as per BSPEC
> v5: Corrected waiting twi
Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") changed how the DDI IO power domains get enabled, but
neglected the need to enable those domains when enabling a DP connector
with MST enabled, leading to
Kernel panic - not syncing: Timeout: Not all CPUs en
On Wed, Mar 01, 2017 at 04:13:14PM +0200, Ander Conselvan de Oliveira wrote:
> Using crtc->config directly is being removed in favor of passing a
> pipe_config. Follow the trend and pass pipe_config to pch_enable()
> functions.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gp
This fixes the kernel doc warning that was introduced in
the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
atomic property for link status")'. Description has
been added for the enum values.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
-
On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within
On Wed, Mar 01, 2017 at 06:45:10AM -0800, Manasi Navare wrote:
> This fixes the kernel doc warning that was introduced in
> the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
> atomic property for link status")'. Description has
> been added for the enum values.
>
> Signed-off-by: Manasi Navare
On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the moni
Op 16-02-17 om 19:07 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Add tracepoints for display FIFO underruns. Makes it more convenient to
> correlate the underruns with other display tracepoints.
I'm still not sold on how crtc_state->visible_planes deviates from
crtc_state->pl
On Tue, Feb 28, 2017 at 05:01:25PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 28, 2017 at 03:28:47PM +0100, Maarten Lankhorst wrote:
> > This cannot be done reliably during vblank evasasion
> > since the color management registers are not double buffered.
> >
> > The original commit that moved it a
On Tue, Feb 28, 2017 at 03:28:48PM +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/i
Reintroduce a lock around tiling vs framebuffer creation to prevent
modification of the obj->tiling_and_stride whilst the framebuffer is
being created. Rather than use struct_mutex once again, use the
per-object lock - this will also be required in future to prevent
changing the tiling whilst submi
No more direct return -EINVAL as we have to unwind the
obj->framebuffer_references.
Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the
framebuffer")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c |
On Fri, Dec 16, 2016 at 12:29:07PM +0200, Jani Nikula wrote:
> From: Manasi Navare
>
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link trainin
On Wed, Mar 01, 2017 at 03:09:36PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 28, 2017 at 04:22:33PM +, Chris Wilson wrote:
> > Reintroduce a lock around tiling vs framebuffer creation to prevent
> > modification of the obj->tiling_and_stride whilst the framebuffer is
> > being created. Rather t
== Series Details ==
Series: Try to fix MST regression with DDI IO power domains (rev2)
URL : https://patchwork.freedesktop.org/series/20345/
State : success
== Summary ==
Series 20345v2 Try to fix MST regression with DDI IO power domains
https://patchwork.freedesktop.org/api/1.0/series/20345/
Bring the test/set/clear bit functions we have into a single place.
v2: Add gtk-doc comment blocks (Daniel)
Cc: Daniel Vetter
Reviewed-by: Joonas Lahtinen (v1)
Signed-off-by: Michel Thierry
---
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 +
lib/Makefile.sources
On Wed, Mar 01, 2017 at 04:07:02PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> > 1.1.
> >
> > When a sink that supports deep color is connected to the output, the
> > receiv
On Wed, Mar 01, 2017 at 07:52:26AM -0800, Michel Thierry wrote:
> Bring the test/set/clear bit functions we have into a single place.
>
> v2: Add gtk-doc comment blocks (Daniel)
Hiss, boo! Will someone take gtk-doc and bury it? -flto to save the day?
-Chris
--
Chris Wilson, Intel Open Source Te
This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
I assumed it's ok, but really should have double-checked - CI caught
tons of fail :(
Cc: Jani Nikula
Cc: Manasi Navare
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 27 ---
On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>
> I assumed it's ok, but really should have double-checked - CI caught
> tons of fail :(
For the record, the failure comes from the error message in
intel_dp_get_link_t
On Wed, 01 Mar 2017, Chris Wilson wrote:
> On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
>> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>>
>> I assumed it's ok, but really should have double-checked - CI caught
>> tons of fail :(
Considering the velocity of drm
On Wed, 01 Mar 2017, Jani Nikula wrote:
> On Wed, 01 Mar 2017, Chris Wilson wrote:
>> On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
>>> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>>>
>>> I assumed it's ok, but really should have double-checked - CI caught
>>>
Engine related definitions are located in different files
and it is easy to break their cross dependency.
Additionally use GEM_WARN_ON to catch invalid engine index.
v2: compare against array size
Signed-off-by: Michal Wajdeczko
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Fix all intel_framebuffer_init
failures to take the error path
URL : https://patchwork.freedesktop.org/series/20464/
State : success
== Summary ==
Series 20464v1 Series without cover letter
https://patchwork.freedesktop.org/
On 17-03-01 12:51:17, Ville Syrjälä wrote:
On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
On 17-02-28 12:18:39, Jason Ekstrand wrote:
>I've said it before but reading through Ben's patches again make me want to
>be peskier about it. I would really like the UABI to treat the CC
On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote:
> On Wed, 01 Mar 2017, Chris Wilson wrote:
> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
> >>
> >> I assumed it's ok, but really should have double-
On Wed, Mar 01, 2017 at 09:50:56AM -0800, Ben Widawsky wrote:
> On 17-03-01 12:51:17, Ville Syrjälä wrote:
> >On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> >> On 17-02-28 12:18:39, Jason Ekstrand wrote:
> >
> >> >I've said it before but reading through Ben's patches again make me
On Wed, 01 Mar 2017, Ville Syrjälä wrote:
> On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote:
>> On Wed, 01 Mar 2017, Chris Wilson wrote:
>> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
>> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>> >>
>> >>
On Wed, Mar 01, 2017 at 08:18:18PM +0200, Jani Nikula wrote:
> On Wed, 01 Mar 2017, Ville Syrjälä wrote:
> > On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote:
> >> On Wed, 01 Mar 2017, Chris Wilson wrote:
> >> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
> >> >> Thi
On Tue, Feb 07, 2017 at 01:20:35AM -0800, Oscar Mateo wrote:
> From: Michal Wajdeczko
>
> Prepare for an alternate GuC communication interface.
>
> v2: Make a few functions static and name them correctly while we are at it
> (Oscar)
> v3: Leave an intel_guc_send_mmio interface for users that re
One of the if statement covers the next line in enable I/O sequence.
This patch correct the same by adding error message.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, March 1, 2017 7:44 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Shankar, Uma ; Mukherjee, Indranil
> ; Saarinen, Jani ;
> Kamath, Sunil ; Deepak M
> ; Chauhan, Madhav
> Sub
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0
[i915] at addr 8801f7788358
[31908.547297] Read of size 8 by task drv_selftest/3781
[31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: GBU W
4.10.0+ #451
[31908.547553] Hardware name:
== Series Details ==
Series: drm/i915: Use BUILD_BUG_ON to detected missing engine definitions (rev2)
URL : https://patchwork.freedesktop.org/series/20394/
State : success
== Summary ==
Series 20394v2 drm/i915: Use BUILD_BUG_ON to detected missing engine definitions
https://patchwork.freedeskt
On 01/03/2017 12:11, Chris Wilson wrote:
The spam of every context initialisation saying the same thing is annoying
me! Move the information to the setup of the engine.
Yes I've noticed this ugly side effect of code consolidation. :)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
driv
On 01/03/2017 17:39, Michal Wajdeczko wrote:
Engine related definitions are located in different files
and it is easy to break their cross dependency.
Additionally use GEM_WARN_ON to catch invalid engine index.
v2: compare against array size
Signed-off-by: Michal Wajdeczko
Cc: Jani Nikula
C
On Tue, Feb 28, 2017 at 09:53:37PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 07:07:38PM +0100, Michal Wajdeczko wrote:
> > On Tue, Feb 28, 2017 at 04:52:34PM +, Chris Wilson wrote:
> > > On Tue, Feb 28, 2017 at 04:43:02PM +, Chris Wilson wrote:
> > > > On Tue, Feb 28, 2017 at 02:
== Series Details ==
Series: drm/i915/glk: Fix DSI enable I/O sequence
URL : https://patchwork.freedesktop.org/series/20474/
State : warning
== Summary ==
Series 20474v1 drm/i915/glk: Fix DSI enable I/O sequence
https://patchwork.freedesktop.org/api/1.0/series/20474/revisions/1/mbox/
Test gem
Return silently without producing much noise on platforms
that have a HuC but the firmware is absent.
Cc: Ander Conselvan De Oliveira
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_huc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/d
On Wed, Mar 01, 2017 at 07:29:15PM +, Tvrtko Ursulin wrote:
>
> On 01/03/2017 17:39, Michal Wajdeczko wrote:
> > Engine related definitions are located in different files
> > and it is easy to break their cross dependency.
> >
> > Additionally use GEM_WARN_ON to catch invalid engine index.
>
1 - 100 of 118 matches
Mail list logo
