A few styles issues have creept in here, fix them before touching this
code again.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95d6f4b
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
Signed-off-by: Damien Lespiau
Tested-by: Cancan Feng
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
---
drive
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.
> Upd
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 del
eing defined 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
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 compli
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 man
EL_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/drm/drm_
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
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 dri
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 ha
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
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:
>
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? Can
ust making sure 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
or when it encouters an invalid format, leaving the
> user scratching his head trying to figure out why addfb failed. Make
> life a bit easier by using drm_get_format_name() in both places.
>
> Signed-off-by: Ville Syrj?l?
Reviewed-by: Damien Lespiau
--
Damien
Those functions are just reading data from those pointers.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_debugfs.c | 4 ++--
include/drm/drmP.h| 9 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm
Those structures are not used anywhere.
Signed-off-by: Damien Lespiau
---
include/drm/drmP.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c3b659a..1c502ff 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4813ff1..b4b51d4 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ebbb50e..7dac943 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b
On Thu, Apr 03, 2014 at 11:32:30AM +0200, Daniel Vetter wrote:
> On Wed, Apr 02, 2014 at 08:26:23AM -0700, Randy Dunlap wrote:
> > On 04/02/2014 01:24 AM, Jani Nikula wrote:
> > > Drop the cast from the pointer diff to fix:
> > >
> > > drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format
that we could automatically overscan with
the right amount at some point (with some sort of database) and with
that flag set, we don't know if the sink is overscanning or not, but
then I guess we could include whether the TV honour in that flag in a db
as well.
In any case, I echo the review:
Reviewed-by: Damien Lespiau
--
Damien
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e90c8dc..b248382 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -659,7 +659,7 @@ struct
I was reminded on Monday that we'd like to be able to subclass struct
drm_device so we don't have to always juggle between a pointer to a struct
drm_device and its drv_private field to access everything we care about.
It'd be nicer for those two pointers to have the same value to avoid a few
extra
Not specifying it makes it a bit easier to identify drivers that really
need this field, and down the line, ease refactoring. This field doesn't
make sense for KMS drivers anyway.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/qxl/qxl_
This field is only used when creating a new buffer and can already be
found in the drm_driver structure, so no need to duplicate the
information for every buffer.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_bufs.c | 13 ++---
include/drm/drmP.h | 1 -
2 files changed
This field is really the size of the per-driver private data attached to
a struct drm_buf. Name it accordingly and add a comment so it doesn't
get confused with, say, the size of the private data attatched to a struct
drm_device.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_b
the device structure.
This patch enables drivers to declare the size of the device structure
they want DRM core to create for them.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_stub.c | 8 +++-
include/drm/drmP.h | 8
2 files changed, 15 insertions(+), 1 deletion(-)
d
_private in our
struct drm_driver definition for the DRM core to allocate enough
space,
- to ease the transition, dev->dev_private is still valid and points
to the start of the structure.
- don't kfree dev_private either in the _load() error path or the
_unload() vfunc.
On Wed, Jan 08, 2014 at 09:26:51PM +0100, Daniel Vetter wrote:
> > So the parent structure is expected to have "struct drm_device" at
> > offset 0? I'd rather like to see a "drm_dev_init()" alongside
> > drm_dev_alloc() similar to device_initialize().
>
> Yeah, I think for subclassing we want driv
On Wed, Dec 11, 2013 at 11:35:06AM +0100, Daniel Vetter wrote:
> Especially not on modesetting drivers - this is used to size
> the driver private structure for legacy drm buffers.
>
> Signed-off-by: Daniel Vetter
I managed to write the same patch one month later, so:
Reviewe
On Tue, Jan 14, 2014 at 04:21:50PM -0200, Rodrigo Vivi wrote:
> This debugfs interface will allow intel-gpu-tools test case
> to verify if screen has been updated properly on cases like PSR.
>
> v2: Accepted all Daniel's suggestions:
> * grab modeset lock
> * loop over connector and check
On Thu, Jan 16, 2014 at 05:55:06PM +, Damien Lespiau wrote:
> > + /* Wait 2 vblanks to be sure we will have the correct CRC value */
> > + intel_wait_for_vblank(dev, intel_crtc->pipe);
> > + intel_wait_for_vblank(dev, intel_crtc->pipe);
>
> I think t
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 =
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 i
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
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 pat
I just collected a few sad patches crying in the dark alley of the Internet
that dri-devel can sometimes be. A few of them even have a r-b tag by
benevolent and fatherly figures. All they want is to find a new home!
--
Damien
As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.
Signed-off-by: Damien Lespiau
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_modes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers
Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.
v2: Also patch output_poll_execute() (Daniel Vetter)
Signed-off-by: Damien Lespiau
Reviewed-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc_helper.c | 22 ++
1 fi
drm_helper_probe_single_connector_modes() is responsible for pruning the
previously detected modes on a disconnected connector. We don't really
need to log, again, the full list of modes that used to be valid when
connected.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_hel
From: "Lespiau, Damien"
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e3e0d65..23fb185 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
From: Chris Cummins
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_io
Updated series with:
- Reviews applied,
- Drop a patch that would conflict with Ville's latest changes,
- Drop Chris (Cummins)'s patch as he rebased it on top of drm-next and sent it
back himself,
- Add a suggestion from Chris (Wilson) to not repeat the message in the poll
handler. I did not d
As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.
Signed-off-by: Damien Lespiau
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_modes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers
Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.
v2: Also patch output_poll_execute() (Daniel Vetter)
v3: Use drm_get_connector_status_name (Ville Syrj?l?)
Signed-off-by: Damien Lespiau
Reviewed-by: Jesse Barnes (for v1)
---
drive
drm_helper_probe_single_connector_modes() is responsible for pruning the
previously detected modes on a disconnected connector. We don't really
need to log, again, the full list of modes that used to be valid when
connected.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_hel
Suggested-by: Chris Wilson
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9085db6..ed1334e 100644
--- a
here are still some
> deltas between the kernel i915_drm.h and the one in libdrm, but those
> can be resolved in other patches.
>
> Signed-off-by: Ian Romanick
> Reviewed-by: Kenneth Graunke [v3]
> Cc: Mika Kuoppala
> Cc: Daniel Vetter
Looks good to me.
by: Zhenyu Wang
> Cc: Damien Lespiau
> Cc: Daniel Vetter
I was thinking that I missed it in the (lidrm) review, but it's actually
a newer patch that introduces the checks.
Lesson learned for next ioctl reviews (kernel), have a better pass on
the input validation and think about rejecti
On Thu, Nov 21, 2013 at 07:19:45PM +0200, Ville Syrj?l? wrote:
> > > It seems natural to extend those flags to describe the picture aspect
> > > ratio (that
> > > why dri-devel is in Cc., touching core DRM).
> >
> > To start with we can use a single bit in drm_display_mode->flags to
> > distingu
To make it clear what exactly mode_valid() should return.
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc_helper.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index ef6ad3a..b1388b5 100644
--- a
We had some mode_valid() vfuncs returning an int, others the enum. Let's
use the latter everywhere.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_crt.c | 5 +++--
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_dsi.c | 5 +++--
drivers/gpu/drm
ly wrong:
- 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):
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
d-off-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 inser
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
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
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 |
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_
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
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
---
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
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/
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/
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
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
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
> >
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
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
> GPG
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
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
ase.
Also, 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..e17db
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
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
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 ++
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/
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 &
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
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
> color
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 files,
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.
>
> Signed-o
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 drm_in
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 get_p
(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 *g
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 st
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 propert
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
> color
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 actual
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 som
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:
>
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 prog
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 app
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,
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.
>
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 functions
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 case
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
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
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 adjuste
401 - 500 of 505 matches
Mail list logo
