On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote:
> Since we're not synchronizing the ring request list during error state capture
> the request list state might change between the time the corresponding error
> request list was allocated and dimensioned to the time when the ring request
On Thu, Oct 08, 2015 at 03:28:25PM -0700, Matt Roper wrote:
> It's been reported that the atomic watermark series triggers some
> regressions on SKL, which we haven't been able to track down yet. Let's
> temporarily revert these patches while we track down the root cause.
>
> This commit
On Fri, Oct 09, 2015 at 09:58:51AM +0200, Daniel Vetter wrote:
> > > +static bool i915_gem_request_retireable(struct drm_i915_gem_request *req)
> > > +{
> > > + return (i915_gem_request_completed(req, true) &&
> > > + (!req->elsp_submitted || req->ctx_complete));
> >
> > I disagree with
On Fri, Oct 09, 2015 at 10:32:11AM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote:
> > In the past vmas have sometimes turned out to be NULL when capturing buffer
> > objects during error state capture. To avoid NULL pointer exceptions throw a
> > WARNING
On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
> > The concern is that this isn't how SIG_SEGV works, it's a signal the
> > thread who made the
On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote:
> My idea was to create a new request for 3. which gets signalled by the
> scheduler in intel_lrc_irq_handler. My idea was that we'd only create
> these when a ctx switch might occur to avoid overhead, but I guess if we
> just outright
On 08/10/15 10:46, Chris Wilson wrote:
On Thu, Oct 08, 2015 at 10:32:39AM +0100, Tvrtko Ursulin wrote:
On 07/10/15 17:19, Chris Wilson wrote:
On Wed, Oct 07, 2015 at 04:57:25PM +0100, Tvrtko Ursulin wrote:
Hi,
On 06/10/15 11:39, Chris Wilson wrote:
Since the remove of the pin-ioctl, we
On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote:
> Using safe list iterators alleviates the problem of unsynchronized driver list
> manipulations while error state capture is in the process of traversing lists.
>
> Signed-off-by: Tomas Elf
> ---
>
On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
> The concern is that this isn't how SIG_SEGV works, it's a signal the
> thread who made the invalid access gets directly. You never get a SIG_SEGV
> for bad access
On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote:
> On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
> >
> > Hm if this still works the same way as on older platforms then pagefaults
> > just read all 0 and writes go nowhere from the gpu. That generally also
> > explains
On Fri, Oct 09, 2015 at 10:55:26AM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
> > On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
> > > On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
> > > The concern is that this
On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote:
> In the past vmas have sometimes turned out to be NULL when capturing buffer
> objects during error state capture. To avoid NULL pointer exceptions throw a
> WARNING and exit early and be prepared for the error state not being fully
>
On Fri, Oct 09, 2015 at 08:46:31AM +0100, Chris Wilson wrote:
> On Thu, Oct 08, 2015 at 07:31:40PM +0100, Tomas Elf wrote:
> > Avoid NULL pointer exceptions in the display driver for certain critical
> > cases
> > when unpin_work has turned out to be NULL.
>
> Nope, the machine reached a point
On Fri, Oct 09, 2015 at 10:38:18AM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote:
> > Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
> > concurrency problems between the context event interrupt handler and the
> > reset
> >
On 09/10/15 09:55, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
The concern is that this isn't how SIG_SEGV works, it's a signal
On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote:
> Sometimes the iterated vma objects are NULL apparently. Be aware of this while
> iterating and do early exit instead of causing a NULL pointer exception.
>
> Signed-off-by: Tomas Elf
> ---
>
On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote:
> Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
> concurrency problems between the context event interrupt handler and the reset
> path immediately following a GPU reset.
>
> Signed-off-by: Tomas Elf
On 08/10/15 09:55, Tvrtko Ursulin wrote:
On 07/10/15 22:07, Vivek Kasireddy wrote:
Hi Tvrtko,
On Wed, 7 Oct 2015 15:07:30 +0100
Tvrtko Ursulin wrote:
Hi,
On 07/10/15 03:35, Vivek Kasireddy wrote:
This new subtest will validate a Y-tiled object's tiling
On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote:
> > On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
> > >
> > > Hm if this still works the same way as on older platforms then pagefaults
> > > just read all 0 and
On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and
On Fri, Oct 09, 2015 at 09:36:58AM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 09:58:51AM +0200, Daniel Vetter wrote:
> > > > +static bool i915_gem_request_retireable(struct drm_i915_gem_request
> > > > *req)
> > > > +{
> > > > + return (i915_gem_request_completed(req, true) &&
> >
On Tue, Sep 08, 2015 at 01:56:25PM +0200, Daniel Vetter wrote:
> With kms all the data getparam looks at is actually invariant, and
> certainly not protected by the global kms mutex. With ums all the
> setup code is already racy as hell, so this won't make things any
> worse.
Correct.
> I've
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
[snip]
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index d5315b2..74f8fc3 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> Function intel_attach_color_properties_to_crtc attaches a
> color property to its CRTC object. This patch calls this
> function from crtc initialization sequence.
>
> Signed-off-by: Shashank Sharma
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
> that needs to be programmed into respective CSC registers.
>
> This patch does the following:
> 1. Adds the core function to program
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> BDW/SKL/BXT supports Degamma color correction feature, which
> linearizes the non-linearity due to gamma encoded color values.
> This will be applied before Color Transformation.
>
> This patch does the
Hi Rafael,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
ignore]
config: mn10300-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod
Hi Tvrtko,
On Fri, 9 Oct 2015 09:34:25 +0100
Tvrtko Ursulin wrote:
>
>
> On 08/10/15 09:55, Tvrtko Ursulin wrote:
> > On 07/10/15 22:07, Vivek Kasireddy wrote:
> >>
> >> Hi Tvrtko,
> >>
> >> On Wed, 7 Oct 2015 15:07:30 +0100
> >> Tvrtko Ursulin
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> The color correction blob values are loaded during set_property
> calls. This patch adds a function to find the blob and apply the
> correction values to the display registers, during the atomic
> commit
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
> that needs to be programmed into CGM (Color Gamut Mapping) registers.
>
> This patch does the following:
> 1. Attaches CSC property to CRTC
> 2. Adds
Em Qui, 2015-10-08 às 15:28 -0700, Matt Roper escreveu:
> It's been reported that the atomic watermark series triggers some
> regressions on SKL, which we haven't been able to track down yet.
> Let's
> temporarily revert these patches while we track down the root cause.
>
> This commit squashes
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
> This patch adds new variables in CRTC state, to hold respective color
> correction blobs. These blobs will be required during the atomic commit
> for writing the color correction values in correction
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
> As per DRM color manager design, if a userspace wants to set a correction
> blob, it prepares it and sends the blob_id to kernel via set_property
> call. DRM framework takes this blob_id, gets the blob,
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> CHV/BSW supports Degamma color correction, which linearizes all
> the non-linear color values. This will be applied before Color
> Transformation.
>
> This patch does the following:
> 1. Attach deGamma
On Thu, Oct 08, 2015 at 07:31:40PM +0100, Tomas Elf wrote:
> Avoid NULL pointer exceptions in the display driver for certain critical cases
> when unpin_work has turned out to be NULL.
Nope, the machine reached a point where it cannot possibly reach, we
want the OOPS.
-Chris
--
Chris Wilson,
On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote:
> Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
> concurrency problems between the context event interrupt handler and the reset
> path immediately following a GPU reset.
Hmm, my tree just does:
static void
On Thu, Oct 08, 2015 at 12:08:20PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There isn't an explicit stolen memory base register on gen2.
> Some old comment in the i915 code suggests we should get it via
> max_low_pfn_mapped, but that's
Hi,
This started somewhere between Kernel 4.2 and 4.3-rc1,
but I only noticed it a day ago.
The first S3 suspend after a fresh boot works fine.
Thereafter, suspends simply resume again immediately.
I get the following errors on my console:
[ 152.697247] i915 :00:02.0: GEM idle failed,
Another regression for Jairo to track.
-Daniel
On Thu, Oct 08, 2015 at 11:43:39PM -0700, Doug Smythies wrote:
>
> Hi,
>
> This started somewhere between Kernel 4.2 and 4.3-rc1,
> but I only noticed it a day ago.
>
> The first S3 suspend after a fresh boot works fine.
> Thereafter, suspends
On Thu, 2015-10-08 at 16:57 +0100, Chris Wilson wrote:
> Correct me if I am wrong, but it looks like i915_svm implements the
> lowlevel interface with the hardware, so by convention is intel_svm.c
I think the plan is to drop the driver-mode interface altogether and
use the OS-mode version that I
On Thu, Oct 08, 2015 at 01:19:27PM -0700, Jesse Barnes wrote:
> On 09/23/2015 08:52 AM, Paulo Zanoni wrote:
> > Technology has evolved and now we have eDP panels with 3200x1800
> > resolution. In the meantime, the BIOS guys didn't change the default
> > 32mb for stolen memory. On top of that, we
On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote:
> Sometimes the iterated vma objects are NULL apparently. Be aware of this while
> iterating and do early exit instead of causing a NULL pointer exception.
Wrong.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote:
> Since we're not synchronizing the ring request list during error state capture
> the request list state might change between the time the corresponding error
> request list was allocated and dimensioned to the time when the ring request
On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote:
> Using safe list iterators alleviates the problem of unsynchronized driver list
> manipulations while error state capture is in the process of traversing lists.
Wrong, this does not make anything safe.
-Chris
--
Chris Wilson, Intel
On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote:
> In the past vmas have sometimes turned out to be NULL when capturing buffer
> objects during error state capture. To avoid NULL pointer exceptions throw a
> WARNING and exit early and be prepared for the error state not being fully
>
On Thu, Oct 08, 2015 at 04:08:52PM +0100, Chris Wilson wrote:
> On Thu, Oct 08, 2015 at 03:31:08PM +0100, Tvrtko Ursulin wrote:
> >
> > On 08/10/15 12:09, Chris Wilson wrote:
> > >On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote:
> > >>>-struct drm_i915_gem_object *
> >
On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
>
> On 28/09/15 15:14, Daniel Vetter wrote:
> >On Mon, Sep 28, 2015 at 02:52:30PM +0100, Chris Wilson wrote:
> >>On Mon, Sep 28, 2015 at 03:42:22PM +0200, Daniel Vetter wrote:
> >>>On Wed, Sep 23, 2015 at 09:07:24PM +0100, Chris
On Thu, Oct 08, 2015 at 01:32:07PM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 03:52:01PM +0100, Nick Hoath wrote:
> > There is a desire to simplify the i915 driver by reducing the number of
> > different code paths introduced by the LRC / execlists support. As the
> > execlists request
On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
>
> Hm if this still works the same way as on older platforms then pagefaults
> just read all 0 and writes go nowhere from the gpu. That generally also
> explains ever-increasing numbers of the CS execution pointer since it's
> busy churning
On Thu, Oct 08, 2015 at 11:46:08PM +0100, David Woodhouse wrote:
> On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote:
> >
> > Could someone clarify what this means from the TDR point of view,
> > please? When you say "context blew up" I'm guessing that you mean that
> > come context caused the
On Thu, Oct 01, 2015 at 07:57:12PM -0300, Paulo Zanoni wrote:
> According to my experiments (and later confirmation from the hardware
> developers), the maximum sizes mentioned in the specification delimit
> how far in the buffer the hardware tracking can go. And the hardware
> calculates the size
On Thu, Oct 08, 2015 at 07:31:38PM +0100, Tomas Elf wrote:
> Error state capture is dependent on i915_gem_active_request() and
> i915_gem_obj_is_pinned(). Since there is no synchronization between error
> state
> capture and the driver state we at least need to use safe list iterators in
> these
On Fri, Oct 09, 2015 at 09:28:37AM +0200, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 11:46:08PM +0100, David Woodhouse wrote:
> > On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote:
> > >
> > > Could someone clarify what this means from the TDR point of view,
> > > please? When you say
On Thu, Oct 08, 2015 at 04:12:31PM +0100, Michel Thierry wrote:
> On 10/8/2015 3:37 PM, Tvrtko Ursulin wrote:
> >From: Tvrtko Ursulin
> >
> >commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
> >Author: Tvrtko Ursulin
> >Date: Mon Oct 5 13:26:36
On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote:
> >From: Chris Wilson
> >
> >If we run out of stolen memory when trying to allocate an object, see if
> >we can reap enough purgeable objects to free up enough
Hi Shashank,
[auto build test WARNING on next-20151009 -- if it's inappropriate base, please
ignore]
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for
parameter 'wedged'
drivers/gpu/dr
On Tue, Sep 29, 2015 at 06:25:44PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2015 at 05:27:33PM +0200, Lukas Wunner wrote:
> > Hi Daniel,
> >
> > On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > > > On Mon,
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
[snip]
> +
> +/* Color management bit utilities */
> +#define GET_BIT_MASK(n) ((1 << n) - 1)
> +
> +/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
> +#define GET_BITS(x, start, nbits)
Hi Shashank,
[auto build test WARNING on next-20151009 -- if it's inappropriate base, please
ignore]
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for
parameter 'wedged'
drivers/gpu/dr
This series implement support to a drm_dp_aux chardev that allows reading and
writing an arbitrary amount of bytes to arbitrary dpcd register addresses using
regular read, write and lseek operations.
v2:
- lseek is used to select the register to read/write
- read/write are used instead of ioctl
So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the
This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the
The memremap() api [1] was merged in 4.3 [2] with an initial
implementation for x86 and a conversion of the pmem driver. Complete the
conversion for the rest of the kernel.
Feel free to either ack or directly apply a conversion-patch as I will
defer the final removal patches until all the
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> From DRM color management:
>
> DRM color manager supports these color properties:
> 1. "ctm": Color transformation matrix property, where a
>color transformation matrix
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie
This is a squash of the following commits:
Revert "drm/i915: Drop intel_update_sprite_watermarks"
This reverts commit 47c99438b52d12df50e182583634a4cfede3c920.
Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check"
This reverts commit
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> CHV/BSW platform supports two different pipe level gamma
> correction modes, which are:
> 1. Legacy 8-bit mode
> 2. 10-bit CGM (Color Gamut Mapping) mode
>
> This patch does the following:
> 1. Attaches
Thanks for the review comments, Emil.
Regards
Shashank
On 10/10/2015 3:53 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs
Regards
Shashank
On 10/10/2015 3:51 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation
Regards
Shashank
On 10/10/2015 4:41 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Regards
Shashank
On 10/10/2015 5:13 AM, Emil Velikov wrote:
On 9 October 2015 at 20:29, Shashank Sharma wrote:
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the
Regards
Shashank
On 10/10/2015 5:09 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index d5315b2..74f8fc3 100644
Regards
Shashank
On 10/10/2015 4:54 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction
Regards
Shashank
On 10/10/2015 5:15 AM, Emil Velikov wrote:
On 9 October 2015 at 20:29, Shashank Sharma wrote:
Function intel_attach_color_properties_to_crtc attaches a
color property to its CRTC object. This patch calls this
function from crtc initialization
Regards
Shashank
On 10/10/2015 5:24 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch
Regards
Shashank
On 10/10/2015 3:55 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via
Regards
Shashank
On 10/10/2015 4:17 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
[snip]
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb)
Regards
Shashank
On 10/10/2015 4:37 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut
Regards
Shashank
On 10/10/2015 5:19 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be
On 10/09/2015 06:29 AM, David Woodhouse wrote:
> On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
>>
>> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request {
>> /** Execlists no. of times this request has been sent to the ELSP */
>> int elsp_submitted;
>>
>> + /* core
From: Ville Syrjälä
Cairo helpfully allocates a new buffer for us when
cairo_image_surface_create_for_data() is called with a NULL ptr. That
means if gem_mmap__gtt() fails, we get a totally silent failure and
nothing ever drawn into the framebuffer. Very confusing.
From: Ville Syrjälä
Get rid of the gem_mmap() alias of gem_mmap__gtt(). I don't see any
point in having it.
Signed-off-by: Ville Syrjälä
---
demos/intel_sprite_on.c| 4 ++--
lib/igt_fb.c | 2 +-
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
lib/ioctl_wrappers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 80e1ec6..eb745bc 100644
---
From: Ville Syrjälä
Rename the current gem_mmap__{cpu,gtt,wc}() functions into
__gem_mmap__{cpu,gtt,wc}(), and add back wrappers with the original name
that assert that the pointer is valid. Most callers will expect a valid
pointer and shouldn't have to bother with
On 10/09/2015 02:07 AM, David Woodhouse wrote:
> On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote:
>> On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote:
>>> On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
Hm if this still works the same way as on older
From: Ville Syrjälä
gem_mmap__{cpu,gtt,wc}() already has the assert built in, so replace
__gem_mmap__{cpu,gtt,wc}() + igt_assert() with it.
Mostly done with coccinelle, with some manual help:
@@
identifier I;
expression E1, E2, E3, E4, E5, E6;
@@
(
- I =
From: Ville Syrjälä
Do the following
ptr = gem_mmap__{cpu,gtt,wc}()
+igt_assert(ptr);
whenever the code doesn't handle the NULL ptr in any kind of
specific way.
Makes it easier to move the assert into gem_mmap__{cpu,gtt,wc}() itself.
Mostly done with
From: Ville Syrjälä
gem_mmap__{cpu,gtt,wc} never return MAP_FAILED, it gets converted to
NULL internally. So don't go asserting that the returned value is
not MAP_FAILED.
Done with coccinelle:
@@
type T;
identifier I;
@@
(
I = gem_mmap__gtt(...);
|
I =
On 09/10/2015 08:49, Chris Wilson wrote:
On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote:
Using safe list iterators alleviates the problem of unsynchronized driver list
manipulations while error state capture is in the process of traversing lists.
Wrong, this does not make anything
On 09/10/2015 09:39, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 08:46:31AM +0100, Chris Wilson wrote:
On Thu, Oct 08, 2015 at 07:31:40PM +0100, Tomas Elf wrote:
Avoid NULL pointer exceptions in the display driver for certain critical cases
when unpin_work has turned out to be NULL.
Nope,
On Fri, 09 Oct 2015, Chris Wilson wrote:
> On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
>> From: Chris Wilson
>>
>> A long time ago (before 3.14) we relied on a permanent pinning of the
>> ifbdev to lock the fb in place inside
On 09/10/15 12:51, Chris Wilson wrote:
If the impossible happens and we fail to rebind a VMA in the middle of
rebinding all VMA for an object we currently bail out and leave the
object in an inconsistent state. Attempt to unwind the incomplete update
by reverting all updated VMA back to the
On 09/10/15 13:19, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote:
On 09/10/15 12:51, Chris Wilson wrote:
If the impossible happens and we fail to rebind a VMA in the middle of
rebinding all VMA for an object we currently bail out and leave the
object in
On Thu, 08 Oct 2015, Daniel Vetter wrote:
> On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote:
>> On Thu, 2015-10-08 at 11:43 +0300, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > EDID detailed timings have a
On 09/10/2015 08:48, Chris Wilson wrote:
On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote:
Sometimes the iterated vma objects are NULL apparently. Be aware of this while
iterating and do early exit instead of causing a NULL pointer exception.
Wrong.
-Chris
So the NULL pointer
On 09/10/2015 08:49, Chris Wilson wrote:
On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote:
In the past vmas have sometimes turned out to be NULL when capturing buffer
objects during error state capture. To avoid NULL pointer exceptions throw a
WARNING and exit early and be prepared for
On 09/10/2015 09:28, Daniel Vetter wrote:
On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote:
Since we're not synchronizing the ring request list during error state capture
the request list state might change between the time the corresponding error
request list was allocated and
On 09/10/2015 09:32, Daniel Vetter wrote:
On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote:
In the past vmas have sometimes turned out to be NULL when capturing buffer
objects during error state capture. To avoid NULL pointer exceptions throw a
WARNING and exit early and be prepared
On 09/10/2015 11:38, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 11:27:48AM +0100, Tomas Elf wrote:
On 09/10/2015 08:41, Chris Wilson wrote:
On Thu, Oct 08, 2015 at 07:31:38PM +0100, Tomas Elf wrote:
Error state capture is dependent on i915_gem_active_request() and
i915_gem_obj_is_pinned().
On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote:
>
> On 09/10/15 12:51, Chris Wilson wrote:
> >If the impossible happens and we fail to rebind a VMA in the middle of
> >rebinding all VMA for an object we currently bail out and leave the
> >object in an inconsistent state. Attempt
1 - 100 of 161 matches
Mail list logo