As that is what they are meant to be. It will prevent any confusion if we
have to add other flags in the future.
Signed-off-by: Michel Thierry
---
lib/igt_gt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index e44b6db1..d83e23a1 100644
---
== Series Details ==
Series: drm/i915/dp: Reset the link params on HPD/connected boot/resume
URL : https://patchwork.freedesktop.org/series/19277/
State : success
== Summary ==
Series 19277v1 drm/i915/dp: Reset the link params on HPD/connected boot/resume
https://patchwork.freedesktop.org/api/
The max link parameters should be set/reset only on HPD or
connected boot case or on system resume.
Add a flag reset_link_params to intel_dp to decide when
to reset the max link parameters. This prevents the parameters
from getting reset/overwritten through all other
connector->funcs->detect() cal
== Series Details ==
Series: drm/i915/dp: Clean up/Get rid of detect_done flag
URL : https://patchwork.freedesktop.org/series/19276/
State : success
== Summary ==
Series 19276v1 drm/i915/dp: Clean up/Get rid of detect_done flag
https://patchwork.freedesktop.org/api/1.0/series/19276/revisions/1
On 7 February 2017 at 14:49, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
>> On 7 February 2017 at 14:29, Daniel Vetter wrote:
>> > Noticed that everyone duplicates the same logic here and we could safe
>> > a few lines per driver. Yay for lots of drivers to
Detect_done flag was added previously when intel_dp_long_pulse
was called from multiple places. However now it is called only
from intel_dp_detect(). So this flag becomes redundant.
Anyway now, we set this to false right away after intel_dp_long_pulse
so it calls long pulse handler always for all c
== Series Details ==
Series: series starting with [1/3] drm/i915: Move calling engine->init_hw() to
its own function
URL : https://patchwork.freedesktop.org/series/19263/
State : success
== Summary ==
Series 19263v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/
Hi,
Please consider pulling i915 updates to linux-firmware.git.
The following changes since commit 6d3bc8886517d171068fd1263176b8b5c51df204:
Fix permissions on ti-connectivity firmware from 05e9fe59 (2017-01-13
10:14:07 -0500)
are available in the git repository at:
https://github.com/anu
On Tue, Feb 07, 2017 at 05:54:10PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Following a reset, the context and page directory registers are lost.
> > However, the queue of requests that we resubmit after the reset may
> > depend upon them - the registers are restored from a contex
On Tue, Feb 07, 2017 at 09:12:25PM +, Chris Wilson wrote:
> Currently we do a reset prepare/finish around the call to reset the GPU,
> but it looks like we need a later stage after the hw has been
> reinitialised to allow GEM to restart itself. Start by splitting the 2
> GEM phases into 3:
>
>
When we restart the engines, and we have active requests, a request on
the first engine may complete and queue a request to the second engine
before we try to restart the second engine. That queueing of the
request may race with the engine to restart, and so may corrupt the
current state. Disabling
Just a simple refactor to move a loop and some support code out of
i915_gem_init_hw(). This is in preparation for avoiding a race between
the tasklet writing to ELSP whilst simultaneously being written by
engine->init_hw() following a GPU reset.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Currently we do a reset prepare/finish around the call to reset the GPU,
but it looks like we need a later stage after the hw has been
reinitialised to allow GEM to restart itself. Start by splitting the 2
GEM phases into 3:
prepare - before the reset, check if GEM recovered, then stop GEM
re
== Series Details ==
Series: drm/i915: Always convert incoming exec offsets to non-canonical
URL : https://patchwork.freedesktop.org/series/19259/
State : failure
== Summary ==
Series 19259v1 drm/i915: Always convert incoming exec offsets to non-canonical
https://patchwork.freedesktop.org/api/
On Tue, Feb 07, 2017 at 01:37:52AM -0800, Oscar Mateo wrote:
>
>
> On 02/07/2017 09:25 AM, Chris Wilson wrote:
> >On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:
> >>
> >>On 02/02/2017 11:33 PM, Chris Wilson wrote:
> >>>On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
> >
On Tue, Feb 07, 2017 at 08:55:59PM +0100, Michał Winiarski wrote:
> We're using non-canonical addresses in drm_mm, and we're making sure that
> userspace is using canonical addressing - both in case of softpin
> (verifying incoming offset) and when relocating (converting to canonical
> when updatin
== Series Details ==
Series: drm/i915: Introduce intel_cdclk_state (rev12)
URL : https://patchwork.freedesktop.org/series/16994/
State : warning
== Summary ==
Series 16994v12 drm/i915: Introduce intel_cdclk_state
https://patchwork.freedesktop.org/api/1.0/series/16994/revisions/12/mbox/
Test k
This has been tested to correctly execute the compliance request.
Reviewed-by: Manasi Navare
Manasi
On Fri, Feb 03, 2017 at 04:19:35PM +0200, Jani Nikula wrote:
> Localize link_rate_index to the if block, and rename to just index to
> reduce indent.
>
> Cc: Manasi Navare
> Cc: Ville Syrjälä
Hi Jani,
Thanks for this patch series. This definitely makes use
of lane count and link rate cleaner while handling the link failures.
I have tested these patches with compliance device along with my pending
DRM link-status patches and it does the fallback as expected.
It does not solve the proble
We're using non-canonical addresses in drm_mm, and we're making sure that
userspace is using canonical addressing - both in case of softpin
(verifying incoming offset) and when relocating (converting to canonical
when updating offset returned to userspace).
Unfortunately when considering the need f
On Thu, 2017-02-02 at 10:44 +0200, Jani Nikula wrote:
> On Wed, 01 Feb 2017, "Pandiyan, Dhinakaran"
> wrote:
> > On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> >> Rename the function, move it at the top, and reuse in
> >> intel_dp_link_rate_index(). If there was a reason in the past to u
From: Ville Syrjälä
Introduce intel_cdclk state which for now will track the cdclk
frequency, the vco frequency and the reference frequency (not sure we
want the last one, but I put it there anyway). We'll also make the
.get_cdclk() function fill out this state structure rather than
just returnin
From: Ville Syrjälä
Let's try to shrink intel_display.c a bit by moving the cdclk/rawclk
stuff to a new file. It's all reasonably self contained so we don't
even have to add that many non-static symbols.
We'll also take the opportunity to shuffle around the functions a bit
to get things in a mor
From: Ville Syrjälä
Let's clean up the mess we have in the if ladder that assigns the
.get_cdclk() hooks. The grouping of the platforms by the function
results in a thing that's not really legible, so let's do it the
other way around and order the if ladder by platform and duplicate
whatever assi
From: Ville Syrjälä
Rename the .get_display_clock_speed() hook to .get_cdclk().
.get_cdclk() is more specific (which clock) and it's much
shorter.
v2: Deal with IS_GEN9_BC()
v3: Deal with i945gm_get_display_clock_speed()
Signed-off-by: Ville Syrjälä
Reviewed-by: Ander Conselvan de Oliveira
Li
== Series Details ==
Series: drm/i915/guc: Make intel_guc_send a function pointer (rev2)
URL : https://patchwork.freedesktop.org/series/19024/
State : failure
== Summary ==
Series 19024v2 drm/i915/guc: Make intel_guc_send a function pointer
https://patchwork.freedesktop.org/api/1.0/series/1902
This allows us to be a little more flexible with how we use
igt_warn_on() and igt_warn_on_f() by allowing us to write statements
like this:
if (igt_warn_on(scary_condition)) {
/* some error handling... */
}
Signed-off-by: Lyude
---
lib/igt_core.h | 25 +++
On Wed, Feb 01, 2017 at 12:50:26AM +0100, Arthur Heymans wrote:
> This is according to Mobile Intel® 945 Express Chipset
> Family datasheet.
>
> Signed-off-by: Arthur Heymans
Reviewed-by: Ville Syrjälä
and pushed to dinq. Thanks for the patch.
> ---
> drivers/gpu/drm/i915/i915_reg.h |
On Tue, Feb 07, 2017 at 06:51:25PM +0100, Maarten Lankhorst wrote:
> Op 07-02-17 om 16:35 schreef Ville Syrjälä:
> > On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
> >> On 07/02/17 15:22, Uwe Kleine-König wrote:
> >>> Hello,
> >>>
> >>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
>
Op 07-02-17 om 16:35 schreef Ville Syrjälä:
> On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
>> On 07/02/17 15:22, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> Op
On 02/07/2017 09:25 AM, Chris Wilson wrote:
On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:
On 02/02/2017 11:33 PM, Chris Wilson wrote:
On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
From: Michal Wajdeczko
The GuC descriptor is big in size. If we use local defin
== Series Details ==
Series: series starting with [1/2] drm/fb-helper: Explain unload sequence a bit
better (rev3)
URL : https://patchwork.freedesktop.org/series/19242/
State : failure
== Summary ==
CC drivers/acpi/acpica/uterror.o
CC drivers/acpi/acpica/utglobal.o
CC dri
On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:
>
>
> On 02/02/2017 11:33 PM, Chris Wilson wrote:
> >On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
> >>From: Michal Wajdeczko
> >>
> >>The GuC descriptor is big in size. If we use local definition of
> >>guc_desc we have
== Series Details ==
Series: drm/i915: Restart all engines atomically
URL : https://patchwork.freedesktop.org/series/19249/
State : success
== Summary ==
Series 19249v1 drm/i915: Restart all engines atomically
https://patchwork.freedesktop.org/api/1.0/series/19249/revisions/1/mbox/
Test gem_e
On Tue, Feb 07, 2017 at 05:58:58PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > When we restart the engines, and we have active requests, a request on
> > the first engine may complete and queue a request to the second engine
> > before we try to restart the second engine. That queuei
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 require old-style
communication
Signed-off-by: Michel Thierry
Signed-off-b
On 02/02/2017 11:33 PM, Chris Wilson wrote:
On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
From: Michal Wajdeczko
The GuC descriptor is big in size. If we use local definition of
guc_desc we have a chance to overflow stack. Use allocated one.
v2: Rebased
v3: Split
v4: Handle E
== Series Details ==
Series: drm/i915: Restore context and pd for ringbuffer submission after reset
(rev3)
URL : https://patchwork.freedesktop.org/series/19110/
State : success
== Summary ==
Series 19110v3 drm/i915: Restore context and pd for ringbuffer submission after
reset
https://patchwo
On 02/03/2017 03:48 AM, Michal Wajdeczko wrote:
On Thu, Feb 02, 2017 at 07:42:46AM -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)
Signed-off-by: Mich
On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:31 PM, Jose Abreu wrote:
> > Hi Shashank,
> >
> >
> >
> > On 06-02-2017 13:59, Shashank Sharma wrote:
> > > This patch does following:
> > > - Adds a new structure (drm_hdmi_info) in d
== Series Details ==
Series: drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)
URL : https://patchwork.freedesktop.org/series/19240/
State : failure
== Summary ==
Series 19240v1 drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)
https://patchwork.freedesktop.org/api/1.0/series/19240/revis
On Tue, Feb 07, 2017 at 05:16:03PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
> v3: Actually remove rele
Regards
Shashank
On 2/7/2017 4:44 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
v3: Actually remove release_fbi (Sean, Emil, Chris) ...
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf
Regards
Shashank
On 2/7/2017 4:31 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, 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
Thanks for the review Jose, my comments inline.
Regards
Shashank
On 2/7/2017 4:24 PM, Jose Abreu wrote:
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, Shashank Sharma wrote:
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the so
On Tue, Feb 07, 2017 at 02:49:38PM +, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> > On 7 February 2017 at 14:29, Daniel Vetter wrote:
> > > Noticed that everyone duplicates the same logic here and we could safe
> > > a few lines per driver. Yay for lot
Regards
Shashank
On 2/7/2017 3:51 PM, Jani Nikula wrote:
On Mon, 06 Feb 2017, 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 footprin
Chris Wilson writes:
> When we restart the engines, and we have active requests, a request on
> the first engine may complete and queue a request to the second engine
> before we try to restart the second engine. That queueing of the
> request may itself cause the engine to restart, and so the su
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> Cc: Chris Wilson
> Cc: Sean Paul
> Cc: Noralf Trønnes
> Signed
Chris Wilson writes:
> Following a reset, the context and page directory registers are lost.
> However, the queue of requests that we resubmit after the reset may
> depend upon them - the registers are restored from a context image, but
> that restore may be inhibited and may simply be absent fro
When we restart the engines, and we have active requests, a request on
the first engine may complete and queue a request to the second engine
before we try to restart the second engine. That queueing of the
request may itself cause the engine to restart, and so the subsequent
handling by engine->in
On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS)
On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
> On 07/02/17 15:22, Uwe Kleine-König wrote:
> > Hello,
> >
> > On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
> >> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> >>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
> >
Chris Wilson writes:
> The predominant VMA class is normal GTT, so allow gcc to emphasize that
> path and avoid unnecessary stack movement.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 61
> +++--
>
Following a reset, the context and page directory registers are lost.
However, the queue of requests that we resubmit after the reset may
depend upon them - the registers are restored from a context image, but
that restore may be inhibited and may simply be absent from the request
if it was in the
SIGRTMAX appears to be used by valgrind now for its internal tracking,
so avoid it in the helpers.
Also add some valgrind annotations in gem_mmap, to make sure that its
accesses are tracked correctly.
Signed-off-by: Maarten Lankhorst
---
diff --git a/configure.ac b/configure.ac
index 5bdd744a075
On 07/02/17 15:22, Uwe Kleine-König wrote:
Hello,
On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
Op 31-01-17 om 0
On Tue, 07 Feb 2017, Jose Abreu wrote:
> Hi Jani,
>
>
> On 07-02-2017 13:35, Jani Nikula wrote:
>> On Tue, 07 Feb 2017, Jose Abreu wrote:
+bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
+{
+ u8 status;
+ int ret;
+
+ ret = drm_scdc_readb(adapte
On Tue, 07 Feb 2017, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote:
>> > On Tue, 07 Feb 2017, Joonas Lahtinen
>> > wrote:
>> >
>> > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
>> > >
>> > > On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
>
Hi Jani,
On 07-02-2017 13:35, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu wrote:
>>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>>> +{
>>> + u8 status;
>>> + int ret;
>>> +
>>> + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>>> + if (re
On Tue, 07 Feb 2017, Zhenyu Wang wrote:
> Hi,
>
> These are GVT-g changes for 4.11 merge window, mostly for gvt init
> order fix that impacted resource handling for device model, the one
> i915 change has been reviewed and acked.
>
> I can't find good tag on dinf for this now, so base on current d
"caps.buf" is always NULL here and "caps.size" is always zero. The code
is a no-op and can be removed.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..773a45aa18f8 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++
On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> On 7 February 2017 at 14:29, Daniel Vetter wrote:
> > Noticed that everyone duplicates the same logic here and we could safe
> > a few lines per driver. Yay for lots of drivers to make such tiny
> > refactors worth-while!
> >
> > v2:
On Tue, Feb 07, 2017 at 04:34:57PM +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> > If "caps.buf" is already NULL then it doesn't need to be freed or set to
> > NULL.
> >
> > Signed-off-by: Dan Carpenter
>
>
>
> > @@ -965,11 +965,8 @@ static long intel
On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote:
> > On Tue, 07 Feb 2017, Joonas Lahtinen
> > wrote:
> >
> > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
> > >
> > > On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
> > > >
> > > > On Mon, 06 Feb 2017, Joonas Lahtinen
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5220a7b5e6ff..074ab22a7cf3 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -781,7 +781,9 @@ EXPORT_SYMB
On Tue, Feb 07, 2017 at 04:24:25PM +0200, Joonas Lahtinen wrote:
> On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote:
> > @@ -2024,8 +2024,16 @@ void i915_gem_runtime_suspend(struct
> > drm_i915_private *dev_priv)
> > for (i = 0; i < dev_priv->num_fence_regs; i++) {
> > struct d
On ti, 2017-02-07 at 14:03 +, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote:
> >
> > "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> > We already have GENMASK for generating the mask, use it!
> >
> > Signed-off-by: Joonas Lahtinen
On 7 February 2017 at 14:29, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
Hmm afaict this patch inlines drm_fb_hel
On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> If "caps.buf" is already NULL then it doesn't need to be freed or set to
> NULL.
>
> Signed-off-by: Dan Carpenter
> @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
> unsigned int cmd,
>
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/d
On Tue, Feb 07, 2017 at 03:10:49PM +0100, Daniel Vetter wrote:
> While reviewing Chris' patches to properly cancel our async workers I
> checked that this happens after the fbdev is already unregistered.
> That's the case, but I found a small gap in our docs, fill that in.
>
> Note that I don't ex
== Series Details ==
Series: series starting with [1/2] drm: Cancel drm_fb_helper_dirty_work on
unload
URL : https://patchwork.freedesktop.org/series/19230/
State : failure
== Summary ==
Series 19230v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/19230/revision
On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote:
> The goal of the WARN was to catch when we are still actively using the
> fence as we go into the runtime suspend. However, the reg->pin_count is
> too coarse as it does not distinguish between exclusive ownership of the
> fence register from a
On ti, 2017-02-07 at 10:23 +, Chris Wilson wrote:
> After a brief discussion, we settled on a naming convention for the
> conditional GEM debugging data that should be clearer to the casual
> user: GEM_DEBUG
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen Cc: Tvrtko Ursulin
> Cc: Mika
While reviewing Chris' patches to properly cancel our async workers I
checked that this happens after the fbdev is already unregistered.
That's the case, but I found a small gap in our docs, fill that in.
Note that I don't explain what release_fbi does, because that function
will disappear in the
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
On Tue, Feb 07, 2017 at 12:49:56PM +, Chris Wilson wrote:
> We can not allow the worker to run after its fbdev, or even the module,
> has been removed.
>
> Fixes: cfe63423d9be ("drm/fb-helper: Add
> drm_fb_helper_set_suspend_unlocked()")
> Signed-off-by: Chris Wilson
> Cc: Noralf Trønnes
>
On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote:
> "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> We already have GENMASK for generating the mask, use it!
>
> Signed-off-by: Joonas Lahtinen
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_device_info.c
"BIT(max) - 1" will overflow when max = 32, and GCC will complain.
We already have GENMASK for generating the mask, use it!
Signed-off-by: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
drivers/gpu/drm/i915/
On Sat, 04 Feb 2017, Lyude wrote:
> This adds a file in i915's debugfs directory that allows userspace to
> manually control HPD storm detection. This is mainly for hotplugging
> tests, where we might want to test HPD storm functionality or disable
> storm detection to speed up hotplugging tests w
On Tue, 07 Feb 2017, Jose Abreu wrote:
>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>> +{
>> +u8 status;
>> +int ret;
>> +
>> +ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>> +if (ret < 0) {
>> +DRM_ERROR("Failed to read scram
On Tue, 07 Feb 2017, Joonas Lahtinen wrote:
> On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
>> On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
>> >
>> > On Mon, 06 Feb 2017, Joonas Lahtinen
>> > wrote:
>> > >
>> > > Convert all scripts to use /bin/sh shebang and fix all s
When doing a full atomic modeset, kernel should fail if the flag
DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of
'kms_plane_lowres' testset. The testcases are 'pipe-x-allow-modeset' where
x stands for pipe in question.
For: VIZ-6955
Signed-off-by: Mika Kahola
---
tests/
== Series Details ==
Series: GLK MIPI DSI VIDEO MODE PATCHES (rev4)
URL : https://patchwork.freedesktop.org/series/16542/
State : failure
== Summary ==
Series 16542v4 GLK MIPI DSI VIDEO MODE PATCHES
https://patchwork.freedesktop.org/api/1.0/series/16542/revisions/4/mbox/
Test drv_hangman:
Hello,
On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
>>> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
On Mon, Feb 06, 2017 at 10:34:31AM +0530, Kamble, Sagar A wrote:
>
>
> On 2/4/2017 7:40 PM, Arkadiusz Hiler wrote:
> > On Fri, Feb 03, 2017 at 01:58:33PM +0530, Sagar Arun Kamble wrote:
> > > HUC_STATUS, GUC_STATUS, SOFT_SCRATCH registers are read in debugfs
> > > and getparam ioctl. This patch c
If "caps.buf" is already NULL then it doesn't need to be freed or set to
NULL.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..de2a55178a37 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/g
We can not allow the worker to run after its fbdev, or even the module,
has been removed.
Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: Chris Wilson
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: dri-de...@lists.freedesk
We can not allow the worker to run after its fbdev, or even the module,
has been removed.
Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support")
Signed-off-by: Chris Wilson
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: dri-de...@lists.freedesktop.org
Cc: #
As per BSPEC, GLK supports MIPI DSI 8X clk only on PORT A.
Therefore only for PORT A PLL divider value should be validated.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
From: Deepak M
Register MIPI_CLOCK_CTRL is applicable only
for BXT platform. Future platform have other
registers to program the escape clock dividers.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 25 +++--
1 file changed
From: Deepak M
v2: Addressed Jani's Review comments(renamed bit field macros)
Txesc clock divider is calculated and programmed
for geminilake platform.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++
drivers/gpu/drm/i915/intel_dsi_pll.
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
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915
From: Deepak M
Dual link Z-inversion overlap field is present
in MIPI_CTRL register unlike the older platforms,
hence setting the same in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 17 +
1 file changed, 13 insertion
From: Deepak M
Program the clk lane and tlpx time count registers
to configure DSI PHY.
v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Program clk lane timing reg same as dphy param reg.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_r
From: Deepak M
For GEMINILAKE, dphy param reg values are programmed in terms
of HS byte clock count while for older platforms in terms of
HS ddr clk count.
v2: Added comments to clarify ddr clock count calculation
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915
From: Deepak M
PLL divider range for GLK is different than that of
BXT, hence adding the GLK range check in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_dsi_pll.c | 20 ++--
2 f
The patches in this list enable MIPI DSI video mode
support for GLK platform. Tesed locally.
v2: Renamed bitfields macros as per review comments(Jani)
v3: Code alignment/abstraction as per arch (Jani review comments)
v4: Fix DSI disable sequence, pll divider checks. Review comments(Jani)
Deepak M
1 - 100 of 129 matches
Mail list logo
