From: Sagar Kamble
Started documenting drm properties for drm drivers. This patch provides
information about properties in drm, i915, psb and cdv/gma-500. Information
about other properties can be added on top of these.
v2: Added description of drm properties in armada, exynos, i2c/ch7006, novea
From: Sagar Kamble
Started documenting drm properties for drm drivers. This patch provides
information about properties in drm, i915, psb and cdv/gma-500. Information
about other properties can be added on top of these.
v2: Added description of drm properties in armada, exynos, i2c/ch7006, novea
On VLV systems addressing 4GB of memory or greater, memory corruption was seen
when initializing and attempting to render VP8 hardware decode surfaces using
the VXD392 HW IP block.
The VXD MMU has a limitation to addressing only 32bits. On 64bit kernel and
user space builds this can cause problem
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.
On a similar note, intel_display.c already had a function called
intel_disab
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 132 ++-
drivers/gpu/drm/i9
Before we add additional types of planes to the DRM plane list, ensure
that existing loops over all planes continue to operate only on
"overlay" planes and ignore primary & cursor planes.
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 6 +
From: Paulo Zanoni
Hi
This series depends on:
- [PATCH 0/6] More runtime PM fixes
- [PATCH 00/16] Merge PC8 with runtime PM, v3
- [PATCH 00/20] ILK+ interrupt improvements, v2
Patches 1 and 2 are the last pieces of my runtime PM rework, and patch 1 needs
all the previous patches to be merged
From: Paulo Zanoni
This sould be enough.
v2: BDW should also run hsw_runtime_resume (Ben).
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 8 ++--
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Paulo Zanoni
Now that we don't keep the hotplug interrupts enabled anymore, we can
kill the regsave struct and just cal the normal IRQ preinstall,
postinstall and uninstall functions. This makes it easier to add
runtime PM support to non-HSW platforms.
The only downside is in case we get a
From: Paulo Zanoni
That's what the spec said! And HSW needs it through pcode (you can
only read it through MCHBAR), so create hsw_write_dcomp to abstract
the weirdness.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 28 ++--
1 file changed, 18 in
From: Paulo Zanoni
We're adding runtime suspend support to more platforms, so organize
the code in a way that all a new platform needs to do is to add its
own gen-specific functions. Also rename the i915_ functions to intel_
to make it clear that it's the top level one, not something that just
ru
From: Paulo Zanoni
Now that PC8 is part of runtime PM, the check is useless.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 10 ++
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_display.c | 4
3 files changed, 2 insertions(+), 13 d
From: Paulo Zanoni
Just because I have a SNB machine and I can easily test it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 27 +--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 7 +++
3 files changed
From: Paulo Zanoni
Missing from gen8_irq_uninstall.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3584a16d..1e5cc5b 100644
--- a/drivers/gpu/drm/i915/
From: Paulo Zanoni
To merge the common code of ironlake_irq_preinstall and
ironlake_irq_uninstall.
We should also probably do something about that HSWSTAM write on a
later commit.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 23 ---
1 file changed, 12
From: Paulo Zanoni
On the preinstall stage we should just disable all the interrupts, but
we currently enable all the south display interrupts due to the way we
touch SDEIER at the IRQ handlers (note: they are still masked and our
IRQ handler is disabled). Instead of doing that, let's make the
pr
From: Paulo Zanoni
I previously chose to keep the POSTING_READ calls as something to be
done by the macro callers, but the conclusion after discussing this on
the mailing list is that leaving the POSTING_READ calls to the macros
makes the code safer, and the additional useless register reads
shou
From: Paulo Zanoni
We should only enable interrupts at postinstall.
And now on ILK/SNB/IVB/HSW the irq_preinstall and irq_postinstall
functions leave the hardware in the same state.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 10 --
1 file changed, 4 insertions(+
From: Paulo Zanoni
And the equivalent GEN8_IRQ_INIT_NDX macro. These macros are for the
postinstall functions. The next patch will improve this macro.
Notice that I could have included POSTING_READ calls to the macro, but
that would mean the code would do a few more POSTING_READs than
necessary.
From: Paulo Zanoni
The IRQ_INIT and IRQ_FINI macros are basically the same thing, with
the exception that IRQ_FINI doesn't properly clear IIR twice and
doesn't have as many POSTING_READs as IRQ_INIT. So rename the macro to
IRQ_RESET and use it everywhere.
Signed-off-by: Paulo Zanoni
---
driver
From: Paulo Zanoni
Same as the _INIT macro: the goal is to reuse the GEN8 macros, but
there are still some slight differences.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i
From: Paulo Zanoni
Instead of trying to clear it again. It should already be masked and
disabled and zeroed at preinstall/uninstall.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --
From: Paulo Zanoni
After the latest changes, ibx_irq_preinstall and ibx_irq_uninstall are
the same, so remove one of the copies and rename the other to
ibx_irq_reset (since we're using the "reset" name for things which are
called both at preinstall and uninstall).
Signed-off-by: Paulo Zanoni
--
From: Paulo Zanoni
The duplicate was at an _uninstall function, so rename it to
gen5_gt_irq_reset.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i
From: Paulo Zanoni
Just like ibx_irq_preinstall. We'll call this from somewhere else in
the next patch.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/d
From: Paulo Zanoni
Same as SERR_INT and the other IIR registers: reset on
preinstall/uninstall and WARN for non-zero values at postinstall. This
one also doesn't need double-clear.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 7 +--
1 file changed, 5 insertions(+), 2 d
From: Paulo Zanoni
After all, we call ibx_irq_preinstall from gen8_irq_preinstall.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ff0c63d..95f535b 1006
From: Paulo Zanoni
So we can merge all the common code from postinstall and uninstall.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/d
From: Paulo Zanoni
It's the only thihg missing, apparently.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a9f173c..f681462 100644
--- a/drivers/gpu/dr
From: Paulo Zanoni
This interrupt gets initialized with a different IER value, so it was
not using the macro. The problem is that we plan to modify the macro
to make it do additional things, and we want the SDE interrupts
updated too. So let's make sure we call the macro, then, after it, we
do th
From: Paulo Zanoni
Hi
This is basically a rebase of "[PATCH 00/19] ILK+ interrupt improvements", which
was sent to the mailing list on January 22. There are no real differences,
except for the last patch, which is new.
Original cover letter:
http://lists.freedesktop.org/archives/intel-gfx/2014-
From: Paulo Zanoni
The SERR_INT register is very similar to the other IIR registers, so
let's zero it at preinstall/uninstall and WARN for a non-zero value at
postinstall, just like we do with the other IIR registers. For this
one, there's no need to double-clear since it can't store more than
on
From: Paulo Zanoni
The goal is to reuse the GEN8 macros, but a few changes are needed, so
let's make things easier to review.
I could also use these macros on older code, but since I plan to
change how the interrupts are initialized, we'll risk breaking the
older code in the next commits, so I'l
From: Paulo Zanoni
And rename is to GEN5_IRQ_INIT.
We have discussed doing equivalent changes on July 2013, and I even
sent a patch series for this: "[PATCH 00/15] Unify interrupt register
init/reset". Now that the BDW code was merged, I have one more
argument in favor of these changes.
Here's
From: Paulo Zanoni
The only remaining field of the struct was the lock, which was
useless.
v2: - Rebase.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 --
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/intel_pm.c |
From: Paulo Zanoni
When other platforms add runtime PM support they will also need to
disable interrupts, so move the variable to the runtime PM struct.
Also notice that the longer-term goal is to completely kill the
regsave struct, and I even have patches for that.
v2: - Rebase.
v3: - Rebase.
From: Paulo Zanoni
Function intel_init_runtime_pm is supposed to start allowing runtime
PM from that point, but it's called very late on the driver
initialization code, to prevent the driver from trying to suspend
while still initializing. The problem is that variables are accessed
earlier than t
From: Paulo Zanoni
It was just being used on debugfs and on a WARN inside
hsw_set_power_well. But now that we PC8 is part of runtime PM and we
get/put runtime PM when we get/put any power domain, we shouldn't need
the WARN anymore.
v2: - Rebase.
v3: - Rebase.
Reviewed-by: Jesse Barnes
Signed-o
From: Paulo Zanoni
Because we merged the PC8 and runtime PM features, so calling
intel_runtime_pm_get now has the same meaning, and we plan to just
remove hsw_disable_package_c8 for this exact reason.
My first patch tried to completely kill
intel_aux_display_runtime_get/put, because I was assumi
From: Paulo Zanoni
We already get runtime PM references, and PC8 is now part of runtime
PM, so this is enough.
v2: - Rebase.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/
From: Paulo Zanoni
Now that PC8 got much simpler, there are less things to document.
Also, runtime PM already has a nice documentation, so we don't need to
re-explain it on our driver.
v2: - Rebase.
- Fix typo (Jesse).
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
---
drivers/gpu
From: Paulo Zanoni
After we removed all the intermediate abstractions, we can rename
these functions to just hsw_{en,dis}able_pc8.
v2: - Rebase.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/intel_display.c | 4 +
From: Paulo Zanoni
After the latest changes, the indirection is useless.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b
From: Paulo Zanoni
Because we already get/put runtime PM every time we get/put any power
domain, and now PC8 and runtime PM are the same thing.
With this, we can also now kill the hsw_{en,dis}able_package_c8
functions.
v2: - Rebase.
v3: - Rebase.
v4: - Rebase.
Reviewed-by: Jesse Barnes
Signed
From: Paulo Zanoni
Any power domain will require the HW to be in PCI D0 state, so just do
the simple thing.
Dear maintainer: since intel_display_power_put() and
intel_display_power_get() are almost identical, git-am has failed
apply the patch on my local machine once: it added both chunks to
put
From: Paulo Zanoni
When we merge PC8 and runtime PM, these new functions are going to be
called by the runtime suspend/resume functions, and their callers are
going to be removed.
v2: - Rebase
Reviewed-by: Imre Deak (v1)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c |
From: Paulo Zanoni
Since after the latest patches it's only being used to prevent
getting/putting the runtime PM refcount.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i
From: Paulo Zanoni
... instead of PC8 references. Now that both are the same thing and we
are killing PC8, just get the runtime PM reference.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-
From: Paulo Zanoni
Currently, when our driver becomes idle for i915.pc8_timeout (default:
5s) we enable PC8, so we save some power, but not everything we can.
Then, while PC8 is enabled, if we stay idle for more
autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the
graphics devic
From: Paulo Zanoni
The requirements_met variable was used to track two things: enabled
CRTCs and the power well. After the latest chagnes, we get a runtime
PM reference whenever we get any of the power domains, and we get
power domains when we enable CRTCs or the power well, so we should
already
From: Paulo Zanoni
Hi
So this series is obviously the follow up of "Merge PC8 with runtime PM, v2". It
contains the changes requested by our reviewers, a rebase, and the latest
Reviewed-by tags. Daniel asked me to send it on a new thread to avoid confusion,
and I agree this is the best way to pr
From: Paulo Zanoni
Otherwise, when we run intel_modeset_check_state we may already be
runtime suspended, and our state checking code will read registers
while the device is suspended. This can only happen if your
autosuspend_delay_ms is low (not the default 10s) and i915.pc8_timeout
is set to zer
From: Paulo Zanoni
... at edp_have_panel_vdd. Just return false, saying we don't have the
panel VDD since the device is suspended.
We started getting WARNs about this problem since the patch that
started checking if we're suspended while reading registers.
Testcase: igt/pm_pc8
Signed-off-by: Pa
From: Paulo Zanoni
Commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 tried to revert commit
dff392dbd258381a6c3164f38420593f2d291e3b, but wasn't complete, which
resulted in regressions on Haswell. So this commit should fix
b3064154dfd37deb386b1e459c54e1ca2460b3d5 by undoing what it did and
providin
From: Paulo Zanoni
Because gen6_gt_force_wake_{get,put} should already be responsible for
getting/putting runtime PM. If we keep these calls, debugfs will not
be testing the get/put calls of the forcewake functions.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 --
1
From: Paulo Zanoni
To avoid WARNs when we call it.
Testcase: igt/pm_pc8/reg-read-ioctl
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75693
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_uncore.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
From: Paulo Zanoni
Hi
So after Daniel merged that huge amount of patches that had accumulated, I
decided to test runtime PM again and found some regressions. The first two
patches are extremely important: they fix the current regressions and put our
tree back in the state where it was. Without t
From: Paulo Zanoni
So far force_wake_timer was only used by gen6_gt_force_wake_put. Since
we always had balanced gen6_gt_force_wake_get/put calls, we could
guarantee balanced calls to intel_runtime_pm_get/put.
Commit 8232644ccf099548710843e97360a3fcd6d28e04, "drm/i915: Convert
the forcewake work
On Fri, Mar 07, 2014 at 10:14:58AM -0800, Volkin, Bradley D wrote:
> Reviewed-by: Brad Volkin
>
> On Fri, Mar 07, 2014 at 12:30:37AM -0800, Chris Wilson wrote:
> > We don't always want to write into main memory with pwrite. The shmem
> > fast path in particular is used for memory that is cacheabl
Hi all,
New -testing cycle with cool stuff:
- fine-grained display power domains for byt (Imre)
- runtime pm prep patches for !hsw from Paulo
- WiZ hashing flag updates from Ville
- ppgtt setup cleanup and enabling of full 4G range on bdw (Ben)
- fixes from Jesse for the inherited intial config co
On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle wrote:
> On Fri, 2014-03-07 at 13:40 -0700, Bjorn Helgaas wrote:
>> It seems quite possible that I broke pci_bus_alloc_resource(), which could
>> cause an allocation failure like this.
>>
>> If you have a chance to try it, here's a debug patch against v3.
On Fri, Mar 07, 2014 at 09:09:03PM +0100, Daniel Vetter wrote:
> Since the gpu reset + full ppgtt merge we have a hard hang on snb when
> running the gem_reset_stat tests. Recently Mika also some more strict
> forcewake fifo warnigns for gen6/7 in
>
> commit 20277c60ed08ab4f7237854cc6c2046649f9200
On Fri, Mar 07, 2014 at 06:32:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> ILK and IVB don't like switching between sprite only and primary only
> configurations when LP1+ watermarks have been enabled in the recent
> past. Like WaCxSRDisabledForSpriteScaling we can a
On Fri, Mar 07, 2014 at 06:32:14PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We won't be calling intel_enable_primary_plane() or
> intel_disable_primary_plane() with the primary plane in the
> wrong state. So remove the useless DISPLAY_PLANE_ENABLE checks.
>
> Signed-
On Fri, 2014-03-07 at 13:40 -0700, Bjorn Helgaas wrote:
> It seems quite possible that I broke pci_bus_alloc_resource(), which could
> cause an allocation failure like this.
>
> If you have a chance to try it, here's a debug patch against v3.14-rc5. It
> should apply cleanly to 96702be56037. I
Daniel Vetter writes:
> On Thu, Mar 06, 2014 at 11:19:54AM +1030, Rusty Russell wrote:
>> Daniel Vetter writes:
>> > Users just love to set random piles of options since surely enabling
>> > all the experimental stuff helps. Later on we get bug reports because
>> > it all fell apart.
>> >
>> > Ev
Daniel Vetter writes:
> Users just love to set random piles of options since surely enabling
> all the experimental stuff helps. Later on we get bug reports because
> it all fell apart.
>
> Even more fun when it's labelled a regression when some change only
> just made the feature possible (e.g. s
On Fri, Mar 07, 2014 at 06:16:49PM +0100, Paul Bolle wrote:
> Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> > On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote:
> > > This might end up not being relevant. And this is surely documented
> > > somewhere, but anyhow:
> > > - what git magic
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> Can you open a kernel.org bugzilla report and attach complete dmesg
>> logs of the working and broken kernels to it? There might be more
>> useful resource-related messages from the PCI
Since the gpu reset + full ppgtt merge we have a hard hang on snb when
running the gem_reset_stat tests. Recently Mika also some more strict
forcewake fifo warnigns for gen6/7 in
commit 20277c60ed08ab4f7237854cc6c2046649f9200f
Author: Mika Kuoppala
Date: Wed Mar 5 18:08:19 2014 +0200
drm/i
On Fri, Mar 07, 2014 at 07:18:29PM +0100, Hans de Goede wrote:
> Hi,
>
> On 03/07/2014 02:18 PM, Chris Wilson wrote:
> > If we set master_count to non-zero, we won't ever call drmDropMaster
> > (since our get/put will be unbalanced). Does the server manage
> > DRM_MASTER across VT switches for thi
We need to enable interrupt processing before all the modeset
state is set up. But that means we can fall over when we get a pipe
underrun. This shouldn't happen as long as the bios works correctly
but as usual this turns out to be wishful thinking.
So disable error interrupts at irq install time
We need to enable interrupt processing before all the modeset
state is set up. But that means we can fall over when we get a pipe
underrun. This shouldn't happen as long as the bios works correctly
but as usual this turns out to be wishful thinking.
So disable error interrupts at irq install time
On Fri, Mar 7, 2014 at 7:24 PM, Ville Syrjälä
wrote:
>
> I'll withold my r-b until we figure out what to do about the
> "no full modeset"case ;)
Atm that case doesn't really exist outside of fastboot=1. And that has
the much larger issue of not updating the watermarks to our own
power-optimized s
On 03/06/2014 06:27 AM, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> Started documenting drm properties for drm drivers. This patch provides
> information about properties in drm, i915, psb and cdv/gma-500. Information
> about other properties can be added on top of these.
>
> v2: Ad
On Fri, Mar 07, 2014 at 06:11:42PM +0100, Daniel Vetter wrote:
> We need to enable interrupt processing before all the modeset
> state is set up. But that means we can fall over when we get a pipe
> underrun. This shouldn't happen as long as the bios works correctly
> but as usual this turns out to
Reviewed-by: Brad Volkin
On Fri, Mar 07, 2014 at 12:30:37AM -0800, Chris Wilson wrote:
> We don't always want to write into main memory with pwrite. The shmem
> fast path in particular is used for memory that is cacheable - under
> such circumstances forcing the cache eviction is undesirable. As
Hi,
On 03/07/2014 02:18 PM, Chris Wilson wrote:
> On Fri, Mar 07, 2014 at 02:13:38PM +0100, Hans de Goede wrote:
>> Signed-off-by: Hans de Goede
>> ---
>> src/intel_device.c | 19 ++-
>> src/intel_module.c | 4
>> 2 files changed, 10 insertions(+), 13 deletions(-)
>>
>> dif
Reviewed-by: Brad Volkin
On Fri, Mar 07, 2014 at 12:30:36AM -0800, Chris Wilson wrote:
> We used to lock individual pages inside the buffer object and so needed
> to update the page flags every time. However, we now pin the pages into
> the object for the duration of the pwrite/pread (and hopeful
Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote:
> > This might end up not being relevant. And this is surely documented
> > somewhere, but anyhow:
> > - what git magic returns the hashes of the 15 commits that merge commit
> > 96702be5
> I mean what's there in the mode structure. So if we define the border as
> something that reduces hactive/vactice, we'd program the pfit output size as
> hactive-left_border-right_border x vactive-top_border-bottom_border.
> We can't change the already existing structure, so if we want to upda
We need to enable interrupt processing before all the modeset
state is set up. But that means we can fall over when we get a pipe
underrun. This shouldn't happen as long as the bios works correctly
but as usual this turns out to be wishful thinking.
So disable error interrupts at irq install time
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how
From: Kristian Høgsberg
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_m
Some machines may have a broken VBT or no VBT at all, but we still want
to use SSC there. So check for it and keep it enabled if we see it
already on. Based on an earlier fix from Kristian.
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 4
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fi
By stuffing the fb allocation into the crtc, we get mode set lifetime
refcounting for free, but have to handle the initial pin & fence
slightly differently. It also means we can move the shared fb handling
into the core rather than leaving it out in the fbdev code.
v2: null out crtc->fb on error
As of IVB, the memory controller does internal swizzling already, so we
shouldn't need to enable these. Based on an earlier fix from Kristian.
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c| 7 +++
drivers/gpu/drm/i915/i915_gem_tiling
Early at init time, we can try to read out the plane config structure
and try to preserve it if possible.
v2: alloc fb obj at init time after fetching plane config
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/intel_display.c | 92 +++
This should allow BIOS fb inheritance to work on ILK+ machines too.
v2: handle tiled BIOS fbs (Kristian)
split out common bits (Jesse)
v3: alloc fb obj out in _init
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 62
1 file changed
On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> I wouldn't start bisecting yet, but if you're in the mood, this
>> commit: 96702be56037 "Merge branch 'pci/resource' into next" looks
>> like a good place to start, so you could try the
From: Ville Syrjälä
If we mark the LP1+ watermarks as disabled every time sprite scaling
is enabled, we end doing pointless work applying watermarks even though
nothing has changed. This is an artifact of the way
dev_priv->wm.lp_disabled affects the operation of
ilk_setup_pending_watermarks(). If
From: Ville Syrjälä
We may have use for vblank interrupts during plane enabling/disabling, so
don't call drm_vblank_off() until planes are off, and call
drm_vblank_on() just before we start to enable the planes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
From: Ville Syrjälä
Switch the code over to using the two phase watermark update. The steps
generally follow this pattern:
1. Calculate new plane parameters for changed planes
2. Calculate new target and intermediate watermarks
3. Check that both the target and intermediate watermarks are valid
From: Ville Syrjälä
Make sure we programmed the watermarks correctly, by reading out the
hardware state again after programming and comparing it with the
state we supposedly programmed into hardware. Dump the watermark
registers after a mismatch, very much like we for the pipe config.
The only di
From: Ville Syrjälä
Split ilk_update_wm() into two parts; one doing the progragramming
and the other the calculations.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/d
From: Ville Syrjälä
When we switch between one active pipe and multiple active pipes, the
display FIFO gets repartitioned. Disable the LP1+ waterwarks while that
is happening to make sure we don't get any glitches on other active
pipes while doing a modeset on another other pipe.
Signed-off-by:
From: Ville Syrjälä
We need to perform watermark programming before and after changing the
plane configuration. Add two new vfuncs to do that. The pre phase is
supposed to switch over to the intermediate watermarks which are
computed so that they can deal with both the old and new plane
configura
From: Ville Syrjälä
Rather than have a wait_for_vblank() in the primary plane enable/disable
funcs, move the wait_for_vblank() to happen after enabling/disabling all
planes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 7 +--
1 file changed, 5 insertions(+), 2 de
From: Ville Syrjälä
Pull the LP0 validate out from intel_compute_pipe_wm() into a separate
function. We will have further need for such a function to validate
both the final watermarks and the intermediate watermarks we will be
using while the plane(s) transition between different configurations.
1 - 100 of 151 matches
Mail list logo
