Hello here are some details about the problem.
-Operative System: QNX
-Symptoms: Aproximately 1 out of 200 video mode switches will cause the CPU to
hang during the next 30-60 VSYNC signals after the mode switches.After hang up
most motherboards switch power off after 5-10 seconds.
The mode sw
On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter wrote:
>>> Proposal. Add a new boolean ->active to the crtc state, which will track
>>> the dpms state of the crtc. Add a helper to the atomic core functions
>>> which will compute ->active from the state update according to the
>>> proposals for issue
On Fri, Nov 7, 2014 at 12:31 AM, Stéphane Marchesin
wrote:
> On Thu, Nov 6, 2014 at 1:43 AM, Daniel Vetter wrote:
>>
>> Hi all,
>>
>> After a few atomic irc chats I've shockingly realized that I've completely
>> ignored dpms handling in my helper series. Oops.
>>
>> But there's a few things which
On Fri, Nov 7, 2014 at 12:33 AM, Daniel Vetter wrote:
> All this only matters for cloned configs anyway only, which is about
> i915 for gen2, roughly. Well Ville implemented cloning for some more
> recent stuff too.
Ok, I've grepped: Beside i915 there's only radeon which has a
possible_clones set
On Thu, Nov 6, 2014 at 11:35 PM, Sean Paul wrote:
>>> Proposal: Only shut down anything (and then the hole output pipe with all
>>> cloned outputs) when all connector's dpms property is set to off. And
>>> enable it again as soon as one property goes to on.
>>
>> Well, it isn't quite the behavior
On Thu, Nov 6, 2014 at 1:43 AM, Daniel Vetter wrote:
>
> Hi all,
>
> After a few atomic irc chats I've shockingly realized that I've completely
> ignored dpms handling in my helper series. Oops.
>
> But there's a few things which are seriously wrong with DPMS, so I've
> figured I'll start a discus
>> 2. Cloned configurations
>>
>> Currently dpms is set per-connector, and the crtc helpers only shut down
>> the specific encoder. Only when all connectors are off will it shut down
>> the crtc, too. That pretty much defeats the point of the new helpers of
>> always enabling/disabling a given outp
Ping on this series. They're related to the batch copy series, but
the changes are valid and tests should still pass even without the
kernel changes being merged.
On Mon, Nov 03, 2014 at 11:18:59AM -0800, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> The size of the batch buffer passed to the
On Thu, Nov 6, 2014 at 5:06 PM, Rob Clark wrote:
> On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> After a few atomic irc chats I've shockingly realized that I've completely
>> ignored dpms handling in my helper series. Oops.
>>
>> But there's a few things which are seriousl
On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote:
> Hi all,
>
> After a few atomic irc chats I've shockingly realized that I've completely
> ignored dpms handling in my helper series. Oops.
>
> But there's a few things which are seriously wrong with DPMS, so I've
> figured I'll start a discussi
On Thu, Nov 6, 2014 at 12:53 PM, Ville Syrjälä
wrote:
> On Thu, Nov 06, 2014 at 09:09:52PM +0200, Ville Syrjälä wrote:
>> On Thu, Nov 06, 2014 at 10:55:12AM +, Chris Wilson wrote:
>> > On Wed, Nov 05, 2014 at 12:11:41PM +0100, Daniel Vetter wrote:
>> > > On Thu, Oct 30, 2014 at 5:18 PM, Rodrig
On Tue, 21 Oct 2014 16:50:12 +0300
Ville Syrjälä wrote:
> On Thu, Sep 11, 2014 at 07:15:27AM -0700, Jesse Barnes wrote:
> > On Thu, 11 Sep 2014 14:59:35 +0300
> > Imre Deak wrote:
> >
> > > On Thu, 2014-09-11 at 08:49 +0100, Chris Wilson wrote:
> > > > On Wed, Sep 10, 2014 at 06:17:01PM +0300,
On Thu, Nov 06, 2014 at 09:09:52PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 06, 2014 at 10:55:12AM +, Chris Wilson wrote:
> > On Wed, Nov 05, 2014 at 12:11:41PM +0100, Daniel Vetter wrote:
> > > On Thu, Oct 30, 2014 at 5:18 PM, Rodrigo Vivi
> > > wrote:
> > > > Global GTT doesn't have pat_se
On Thu, Nov 06, 2014 at 08:18:46PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 06, 2014 at 09:35:48AM -0800, O'Rourke, Tom wrote:
> > On Thu, Nov 06, 2014 at 10:28:53AM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 05, 2014 at 05:32:44PM -0800, Tom.O'rou...@intel.com wrote:
> > > > From: Tom O'Rourke
On Thu, Nov 6, 2014 at 3:00 PM, Daniel Vetter wrote:
> In all cases the text requires that new drivers are converted to the
> atomic interfaces.
>
> v2: Add overview for state handling.
>
> v3: Review from Sean: Some spelling fixes and drop the misguided
> hunk to remove rgba from the plane he
On Thu, Nov 6, 2014 at 2:57 PM, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote:
>> On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
>> > The atomic users and helpers assume that there is always a obj->state
>> > structure around. Which means drivers
In all cases the text requires that new drivers are converted to the
atomic interfaces.
v2: Add overview for state handling.
v3: Review from Sean: Some spelling fixes and drop the misguided
hunk to remove rgba from the plane helpers compat list.
Cc: Sean Paul
Signed-off-by: Daniel Vetter
-
On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
> > The atomic users and helpers assume that there is always a obj->state
> > structure around. Which means drivers need to somehow create that at
> > driver load time. Also i
The atomic users and helpers assume that there is always a obj->state
structure around. Which means drivers need to somehow create that at
driver load time. Also it should obviously reset hardware state, so
needs to be reset upon resume.
Finally the destroy/duplicate_state functions are an awful l
On Thu, Nov 06, 2014 at 10:55:12AM +, Chris Wilson wrote:
> On Wed, Nov 05, 2014 at 12:11:41PM +0100, Daniel Vetter wrote:
> > On Thu, Oct 30, 2014 at 5:18 PM, Rodrigo Vivi
> > wrote:
> > > Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
> > > So the only way to avoi
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Wednesday, October 29, 2014 12:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 10/10] drm/i915: Enable PSR for Baytrail and
>B
On Thu, Nov 6, 2014 at 1:13 PM, Daniel Vetter wrote:
>
> On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote:
> > On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> > > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > > +retry:
> > > + crtc_state = drm_atomic_ge
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Wednesday, October 29, 2014 12:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 08/10] drm/i915: VLV/CHV PSR debugfs.
>
>Add deb
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Wednesday, October 29, 2014 12:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 06/10] drm/i915: VLV/CHV PSR Software timer mode
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Wednesday, October 29, 2014 12:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 07/10] drm/i915: VLV/CHV PSR: Increase wait delay
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Wednesday, October 29, 2014 12:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 04/10] drm/i915: PSR VLV/CHV: Introduce setup,
>e
On Wed, Nov 5, 2014 at 5:01 PM, Daniel Vetter wrote:
> On Wed, Nov 05, 2014 at 02:48:48PM -0500, Sean Paul wrote:
>> > + if (!crtc && crtc != set->crtc)
>>
>> I think this should be an ||
>
> Hm. My idea idea was actually something along the lines of
> diff --git a/drivers/gpu/drm/drm_atomic_helpe
On Wed, Nov 5, 2014 at 4:44 PM, Daniel Vetter wrote:
> I've applied all the other nits, replies to the more interesting bits
> below.
>
> On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote:
>> On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote:
>> > + if (new_encoder != connector
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Wednesday, October 29, 2014 12:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 02/10] drm/i915: VLV PSR: Status/enabled functio
On Thu, Nov 06, 2014 at 09:35:48AM -0800, O'Rourke, Tom wrote:
> On Thu, Nov 06, 2014 at 10:28:53AM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 05, 2014 at 05:32:44PM -0800, Tom.O'rou...@intel.com wrote:
> > > From: Tom O'Rourke
> > >
> > > Based on sandybridge_pcode_write, haswell_pcode_write ha
Hi Rodrigo,
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Wednesday, October 29, 2014 12:16 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 01/10] drm/i915: Add PSR registers f
On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > +retry:
> > + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > + if (IS_ERR(crtc_state)) {
> > + r
On Sun, Nov 02, 2014 at 02:19:30PM +0100, Daniel Vetter wrote:
> So my original plan was that the drm core refcounts framebuffers like
> with the legacy ioctls. But that doesn't work for a bunch of reasons:
>
> - State objects might live longer than until the next fb change
> happens for a plane.
On Sun, Nov 02, 2014 at 02:19:29PM +0100, Daniel Vetter wrote:
> In all cases the text requires that new drivers are converted to the
> atomic interfaces.
>
> v2: Add overview for state handling.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 20 +++
On Sun, Nov 02, 2014 at 02:19:26PM +0100, Daniel Vetter wrote:
> No helper function to do it all yet provided since no driver has
> support for driver core fences yet. Which we'd need to make the
> implementation really generic.
>
> v2: Clarify async howto a bit per the discussion With Rob Clark.
>
On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> Currently there is no way to implement async flips using atomic, that
> essentially requires us to be able to cancel pending requests
> mid-flight.
>
> To be able to do that (and I guess we want this since vblank synced
> updates whic
On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
> The atomic users and helpers assume that there is always a obj->state
> structure around. Which means drivers need to somehow create that at
> driver load time. Also it should obviously reset hardware state, so
> needs to be reset upo
On Thu, Nov 06, 2014 at 05:56:36AM -0800, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 07:36:55AM +, Chris Wilson wrote:
> > On Wed, Nov 05, 2014 at 02:42:00PM -0800, Volkin, Bradley D wrote:
> > > For this part, I've got an implementation that works ok but one
> > > difference is
> > > that
On Thu, Nov 06, 2014 at 10:28:53AM +0200, Ville Syrjälä wrote:
> On Wed, Nov 05, 2014 at 05:32:44PM -0800, Tom.O'rou...@intel.com wrote:
> > From: Tom O'Rourke
> >
> > Based on sandybridge_pcode_write, haswell_pcode_write has an
> > additional field for address control.
>
> It's already there in
On Thu, 06 Nov 2014, Rodrigo Vivi wrote:
> Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
> So the only way to avoid screen corruptions is setting PAT 0 to Uncached.
>
> MOCS can still be used though. But if userspace is trusting PTE for
> cache selection the safest thin
On Wed, 05 Nov 2014, Daniel Vetter wrote:
> On Wed, Nov 05, 2014 at 02:46:31PM +0200, Jani Nikula wrote:
>> Never trust (your interpretation of) the VBT. Regression from
>>
>> commit 6dda730e55f412a6dfb181cae6784822ba463847
>> Author: Jani Nikula
>> Date: Tue Jun 24 18:27:40 2014 +0300
>>
>>
On Wed, Nov 05, 2014 at 12:48:35PM +, Chris Wilson wrote:
> On Thu, Oct 23, 2014 at 05:55:47PM +0100, Chris Wilson wrote:
> > From: Akash Goel
> >
> > This patch provides support to create write-combining virtual mappings of
> > GEM object. It intends to provide the same funtionality of 'mmap
On Thu, Nov 06, 2014 at 04:02:10PM +0200, Imre Deak wrote:
> On Tue, 2014-10-07 at 17:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We need the HPLL frequency when calculating cdclk. Currently we read
> > that out from the hardware every single time, which isn't g
From: Tvrtko Ursulin
Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.
This also means that objects now can have multiple VMA entries.
Added a GGTT view concept and linked it with the VMA to distinguish betwen
mult
On Thu, Nov 06, 2014 at 09:04:14AM +, Chris Wilson wrote:
> On Wed, Nov 05, 2014 at 02:26:06PM -0800, Jesse Barnes wrote:
> > +static int intel_set_mode(struct drm_crtc *crtc,
> > + struct drm_display_mode *mode,
> > + int x, int y, struct drm_framebuffer
On Thu, Nov 06, 2014 at 02:53:09PM +0100, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 09:25:22AM +, Chris Wilson wrote:
> > On Thu, Nov 06, 2014 at 11:03:40AM +0200, Ander Conselvan de Oliveira wrote:
> > > This simplifies the code quite a bit compared to iterating over all
> > > rings durin
On Wed, Nov 05, 2014 at 05:30:52PM +0200, Mika Kuoppala wrote:
> This reverts commit 5cb13c07dae73380d8b3ddc792740487b8742938.
>
> While the relevance for WaRsDontPollForAckOnClearingFWBits is under
> investigation, revert this as regression.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cg
On Tue, 2014-10-07 at 17:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We need the HPLL frequency when calculating cdclk. Currently we read
> that out from the hardware every single time, which isn't going to fly
> very well if the device is runtime suspended. So cache
On Thu, Nov 06, 2014 at 07:36:55AM +, Chris Wilson wrote:
> On Wed, Nov 05, 2014 at 02:42:00PM -0800, Volkin, Bradley D wrote:
> > For this part, I've got an implementation that works ok but one difference
> > is
> > that if we stop submitting batches, and therefore stop calling
> > batch_poo
On Thu, Nov 06, 2014 at 09:25:22AM +, Chris Wilson wrote:
> On Thu, Nov 06, 2014 at 11:03:40AM +0200, Ander Conselvan de Oliveira wrote:
> > This simplifies the code quite a bit compared to iterating over all
> > rings during the ring interrupt.
> >
> > Also, it allows us to drop the mmio_flip
On Thu, Nov 06, 2014 at 02:49:12PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We may need to access various hardware bits in the .global_resources()
> hook, so move the call to occur after enabling all the newly required
> power wells, but before disabling all the now u
On Thu, 06 Nov 2014, Arnd Hannemann wrote:
> Hi,
>
> thanks for your quick response.
>
> Am 06.11.2014 um 10:39 schrieb Jani Nikula:
>> On Thu, 06 Nov 2014, Arnd Hannemann wrote:
>>> Hi,
>>>
>>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>>> via a Docking Station (MST)
From: Ville Syrjälä
We may need to access various hardware bits in the .global_resources()
hook, so move the call to occur after enabling all the newly required
power wells, but before disabling all the now unneeded wells. This
should guarantee that we have all the sufficient hardware resources
a
as it helps with bug triaging.
v2: Use PAGE_SIZE on alloc, don't spam to dmesg (Chris Wilson)
Suggested-by: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 31 +++
2 files changed, 3
On Thu, Nov 06, 2014 at 01:03:47PM +0200, Mika Kuoppala wrote:
> as it helps with bug triaging.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 32
> 2
On Thu, Nov 06, 2014 at 01:03:46PM +0200, Mika Kuoppala wrote:
> for the Brothers in Triage
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/driver
for the Brothers in Triage
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index d17360b..89a2f3d 100644
--- a/drivers/gpu/d
as it helps with bug triaging.
Suggested-by: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 32
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b
On Wed, Nov 05, 2014 at 12:11:41PM +0100, Daniel Vetter wrote:
> On Thu, Oct 30, 2014 at 5:18 PM, Rodrigo Vivi wrote:
> > Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
> > So the only way to avoid screen corruptions is setting PAT 0 to Uncached.
> >
> > MOCS can still b
On Thu, Nov 06, 2014 at 08:22:54AM +0200, Timo Aaltonen wrote:
> On 06.11.2014 01:48, Rodrigo Vivi wrote:
> > Using dispatch mask cause hangs waiting PS Done on some cases like bug
> > #83207,
> > with larger screen or when scaling it.
> >
> > Also mesa uses VMask instead of Dmask for 3DSTATE_PS
Hi,
thanks for your quick response.
Am 06.11.2014 um 10:39 schrieb Jani Nikula:
> On Thu, 06 Nov 2014, Arnd Hannemann wrote:
>> Hi,
>>
>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>> via a Docking Station (MST).
>>
>> During Bootup all three displays work, even when
Hi all,
After a few atomic irc chats I've shockingly realized that I've completely
ignored dpms handling in my helper series. Oops.
But there's a few things which are seriously wrong with DPMS, so I've
figured I'll start a discussion about them first - converting to atomic
looks like a good time
On Thu, 06 Nov 2014, Arnd Hannemann wrote:
> Hi,
>
> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
> via a Docking Station (MST).
>
> During Bootup all three displays work, even when X is started.
> However, if the laptop display is turned off once (either because of
> pow
On Thu, Nov 06, 2014 at 11:03:40AM +0200, Ander Conselvan de Oliveira wrote:
> This simplifies the code quite a bit compared to iterating over all
> rings during the ring interrupt.
>
> Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip
> struct is only accessed in two places.
Hi,
I have a Thinkpad T440s (Haswell) connected to two additional Monitors
via a Docking Station (MST).
During Bootup all three displays work, even when X is started.
However, if the laptop display is turned off once (either because of
power saving, or via xrandr), it fails to "come back".
That i
On Wed, Nov 05, 2014 at 02:26:06PM -0800, Jesse Barnes wrote:
> +static int intel_set_mode(struct drm_crtc *crtc,
> + struct drm_display_mode *mode,
> + int x, int y, struct drm_framebuffer *fb)
> +{
> + struct intel_crtc_config *pipe_config;
> +
This simplifies the code quite a bit compared to iterating over all
rings during the ring interrupt.
Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip
struct is only accessed in two places. The first is when the flip is
queued and the other when the mmio writes are done. Since
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=348/348->348/348
PNV: pass/total=324/328->324
As obj->map_and_fenceable computation has changed to only be set when
the object is bound inside the global GTT (and is suitable aligned to a
fence region) we need to accommodate those changes when the tiling is
adjusted. The easiest solution is to unbind from the global GTT if we
are currently fen
On Tue, Nov 04, 2014 at 04:51:44AM -0800, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> Pineview requires this. But this changes the debug API...
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=82280
> Signed-off-by: Chris Wilson
> Signed-off-by: Rodrigo Vivi
Chris already retract
On Thu, Nov 06, 2014 at 04:02:30PM +0800, Zhao Yakui wrote:
> After applying the commit(982f7eb238a0898c456e0574dee7c4507738d75f), the
> OUT_RELOC is
> updated on Broadwell and later, which is to handle the 64-bit field of gfx
> address
> internally. In such case some commands should be fixed, ot
On Wed, Nov 05, 2014 at 05:32:44PM -0800, Tom.O'rou...@intel.com wrote:
> From: Tom O'Rourke
>
> Based on sandybridge_pcode_write, haswell_pcode_write has an
> additional field for address control.
It's already there in snb.
Do you have an actual use case for this? If so I wonder if we should
j
After applying the commit(982f7eb238a0898c456e0574dee7c4507738d75f), the
OUT_RELOC is
updated on Broadwell and later, which is to handle the 64-bit field of gfx
address
internally. In such case some commands should be fixed, otherwise GPU hang will
be triggered when running rendercopy.
(It is alr
After applying the commit(982f7eb238a0898c456e0574dee7c4507738d75f), the
OUT_RELOC is
updated on Broadwell and later, which is to handle the 64-bit field of gfx
address
internally. In such case some commands should be fixed, otherwise GPU hang will
be triggered when running gem_media_fill.
(It is
74 matches
Mail list logo
