On Wed, 08 May 2013, Ville Syrjälä wrote:
> On Wed, May 08, 2013 at 05:03:31PM +0100, Damien Lespiau wrote:
>> +static const char *connector_status_str(enum drm_connector_status status)
>> +{
>> +switch (status) {
>> +case connector_status_connected:
>> +return "connected";
>>
On Mon, 2013-05-06 at 10:36 +0200, Daniel Vetter wrote:
> On Mon, May 6, 2013 at 10:33 AM, Daniel Vetter wrote:
> > Dear stable team,
> >
> > Please backport
> >
> > commit 4615d4c9e27eda42c3e965f208a4b4065841498c
> > Author: Chris Wilson
> > Date: Mon Apr 8 14:28:40 2013 +0100
> >
> > drm/
Hi Jesse,
> -Original Message-
> From: Barnes, Jesse
> Sent: Friday, May 10, 2013 2:30 AM
> To: Takashi Iwai
> Cc: Daniel Vetter; Wang, Xingchao; david.hennings...@canonical.com;
> Girdwood, Liam R; Li, Jocelyn; Lin, Mengdong; Zanoni, Paulo R; Wang Xingchao;
> intel-gfx; alsa-de...@alsa-p
Hi Takashi,
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Friday, May 10, 2013 1:18 AM
> To: Daniel Vetter
> Cc: Wang, Xingchao; david.hennings...@canonical.com; Girdwood, Liam R;
> Barnes, Jesse; Li, Jocelyn; Lin, Mengdong; Zanoni, Paulo R; Wang Xingchao;
> inte
drm_i915_private is getting bigger and bigger when adding new vbt stuff.
So, the better way of getting drm_i915_private organized is to create
a special structure for vbt stuff.
v2: Basically conflicts fixes
Reviewed-by: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_dma
Hi Daniel,
This patch is a prep one for PSR series and had been reviewed by Ville already.
I'm sending it standalone because it's been a pain to rebase psr work,
because this one always conflicts.
Since I solved many conflicts during the way probably Ville would like
to give a second look.
Anyway,
drm_i915_private is getting bigger and bigger when adding new vbt stuff.
So, the better way of getting drm_i915_private organized is to create
a special structure for vbt stuff.
Reviewed-by: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_dma.c | 8 +--
drivers/gpu/
On Wed, Apr 17, 2013 at 04:05:10PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/4/17 Imre Deak :
> > For the device to enter D3 we should enable PCH clock gating.
> >
> > v2:
> > - use HAS_PCH_LPT instead of IS_HASWELL (Ville, Paolo)
> > - rename lpt_allow_clock_gating to lpt_suspend_hw (Paolo)
> >
>
2013/4/24 :
> From: Ville Syrjälä
>
> If the calculated FBC watermark is no good, we simply disable FBC
> watermarks. But we fail to re-enable them later if the calculated
> watermark becomes good again. Fix that, but remember to leave FBC
> watermarks disabled on ILK since that's required by som
From: Paulo Zanoni
We were previously calling sandybridge_update_wm on HSW, but the SNB
function didn't really match the HSW specification, so we were just
writing the wrong values. For example, I was not seeing any LP
watermark ever enabled.
This patch implements the haswell_update_wm function
On Mon, May 6, 2013 at 5:49 PM, Daniel Vetter wrote:
> On Mon, May 6, 2013 at 1:43 PM, Niko! wrote:
> > Hi Daniel,
> >
> > I'm a damned and fooled linux-only user with a fresh z2760 based
> > tablet/netbook (samsung ativ 500t e.g. "FULL PC EXPERIENCE"!!!).
>
[...]
> For your question: This is a
From: Paulo Zanoni
The spec says the linetime watermarks must be programmed before
enabling any display low power watermarks, but we're currently
updating the linetime watermarks after we call intel_update_watermarks
(and only at crtc_mode_set, not at crtc_{enable,disable}). So IMHO the
best way
On Wed, 8 May 2013 19:12:49 -0700
Ben Widawsky wrote:
> On Wed, May 08, 2013 at 10:45:14AM -0700, Jesse Barnes wrote:
> > In some cases, we may not need GTT address space allocated to a stolen
> > object, so allow passing -1 to the preallocated function to indicate as
> > much.
> >
> > v2: remov
On Mon, 6 May 2013 16:45:52 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rewrite the ILK+ watermark code to allow:
> - updating the watermarks safely (to avoid underruns)
> - pre-computing watermarks (will help with atomic modest and pageflip)
> - enabling LP1+ watermark
On Thu, 9 May 2013 11:30:01 -0700
Jesse Barnes wrote:
> > The question is in which level we need power_well_*() controls.
> > If the initialization of HD-audio controller (e.g. PCI registers)
> > requires the power well on, hda_intel.c requires the calls, as this
> > patch does. OTOH, if it's on
On Thu, 9 May 2013 19:17:36 +0200
Takashi Iwai wrote:
> At Thu, 9 May 2013 11:23:21 +0200,
> Daniel Vetter wrote:
> >
> > 2. On a quick read of the hda driver stuff I don't think the power
> > well enable/disable places are at the right spot: We force the power
> > well on whenever the hda codec
---
assembler/gram.y | 20
assembler/lex.l | 1 +
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/assembler/gram.y b/assembler/gram.y
index 50d71d1..09f21f1 100644
--- a/assembler/gram.y
+++ b/assembler/gram.y
@@ -440,7 +440,7 @@ static void resolve_subnr(str
Display register 46500h bit 23 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
v2: Ville suggested to enable it back when disabling fbc to avoid wasting
power.
v3: RMW to preserve other bits (by Ville)
v4: Fix from Ville: sed &/| at RMW
v5: Too far on sed.
Cc:
At Thu, 9 May 2013 11:23:21 +0200,
Daniel Vetter wrote:
>
> 2. On a quick read of the hda driver stuff I don't think the power
> well enable/disable places are at the right spot: We force the power
> well on whenever the hda codec is used, but we must only do that when
> we want to output audio to
Display register 42020h bit 9 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
v2: RMW to preserve other bits (by Ville)
v3: Fix from Ville: sed &/| at RMW
v4: Too far on sed.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/g
On Mon, May 06, 2013 at 10:36:49AM +0200, Daniel Vetter wrote:
> On Mon, May 6, 2013 at 10:33 AM, Daniel Vetter wrote:
> > Dear stable team,
> >
> > Please backport
> >
> > commit 4615d4c9e27eda42c3e965f208a4b4065841498c
> > Author: Chris Wilson
> > Date: Mon Apr 8 14:28:40 2013 +0100
> >
> >
On Thu, May 9, 2013 at 9:20 AM, Chris Cummins
wrote:
> The intention here is to make the output of dmesg with full verbosity a
> bit easier for a human to parse. This commit transforms:
>
> [drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc010645b
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc
On Thu, 09 May 2013, Daniel Vetter wrote:
> On Thu, May 09, 2013 at 11:47:01AM +0300, Jani Nikula wrote:
>> On Wed, 08 May 2013, Daniel Vetter wrote:
>> > Queued for -next, thanks for the patch.
>>
>> Shouldn't this be headed for 3.10 through -fixes?
>
> The hpd filtering is only in -next thus f
Hi Daniel,
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Thursday, May 09, 2013 5:23 PM
> To: Wang, Xingchao
> Cc: david.hennings...@canonical.com; Girdwood, Liam R; ti...@suse.de;
> Barnes, Jesse; Li, Jocelyn; Lin,
On Thu, May 09, 2013 at 11:47:01AM +0300, Jani Nikula wrote:
> On Wed, 08 May 2013, Daniel Vetter wrote:
> > Queued for -next, thanks for the patch.
>
> Shouldn't this be headed for 3.10 through -fixes?
The hpd filtering is only in -next thus far. Or have I botched up my patch
tracking again?
-D
Hi all,
Three things:
1. Any reason public mailing lists (intel-gfx, alsa-devel) aren't
cc'ed? Afaics no secret stuff is being discussed here ... Please
resend the patches with mailings lists cc'ed.
2. On a quick read of the hda driver stuff I don't think the power
well enable/disable places are
I have run some video process test cases calling libva based on vesc-rebase
kernel, output videos of video processing are ok by a little mild test cases
(include de-interlacing, denoise, color space conversion and scaling).
Then I used upstream kernel which not support vesc, output of vpp was wro
On Wed, 08 May 2013, Daniel Vetter wrote:
> Queued for -next, thanks for the patch.
Shouldn't this be headed for 3.10 through -fixes?
Jani.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-g
29 matches
Mail list logo