On Wed, Aug 26, 2015 at 08:49:00AM +0200, Thomas Hellstrom wrote:
> Hi, Tiago.
>
> On 08/26/2015 02:02 AM, Tiago Vignatti wrote:
> > From: Daniel Vetter
> >
> > The userspace might need some sort of cache coherency management e.g. when
> > CPU
> > and GPU domains are being accessed through dma-b
On 08/26/2015 05:04 PM, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
On 08/26/2015 10:42 AM, Archit Taneja wrote:
On 08/25/2015 07:15 PM, Daniel Vetter wrote:
Faster than recompiling.
Note that restore_fbdev_mode_unlocked is a bit special and the o
On Tue, Aug 25, 2015 at 01:48:13AM +, Yang, Libin wrote:
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, August 25, 2015 12:27 AM
> > To: Yang, Libin
> > Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> > g...@lists.fre
On 08/26/2015 02:10 PM, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 08:49:00AM +0200, Thomas Hellstrom wrote:
>> Hi, Tiago.
>>
>> On 08/26/2015 02:02 AM, Tiago Vignatti wrote:
>>> From: Daniel Vetter
>>>
>>> The userspace might need some sort of cache coherency management e.g. when
>>> CPU
>>>
On 08/26/2015 05:07 PM, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
On 08/26/2015 10:42 AM, Archit Taneja wrote:
On 08/25/2015 07:15 PM, Daniel Vetter wrote:
Faster than recompiling.
Queued for -next to resolve conflicts in another series, thanks for the patch.
-Daniel
On Fri, Jul 10, 2015 at 06:03:39PM +0530, Sivakumar Thulasimani wrote:
> Reviewed-by: Sivakumar Thulasimani
>
>
>
> On 6/29/2015 5:55 PM, ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä
> >
> >B
On Wed, Aug 19, 2015 at 02:29:37PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote:
> >
> >
> > On 07/09/2015 02:15 AM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Normmally the common lane in a PHY channel gets powered up when
On Wed, Aug 19, 2015 at 04:39:41PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 19, 2015 at 06:52:57PM +0530, Deepak wrote:
> >
> >
> > On 07/09/2015 02:15 AM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > We can choose to leave the display PHY CL2 powerdown up to some
On Thu, 2015-08-20 at 18:11 -0700, Matt Roper wrote:
> Just pull the info out of the plane state structure rather than staging
> it in an additional structure.
>
> Signed-off-by: Matt Roper
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/intel_pm.c | 133
> +
On Thu, 2015-08-20 at 18:11 -0700, Matt Roper wrote:
> Just pull the info out of the CRTC state structure rather than staging
> it in an additional structure.
>
> Signed-off-by: Matt Roper
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/intel_pm.c | 84
> ++-
On Wed, Aug 26, 2015 at 05:59:14PM +0530, Archit Taneja wrote:
>
>
> On 08/26/2015 05:07 PM, Daniel Vetter wrote:
> >On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote:
> >>On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
> >>>
> >>>
> >>>On 08/26/2015 10:42 AM, Archit Ta
On Wed, Aug 26, 2015 at 02:28:30PM +0200, Thomas Hellstrom wrote:
> On 08/26/2015 02:10 PM, Daniel Vetter wrote:
> > On Wed, Aug 26, 2015 at 08:49:00AM +0200, Thomas Hellstrom wrote:
> >> Hi, Tiago.
> >>
> >> On 08/26/2015 02:02 AM, Tiago Vignatti wrote:
> >>> From: Daniel Vetter
> >>>
> >>> The u
On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote:
> As we mark the preallocated objects as bound, we should also flag them
> correctly as being map-and-fenceable (if appropriate!) so that latter
> users do not get confused and try and rebind the pinned vma in order to
> get a map-and-fe
On Wed, Aug 26, 2015 at 03:06:59PM +0200, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote:
> > As we mark the preallocated objects as bound, we should also flag them
> > correctly as being map-and-fenceable (if appropriate!) so that latter
> > users do not get co
On Wed, Aug 26, 2015 at 01:36:05AM +0530, Animesh Manna wrote:
> Dmc will restore the csr program except DC9, cold boot,
> warm reset, PCI function level reset, and hibernate/suspend.
>
> intel_csr_load_program() function is used to load the firmware
> data from kernel memory to csr address space.
On Thu, Aug 20, 2015 at 06:11:59PM -0700, Matt Roper wrote:
> Since we allocate a few CRTC states on the stack, also switch the 'wm'
> struct here to be a union so that we're not wasting stack space with
> other platforms' watermark values.
>
I don't like this patch. The locking rules (once we ha
On Wed, Aug 26, 2015 at 01:36:08AM +0530, Animesh Manna wrote:
> While display engine entering into low power state no need to disable
> cdclk pll as CSR firmware of dmc will take care. If pll is already
> enabled firmware execution sequence will be blocked. This is one
> of the criteria for dmc to
On Tue, Aug 25, 2015 at 07:03:41PM -0300, Paulo Zanoni wrote:
> Dear git bisect user,
>
> Even though this is the patch that introduced the WARN() you're
> bisecting, please notice that it's very likely that the problem you're
> facing was already present before this commit. In other words: this
>
On Wed, Aug 26, 2015 at 09:29:56AM +0200, Maarten Lankhorst wrote:
> This partially reverts commit 74c090b1bdc57b1c9f1361908cca5a3d8a80fb08.
>
> The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async
> support.
>
> Signed-off-by: Maarten Lankhorst
Queued for -next, thanks for the
Joonas Lahtinen writes:
> Hi,
>
> Added Michel and Dave as CC too, to notice this, as they are specified
> in the patch as CC.
>
> On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
>> This is based on Mika Kuoppala's patch below:
>> http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.i
On Wed, Aug 26, 2015 at 7:33 AM, Jani Nikula wrote:
> Cc: Thierry Reding
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> include/drm/drm_dp_helper.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> inde
On Thu, 2015-08-20 at 18:11 -0700, Matt Roper wrote:
> A bunch of SKL watermark-related structures have the cursor plane as a
> separate entry from the rest of the planes. If we just extend the
> relevant plane arrays by one entry and use the top-most array element as
> the cursor, it will simplif
On Wed, Aug 26, 2015 at 12:45:32PM +, Conselvan De Oliveira, Ander wrote:
> On Thu, 2015-08-20 at 18:11 -0700, Matt Roper wrote:
> > Just pull the info out of the plane state structure rather than staging
> > it in an additional structure.
> >
> > Signed-off-by: Matt Roper
>
> Reviewed-by: A
On Tue, Aug 25, 2015 at 11:12 PM, Mike Frysinger wrote:
> On 24 Aug 2015 14:42, Patrik Jakobsson wrote:
>> We need to be able to store private data in the tcb across it's
>> lifetime. To ensure proper destruction of the data a free_priv_data
>> callback must be provided if an allocation is stored
On Thu, Aug 20, 2015 at 06:11:53PM -0700, Matt Roper wrote:
> Just pull the info out of the CRTC state structure rather than staging
> it in an additional structure.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 84
> ++---
> 1 file
On Wed, Aug 26, 2015 at 03:06:59PM +0200, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote:
> > As we mark the preallocated objects as bound, we should also flag them
> > correctly as being map-and-fenceable (if appropriate!) so that latter
> > users do not get co
With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.
Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set
On 8/26/2015 6:40 PM, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 01:36:05AM +0530, Animesh Manna wrote:
Dmc will restore the csr program except DC9, cold boot,
warm reset, PCI function level reset, and hibernate/suspend.
intel_csr_load_program() function is used to load the firmware
data fr
On Aug 26 2015 or thereabouts, Sivakumar Thulasimani wrote:
>
>
> On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:
> >On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:
> >>On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
> >> wrote:
> >>>On Jul 30 2015 or thereabouts, Sivakumar Thulasima
On 8/26/2015 6:41 PM, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 01:36:08AM +0530, Animesh Manna wrote:
While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked
On 08/26/2015 09:58 AM, Daniel Vetter wrote:
The other is that right now there's no user nor implementation in sight
which actually does range-based flush optimizations, so I'm pretty much
expecting we'll get it wrong. Maybe instead we should go one step further
and remove the range from the inte
On Wed, Aug 05, 2015 at 12:45:48PM +0200, Maarten Lankhorst wrote:
> From: Patrik Jakobsson
>
> When reading out hw state for planes we disable inactive planes which in
> turn triggers an update of the watermarks. The update depends on the
> crtc_clock being set which is done when reading out enc
On Wed, Aug 26, 2015 at 11:32:30AM -0300, Tiago Vignatti wrote:
> On 08/26/2015 09:58 AM, Daniel Vetter wrote:
> >The other is that right now there's no user nor implementation in sight
> >which actually does range-based flush optimizations, so I'm pretty much
> >expecting we'll get it wrong. Maybe
On 08/26/2015 04:32 PM, Tiago Vignatti wrote:
> On 08/26/2015 09:58 AM, Daniel Vetter wrote:
>> The other is that right now there's no user nor implementation in sight
>> which actually does range-based flush optimizations, so I'm pretty much
>> expecting we'll get it wrong. Maybe instead we should
On 08/26/2015 11:51 AM, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 11:32:30AM -0300, Tiago Vignatti wrote:
On 08/26/2015 09:58 AM, Daniel Vetter wrote:
The other is that right now there's no user nor implementation in sight
which actually does range-based flush optimizations, so I'm pretty mu
Speeds up testcases except for those where we want to exercise the
probing itself.
Note this blew up and I ragequit after a few more regressions
uncovered in a chain, so this isn't all that well-tested really :(
Signed-off-by: Daniel Vetter
---
configure.ac | 2 +-
lib/igt_
Hello,
current drm-intel-nightly git fails to run OpenGL games with an
intel_do_flush_locked failed: Invalid argument
error message.
dmesg shows:
[ 2993.516697] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter
i915 gmbus dpb
[ 2993.516884] [drm:drm_helper_probe_single_connect
On Wed, Aug 26, 2015 at 10:05:00AM +, Jindal, Sonika wrote:
> HPD bits control the interrupt but the live status (with some monitors) takes
> time to get set.
> We had experienced this with VLV and CHV with few monitors.
> So Android code always has this retry for live status.
>
> Yes, this w
On 8/20/2015 1:17 PM, Jani Nikula wrote:
Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.
v2: make the function return a boolean
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 41 +
Chris Wilson writes:
> Delay the expensive read on the FPGA_DBG register from once per mmio to
> once per forcewake section when we are doing the general wellbeing
> check rather than the targetted error detection. This almost reduces
> the overhead of the debug facility (for example when submitt
> 26 aug 2015 kl. 16:58 skrev Tiago Vignatti :
>
>> On 08/26/2015 11:51 AM, Daniel Vetter wrote:
>>> On Wed, Aug 26, 2015 at 11:32:30AM -0300, Tiago Vignatti wrote:
On 08/26/2015 09:58 AM, Daniel Vetter wrote:
The other is that right now there's no user nor implementation in sight
>>
On Wed, Aug 26, 2015 at 04:39:12PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 20, 2015 at 06:11:53PM -0700, Matt Roper wrote:
> > Just pull the info out of the CRTC state structure rather than staging
> > it in an additional structure.
> >
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm
Very strictly speaking this is possible if you have special hw and
genlocked CRTCs. In general switching a plane between two active CRTC
just won't work so well and is probably not tested at all. Just forbid
it.
I've put this into the core since I really couldn't come up with a
case where we don't
On Wed, Aug 26, 2015 at 06:27:36PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Delay the expensive read on the FPGA_DBG register from once per mmio to
> > once per forcewake section when we are doing the general wellbeing
> > check rather than the targetted error detection. This almo
On Wed, Aug 26, 2015 at 08:37:41AM -0700, Matt Roper wrote:
> On Wed, Aug 26, 2015 at 04:39:12PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 20, 2015 at 06:11:53PM -0700, Matt Roper wrote:
> > > Just pull the info out of the CRTC state structure rather than staging
> > > it in an additional structu
On Wed, Aug 26, 2015 at 05:41:23PM +0200, Daniel Vetter wrote:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
>
> I've put th
On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter wrote:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
So, I expect msm shoul
On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter
> wrote:
>> Very strictly speaking this is possible if you have special hw and
>> genlocked CRTCs. In general switching a plane between two active CRTC
>> just won't work so well and is probably
On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter
> > wrote:
> >> Very strictly speaking this is possible if you have special hw and
> >> genlocked CRTCs. In general switching a plan
On Wed, 2015-08-26 at 18:53 +0300, Ville Syrjälä wrote:
> On Wed, Aug 26, 2015 at 05:41:23PM +0200, Daniel Vetter wrote:
> > Very strictly speaking this is possible if you have special hw and
> > genlocked CRTCs. In general switching a plane between two active
> > CRTC
> > just won't work so well a
On Wed, 2015-08-26 at 11:15 +0300, Jani Nikula wrote:
> On Thu, 13 Aug 2015, "Jindal, Sonika"
> wrote:
> > On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote:
> > > > On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
> > > > > > On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
> > > > > >
From: Ville Syrjälä
Make the code mode readable by pulling the "does this crtc have any
encoders?" deduction into a separate function.
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 +-
1 file changed, 13 insertions(+), 9 d
From: Ville Syrjälä
The BIOS sometimes likes to enable pipes w/o any ports, at least on
older machines. Currently we fail to assign anything sensible to
crtc->hwmode.crtc_clock which leads to complaints from the vblank code.
Deal with active pipes w/o ports and assign something sensible to
crtc_c
On Wed, 2015-08-26 at 11:06 +0200, Daniel Vetter wrote:
> On Thu, Aug 20, 2015 at 04:12:00PM -0700, Rodrigo Vivi wrote:
> > From: Rodrigo Vivi
> >
> > Let's use a native read with retry as suggested per spec to
> > fix Sink CRC on SKL when PSR is enabled.
> >
> > With PSR enabled panel is probab
Attach the some introduction to help the discussion:
[ Current Implementation - Performance Oriented ! ]
Guest create Guest submits
a new context its context
+
Forgot to do that in
commit d328c9d78d64ca11e744fe227096990430a88477
Author: Daniel Vetter
Date: Fri Apr 10 16:22:37 2015 +0200
drm/i915: Select starting pipe bpp irrespective or the primary plane
and it's confusing. Fix it.
Cc: Jesse Barnes
Signed-off-by: Daniel Vetter
---
drivers/gp
On Wed, Aug 26, 2015 at 12:30 PM, Ville Syrjälä
wrote:
> On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
>> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
>> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter
>> > wrote:
>> >> Very strictly speaking this is possible if you have sp
On Wed, Aug 26, 2015 at 01:38:36PM -0400, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 12:30 PM, Ville Syrjälä
> wrote:
> > On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
> >> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
> >> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter
> >
On Wed, Aug 26, 2015 at 1:53 PM, Ville Syrjälä
wrote:
> On Wed, Aug 26, 2015 at 01:38:36PM -0400, Rob Clark wrote:
>> On Wed, Aug 26, 2015 at 12:30 PM, Ville Syrjälä
>> wrote:
>> > On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
>> >> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
On Tue, Aug 25, 2015 at 09:33:41PM -0700, Hindman, Gavin wrote:
> Does this series comprehend all of the ddr-dvfs/PM-5 watermark reworks that
> Ville did towards the end of CHV, or is this series additive to that?
Are you referring to the series
[PATCH 00/10] drm/i915: Another WM rewrite to
2015-08-17 16:51 GMT-03:00 Paulo Zanoni :
> 2015-08-12 12:44 GMT-03:00 :
>> From: Ville Syrjälä
>>
>> Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space
>> vs. tab issues.
>>
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 72
>> +
2015-08-17 17:06 GMT-03:00 Paulo Zanoni :
> 2015-08-12 12:44 GMT-03:00 :
>> From: Ville Syrjälä
>>
>> Eliminate a bunch of duplicated code that calculates the currently
>> enabled HPD interrupt bits.
>
> Nice one! I see this one also depends on a patch that's not merged
> yet, so I'm not sure if
On 2015-08-26 10:33, Daniel Vetter wrote:
On Wed, Aug 19, 2015 at 10:48:55AM +0200, David Henningsson wrote:
This callback will be called by the i915 driver to notify the hda
driver that its HDMI information needs to be refreshed, i e,
that audio output is now available (or unavailable) - usua
2015-08-12 12:44 GMT-03:00 :
> From: Ville Syrjälä
>
> Extract the core of ironlake_{enable,disable}_display_irq() into a new
> function. We'll have further use for it later.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 39 ---
>
2015-08-12 12:44 GMT-03:00 :
> From: Ville Syrjälä
>
> Make LPT:LP checks look neater by wrapping the details in a
> new HAS_PCH_LPT_LP() macro.
This has the potential to be confusing since HAS_PCH_LPT() is also
true for cases where HAS_PCH_LPT_LP() is true. Maybe we could rename
the macro in so
2015-08-12 12:44 GMT-03:00 :
> From: Ville Syrjälä
>
> The PORTA HPD defines are not BXT specific. They also exist on SPT,
> and partially already on LPT:LP.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 10 +-
> 2
On Wed, Aug 26, 2015 at 04:13:52PM -0300, Paulo Zanoni wrote:
> 2015-08-12 12:44 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > The PORTA HPD defines are not BXT specific. They also exist on SPT,
> > and partially already on LPT:LP.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/
Very strictly speaking this is possible if you have special hw and
genlocked CRTCs. In general switching a plane between two active CRTC
just won't work so well and is probably not tested at all. Just forbid
it.
I've put this into the core since right now no helper or driver copes
with it, no user
On 08/26/2015 12:58 AM, Jani Nikula wrote:
Normally we determine the backlight PWM modulation frequency (which we
also use as backlight max value) from the backlight registers at module
load time, expecting the registers have been initialized by the BIOS. If
this is not the case, we fail.
The VB
On 08/26/2015 12:58 AM, Jani Nikula wrote:
Make it available outside of intel_dp.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 33 +
drivers/gpu/drm/i915/intel_dp.c | 34 --
drivers/gpu/drm/i915/
On 08/26/2015 12:58 AM, Jani Nikula wrote:
This is a rebase of [1] and originally [2]. I haven't tried this in a
year and I have no idea if it works on SKL, and it's not implemented for
BXT. However there's renewed interest, so here's the rebase.
Renewed interest as an ODM has been reporting th
2015-08-12 12:44 GMT-03:00 :
> From: Ville Syrjälä
>
> Starting from SPT the only interrupts living in the south are GMBUS and
> HPD. What's worse some of the SPT specific new bits conflict with some
> other bits on earlier PCH generations. So better not use the
> cpt_irq_handler() for SPT+ anymo
On Wed, Aug 26, 2015 at 3:49 PM, Daniel Vetter wrote:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
>
> I've put this into t
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> On Wed, Aug 26, 2015 at 04:13:52PM -0300, Paulo Zanoni wrote:
...
>> Although the doc for LPT _suggests_ this is only for LPT:LP, it
>> doesn't mark this bit as LPT:LP-specific just like it marks all the
>> other LPT:LP-specific bits i
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, August 26, 2015 1:40 AM
> To: Konduru, Chandra
> Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel; Syrjala, Ville
> Subject: Re: [Intel-gfx] [PATCH 08/15] drm/i915:
> > -static char intel_get_stepping(struct drm_device *dev)
> > +char intel_get_stepping(struct drm_device *dev)
>
> I guess we should have a new home for this now that it's used outside of
> intel_csr.c Plus kerneldoc, as usual.
Will add kerneldoc header and respun, but where do you want to move
> > +static void test_nv12_invalid_fb_params(data_t *d)
> > +{
> > + igt_display_t *display = &d->display;
> > + igt_output_t *output;
> > + enum pipe pipe;
> > + int valid_tests = 0;
> > +
> > + igt_require(d->display.has_universal_planes);
> > + igt_require(d->num_scalers);
> > +
> >
Hi Daniel,
On Wed, Aug 26, 2015 at 10:56:00AM +0200, Daniel Vetter wrote:
> On Tue, Aug 25, 2015 at 08:17:05AM +0800, Zhiyuan Lv wrote:
> > Hi Chris,
> >
> > On Mon, Aug 24, 2015 at 11:23:13AM +0100, Chris Wilson wrote:
> > > On Mon, Aug 24, 2015 at 06:04:28PM +0800, Zhiyuan Lv wrote:
> > > > Hi
Hi Ville,
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, August 26, 2015 8:27 PM
> To: Yang, Libin
> Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> jani.nik...@linux.intel.
Hi Danie,
On Wed, Aug 26, 2015 at 10:47:37AM +0200, Daniel Vetter wrote:
> On Thu, Aug 20, 2015 at 01:57:13PM +0300, Joonas Lahtinen wrote:
> > On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> > > The full ppgtt is supported in Intel GVT-g device model. So the
> > > restriction can be removed
> On Wed, 2015-08-26 at 11:15 +0300, Jani Nikula wrote:
> > On Thu, 13 Aug 2015, "Jindal, Sonika"
> > wrote:
> > > On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote:
> > > > > On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
> > > > > > > On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
>
Hi Daniel,
On Wed, Aug 26, 2015 at 10:50:23AM +0200, Daniel Vetter wrote:
> > > @@ -332,6 +332,12 @@ int i915_gem_context_init(struct drm_device
> > > *dev)
> > > if (WARN_ON(dev_priv->ring[RCS].default_context))
> > > return 0;
> > >
> > > + if (intel_vgpu_active(
On 07/09/2015 02:15 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Currently we relesar the lane soft reset before lane stagger settings
have been programmed. I believe that means we don't actually do lane
staggering. So move the soft reset deassert to happen after lane
staggeri
On 07/09/2015 02:16 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Add some checks that the state of the DPIO lanes is more or less what we
expect based on the overrides.
The hardware only provides two bits per channel indicating whether all
or some of the lanes are powered dow
On 07/09/2015 02:16 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
At various points when changing the DPIO lane/phy power states,
construct an expected value of the DISPLAY_PHY_STATUS register
and compare it with the real thing.
To construct the expected value we look at our s
On 8/26/2015 7:59 PM, Benjamin Tissoires wrote:
On Aug 26 2015 or thereabouts, Sivakumar Thulasimani wrote:
On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:
On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:
On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
wrote:
On Jul 30 2015 or
On 8/26/2015 4:58 PM, Animesh Manna wrote:
This patch series has the changes done to redesign the dmc firmware
loading flow. This is continuation of the below patch series after
addressing review comments from Daniel.
v1: http://lists.freedesktop.org/archives/intel-gfx/2015-August/072921.html
On Mon, 2015-08-24 at 13:35 +0100, Chris Wilson wrote:
> On Mon, Aug 24, 2015 at 05:28:14PM +0530, ankitprasad.r.sha...@intel.com
> wrote:
> > +static int
> > +__i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
> > +{
> > + const struct drm_i915_gem_object_ops *ops = obj->ops;
> > +
Op 26-08-15 om 21:49 schreef Daniel Vetter:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
>
> I've put this into the core sin
On Tue, 2015-08-25 at 11:51 +0100, Siluvery, Arun wrote:
> On 24/08/2015 12:58, ankitprasad.r.sha...@intel.com wrote:
> > From: Ankitprasad Sharma
> >
> > This patch provides support for the User to populate the object
> > with system pages at its creation time. Since this can be safely
> > perfor
101 - 190 of 190 matches
Mail list logo
