Implemented the comments based on
www.spinics.net/lists/intel-gfx/msg42439.html
Arun R Murthy (1):
drm/i915: use waitqueue in wait for vblank
drivers/gpu/drm/i915/i915_dma.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c | 16 -
Instead of using sleep functions in wait for vblank, which wakes up on
sleep timeout aften, thereby scheduler provoking scheduler. Hence use
waitqueue in wait for vblank.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/i915_dma.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |1
On Wed, May 21, 2014 at 01:09:58PM +0530, Arun R Murthy wrote:
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 56edff3..f97f0fe 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1513,8 +1513,11 @@ static irqreturn_t
On Tue, Apr 15, 2014 at 09:41:34PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Starting from ILK, mmio flips also cause a flip done interrupt to be
> signalled. This means if we first do a set_base and follow it
> immediately with the CS flip, we might mistake the flip d
On Wed, May 21, 2014 at 01:09:58PM +0530, Arun R Murthy wrote:
> Instead of using sleep functions in wait for vblank, which wakes up on
> sleep timeout aften, thereby scheduler provoking scheduler. Hence use
> waitqueue in wait for vblank.
>
> Signed-off-by: Arun R Murthy
You're rebuilding infra
On 04/25 20:14, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Document the internal structure of the VLV display PHY a bit to help
> people understand how the different register blocks relate to each
> other.
>
> v2: Add a bit more text
> Make it a DOC: comment, but leave th
On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrjälä wrote:
> For everything but the reset_vblank_counter() thing:
> Reviewed-by: Ville Syrjälä
>
> And another caveat: I only glanced at the crtc_helper stuff. It looks
> sane but I didn't go reading through the drivers to figure out if they
> w
For everything but the reset_vblank_counter() thing:
Reviewed-by: Ville Syrjälä
And another caveat: I only glanced at the crtc_helper stuff. It looks
sane but I didn't go reading through the drivers to figure out if they
would fall over or work.
About the reset_vblank_counter(), I think we might
On Wed, May 21, 2014 at 08:54:04AM +0100, Chris Wilson wrote:
> On Wed, May 21, 2014 at 01:09:58PM +0530, Arun R Murthy wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 56edff3..f97f0fe 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++
On Wed, May 21, 2014 at 04:31:37PM +0800, Lee, Chon Ming wrote:
> On 04/25 20:14, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Document the internal structure of the VLV display PHY a bit to help
> > people understand how the different register blocks relate to each
> > ot
On Wed, May 21, 2014 at 10:35:59AM +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrjälä wrote:
> > For everything but the reset_vblank_counter() thing:
> > Reviewed-by: Ville Syrjälä
> >
> > And another caveat: I only glanced at the crtc_helper stuff. It looks
> >
On Fri, May 16, 2014 at 11:54:09AM +0530, sourab gupta wrote:
> On Fri, May 16, 2014 at 11:03 AM, akash goel wrote:
>
> >
> > Sorry not aware of this specific difference in the starting value of
> > scanline counter for HSW+ (& gen 2), but implementation wise, patch looks
> > fine.
> >
> > Review
From: Imre Deak
This is commit 76c4b250080fff6e4befaa36199424 upstream.
During resume the intel hda audio driver depends on the i915 driver
reinitializing the audio power domain. Since the order of calling the
i915 resume handler wrt. that of the audio driver is not guaranteed,
move the power do
This is commit 2ab1bc9df01dbc19b55b2271100db7 upstream.
Apparently it doesn't work. X-tiled self-refresh works flawlessly
otoh. Apparently X still works correctly with linear framebuffers, so
might just be an issue with the initial modeset. It's unclear whether
this just borked wm setup from our s
From: Jani Nikula
This is commit 0f540c3a7cfb91c9d7a19eb0c95c24 upstream.
Since
commit ee1452d7458451a7508e0663553ce88d63958157
Author: Jani Nikula
Date: Fri Sep 20 15:05:30 2013 +0300
drm/i915: assume all GM45 Acer laptops use inverted backlight PWM
failed and was later reverted in
com
From: Chris Wilson
This is commit df6f783a4ef6790780a67c491897ac upstream.
On non-LLC platforms, when changing the cache level of an object, we may
need to unbind it so that prefetching across page boundaries does not
cross into a different memory domain. This requires us to unbind
conflicting v
Hi Greg,
This is a set of drm/i915 patches which didn't apply cleanly on for 3.14. All
absed on 3.14.4. I've left out the bdw patches for now and will sign up someone
else for that task.
Cheers, Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedes
On Tue, May 20, 2014 at 07:31:33PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > If a pipe is already active when we init/resume there might not be a
> > full modeset afterwards so drm_vblank_on() may n
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, May 21, 2014 4:50 PM
> To: Lee, Chon Ming
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Add a brief description of
> the VLV display PHY interna
On Wed, May 21, 2014 at 09:58:35AM +, Lee, Chon Ming wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Wednesday, May 21, 2014 4:50 PM
> > To: Lee, Chon Ming
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [
On Fri, Apr 25, 2014 at 08:14:32PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The ascii art version of the DPIO diagram gets mangled by docbook, so
> we can't use it there. Insted provide another version built using
> .
>
> Signed-off-by: Ville Syrjälä
I guess one co
Adding relevant read out comparison code, in check_crtc_state, for the new
member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
values for a DP downclock mode (if available). Suggested by Daniel.
v2: Changed patch title.
Daniel's review comments incorporated.
Added relevant stat
For Gen < 8, set M2_N2 registers on every mode set. This is required to make
sure M2_N2 registers are set during boot, resume from sleep for cross-
checking the state. The register is set only if DRRS is supported.
Signed-off-by: Vandana Kannan
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dr
On 04/25 20:14, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The ascii art version of the DPIO diagram gets mangled by docbook, so
> we can't use it there. Insted provide another version built using
> .
>
> Signed-off-by: Ville Syrjälä
When generating drm.tmpl to html, it say
From: Ville Syrjälä
We have to write to the primary plane base address registrer when we
enable/disable the primary plane in response to sprite coverage. Those
writes will cause the flip counter to increment which could interfere
with the detection of CS flip completion. We could end up completin
On Wed, May 14, 2014 at 08:51:03PM +0200, Daniel Vetter wrote:
> From: Peter Hurley
>
> The irq flags state is already established by the outer
> spin_lock_irqsave(); re-disabling irqs is redundant.
>
> Signed-off-by: Peter Hurley
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq
On Wed, May 14, 2014 at 08:51:04PM +0200, Daniel Vetter wrote:
> From: Ville Syrjälä
>
> Currently there's one per-device vblank disable timer, and it gets
> reset wheneven the vblank refcount for any crtc drops to zero. That
"whenever"
> means that one crtc could accidentally be keeping the vb
On Wed, May 14, 2014 at 08:51:05PM +0200, Daniel Vetter wrote:
> From: Ville Syrjälä
>
> If there's a blocking vblank wait in progress while the vblank interrupt
> gets disabled, the current code will just let the vblank wait time out.
> Instead make it return immediately when vblank interrupts g
On Wed, May 21, 2014 at 01:20:55PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:05PM +0200, Daniel Vetter wrote:
> > From: Ville Syrjälä
> >
> > If there's a blocking vblank wait in progress while the vblank interrupt
> > gets disabled, the current code will just let the vblank wa
On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> From: Ville Syrjälä
>
> drm_vblank_off() will turn off vblank interrupts, but as long as the
> refcount is elevated drm_vblank_get() will not re-enable them. This
> is a problem is someone is holding a vblank reference while a modes
On Wed, May 14, 2014 at 08:51:07PM +0200, Daniel Vetter wrote:
> Originally these functions have been for user modesetting drivers to
> ensure vblank processing doesn't fall over completely around modeset
> changes. This has been carried over ever since then.
>
> Now that Ville cleaned our vblank
A single object may be referenced by multiple registers fundamentally
breaking the static allotment of ids in the current design. When the
object is used the second time, the physical address of the first
assignment is relinquished and a second one granted. However, the
hardware is still reading (a
for proper refcounting to take place as we use
i915_add_request() for it.
i915_add_request() also takes the context for the request
from ring->last_context so move the null state batch
submission after the ring context has been set.
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Damien Lespiau
Signed-
On Wed, May 21, 2014 at 01:17:49PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:04PM +0200, Daniel Vetter wrote:
> > From: Ville Syrjälä
> >
> > Currently there's one per-device vblank disable timer, and it gets
> > reset wheneven the vblank refcount for any crtc drops to zero. Th
On Wed, May 21, 2014 at 01:32:35PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> > From: Ville Syrjälä
> >
> > drm_vblank_off() will turn off vblank interrupts, but as long as the
> > refcount is elevated drm_vblank_get() will not re-enable them.
From: Ville Syrjälä
kms_mmio_vs_cs_flip has two subtests:
- setplane_vs_cs_flip tests the interaction between
fullscreen sprites and CS flips
- setcrtc_vs_cs_flip tests the interaction between
primary plane panning and CS flips
v2: Skip sprite test when there are no sprites
Reduce busy_b
On Wed, May 21, 2014 at 06:59:03PM +0800, Lee, Chon Ming wrote:
> On 04/25 20:14, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The ascii art version of the DPIO diagram gets mangled by docbook, so
> > we can't use it there. Insted provide another version built using
> > .
On Wed, May 21, 2014 at 03:08:51PM +0300, Mika Kuoppala wrote:
> for proper refcounting to take place as we use
> i915_add_request() for it.
>
> i915_add_request() also takes the context for the request
> from ring->last_context so move the null state batch
> submission after the ring context has
On Wed, May 21, 2014 at 04:40:04PM +0530, Vandana Kannan wrote:
> Adding relevant read out comparison code, in check_crtc_state, for the new
> member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
> values for a DP downclock mode (if available). Suggested by Daniel.
>
> v2: Chang
On Wed, May 21, 2014 at 12:42:56PM +0100, Chris Wilson wrote:
> A single object may be referenced by multiple registers fundamentally
> breaking the static allotment of ids in the current design. When the
> object is used the second time, the physical address of the first
> assignment is relinquish
On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > don't need any hacks any longer to keep the vblank logic sane when
> > all the registers go poof.
On Wed, May 14, 2014 at 08:51:12PM +0200, Daniel Vetter wrote:
> If we want to use this functionality in generic helpers to make
> sure that all drivers have somewhat sane vblank handling across
> modesets/dpms, we need to make it work for all drivers. But some
> don't support interrupts and hence
On Wed, May 14, 2014 at 08:51:16PM +0200, Daniel Vetter wrote:
> If we want to use this functionality in generic helpers to make
> sure that all drivers have somewhat sane vblank handling across
> modesets/dpms, we need to make it work for all drivers. But some
> don't support interrupts and hence
On Wed, May 21, 2014 at 10:35:59AM +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrjälä wrote:
> > For everything but the reset_vblank_counter() thing:
> > Reviewed-by: Ville Syrjälä
> >
> > And another caveat: I only glanced at the crtc_helper stuff. It looks
> >
for proper refcounting to take place as we use
i915_add_request() for it.
i915_add_request() also takes the context for the request
from ring->last_context so move the null state batch
submission after the ring context has been set.
v2: we need to check for correct ring now (Ville Syrjälä)
Cc: V
On Wed, May 21, 2014 at 03:08:51PM +0300, Mika Kuoppala wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
> b/drivers/gpu/drm/i915/i915_gem_render_state.c
> index 392aa7b..d29e6b2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
> +++ b/drivers/gpu/drm/i915/i915_gem_ren
On Wed, May 21, 2014 at 02:53:00PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:16PM +0200, Daniel Vetter wrote:
> > If we want to use this functionality in generic helpers to make
> > sure that all drivers have somewhat sane vblank handling across
> > modesets/dpms, we need to make
for proper refcounting to take place as we use
i915_add_request() for it.
i915_add_request() also takes the context for the request
from ring->last_context so move the null state batch
submission after the ring context has been set.
v2: we need to check for correct ring now (Ville Syrjälä)
v3: no
On 16 May 2014 17:40, wrote:
> From: Ville Syrjälä
>
> FIFO underruns don't generate an interrupt on gmch platforms, so we
> should check whether there were any that we failed to notice when
> we're disabling FIFO underrun reporting.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Thomas Wood
On 16 May 2014 17:40, wrote:
> From: Ville Syrjälä
>
> Checking whether the error interrupt was enabled or not isn't really
> necessary when we check for uncleared FIFO underruns. If it was enabled
> we'll race with the interrupt handler a bit, but that seems OK as we
> still claim the interrupt
On 16 May 2014 17:40, wrote:
> From: Ville Syrjälä
>
> FIFO underruns don't generate interrupts on gmch platforms, so
> if we want to know whether a modeset triggered FIFO underruns we
> need to explicitly check for them.
>
> As a modeset on one pipe could cause underruns on other pipes,
> check
On 16 May 2014 17:40, wrote:
> From: Ville Syrjälä
>
> Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
> So in order to avoid false positives we must enable the FIFO underrun
> reporting only when at least one plane is enabled on the pipe. For
> now just move the underrun
On Fri, May 16, 2014 at 07:40:25PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
> So in order to avoid false positives we must enable the FIFO underrun
> reporting only when at least one plane is enab
On Wed, May 21, 2014 at 04:52:31PM +0200, Daniel Vetter wrote:
> On Fri, May 16, 2014 at 07:40:25PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
> > So in order to avoid false positives we must
On Wed, May 21, 2014 at 05:02:56PM +0300, Mika Kuoppala wrote:
> for proper refcounting to take place as we use
> i915_add_request() for it.
>
> i915_add_request() also takes the context for the request
> from ring->last_context so move the null state batch
> submission after the ring context has
On Wed, May 21, 2014 at 04:54:55PM +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 05:02:56PM +0300, Mika Kuoppala wrote:
> > for proper refcounting to take place as we use
> > i915_add_request() for it.
> >
> > i915_add_request() also takes the context for the request
> > from ring->last_co
On Wed, 21 May 2014 08:52:34 +0200
Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> > Gets the detect code (which may take awhile) out of the resume path,
> > speeding things up a bit.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i9
On Wed, May 21, 2014 at 08:00:22AM -0700, Jesse Barnes wrote:
> On Wed, 21 May 2014 08:52:34 +0200
> Daniel Vetter wrote:
>
> > On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> > > Gets the detect code (which may take awhile) out of the resume path,
> > > speeding things up a bit.
On Wed, May 21, 2014 at 04:00:40PM +0100, Chris Wilson wrote:
> On Wed, May 21, 2014 at 04:54:55PM +0200, Daniel Vetter wrote:
> > On Wed, May 21, 2014 at 05:02:56PM +0300, Mika Kuoppala wrote:
> > > for proper refcounting to take place as we use
> > > i915_add_request() for it.
> > >
> > > i915_a
Re-define MIPI register definitions in such a way that most of
the existing DSI code can be re-used for future platforms. Register
definitions are re-written using MMIO offset variable, so that without
changing the existing sequence, same code can be generically applied.
V2: Addressing review comm
On Wed, May 21, 2014 at 07:02:56AM -0700, Mika Kuoppala wrote:
> + if (ring->id == RCS && !to->is_initialized && from == NULL) {
> + ret = i915_gem_render_state_init(ring);
> + if (ret)
> + DRM_ERROR("init render state: %d\n", ret);
> + }
Apologi
On Wed, May 21, 2014 at 08:56:59PM +0530, Shashank Sharma wrote:
> Re-define MIPI register definitions in such a way that most of
> the existing DSI code can be re-used for future platforms. Register
> definitions are re-written using MMIO offset variable, so that without
> changing the existing se
> -Original Message-
> From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com]
> Sent: Tuesday, May 20, 2014 12:56 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Mateo Lozano, Oscar
> Subject: [PATCH 1/2] tests/drv_hangman: Convert test from shell script to c
>
> Mixing script and stand
Adding stuff at the bottom is really no how this should be done, since
that's the place for ums/dri dungeons.
This was added in
commit a8ebba75b358f9c912cbcba0c14a2072e7280b2f
Author: Zhao Yakui
Date: Thu Apr 17 10:37:40 2014 +0800
drm/i915: Use the coarse ping-pong mechanism based on drm
Thanks for pointing this out.
I will correct all formatting stuff and re-send patch.
Regards
Shashank
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Wednesday, May 21, 2014 9:05 PM
To: Sharma, Shashank
Cc: Lespiau, Damien; Vetter, Daniel; intel-gfx@l
> -Original Message-
> From: Mika Kuoppala [mailto:mika.kuopp...@linux.intel.com]
> Sent: Tuesday, May 20, 2014 12:56 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Mateo Lozano, Oscar
> Subject: [PATCH 2/2] tests/drv_hangman: Add subtest for error state
> capture/dump
>
> Guarantees that
UXA was reporting page-flip completion as soon as the flip was scheduled
with the kernel, instead of waiting for the kernel to indicate that the
flip had actually completed.
Moving the DRI2SwapComplete call to the right place fixes all of our
Piglit tests for OML_sync_control when run on xf86-vide
On Wed, May 21, 2014 at 06:35:12PM +0300, Ville Syrjälä wrote:
> > +
> > +/* VLV port control */
> > #define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190)
> > #define _MIPIB_PORT_CTRL (VLV_DISPLAY_BASE + 0x61700)
> > #define MIPI_PORT_CTRL(pipe)
> On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote:
> > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> > > This RFC is based on previous discussion to set up a generic
> > > communication channel between display and audio driver and an
> > > internal design of Intel MCG/VPG HDMI
On Wed, May 21, 2014 at 5:56 PM, Babu, Ramesh wrote:
>> On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote:
>> > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
>> > > This RFC is based on previous discussion to set up a generic
>> > > communication channel between display and audio
From: Mika Kuoppala
for proper refcounting to take place as we use
i915_add_request() for it.
i915_add_request() also takes the context for the request
from ring->last_context so move the null state batch
submission after the ring context has been set.
v2: we need to check for correct ring now
On Wed, May 21, 2014 at 08:53:18AM -0700, Jamey Sharp wrote:
> UXA was reporting page-flip completion as soon as the flip was scheduled
> with the kernel, instead of waiting for the kernel to indicate that the
> flip had actually completed.
>
> Moving the DRI2SwapComplete call to the right place f
On Wed, May 21, 2014 at 05:24:18PM +0100, Chris Wilson wrote:
> On Wed, May 21, 2014 at 08:53:18AM -0700, Jamey Sharp wrote:
> > Please merge this patch, which fixes two spec violations that make
> > OML_sync_control unusable; and if you're concerned about uncomposited
> > triple-buffering in UXA,
On Wed, 2014-05-21 at 18:05 +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 5:56 PM, Babu, Ramesh wrote:
> >> On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote:
> >> > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> >> > > This RFC is based on previous discussion to set up
On Tue, May 20, 2014 at 11:09:03AM -0700, Jesse Barnes wrote:
> This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
> that it resets the whole common lane section of the PHY. This is
> required on machines where the BIOS doesn't do this for us on boot or
> resume to properly re-ca
On Wed, 21 May 2014 20:54:03 +0300
Ville Syrjälä wrote:
> On Tue, May 20, 2014 at 11:09:03AM -0700, Jesse Barnes wrote:
> > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
> > that it resets the whole common lane section of the PHY. This is
> > required on machines where the
And to answer more specifically...
On Wed, 21 May 2014 20:54:03 +0300
Ville Syrjälä wrote:
> > + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC,
> > +false);
> > + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC,
> > +
三月！ writes:
> Hello! I'm developing some openCL application with Beignet in Ubuntu
> 14.04 x64 Desktop upon Bay Trail E3825. And I found that reading data
> from GPU memory through whatever drm_intel gem_bo_map or
> drm_intel_gem_bo_get subdata cost about 0.002 ~ 0.003 second to fetch
> a 7MiB
More of an example of where to use the stepping macro than anything
else. I think these early steppings never went outside of Intel.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/driver
In some cases to enable or disable features & workarounds, we may need
to check the GPU stepping. Add a macro to do that based on caching the
PCI revision ID reg.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
2 files changed, 4 i
On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote:
> And to answer more specifically...
>
> On Wed, 21 May 2014 20:54:03 +0300
> Ville Syrjälä wrote:
>
> > > + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC,
> > > + false);
> > > +
On Wed, May 21, 2014 at 11:42:25AM -0700, Jesse Barnes wrote:
> In some cases to enable or disable features & workarounds, we may need
> to check the GPU stepping. Add a macro to do that based on caching the
> PCI revision ID reg.
What about just using dev->pdev->revision like we already do?
-Chr
From: Paulo Zanoni
Because this will trigger "Unclaimed register" messages. All I need to
reproduce this problem is to boot my HSW machine with eDP+HDMI
connected.
Regression introduced by:
commit 9ed109a7b445e3f073d8ea72f888ec80c0532465
Author: Daniel Vetter
Date: Thu Apr 24 23:54:52 2014 +
From: Paulo Zanoni
Because this will trigger "Unclaimed register" messages. This can be
reproduced by running the pm_rpm tests of the test suite. It can
probably be reproduced by any of the tests that do modesets too.
Regression introduced by:
commit acfa75b02e72bad7c93564ac379712e29c001432
Aut
From: Paulo Zanoni
The current code only runs when we do an I915_WRITE operation. It
checks if the unclaimed register flag is set before we do the
operation, and then it checks it again after we do the operation. This
double check allows us to find out if the I915_WRITE operation in
question is t
On Wed, May 21, 2014 at 04:23:20PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because this will trigger "Unclaimed register" messages. All I need to
> reproduce this problem is to boot my HSW machine with eDP+HDMI
> connected.
>
> Regression introduced by:
>
> commit 9ed109a7b445e3f073
On Wed, 21 May 2014 19:50:53 +0100
Chris Wilson wrote:
> On Wed, May 21, 2014 at 11:42:25AM -0700, Jesse Barnes wrote:
> > In some cases to enable or disable features & workarounds, we may need
> > to check the GPU stepping. Add a macro to do that based on caching the
> > PCI revision ID reg.
>
From: Paulo Zanoni
With the current code, we unconditionally touch
HSW_AUD_PIN_ELD_CP_VLD, which means we can touch it when the power
well is off, and that will trigger an "Unclaimed register" message.
Just adding the intel_crtc->config.has_audio should already avoid the
unclaimed register messs
On Wed, May 21, 2014 at 05:29:31PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> With the current code, we unconditionally touch
> HSW_AUD_PIN_ELD_CP_VLD, which means we can touch it when the power
> well is off, and that will trigger an "Unclaimed register" message.
>
> Just adding the in
Reviewed-by Rodrigo Vivi
On Wed, May 21, 2014 at 4:04 AM, wrote:
> From: Ville Syrjälä
>
> We have to write to the primary plane base address registrer when we
> enable/disable the primary plane in response to sprite coverage. Those
> writes will cause the flip counter to increment which coul
> >
> > This RFC is based on previous discussion to set up a generic
communication channel between display and audio driver and
> > an internal design of Intel MCG/VPG HDMI audio driver. It's still an
initial draft and your advice would be appreciated
> > to improve the design.
> >
> > The basic id
On May-21-2014 6:03 PM, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 04:40:04PM +0530, Vandana Kannan wrote:
>> Adding relevant read out comparison code, in check_crtc_state, for the new
>> member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
>> values for a DP downclock mode (
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_drv.h between commit f93e94efebbe ("drm/i915:
Fix dynamic allocation of physical handles") from the drm-intel-fixes
tree and commit 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user
pages into video
Adding relevant read out comparison code, in check_crtc_state, for the new
member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
values for a DP downclock mode (if available). Suggested by Daniel.
v2: Changed patch title.
Daniel's review comments incorporated.
Added relevant stat
On Wed, 2014-05-21 at 21:43 +0300, Ville Syrjälä wrote:
> On Wed, May 21, 2014 at 11:11:15AM -0700, Jesse Barnes wrote:
> > And to answer more specifically...
> >
> > On Wed, 21 May 2014 20:54:03 +0300
> > Ville Syrjälä wrote:
> >
> > > > + __vlv_set_power_well(dev_priv,
> > > > P
95 matches
Mail list logo
