From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..3d3803a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm
From: Paulo Zanoni
We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display
From: Paulo Zanoni
We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu
From: Paulo Zanoni
This is bad news and shouldn't be happening.
V2: Rebase.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 13 +++--
drivers/gpu/drm/i915/i915_reg.h |2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
From: Paulo Zanoni
In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
- after we receive one of these errors, we mask the interrupt, so
we won't get an "interrupt storm" and we also won't flood dmesg;
- at each mode set we en
On Fri, Mar 22, 2013 at 02:16:38PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This solves some "unclaimed register" messages when booting the
> machine with eDP attached.
>
> V2: Rebase and add the comment requested by Daniel.
>
> Signed-off-by: Paulo Zanoni
Merged this one and the p
On Fri, Apr 12, 2013 at 10:50:45AM -0700, Jesse Barnes wrote:
> Uses slightly different interfaces than other platforms.
>
> v2: track actual set freq, not requested (Rohit)
> fix debug prints in init code (Jesse)
> v3: don't write sleep reg (Jesse)
> re-add RC6 wake limit write (Ben)
>
Hi
2013/3/28 Daniel Vetter :
> On Fri, Feb 22, 2013 at 05:05:29PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> In this commit we enable both CPU and PCH FIFO underrun reporting and
>> start reporting them. We follow a few rules:
>> - after we receive one of these errors, we mask the i
On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote:
> Hi Greg,
>
> Please consider
>
> 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
> the per-process entries, 2012-08-24
>
> for application to the 3.4.y tree.
>
> Without this patch, Geoff Crompt
On Fri, Apr 12, 2013 at 10:50:44AM -0700, Jesse Barnes wrote:
> When requesting frequency changes or querying status from the Punit, we
> need to use an opcode that corresponds to the frequency, taking into
> account the memory frequency.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we incre
On Fri, Apr 12, 2013 at 2:10 AM, Mika Kuoppala
wrote:
> commit 647416f9eefe7699754b01b9fc82758fde83248c
> Author: Kees Cook
> Date: Sun Mar 10 14:10:06 2013 -0700
>
> drm/i915: use simple attribute in debugfs routines
>
> made i915_next_seqno debugfs entry to crop it's output
> if returned
On Fri, Apr 12, 2013 at 2:15 AM, Mika Kuoppala
wrote:
> Kees Cook writes:
>
>> On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
>> wrote:
>>> Kees Cook writes:
>>>
On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
wrote:
> commit 647416f9eefe7699754b01b9fc82758fde83248c
> Author:
When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 56 +++
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq calc
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq calc
On Fri, Apr 12, 2013 at 06:48:43PM +0200, Daniel Vetter wrote:
> Yet again our current confusion between doing the modeset globally,
> but only having the new parameters for one crtc at a time.
>
> So that intel_set_mode essentially already does a global modeset:
> intel_modeset_affected_pipes com
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes compares the current state with where we
want to go to (which is carefully s
Summary
We finished a new round of kernel testing. Generally, in this circle, 2 new
bugs are filed, 23 bugs are still opened,1 Resolved fixed bugs(we are busy in
doing our testing, sorry that we are slow to response this bug, we will retest
this bug ASAP), 6 bugs are closed.
Test Environment
On Fri, Apr 12, 2013 at 11:46 AM, Chris Wilson wrote:
> On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote:
>> Yet again our current confusion between doing the modeset globally,
>> but only having the new parameters for one crtc at a time.
>>
>> This time things blew up when restoring
On Fri, Apr 12, 2013 at 04:13:47PM +0200, j j wrote:
> Thanks for concrete answer. I rebuilt my xf86-video-intel driver with
> glamor, SNA and UXA support enabled but unfortunately it did not help. My
> "815 E"
> chipset still works slow. I think it is because glamor, SNA and UXA does not
> support
Thanks for concrete answer. I rebuilt my xf86-video-intel driver with
glamor, SNA and UXA support enabled but unfortunately it did not help. My
"815 E"
chipset still works slow. I think it is because glamor, SNA and UXA does not
support my chipset, right ?
If so, is it going to be supported in the
On Thu, Apr 11, 2013 at 04:29:07PM +0200, Daniel Vetter wrote:
> This is horrible lore and we should be able to get rid of it now
> that the lvds/pfit handling code actually does the right thing.
>
> Signed-off-by: Daniel Vetter
I'd prefer 4 & 5 squashed, specially as 5 will then introduce a WAR
On Thu, Apr 11, 2013 at 04:29:08PM +0200, Daniel Vetter wrote:
> Just blows through 50ms for naught, since the pipe is off.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Int
On Thu, Apr 11, 2013 at 04:29:09PM +0200, Daniel Vetter wrote:
> The i9xx modeset sequence is currently pretty fishy, so tight it all
> up with some good assert-sprinkling.
>
> We already have good coverage on the disable side, but the enable side
> is spotty (since until recently it was wrong).
>
On Thu, Apr 11, 2013 at 04:29:10PM +0200, Daniel Vetter wrote:
> We can only enable the pfit if the pipe. Ensure that this is obied
> with a neat assert.
>
> Also check whether the pfit is off before enabling it - if not we've
> lost track of things somewhere since the pfit is only ever used by th
On Thu, Apr 11, 2013 at 04:29:06PM +0200, Daniel Vetter wrote:
> The recent rework of the pfit handling didn't take into account that
> the panel fitter is fixed to pipe B:
>
> commit 24a1f16de97c4cf0029d9acd04be06db32208726
> Author: Mika Kuoppala
> Date: Fri Feb 8 16:35:37 2013 +0200
>
>
On Fri, Apr 12, 2013 at 03:18:36PM +0300, Jani Nikula wrote:
> In preparation of adding locking to backlight, make max backlight value
> (the modulation frequency the PWM duty cycle value must not exceed)
> internal to intel_panel.c.
>
> Have intel_panel_set_backlight() accept a caller defined ran
In theory, this should prevent the BIOS from requesting them from us, and
this should be the right thing.
In practice, this is not always the case, and might surprise the BIOS.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c |4 +---
1 file changed, 1 insertion(+), 3 de
In theory, the BIOS should not even request these from us now that we
aren't claiming we support these, but when it does anyway, don't pretend it
succeeded. It should be the right thing to do, but might confuse the BIOS.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 19
There's still stuff to do on opregion cleanup, but here are some potentially
risky and/or controversial ones...
Jani Nikula (3):
drm/i915: don't pretend we support ASLE ALS, PFIT, or PFMB
drm/i915/opregion: don't pretend we did something when we didn't
drm/i915: drop code duplication in favo
With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_irq.c |4 ++--
drivers/gpu/drm/i915/intel_opregion.c | 37 ---
Backlight data and registers are fiddled through LVDS/eDP modeset
enable/disable hooks, backlight sysfs files, asle interrupts, and register
save/restore. Protect the backlight related registers and driver private
fields using a spinlock.
The locking in register save/restore covers a little more t
In preparation of adding locking to backlight, make max backlight value
(the modulation frequency the PWM duty cycle value must not exceed)
internal to intel_panel.c.
Have intel_panel_set_backlight() accept a caller defined range for level,
and scale input to max backlight value internally.
Clean
Patches 1-2 are for locking, 3-4 are related only by being backlight fixes.
I haven't tested these much...
BR,
Jani.
Jani Nikula (4):
drm/i915: keep max backlight internal to intel_panel.c
drm/i915: protect backlight registers and data with a spinlock
drm/i915: ensure single initialization
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 5d3e9d7..0362f5c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers
Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset clea
On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote:
> Yet again our current confusion between doing the modeset globally,
> but only having the new parameters for one crtc at a time.
>
> This time things blew up when restoring modes in the switchless resume
> code - intel_modeset_affect
On Thu, Apr 11, 2013 at 08:36:26AM -0700, Ben Widawsky wrote:
> On Thu, Apr 11, 2013 at 07:10:50AM +0100, Chris Wilson wrote:
> > On Wed, Apr 10, 2013 at 07:43:39PM -0700, Ben Widawsky wrote:
> > > I think this is a nice generalization on it's own, but it's primarily
> > > prep work for my PPGTT su
Kees Cook writes:
> On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala
> wrote:
>> Kees Cook writes:
>>
>>> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala
>>> wrote:
commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook
Date: Sun Mar 10 14:10:06 2013 -0700
commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook
Date: Sun Mar 10 14:10:06 2013 -0700
drm/i915: use simple attribute in debugfs routines
made i915_next_seqno debugfs entry to crop it's output
if returned value was large enough. Using simple_attr
will limit the output to 24
On Thu, Apr 11, 2013 at 11:09:00PM +0200, Daniel Vetter wrote:
> On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote:
> > Yet again our current confusion between doing the modeset globally,
> > but only having the new parameters for one crtc at a time.
> >
> > This time things blew up wh
Hi Greg,
Please consider
9a0f938bde74 drm/i915: Use the correct size of the GTT for placing
the per-process entries, 2012-08-24
for application to the 3.4.y tree.
Without this patch, Geoff Crompton's iMac hits a BUG during bootup.
The problem is reproducible on
* Debian's 3.2.y
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
>
> I've just tracked down and fixed an bug which can lead to a hard-hang
> in the crtc restore code (which is used both in the lid handler when
> opening and on resume). If you could please test this patch (on top of
> drm-intel-night
44 matches
Mail list logo
