Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
Hi Daniel, Chris
On 11/12/2014 08:38 AM, Chris Wilson wrote:
On Wed, Nov 12, 2014 at 05:33:08PM +0100, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 10:46 AM, Chris Wilson wrote:
On Wed, Nov 12, 2014 at 09:44:34AM +0100, Daniel Vetter wrote:
On Fri, Nov 07, 2014 at 02:22:01PM -0800, bradley.d
Hi Chris,
+static struct drm_i915_gem_object*
+i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
+ struct drm_i915_gem_exec_object2 *shadow_exec_entry,
+ struct eb_vmas *eb,
+ struct drm_i915_gem_object *batch_obj,
+
Yeah, I'm glad you skipped this one. It was something old I was just carrying
for too long...
Just tested on -nightly and everything is working fine. Even after
suspend-resume! :)
Still said that I cannot use sink_crc when psr is enabled...
Thank you very much.
-Original Message-
Fro
On Fri, Nov 21, 2014 at 09:49:21PM +0100, Daniel Vetter wrote:
> On Fri, Nov 21, 2014 at 09:54:29PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On gen4 and earlier the GPU reset also resets the display, so we should
> > protect against concurrent modeset operations
On Fri, Nov 21, 2014 at 09:52:37PM +0100, Daniel Vetter wrote:
> On Thu, Nov 20, 2014 at 09:32:34AM +, Daniel, Thomas wrote:
> > > -Original Message-
> > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > > Of Daniel Vetter
> > > Sent: Wednesday, November 1
On Thu, Nov 20, 2014 at 09:32:34AM +, Daniel, Thomas wrote:
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Daniel Vetter
> > Sent: Wednesday, November 19, 2014 7:29 PM
> > To: Harrison, John C
> > Cc: Intel-GFX@Lists.FreeDesk
On Fri, Nov 21, 2014 at 09:54:29PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On gen4 and earlier the GPU reset also resets the display, so we should
> protect against concurrent modeset operations. Grab all the modeset locks
> around the entire GPU reset dance, remeber
On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote:
> On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote:
> > on vlv, if ipvr is installed, it need be manually unloaded before
> > i915, otherwise user might run into use-after-free issue.
>
> Huh? That doesn't sound right. What e
On Fri, Nov 21, 2014 at 09:00:36PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When doing a nop modeset we currently leave crtc->new_config point at
> the already freed temporary pipe_config. That will anger the sanity
> checks in intel_modeset_update_state() when the no
On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote:
> on vlv, if ipvr is installed, it need be manually unloaded before
> i915, otherwise user might run into use-after-free issue.
Huh? That doesn't sound right. What exactly is it that's going wrong?
You should never have to do this. If you
On Fri, Nov 21, 2014 at 07:01:54PM +, Dave Gordon wrote:
> On 20/11/14 08:45, Daniel Vetter wrote:
> > We need to do that every time we resume the rings, not just at load.
> > I've overlooked this in my untangling of the ring init code.
>
> Hi Daniel,
>
> another thing that needs untangling i
From: Ville Syrjälä
The GPU reset also resets the display on gen3/4. The g33 docs say we
should disable all planes before flipping the reset switch. Just
disable all the crtcs instead. That seems a nicer thing to do anyway.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c
From: Ville Syrjälä
On pre-ctg GPU reset also resets the display hardware. Force a mode
restore after the GPU reset, and also re-init clock gating.
v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating()
in case more relevant stuff gets added there at some point
Restore inte
On Fri, 21 Nov 2014 21:00:36 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When doing a nop modeset we currently leave crtc->new_config point at
> the already freed temporary pipe_config. That will anger the sanity
> checks in intel_modeset_update_state() when the nop mode
From: Ville Syrjälä
g33 seems to sit somewhere between the 915/945/965 style and the
g4x style. The bits look like g4x, but we still need to do a full
reset including display.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/intel_uncore.c |
From: Ville Syrjälä
On gen4 and earlier the GPU reset also resets the display, so we should
protect against concurrent modeset operations. Grab all the modeset locks
around the entire GPU reset dance, remebering first ti dislogde any
pending page flip to make sure we don't deadlock. Any pageflip
From: Ville Syrjälä
This is a respin of my earlier gen3/4 GPU reset patches. Ken was complaining
about the lack of reset on gen4 and I pointed him at my branch, which he used
with some success.
I had to do a bit of rebasing on the patches, but I left Ken's tested-by in
place. Originally we had i
From: Ville Syrjälä
915/945 have the same reset registers as 965, so share the code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 24
3 files changed, 1
From: Ville Syrjälä
On pre-ctg the reset bit directly controls the reset signal. We must
assert it for >=20usec and then deassert it. Bit 1 is a RO status bit
which should also go down when the reset is no longer asserted.
Tested-by: Kenneth Graunke
Signed-off-by: Ville Syrjälä
---
drivers/gp
On Fri, Nov 21, 2014 at 11:13:02AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> CHV infoframes were not being enabled.
>
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/intel_hdmi.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/
From: Clint Taylor
CHV infoframes were not being enabled.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_hdmi.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index ec87333..3abc200 100644
--- a/d
on vlv, if ipvr is installed, it need be manually unloaded before
i915, otherwise user might run into use-after-free issue.
v2:
added this patch per Daniel's comment
v3:
no change
Signed-off-by: Yao Cheng
---
tests/drv_module_reload | 16
1 file changed, 16 insertions(+)
diff
add usermode helper for the ipvr kernel driver.
test_ioctl: test kernel driver by directly ioctl
v2:
take Emil's comments
- correctly align ipvr_drm.h
v3:
take Daniel Vetter and Daniel Stone's comments, and implement PRIME
- correctly align ipvr_drm.h
- use __u32 family in
drm/ipvr is a new GEM driver for VED (PowerVR's VPU integrated in Intel GPU),
which extends video capability.
A new Kconfig added for building ipvr driver:
CONFIG_DRM_IPVR: Build option for ipvr module
The driver name "ipvr" means the PowerVR's core wrapped by Intel. The PowerVR
VPUs are also
Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver (a standalone drm driver) probes the VED device and
creates a new
From: Ville Syrjälä
When doing a nop modeset we currently leave crtc->new_config point at
the already freed temporary pipe_config. That will anger the sanity
checks in intel_modeset_update_state() when the nop modeset gets
followed by a GPU reset on gen3/4 where the display block gets fully
reini
On 20/11/14 08:45, Daniel Vetter wrote:
> We need to do that every time we resume the rings, not just at load.
> I've overlooked this in my untangling of the ring init code.
Hi Daniel,
another thing that needs untangling in the general maze of init code is
the initialisation of the active and req
On Tue, Nov 18, 2014 at 06:21:18PM +, R, Durgadoss wrote:
>
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> >Of Rodrigo Vivi
> >Sent: Friday, November 14, 2014 10:23 PM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Vivi, Rodrigo
>
On Wed, Nov 19, 2014 at 07:38:51AM -0800, Rodrigo Vivi wrote:
> Since active function on VLV immediately activate PSR let's give more
> time for idleness.
>
> v2: Rebase over intel_psr.c and fix typo.
> v3: s/psr/PSR on comment (by Durgadoss)
>
> Reviewed-by: Durgadoss R
> Signed-off-by: Rodrigo
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 369/369 3
This function was in use to check if PSR feature got enabled.
However on HSW and BDW we currently force psr exit by disabling
EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
returning the active/inactive state that is different from the enable/disable
meaning and had the risk
On Thu, Nov 20, 2014 at 02:22:08AM -0800, Rodrigo Vivi wrote:
> This function was in use to check if PSR feature got enabled.
> However on HSW and BDW we currently force psr exit by disabling
> EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
> returning the active/inactive sta
On Thu, Nov 20, 2014 at 02:58:16PM +, Damien Lespiau wrote:
> Because the plane registers are different in Skylake we need to adapt
> the MMIO code as well.
>
> v2: Don't introduce yet another vfunc when the direction is do
> consolidate the plane updates to use the same code path (Daniel)
>
On Fri, Nov 21, 2014 at 04:14:56PM +, Damien Lespiau wrote:
> v2: Put the DPLL0 state readout in skylake_get_ddi_pll(), closer to
> where the PLL assignement read out is done rather than the frequency
> readout function. (Daniel)
>
> v3: Remove stray new line (Damien)
> Add Paulo's r-b tag
From: "Michael H. Nguyen"
Was missing
Issue: VIZ-4701
Signed-off-by: Michael H. Nguyen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 14 +++---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_
I've missed checking this and so didn't notice that there's a NULL
check missing. Since depending upon calling context the crtc might not
even be there (disable-me-harder does happen around planes, especially
in cleanup code) we need to dodge the oops and look at the global
acquire ctx.
v2: Actual
On Fri, Nov 21, 2014 at 04:40:18PM +0100, Daniel Vetter wrote:
> I've missed checking this and so didn't notice that there's a NULL
> check missing. Since depending upon calling context the crtc might not
> even be there (disable-me-harder does happen around planes, especially
> in cleanup code) we
v2: Put the DPLL0 state readout in skylake_get_ddi_pll(), closer to
where the PLL assignement read out is done rather than the frequency
readout function. (Daniel)
v3: Remove stray new line (Damien)
Add Paulo's r-b tag for v1
Reviewed-by: Paulo Zanoni (v1)
Signed-off-by: Damien Lespiau
---
v2: Put the DPLL0 state readout in skylake_get_ddi_pll(), closer to
where the PLL assignement read out is done rather than the frequency
readout function. (Daniel)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
drivers/gpu/drm/i915/intel_display.c | 11 ++-
I've missed checking this and so didn't notice that there's a NULL
check missing. Since depending upon calling context the crtc might not
even be there (disable-me-harder does happen around planes, especially
in cleanup code) we need to dodge the oops and look at the global
acquire ctx.
Reported-b
On 20/11/14 19:13, Chris Wilson wrote:
> For example,
>
> /sys/kernel/debug/dri/0/i915_hangcheck_info:
>
> Hangcheck active, fires in 15887800ms
> render ring:
> seqno = -4059 [current -583]
> action = 2
> score = 0
> ACTHD = 1ee8 [current 21f980]
> max ACT
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 369/369 3
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 369/369 3
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 369/369 3
Hi all,
New -testing cycle with cool stuff:
- infoframe tracking (for fastboot) from Jesse
- start of the dri1/ums support removal
- vlv forcewake timeout fixes (Imre)
- bunch of patches to polish the rps code (Imre) and improve it on bdw (Tom
O'Rourke)
- on-demand pinning for execlist contexts
On Thu, 20 Nov 2014, taj masindi wrote:
> Can you please help me out. where can i find the Intel Graphics Driver
> Acceleration 3600 for my 32bit linux kali
If it's GMA 3600 you're out of luck. There's no open source driver
[1]. Please share 'lspci -nn' output so we can verify which chipset you
h
47 matches
Mail list logo