Hi Jesse,
Thanks for the review. Below is my response.
> - why not use the callback to __vlv_force_wake_* from
gen6_gt_force_wake_*? i.e. why is VLV special here?
[Deepak] Gen6 has a single power well whereas the VLV is has spate wells.
This was the reason for the separate function
On Friday 15 November 2013 02:25 PM, Daniel Vetter wrote:
On Fri, Nov 15, 2013 at 10:27:25AM +0200, Jani Nikula wrote:
On Sat, 09 Nov 2013, Shobhit Kumar wrote:
Basically ULPS handling during enable/disable has been moved to
pre_enable and post_disable phases. PLL and panel power disable
also
On Tue, Nov 19, 2013 at 2:39 AM, Daniel Vetter wrote:
> On Tue, Nov 19, 2013 at 3:08 AM, Rodrigo Vivi wrote:
>> I'm just on going with another -collector update and since this patch
>> fixes a bug I think it would be a good one to include.
>>
>> But since it was bikeshedded it is better to ask Vi
On Thu, 14 Nov 2013 19:02:15 +0530
deepa...@intel.com wrote:
> From: Deepak S
>
> Added media/render/common well VLV force wake routines to help
> bring up the WELLS before access the register
> - Refactor current vlv_forcewake get/put and added MEDIA or
> RENDER specific Forcewake.
> - Added
Hi Daniel, I was missing a rebase on testing.
Anyway, collector is now updated and all patches there are reviewed.
Thanks
On Tue, Nov 19, 2013 at 9:25 AM, Rodrigo Vivi wrote:
> On Mon, Nov 18, 2013 at 7:28 PM, Ausmus, James wrote:
>> On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi wrote:
>>>
>>>
Reviewed-by: Rodrigo Vivi
On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> If we force the hw to idle as our first step during unload, we can abort
> the unload upon failure. Later we can probe whether the hardware remain
> active even after we try to shut it down.
Reviewed-by: Rodrigo Vivi
On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi wrote:
> From: Ville Syrjälä
>
> We send the primary and cursor plane data through the gamma unit.
> In order to get matching output from sprites, also send the sprite
> data through the gamma unit.
>
> In the future we sho
On Tue, Nov 19, 2013 at 5:52 AM, Chris Wilson wrote:
> On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote:
>> From: Daniel Vetter
>>
>> This is useful when we only have aliasing ppgtt and want to figure out
>> what exactly is accesssible and what not. Paulo can somehow overwrite
>> the
no idea what happened here...
maybe I lost a rebase on my scripts... will rebase or just remove for now
Thanks
On Tue, Nov 19, 2013 at 8:38 AM, Daniel Vetter wrote:
> On Tue, Nov 19, 2013 at 01:46:55PM +, Chris Wilson wrote:
>> On Mon, Nov 18, 2013 at 06:32:32PM -0800, Rodrigo Vivi wrote:
>>
On Mon, Nov 18, 2013 at 7:28 PM, Ausmus, James wrote:
> On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi wrote:
>>
>> This is another drm-intel-collector updated notice:
>> http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
>>
>> Here goes the update list in order for better r
On 19.11.2013 11:22, Daniel Vetter wrote:
On Tue, Nov 19, 2013 at 10:42 AM, Krzysztof Kolasa wrote:
Ok dmesg ready and is attached to email.
Should be fixed in latest drm-intel-fixes from
http://cgit.freedesktop.org/~danvet/drm-intel/
The patches are for 3.13 but will get backported as soon a
On Tue, Nov 19, 2013 at 05:15:09PM +0100, Thomas Richter wrote:
> Hi Daniel, dear intel experts,
>
> please find a patch attached that finally addresses the display
> flicker on i830 chipsets. This
> patch adds a lower watermark setting in intel_watermark_params{},
> but keeps it zero for
> all bu
On Tue, Nov 19, 2013 at 01:46:55PM +, Chris Wilson wrote:
> On Mon, Nov 18, 2013 at 06:32:32PM -0800, Rodrigo Vivi wrote:
> > From: Ville Syrjälä
> >
> > Use the same wait_for_vblank code for CTG that we use for ILK+.
> >
> > Also fix the name of the frame counter register while at it.
> >
Hi Daniel, dear intel experts,
please find a patch attached that finally addresses the display flicker
on i830 chipsets. This
patch adds a lower watermark setting in intel_watermark_params{}, but
keeps it zero for
all but the i830 chipsets. The necessary new defines are in i915_reg.h.
Greetin
On Tue, Nov 19, 2013 at 05:51:54PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 18, 2013 at 07:38:16AM +0100, Daniel Vetter wrote:
> > Haswell's DDI encoders have their own ->get_config callback and in
> >
> > commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
> > Author: Jani Nikula
> > Date: Mon Oc
On Mon, Nov 18, 2013 at 07:38:16AM +0100, Daniel Vetter wrote:
> Haswell's DDI encoders have their own ->get_config callback and in
>
> commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
> Author: Jani Nikula
> Date: Mon Oct 21 10:52:07 2013 +0300
>
> drm/i915/dp: workaround BIOS eDP bpp clam
On Mon, Nov 18, 2013 at 06:08:15PM -0800, Rodrigo Vivi wrote:
> I'm just on going with another -collector update and since this patch
> fixes a bug I think it would be a good one to include.
>
> But since it was bikeshedded it is better to ask Ville and Chris if
> their comments was a NAck or I ca
On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote:
> From: Daniel Vetter
>
> This is useful when we only have aliasing ppgtt and want to figure out
> what exactly is accesssible and what not. Paulo can somehow overwrite
> the fbcon framebuffer with the blitter on his hsw machine ...
>
On Mon, Nov 18, 2013 at 06:32:31PM -0800, Rodrigo Vivi wrote:
> From: Ville Syrjälä
>
> When the hardware frame counter reads 0xff and we're already past
> vblank start, we'd return 0x100 as the vblank counter value. Once
> we'd cross into the next frame's active portion, the vblank count
On Mon, Nov 18, 2013 at 06:32:32PM -0800, Rodrigo Vivi wrote:
> From: Ville Syrjälä
>
> Use the same wait_for_vblank code for CTG that we use for ILK+.
>
> Also fix the name of the frame counter register while at it.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Rodrigo Vivi
Reviewed-by:
Hi Bruno,
Thanks for the response. I have subscribed to the intel-gfx list. I didn't post
the error_state file since it huge.
I was trying to play Myst Online using wine-1.3.24. I get started and start
moving my avatar fairly
quickly I get the error.
I have built the latest X, mesa etc from
On Mon, Nov 18, 2013 at 06:32:37PM -0800, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> If the hardware does not support package C8, then do not even schedule
> work to enable it. Thereby we can eliminate a bunch of dangerous work.
>
> Signed-off-by: Chris Wilson
> Cc: Paulo Zanoni
> Reviewed-b
On Tue, Nov 19, 2013 at 3:08 AM, Rodrigo Vivi wrote:
> I'm just on going with another -collector update and since this patch
> fixes a bug I think it would be a good one to include.
>
> But since it was bikeshedded it is better to ask Ville and Chris if
> their comments was a NAck or I can conside
On Tue, Nov 19, 2013 at 10:55 AM, Thomas Richter wrote:
> In the meantime, I also checked with video overlays, and the minimum value
> of 6 is not yet quite optimal, higher values (lower watermarks) seem to do
> even better. From the values I get, I also estimate a minimum latency of
> about 1100
On Tue, Nov 19, 2013 at 10:42 AM, Krzysztof Kolasa wrote:
> Ok dmesg ready and is attached to email.
Should be fixed in latest drm-intel-fixes from
http://cgit.freedesktop.org/~danvet/drm-intel/
The patches are for 3.13 but will get backported as soon as they land
in upstream.
-Daniel
>
>
> On
Hi Daniel,
did you get this? (See below)?
In the meantime, I also checked with video overlays, and the minimum
value of 6 is not yet quite optimal, higher values (lower watermarks)
seem to do even better. From the values I get, I also estimate a minimum
latency of about 1100 ns, the default v
Hi
On Sunday 17 November 2013 21:05:46 Borislav Petkov wrote:
> On Sun, Nov 17, 2013 at 05:45:18PM +0100, MPhil. Emanoil Kotsev wrote:
> > How - new libraries - more exhaustive algorythms - higher cpu usage
> > etc. Some of the things M$ is doing on purpose to force you upgrade
> > your hardware e
Please boot with drm.debug=0xe added to your kernel cmdline, reproduce
the issue and then attach the complete dmesg. Please make sure it
contains everything from boot-up.
Also _always_ cc relevant mailing lists when reporting an issue
-Daniel
On Tue, Nov 19, 2013 at 9:54 AM, Krzysztof Kolasa wr
On Mon, Nov 18, 2013 at 05:38:18PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding
> wrote:
> >> Note that there's already a bit of abstraction for i2c over dp aux, but
> >> imo that's at the wrong level. At least reading through i915, gma500 and
> >> radeon code ther
29 matches
Mail list logo
