On Tue, Sep 09, 2014 at 02:43:14PM -0300, Gustavo Padovan wrote:
2014-09-09 Ville Syrjälä ville.syrj...@linux.intel.com:
On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Factor out a piece of code from
On Tue, Sep 09, 2014 at 06:58:47PM +0300, Ville Syrjälä wrote:
On Tue, Sep 09, 2014 at 11:43:19AM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The !crtc-enabled case will now be handled by the !visible code,
since the handling is basically the same.
On Tue, Sep 09, 2014 at 06:30:09PM -0700, Matt Roper wrote:
On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch adds support for CSC correction color property.
It does the following:
1. Creates a new DRM
On Tue, Sep 09, 2014 at 02:25:50PM -0700, Jesse Barnes wrote:
On Tue, 09 Sep 2014 21:45:08 +0530
Deepak S deepa...@intel.com wrote:
On Monday 08 September 2014 08:10 PM, Daniel Vetter wrote:
On Mon, Sep 08, 2014 at 05:14:23PM +0300, Ville Syrjälä wrote:
On Mon, Sep 08, 2014 at
This allows us to drop 2 header declarations from drmP.h. The 3rd one
is also used in drm_ioctl.c, so for that create a new drm_internal.h
header for non-legacy non-kms (since we have internal headers for
those parts already) declarations private to drm.ko.
Signed-off-by: Daniel Vetter
Hello Bob,
Thanks for your time and review comments.
Please find my comments inline.
Regards
Shashank
On 9/10/2014 4:21 AM, Bob Paauwe wrote:
On Tue, 9 Sep 2014 11:53:13 +0530
shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
Color manager is a framework which
On Tue, Sep 09, 2014 at 05:49:46PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
Thanks for your time and review.
Please find my comments inline.
Regards
Shashank
On 9/10/2014 4:21 AM, Bob Paauwe wrote:
On Tue, 9 Sep 2014 11:53:15 +0530
shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch adds support for CSC correction color
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell onwards, you are able to select the security bit
separate from the address space - and we always requested to use ppgtt.
This breaks
On Wed, Sep 10, 2014 at 10:26:54AM +0100, Chris Wilson wrote:
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell onwards, you are able to select the security bit
separate from the
On Wed, Sep 10, 2014 at 10:26:54AM +0100, Chris Wilson wrote:
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell onwards,
Not onwards unfortunately. BDW went back to the single bit
On Wed, Sep 10, 2014 at 01:30:45PM +0300, Ville Syrjälä wrote:
Do we actually want to make a distinction between GGTT and secure given
that HSW is the only one where it makes any difference? Why not just
set both GGGT and secure bits on HSW when I915_DISPATCH_SECURE is set?
If it is only HSW,
Hello Matt,
Thanks for your detailed descriptions, reviews comments and time.
Please find my comments inline.
Regards
Shashank
On 9/10/2014 6:58 AM, Matt Roper wrote:
On Tue, Sep 09, 2014 at 11:53:12AM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell onwards, you are able to select the security bit
separate from the address space - and we always requested to use ppgtt.
This breaks
Matt,
Thanks for your time and comments.
Please find mine inline.
Regards
Shashank
On 9/10/2014 6:59 AM, Matt Roper wrote:
On Tue, Sep 09, 2014 at 11:53:13AM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
Color manager is a framework which adds drm
On Wed, Sep 10, 2014 at 12:18:27PM +0100, Chris Wilson wrote:
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell onwards, you are able to select the security bit
ggtt). For Haswell
Matt,
Thanks for your time and review comments.
Please find mine inline.
Regards
Shashank
On 9/10/2014 6:59 AM, Matt Roper wrote:
On Tue, Sep 09, 2014 at 11:53:14AM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch does following things:
1.
On Wed, Sep 10, 2014 at 12:21:43PM +0100, Chris Wilson wrote:
On Wed, Sep 10, 2014 at 12:18:27PM +0100, Chris Wilson wrote:
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell
After a GPU reset, we reinitialize RPS and RC6 state. (This may be
unnecessary, they be preserved across the reset anyway...) Given that
the GPU was active before the reset, it is likely that we do have a
pending RPS work item and so we should simply disable it rather than
emit a warn.
Hi Daniel,
Overall I still think there's a bit too much indirection - I don't
see why
the color manager needs to sit in a separate file with separate
registration functions. Doing it like that rips apart the per-crtc
setup/teardown quite a lot and isn't how properties are handled anywhere
Hi Dave,
So here's the final bits of Ville's vblank rework with a bit of cleanup
from Mario on top.
The neat thing this finally allows is to immediately disable the vblank
interrupt on the last drm_vblank_put if the hardware has perfectly
accurate vblank counter and timestamp readout support. On
On Wed, Sep 10, 2014 at 2:05 PM, Sharma, Shashank
shashank.sha...@intel.com wrote:
- How does it tear down per CRTC setup creating a separate file :) ?
I can see all standard DRM connector property getting created in
drm_crtc.c, other properties like pfit, force-audio etc are getting
On Wed, Sep 10, 2014 at 03:00:03PM +0300, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 12:21:43PM +0100, Chris Wilson wrote:
On Wed, Sep 10, 2014 at 12:18:27PM +0100, Chris Wilson wrote:
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only
Hi Daniel, hi Ville,
just tried the new 3.17.0+rc4 kernel, though with old userspace (i.e.
xserver-xorg-video-intel is *old*, libdrm is old, mesa is old). If I do,
I get a GPU hung from xorg.conf. The same userspace works fine on
3.15.0 with patches from Ville.
Is this expected behavior or
On Wed, Sep 10, 2014 at 01:01:58PM +0100, Chris Wilson wrote:
After a GPU reset, we reinitialize RPS and RC6 state. (This may be
unnecessary, they be preserved across the reset anyway...) Given that
the GPU was active before the reset, it is likely that we do have a
pending RPS work item and
On Wed, Sep 10, 2014 at 02:17:30PM +0200, Thomas Richter wrote:
Hi Daniel, hi Ville,
just tried the new 3.17.0+rc4 kernel, though with old userspace (i.e.
xserver-xorg-video-intel is *old*, libdrm is old, mesa is old). If I do, I
get a GPU hung from xorg.conf. The same userspace works fine
From: Ville Syrjälä ville.syrj...@linux.intel.com
Use pack_aux() to construct the PSR exit DPMS D0 AUX message,
and use the defines from dp_dp_helper.h to populate the message
contents.
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Hi Dave, more fixes for 3.17, almost all Cc: stable material.
BR,
Jani.
The following changes since commit 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd:
Linux 3.17-rc4 (2014-09-07 16:09:43 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel
Damien Lespiau damien.lesp...@intel.com writes:
From: Zhe Wang zhe1.w...@intel.com
Implement common forcewake functions shared by Gen9 features.
Signed-off-by: Zhe Wang zhe1.w...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |
On Wed, 10 Sep 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Use pack_aux() to construct the PSR exit DPMS D0 AUX message,
and use the defines from dp_dp_helper.h to populate the message
contents.
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Sep 10, 2014 at 03:25:31PM +0200, Thomas Richter wrote:
Am 10.09.2014 14:22, schrieb Daniel Vetter:
On Wed, Sep 10, 2014 at 02:17:30PM +0200, Thomas Richter wrote:
Hi Daniel, hi Ville,
just tried the new 3.17.0+rc4 kernel, though with old userspace (i.e.
xserver-xorg-video-intel is
On Wed, Sep 10, 2014 at 03:25:31PM +0200, Thomas Richter wrote:
Am 10.09.2014 14:22, schrieb Daniel Vetter:
On Wed, Sep 10, 2014 at 02:17:30PM +0200, Thomas Richter wrote:
Hi Daniel, hi Ville,
just tried the new 3.17.0+rc4 kernel, though with old userspace (i.e.
xserver-xorg-video-intel
On Wed, Sep 10, 2014 at 04:45:09PM +0300, Jani Nikula wrote:
On Wed, 10 Sep 2014, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Use pack_aux() to construct the PSR exit DPMS D0 AUX message,
and use the defines from dp_dp_helper.h to populate the
Am 10.09.2014 16:00, schrieb Ville Syrjälä:
The w/a batch is corrupted. 0x400-0x1000 somehow got turned into zeroes.
Both are page boundaries, so I guess trying out Chris's TLB fix would
be worth a shot.
According to patch, it is already applied, which is no miracle since I
pulled yesterday.
Hmm, not quite an ack from my side for the pull in its current form. I
said if the two remaining issues i mentioned are addressed, then i'm
happy with it and can have my reviewed/acked-by. Looking at the code
they haven't been adressed.
However, this is easily fixable on top of the current
e-mail snafu, sent it too early by accident, and from a gmail web
interface which i'm apparently incapable of using properly...
The second fix should look like this:
A simple fix in static void vblank_disable_and_save() would be to
replace the new...
if (!vblank-enabled) {
... check by ...
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
v2: take Ville's comments
- move comment along with the pin_and_fence call
- check for error before calling i915_gem_track_fb
- move
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
v2: use struct intel_crtc as argument to intel_update_pipe_size()
v3: use 'crtc' as
i915_suspend() is called from the DRM legacy S3 suspend/S4 freeze paths
and the switcheroo suspend path. For switcheroo we only ever need to
perform a full suspend (PM_EVENT_SUSPEND) and for the DRM legacy path
we can handle the S4 freeze (PM_EVENT_FREEZE) the same way as S3
suspend. The only
The first part of the patchset (1-6) fixes an S4 bug on VLV introduced
recently. The rest unifies the various S3/S4 handlers, which are in
practice the same. The only real difference - besides some unused code -
is that during S3 suspend we disable the PCI device whereas across an S4
freeze/thaw
During S4 freeze we don't call intel_suspend_complete(), which would
save the gunit HW state, but during S4 thaw/restore events we call
intel_resume_prepare() which restores it, thus ending up in a corrupted
HW state.
Fix this by calling intel_suspend_complete() from the corresponding
freeze_late
If the device is suspended already through the switcheroo interface we
shouldn't suspend it again. We have the corresponding check for S3
suspend already, add it for S4 freeze and poweroff too.
Note that there is still the problem that the resume path should also
check for the switcheroo-off
Checking for GT faults is not specific in any way to S4 thaw, so do it
also during S3 resume and S4 restore. This allows us to unify the
handlers for these events in an upcoming patch.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 5 ++---
1 file changed, 2
The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw
events so we don't need to care about it either. Only S3 suspend and S4
freeze events are handled. Leave an assert behind to be sure.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6
This will hopefully make it easier to navigate the code without the need
to consult the full PM documentation.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bf4ff5e..89b63fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++
This is needed by an upcoming patch fixing the switcheroo/legacy suspend
paths.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git
On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
Hmm, not quite an ack from my side for the pull in its current form. I
said if the two remaining issues i mentioned are addressed, then i'm
happy with it and can have my reviewed/acked-by. Looking at the code
they
We already disable everything during S4 freeze, except the PCI device
itself. There is no reason why we couldn't disable that too and doing
so allows us to unify these handlers in the next patch with the
corresponding S3 suspend/resume handlers.
Signed-off-by: Imre Deak imre.d...@intel.com
---
To avoid processing hotplug events we disable connector polling for the
duration of S3 suspend. We also disable it for S4 freeze, and keep it
disabled after S4 thaw. This won't prevent though hotplug processing,
since we re-enable interrupts anyway. There is also no need to prevent
it at that
The logic to skip restoring GTT mappings was added to speed up
suspend/resume, but not on old GENs where not restoring them caused
problems. The check for old GENs is based on the existance of OpRegion,
but this doesn't work since opregion is initialized only after
the check. So we end up always
The suspend_late handler saves some registers and powers off the device,
so it doesn't have a big overhead. Calling it at S4 poweroff_late time
makes the power off handling identical to the S3 suspend and S4 freeze
handling, so do this for consistency.
Signed-off-by: Imre Deak imre.d...@intel.com
By now we handle switcheroo and legacy suspend/resume the same way, so
no need to keep separate functions for them.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c | 11 +++
The S3 and S4 events are now handled the same way internally, there is no
need to keep separate wrapper functions around them. Simply reuse the
suspend/resume versions everywhere.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 98
By now the S4 freeze/thaw and S3 suspend/resume events are handled the
same way, so we can rename the freeze/thaw internal helpers to
suspend/resume accordingly to make clearer what the helpers do. Also
rename i915_resume_early to i915_drm_resume_early aligning it with the
rest of the helper
During switcheroo/legacy suspend we don't call the suspend_late handler but
when resuming afterwards we call resume_early. This happened to work so far,
since suspend_late only disabled the PCI device. This changed in
commit 016970beb05da6285c2f3ed2bee1c676cb75972e
Author: Sagar Kamble
On Wed, Sep 10, 2014 at 5:29 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
Hmm, not quite an ack from my side for the pull in its current form. I
said if the two remaining issues i mentioned are addressed, then
On Wed, Sep 10, 2014 at 09:16:45AM +0200, Daniel Vetter wrote:
On Tue, Sep 09, 2014 at 02:25:50PM -0700, Jesse Barnes wrote:
On Tue, 09 Sep 2014 21:45:08 +0530
Deepak S deepa...@intel.com wrote:
On Monday 08 September 2014 08:10 PM, Daniel Vetter wrote:
On Mon, Sep 08, 2014 at
On Wed, Sep 10, 2014 at 06:16:53PM +0300, Imre Deak wrote:
The first part of the patchset (1-6) fixes an S4 bug on VLV introduced
recently. The rest unifies the various S3/S4 handlers, which are in
practice the same. The only real difference - besides some unused code -
is that during S3
On Wed, Sep 10, 2014 at 05:47:39PM +0200, Daniel Vetter wrote:
Aside if someone gets bored and wants to apply some polish: And __ variant
of force_wake_get/put which only asserts that the device isn't runtime
suspended instead of doing the runtime_pm_get/put would be cute - we have
one other
On Wed, 10 Sep 2014 14:25:00 +0530
Sharma, Shashank shashank.sha...@intel.com wrote:
Thanks for your time and review.
Thanks for working on this. This is a feature that the IOTG group is
interested in.
Please find my comments inline.
Regards
Shashank
On 9/10/2014 4:21 AM, Bob Paauwe
On Wed, 10 Sep 2014 14:10:01 +0530
Sharma, Shashank shashank.sha...@intel.com wrote:
Hello Bob,
Thanks for your time and review comments.
Please find my comments inline.
Regards
Shashank
On 9/10/2014 4:21 AM, Bob Paauwe wrote:
On Tue, 9 Sep 2014 11:53:13 +0530
On Wed, Sep 10, 2014 at 12:03:17PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
v2: take Ville's comments
- move comment along with the pin_and_fence call
-
On Wed, Sep 10, 2014 at 12:04:17PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
v2: use
Hmm Ok Daniel. Let me try and clean up the forcewake. :)
Chris, most of the debugfs is already covered with runtime_get/put. If anything
is missed we can add that
Thanks
Deepak
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, September 10, 2014
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 20 ++
drivers/gpu/drm/i915/intel_lrc.c | 21 ++-
drivers/gpu/drm/i915/intel_uncore.c | 52 +++-
4 files changed, 27 insertions(+), 68 deletions(-)
On Wed, Sep 10, 2014 at 07:26:53PM +0300, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 12:03:17PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
v2: take Ville's
2014-09-10 13:43 GMT-03:00 Chris Wilson ch...@chris-wilson.co.uk:
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 20 ++
drivers/gpu/drm/i915/intel_lrc.c | 21 ++-
drivers/gpu/drm/i915/intel_uncore.c | 52
On Wed, Sep 10, 2014 at 01:57:16PM -0300, Paulo Zanoni wrote:
2014-09-10 13:43 GMT-03:00 Chris Wilson ch...@chris-wilson.co.uk:
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 20 ++
drivers/gpu/drm/i915/intel_lrc.c | 21
On Wed, Sep 10, 2014 at 01:57:16PM -0300, Paulo Zanoni wrote:
2014-09-10 13:43 GMT-03:00 Chris Wilson ch...@chris-wilson.co.uk:
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 20 ++
drivers/gpu/drm/i915/intel_lrc.c | 21
On Wed, Sep 10, 2014 at 05:43:15PM +0100, Chris Wilson wrote:
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 20 ++
drivers/gpu/drm/i915/intel_lrc.c | 21 ++-
drivers/gpu/drm/i915/intel_uncore.c | 52
On Wed, Sep 10, 2014 at 08:15:47PM +0300, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 05:43:15PM +0100, Chris Wilson wrote:
static void gen6_force_wake_timer(unsigned long arg)
Looks like you forgot to kill the rpm_put() from the timer. And then we
also need to make sure the timer is
On Fri, Sep 05, 2014 at 01:53:12PM +0100, Damien Lespiau wrote:
Ville found out that the DATA1 register exists since SNB with some
scarce apparitions in the specs throughout the times. In his own words:
Also according to Bspec the mailbox data1 register already existed
since snb. The
On Fri, Sep 05, 2014 at 01:53:11PM +0100, Damien Lespiau wrote:
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
I think I'll punt on reviewing this for now. I need to go through
the other skl wm stuff first, and then I probaly
On Thu, Sep 04, 2014 at 07:49:43PM +0100, Damien Lespiau wrote:
From: Pradeep Bhat pradeep.b...@intel.com
This patch reads the memory latency values for all the 8 levels for
SKL. These values are needed for the Watermark computation.
v2: Incorporated the review comments from Damien on
On Thu, Sep 04, 2014 at 12:27:10PM +0100, Damien Lespiau wrote:
From: Pradeep Bhat pradeep.b...@intel.com
This patch defines SKL specific PLANE_WM Watermark registers. It also
defines macros to get the addresses of different LP levels within a pipe.
v2: Reworked the register definitions
On Wed, Sep 10, 2014 at 04:38:43PM +0530, Sharma, Shashank wrote:
Hello Matt,
Thanks for your detailed descriptions, reviews comments and time.
Please find my comments inline.
Regards
Shashank
On 9/10/2014 6:58 AM, Matt Roper wrote:
On Tue, Sep 09, 2014 at 11:53:12AM +0530,
On Wed, Sep 10, 2014 at 12:04:18PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for
Introduce a structure to track the individual forcewake domains and use
that to eliminated duplicate logic.
---
drivers/gpu/drm/i915/i915_debugfs.c | 41 +++---
drivers/gpu/drm/i915/i915_drv.h | 32 +++--
drivers/gpu/drm/i915/intel_uncore.c | 265
3
On Wed, 2014-09-10 at 17:52 +0200, Daniel Vetter wrote:
On Wed, Sep 10, 2014 at 06:16:53PM +0300, Imre Deak wrote:
The first part of the patchset (1-6) fixes an S4 bug on VLV introduced
recently. The rest unifies the various S3/S4 handlers, which are in
practice the same. The only real
On Thu, Sep 04, 2014 at 12:27:11PM +0100, Damien Lespiau wrote:
From: Pradeep Bhat pradeep.b...@intel.com
This patch defines the structures needed for computation of
watermarks of pipes and planes for SKL.
v2: Incorporated Damien's review comments and removed unused fields
in structs
On Wed, Sep 10, 2014 at 09:25:29PM +0300, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 12:04:18PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both
The data structure it was supposed to be sanity checking has long gone.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 42 -
1 file changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
If we believe that the device can cross cache domains in its prefetcher
(i.e. we allow neighbouring pages in different domains), we don't supply
a color_adjust callback. Use the presence of this callback to better
determine when we should be verifying that the GTT space we just
used is valid.
Here are a couple of small bug fixes which make DRI3/Present work
better with UXA.
[PATCH 1/2] Do not clear pending kernel events on mode switch
This patch prevents GL-based compositing managers from wedging when
performing video mode setting. The problem was that DIX was never
receiving
BO allocations for pixmaps must be aligned to the tile height, but at
some point the code was changed to align them to twice the tile
height. This overallocates pixmaps, wasting memory, but more
importantly, for buffers allocated by DRM and shared through DRI3, the
stricter alignment check causes
Let the kernel send these back to us so that DIX hears about them in
the usual way.
Mode setting while Present has a flip active will trigger an unflip
before the mode is changed. The event from that unflip will not get
processed before the mode switch is executed. Clearing the driver
queue at
On Wed, Sep 10, 2014 at 04:50:56PM +0530, Sharma, Shashank wrote:
...
+
+/* Properties */
+enum clrmgr_tweaks {
+ csc = 0,
+ gamma,
+ contrast,
+ brightness,
+ hue_saturation,
+ clrmgr_tweak_invalid
+};
These are just enums into your property name array, right? I'm not
On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch adds support for CSC correction color property.
It does the following:
1. Creates a new DRM property for CSC correction. Adds this into
mode_config.
...
90 matches
Mail list logo
