On Tue, Jan 14, 2014 at 06:14:07AM -0800, Ben Widawsky wrote:
> +#include
> +#include
> +#include
> +#include
> +#include
> +#if 0
> +#include
> +#include
> +#endif
Could remove that #if
Last time I remember we talked about a intel_display_test.c where we
could shove more stuff (Rodrigo's
On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote:
> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> > Both i915 and Armada had the exact same implementation. For an upcoming
> > patch, I'd like to call this function from two different source files in
> > i915, and havin
The opregion notification for runtime suspend is currently D1, not D3.
Signed-off-by: Kristen Carlson Accardi
---
drivers/gpu/drm/i915/i915_drv.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index
On Tue, Jan 14, 2014 at 06:14:07AM -0800, Ben Widawsky wrote:
> At almost 800 lines of code, with almost a function per platform, this
> code was cluttering up the existing debugfs file, which has
> historically had fairly small functions.
>
> Patch should have no functional changes.
>
> Signed-o
On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> Both i915 and Armada had the exact same implementation. For an upcoming
> patch, I'd like to call this function from two different source files in
> i915, and having it available externally helps there too.
>
> While moving, add 'debu
At almost 800 lines of code, with almost a function per platform, this
code was cluttering up the existing debugfs file, which has
historically had fairly small functions.
Patch should have no functional changes.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/Makefile | 2 +-
driv
Both i915 and Armada had the exact same implementation. For an upcoming
patch, I'd like to call this function from two different source files in
i915, and having it available externally helps there too.
While moving, add 'debugfs_' to the name in order to match the other drm
debugfs helper functio
On Tue, 14 Jan 2014 15:06:46 -0800
Kristen Carlson Accardi wrote:
> On Tue, 14 Jan 2014 11:19:44 -0800
> Jesse Barnes wrote:
>
> > On Tue, 14 Jan 2014 10:26:02 +0100
> > Daniel Vetter wrote:
> >
> > > On Mon, Jan 13, 2014 at 01:32:45PM -0800, Kristen Carlson Accardi wrote:
> > > > The opregio
On Tue, 14 Jan 2014 11:19:44 -0800
Jesse Barnes wrote:
> On Tue, 14 Jan 2014 10:26:02 +0100
> Daniel Vetter wrote:
>
> > On Mon, Jan 13, 2014 at 01:32:45PM -0800, Kristen Carlson Accardi wrote:
> > > The opregion notification for runtime suspend should be D1, not D3.
> > > This is to maintain c
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 in place now and seem relatively stable.
> >
> > Signed-off-by: Jesse
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 in place now and seem relatively stable.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 --
> 1 file chang
On Mon, 13 Jan 2014 17:55:27 -0200
Paulo Zanoni wrote:
> 2014/1/8 Jesse Barnes :
> > No idea if this is correct or not, all the WRPLL programming is new to
> > me. Paulo, can you take a look? At least it doesn't complain on my BDW
> > here...
>
> As a side note: can't we add some debugfs inter
On Tue, 14 Jan 2014 10:26:02 +0100
Daniel Vetter wrote:
> On Mon, Jan 13, 2014 at 01:32:45PM -0800, Kristen Carlson Accardi wrote:
> > The opregion notification for runtime suspend should be D1, not D3.
> > This is to maintain compatibility with firmware.
> >
> > Signed-off-by: Kristen Carlson A
It ought to work ok in 3.14. We have some fun stuff coming after that,
but all the basics are in place now and seem relatively stable.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/g
On Tue, Jan 14, 2014 at 06:29:48PM +, Beckett, Robert wrote:
> In Makefile language, rule and dependency definitions use immediate
> expansions of variables, so they get expanded as soon as the rule is
> created (1st pass). Rule implementation (a.k.a recipe) use deferred
> expansion (2nd pass).
In Makefile language, rule and dependency definitions use immediate expansions
of variables, so they get expanded as soon as the rule is created (1st pass).
Rule implementation (a.k.a recipe) use deferred expansion (2nd pass).
Android effectively makes all Android.mk files a single makefile by i
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 DPMS on
* return errors
* use _eDP1 suffix for easy future extensi
Signed-off-by: Rodrigo Vivi
---
tests/Android.mk | 1 +
tests/Makefile.sources | 1 +
tests/kms_sink_crc_basic.c | 201 +
3 files changed, 203 insertions(+)
create mode 100644 tests/kms_sink_crc_basic.c
diff --git a/tests/Android.mk
This address will be used to verify panel CRC for test and
validation purposes.
Signed-off-by: Rodrigo Vivi
---
include/drm/drm_dp_helper.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1d09050..ba0b90d 100644
---
On Tue, Jan 14, 2014 at 06:01:38PM +, robert.beck...@intel.com wrote:
> From: Robert Beckett
>
> Fix usage of shared variable LOCAL_PATH in deferred variable expansion area.
Out of curiosity, do you mind explaining what the late evaluation of
LOCAL_PATH broke? and why you didn't need to upda
From: Robert Beckett
Fix usage of shared variable LOCAL_PATH in deferred variable expansion area.
Signed-off-by: Robert Beckett
---
tests/Android.mk |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/Android.mk b/tests/Android.mk
index c65f94c..abccb7f 100644
-
On Tue, Jan 14, 2014 at 10:54 AM, Alex Deucher wrote:
> On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding
> wrote:
>> Hi,
>>
>> This small series introduces some infrastructure to support AUX channels
>> in a generic way. Drivers make use of it by embedding and filling in a
>> struct drm_dp_aux. Va
On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding
wrote:
> Hi,
>
> This small series introduces some infrastructure to support AUX channels
> in a generic way. Drivers make use of it by embedding and filling in a
> struct drm_dp_aux. Various helpers can then be used to for example read
> from or wri
On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding
wrote:
> Add a helper to probe a DP link (read out the supported DPCD revision,
> maximum rate, link count and capabilities) as well as power up the DP
> link and configure it accordingly.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v3:
> -
On Fri, 10 Jan 2014, Cyrille Pontvieux wrote:
> I recently acquired a Toshiba laptop with a Intel Graphics 4600M in it
> (8086:0416, subsystem 1179:fa82).
> This Toshiba system is provided with UEFI (EFI Insyde H2O 1.30).
> I compiled and use Linux kernel 3.13-rc7 (config.gz attached)
> This syst
Hi,
This small series introduces some infrastructure to support AUX channels
in a generic way. Drivers make use of it by embedding and filling in a
struct drm_dp_aux. Various helpers can then be used to for example read
from or write to the DPCD.
Patch 1 adds the basic infrastructure as well as a
The function reads the link status (6 bytes starting at offset 0x202)
from the DPCD so that it can be conveniently passed to other DPCD
helpers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 16
include/drm/drm_dp_helper.h | 3 +++
2 files changed, 19
Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
infrastructure. It extracts the retry logic from existing drivers, which
should help in porting those drivers to this new helper.
Signed-off-by: Thierry Reding
---
Changes in v3:
- add back DRM_DEBUG_KMS and DRM_ERROR message
This is a superset of the current i2c_dp_aux bus functionality and can
be used to transfer native AUX in addition to I2C-over-AUX messages.
Helpers are provided to read and write the DPCD, either blockwise or
byte-wise. Many of the existing helpers for DisplayPort take a copy of a
portion of the D
Add a helper to probe a DP link (read out the supported DPCD revision,
maximum rate, link count and capabilities) as well as power up the DP
link and configure it accordingly.
Signed-off-by: Thierry Reding
---
Changes in v3:
- split into drm_dp_link_power_up() and drm_dp_link_configure()
- do not
On Tue, 14 Jan 2014, Daniel Vetter wrote:
> On Mon, Jan 13, 2014 at 03:16:42PM -0500, Alan Stern wrote:
> > On Wed, 8 Jan 2014, Daniel Vetter wrote:
> >
> > > On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote:
> > > > On Wed, 8 Jan 2014, Daniel Vetter wrote:
> > > >
> > > > > On Wed, Ja
On Mon, 13 Jan 2014, Alan Stern wrote:
> On Wed, 8 Jan 2014, Daniel Vetter wrote:
>
>> On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote:
>> > On Wed, 8 Jan 2014, Daniel Vetter wrote:
>> >
>> > > On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote:
>> > > > On Tue, 7 Jan 2014, Dan
On Tue, 2014-01-14 at 14:31 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> crtc->new_config is only relevant for pipes that are going to be active
> post-modeset. Set the pointer to NULL for all pipes that are going to
> be disabled. This is done to help catch bugs where so
From: Ville Syrjälä
crtc->new_config is only relevant for pipes that are going to be active
post-modeset. Set the pointer to NULL for all pipes that are going to
be disabled. This is done to help catch bugs where some piece of code
would go looking at crtc->new_config even if the data there is st
On Tue, Jan 14, 2014 at 01:36:32PM +0200, Mika Kuoppala wrote:
> Daniel Vetter writes:
>
> > This is user-triggerable and hence we should not allow it to spam
> > dmesg. Also, it upsets the nice dmesg tracking piglit does.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72740
> > C
Daniel Vetter writes:
> This is user-triggerable and hence we should not allow it to spam
> dmesg. Also, it upsets the nice dmesg tracking piglit does.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72740
> Cc: Mika Kuoppala
> Signed-off-by: Daniel Vetter
Reviewed-by: Mika Kuoppala
From: Ville Syrjälä
crtc->new_config is only relevant for pipes that are going to be active
post-modeset. Set the pointer to NULL for all pipes that are going to
be disabled. This is done to help catch bugs where some piece of code
would go looking at crtc->new_config even if the data there is st
On Tue, Jan 14, 2014 at 11:40:54AM +0100, Daniel Vetter wrote:
> This is user-triggerable and hence we should not allow it to spam
> dmesg. Also, it upsets the nice dmesg tracking piglit does.
Make note that this is just extra debugging information, mostly
unwanted, in case of a hang and that ther
This is user-triggerable and hence we should not allow it to spam
dmesg. Also, it upsets the nice dmesg tracking piglit does.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72740
Cc: Mika Kuoppala
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1
On Jan-02-2014 4:05 AM, Ben Widawsky wrote:
> Hi Daniel, and welcome back.
>
> Tomorrow I go on vacation, and since it's more or less the end of the
> day for anyone still submitting or reviewing patches, I figured now is
> as good a time as any to do this.
>
> http://cgit.freedesktop.org/~bwidaw
On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
> Does that -1 ever make sense? We don't support mode-object-hotplugging
> so all "drm_crtc" objects are known at initialization time. I'd rather
> put a BUG() here than a silent -1. This also makes drm_crtc_mask()
> redundant.
I disa
On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote:
> Hi Russel
>
> On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
> >> Does that -1 ever make sense? We don't support mode-object-hotplugging
> >> s
On Mon, Jan 13, 2014 at 01:32:45PM -0800, Kristen Carlson Accardi wrote:
> The opregion notification for runtime suspend should be D1, not D3.
> This is to maintain compatibility with firmware.
>
> Signed-off-by: Kristen Carlson Accardi
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> 1 file ch
Thanks Daniel. I will wait for Chris feedback and then address the comments.
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, January 14, 2014 2:52 PM
To: S, Deepak
Cc: intel-gfx@lists.freedesktop.org; Chris Wilson
Subject: R
On Thu, Jan 09, 2014 at 07:31:08PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> When current delay is already at max delay, Let's disable the PM UP
> THRESHOLD INTRRUPTS, so that we will not get further interrupts until
> current delay is less than max delay, Also request for the PM DOWN
>Yeah if we need to bring the gfx clocks up (which makes sense) then I guess we
>need this. I'm not sure about the wait on the punit though; that could end up
>penalizing us in bursty workloads, since the punit can take quite some time to
>update the freq, but I don't actually see a wait here?
On Mon, Jan 13, 2014 at 03:16:42PM -0500, Alan Stern wrote:
> On Wed, 8 Jan 2014, Daniel Vetter wrote:
>
> > On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote:
> > > On Wed, 8 Jan 2014, Daniel Vetter wrote:
> > >
> > > > On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote:
> > > >
On Mon, Jan 13, 2014 at 06:03:01PM +, Damien Lespiau wrote:
> The ->detect() vfunc of connectors is usually responsible for setting the
> encoder type on intel_digital_ports when a hotplug event happens.
>
> However we sometimes want to force a modeset on a specific connector:
> - the user c
48 matches
Mail list logo
