Blanking/unblanking the console in a loop on an Asus T100 sometimes
leaves the console blank. After some digging I found that applying
commit 61bc95c1fbbb6a08b55bbe161fdf1ea5493fc595
Author: Egbert Eich
Date: Mon Mar 4 09:24:38 2013 -0500
DRM/i915: On G45 enable cursor plane briefly after
Hi,
Just wondering what the point of the WARN(!encoder->crtc) in that function is,
I hit this with MST and I can't see what it should matter, where I hit
it is if I dock MST while X is running and VT switch, I get it,
I first wondered when encoder would ever be false in non-MST world
anyways, bu
Hi Daniel,
Please let me know if this patch
(http://lists.freedesktop.org/archives/intel-gfx/2014-May/045877.html)
and the patch
http://lists.freedesktop.org/archives/intel-gfx/2014-May/045804.html
require any other changes..
I have included all your review comments till date..
Thanks,
Vandana
O
On 29.05.2014 19:56, Daniel Vetter wrote:
> On Thu, May 29, 2014 at 6:11 AM, Michel Dänzer wrote:
>>
>>> We could rename the off/on to pre/post_modeset if you like, but then
>>> someone gets to audit all the other drivers. That someone isn't
>>> going to be me.
>>
>> I appreciate your caution wrt
On Thursday, May 29, 2014 02:48:44 PM Jesse Barnes wrote:
> From: Kristen Carlson Accardi
>
> Needed in ->freeze routines to figure out the target system state and
> take appropriate action.
>
> v2: split out ACPI patch
>
> Signed-off-by: Kristen Carlson Accardi
> Signed-off-by: Jesse Barnes
After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
modes
From: Kristen Carlson Accardi
Needed in ->freeze routines to figure out the target system state and
take appropriate action.
v2: split out ACPI patch
Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Jesse Barnes
---
drivers/acpi/sleep.c | 1 +
1 file changed, 1 insertion(+)
diff --git
This indicates to the firmware that it can power down various other
components or bring them back up, depending on the target system state.
Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 10 ++
1 file changed, 10 insertions(+)
d
On Fri, Apr 04, 2014 at 04:12:07PM -0700, Jesse Barnes wrote:
> Some platforms may not have it, and enumerating it is both confusing and
> time consuming due to the hotplug and DDC probing.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 i
Working for real this time. i915_ppgtt_info has all sorts of good stuff
in it and X is running nicely on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/d
All the date we print is invariant for the lifetime of the driver.
And none of it would be protected by the mode_config.mutex anyway.
So drop it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_
This goes all the way back to the introduction of this debugfs file,
even though back then no locking really was required. None of the
intermediate patches fixed this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi Daniel, hi folks,
according to my knowledge, the pipe A quirk is unconditionally enabled
on the 830 to allow resume to work properly. Unfortunately, it does
quite the opposite on the S6010, it breaks resume completely.
If the pipe A quirk is disabled, then the boot console works correctly.
On Thu, May 29, 2014 at 08:44:51AM -0700, Jesse Barnes wrote:
> On Thu, 29 May 2014 08:30:10 -0700
> "Volkin, Bradley D" wrote:
>
> > On Wed, May 28, 2014 at 03:02:24PM -0700, Jesse Barnes wrote:
> > > Need testing and possibly disabling on earlier steppings, but looks ok
> > > here on my B3.
> >
From: Kristen Carlson Accardi
This allows the system to enter the lowest power mode during system freeze.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 16 +++-
3 files changed,
From: Kristen Carlson Accardi
We want to make sure everything is disabled and at its lowest power when
freezing.
Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i9
From: Kristen Carlson Accardi
This indicates to the firmware that it can power down various other
components or bring them back up, depending on the target system state.
Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Jesse Barnes
---
drivers/acpi/sleep.c| 1 +
drivers/gpu/
From: Kristen Carlson Accardi
This matches the runtime suspend paths and allows the system to enter
the lowest power mode at freeze time.
Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --
The following series adds support for exposing various connector features using
debugfs. The first patch refactors the sysfs connector add and remove functions
into generic functions to register and unregister connectors. The remaining
patches add an interface for each connector to debugfs and expo
Introduce generic functions to register and unregister connectors. This
provides a common place to add and remove associated user space
interfaces.
Signed-off-by: Thomas Wood
---
Documentation/DocBook/drm.tmpl| 6 +++---
drivers/gpu/drm/armada/armada_output.c| 4 ++--
d
Add a file to debugfs for each connector to enable modification of the
"force" connector attribute. This allows connectors to be enabled or
disabled for testing and debugging purposes.
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_crtc.c| 17 ++-
drivers/gpu/drm/drm_debugfs.c | 101
Add a file to debugfs for each connector that allows the edid data to be
overridden.
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_crtc.c | 4 +++
drivers/gpu/drm/drm_debugfs.c | 56 ++
drivers/gpu/drm/drm_probe_helper.c | 9 +-
include
On Thu, 29 May 2014 08:30:10 -0700
"Volkin, Bradley D" wrote:
> On Wed, May 28, 2014 at 03:02:24PM -0700, Jesse Barnes wrote:
> > Need testing and possibly disabling on earlier steppings, but looks ok
> > here on my B3.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i915_
On Wed, May 28, 2014 at 03:02:24PM -0700, Jesse Barnes wrote:
> Need testing and possibly disabling on earlier steppings, but looks ok
> here on my B3.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Recent changes in igt_kms to support universal planes have removed the
plane list order guarantees that kms_plane depended upon. Ensure that
we loop over the entire plane list properly and then selectively skip
non-overlay planes.
While we're at it, update a couple igt_output_get_plane() calls to
For some of our tests, we want to make sure that bogus plane programming
attempts fail with the expected error code. Add
igt_drm_plane_try_commit() that will just return the error code on
failure rather than failing the current subtest. This lets us test the
return value against the expected erro
Add support for universal planes. This involves revamping the existing
plane handling a bit to allow primary & cursor planes to come from the
DRM plane list, rather than always being manually added. Also,
eliminate the hard-coded position of primary & cursor in the plane list
since the DRM could
Add a simple test to exercise universal plane support.
v5:
- Check that we don't have more than one primary or cursor. This will
catch accidental calls to drm_plane_init() in the kernel where
drm_universal_plane_init() was intended (these don't cause a compile
warning due to type compat
If a subtest fails, cleanup_crtc() never gets called and then the
test_data_t structure for the test is lost, including the CRC file
descriptor that we never got a chance to release; this causes all
subsequent tests to fail with -EBUSY at igt_pipe_crc_new().
The split between permanent data_t and
The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.
Prior to this patch, a plane's possible_crtcs field was purely
informational for userspace and was never actually verified at the
kernel level (aside from the primary plane helper
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
v8:
- Pin/unpin properly when clipping causes the primary plane to be
disabled when it has previously been enabled.
- s/drm_primary_helper_check_update/drm_p
In a future patch, we'll allow the primary plane to be disabled by
userspace via the universal plane API. If a modeset is requested while
the primary plane is disabled, crtc->primary->fb will be NULL which
generally triggers a full modeset (except in fastboot situations). If
we detect that the cr
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A few of the checks here were also updated based on suggestions by
V
Re-posting the final versions of these patches now that they all have a r-b, as
requested by Daniel. Corresponding i-g-t tests will be sent shortly.
Previous patch review thread and comments are here:
http://lists.freedesktop.org/archives/intel-gfx/2014-April/044527.html
Matt Roper (4):
drm:
Hi Daniel, hi folks,
still a couple of observations from my side on this. The 1024x786x24
mode here uses a clock of 65MHz (65000kHz), if that is inserted into the
watermark computation, it computes from that a prefetch of 40 entries,
and thus a watermark level of four, which is much much too hi
The always-on power well pixel path on haswell is routed such that it
bypasses the panel fitter when we use is. Which means the pfit CRC
source won't work in that configuration.
Add a new disallow-bypass flags to the pfit pipe config state and set
it when we want to use the pf CRC. Results in a bi
On Thu, May 29, 2014 at 12:41:44PM +0200, Daniel Vetter wrote:
> On Thu, May 29, 2014 at 1:21 AM, Damien Lespiau
> wrote:
> > On Thu, May 29, 2014 at 12:27:55AM +0200, Daniel Vetter wrote:
> >> - if (IS_HASWELL(dev) &&
> >> intel_crtc->config.pch_pfit.enabled)
> >> +
On Thu, May 29, 2014 at 6:11 AM, Michel Dänzer wrote:
>
>> We could rename the off/on to pre/post_modeset if you like, but then
>> someone gets to audit all the other drivers. That someone isn't
>> going to be me.
>
> I appreciate your caution wrt other drivers, but I'm worried that having
> a sec
On Thu, May 29, 2014 at 1:21 AM, Damien Lespiau
wrote:
> On Thu, May 29, 2014 at 12:27:55AM +0200, Daniel Vetter wrote:
>> - if (IS_HASWELL(dev) &&
>> intel_crtc->config.pch_pfit.enabled)
>> + if (IS_HASWELL(dev) &&
>> intel_crtc->config.pch_pfit.enabled |
From: Sourab Gupta
This patch enables the selection of MMIO flip vs CS flip at
page flip time. Earlier, this selection was done only at the
init time, so, once .queue_flip was set, it was used forever.
This patch enables this selection of flip mechanism at a time
when page flips is being issued.
From: Sourab Gupta
This patch enhances the module parameter, 'use_mmio_flip' which
enables MMIO flips, to make it tristate. The values being-
0: Force CS flip
1: Force MMIO flip (Gen5+)
>1: Driver discretion is applied while selecting CS vs MMIO flip.
For Valleyview, this driver selection happen
From: Sourab Gupta
This patch enables the framework for using MMIO based flip calls,
in contrast with the CS based flip calls which are being used currently.
MMIO based flip calls can be enabled on architectures where
Render and Blitter engines reside in different power wells. The
decision to us
From: Sourab Gupta
This patch series enables the framework for using MMIO flips in place of
Blitter ring based flips.
This is useful for Media power well residency optimization. These may be
enabled on architectures where Render and Blitter engines reside in different
power wells.
The blitter rin
43 matches
Mail list logo
