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 does the following:
1. Adds th
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 applied before Color Transforma
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 sequence.
Signed-off-by: Shashank
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 following:
1. Attaches CSC
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
--- a/drivers/gpu/drm/i915/int
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 values to the display registe
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
Transformation.
This patch does the follo
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 Mapping) mode
This patch does the
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 matrix property, where a
c
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) till 'n' bits */
+#define GET_
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 set_property
call. DRM framework takes
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 will be required during the ato
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 wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> On 07/10
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 +x
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 CSC correction values for
>
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 following:
> 1. Adds the cor
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
> Signed-off-by: Kausal Malladi
Maybe squash
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 the core function to program
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
> +++ b/drivers/gpu/drm/i915/intel_co
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 call.
>
> Signed-off-by: Sh
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 property to CRTC
> 2. Add the
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 Gamma property to CRTC
> 3.
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) ((x >> start) & GET_BIT_MASK(n
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, and saves it
> in the CRTC s
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 registers.
>
> Signed-off-by: S
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
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan
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 of 9 correction values gets
>
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 conversi
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, S
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 dr
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 connector
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 7809e5ae35b9d8d0710f0874b2e3f10be144e3
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'
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,
[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'
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'
On 10/09/2015 08:53 PM, jairo.daniel.miramontes.ca...@linux.intel.com wrote:
> This week's existing bugzilla regressions, added a bisected column which
> means if the Bug
> does have a bisect available.
>
>
> BugIdSummary Created on
>
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'
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 CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by:
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.
This patch adds the no of coefficients(65) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.
Signed-off-by: Shashank Sharma
Sig
I915 color manager registers pipe gamma correction as palette
correction after CTM property.
For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info
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 call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel
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 following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit Split Gamma mode
3. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines
S
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 the core function to program CSC correction values
3. Adds CSC correction macros
Signed-of
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coeffi
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
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_
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 Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macr
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_before_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coeff
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 property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2.
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h
The per color property patches coming up in this patch series
will fill the appropriate functions in this file.
Signed-off-by: Shashank Sharma
From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
2. "palette_before_ctm": for corrections which get
This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i
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 registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_ato
Color Management is an extension to DRM framework. It allows
abstraction of hardware color correction and enhancement capabilities
by virtue of DRM properties.
There are two major types of color correction supported by DRM
color manager:
- CTM: color transformation matrix, properties where a corre
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 26 +++
Color Manager framework defines a DRM property for color
space transformation and Gamut mapping. This property is called
CTM (Color Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for co
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, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from
This patch set adds Color Manager implementation in DRM layer. Color Manager
is an extension in DRM framework to support color correction/enhancement.
Various Hardware platforms can support several color correction capabilities.
Color Manager provides abstraction of these capabilities and allows a
As per the DRM get_property implementation for a blob, framework
is supposed to return the blob_id to the caller. All the color
management blobs are saved in CRTC state during the set call.
This patch adds get_property support for color management
properties, by referring to the existing blob for
DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.
Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after
This week's existing bugzilla regressions, added a bisected column which means
if the Bug
does have a bisect available.
BugIdSummary Created on
Bisected
<>
92237Horrible noise (audio) via DisplayPort [regre10/2/
On 09/10/15 18:26, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
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
On Fri, Oct 09, 2015 at 07:33:23PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> > The error state is purposefully racy as we expect it to be called at any
> > time and so have avoided any locking whilst capturing the crash dump.
> > However, with mul
On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> The error state is purposefully racy as we expect it to be called at any
> time and so have avoided any locking whilst capturing the crash dump.
> However, with multi-engine GPUs and multiple CPUs, those races can
> manifest into OOPSe
On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
> >
> > 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
On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> > 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
On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> 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 sw
On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
>
> 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 Ursu
On Fri, Oct 09, 2015 at 07:19:16PM +0300, ville.syrj...@linux.intel.com wrote:
> 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:
> @@
> ident
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 = __gem_mmap__gtt(E1, E2, E3, E4);
+ I =
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 failures.
To avoid changing an
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 platform
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 +-
lib/ioctl_wrappers.h | 16
tests
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
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -456,7 +456,7 @@
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 coccinelle, with some manual cleanups:
@@
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 = gem_mmap__cpu(...);
|
I = gem_mmap__wc(.
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.
Put in an igt_assert() to make
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 f
On 08/10/15 11:22, Tvrtko Ursulin wrote:
Hi,
On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user w
On 09/10/15 15:04, Joonas Lahtinen wrote:
Currently the shell scripts (+ a couple of 'execl') in intel-gpu-tools
are are using a mix of #!/bin/bash (13) or #!/bin/sh shebangs (6). Also
5 of the #!/bin/bash scripts do source a #!/bin/sh script.
I think we should have it unified, either drop Bash
Hi Joonas,
On android /bin does not exist. It is /system/bin/sh (there is no
/system/bin/bash) so the script needs to be executed specifying the shell to
override the shebang anyway. e.g. '/system/bin/sh script.sh'
Currently the script type tests are not run on android as the build system does
Currently the shell scripts (+ a couple of 'execl') in intel-gpu-tools
are are using a mix of #!/bin/bash (13) or #!/bin/sh shebangs (6). Also
5 of the #!/bin/bash scripts do source a #!/bin/sh script.
I think we should have it unified, either drop Bash dependency
completely or convert all scripts
After discussions with Art, Ville and others internally on how DC5/6
should normally work and existing open issues related to the HW
automatic DC5/6 functionality, I have the following understanding.
In the future we will require the firmware for any display side runtime
power management (and poss
On 09/10/15 14:11, Chris Wilson wrote:
Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_display. By knowing that only objects pinned to the hardware
will have an elevated vma->pin_count, so we can coalle
Hi Chris,
[auto build test WARNING on next-20151009 -- if it's inappropriate base, please
ignore]
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
include/drm/drm_crtc.h:1162: warning: No description found for parameter
'dirty_info_property'
includ
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 fence obj for this request, may be exported */
> +
Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_display. By knowing that only objects pinned to the hardware
will have an elevated vma->pin_count, so we can coallesce many of the
linear walks over the obj-
On Fri, Oct 09, 2015 at 01:37:19PM +0100, Tvrtko Ursulin wrote:
>
> 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
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 an
The error state is purposefully racy as we expect it to be called at any
time and so have avoided any locking whilst capturing the crash dump.
However, with multi-engine GPUs and multiple CPUs, those races can
manifest into OOPSes as we attempt to chase dangling pointers freed on
other CPUs. Under
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 to
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 to
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 orig
On 09/10/2015 11:44, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 11:30:34AM +0100, Tomas Elf wrote:
On 09/10/2015 08:46, 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
On 09/10/15 11:34, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 11:17:19AM +0100, Tvrtko Ursulin wrote:
- list_for_each_entry(vma, &obj->vma_list, vma_link)
- if (drm_mm_node_allocated(&vma->node)) {
- ret = i915_vma_bind(vma, cac
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(). Si
On Fri, Oct 09, 2015 at 12:30:29PM +0100, Tomas Elf wrote:
> 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 caus
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 the GGTT. However, the
>> introduction of stealing th
1 - 100 of 162 matches
Mail list logo
