As noticed by Dan, there is useless (and incorrect) code in kvmgt trying
to kfree(NULL), though almost harmless. It was a copy-paste mistake and
should be removed.
Reported-by: Dan Carpenter
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 7 ---
1 file changed, 7 deletions(-
On ke, 2017-01-25 at 17:26 +, Chris Wilson wrote:
> Remove WaGsvDisableTurbo and WaRsUseTimeoutMode as these were only for
> pre-production Broxton devices, and this code is now defunct.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
On 01/26/2017 02:50 PM, Dan Carpenter wrote:
> Hello Jike Song,
>
> The patch 659643f7d814: "drm/i915/gvt/kvmgt: add vfio/mdev support to
> KVMGT" from Dec 8, 2016, leads to the following static checker
> warning:
>
> drivers/gpu/drm/i915/gvt/kvmgt.c:969 intel_vgpu_ioctl()
> warn: cal
Hello Jike Song,
The patch 659643f7d814: "drm/i915/gvt/kvmgt: add vfio/mdev support to
KVMGT" from Dec 8, 2016, leads to the following static checker
warning:
drivers/gpu/drm/i915/gvt/kvmgt.c:969 intel_vgpu_ioctl()
warn: calling kfree() when 'caps.buf' is always NULL.
drivers/gpu
Having converted the force_wake_get/_put routines for a vGPU to be no-op,
we can use the common mmio accessors and remove our specialised routines
that simply skipped the calls to control force_wake.
Signed-off-by: Weinan Li
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 58
For a virtualized GPU, the host maintains the forcewake state on the real
device. As we don't control forcewake ourselves, we can simply set
force_wake_get() and force_wake_put() to be no-ops. By setting the vfuncs,
we adjust both the manual control of forcewake and around the mmio
accessors (makin
I am not sure if native driver still need POSTING_READ action. But for guest we
can remove it directly.
Search the code, there are still upon 270 hints use POSTING_READ.
For guest OS, one frequent POSTING_READ_FW action is in irq handler, it will
impact the performance if there is heavy interrup
On 2017.01.25 12:49:48 +0200, Jani Nikula wrote:
> Side note, in the admin interface, please allow anyone subscribed to
> intel-gfx or dri-devel post to intel-gvt-dev without moderation. It's
> under Privacy options... | Sender filters | List of non-member addresses
> whose postings should be autom
I tested this patch in dinq on a KBL system and it fixed the bug. The
system doesn't crash on disconnecting or powering off the second monitor
in the DP-MST chain. I also replied to the Bugzilla issue.
Tested-by: Nathan D Ciobanu
On 12/05/2016 01:49 PM, Pierre-Louis Bossart wrote:
100% repro
On Wed, Jan 25, 2017 at 7:26 AM, Daniel Vetter wrote:
> Returning 0 for an on-chip gpu doesn't change anything at all.
>
> Cc: Patrik Jakobsson
> Signed-off-by: Daniel Vetter
Acked-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 6 --
> 1 file changed, 6 deletions(-)
>
>
I tested this on a KBL using 01-25-2017 dinq and it fixed the bug.
Tested-by: Nathan D Ciobanu
On 12/05/2016 01:49 PM, Pierre-Louis Bossart wrote:
100% reproducible issue found on SKL SkullCanyon NUC with two external
DP daisy-chained monitors in DP/MST mode. When turning off or changing
the
On 1/25/17 3:21 PM, Takashi Iwai wrote:
On Tue, 24 Jan 2017 23:57:48 +0100,
Jerome Anand wrote:
This patch series has only been tested on hardware with
a single HDMI connector/pipe and additional work may be needed for newer
machines with 2 connectors
BTW, I have such a machine, CHV with two
On 2017-01-25 12:59 AM, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:32PM -0800, Dhinakaran Pandiyan wrote:
>> It is necessary to track states for objects other than connector, crtc
>> and plane for atomic modesets. But adding objects like DP MST link
>> bandwidth to drm_atomic_state would
On Tue, 24 Jan 2017 23:57:48 +0100,
Jerome Anand wrote:
>
> This patch series has only been tested on hardware with
> a single HDMI connector/pipe and additional work may be needed for newer
> machines with 2 connectors
BTW, I have such a machine, CHV with two DP outputs.
If you have a test pat
On Tue, 24 Jan 2017 17:07:48 +0100,
Julia Lawall wrote:
>
> Remove unneeded variable used to store return value.
>
> Generated by: scripts/coccinelle/misc/returnvar.cocci
>
> CC: Jerome Anand
> Signed-off-by: Julia Lawall
> Signed-off-by: Fengguang Wu
> ---
>
> In-Reply-To: <20170124225753.9
On Wed, 2017-01-25 at 07:18 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:35PM -0800, Dhinakaran Pandiyan wrote:
> > Having a ->atomic_release callback is useful to release shared resources
> > that get allocated in compute_config().
> >
> > Suggested-by: Daniel Vetter
> > Signed-of
On Wed, 2017-01-25 at 07:15 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:37PM -0800, Dhinakaran Pandiyan wrote:
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> > enabled with drm_a
On Wed, 2017-01-25 at 07:16 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:36PM -0800, Dhinakaran Pandiyan wrote:
> > Implement the ->atomic_release() callback to release the shared link
> > bandwidth that was originally acquired during compute_config()
> >
> > Signed-off-by: Dhinakar
On Wed, 2017-01-25 at 06:59 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:32PM -0800, Dhinakaran Pandiyan wrote:
> > It is necessary to track states for objects other than connector, crtc
> > and plane for atomic modesets. But adding objects like DP MST link
> > bandwidth to drm_atomi
On Wed, Jan 25, 2017 at 12:13 PM, Linus Torvalds
wrote:
>
> Is nobody else seeing this? This is on my bog-standard intel laptop
> (Dell XPS13 as you can see in the warning).
Actually, it's on my desktop as well. So I'm assuming pretty much any
i915 config shows it. It's been introduced after rc5.
On Mon 14 Nov 2016, Chris Wilson wrote:
> Userspace is faced with a dilemma. The kernel requires implicit fencing
> to manage resource usage (we always must wait for the GPU to finish
> before releasing its PTE) and for third parties. However, userspace may
> wish to avoid this serialisation if it
On Wed, 2017-01-25 at 06:43 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:30PM -0800, Dhinakaran Pandiyan wrote:
> > The avail_slots member in the MST topology manager is never updated to
> > reflect the available vcpi slots. The check is effectively against
> > total_slots. So, let's
On Wed, 2017-01-25 at 10:31 +1000, Dave Airlie wrote:
> On 25 January 2017 at 09:49, Dhinakaran Pandiyan
> wrote:
> > drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
> > also finds if there are enough slots available. This check is a duplicate
> > of that implemented in drm_dp
> So the plan (again with Wolfram's ack) is for all these patches
> including the i2c-designware ones to go upstream through the drm-intel
> tree, to avoid an intermediate state were things don't work.
Yes. I'd just like to pull in an immutable branch into my i2c/for-next
once this series is acce
If I understand correctly, this patch preserves the kernel's current
implicit fencing, even when an input fence fd is given to execbuffer. I'm
convinced that's the right approach.
If userspace does want to disable the implicit fencing during an
execbuffer, then it should disable that explicit fenc
I didn't notice this until now, because my laptop still *works*, but
there seems to be a locking issue wth the drm connector list in the
i915 driver init path.
See appended call trace.
I don't know what part of the trace is supposed to get the mode_config
locks - maybe it's the generic drm kms he
On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
> Op 25-01-17 om 09:09 schreef Thomas Hellstrom:
> > On 01/25/2017 05:54 AM, Daniel Vetter wrote:
> >> On Tue, Jan 24, 2017 at 01:44:54PM -0800, Matt Roper wrote:
> >>> On Wed, Jan 11, 2017 at 05:15:47PM +0100, Daniel Vetter wrote:
On Wed, Jan 25, 2017 at 04:43:58PM +, mario.limoncie...@dell.com wrote:
> Thanks for your comments. Some nested below.
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Wednesday, January 25, 2017 9:57 AM
> > To: Limonciello, Mario
> >
2017-01-25 Daniel Vetter :
> On Wed, Jan 25, 2017 at 10:57:17AM -0200, Gustavo Padovan wrote:
> > Hi Daniel,
> >
> > 2017-01-25 Daniel Vetter :
> >
> > > There was a bit of mix-up between initialization and registering.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> No point in documenting these, they only confuse.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
> include/drm/drm_drv.h | 13 -
> 2 files
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> i915, nouveau (ever since merged to upstream) and radeon all lack ums
> support in upstream. No point keeping the ums vgaarb support around.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_irq.c | 2
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> Use the same trick we used for i915 when we still had ums support:
> Just initialize the agp support unconditionally in the driver load
> function.
>
> Unfortunately that means we need to export drm_agp_init again, but I
> think that's a less
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> With that the drm_pci_device_is_agp function becomes trivial, so
> inline that too. And while at it, move the drm_pci_agp_destroy
> declaration into drm-internal.h, since it's not used by drivers.
>
> Cc: Alex Deucher
> Cc: Ben Skeggs
> Sig
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> It's only for a device quirk, and we might as well do that in the load
> callback.
>
> Signed-off-by: Daniel Vetter
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/mga/mga_dma.c | 20 +++-
> drivers/gpu/drm/mga/mga_drv.c |
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> The function operates on modes, not CRTCs. Also move it into
> drm_modes.[hc]. Spotted while reviewing CRTC docs.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/
On Wed, Jan 25, 2017 at 09:13:44AM -0800, Rafael Antognolli wrote:
> Hi Mario, please see below...
>
> On Wed, Jan 25, 2017 at 04:43:58PM +, mario.limoncie...@dell.com wrote:
> > Thanks for your comments. Some nested below.
> >
> > > -Original Message-
> > > From: Ville Syrjälä [mail
Remove WaGsvDisableTurbo and WaRsUseTimeoutMode as these were only for
pre-production Broxton devices, and this code is now defunct.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_pm.c | 35 +++
1 file changed, 3
Hi Mario, please see below...
On Wed, Jan 25, 2017 at 04:43:58PM +, mario.limoncie...@dell.com wrote:
> Thanks for your comments. Some nested below.
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Wednesday, January 25, 2017 9:57 AM
>
Thanks for your comments. Some nested below.
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, January 25, 2017 9:57 AM
> To: Limonciello, Mario
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] DP Aux interfaces inquiry
>
On 24 January 2017 at 01:25, Robert Bragg wrote:
> There's a HW race condition between OA unit tail pointer register
> updates and writes to memory whereby the tail pointer can sometimes get
> ahead of what's been written out to the OA buffer so far (in terms of
> what's visible to the CPU).
>
> A
On Tue, Jan 24, 2017 at 07:51:28PM +, mario.limoncie...@dell.com wrote:
> Hi,
>
> Recently Synaptics collaborated with Dell on a plugin [1] for fwupd that
> allows flashing Synaptics MST hubs using the DP aux interface to manipulate
> the DPCD [2].
> Currently the plugin hardcodes the max nu
On 24 January 2017 at 01:25, Robert Bragg wrote:
> This avoids redundantly passing an (inout) head and tail pointer to
> gen7_append_oa_reports() from gen7_oa_read which doesn't need to
> reference either itself.
>
> Moving the head/tail reads and writes into gen7_append_oa_reports should
> have n
On 24 January 2017 at 01:25, Robert Bragg wrote:
> There's no need for the driver to keep reading back the head pointer
> from hardware since the hardware doesn't update it automatically. This
> way we can treat any invalid head pointer value as a software/driver
> bug instead of spurious hardware
On 24 January 2017 at 01:25, Robert Bragg wrote:
> If the function for checking whether there is OA buffer data available
> (during a poll or blocking read) has false positives then we want to
> avoid a situation where the subsequent read() returns EAGAIN (after
> a more accurate check) followed b
On 24 January 2017 at 01:25, Robert Bragg wrote:
> If I'm going to complain about a back-to-front convention then the least
> I can do is not muddle the comment up too.
>
> Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
___
Intel-gfx mailing lis
On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> > Hi Dave,
> >
> > Still waiting for your testing results on this one here ...
>
> It's definitely stable with that patch applied. No more crashes.
>
> But, it's also definitely having
On Wed, Jan 25, 2017 at 02:26:09PM +, Eric Engestrom wrote:
> On Wednesday, 2017-01-25 07:26:57 +0100, Daniel Vetter wrote:
> > After going through all the trouble of splitting out parts from
> > drm_crtc.[hc] and then properly documenting each I've entirely
> > forgotten to show the same TLC f
On Wed, Jan 25, 2017 at 10:57:17AM -0200, Gustavo Padovan wrote:
> Hi Daniel,
>
> 2017-01-25 Daniel Vetter :
>
> > There was a bit of mix-up between initialization and registering.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_connector.c | 9 -
> > 1 file change
On Tue, Jan 24, 2017 at 09:20:49PM -0800, Ben Widawsky wrote:
> Originally based off of a patch by Kristian.
>
> This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
> about the modifiers that will work with each format.
>
> It's modified from Kristian's patch in that the modi
On Wed, Jan 25, 2017 at 10:55:21AM -0200, Gustavo Padovan wrote:
> Otherwise looks good:
Fixed up all and applied
> Reviewed-by: Gustavo Padovan
and thanks for your review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> Hi Dave,
>
> Still waiting for your testing results on this one here ...
It's definitely stable with that patch applied. No more crashes.
But, it's also definitely having difficulty re-probing to find the
monitor that's attached to the dock in some
On Wed, Jan 25, 2017 at 10:48:53AM -0200, Gustavo Padovan wrote:
> Otherwise looks good to me:
Nice catches, fixed them all and applied it.
>
> Rewiewed-by: Gustavo Padovan
Thanks for your review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
On Wed, 25 Jan 2017 15:45:05 +0100,
Jani Nikula wrote:
>
> On Wed, 25 Jan 2017, Takashi Iwai wrote:
> > On Tue, 24 Jan 2017 23:57:48 +0100,
> > Jerome Anand wrote:
> >>
> >> Legacy (CherryTrail/ Baytrail) HDMI audio drivers added
> >> Legacy hdmi audio-Gfx interaction/ interfacing is updated to
== Series Details ==
Series: drm/i915: Add MIPI_IO WA and program DSI regulators (rev2)
URL : https://patchwork.freedesktop.org/series/18223/
State : success
== Summary ==
Series 18223v2 drm/i915: Add MIPI_IO WA and program DSI regulators
https://patchwork.freedesktop.org/api/1.0/series/18223/
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Check we can create and execution within a context.
>
> Signed-off-by: Chris Wilson
> +static struct i915_vma *
> +gpu_fill_pages(struct i915_vma *vma, u64 offset, unsigned long count, u32
> value)
> +{
It smells like goto err; in this
On Wed, 25 Jan 2017, Takashi Iwai wrote:
> On Tue, 24 Jan 2017 23:57:48 +0100,
> Jerome Anand wrote:
>>
>> Legacy (CherryTrail/ Baytrail) HDMI audio drivers added
>> Legacy hdmi audio-Gfx interaction/ interfacing is updated to use
>> irq chip framework
>>
>> This patch series has only been test
On Wednesday, 2017-01-25 07:26:57 +0100, Daniel Vetter wrote:
> After going through all the trouble of splitting out parts from
> drm_crtc.[hc] and then properly documenting each I've entirely
> forgotten to show the same TLC for CRTCs themselves!
>
> Let's make amends asap.
>
> Signed-off-by: Da
== Series Details ==
Series: series starting with [1/2] drm/i915: Report the failure to write to the
punit
URL : https://patchwork.freedesktop.org/series/18549/
State : warning
== Summary ==
Series 18549v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/18549/revi
From: Uma Shankar
Enable MIPI IO WA for BXT DSI as per bspec and
program the DSI regulators.
v2: Moved IO enable to pre-enable as per Mika's
review comments. Also reused the existing register
definition for BXT_P_CR_GT_DISP_PWRON.
v3: Added Programming the DSI regulators as per disable/enable
s
On Wed, Jan 25, 2017 at 09:44:52PM +0800, Weinan Li wrote:
Having converted the force_wake_get/_put routines for a vGPU to be
no-op, we can use the common mmio accessors and remove our specialised
routines that simply skipped the calls to control force_wake.
> Signed-off-by: Weinan Li
Reviewed-b
On Wed, Jan 25, 2017 at 09:44:51PM +0800, Weinan Li wrote:
> Host maintian the hardware's forcewake state, guest don't need and also
> can't control it. Although vgpu_read/write bypass forcewake_get/put in MMIO
> read/write, but still have separate path called by
> "intel_uncore_forcewake_get/put"
On Tue, Jan 24, 2017 at 02:29:00PM +0200, David Weinehall wrote:
> On Fri, Jan 20, 2017 at 08:21:55PM +0200, ville.syrj...@linux.intel.com wrote:
> > 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
On Wednesday, 2017-01-25 07:26:45 +0100, Daniel Vetter wrote:
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to
On Tue, 24 Jan 2017 23:57:48 +0100,
Jerome Anand wrote:
>
> Legacy (CherryTrail/ Baytrail) HDMI audio drivers added
> Legacy hdmi audio-Gfx interaction/ interfacing is updated to use
> irq chip framework
>
> This patch series has only been tested on hardware with
> a single HDMI connector/pipe
Signed-off-by: Weinan Li
---
drivers/gpu/drm/i915/intel_uncore.c | 58 -
1 file changed, 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 9fad4de..e9046fa 100644
--- a/drivers/gpu/drm/i915/intel_unco
Host maintian the hardware's forcewake state, guest don't need and also
can't control it. Although vgpu_read/write bypass forcewake_get/put in MMIO
read/write, but still have separate path called by
"intel_uncore_forcewake_get/put" and
"intel_uncore_forcewake_get/put__locked". Unnecessary MMIO acce
>-Original Message-
>From: Nikula, Jani
>Sent: Thursday, January 19, 2017 4:34 PM
>To: Srinivas, Vidya ; intel-
>g...@lists.freedesktop.org
>Cc: Shankar, Uma ; Syrjala, Ville
>
>Subject: Re: [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators
>
>On Thu, 19 Jan 2017, Vidya Srinivas
As the previous punit i/o may have failed, the contents of the PDATA are
undefined. Always clear it to 0 prior to sending the command.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_sideband.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/d
The write to the punit may fail, so propagate the error code back to its
callers. Of particular interest are the RPS writes, so add appropriate
user error codes and logging.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 --
drivers/gpu/drm/i915
Chris Wilson writes:
> On Wed, Jan 25, 2017 at 03:09:04PM +0200, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > On Wed, Jan 25, 2017 at 02:31:08PM +0200, Mika Kuoppala wrote:
>> >> Certain Baytrails, namely the 4 cpu core variants, have been
>> >> plaqued by spurious system hangs, mostly
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> i915_gem_gtt_insert should allocate from the available free space in the
> GTT, evicting as necessary to create space.
>
> Signed-off-by: Chris Wilson
> + list_add(&obj->batch_pool_link, &objects);
Still dislike the obscurity
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> i915_gem_gtt_reserve should put the node exactly as requested in the
> GTT, evicting as required.
>
> Signed-off-by: Chris Wilson
I might de-magic 2*I915_GTT_PAGE_SIZE and couple of expect helpers, but
regardless;
Reviewed-by: Joonas Lahti
== Series Details ==
Series: drm/i915/byt: Avoid tweaking evaluation thresholds
URL : https://patchwork.freedesktop.org/series/18543/
State : success
== Summary ==
Series 18543v1 drm/i915/byt: Avoid tweaking evaluation thresholds
https://patchwork.freedesktop.org/api/1.0/series/18543/revisions
On Wed, Jan 25, 2017 at 03:09:04PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Wed, Jan 25, 2017 at 02:31:08PM +0200, Mika Kuoppala wrote:
> >> Certain Baytrails, namely the 4 cpu core variants, have been
> >> plaqued by spurious system hangs, mostly occurring with light loads.
>
Chris Wilson writes:
> On Wed, Jan 25, 2017 at 02:31:08PM +0200, Mika Kuoppala wrote:
>> Certain Baytrails, namely the 4 cpu core variants, have been
>> plaqued by spurious system hangs, mostly occurring with light loads.
>>
>> Multiple bisects by various people point to a commit which changes t
Hi Daniel,
2017-01-25 Daniel Vetter :
> Returning 0 for an on-chip gpu doesn't change anything at all.
>
> Cc: Patrik Jakobsson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 6 --
> 1 file changed, 6 deletions(-)
Reviewed-by: Gustavo Padovan
Hi Daniel,
2017-01-25 Daniel Vetter :
> There was a bit of mix-up between initialization and registering.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_connector.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c
Hi,
we've got a bug report about the blank monitor on Cherry Trail
machines. And, Intel team (Cc'ed) spotted out that this seems
triggered by DPMS transition. A patch like below actually fixes the
problem.
Of course it doesn't look like a right "fix". Do you guys have any
hint for further debu
Hi Daniel,
2017-01-25 Daniel Vetter :
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to be long).
>
> Also s
Hi Daniel,
2017-01-25 Daniel Vetter :
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to be long).
>
> Also s
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_plane.c | 94 ++---
> --
> 1 file changed, 52 insertions(+), 42
Hi Daniel,
2017-01-25 Daniel Vetter :
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to be long).
>
> Also s
On Wed, Jan 25, 2017 at 02:31:08PM +0200, Mika Kuoppala wrote:
> Certain Baytrails, namely the 4 cpu core variants, have been
> plaqued by spurious system hangs, mostly occurring with light loads.
>
> Multiple bisects by various people point to a commit which changes the
> reclocking strategy for
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_pipe_color.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -
On Wed, Jan 25, 2017 at 03:03:42PM +0530, Archit Taneja wrote:
>
>
> On 01/25/2017 11:56 AM, Daniel Vetter wrote:
> > I just learned that &struct_name.member_name works and looks pretty
> > even. It doesn't (yet) link to the member directly though, which would
> > be really good for big structure
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_panel_fitting.c | 16
> 1 file changed, 8 insertions(+), 8 deletion
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, January 25, 2017 3:17 PM
> To: Li, Weinan Z
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: ignore forcewake get/put
>
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_mmio_vs_cs_flip.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_mmap_write_crc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
Certain Baytrails, namely the 4 cpu core variants, have been
plaqued by spurious system hangs, mostly occurring with light loads.
Multiple bisects by various people point to a commit which changes the
reclocking strategy for Baytrail to follow its bigger brethen:
commit 8fb55197e64d ("drm/i915: Ag
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_legacy_colorkey.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> di
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_fence_pin_leak.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_flip_event_leak.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_fbc_crc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/tests/kms_fbc_crc.
Am Sonntag, 22. Januar 2017, 13:32:08 CET schrieb Linus Torvalds:
> Things seem to be calming down a bit, and everything looks nominal.
>
> There's only been about 250 changes (not counting merges) in the last
> week, and the diffstat touches less than 300 files (with drivers and
> architecture up
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Some pieces of code are independent of hardware but are very tricky to
> exercise through the normal userspace ABI or via debugfs hooks. Being
> able to create mock unit tests and execute them through CI is vital.
> Start by adding a central p
* Jani Nikula wrote:
> On Wed, 25 Jan 2017, Jani Nikula wrote:
> > On Wed, 25 Jan 2017, Ingo Molnar wrote:
> >> * Paulo Zanoni wrote:
> >>
> >>> So don't forget to reserve its stolen memory bits.
> >>>
> >>> Cc: Ingo Molnar
> >>> Cc: H. Peter Anvin
> >>> Cc: Ander Conselvan de Oliveira
>
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_chv_cursor_fail.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_crtc_background_color.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Reviewed-by: Mika Kahola
On Tue, 2017-01-24 at 18:33 -0500, Robert Foss wrote:
> Add changes reflecting the new support for dynamic number of planes
> per pipe.
>
> Signed-off-by: Robert Foss
> ---
> tests/kms_cursor_crc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
1 - 100 of 124 matches
Mail list logo
