Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote: > Damien - did you ever test these mandatory modes on an actual > commercial 3D TV or similar device? My main testing device was a Samsung TV with this 3D_present bit set and all the advertised modes were working. Can't quite remember

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 01:48:04PM -0500, Ilia Mirkin wrote: > After some more conversations with Alastair, it sounds like what's > actually going on is that it's just the frame-packing modes that > aren't working, but all the side-by-side and top-and-bottom modes from > the "mandatory" list work.

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote: > On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote: > > Damien - did you ever test these mandatory modes on an actual > > commercial 3D TV or similar device? > > My main testing device was a Samsung TV

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 12:10:56AM -0500, Ilia Mirkin wrote: > On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater > wrote: > > HDMI specification 1.4a, table 8-15 is very explicitly a "must > > support at least one of" table, not a "must support all of" table. >

[Intel-gfx] [PATCH libdrm] xf86drm: Bound strstr() to the allocated data

On Fri, Jan 22, 2016 at 04:48:05PM +0200, Ville Syrjälä wrote: > On Fri, Jan 22, 2016 at 12:51:23PM +0000, Damien Lespiau wrote: > > We are reading at most sizeof(data) bytes, but then data may not contain > > a terminating '\0', at least in theory, so strstr() may overflo

[PATCH libdrm] xf86drm: Bound strstr() to the allocated data

We are reading at most sizeof(data) bytes, but then data may not contain a terminating '\0', at least in theory, so strstr() may overflow the stack allocated array. Make sure that data always contains at least one '\0'. Signed-off-by: Damien Lespiau --- xf86drm.c | 3 ++- 1 file changed, 2

[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities

On Fri, Jul 03, 2015 at 08:41:31AM +0200, Daniel Vetter wrote: > > Yeah. My first idea for the gamma stuff was that we'd simply have the > > blob property for the data, and then a separate enum property which > > decides how we interpret the blob contents. The default for the enum > > would be the

[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities

On Thu, Jul 02, 2015 at 05:20:45PM +0100, Damien Lespiau wrote: > On Wed, Jul 01, 2015 at 09:18:14PM +0530, Kausal Malladi wrote: > > From: Kausal Malladi > > > > The DRM color management framework is targeting various hardware > > platforms and drivers. Different p

[PATCH 03/12] drm/i915: Attach color properties to CRTC

On Wed, Jul 01, 2015 at 09:18:13PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch does the following: > 1. Adds new files intel_color_manager(.c/.h) > 2. Attaches color properties to CRTC while initialization We usually order the series so that "it always works". In this

[PATCH 08/12] drm: Export drm_property_replace_global_blob function

On Wed, Jul 01, 2015 at 09:18:18PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > drm_property_replace_global_blob() is getting used by many wrapper > functions to replace an existing blob with new values. Because this > function was static, modules are forced to create wrapper

[PATCH 07/12] drm: Add structures to set/get a palette color property

On Wed, Jul 01, 2015 at 09:18:17PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > 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. >

[PATCH 03/12] drm/i915: Attach color properties to CRTC

On Wed, Jul 01, 2015 at 09:18:13PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch does the following: > 1. Adds new files intel_color_manager(.c/.h) > 2. Attaches color properties to CRTC while initialization A small note that we could remove manager from the whole API name,

[PATCH 04/12] drm: Add structures for querying color capabilities

On Wed, Jul 01, 2015 at 09:18:14PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > The DRM color management framework is targeting various hardware > platforms and drivers. Different platforms can have different color > correction and enhancement capabilities. > > A commom user space

[PATCH 09/12] drm/i915: Add pipe level Gamma correction for CHV/BSW

On Wed, Jul 01, 2015 at 09:18:19PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > CHV/BSW platform supports various Gamma correction modes, which are: > 1. Legacy 8-bit mode > 2. 10-bit CGM (Color Gamut Mapping) mode > > This patch does the following: > 1. Adds the core function to

[PATCH v2 08/10] drm: Add CSC correction structure

On Thu, Jun 04, 2015 at 07:12:39PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch adds a new structure in DRM layer for CSC color correction. > This structure will be used by all user space agents to configure > appropriate CSC format and CSC level. And another little one:

[PATCH v2 01/10] drm/i915: Initialize Color Manager

On Tue, Jun 09, 2015 at 11:34:44AM +0100, Damien Lespiau wrote: > "CSC" is quite specific to how Intel calls the unit doing the 3x3 matrix > transform on colors, maybe we could be more generic there? > "color-matrix"? This also depends if we want to try to create

[PATCH v2 07/10] drm/i915: Add pipe level Gamma correction for CHV/BSW

On Thu, Jun 04, 2015 at 07:12:38PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch does the following: > 1. Adds the core function to program Gamma correction values for CHV/BSW >platform A couple of things I forgot (they are probably others): - This patch doesn't

[PATCH v2 00/10] Color Manager Implementation

On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch set adds color manager implementation in drm/i915 layer. > Color Manager is an extension in i915 driver to support color > correction/enhancement. Various Intel platforms support several >

[PATCH v2 10/10] drm/i915: Add CSC support for CHV/BSW

On Thu, Jun 04, 2015 at 07:12:41PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch does the following: > 1. Adds the core function to program CSC correction values for >CHV/BSW platform > 2. Adds CSC correction macros/defines > 3. Adds a pointer to hold blob for CSC

[PATCH v2 08/10] drm: Add CSC correction structure

On Thu, Jun 04, 2015 at 07:12:39PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch adds a new structure in DRM layer for CSC color correction. > This structure will be used by all user space agents to configure > appropriate CSC format and CSC level. > > /* Color Management

[PATCH v2 07/10] drm/i915: Add pipe level Gamma correction for CHV/BSW

(Note I haven't actually looked at the CHV specific details just yet, that'll be for another pass). On Thu, Jun 04, 2015 at 07:12:38PM +0530, Kausal Malladi wrote: > +int chv_set_gamma(struct drm_device *dev, uint32_t blob_id, > + struct drm_crtc *crtc) > +{ > + struct drm_gamma

[PATCH v2 07/10] drm/i915: Add pipe level Gamma correction for CHV/BSW

On Sat, Jun 06, 2015 at 05:39:23PM +0530, Sharma, Shashank wrote: > >>+if (gamma_data->gamma_precision == I915_GAMMA_PRECISION_UNKNOWN) { > >Switch/case instead? > Yep, got it. > > > >Also, is UNKNOWN for disabling? Why not rename it to DISABLE then? > Actually unknown is valid in case of

[PATCH v2 04/10] drm: Add Gamma correction structure

On Thu, Jun 04, 2015 at 07:12:35PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch adds a new structure in DRM layer for Gamma color correction. > This structure will be used by all user space agents to configure > appropriate Gamma precision and Gamma level. > > struct

[PATCH v2 02/10] drm/i915: Attach color properties to CRTC

On Thu, Jun 04, 2015 at 07:12:33PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > Every CRTC would be carrying its own instances of CSC and Gamma color > correction values. This patch adds a new function to attach color > properties to respective CRTCs while initialization. > >

[PATCH v2 01/10] drm/i915: Initialize Color Manager

On Thu, Jun 04, 2015 at 07:12:32PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > Color Manager is an extension in i915 driver to handle color correction > and enhancements across various Intel platforms. > > This patch initializes color manager framework by : > 1. Adding two new

[PATCH v2 00/10] Color Manager Implementation

On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch set adds color manager implementation in drm/i915 layer. > Color Manager is an extension in i915 driver to support color > correction/enhancement. Various Intel platforms support several >

[PATCH 0/7] Color Manager Implementation

On Tue, Jun 02, 2015 at 01:22:42AM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch set adds color manager implementation in drm/i915 layer. Is anyone working on tests/test plan? Thanks, -- Damien

[Intel-gfx] drivers/gpu/drm/i915/i915_gem_gtt.c

On Fri, May 22, 2015 at 02:17:32PM -0700, Andrew Morton wrote: > I'm not sure what's happened to the drm code in linux-next - it's > exploding all over the place. Did someone turn on -Werror without > doing anywhere near enough testing? > > Anyway, I don't know how to fix this i386 build error:

[PATCH 1/3] RELEASING: Fix releasing instructions to match the latest release.sh

On Thu, Mar 19, 2015 at 05:39:06PM +, Emil Velikov wrote: > On 19/03/15 16:35, Damien Lespiau wrote: > > - Running "make distcheck" should result in no warnings or errors > > - and end with a message of the form: > > + Verify that the code passes &

[PATCH 2/3] RELEASING: Fix the step numbering

On Thu, Mar 19, 2015 at 05:32:28PM +, Emil Velikov wrote: > On 19/03/15 16:35, Damien Lespiau wrote: > > Signed-off-by: Damien Lespiau > > --- > > RELEASING | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/

[PATCH v2] intel: Merge latest i915_drm.h

Roberts Reviewed-by: Damien Lespiau And merged into master. Thanks! -- Damien > --- > > Here is a v2 of the patch just to rebase it on the changes that were > added manually in commit d556e068a7e4e9d. > > include/drm/i915_drm.h | 48 ++

[PATCH 3/3] RELEASING: Fix annouce typo

That's the only type :set spell found. Signed-off-by: Damien Lespiau --- RELEASING | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASING b/RELEASING index 8ed7490..78e90c0 100644 --- a/RELEASING +++ b/RELEASING @@ -51,7 +51,7 @@ Follow these steps to release a new

[PATCH 2/3] RELEASING: Fix the step numbering

Signed-off-by: Damien Lespiau --- RELEASING | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/RELEASING b/RELEASING index e17dbea..8ed7490 100644 --- a/RELEASING +++ b/RELEASING @@ -13,14 +13,14 @@ Follow these steps to release a new version of libdrm

[PATCH 1/3] RELEASING: Fix releasing instructions to match the latest release.sh

, make a note that release.sh will run make distcheck for you, so we don't strickly need to run it beforehand. Signed-off-by: Damien Lespiau --- RELEASING | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/RELEASING b/RELEASING index 3f07146..e17dbea 100644

[PATCH 0/3] A few fixes in the libdrm release documentation

Made a release with those instructions, they turned out to be slightly outdated. Fix it for the next first-time person. -- Damien Damien Lespiau (3): RELEASING: Fix releasing instructions to match the latest release.sh RELEASING: Fix the step numbering RELEASING: Fix annouce typo

[ANNOUNCE] libdrm 2.4.60

Alan Coopersmith (2): Stop undefining _ATOMIC_TYPE in Solaris/NetBSD section of xf86atomic.h On Solaris, #include in xf86drm.c Chih-Wei Huang (1): android: remove duplicate libdrm in LOCAL_SHARED_LIBRARIES Damien Lespiau (1): build: Bump version number to 2.4.60 before

[Intel-gfx] [PATCH 1/2 v2] intel: Export total subslice and EU counts

On Mon, Mar 09, 2015 at 04:13:03PM -0700, jeff.mcgee at intel.com wrote: > From: Jeff McGee > > Update kernel interface with new I915_GETPARAM ioctl entries for > subslice total and EU total. Add a wrapping function for each > parameter. Userspace drivers need these values when constructing >

[PATCH] intel: Export total subslice and EU counts

On Mon, Mar 02, 2015 at 03:39:27PM -0800, jeff.mcgee at intel.com wrote: > From: Jeff McGee 2 small details, but otherwise: Reviewed-by: Damien Lespiau > Update kernel interface with new I915_GETPARAM ioctl entries for > subslice total and EU total. Add a wrapping function

[PATCH libdrm 00/12] Introduce drm_intel_device and use i915_pciid.h

On Fri, Mar 06, 2015 at 02:10:44PM +, Emil Velikov wrote: > On 05/03/15 16:20, Damien Lespiau wrote: > > A couple of things I wanted to do for the longest time: > > > > - Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy > > the

[PATCH 09/12] intel: Provide IS_GENX() macros taking a drm_intel_device as argument

On Thu, Mar 05, 2015 at 10:41:19AM -0800, Ian Romanick wrote: > On 03/05/2015 08:20 AM, Damien Lespiau wrote: > > Time to switch over all the IS_GENX() macros to the new device object. > > Nothing more than a mechanical search & replace here. > > Hmm... why not just do

[PATCH 12/12] intel: Remove intel_chipset.h

Finally, we can remove this file now that everything is using drm_intel_device. Signed-off-by: Damien Lespiau --- intel/Makefile.sources | 1 - intel/intel_bufmgr_gem.c | 1 - intel/intel_chipset.h| 184 --- intel/intel_decode.c | 1

[PATCH 11/12] intel: Make test_decode not depend on intel_chipset.h

We were pulling a few PCI ids, we can just hardcode them, it doesn't change much. Signed-off-by: Damien Lespiau --- intel/test_decode.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/intel/test_decode.c b/intel/test_decode.c index 1ffd829..b9897b3 100644 --- a/intel

[PATCH 10/12] intel: Make test_decode fail gracefully the decode context is NULL

If, for some reason, we couldn't create the decode context, exit, instead of segfaulting. Signed-off-by: Damien Lespiau --- intel/test_decode.c | 5 + 1 file changed, 5 insertions(+) diff --git a/intel/test_decode.c b/intel/test_decode.c index 93f47ef..1ffd829 100644 --- a/intel

[PATCH 09/12] intel: Provide IS_GENX() macros taking a drm_intel_device as argument

Time to switch over all the IS_GENX() macros to the new device object. Nothing more than a mechanical search & replace here. Signed-off-by: Damien Lespiau --- intel/intel_bufmgr_gem.c | 7 +- intel/intel_chipset.h | 158 -- intel/intel_deco

[PATCH 08/12] intel: Remove direct usage of IS_915()

One more step towards getting rid of intel_chipset.h. The slightly tricky bit here is that I don't want to leave defines like IS_CHIP() or IS_GEN4() is a file that can potentially become a public header. intel_device_priv.h was introduced then. Signed-off-by: Damien Lespiau --- intel

[PATCH 07/12] intel: Kill the IS_GEN4() macro

Turns out nobody was using it, nor the underlying defines. Signed-off-by: Damien Lespiau --- intel/intel_chipset.h | 15 --- 1 file changed, 15 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index a8a2b0e..241d700 100644 --- a/intel/intel_chipset.h +++ b

[PATCH 06/12] intel: Kill the IS_9XX() macro

IS_9XX() has grown to mean gen >= 3. It was only used in a single test: (IS_9XX && !IS_GEN3) Which has then be replaced with gen >= 4. The code in that area was idented a bit weirdly, so do a pass on that as well. Signed-off-by: Damien Lespiau --- intel/intel_

[PATCH 05/12] intel: Use '||' for the boolean or

While the bitwise operator should do the right thing here, it's probably better to use the logical or here, at least to not cause a 'wtf' when reading the code. At the same time, get rid of unnecessary '()'. Signed-off-by: Damien Lespiau --- intel/intel_bufmgr_gem.c | 4 ++-- 1 file changed, 2

[PATCH 04/12] intel: Make drm_intel_decode use a drm_intel_device

Signed-off-by: Damien Lespiau --- intel/intel_decode.c | 31 --- 1 file changed, 12 insertions(+), 19 deletions(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c index 7d5cbe5..9ada2fa 100644 --- a/intel/intel_decode.c +++ b/intel/intel_decode.c @@ -35,6

[PATCH 03/12] intel: Use drm_intel_device in the gem buffer manager

Signed-off-by: Damien Lespiau --- intel/intel_bufmgr_gem.c | 58 +++- 1 file changed, 8 insertions(+), 50 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 33d8fbc..72a6ab1 100644 --- a/intel/intel_bufmgr_gem.c +++ b

[PATCH 02/12] intel: Introduce an drm_intel_device object

-by: Damien Lespiau --- intel/Makefile.sources | 3 + intel/i915_pciids.h| 289 +++ intel/intel_device.c | 300 + intel/intel_device.h | 99 4 files changed, 691 insertions

[PATCH 01/12] intel: Remove unused define IS_MOBILE()

Signed-off-by: Damien Lespiau --- intel/intel_chipset.h | 10 -- 1 file changed, 10 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index e22a867..9a8df6a 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -181,16 +181,6 @@ #define

[PATCH libdrm 00/12] Introduce drm_intel_device and use i915_pciid.h

- I ran with this series on a couple of machines with no noticeable problem - I check that the INTEL_DEVID_OVERRIDE env variable was still working (to dump AUB files) - make check, which exercises changes in the decoder path, still passes -- Damien Damien Lespiau (12): intel: Remove unu

[PATCH] drm: Fix the CRTC_STEREO_DOUBLE_ONLY define to include stero modes

the CRTC_STEREO_DOUBLE flag. Otherwise, we'll get the wrong h/v for frame packing stereo 3d modes. Cc: Gustavo Padovan Cc: Matt Roper Cc: Ander Conselvan de Oliveira Signed-off-by: Damien Lespiau --- include/drm/drm_modes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm

[PATCH] drm: Fix drm_crtc_vblank_get() documentation

drm_crtc_vblank_get() is the new drm_vblank_get(), not the new drm_vblank_off(). Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 10574a0..c9f5453 100644

[Intel-gfx] [PATCH 3/5] drm/i915: Use fb format modifiers in skylake_update_primary_plane

On Mon, Feb 09, 2015 at 07:03:26PM +0100, Daniel Vetter wrote: > Just a little demo really. We probably need to introduce skl specific > functions for a lot of the format validation stuff, or at least > helpers. Specifically I think intel_framebuffer_init and > intel_fb_align_height must be

[PATCH libdrm] drm: Avoid out of bound write in drmOpenByName()

that retcode is > 0 to avoid that case. This was found by static analysis. Signed-off-by: Damien Lespiau --- xf86drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xf86drm.c b/xf86drm.c index d900b4b..106b8ab 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -579,7 +579,7 @@ static

[PATCH] Fix SIGSEGV in libdrm for heigth = 0 and width = 0

On Fri, Nov 07, 2014 at 07:43:04PM +0100, Thomas Meyer wrote: > > drm_intel_gem_bo_free() crashes because the list bo_gem->vma_list is not > yet initialised, but the error path tries to free it. > > See also https://bugs.freedesktop.org/show_bug.cgi?id=75844 > > Reviewed-by: Chris Wilson >

[Intel-gfx] [PATCH 05/17] drm: Add atomic driver interface definitions for objects

On Wed, Nov 05, 2014 at 06:04:59PM +0100, Daniel Vetter wrote: > On Wed, Nov 5, 2014 at 5:26 PM, Thierry Reding > wrote: > >> +struct drm_plane_state { > >> + struct drm_crtc *crtc; > >> + struct drm_framebuffer *fb; > >> + > >> + /* Signed dest location allows it to be partially off

[PATCH 3/3] drm/gma500: Don't destroy DRM properties in the driver

When drm properties are created, they are added to mode_config.property_list which is then used in drm_mode_config_cleanup() to destroy every single property created by the driver. Cc: Patrik Jakobsson Signed-off-by: Damien Lespiau --- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 49

[PATCH 2/3] drm/i915: Don't destroy DRM properties in the driver

When drm properties are created, they are added to mode_config.property_list, which is then used in drm_mode_config_cleanup() to destroy every single property created by the driver. Cc: Chandra Konduru Cc: Daniel Vetter Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_sdvo.c | 47

[PATCH 1/3] drm: Add a note to drm_property_create() about property lifetime

Cc: Chandra Konduru Cc: Daniel Vetter Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_crtc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 4081d7a..0f3c24c 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu

[PATCH libdrm 1/3] intel/skl: Add SKL PCI ids

On Tue, Sep 30, 2014 at 11:19:37AM +0100, Thomas Wood wrote: > On 26 September 2014 14:19, Damien Lespiau > wrote: > > v2: Add more PCI IDs (Michael H. Nguyen) > > v3: Synchronize one more with the kernel PCI IDs (Damien) > > > > Signed-off-by: Damien Lespiau &

[PATCH libdrm 3/3] intel/skl: add gen9 to the CS decoding init

Signed-off-by: Damien Lespiau Reviewed-by: Kenneth Graunke Signed-off-by: Ben Widawsky --- intel/intel_decode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c index a5d6e04..7d5cbe5 100644 --- a/intel/intel_decode.c +++ b

[PATCH libdrm 2/3] intel/skl: Add gen9 to the buffer manager init

Signed-off-by: Damien Lespiau Reviewed-by: Kenneth Graunke Signed-off-by: Ben Widawsky --- intel/intel_bufmgr_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index ba65527..a6fa224 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel

[PATCH libdrm 1/3] intel/skl: Add SKL PCI ids

v2: Add more PCI IDs (Michael H. Nguyen) v3: Synchronize one more with the kernel PCI IDs (Damien) Signed-off-by: Damien Lespiau Signed-off-by: Ben Widawsky Signed-off-by: Michael H. Nguyen --- intel/intel_chipset.h | 43 ++- 1 file changed, 42

[Intel-gfx] [PATCH] intel: Don't leak the test page in an has_userptr() error path

On Fri, Sep 19, 2014 at 02:31:56PM +0100, Tvrtko Ursulin wrote: > > Reviewed-by: Tvrtko Ursulin > Thanks for the review, pushed the patch. -- Damien

[PATCH] intel: Don't leak the test page in an has_userptr() error path

When handling the error on GEM_CLOSE, we weren't freeing the allocated page. Plug that. Signed-off-by: Damien Lespiau --- intel/intel_bufmgr_gem.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index f378e5c..ce35bd4

[Intel-gfx] [PATCH] intel: Add support for userptr objects

ns and uncertainty > about its usefulness. > > v2: Improved error handling in feature detection per review comments. > > Signed-off-by: Tvrtko Ursulin > --- Reviewed-by: Damien Lespiau Pushed a slightly modified version of this patch as libdrm now has explicit symb

Shareable bufmgr objects v4

On Mon, Sep 15, 2014 at 02:12:25PM +0100, Chris Wilson wrote: > On Fri, Sep 12, 2014 at 01:48:34PM +0100, Lionel Landwerlin wrote: > > This is getting bigger than expected. Adding the locking that Chris > > suggested on IRC. > > > > Thanks for taking time to review Chris. > > I'm happy with this

[PATCH] drm: Improve debug output for drm_wait_one_vblank

On Mon, Sep 15, 2014 at 02:05:56PM +0200, Daniel Vetter wrote: > This replicates what we've done in i915 in > > commit 31e4b89acbd7b19c9a8557e6e660a583a0b97daa > Author: Damien Lespiau > Date: Mon Aug 18 13:51:00 2014 +0100 > > drm/i915: Print the pipe on which the

[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

On Wed, Aug 27, 2014 at 03:11:08PM +0200, Thierry Reding wrote: > > So we're left with > > > > #define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0) > > > > Vs > > > > #define DP_TRAIN_VOLTAGE_SWING_LEVEL(x) ((x) << 0) > > > > The second variant doesn't really bring much more clarity?

drm/i915/bdw: Provide the BDW specific HDMI buffer translation table

On Wed, Aug 27, 2014 at 04:04:46PM +0300, Dan Carpenter wrote: > Hello Damien Lespiau, > > The patch a26aa8baee6c: "drm/i915/bdw: Provide the BDW specific HDMI > buffer translation table" from Aug 1, 2014, leads to the following > static checker warning: >

[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

On Wed, Aug 27, 2014 at 08:47:54AM +0100, Damien Lespiau wrote: > > An alternative would be to provide a second set of defines for eDP 1.4 > > where the name implies the meaning and then use them as appropriate. > > We went through the idea as well and: > > I actually t

[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

On Tue, Aug 26, 2014 at 01:28:19PM +0200, Thierry Reding wrote: > On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jindal at intel.com wrote: > > From: Sonika Jindal > > > > Adding new defines, older one will be removed in the last patch in the > > series. > > This is to rename the defines to

drivers/video/hdmi.c: Source Product Description (SPD) Information frame logging

On Tue, Aug 26, 2014 at 12:46:32PM +0200, Martin Bugge (marbugge) wrote: > Hello Damien > > I'm writing to you as you seems to be one of latest maintainers of: > > include/linux/hdmi.h > drivers/video/hdmi.c > > I wanted to add "Source Product Description information frame" > logging for the

[Intel-gfx] [PATCH 2/7] drm/i915: Renaming DP training vswing pre emph defines

s are different. > > Done using following cocci patch for each define: > @@ > @@ > > # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0) > + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0) > > ... > > Signed-off-by: Sonika Jindal Reviewed-by

[Intel-gfx] [PATCH 1/7] drm: Renaming DP training vswing pre emph defines

LEVEL_0 (0 << 0) > > ... > Cc: dri-devel at lists.freedesktop.org > > Signed-off-by: Sonika Jindal Reviewed-by: Damien Lespiau -- Damien > --- > include/drm/drm_dp_helper.h |8 > 1 file changed, 8 insertions(+) > > diff --git a/include/

How to design a DRM KMS driver exposing 2D compositing?

On Mon, Aug 11, 2014 at 03:07:33PM +0300, Pekka Paalanen wrote: > > > there is some hardware than can do 2D compositing with an arbitrary > > > number of planes. I'm not sure what the absolute maximum number of > > > planes is, but for the discussion, let's say it is 100. > > > > > > There are

How to design a DRM KMS driver exposing 2D compositing?

On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > Hi, Hi, > there is some hardware than can do 2D compositing with an arbitrary > number of planes. I'm not sure what the absolute maximum number of > planes is, but for the discussion, let's say it is 100. > > There are many

[PATCH] drm: Use the type of the array element when reallocating

as: struct drm_fb_helper_connector { struct drm_connector *connector; }; This was still doing the right thing, but may not in the future if additional fields are added. Cc: Todd Previte Cc: Dave Airlie Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file

[PATCH] drm: Don't return 0 for a value used as a denominator

Static analysis will be unhappy if a function can theoretically return 0 and we're trying to divide by that value. Mark that case that cannot occur as a BUG() instead. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[Intel-gfx] [PATCH 0/6] Rename DP training vswing/pre-emph defines

On Tue, Aug 05, 2014 at 04:38:16PM +0530, sonika.jindal at intel.com wrote: > From: Sonika Jindal > > Rename the defines to have levels instead of values for vswing and pre-emph > levels as the values may differ in other scenarios like low vswing of eDP 1.4 > where the values are different. >

[PATCH] drm/mst: Don't use uninitialized fields of the sideband message header

We could be using uninitialized fields of the header in drm_dp_encode_sideband_msg_hdr(), for instance hdr->somt is set to 1 in the first patcket but never set to 0 otherwise. Always clear the header at the start then. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_dp_mst_topology.c

[PATCH] drm/mst: Avoid reading uninitialized value

A static analysis tool tells me that we could try to read an uninitialized 'ret' value. Plug that. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm

[Intel-gfx] [v2 00/11] Support for 180 degree HW rotation

On Sun, Jul 06, 2014 at 01:41:12PM +0530, Jindal, Sonika wrote: > >Missing from this series, your two documentation patches (we need to > >bundle things up as a entity that makes sense for one of the maintainers > >to pick it up (either Dave or Daniel)). > > > I was not aware that documentation

[v2 11/11] drm: Resetting rotation property

t intel.com > Signed-off-by: Sonika Jindal Reviewed-by: Damien Lespiau > --- > drivers/gpu/drm/drm_fb_helper.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > inde

[Intel-gfx] [v2 00/11] Support for 180 degree HW rotation

On Fri, Jul 04, 2014 at 03:13:52PM +0530, sonika.jindal at intel.com wrote: > From: Sonika Jindal > > Enables 180 degree rotation for sprite and primary planes. > Updated the primary plane rotation support as per the new universal plane > design. > > Most of these patches were already reviewed

[Intel-gfx] [v2 10/11] drm/i915: Add 180 degree primary plane rotation support

On Fri, Jul 04, 2014 at 03:14:02PM +0530, sonika.jindal at intel.com wrote: > +static int intel_primary_plane_set_property(struct drm_plane *plane, > + struct drm_property *prop, > + uint64_t val) > +{ > + struct drm_device *dev =

[PATCH libdrm 1/2] intel: Sync the command parser version parameter from kernel

On Thu, Jun 19, 2014 at 09:28:08AM -0700, Volkin, Bradley D wrote: > On Thu, Jun 19, 2014 at 11:31:53AM +0100, Damien Lespiau wrote: > > Cc: Bradley Volkin > > Signed-off-by: Damien Lespiau > > Thanks for taking care of this Damien. > > Reviewed-by: Brad Volkin Th

[PATCH libdrm 2/2] intel: Sync typo fix from the kernel sources.

Signed-off-by: Damien Lespiau --- include/drm/i915_drm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index 980dbf8..8eb0cb3 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -722,7 +722,7 @@ struct

[PATCH libdrm 1/2] intel: Sync the command parser version parameter from kernel

Cc: Bradley Volkin Signed-off-by: Damien Lespiau --- include/drm/i915_drm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index 2f4eb8c..980dbf8 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -337,6 +337,7 @@ typedef

[PATCH] drm/doc: Fix nouveau typo

Signed-off-by: Damien Lespiau --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index efef637..0854aed 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook

[PATCH 3/3] drm/i915: Fix the confusing comment about the ioctl limits

It was reported that this comment was confusing, and indeed it is. Signed-off-by: Damien Lespiau --- include/uapi/drm/i915_drm.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index ff57f07..eacd063 100644

[PATCH 2/3] drm: Driver-specific ioctls range from 0x40 to 0x9f

DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99. Signed-off-by: Damien Lespiau --- include/uapi/drm/drm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 9abbeb9..b0b8556 100644 --- a/include/uapi/drm

[PATCH 1/3] drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()

I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used in a few places. I suspect its usage has been spread by copy & paste rather than anything else. Let's just remove it for plain ARRAY_SIZE(). Signed-off-by: Damien Lespiau --- drivers/gpu/drm/armada/armada_drv.c

[PATCH 0/3] A couple of fixes about the ioctl number split

It was reported a long time ago the various comments about the DRM/driver specific ioctl split were confusing. So tried to fix that. Patch #1 is a bonus patch that removes DRM_ARRAY_SIZE(). -- Damien Damien Lespiau (3): drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE() drm: Driver-specific

[PATCH] drm: Remove spurious ';'

One small step after another, the never-ending crusade towards better code continues. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/ast/ast_post.c | 4 ++-- drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c

[PATCH] drm/doc: Add the "type" plane property to the list of properties

Matt aded this plane property before we had a table giving a summary of the properties. Add it there. Cc: Matt Roper Signed-off-by: Damien Lespiau --- Documentation/DocBook/drm.tmpl | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/drm.tmpl b

[Intel-gfx] [PATCH] drivers/gpu/drm/i915/dma: style fixes

On Mon, Jun 02, 2014 at 04:59:39PM +0200, Robin Schroer wrote: > Fixed several double space pointer notations, and added one newline > > Signed-off-by: Robin Schroer Reviewed-by: Damien Lespiau -- Damien

  1   2   3   4   5   6   >