On Wed, Nov 20, 2013 at 03:01:03PM -0800, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Wed, Nov 06, 2013 at 11:02:25PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > All the other .enable_fbc() funcs use plane_name(). Make
> > gen7_enable_fbc() do the same
On Tue, Nov 19, 2013 at 09:42:55AM -0800, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi wrote:
> > From: Ville Syrjälä
> >
> > We send the primary and cursor plane data through the gamma unit.
> > In order to get matching output from sprites,
On Wed, Nov 20, 2013 at 11:39 PM, Rodrigo Vivi wrote:
> On Wed, Nov 06, 2013 at 11:02:16PM +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> We need some protection for the FBC state, and since struct_mutex
>> is it currently in most places, make sure all FBC update/disable
(just noticed mutt behind tsocks missed this email)
On Wed, Nov 6, 2013 at 1:02 PM, wrote:
> One more attempt at making FBC suck a bit less.
>
> The main thing as before is getting the LRI based render/blitter
> tracking in place.
>
> In this updates series I decided the way to avoid the kms loc
On Thu, Nov 21, 2013 at 09:08:44AM +0100, Daniel Vetter wrote:
> On Wed, Nov 20, 2013 at 03:01:03PM -0800, Rodrigo Vivi wrote:
> > Reviewed-by: Rodrigo Vivi
> >
> > On Wed, Nov 06, 2013 at 11:02:25PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > All the
On Thu, Nov 21, 2013 at 09:22:43AM +0100, Daniel Vetter wrote:
> On Wed, Nov 20, 2013 at 11:39 PM, Rodrigo Vivi wrote:
> > On Wed, Nov 06, 2013 at 11:02:16PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> >> From: Ville Syrjälä
> >>
> >> We need some protection for the FBC state, and since st
On Thu, Nov 21, 2013 at 09:08:44AM +0100, Daniel Vetter wrote:
> On Wed, Nov 20, 2013 at 03:01:03PM -0800, Rodrigo Vivi wrote:
> > Reviewed-by: Rodrigo Vivi
> >
> > On Wed, Nov 06, 2013 at 11:02:25PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > All the
From: Ville Syrjälä
We need some protection for the FBC state, and since struct_mutex
is it currently in most places, make sure all FBC update/disable
calles are protected by it.
v2: Also protect intel_disable_fbc in i9xx_crtc_disable
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/inte
From: Ville Syrjälä
In order to do the FBC tracking properly for execbuffer, we need to
figure out if the object being rendered to is the current front buffer.
However in order to do that purely based on the crtc, we'd need to
grab crtc->mutex, but we can't since we're already holding struct_mute
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need
On Thu, Nov 21, 2013 at 01:14:10PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> As per the SNB and HSW PM guides, we should enable FBC render/blitter
> tracking only during batches targetting the front buffer.
>
> On SNB we must also update the FBC render tracking addres
From: Paulo Zanoni
If we're disabling the VDD override bit and the panel is enabled, we
don't need to wait for anything. If the panel is disabled, then we
need to actually wait for panel_power_cycle_delay, not
panel_power_down_delay, because the power down delay was already
respected when we disa
From: Paulo Zanoni
When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
a second version of the patch to correct this problem. The problem is
that v1 was merged instead of v2.
I was able to notice the problem wh
On Mon, Nov 18, 2013 at 02:45:47PM -0200, Paulo Zanoni wrote:
> 2013/11/15 Jani Nikula :
> > Similar to
> > commit fdbc3b1f639bb2cbfb32c612b2699e0ba373317d
> > Author: Jani Nikula
> > Date: Tue Nov 12 17:10:13 2013 +0200
> >
> > drm/i915/dp: set sink to power down mode on dp disable
> >
> >
From: Ville Syrjälä
kms_fbc_crc will perform various write operations to the scanout buffer
whilc FBC is enabled. CRC checks will be used to make sure the
modifcations to scanout buffer are detected.
The operations include:
- page flip
- pwrite
- GTT mmap
- CPU mmap
- blit
- rendercopy
-
On Thu, Nov 21, 2013 at 01:47:26PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> So we'll get a fault when someone tries to access the mmap, then we'll
> wake up from D3.
Harsh. Very harsh. Is the GTT completely off-limits under pc8, or is it
only the GTT access to the display engine? i.e.
From: Paulo Zanoni
We just don't need this. This saves 250ms from every modeset on my
machine.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 731a919
On Thu, Nov 21, 2013 at 02:48:55AM +, Gohad, Tushar wrote:
> > On Wed, Nov 20, 2013 at 11:45:03PM +, Gohad, Tushar wrote:
> > > > > On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> > > > > > Folks,
> > > > > >
> > > > > > When filling in an HDMI AVI infoframe, how does one c
From: Paulo Zanoni
And put it when it's off. Otherwise, when you run pm_pc8 from
intel-gpu-tools, and the delayed function that disables VDD runs,
we'll get some messages saying we're touching registers while the HW
is suspended.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c
On Thu, Nov 21, 2013 at 09:29:52PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> FBC host modification tracking only works through GTT mmaps, so any
> direct CPU access needs to manually nuke the compressed framebuffer
> on modifications. Hook up the dirtyfb ioctl to do ju
On Thu, Nov 21, 2013 at 09:29:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Flush the caches when moving a scanout buffer from CPU to GTT domain.
> This allows us to move a scanout buffer to CPU write domain, do some
> writes, and move it back to the GTT read domain.
On Thu, Nov 21, 2013 at 09:29:45PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SNB has another register where the actual FBC CPU fence number is
> stored. The documenation explicitly states that the fence number
> in DPFC_CTL must be 0 on SNB. And in fact when it's not z
From: Paulo Zanoni
This patch adds the initial infrastructure to allow a Runtime PM
implementation that sets the device to its D3 state. The patch just
adds the necessary callbacks and the initial infrastructure.
We still don't have any platform that actually uses this
infrastructure, we still d
From: Ville Syrjälä
The FBC RT address is stored in the context, and thus needs to be
rewritten after a context switch before any batches are run. We emit
the LRI to update the FBC RT address when we call the ring ->flush
function to invalidate the caches.
When a context switch is being performe
From: Paulo Zanoni
Sometimes we want to disable all the screens on a system, because that
will allow the graphics card to be put into low-power states. The
problem is that, for example, while all screens are disabled, if we
get a hotplug interrupt, fbcon will decide to set a mode instead of
keepi
From: Paulo Zanoni
When we call intel_dp_i2c_init we already get some I2C calls, which
will trigger a VDD enable, which will make use of the panel power
sequencing registers, so we need to have them ready by this time.
The good side is that we were reading the values, but were not using
them for
On Thu, Nov 21, 2013 at 01:47:32PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The eDP spec defines some points where after you do action A, you have
> to wait some time before action B. The thing is that in our driver
> action B does not happen exactly after action A, but we still use
>
From: Paulo Zanoni
I don't see a reason to touch VDD when we're disabling the panel:
since the panel is enabled, we don't need VDD. This saves a few sleep
calls from the vdd_on and vdd_off functions at every modeset.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 1 -
driv
From: Paulo Zanoni
The current code was checking if all bits of "val" were enabled and
DE_PCH_EVENT_IVB was disabled. The new code doesn't care about the
state of DE_PCH_EVENT_IVB: it just checks if everything else is 1.
The goal is that future patches may completely disable interrupts, and
the
From: Borislav Petkov
Too many t's.
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Borislav Petkov
---
drivers/gpu/drm/i915/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/driv
From: Paulo Zanoni
Hi
This series adds Haswell runtime PM support, which will put the graphics device
in D3 state, saving a lot of power. Fore more information, see the previous
cover letter:
http://lists.freedesktop.org/archives/intel-gfx/2013-October/034910.html
What changes from the previo
On Thu, Nov 21, 2013 at 01:47:20PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now that we are actually setting the device to the D3 state, we should
> issue the notification.
Can you please add a snippet to justify the ordering? Is there anything
to say what state the callee expects the
On Thu, Nov 21, 2013 at 06:33:21PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 21, 2013 at 11:49:47AM +, Chris Wilson wrote:
> > On Thu, Nov 21, 2013 at 01:14:10PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > As per the SNB and HSW PM guides, we should
On Thu, Nov 21, 2013 at 01:47:27PM -0200, Paulo Zanoni wrote:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0a19401..199d0c0 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -368,6 +368,12 @@ static bool drm_fb_he
From: Ville Syrjälä
rendercopy does the batch buffer flush internally, so if we want
to use it with multiple contexts, we need to pass the context
in from caller.
Signed-off-by: Ville Syrjälä
---
lib/rendercopy.h| 5 +
lib/rendercopy_gen6.c | 12 +++-
lib
On Thu, Nov 21, 2013 at 11:49:47AM +, Chris Wilson wrote:
> On Thu, Nov 21, 2013 at 01:14:10PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > As per the SNB and HSW PM guides, we should enable FBC render/blitter
> > tracking only during batches targetting the fron
From: Paulo Zanoni
The eDP spec defines some points where after you do action A, you have
to wait some time before action B. The thing is that in our driver
action B does not happen exactly after action A, but we still use
msleep() calls directly. What this patch happens is that we record the
tim
From: Ville Syrjälä
The ILK/SNB docs don't really mention the the DPFC_HT_MODIFY bit.
CTG docs clearly state that it should be set only when tracking
back buffer modification in persistent mode. The bit is supposed
to be set by software after the first CPU modification to the
back buffer, and it
From: Ville Syrjälä
Flush the caches when moving a scanout buffer from CPU to GTT domain.
This allows us to move a scanout buffer to CPU write domain, do some
writes, and move it back to the GTT read domain. The display will then
see the correct data. In addition we still need to do the dirtyfb
i
From: Ville Syrjälä
ILK should work pretty much the same as SNB, except it
doesn't have the blitter, so we only care about render tracking.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 --
drivers/gpu/drm/i915/in
From: Borislav Petkov
gcc complains that:
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’:
drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used
uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ‘val’ was
From: Paulo Zanoni
If I add code to enable runtime PM on my Haswell machine, start a
desktop environment, then enable runtime PM, these functions will
complain that they're trying to read/write registers while the
graphics card is suspended.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915
2013/11/21 Chris Wilson :
> On Thu, Nov 21, 2013 at 01:47:26PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> So we'll get a fault when someone tries to access the mmap, then we'll
>> wake up from D3.
>
> Harsh. Very harsh. Is the GTT completely off-limits under pc8
Under D3, not PC8.
>
On Thu, Nov 21, 2013 at 04:49:46PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> gcc complains that:
>
> drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’:
> drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used
> uninitialized in this functio
From: Paulo Zanoni
These are needed when we cat the debugfs and sysfs files.
V2: - Rebase
V3: - Rebase
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 45 ++---
drivers/gpu/drm/i915/i915_sysfs.c | 14 ++--
drivers/gpu/drm/i915/in
From: Ville Syrjälä
The ILK/SNB docs are a bit unclear what the persistent mode does, but
the CTG docs clearly state that it was meant to be used when we're
tracking back buffer modifications. We never do that, so leave it in
non-persistent mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/dr
From: Paulo Zanoni
The plan is to merge PC8 and D3 into a single feature, and when we're
in D3 we won't get any hotplug interrupt anyway, so leaving them
enable doesn't make sense, and it also brings us a problem. The
problem is that we get a hotplug interrupt right when we we wake up
from D3, wh
From: Paulo Zanoni
The code to enable/disable PC8 already takes care of saving and
restoring all the registers we need to save/restore, so do a put()
call when we enable PC8 and a get() call when we disable it.
Ideally, in order to make it easier to add runtime PM support to other
platforms, we
From: Paulo Zanoni
In the current code, at haswell_modeset_global_resources, first we
decide if we want to enable/disable the power well, then we decide if
we want to enable/disable PC8. On the case where we're enabling PC8
this works fine, but on the case where we disable PC8 due to a non-eDP
mo
At least on my VLV stepping VGA detection doesn't work in certain cases.
One such case is when all pipes are off and VGA is plugged in. Another
case reported by Joonas Lahtinen (also on the same stepping) is booting
with VGA disconnected where we incorrectly report that VGA is connected.
At least i
On Thu, Nov 21, 2013 at 01:47:21PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If I add code to enable runtime PM on my Haswell machine, start a
> desktop environment, then enable runtime PM, these functions will
> complain that they're trying to read/write registers while the
> graphics
From: Paulo Zanoni
So we'll get a fault when someone tries to access the mmap, then we'll
wake up from D3.
This fixes the gem-mmap-gtt subtest from pm_pc8 from intel-gpu-tools.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drive
From: Ville Syrjälä
FBC host modification tracking only works through GTT mmaps, so any
direct CPU access needs to manually nuke the compressed framebuffer
on modifications. Hook up the dirtyfb ioctl to do just that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 19 ++
From: Ville Syrjälä
On FBC2 (CTG+) page flips will automagically nuke FBC, so the only thing
we need to do on page flip is update the CPU fence information.
On FBC1 we need to to disable+re-enable FBC around page flips. Previously
we just called intel_disable_fbc() + intel_update_fbc() to do tha
From: Ville Syrjälä
SNB has another register where the actual FBC CPU fence number is
stored. The documenation explicitly states that the fence number
in DPFC_CTL must be 0 on SNB. And in fact when it's not zero,
the GTT tracking simply doesn't work.
Signed-off-by: Ville Syrjälä
---
drivers/gp
On Thu, Nov 21, 2013 at 05:10:30PM +0100, Richard Weinberger wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 6ed45a984230..1191aa47adc9 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
On Thu, Nov 21, 2013 at 07:19:45PM +0200, Ville Syrjälä wrote:
> > > It seems natural to extend those flags to describe the picture aspect
> > > ratio (that
> > > why dri-devel is in Cc., touching core DRM).
> >
> > To start with we can use a single bit in drm_display_mode->flags to
> > distingu
From: Paulo Zanoni
We already have some checks and shouldn't be reaching these places on
!HAS_PC8 platforms, but add a WARN, just in case.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_di
From: Ville Syrjälä
Not all drivers will need take all the modeset locks for dirtyfb, so
push the locking down to the drivers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 2 --
drivers/gpu/drm/omapdrm/omap_fb.c | 4
drivers/gpu/drm/qxl/qxl_display.c | 9 +
From: Paulo Zanoni
Currently, PC8 is enabled at modeset_global_resources, which is called
after intel_modeset_update_state. Due to this, there's a small race
condition on the case where we start enabling PC8, then do a modeset
while PC8 is still being enabled. The racing condition triggers a WARN
Another set of FBC patches, which should fit on top of the previous set:
"[PATCH 00/10] drm/i915: FBC fixes v2"
The persistent mode and HT tracking bit stuff is a bit unclear in the docs,
but I can remove it all, and everything still seems to work fine.
The page flip and dirtyfb stuff is maybe a
On Thu, Nov 21, 2013 at 01:47:18PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Currently, PC8 is enabled at modeset_global_resources, which is called
> after intel_modeset_update_state. Due to this, there's a small race
> condition on the case where we start enabling PC8, then do a modese
From: Paulo Zanoni
Now that we are actually setting the device to the D3 state, we should
issue the notification.
Jani originally wrote a similar patch for PC8, but then we discovered
that we were not really changing the PCI D states when
enabling/disabling PC8, so we had to postpone his patch.
On Thu, Nov 21, 2013 at 03:29:55PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Too many t's.
>
> Cc: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Borislav Petkov
Queued for -next, thanks for the patch.
-Daniel
> ---
>
On Thu, Nov 21, 2013 at 04:39:43PM +, Chris Wilson wrote:
> On Thu, Nov 21, 2013 at 06:33:21PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 21, 2013 at 11:49:47AM +, Chris Wilson wrote:
> > > On Thu, Nov 21, 2013 at 01:14:10PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
65 matches
Mail list logo
