On Wednesday 23 April 2014 01:49 AM, Daniel Vetter wrote:
On Mon, Apr 21, 2014 at 07:28:54PM +0530, Deepak S wrote:
Hi Ville,
let me know if you want some of other small patches to be squashed.
Quick aside: Something seems to have gone with git send-email thread - the
patches aren't in-reply-
This follows Daniel's advice to add the two test cases based on multi drm_fd to
test the ring sync and CPU<->GPU sync.
The Broadwell GT3 machine has two independent BSD rings that can be used
to process the video commands. This is implemented in kernel driver and
transparent
to the user-space. Bu
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the CPU<->GPU sync for the second BSD ring.
V1->V2: Follow Daniel's comment to add one subtext instead of one individual
test case, which is use
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the ring sync between the two BSD rings. At the same time it also needs to
check the sync among the second BSD ring and the other rings.
V2->V3:
On Tue, 2014-04-22 at 13:44 -0600, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 02:52:04PM +0300, Imre Deak wrote:
> > On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
> > > The Broadwell GT3 machine has two independent BSD rings in kernel driver
> > > while
> > > it is transparent to the us
On Tue, 2014-04-22 at 13:48 -0600, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 03:05:03PM +0300, Imre Deak wrote:
> > On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
> > > The Broadwell GT3 machine has two independent BSD rings in kernel driver
> > > while
> > > it is transparent to the us
On 22 April 2014 20:06:14, Daniel Vetter wrote:
On Thu, Apr 17, 2014 at 07:34:31PM +0300, Jani Nikula wrote:
On Wed, 16 Apr 2014, Robert Beckett wrote:
On 25/03/2014 13:23, Chris Wilson wrote:
Try to flush out dirty pages into the swapcache (and from there into the
swapfile) when under memory
From: Paulo Zanoni
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(),
From: Paulo Zanoni
If intel_edp_init_connector() returns false, then we know that
is_edp() is true because of the early return at
intel_edp_init_connector(). So remove the redundant check.
Change proposed by Chris on his review to "drm/i915: get power domain
in case the BIOS enabled eDP VDD".
S
From: Paulo Zanoni
This was suggested by Chris on his review to the first version of
"drm/i915: get power domain in case the BIOS enabled eDP VDD". Well,
at least that's what I understood from his comment :)
The downside of this patch is that in a few places we will call
intel_display_port_power
From: Paulo Zanoni
We already call intel_dp_power_get, which will get a power domain, and
every power domain should get a runtime PM reference, which will wake
up the machine.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/
Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At least one such case I could trigger is
the simulated reset via the i915_wedged debugfs entry. Fix this by
getting an RPM r
Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At least one such case I could trigger is
the simulated reset via the i915_wedged debugfs entry. Fix this by
getting an RPM r
2014-04-11 6:02 GMT-03:00 Daniel Vetter :
> On Thu, Apr 10, 2014 at 10:52:26AM -0700, Ben Widawsky wrote:
>> On Thu, Apr 10, 2014 at 10:50:43AM -0700, Ben Widawsky wrote:
>> > On Thu, Apr 10, 2014 at 09:04:47AM +0200, Daniel Vetter wrote:
>> > > This reverts commit 4b28a1f3ef55a3b0b68dbab1fe6dbaf18
On Tue, Apr 22, 2014 at 10:17:50PM +0200, Daniel Vetter wrote:
> Otherwise we'll end up spamming dmesg on every context creation on snb
> with vt-d enabled. This regression was introduced in
>
> commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
> Author: Ben Widawsky
> Date: Fri Dec 6 14:11:14 20
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes
Date: Fri Mar 7 08:5
On Tue, Apr 22, 2014 at 11:34:01PM +0300, Imre Deak wrote:
> On Tue, 2014-04-22 at 21:38 +0200, Daniel Vetter wrote:
> > On Fri, Apr 18, 2014 at 03:47:45PM +0300, Imre Deak wrote:
> > > Atm we can end up in the GPU reset deferred work in D3 state if the last
> > > runtime PM reference is dropped be
On Tue, Apr 22, 2014 at 08:17:52PM +0300, Jani Nikula wrote:
> Most likely the minimums for both should be enough for enabling the
> native resolution on the eDP.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73539
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
> Signe
On Tue, Apr 22, 2014 at 08:19:41PM +0300, Mika Kuoppala wrote:
> Hi,
>
> Here are patches to initialize first render context to a hopefully,
> valid state. If pipeline/context is not initialized and we enter rc6 on bdw,
> the render ring can hung on the first batch submitted. That is atleast
> th
On Tue, 2014-04-22 at 21:38 +0200, Daniel Vetter wrote:
> On Fri, Apr 18, 2014 at 03:47:45PM +0300, Imre Deak wrote:
> > Atm we can end up in the GPU reset deferred work in D3 state if the last
> > runtime PM reference is dropped between detecting a hang/scheduling the
> > work and executing the wo
On Tue, Apr 22, 2014 at 08:19:43PM +0300, Mika Kuoppala wrote:
> HW guys say that it is not a cool idea to let device
> go into rc6 without proper 3d pipeline state.
>
> For each new uninitialized context, generate a
> valid null render state to be run on context
> creation.
>
> This patch introd
On Mon, Apr 21, 2014 at 07:28:54PM +0530, Deepak S wrote:
> Hi Ville,
>
> let me know if you want some of other small patches to be squashed.
Quick aside: Something seems to have gone with git send-email thread - the
patches aren't in-reply-to the cover letter. No idea how that happened
though ..
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This regression was introduced in
commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
Author: Ben Widawsky
Date: Fri Dec 6 14:11:14 2013 -0800
drm/i915: Reorganize intel_enable_ppgtt
References: https://
On Fri, Apr 18, 2014 at 06:29:45PM +0200, Alessandro Suardi wrote:
> forwarding from my lkml post as probably more appropriate to send this here...
Yup, but just adding more cc's is preferred. I've re-added lkml for
reference. Bug is fairly obvious regression in 3.15, patch is on the way.
-Daniel
On Fri, Apr 18, 2014 at 08:27:04AM +0100, Chris Wilson wrote:
> Currently objects for which the hardware needs a contiguous physical
> address are allocated a shadow backing storage to satisfy the contraint.
> This shadow buffer is not wired into the normal obj->pages and so the
> physical object i
On Thu, Apr 17, 2014 at 10:37:37AM +0800, Zhao Yakui wrote:
> Based on the hardware spec, the BDW GT3 machine has two independent
> BSD ring that can be used to dispatch the video commands.
> So just initialize it.
>
> V3->V4: Follow Imre's comment to do some minor updates. For example:
> more com
On Tue, Apr 22, 2014 at 03:05:03PM +0300, Imre Deak wrote:
> On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
> > The Broadwell GT3 machine has two independent BSD rings in kernel driver
> > while
> > it is transparent to the user-space driver. In such case it needs to check
> > the CPU<->GPU
On Tue, Apr 22, 2014 at 02:52:04PM +0300, Imre Deak wrote:
> On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
> > The Broadwell GT3 machine has two independent BSD rings in kernel driver
> > while
> > it is transparent to the user-space driver. In such case it needs to check
> > the ring sync
On Fri, Apr 18, 2014 at 03:47:45PM +0300, Imre Deak wrote:
> Atm we can end up in the GPU reset deferred work in D3 state if the last
> runtime PM reference is dropped between detecting a hang/scheduling the
> work and executing the work. At least one such case I could trigger is
> the simulated re
On Fri, Apr 18, 2014 at 12:14:16PM -0700, Andrew Morton wrote:
> On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson
> wrote:
>
> > During testing of i915.ko with working texture sets larger than RAM, we
> > encounter OOM with plenty of memory still trapped within writeback, e.g:
> >
> > [ 42.386
On Tue, Apr 22, 2014 at 01:06:45PM +, Mateo Lozano, Oscar wrote:
> > Subject: [Intel-gfx] [PATCH 6/6] drm/i915: Kick start the rings
> >
> > On g4x, we have an issue where the register write to setup the rings do not
> > always take. However, it appears that the current check also passes only
On Thu, Apr 17, 2014 at 03:21:27PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 11, 2014 at 02:25:41PM -0700, Jesse Barnes wrote:
> > I don't think this is necessary; at least it doesn't appear to be on my
> > BYT. Dropping it speeds up our shutdown code a little, in some cases
> > resulting in faste
On Fri, Apr 11, 2014 at 05:01:20PM +0530, Vandana Kannan wrote:
> Adding relevant read out comparison code, in check_crtc_state, for the new
> member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
> values for a DP downclock mode (if available). Suggested by Daniel.
>
> Signed-of
On Thu, Apr 17, 2014 at 07:34:31PM +0300, Jani Nikula wrote:
> On Wed, 16 Apr 2014, Robert Beckett wrote:
> > On 25/03/2014 13:23, Chris Wilson wrote:
> >> Try to flush out dirty pages into the swapcache (and from there into the
> >> swapfile) when under memory pressure and forced to drop GEM obje
On Thu, Apr 17, 2014 at 04:18:46PM -0700, Volkin, Bradley D wrote:
> On Wed, Mar 19, 2014 at 04:13:06AM -0700, Tvrtko Ursulin wrote:
> > + bo_ptr = (char *)(((unsigned long)ptr + (PAGE_SIZE - 1))
> > + & ~(PAGE_SIZE - 1));
>
> You might add an ALIGN macro in thi
On Tue, Apr 22, 2014 at 07:14:22PM +0200, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 08:18:30AM -0700, Matt Roper wrote:
> > On Tue, Apr 22, 2014 at 03:47:37PM +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 11, 2014 at 02:13:42PM -0700, Matt Roper wrote:
> > ...
> > > > + int ret;
> > > >
On Tue, Apr 22, 2014 at 07:22:40PM +0300, Imre Deak wrote:
> On Tue, 2014-04-22 at 18:10 +0300, Jani Nikula wrote:
> > Knut, thanks for a quick bisect.
> >
> > Imre, please have a look at the sdvo WARN related to sysfs links in the
> > dmesg.
>
> It's probably the same WARN fixed by:
> http://pat
Add runtime PM support for VLV, but leave it disabled. The next patch
enables it.
The suspend/resume sequence used is based on [1] and [2]. In practice we
depend on the GT RC6 mechanism to save the HW context depending on the
render and media power wells. By the time we run the runtime suspend
cal
During runtime suspend there can be a last pending rps.work, so make
sure it's canceled. Note that in the runtime suspend callback we can't
get any RPS interrupts since it's called only after the GPU goes idle
and we set the minimum RPS frequency. The next possibility for an RPS
interrupt is only a
On Tue, Apr 22, 2014 at 04:23:12PM +0100, Chris Wilson wrote:
> On Tue, Apr 22, 2014 at 06:16:34PM +0300, Abdiel Janulgue wrote:
> > This patch series enables resource streamer for xf86-video-intel UXA.
> >
> > Fixes i965 Mesa driver that makes use of resource streamer optimization
> > to survive
These are generated with intel-gpu-tools/tools/null_state_gen.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_renderstate_gen6.h | 281 ++-
drivers/gpu/drm/i915/intel_renderstate_gen7.h | 245 -
drivers/gpu/drm/i915/intel_renderstate_gen8.h | 471 +
Hi,
Here are patches to initialize first render context to a hopefully,
valid state. If pipeline/context is not initialized and we enter rc6 on bdw,
the render ring can hung on the first batch submitted. That is atleast
the hypothesis this work is based on.
The states are stripped from rendercop
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with emty states.
Signed-off-by: Mika Kuoppala
---
drivers/g
as need it for generating batch commands and state
in subsequent commit
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_cmd_parser.c |4 ++--
drivers/gpu/drm/i915/i915_drv.h|1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_c
Most likely the minimums for both should be enough for enabling the
native resolution on the eDP.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73539
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 23
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 52 ---
1 file changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index fba9efd09e87..87a1fa6485be 100644
--- a/drive
These are RFC-ish patches to use link params from VBT for eDP, to
hopefully fix issues related to preferring fast over wide lane
configuration with some eDP panels. Untested, as I don't have hw that
actually fails.
BR,
Jani.
Jani Nikula (2):
drm/i915: clean up VBT eDP link param decoding
drm
On Tue, Apr 22, 2014 at 08:18:30AM -0700, Matt Roper wrote:
> On Tue, Apr 22, 2014 at 03:47:37PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 11, 2014 at 02:13:42PM -0700, Matt Roper wrote:
> ...
> > > + int ret;
> > > +
> > > + /*
> > > + * At the moment we use the same set of setplane restriction
On Wed, Apr 09, 2014 at 09:47:57AM -0700, Daniel Vetter wrote:
> On Wed, Apr 09, 2014 at 08:12:28AM -0700, Volkin, Bradley D wrote:
> > On Tue, Apr 08, 2014 at 11:20:30PM -0700, Chris Wilson wrote:
> > > On Tue, Apr 08, 2014 at 02:22:16PM -0700, bradley.d.vol...@intel.com
> > > wrote:
> > > > From
On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> To implement hotplug detection in a race-free manner, drivers must call
> drm_kms_helper_poll_init() before hotplug events can be triggered. Such
> events can be triggered right after any of the encoders or
On Tue, Apr 22, 2014 at 04:42:19PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> There's no need for this to be modifiable. Make it const so that it can
> be put into the .rodata section.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/armada/
On Tue, Apr 22, 2014 at 06:16:34PM +0300, Abdiel Janulgue wrote:
> This patch series enables resource streamer for xf86-video-intel UXA.
>
> Fixes i965 Mesa driver that makes use of resource streamer optimization
> to survive a full piglit run without bricking the machine. Previously,
> I get rand
On Tue, Apr 22, 2014 at 03:47:37PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 11, 2014 at 02:13:42PM -0700, Matt Roper wrote:
...
> > + int ret;
> > +
> > + /*
> > +* At the moment we use the same set of setplane restrictions as the
> > +* DRM primary plane helper, so go ahead and just c
This patch series enables resource streamer for xf86-video-intel UXA.
Fixes i965 Mesa driver that makes use of resource streamer optimization
to survive a full piglit run without bricking the machine. Previously,
I get random hungs when doing a full piglit round when enabling RS.
After months of
Signed-off-by: Abdiel Janulgue
---
src/intel_options.c|1 +
src/intel_options.h|1 +
src/uxa/intel.h|3 +++
src/uxa/intel_driver.c | 10 +-
4 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/intel_options.c b/src/intel_options.c
index 02a4ae1.
Code is based on my hw-generated binding table code for Mesa
adapted to i965_composite path in UXA.
Signed-off-by: Abdiel Janulgue
---
src/uxa/i965_3d.c |5 ++-
src/uxa/i965_reg.h |8 +
src/uxa/i965_render.c | 78 +++
David,
My apologies for starting a pre-mature design discussion.
Daniel,
Thanks for pointing out first two things, It was not known to me, I will take
care of this in future.
First time I presented color-manager design, in internal display design forum,
where most of the reviewers were not th
On Tue, Apr 22, 2014 at 04:25:22PM +0200, Daniel Vetter wrote:
> I think this doesn't have the possibility to have broken anything yet
> since we don't allow the same context on multiple rings. Except the
> default one, but mesa creates new contexts anyway afaik. Or am I wrong?
It's a minor regres
From: Thierry Reding
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/bochs/bochs_fbdev.
From: Thierry Reding
A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized yet. This happ
From: Daniel Vetter
Some drivers need to be able to have a perfect race-free fbcon setup.
Current drivers only enable hotplug processing after the call to
drm_fb_helper_initial_config which leaves a tiny but important race.
This race is especially noticable on embedded platforms where the
driver
From: Thierry Reding
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplu
On Fri, Apr 18, 2014 at 10:51:46AM +0100, Chris Wilson wrote:
> On Fri, Dec 06, 2013 at 02:11:02PM -0800, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > Previously we dropped the association of a context to a ring. It is
> > however very important to know which ring a context ran on (we could
On Tue, Apr 22, 2014 at 12:07:41PM +, Sharma, Shashank wrote:
> Thanks again David,
> Comments inline.
Three things:
- Please don't send out .pptx files to upstream/public mailing lists,
that's just not how the upstream community works.
- Please either fix up ms outlook to do proper in-li
> Subject: [Intel-gfx] [PATCH 6/6] drm/i915: Kick start the rings
>
> On g4x, we have an issue where the register write to setup the rings do not
> always take. However, it appears that the current check also passes only by
> chance, a second reading of the register returns a different broekn valu
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Chris Wilson
> Sent: Wednesday, April 09, 2014 9:20 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 4/6] drm/i915: Mark device as wedged if we fail to
> resume
>
>
> Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Include a little more information
> about why ring init fails
>
> If we include the expected values for the failing ring register checks, it
> makes it
> marginally easier to see which is the culprit.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Osc
> Subject: [Intel-gfx] [PATCH 2/6] drm/i915: Preserve ring buffers objects
> across
> resume
>
> Tearing down the ring buffers across resume is overkill, risks unnecessary
> failure and increases fragmentation.
>
> After failure, since the device is still active we may end up trying to write
>
> Subject: [Intel-gfx] [PATCH 3/6] drm/i915: Allow the module to load even if we
> fail to setup rings
>
> Even without enabling the ringbuffers to allow command execution, we can still
> control the display engines to enable modesetting. So make the ringbuffer
> initialization failure soft, and m
On Fri, Apr 11, 2014 at 02:13:42PM -0700, Matt Roper wrote:
> Intel hardware allows the primary plane to be disabled independently of
> the CRTC. Provide custom primary plane handling to allow this.
>
> v4:
> - Don't add a primary_plane field to intel_crtc; that was left over
>from a much ea
> Subject: [Intel-gfx] [PATCH 1/6] drm/i915: Replace hardcoded cacheline size
> with macro
>
> For readibility and guess at the meaning behind the constants.
>
> v2: Claim only the meagerest connections with reality.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Oscar Mateo
___
Thanks again David,
Comments inline.
Regards
Shashank
-Original Message-
From: David Herrmann [mailto:dh.herrm...@gmail.com]
Sent: Tuesday, April 22, 2014 5:10 PM
To: Sharma, Shashank
Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Ville
Syrjälä; Thierry Reding; A
On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
> The Broadwell GT3 machine has two independent BSD rings in kernel driver while
> it is transparent to the user-space driver. In such case it needs to check
> the CPU<->GPU sync for the second BSD ring.
>
> V1->V2: Follow Daniel's comment to ad
On Mon, 21 Apr 2014, Knut Petersen wrote:
> Booting kernel 3.15-rc2 on an AOpen i915GMm-hfs, I see the framebuffer broken.
> Only about the upper left quarter of the monitor is used for displaying the
> boot messages,
> these (and the cursor) are replicated at the right of that area.
Is this bef
On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
> The Broadwell GT3 machine has two independent BSD rings in kernel driver while
> it is transparent to the user-space driver. In such case it needs to check
> the ring sync between the two BSD rings. At the same time it also needs to
> check the
On Tue, Apr 22, 2014 at 12:08 PM, Thierry Reding
wrote:
> void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
> *helper,
>const struct drm_fb_helper_funcs *funcs)
> {
> helper->funcs = funcs;
> helper->dev = dev;
> }
>
> So I wonder
Hi
On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank
wrote:
> 1) Why do you register only a single property? Why not register a separate
> property for each color-correction that is available? This way you can drop
> the property-id and use the high-level DRM-prop IDs/names.
>>> That’s the who
Thanks for the review and comments David.
Please find my comments inline.
Regards
Shashank
-Original Message-
From: David Herrmann [mailto:dh.herrm...@gmail.com]
Sent: Tuesday, April 22, 2014 3:08 PM
To: Sharma, Shashank
Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop
On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> > > Current drivers only
Hi
On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank
wrote:
> Gentle reminder
Usual approach is to send any proposals as inline plain-text. It's
really hard to comment on attachments, especially if it's an MS-office
format. Anyhow, some comments on the proposal:
1) Why do you register only a si
On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> > > Current drivers only
On Sun, Apr 20, 2014 at 12:50:23PM -0700, Stephen Hemminger wrote:
> I got this on my desktop (Haswell) box when resuming from suspend
> with Debian testing kernel (3.13).
I've just worked on a massive patch series to rework the haswell WRPLL. It
kills the hsw specific shared pll framework and swi
On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > Some drivers need to be able to have a perfect race-free fbcon setup.
> > Current drivers only enable hotplug processing after the call to
> > drm_fb_helper_initial_c
On Thu, Apr 01, 2014 Felix Miata wrote:
> On 2014-03-31 10:05 (GMT+0200) Janus composed:
>> I have the same problem as the one described by Michael bellow: the
>> Intel Graphic card produces eye strain and headache after some minutes
>> of using it. I found a lot of people complaining on the same p
I got this on my desktop (Haswell) box when resuming from suspend
with Debian testing kernel (3.13).
[147765.739493] [ cut here ]
[147765.739501] WARNING: CPU: 1 PID: 29426 at
/build/linux-oxWk_8/linux-3.13.7/drivers/gpu/drm/i915/intel_ddi.c:763
intel_ddi_pll_mode_set+0x
forwarding from my lkml post as probably more appropriate to send this here...
thanks,
-- Forwarded message --
From: Alessandro Suardi
Date: Fri, Apr 18, 2014 at 12:31 AM
Subject: 3.15-rc1: Endless "Disabling PPGTT because VT-d is on"
messages in /var/log/messages
To: "linux-ker.
On Thu, Apr 01, 2014 Felix Miata wrote:
> On 2014-03-31 10:05 (GMT+0200) Janus composed:
>> I have the same problem as the one described by Michael bellow: the
>> Intel Graphic card produces eye strain and headache after some minutes
>> of using it. I found a lot of people complaining on the same p
87 matches
Mail list logo
