On 01/22/2016 09:00 AM, Daniel Vetter wrote:
> On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orou...@intel.com wrote:
>> From: Tom O'Rourke
>>
>> SLPC (Single Loop Power Controller) is a replacement for
>> some host-based power management features. The SLPC
>> implemenation runs in firmware on Gu
On 01/26/2016 09:00 AM, Daniel Vetter wrote:
> On Tue, Jan 26, 2016 at 07:45:42AM -0800, Jesse Barnes wrote:
>> On 01/22/2016 09:00 AM, Daniel Vetter wrote:
>>> On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orou...@intel.com wrote:
>>>> From: Tom O'Rourke
On Jan 12, 2017 8:04 AM, "Chris Wilson" wrote:
On Thu, Jan 12, 2017 at 05:48:49PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Mon, Jan 09, 2017 at 06:52:53PM +0200, Mika Kuoppala wrote:
> >> +static int i915_gem_context_enable_svm(struct i915_gem_context *ctx)
> >> +{
> >> + int
NLAKE(dev)) {
> > + I915_WRITE(ILK_DISPLAY_CHICKEN2,
> > + (I915_READ(ILK_DISPLAY_CHICKEN2) |
> > + ILK_DPARB_GATE | ILK_VSDPFD_FULL));
>
> I can only hope this is named "chicken" i
t_cpu_power(struct ips_driver *ips, u32 *last, int period)
> > +{
> > + u32 val;
> > + u32 ret;
> > +
> > + /*
> > +* CEC is in joules/65535. Take difference over time to
> > +* get watts.
> > +*/
> > + val = thm_readl(THM_
...and hang your box even faster.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 790fef3..11c25ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -240,11 +240,14
Recent hardware supports the PIPE_CONTROL command. It seems to be
necessary for stability on Ironlake at least, and should be a
performance win on other platforms. This patchset (tested on Ironlake
only) adds support for the PIPE_CONTROL command and changes GEM to use
it by default.
There's a st
This keeps the memory manager from complaining when we take it down.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c | 14 ++
drivers/gpu/drm/i915/i915_drv.h |3 +++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
, on Ironlake
and Sandy Bridge hardware.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |4 +
drivers/gpu/drm/i915/i915_gem.c | 145 +++---
drivers/gpu/drm/i915/i915_irq.c |8 +-
drivers/gpu/drm/i915/i915_reg.h | 11 +++
4 files changed
This gives us finer grained cache control, so should be higher performance.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c | 52 +-
1 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers
Since it's supported on 965 and G4x, enable it there as well.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_irq.c | 33 ++---
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm
This allows us to do less cache flushing on 965+ chipsets.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c | 25 +
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index
Avoid unnecessary PIPE_CONTROL flushing on non-Ironlake platforms where
it shouldn't be needed.
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e6a1cc0..56ff905 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gp
Was better safe than sorry, but it appears these bits aren't necessary.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 56
e the HAS_PIPE_CONTROL macro in i915_get_gem_seqno, or
we'll end up reading the wrong graphics memory, likely causing hangs,
crashes, or worse.
Reported-by: Zdenek Kabelac
Reported-by: Toralf Förster
Tested-by: Toralf Förster
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/i915/i9
On Fri, 26 Mar 2010 11:07:19 -0700
Jesse Barnes wrote:
> On 945, vblank delivery alone seems unreliable. The PIPE*STAT bits get
> set correctly, but interrupts occur at a low frequency relative to
> refresh. If we enable VSYNC interrupts as well however (even though we
> only chec
On Thu, 29 Apr 2010 10:23:58 +0200
Tobias Doerffel wrote:
> Hi,
>
> Am Freitag, 23. April 2010, um 17:17:38 schrieb Adam Jackson:
> > Disclaimer: I haven't tested this extensively, it just seems
> > logical, and I really hate to see us lose FBC on gen3 since that's
> > the family being used in l
On Fri, 30 Apr 2010 13:04:23 +0100
Pedro Ribeiro wrote:
> Hi all,
>
> My Xorg.log shows
>
> (**) intel(0): Kernel mode setting active, disabling FBC.
> (**) intel(0): Framebuffer compression disabled
>
> Is this normal? I'm trying to lower power consumption for my laptop...
> Enabling FBC shou
On Fri, 30 Apr 2010 13:04:23 +0100
Pedro Ribeiro wrote:
> Hi all,
>
> My Xorg.log shows
>
> (**) intel(0): Kernel mode setting active, disabling FBC.
> (**) intel(0): Framebuffer compression disabled
>
> Is this normal? I'm trying to lower power consumption for my laptop...
> Enabling FBC shou
On Sat, 1 May 2010 01:01:12 +0100
Pedro Ribeiro wrote:
> On 1 May 2010 00:06, Jesse Barnes wrote:
> > On Fri, 30 Apr 2010 13:04:23 +0100
> > Pedro Ribeiro wrote:
> >
> >> Hi all,
> >>
> >> My Xorg.log shows
> >>
> >> (**) inte
On Thu, 29 Apr 2010 15:52:36 -0700
Eric Anholt wrote:
> > + if (intel_crtc->plane)
> > + flip_mask =
> > I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
> > + else
> > + flip_mask =
> > I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT; +
> > + /* Wait for any previous flip to fin
On Thu, 29 Apr 2010 14:26:38 -0700
Eric Anholt wrote:
> On Wed, 21 Apr 2010 11:39:24 -0700, Jesse Barnes
> wrote:
> > This allows us to do less cache flushing on 965+ chipsets.
>
> I don't think this commit is correct. The ring processing will
> continue past the
On Wed, 5 May 2010 18:14:47 -0700 (PDT)
SD wrote:
> Dear All.
>
> Sorry to disturb you again.
> When I start glxgears on Fedora 13, it tells me that application and
> suppose to be OpenGL, now synchronized to Vertical Refresh Rate
> (VRR), which in my case - laptop LCD = 60. And it also tells me
access to /dev/dri/card0, so was falling back to swrast. When you're using
> swrast, TFP only appears to work for pixmaps you create, not for compositing
> pixmaps.
>
> Sorry for the noise,
What about the indirect bug? Did that also go away when you fixed the
perms issue? If
those
now so I expect to be able to post them soon.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
In some cases (for instance with kernel threads) it may be desireable to
use on-stack deferrable timers to get their power saving benefits. Add
interfaces to support this for the IPS driver.
Signed-off-by: Jesse Barnes
---
include/linux/timer.h | 15 +++
kernel/timer.c
and/or GPU to increase their power consumption,
and thus performance, when possible. The goal is to maximize
performance within a given platform's TDP (thermal design point).
Signed-off-by: Jesse Barnes
---
drivers/platform/x86/Kconfig | 10 +
drivers/platform/x86/Makefile|
x86/intel_ips.c:1361: warning: type defaults to 'int' in
> declaration of 'type name'
> drivers/platform/x86/intel_ips.c:1361: warning: cast from pointer to integer
> of different size
> drivers/platform/x86/intel_ips.c:1361: warning: assignment makes pointer from
&
On Tue, 11 May 2010 07:59:19 -0700
Jesse Barnes wrote:
> On Mon, 10 May 2010 22:00:46 -0400
> Andrew Morton wrote:
> > > +#define thm_readb(off) readb(ips->regmap + (off))
> > > +#define thm_readw(off) readw(ips->regmap + (off))
> > > +#define
On Tue, 11 May 2010 11:38:36 -0400
Andrew Morton wrote:
> On Tue, 11 May 2010 11:18:54 -0700 Jesse Barnes
> wrote:
>
> > > > > +#define thm_writeb(off, val) writeb((val), ips->regmap + (off))
> > > > > +#define thm_writew(off, val) writew((val
ger
> of different size
> drivers/platform/x86/intel_ips.c:1373: warning: assignment makes pointer from
> integer without a cast
>
> Both x86_64 and i386 fail.
>
Updated patch addressing your comments. I still have to figure out how
to handle CPU hotplug, but other than tha
On Sat, 15 May 2010 01:54:56 -0700
Andy Isaacson wrote:
> On Mon, May 10, 2010 at 10:00:46PM -0400, Andrew Morton wrote:
> > > + int i;
> > > + u16 avg;
> > > +
> > > + for (i = 0; i < IPS_SAMPLE_COUNT; i++)
> > > + total += (u64)(array[i] * 100);
> >
> > Actually, that does work. Someh
:
>
> Bug 28079 - "glresize" causes kernel panic in
> intel_finish_page_flip.
> https://bugs.freedesktop.org/show_bug.cgi?id=28079
Yeah, that's true. Good catch.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Int
915/intel_lvds.c | 22 --
> 1 files changed, 20 insertions(+), 2 deletions(-)
Looks good, we should get it upstream early in this cycle to get it
some test coverage. If it doesn't work out it's easy to revert.
Acked-by: Jesse Barnes
--
Jesse Barnes,
Be sure to enable GPU turbo by default at load time and check GPU busy
and MCP exceeded status correctly. Also fix up CPU power comparison and
work around buggy MCH temp reporting.
Signed-off-by: Jesse Barnes
---
drivers/platform/x86/intel_ips.c | 30 +-
1 files
-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c | 56 -
drivers/gpu/drm/i915/i915_dma.c | 529 +-
drivers/gpu/drm/i915/i915_drv.h | 20 ++-
drivers/gpu/drm/i915/i915_irq.c | 28 +--
drivers/gpu/drm/i915/i915_reg.h | 41
FBC disable on 965 can take long enough to trigger latency checks in the
kernel so be sure to timeout after a reasonable period.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15015.
Tested-by: James Ettle
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/i915/intel_display.c
b
d-off-by: Chris Wilson
> Cc: Jesse Barnes
> Cc: Kristian Høgsberg
> ---
> drivers/gpu/drm/i915/intel_display.c | 20
> 1 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/i
On Thu, 27 May 2010 13:18:15 +0100
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_gem.c | 10 +++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b
on we don't have
> that in our Fedora or RHEL backports wierd.
>
> Ignore this.
>
> I don't remember much discussion on changing drm_os_linux, but it
> should have been fine.
We should still kill the drm_os_linux bits where possible...
--
Jesse Barnes, Intel Open Source
#x27;t work. This is git master from today
> (a25573d5c47ebea34c076075e1993233d7db2b4f).
Are these both on 945? If so, can you guys try two of the patches I
posted earlier? In particular:
drm/i915: fix page flipping on gen3
drm/i915: don't queue flips during a flip pending event
(att
ls.
Arg, ok, I'll refresh them and post new ones tomorrow.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
el_no_modeset_on_lid))
> + return NOTIFY_OK;
> if (!acpi_lid_open()) {
> dev_priv->modeset_on_lid = 1;
> return NOTIFY_OK;
Other than the comment issue, this one looks fine to me. We just can't
seem to win when it comes to lid h
On Thu, 17 Jun 2010 19:44:10 -0700
Jesse Barnes wrote:
> On Fri, 18 Jun 2010 02:20:23 +0200
> Marc Deop i Argemí wrote:
>
> > On Friday June 18 2010 02:17:53 Andrew Lutomirski wrote:
> > > Neither patch applies for me.
> >
> > One of them do
On Fri, 18 Jun 2010 13:04:50 -0700
Jesse Barnes wrote:
> On Thu, 17 Jun 2010 19:44:10 -0700
> Jesse Barnes wrote:
>
> > On Fri, 18 Jun 2010 02:20:23 +0200
> > Marc Deop i Argemí wrote:
> >
> > > On Friday June 18 2010 02:17:53 Andrew Lutomirski wrote:
On Mon, 21 Jun 2010 16:32:48 -0400
Andrew Lutomirski wrote:
> On Sun, Jun 20, 2010 at 11:29 AM, Andrew Lutomirski wrote:
> > On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes
> > wrote:
> >> On Thu, 17 Jun 2010 19:44:10 -0700
> >> Jesse Barnes wrote:
> >>
We did this a long time ago in the DDX driver, but now this fix belongs
in the kernel.
Preserving the aspect ratio is a nicer default.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=18033.
Tested-by: Josh Triplett
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
field names, we'll end up double taking everytime we look at these bits.
So there's no good answer here... :/
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
struct
> drm_device *dev)
>
> I915_WRITE(GEN7_UCGCTL4, GEN7_L3BANK2X_CLOCK_GATE_DISABLE);
>
> - g4x_disable_trickle_feed(dev);
> + I915_WRITE(MI_ARB_VLV, MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE);
>
> I915_WRITE(CACHE_MODE_1,
> _MASK
me. But we can restore the fences from dev_priv->fence_regs...
> Actually we have a very similar problem after a GPU reset where we
> should restore fences for pinned objects (i.e. the scanout). The patch
> to fix both looks fairly straightforward.
To be clear, this only affects gen3
vlv_dpio_write(dev_priv, DPIO_LFP_COEFF(pipe),
>0x005f0021);
I think it's ok, but can you specify the doc title in the commit
message? Should make things easier to find in the rat's nest of files
later. :)
--
Jesse Barnes, In
gt;
> Reported-By: Yuly Novikov
> Cc: Jesse Barnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display
se I can do besides using a special kernel with the backed out
> commit ? Is it possible that others have the same problem ?
Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped. Is there a newer one available for your system? I'm hoping
it'll fix the issu
27;t think that is strictly required, just like we should not limit
> > the user from using set_tiling. (Though the user is never actually going
> > to tell the kernel about such tiling...).
>
> Yeah, I guess we could allow people to shot their foot off. Otoh i
elay < dev_priv->rps.rpe_delay)
> + new_delay = dev_priv->rps.rpe_delay;
> + } else
> new_delay = dev_priv->rps.cur_delay - 1;
>
> /* sysfs frequency interfaces may have snuck in while servicing the
Yeah, s
"min GPU freq: %d MHz (%u)\n",
> + vlv_gpu_freq(dev_priv->mem_freq,
> + dev_priv->rps.min_delay),
> + dev_priv->rps.min_delay);
>
> - DRM_DEBUG_DRIVER("setting GPU freq to %d\
utex_unlock(&dev_priv->rps.hw_lock);
> }
>
Hm that's not what I saw here; I stopped getting the timer interrupts
when the GPU went idle. But that could be explained by punit fw
differences.
So this change looks ok to me.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Sour
)
> - DRM_DEBUG_DRIVER("Punit overrode GPU freq: %d MHz (%u)
> requested, but got %d Mhz (%u)\n",
> - vlv_gpu_freq(dev_priv->mem_freq, val), val,
> - vlv_gpu_freq(dev_priv->mem_freq, pval >> 8),
> pval &
nit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
> + }
> +
> + if (pval & 1)
> + DRM_DEBUG_DRIVER("timed out waiting for Punit\n");
>
> pval >>= 8;
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
g timeout = jiffies + msecs_to_jiffies_timeout(10);
> u32 pval;
>
> WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
dev_priv->rps.min_delay &&
> + new_delay <= dev_priv->rps.max_delay) {
> if (IS_VALLEYVIEW(dev_priv->dev))
> valleyview_set_rps(dev_priv->dev, new_delay);
> else
Reviewed-by: Jesse Barnes
--
Jesse Barn
; - I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
> -
> dev_priv->rps.cur_delay = val;
>
> trace_intel_gpu_freq_change(vlv_gpu_freq(dev_priv->mem_freq, val));
I don't see it anymore either... so Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Sourc
the PLL state on resume from hibernate,
leading to this warning. The refcount is nonzero, indicating the pll
is in use, but the active field is clear, which means we're missing an
update somewhere.
Shuah, just to confirm, does your resume actually work ok aside from
the warning? I *think* it
On Tue, 25 Jun 2013 19:59:28 +
Shuah Khan wrote:
> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 21:37:37 +0200
> > Daniel Vetter wrote:
> >
>
> >>
> >> Adding more lists to cc + Jesse since he's the guilty one
On Tue, 25 Jun 2013 20:51:27 +
Shuah Khan wrote:
> On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 19:59:28 +
> > Shuah Khan wrote:
> >
> >> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> >>> On Tue, 25 Jun 2013
(17 * PAGE_SIZE)
>
> /*
> * Overlay regs
Yeah, we can't rely on the reg I guess, and this matches the docs
(though they don't make it easy to figure it out)... I'd like to see a
reference to the bspec where this information is kept, but other than
that:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |5 +
drivers/gpu/drm/i915/i915_drv.h |1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4a4ec86..226d4d7 100644
--- a/drivers/gpu/drm/i915
Down to 5 patches, rebased on top of today's dinq and with changes
requested by Daniel.
This series is activated through the i915.fastboot=1 boot argument, and
works here on my SNB laptop. We still have some prettying of userspace
to do, but at least we avoid the panel power sequence so things ar
SWELL
use port_clock field rather than a new CPU eDP clock field in crtc_config
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_crt.c |1 +
drivers/gpu/drm/i915/intel_display.c | 109 +++---
drivers/gp
-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 37 ++
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e75ce2f..8a7da45 100644
--- a/drivers/gpu/drm/i915
Need better pfit tracking to do this right.
v2: use fastboot param around this hack
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
-> fb flip behavior
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a55e1e5..0e7324d 100644
--- a/drivers
(VLV_DISPLAY_BASE + 0x7229c)
> +#define _SPBKEYMAXVAL(VLV_DISPLAY_BASE + 0x722a0)
> +#define _SPBTILEOFF (VLV_DISPLAY_BASE + 0x722a4)
> +#define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
> +#define _SPBGAMC (VLV_DISPLAY_BASE + 0x722f4)
>
>
mp;crtc->base, INTEL_OUTPUT_HDMI))
> vlv_dpio_write(dev_priv, DPIO_LFP_COEFF(pipe),
>0x005f0021);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
: rename function to intel_crtc_mode_from_pipe_config for consistency (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 37 ++
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
SWELL
use port_clock field rather than a new CPU eDP clock field in crtc_config
v8: remove stale pixel_multiplier sets (Daniel)
multiply by pixel_multiplier in 9xx clock get too (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm
On Sat, 22 Jun 2013 13:04:09 -0700
Guenter Roeck wrote:
> On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote:
> > On Fri, 21 Jun 2013 23:58:08 -0700
> > Guenter Roeck wrote:
> >
> > > Hi all,
> > >
> > > after upgrading one
DPLL_PORTC_READY_MASK |
> + DPLL_PORTB_READY_MASK);
> }
>
> return true;
As a rule I'd like to see comments explaining this too, so we don't
have to dig through the changelog to figure i
ut)) {
> - DRM_DEBUG_DRIVER("timed out waiting for Punit\n");
> - break;
> - }
> - udelay(10);
> - } while (pval & 1);
> + if (wait_for(((pval = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
&
t; *encoder,
> u32 hdmi_val;
>
> hdmi_val = SDVO_ENCODING_HDMI;
> - if (!HAS_PCH_SPLIT(dev) && !IS_VALLEYVIEW(dev))
> + if (!HAS_PCH_SPLIT(dev))
> hdmi_val |= intel_hdmi->color_range;
> if (adjusted_mode->flags & DRM_
v_dpio_write(dev_priv, DPIO_LPF_COEFF(pipe),
>0x005f0021);
> else
> - vlv_dpio_write(dev_priv, DPIO_LFP_COEFF(pipe),
> + vlv_dpio_write(dev_priv, DPIO_LPF_COEFF(pipe),
>0x00df);
>
> i
ff-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 120 +++---
drivers/gpu/drm/i915/intel_dp.c |7 ++
drivers/gpu/drm/i915/intel_sdvo.c|5 ++
4 files changed, 123 insertions(+), 10 deletions(-)
npredictable performance.
Requested-by: Eric Anholt
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |4 +++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 54 +++
3 files changed, 37 insertions(+), 22 deletions(-)
.
>
> Cc: Imre Deak
> Cc: Jesse Barnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 12 ++--
> drivers/gpu/drm/i915/intel_sdvo.c| 3 ---
> 2 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i
m_setup_global_gtt(dev, 0, mappable_size, gtt_size);
> + i915_gem_setup_global_gtt(dev, 0, mappable_size, gtt_size, PAGE_SIZE);
> }
>
> static int setup_scratch_page(struct drm_device *dev)
Just a nitpick that can be changed with a follow on patch if others
agree: I'd rather see the WARN_ON made a BUG_ON when checking that the
guard_size is a multiple of PAGE_SIZE (which, incidentally, is the
wrong value to use, but that's also for another cleanup).
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
acked idleness elsewhere. I'm
also unsure about the cpufreq calls; I don't really know if this will do
what I want...
Requested-by: Owen Taylor
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 24
drivers/gpu/drm/i915/intel_drv.h
On Fri, 28 Jun 2013 19:37:01 +0100
Chris Wilson wrote:
> On Fri, Jun 28, 2013 at 09:54:32AM -0700, Jesse Barnes wrote:
> > Coming out of idle is usually due to some sort of user input (swiping a
> > screen, clicking a button) and often results in some sort of graphical
> > a
(Jesse)
>
> v5: Don't subtract guard page since we now killed the guard page prior
> to this patch. (Ben)
>
> Cc: Chris Wilson
> Reviewed-by: Jesse Barnes
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915
On Fri, 28 Jun 2013 12:10:51 -0700
Arjan van de Ven wrote:
> On 6/28/2013 11:37 AM, Chris Wilson wrote:
> > On Fri, Jun 28, 2013 at 09:54:32AM -0700, Jesse Barnes wrote:
> >> Coming out of idle is usually due to some sort of user input (swiping a
> >> screen, clicking
Print out the flag that failed and fix up a mismatched paren.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
We need to get the current hw state so we can compare against the
expected state.
References: https://bugs.freedesktop.org/show_bug.cgi?id=66444
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
On Mon, 1 Jul 2013 19:36:32 +0200
Daniel Vetter wrote:
> On Mon, Jul 01, 2013 at 10:19:10AM -0700, Jesse Barnes wrote:
> > We need to get the current hw state so we can compare against the
> > expected state.
> >
> > References: https://bugs.freedesktop.org/show_bug.c
This should help on HSW, where we don't currently have a get_clock call.
Reported-by: Paulo Zanoni
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm
amp;crtc->base, INTEL_OUTPUT_HDMI))
> vlv_dpio_write(dev_priv, DPIO_LPF_COEFF(pipe),
> - 0x005f0021);
> + 0x009f0003);
> else
> vlv_dpio_write(dev_priv, DPIO_LPF_COEFF(pipe),
>
ly out of the range your monitor
wants. If you can get that mode running with the VESA driver you could
collect a register dump in the good and bad cases so we could compare...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 09 Jul 2013 14:46:28 -0700
Christian Kreibich wrote:
> On 07/09/2013 02:27 PM, Jesse Barnes wrote:
> > Sounds like our pixel clock is probably out of the range your monitor
> > wants. If you can get that mode running with the VESA driver you could
> > collect a regi
if we
call ->off directly. Does suspend/resume still work both with and
without X with this patch applied? If we trash the sw state, the VT
switchless resume shouldn't work...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
;ve
failed pretty hard to get things out and tested on time...
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |5 -
drivers/gpu/drm/i915/i915_drv.h |1 -
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
ind
On Fri, 12 Jul 2013 08:07:30 +0200
Daniel Vetter wrote:
> I.e. for letter/pillarboxing. For those cases we need to adjust the
> mode a bit, but Jesse gmch pfit refactoring in
>
> commit 2dd24552cab40ea829ba3fda890eeafd2c4816d8
> Author: Jesse Barnes
> Date: Thu Apr 25 1
HDMI use WRPLL1.After resume from
> S4, HDMI use WRPLL2. The status is different during S4
>
> Actually, the above problem is a regression caused by your commit:
>commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
>Author: Jesse Barnes
>Date: Tue Mar 26 09:25:45 2013 -070
101 - 200 of 3350 matches
Mail list logo
