On Tue, Sep 09, 2014 at 03:14:29PM +0100, John Harrison wrote:
> I pulled a fresh tree on Monday and applied this set of patches.
> There were two conflicts. It looks like nightly does not have
> 'i915_gem_context_setparam_ioctl' yet but the tree the patches came
> from does. Also, my tree has 'DRM
On Thu, Sep 11, 2014 at 12:47:21AM -0600, Jasper St. Pierre wrote:
>Why doesn't mesa allocate buffers in the same way for those chips, then?
Good question.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel
On Wed, Sep 10, 2014 at 02:09:07PM -0700, Keith Packard wrote:
> [PATCH 2/2] Correct BO allocation alignment
>
> This patch makes UXA and Mesa agree about how buffers are allocated
> for images. Without this, UXA was requiring larger padding, which
> meant that converting some textures into pixma
On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sha...@intel.com wrote:
> From: Shashank Sharma
>
> 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.
...
One thing I forgot t
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 proper
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 mod
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 s
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 notific
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.
Sign
The data structure it was supposed to be sanity checking has long gone.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 42 -
1 file changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
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
> >
> > Fold intel_pipe_set_base() in the update primary plane path merging
> > pieces of code that are common to both paths.
> >
> > Basica
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 rea
On Thu, Sep 04, 2014 at 12:27:11PM +0100, Damien Lespiau wrote:
> From: Pradeep Bhat
>
> 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 for future featu
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 files
On Wed, Sep 10, 2014 at 12:04:18PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> 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 check
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, sha
On Thu, Sep 04, 2014 at 12:27:10PM +0100, Damien Lespiau wrote:
> From: Pradeep Bhat
>
> 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 and associated macr
On Thu, Sep 04, 2014 at 07:49:43PM +0100, Damien Lespiau wrote:
> From: Pradeep Bhat
>
> 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 register
> indent
On Fri, Sep 05, 2014 at 01:53:11PM +0100, Damien Lespiau wrote:
> Suggested-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
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 need to stare at the
result a bit before I can think ab
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. Th
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 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 01:57:16PM -0300, Paulo Zanoni wrote:
> 2014-09-10 13:43 GMT-03:00 Chris Wilson :
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
> > drivers/gpu/drm/i915/intel_display.c | 20 ++
> > drivers/gpu/drm/i915/intel_lrc.c | 21 ++-
> > drive
On Wed, Sep 10, 2014 at 01:57:16PM -0300, Paulo Zanoni wrote:
> 2014-09-10 13:43 GMT-03:00 Chris Wilson :
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
> > drivers/gpu/drm/i915/intel_display.c | 20 ++
> > drivers/gpu/drm/i915/intel_lrc.c | 21 ++-
> > drive
2014-09-10 13:43 GMT-03:00 Chris Wilson :
> ---
> 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 07:26:53PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 10, 2014 at 12:03:17PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Optimize code avoiding helding dev mutex if old fb and current fb
> > are the same.
> >
> > v2: take Ville's comments
> > - move
---
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(-)
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 9
On Wed, Sep 10, 2014 at 12:04:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> 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
On Wed, Sep 10, 2014 at 12:03:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> 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 c
On Wed, 10 Sep 2014 14:10:01 +0530
"Sharma, Shashank" 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
> > wrote:
> >
> >> From: Shashank Sh
On Wed, 10 Sep 2014 14:25:00 +0530
"Sharma, Shashank" 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 wrote:
> > On Tue,
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 othe
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 su
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 wrote:
> >
> > >
> > > On Monday 08 September 2014 08:10 PM, Daniel Vetter wrote:
> > > > On Mon, Sep 08, 2014 at 05:
On Wed, Sep 10, 2014 at 5:29 PM, Daniel Vetter wrote:
> On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
> 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 review
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
Date: We
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 names.
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
---
drivers/gpu/drm/i915/i915_drv.c | 98 +++
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
---
drivers/gpu/dr
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
---
drivers/gpu/drm/i915/i915_dma.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c | 11 +++
drivers/gpu/drm/i915/i915_drv.h |
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
---
drivers/gpu/drm/i915/
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 time,
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 re
On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
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 haven't been adressed.
This is needed by an upcoming patch fixing the switcheroo/legacy suspend
paths.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv
Signed-off-by: Imre Deak
---
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
+++ b/drivers/gpu/drm/i91
This will hopefully make it easier to navigate the code without the need
to consult the full PM documentation.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i9
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
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed
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
---
drivers/gpu/drm/i915/i915_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 dele
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 state
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
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 we
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 diffe
From: Gustavo Padovan
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 argument name
Signed-off-by: Gus
From: Gustavo Padovan
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 the
check() stage)
v2: take Vi
From: Gustavo Padovan
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 old_obj != obj to an upper if conditi
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
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 patches
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.
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ä
> >
> > 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.
>
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-xo
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-v
On Wed, 10 Sep 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu
Damien Lespiau writes:
> From: Zhe Wang
>
> Implement common forcewake functions shared by Gen9 features.
>
> Signed-off-by: Zhe Wang
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +-
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/in
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 tags/drm-intel-f
From: Ville Syrjälä
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
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 --
drivers/gpu/drm/i915/intel_dp.c | 16 +
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
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 an
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 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.
On Wed, Sep 10, 2014 at 2:05 PM, Sharma, Shashank
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
> created in intel_modes.c.
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
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 anywhe
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.
Signed-off-
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 Haswel
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
This patch does following things:
1. Adds new function to attach c
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 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
Color manager is a framework which adds drm properties for
color correct
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 the
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
Color manager is an extentio
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
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 bi
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
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 the
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
wrote:
From: Shashank Sharma
This patch adds support for CSC correction color property.
It does the following:
1. Creates a new DRM pr
On Tue, Sep 09, 2014 at 05:49:46PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Optimize code avoiding helding dev mutex if old fb and current fb
> are the same.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
> 1 file c
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
wrote:
From: Shashank Sharma
Color manager is a framework which adds drm properties for
color correction in I915 d
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
---
drive
On Tue, Sep 09, 2014 at 02:25:50PM -0700, Jesse Barnes wrote:
> On Tue, 09 Sep 2014 21:45:08 +0530
> Deepak S 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 05:02:43PM
90 matches
Mail list logo
