On Sun, Apr 15, 2012 at 07:03:18PM +0100, Chris Wilson wrote:
> On Sun, 15 Apr 2012 19:53:19 +0200, Daniel Vetter
> wrote:
> > This regression has been introduced in
> >
> > commit ca9bfa7eed20ea34e862804e62aae10eb159edbb
> > Author: Daniel Vetter
> > Date: Sat Jan 28 14:49:20 2012 +0100
> >
On Sun, 15 Apr 2012 21:44:15 -0300, Eugeni Dodonov wrote:
> On Sun, Apr 15, 2012 at 20:49, Daniel Vetter wrote:
> >
> > I'm honestly not too happy with this table, because somewhere in there
> > we'll have an annoying type, and there's almost zero chance we'll ever
> > find that. So I prefer if w
On 830/845, the BLT unit invalidates the wrong PTE in its TLB after the
GATT is updated. A simple solution is then to always invalidate the TLB
of the BLT prior to each execbuffer.
This does appear to improve the stability slighty, but I am still seeing
spurious GPU deaths under memory pressure.
On gen2, MI_EXE_FLUSH is actually an AGP flush bit and is documented as
being must-be-zero. So obey the documentation, and separate the gen2
flush into its own little routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 30 ++
1 file ch
On Mon, Apr 16, 2012 at 09:26:40AM +0100, Chris Wilson wrote:
> On Sun, 15 Apr 2012 21:44:15 -0300, Eugeni Dodonov wrote:
> > On Sun, Apr 15, 2012 at 20:49, Daniel Vetter wrote:
> > >
> > > I'm honestly not too happy with this table, because somewhere in there
> > > we'll have an annoying type, a
On Mon, Apr 16, 2012 at 09:53:17AM +0100, Chris Wilson wrote:
> On 830/845, the BLT unit invalidates the wrong PTE in its TLB after the
> GATT is updated. A simple solution is then to always invalidate the TLB
> of the BLT prior to each execbuffer.
>
> This does appear to improve the stability sli
On Mon, 16 Apr 2012 11:02:13 +0200, Daniel Vetter wrote:
> On Mon, Apr 16, 2012 at 09:53:17AM +0100, Chris Wilson wrote:
> > On 830/845, the BLT unit invalidates the wrong PTE in its TLB after the
> > GATT is updated. A simple solution is then to always invalidate the TLB
> > of the BLT prior to e
Hello,
I'd like to assist in fixing an issue that is quite nagging concerning the
i915 driver. I wasn't sure whether to classify this as a bug, but it's
something worth considering. Let me explain.
When I first used the i915 driver on my Lenovo X220 laptop, I noticed that
every time I run xrandr,
On Mon, Apr 16, 2012 at 09:04, Dan Aloni wrote:
> Hello,
>
> I'd like to assist in fixing an issue that is quite nagging concerning the
> i915 driver. I wasn't sure whether to classify this as a bug, but it's
> something worth considering. Let me explain.
>
> When I first used the i915 driver on
On Mon, 16 Apr 2012 15:04:50 +0300, Dan Aloni wrote:
> Now you might ask why it is annoying. Well, for instance, say you are
> debugging an SDL application. Those type of applications usually result in
> the GET_CONTROLLERS ioctl() being called by the X server, and re-running
> the same applicatio
On Mon, 2012-04-16 at 01:10 +0200, Daniel Vetter wrote:
> But while looking through the git history I've noticed that this code got
> added before we've figured out the vbios sdvo ddc pin mappings game, so
> I'm inclined to just rip this out. Especially since we start at the ddc
> that does _not_
Upon lastclose(), we switch back to the fbcon configuration. This
requires taking the mode_config lock in order to serialise the change
with output probing elsewhere.
Reported-by: Oleksij Rempel
References: https://bugs.freedesktop.org/show_bug.cgi?id=48652
Signed-off-by: Chris Wilson
Cc: sta...
As we may kick off a delayed workqueue task to switch of the VDD lines, we
need to complete that task prior to turning off the panel (which itself
depends upon VDD being off).
Signed-off-by: Chris Wilson
Cc: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 +++
1 file changed, 7 ins
IvyBridge has the ability to pageflip from either the Render or Blitter
rings. Scheduling the pageflip on the active ring (if the new scanout is
being rendered on either pipeline) saves inserting a semaphore (if
available) and forcing a stall on both pipelines. We presume that the
current scanout i
On Mon, 16 Apr 2012 15:29:41 +0100, Chris Wilson
wrote:
> + ring = obj->ring;
> + if (ring == NULL || ring == &dev_priv->ring[RCS])
should have been: ring == &dev_priv->ring[VCS]
This does require testing on IVB, since the BCS was choosen for a
reason, I'm sure.
-Chris
--
Chris Wilson,
On Sat, 14 Apr 2012 22:14:26 +0100
Chris Wilson wrote:
> As I do not see the output update without the scaler enabled on my
> i3-330m, always enable it.
>
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_sprite.c |5 +++--
> 1 file changed, 3 insertions(
On Sat, 14 Apr 2012 21:56:08 +0100
Chris Wilson wrote:
> Rather than export every single architecture specific update_wm, just
> export the wrapper around the display vtable.
>
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> ---
Looks good.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, In
On Mon, 16 Apr 2012 08:00:17 -0700, Jesse Barnes
wrote:
> Funky... do you notice any difference in output (fuzziness or anything)
> with the scaler enabled? Wonder if it's safe to enable for 1:1 scaling
> on SNB as well.
Hard to tell. Without the scaler being enabled, it is black. :)
The conte
On Mon, 16 Apr 2012 16:14:25 +0100
Chris Wilson wrote:
> On Mon, 16 Apr 2012 08:00:17 -0700, Jesse Barnes
> wrote:
> > Funky... do you notice any difference in output (fuzziness or anything)
> > with the scaler enabled? Wonder if it's safe to enable for 1:1 scaling
> > on SNB as well.
>
> Har
On Mon, Apr 16, 2012 at 4:33 PM, Eugeni Dodonov wrote:
> On Mon, Apr 16, 2012 at 09:04, Dan Aloni wrote:
>
>> Hello,
>>
>> I'd like to assist in fixing an issue that is quite nagging concerning
>> the i915 driver. I wasn't sure whether to classify this as a bug, but it's
>> something worth consi
On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote:
> Okay, with 3.4-rc3 I can confirm that it works much better. For the
> xrandr test case, I've timed each ioctl to about 60 milli-secs with 9
> calls spanning over half a second. Any further suggestions? Isn't it
> possible to tell that nothing i
On Mon, Apr 16, 2012 at 7:37 PM, Adam Jackson wrote:
> On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote:
>
> > Okay, with 3.4-rc3 I can confirm that it works much better. For the
> > xrandr test case, I've timed each ioctl to about 60 milli-secs with 9
> > calls spanning over half a second. Any
On Mon, Apr 16, 2012 at 08:00:17AM -0700, Jesse Barnes wrote:
> On Sat, 14 Apr 2012 22:14:26 +0100
> Chris Wilson wrote:
>
> > As I do not see the output update without the scaler enabled on my
> > i3-330m, always enable it.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jesse Barnes
> > ---
> >
On Mon, Apr 16, 2012 at 08:03:25AM -0700, Jesse Barnes wrote:
> On Sat, 14 Apr 2012 21:56:08 +0100
> Chris Wilson wrote:
>
> > Rather than export every single architecture specific update_wm, just
> > export the wrapper around the display vtable.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jess
On Mon, Apr 16, 2012 at 03:16:42PM +0100, Chris Wilson wrote:
> Upon lastclose(), we switch back to the fbcon configuration. This
> requires taking the mode_config lock in order to serialise the change
> with output probing elsewhere.
>
> Reported-by: Oleksij Rempel
> References: https://bugs.fre
On Mon, Apr 16, 2012 at 03:18:33PM +0100, Chris Wilson wrote:
> As we may kick off a delayed workqueue task to switch of the VDD lines, we
> need to complete that task prior to turning off the panel (which itself
> depends upon VDD being off).
>
> Signed-off-by: Chris Wilson
> Cc: Keith Packard
On Mon, 16 Apr 2012 22:39:51 +0200, Daniel Vetter wrote:
> On Mon, Apr 16, 2012 at 03:18:33PM +0100, Chris Wilson wrote:
> > As we may kick off a delayed workqueue task to switch of the VDD lines, we
> > need to complete that task prior to turning off the panel (which itself
> > depends upon VDD b
Corrected my name in the patch (acreese -> Armin Reese) ...
The attached patch file was updated to reflect reviewer's comments. The only
change I did not make was using PAGE_MASK instead of DISP_BASEADDR_MASK.
PAGE_MASK is CPU architecture dependent and I didn't want to tie our GPU
addressing
Patch 1/2 is a mix of fairly trivial stuff. I see no reason to not take
these.
Patch 3-9 Are all __iomem related. These should run through some
regression testing.
Most of the __iomem stuff fell into place fairly easily, but it's
definitely subject to a lot of copy/paste errors, since trying to
au
This should contain all the changes which require no thought to make
sparse happy.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_ioc32.c|5 -
drivers/gpu/drm/i915/i
Sparse doesn't like:
"error: bad constant expression"
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_sdvo.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index aa1
Almost all of the errors related __iomem problems.
Most of the changes here are trivial, however there is plenty of chance
for yank/paste errors.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 10 ++---
drivers/gpu/drm/i915/intel_opregion.c | 67 +++-
With the exception of a forced cast for phys_obj stuff (a problem in
other patches as well) all of these are fairly simple __iomem compliance
fixes.
As with other patches, yank/paste errors may exist.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_overlay.c | 130 ++
These were mostly straight forward. No forced casting needed.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_deb
Only one case of a "forced" casting where we use ring->map.handle and
cast it to __iomem. As with other patches, this should be safe always.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --gi
It should be safe to do this since GEN driver is only ever for x86, an
__iomem and dma mem should be the same. However, these changes caused me
to really think and try multiple solutions. Someone may come along and
decide to do something better with these.
Signed-off-by: Ben Widawsky
---
drivers
As with one of the earlier patches in the series, we're forced to cast
for copy_[to|from]_user. Again because of the nature of the GEN x86
exclusivity, this should be safe.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
1 file changed, 6 insertions(+), 5 dele
This is only the first part of the patch which does the correct types.
The fix for dereferencing stuff was taking too long, so I've stopped.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_bios.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git
On Mon, 16 Apr 2012 14:07:40 -0700, Ben Widawsky wrote:
> This should contain all the changes which require no thought to make
> sparse happy.
In a couple of spots, we make a structure/array static. Are they
suitable for const as well?
Otherwise, looks sane:
Reviewed-by: Chris Wilson
-Chris
--
On Mon, 16 Apr 2012 14:07:45 -0700, Ben Widawsky wrote:
> rem /= 8;
> while (rem--) {
> - *virt++ = MI_NOOP;
> - *virt++ = MI_NOOP;
> + iowrite32(MI_NOOP, virt);
> + virt+=4;
> + iowrite32(MI_NOOP, virt);
> + virt+
As we may kick off a delayed workqueue task to switch of the VDD lines, we
need to complete that task prior to turning off the panel (which itself
depends upon VDD being off).
v2: Don't cancel the outstanding work as this may trigger a deadlock
Signed-off-by: Chris Wilson
Cc: Keith Packard
---
On Mon, Apr 16, 2012 at 10:01:42PM +0100, Chris Wilson wrote:
> On Mon, 16 Apr 2012 22:39:51 +0200, Daniel Vetter wrote:
> > On Mon, Apr 16, 2012 at 03:18:33PM +0100, Chris Wilson wrote:
> > > As we may kick off a delayed workqueue task to switch of the VDD lines, we
> > > need to complete that ta
On Mon, Apr 16, 2012 at 10:43:42PM +0100, Chris Wilson wrote:
> As we may kick off a delayed workqueue task to switch of the VDD lines, we
> need to complete that task prior to turning off the panel (which itself
> depends upon VDD being off).
>
> v2: Don't cancel the outstanding work as this may
On 04/14/2012 06:41 PM, Ben Widawsky wrote:
This originally started as a patch from Bernard as a way of simply
setting the VS scheduler. After submitting the RFC patch, we decided to
also modify the DS scheduler. To be most explicit, I've made the patch
explicitly set all scheduler modes, and inc
On Mon, 16 Apr 2012 20:06:01 -0300, Eugeni Dodonov
wrote:
> As previously discussed on irc with Daniel, Ben and Jesse, This patch
> moves the power-related functionality into intel_pm module, aiming at
> simplifying the intel_display code and make it less cluttered.
>
> The functionality affecte
On Mon, Apr 16, 2012 at 20:23, Chris Wilson wrote:
> On Mon, 16 Apr 2012 20:06:01 -0300, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
> > As previously discussed on irc with Daniel, Ben and Jesse, This patch
> > moves the power-related functionality into intel_pm module, aiming at
> > simpl
As Chris Wilson noticed, my previous patch that did the refactoring as one big
patch which moved everything at once was extremely difficult to review and
maintain. So I split the same refactoring into a series of smaller patches,
which move one subsystem at a time.
As previously, this reduces the
This commit moves Frame Buffer Compression-related operations and support
functions into the new intel_pm module.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_display.c | 484 ---
drivers/gpu/drm/i915/int
This moves DRPS, RPS and RC6-related functionality into intel_pm module.
It also removes the linux/cpufreq.h include from intel_display, as its
only user was the GPU turbo-related functionality in Gen6+ code path.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 509 ---
This moves the Ironlake energy monitoring functionality into intel_pm
module.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 86 --
drivers/gpu/drm/i915/intel_pm.c | 86 ++
2 files changed, 86 inse
This moves the clock gating-related functions into intel_pm module.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 328 +-
drivers/gpu/drm/i915/intel_drv.h | 16 ++
drivers/gpu/drm/i915/intel_pm.c | 326 ++
On Mon, 16 Apr 2012 21:08:22 -0300
Eugeni Dodonov wrote:
> On Mon, Apr 16, 2012 at 20:23, Chris Wilson
> wrote:
>
> > On Mon, 16 Apr 2012 20:06:01 -0300, Eugeni Dodonov <
> > eugeni.dodo...@intel.com> wrote:
> > > As previously discussed on irc with Daniel, Ben and Jesse, This
> > > patch moves
This is based on a workaround implemented in the windows driver. I've
tried a similar fix for Sandrybridge with no luck, but it is a bit
different for IVB. This is pretty experimental at this point; hopefully
it helps anyone having any missed IRQ issues ;)
Cc: Jesse Barnes
Cc: Michael Larabel
Si
53 matches
Mail list logo
