On Thu, 16 Jan 2014, Daniel Vetter wrote:
> This was forgotten in
>
> commit 565ee3897f0cb1e9b09905747b3784e6605767e8
> Author: Jani Nikula
> Date: Wed Nov 13 12:56:29 2013 +0200
>
> drm/i915: do not save/restore backlight registers in KMS
>
> Since the confusion was likely due to the dupli
On Fri, 17 Jan 2014, Yijing Wang wrote:
> Fix acpi_evaluate_object() return value check,
> shoud acpi_status not int.
Please spellcheck.
>
> Signed-off-by: Yijing Wang
> ---
> v2->v3: Fix compile error pointed out by Hanjun.
> v1->v2: Add CC to related subsystem MAINTAINERS
> ---
> drivers/gpu
On Fri, Jan 17, 2014 at 4:06 AM, Todd Previte wrote:
> For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that
> support it. The
> sink device must report that is supports Displayport 1.2 and the HBR2 bit
> rate in the
> DPCD in order to use HBR2.
sob line missing.
> ---
> dri
For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that support
it. The
sink device must report that is supports Displayport 1.2 and the HBR2 bit rate
in the
DPCD in order to use HBR2.
---
drivers/gpu/drm/i915/intel_dp.c | 21 +++--
1 file changed, 15 insertions(+
On Thu, Jan 16, 2014 at 07:56:54PM +0200, Imre Deak wrote:
> Atm, we don't print these events for all platforms and for VLV/G4X we
> also print them for DP AUX completion events which is unnecessary spam.
> Fix both issues.
>
> Signed-off-by: Imre Deak
Both merged, thanks.
Aside: Paulo asked me
Currently we're doing the reset handling a bit late, and we're doing
it both in the driver load code and on resume. This makes it unusable
for e.g. resetting the panel power sequence state like Paulo wants to.
Instead of adding yet another single-use callback shuffle things
around:
- Output handli
On Thu, Jan 16, 2014 at 08:39:38PM +, Chris Wilson wrote:
> On Thu, Jan 16, 2014 at 06:01:28PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 16, 2014 at 5:58 PM, Chris Wilson
> > wrote:
> > > On Thu, Jan 16, 2014 at 06:35:58PM +0200, Imre Deak wrote:
> > >> The driver shouldn't disable the DP p
2014/1/16 Daniel Vetter :
> On Thu, Jan 16, 2014 at 4:24 PM, Daniel Vetter wrote:
>> Currently we're doing the reset handling a bit late, and we're doing
>> it both in the driver load code and on resume. This makes it unusable
>> for e.g. resetting the panel power sequence state like Paulo wants t
On Thu, Jan 16, 2014 at 06:01:28PM +0100, Daniel Vetter wrote:
> On Thu, Jan 16, 2014 at 5:58 PM, Chris Wilson
> wrote:
> > On Thu, Jan 16, 2014 at 06:35:58PM +0200, Imre Deak wrote:
> >> The driver shouldn't disable the DP port itself, but let userspace do it
> >> through a modeset. See the prev
On Thu, Jan 16, 2014 at 05:55:06PM +, Damien Lespiau wrote:
> > + /* Wait 2 vblanks to be sure we will have the correct CRC value */
> > + intel_wait_for_vblank(dev, intel_crtc->pipe);
> > + intel_wait_for_vblank(dev, intel_crtc->pipe);
>
> I think there's a better way to do this. There'
Fix typo possibly leading to timed out DP aux transactions on ports C,D.
Introduced in:
Commmit 4aeebd7443e36b0a40032e518a9338f48bd27efc
Author: Daniel Vetter
Date: Thu Oct 31 09:53:36 2013 +0100
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72210
Signed off-by: Imre Deak
---
drive
On Tue, Jan 14, 2014 at 04:21:50PM -0200, Rodrigo Vivi wrote:
> This debugfs interface will allow intel-gpu-tools test case
> to verify if screen has been updated properly on cases like PSR.
>
> v2: Accepted all Daniel's suggestions:
> * grab modeset lock
> * loop over connector and check
Atm, we don't print these events for all platforms and for VLV/G4X we
also print them for DP AUX completion events which is unnecessary spam.
Fix both issues.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_irq.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --g
On Thu, Jan 16, 2014 at 04:33:26PM +, Damien Lespiau wrote:
> It can be handy at times to forbid i915 from loading at startup to
> modprobe it later.
modprobe.blacklist=i915
>
> In particular, when trying to debug a problem that occurs at startup,
> it's usually easier to boot into a working
On Thu, Jan 16, 2014 at 07:07:09PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2014 at 04:33:26PM +, Damien Lespiau wrote:
> > It can be handy at times to forbid i915 from loading at startup to
> > modprobe it later.
>
> modprobe.blacklist=i915
Ah, yeah, that works.
--
Damien
On Thu, Jan 16, 2014 at 05:55:48PM +0100, Daniel Vetter wrote:
> On Thu, Jan 16, 2014 at 5:27 PM, wrote:
> > From: Ville Syrjälä
> >
> > My 855gm doesn't register the intel backlight but it still ends up
> > calling the backlight code to enable/disable the backlight via the
> > LVDS code. This l
On Thu, 2014-01-16 at 16:58 +, Chris Wilson wrote:
> On Thu, Jan 16, 2014 at 06:35:58PM +0200, Imre Deak wrote:
> > The driver shouldn't disable the DP port itself, but let userspace do it
> > through a modeset. See the previous patch for the reasoning.
>
> Eh, this occurs not just during link
On Thu, Jan 16, 2014 at 5:58 PM, Chris Wilson wrote:
> On Thu, Jan 16, 2014 at 06:35:58PM +0200, Imre Deak wrote:
>> The driver shouldn't disable the DP port itself, but let userspace do it
>> through a modeset. See the previous patch for the reasoning.
>
> Eh, this occurs not just during link det
On Thu, Jan 16, 2014 at 5:54 PM, Paulo Zanoni wrote:
> 2014/1/16 Daniel Vetter :
>> Our init_clock_gating functions and related code should already take
>> care of this. And if they don't we'd better know.
>
> For both registers, I see functions applying specific workarounds, but
> they only do th
On Thu, Jan 16, 2014 at 06:35:58PM +0200, Imre Deak wrote:
> The driver shouldn't disable the DP port itself, but let userspace do it
> through a modeset. See the previous patch for the reasoning.
Eh, this occurs not just during link detection, but also during
intel_enable_dp, so this comment does
On Thu, Jan 16, 2014 at 5:27 PM, wrote:
> From: Ville Syrjälä
>
> My 855gm doesn't register the intel backlight but it still ends up
> calling the backlight code to enable/disable the backlight via the
> LVDS code. This leads to some WARNs due to backlight.max being 0.
>
> Let's have intel_panel
2014/1/16 Daniel Vetter :
> Our init_clock_gating functions and related code should already take
> care of this. And if they don't we'd better know.
For both registers, I see functions applying specific workarounds, but
they only do the read-write-modify through _MASKED_BIT_ENABLE(). I
don't see a
It can be handy at times to forbid i915 from loading at startup to
modprobe it later.
In particular, when trying to debug a problem that occurs at startup,
it's usually easier to boot into a working machine and modprobe the
driver at a more convenient time.
Signed-off-by: Damien Lespiau
---
dri
On Wed, Jan 15, 2014 at 04:57:28PM -0200, Rodrigo Vivi wrote:
> Hi Ville and Daniel,
>
> Ville, since this is heavily based on your kms_fbc_psr I'd appreciate
> your comments here please.
> Mainly regarding the page_flip+mmaps which I'm not sure how usefull
> they are on this psr case.
> Or my imp
Those are two distinct concepts. Just use a comment to remind us to
remove that W/A at some point.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/in
The driver shouldn't disable the DP port itself, but let userspace do it
through a modeset. See the previous patch for the reasoning.
Keeping this as a separate patch for bisectability.
Suggested-by: Daniel Vetter
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 1 -
1 file chang
Currently if the DP link is lost (either because of a hot unplug, or
failed link status check) we disable the DP port, but leave the rest
of the pipe running. This is incompatible with the modeset disabling
sequence of some platforms/configurations. At least this is the case for
DP ports on the CPU
On Thu, Jan 16, 2014 at 10:27:03AM +0100, Daniel Vetter wrote:
> On Thu, Jan 16, 2014 at 12:55 AM, Daniel Vetter wrote:
> > Anything you put out to stderr will be tracked as a "warn" in piglit. Atm
> > we don't have any such use-case though I think, mostly since keeping
> > unbuffer stderr and buf
From: Ville Syrjälä
My 855gm doesn't register the intel backlight but it still ends up
calling the backlight code to enable/disable the backlight via the
LVDS code. This leads to some WARNs due to backlight.max being 0.
Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight(
This was forgotten in
commit 565ee3897f0cb1e9b09905747b3784e6605767e8
Author: Jani Nikula
Date: Wed Nov 13 12:56:29 2013 +0200
drm/i915: do not save/restore backlight registers in KMS
Since the confusion was likely due to the duplicated definition for
this pci config register, let's unify
On Thu, Jan 16, 2014 at 5:08 PM, Damien Lespiau
wrote:
> On Tue, Jan 14, 2014 at 11:35:22PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 14, 2014 at 02:05:45PM -0800, Ben Widawsky wrote:
>> > On Tue, Jan 14, 2014 at 11:04:16AM -0800, Jesse Barnes wrote:
>> > > It ought to work ok in 3.14. We have s
On Tue, Jan 14, 2014 at 11:35:22PM +0100, Daniel Vetter wrote:
> On Tue, Jan 14, 2014 at 02:05:45PM -0800, Ben Widawsky wrote:
> > On Tue, Jan 14, 2014 at 11:04:16AM -0800, Jesse Barnes wrote:
> > > It ought to work ok in 3.14. We have some fun stuff coming after that,
> > > but all the basics are
Our init_clock_gating functions and related code should already take
care of this. And if they don't we'd better know.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_suspend.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu
On Thu, Jan 16, 2014 at 4:24 PM, Daniel Vetter wrote:
> Currently we're doing the reset handling a bit late, and we're doing
> it both in the driver load code and on resume. This makes it unusable
> for e.g. resetting the panel power sequence state like Paulo wants to.
>
> Instead of adding yet an
Currently we're doing the reset handling a bit late, and we're doing
it both in the driver load code and on resume. This makes it unusable
for e.g. resetting the panel power sequence state like Paulo wants to.
Instead of adding yet another single-use callback shuffle things
around:
- Output handli
From: Ville Syrjälä
I forgot to set new_config and new_enabled appropriately in the load
detect code. Fix it up.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers
On Mon, Jan 13, 2014 at 11:39:01AM -0400, Giacomo Comes wrote:
> On Mon, Jan 13, 2014 at 11:53:18AM -0200, Paulo Zanoni wrote:
> > 2014/1/12 Daniel Vetter :
> > > On Sun, Jan 12, 2014 at 9:23 PM, Giacomo Comes wrote:
> > >> This is the dmesg output using drm-intel-next-2014-01-10
> > >>
> > >> I b
On Thu, Jan 16, 2014 at 3:11 PM, Ville Syrjälä
wrote:
> On Thu, Jan 16, 2014 at 03:00:26PM +0100, Daniel Vetter wrote:
>> On Thu, Jan 16, 2014 at 2:28 PM, Ville Syrjälä
>> wrote:
>> > On Thu, Jan 16, 2014 at 01:41:32PM +0100, Dragos Carp wrote:
>> >> Hi Jani,
>> >>
>> >> thank you for your respon
2014/1/15 Daniel Vetter :
> On Wed, Jan 15, 2014 at 10:21:56AM -0800, Jesse Barnes wrote:
>> On Fri, 3 Jan 2014 17:46:40 -0200
>> Paulo Zanoni wrote:
>>
>> > From: Paulo Zanoni
>> >
>> > The eDP code records a few timestamps containing the last time we took
>> > some actions, because we need to
On Thu, Jan 16, 2014 at 03:00:26PM +0100, Daniel Vetter wrote:
> On Thu, Jan 16, 2014 at 2:28 PM, Ville Syrjälä
> wrote:
> > On Thu, Jan 16, 2014 at 01:41:32PM +0100, Dragos Carp wrote:
> >> Hi Jani,
> >>
> >> thank you for your response.
> >> Attached is the dmesg output trimmed of more thousand
On Thu, Jan 16, 2014 at 2:28 PM, Ville Syrjälä
wrote:
> On Thu, Jan 16, 2014 at 01:41:32PM +0100, Dragos Carp wrote:
>> Hi Jani,
>>
>> thank you for your response.
>> Attached is the dmesg output trimmed of more thousand lines like:
>> [drm:i915_irq_handler], pipe B underrun
>
> That's a bit weird
2014/1/16 Chris Wilson :
> An object can only have an active gtt mapping if it is currently bound
> into the global gtt. Therefore we can simply walk the list of all bound
> objects and check the flag upon those for an active gtt mapping.
>
> From commit 48018a57a8f5900e7e53ffaa0adeb784095accfb
> A
On Thu, Jan 16, 2014 at 01:41:32PM +0100, Dragos Carp wrote:
> Hi Jani,
>
> thank you for your response.
> Attached is the dmesg output trimmed of more thousand lines like:
> [drm:i915_irq_handler], pipe B underrun
That's a bit weird. We're supposed to disable the underrun reporting
after the fi
On Thu, 16 Jan 2014, Dragos Carp wrote:
> Hi Jani,
>
> thank you for your response.
> Attached is the dmesg output trimmed of more thousand lines like:
> [drm:i915_irq_handler], pipe B underrun
Auch. I was hoping to see the early boot, and the first errors. Please
set log_buf_len kernel paramete
Hi Jani,
thank you for your response.
Attached is the dmesg output trimmed of more thousand lines like:
[drm:i915_irq_handler], pipe B underrun
Kernel command line was:
linux /boot/vmlinuz-3.11.6-4-desktop
root=UUID=12529369-6b58-4afe-8e65-9801c19ad8c5
resume=/dev/disk/by-id/ata-SQF-P10S2-
An object can only have an active gtt mapping if it is currently bound
into the global gtt. Therefore we can simply walk the list of all bound
objects and check the flag upon those for an active gtt mapping.
>From commit 48018a57a8f5900e7e53ffaa0adeb784095accfb
Author: Paulo Zanoni
Date: Fri De
From: Ville Syrjälä
If there's no VBT mode not EDID, just read out the current SDVO output
timings, and use the result as the preferred mode for the display.
Signed-off-by: Ville Syrjälä
---
This patch is a total shot in the dark since you didn't provide logs. But
in theory it might do somethi
On Thu, Jan 16, 2014 at 12:55 AM, Daniel Vetter wrote:
> Anything you put out to stderr will be tracked as a "warn" in piglit. Atm
> we don't have any such use-case though I think, mostly since keeping
> unbuffer stderr and buffered stdout in sync is a pain ;-) But I guess we
> could formalize thi
Hi Dragoș -
On Wed, 15 Jan 2014, Dragoș Carp wrote:
> I'm trying to update an old linux board Advantech PCM-9361 (Intel Atom
> N270+ 945GSE+ ICH7M) Linux 2.6.32 + IEGD to the newest opensuse 13.1: Linux
> 3.11.6 + xf86-video-intel 2.99.906.
>
> The IEGD driver has some settings (Port Attributes)
49 matches
Mail list logo
