if (dmaobj->handle < obj->handle)
> ptr = &parent->rb_left;
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/bcc94657/attachment.sig>
chment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/b881fdd5/attachment.html>
On 2016å¹´12æ22æ¥ 02:46, Nicolai Hähnle wrote:
> +static inline bool __sched
> +__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
> +{
> + return a->stamp - b->stamp <= LONG_MAX &&
> +(a->stamp != b->stamp || a > b);
I want to ask a stupid question, why
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/b36eed70/attachment.html>
/20161222-101700
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-r0-201651 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones
ion
-- next part --
A non-text attachment was scrubbed...
Name:
dmesg-yocto-vp-2:20161215153506:x86_64-randconfig-s0-12151053:4.8.0-rc4-3-gbea5b15:1.gz
Type: application/gzip
Size: 12216 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dr
ructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
------ next part --
A non-text attachment was scrubbed...
Name:
dmesg-quantal-ivb41-71:20161216224430:i386-randconfig-x0-12161837:4.8.0-rc4-3-
On Wed, Dec 21, 2016 at 05:21:18PM -0500, Rob Clark wrote:
> On Wed, Dec 21, 2016 at 3:41 PM, Imre Deak wrote:
> > On Thu, 2016-02-25 at 16:15 -0500, Rob Clark wrote:
> >> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
> >> with troublesome monitors.
> >>
> >> v2: don't try
On Wed, Dec 21, 2016 at 05:26:21PM +, Kristian Høgsberg wrote:
> On Wed, Dec 21, 2016 at 7:42 AM Rob Clark wrote:
>
> > On Wed, Dec 21, 2016 at 4:19 AM, Ville Syrjälä
> > wrote:
> > > On Wed, Dec 21, 2016 at 10:15:15AM +0100, Daniel Vetter wrote:
> > >> On Tue, Dec 20, 2016 at 07:46:12PM
On Wed, Dec 21, 2016 at 03:30:04PM +0100, Michael Thayer wrote:
> 21.12.2016 10:05, Daniel Vetter wrote:
> > On Tue, Dec 20, 2016 at 11:38:52AM +0100, Michael Thayer wrote:
> > > The suggested X and Y connector properties are intended as a way for
> > > drivers
> > > for virtual machine GPUs to pr
On Wed, Dec 21, 2016 at 12:12:08PM -0800, Dhinakaran Pandiyan wrote:
> This check is useful for drivers that do not have DRIVER_ATOMIC set but
> have atomic modesetting internally implemented. Wrap the check into a
> function since this is used in many places and as a bonus, the function
> name hel
Hi Dave,
Here's the one lonely bugfix I talked about on irc. There's an oops fix
for nonblocking atomic pending (only hittable for drivers broken in a
specific way, but it's good to make things resilient), but no tested-by
yet from reporters hence postponed.
Cheers, Daniel
The following changes
Hi Dhinakaran,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20161222]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dhinakaran-Pandiyan/drm
On Wed, 2016-12-21 at 12:12 -0800, Dhinakaran Pandiyan wrote:
> This check is useful for drivers that do not have DRIVER_ATOMIC set but
> have atomic modesetting internally implemented. Wrap the check into a
> function since this is used in many places and as a bonus, the function
> name helps to d
Some code beautification applied to lib/prime_numbers (and a couple of
spelling mistakes that Joonas had noticed but I forgot to apply).
-Chris
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
v2: Extract helpers for the repeated tests
v3: Iterate over all allocation flags
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/d
Build the struct drm_mm selftests so that we can trivially run them
within our CI.
"Enable debug, become developer." - Joonas Lahtinen
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
When testing, we want a random but yet reproducible order in which to
process elements. Here we create an array which is a random (using the
Tausworthe PRNG) permutation of the order in which to execute.
Note these are simple helpers intended to be merged upstream in lib/
v2: Tidier code by David
Reuse drm_mm_insert_node() with a temporary node to exercise
drm_mm_replace_node(). We use the previous test in order to exercise the
various lists following replacement.
v2: Check that we copy across the important (user) details of the node.
The internal details (such as lists and hole tracking)
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
v2: Flip sign on conditional assert.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selfte
The nodes must be removed in the *reverse* order. This is correct in the
overview, but backwards in the function description. Whilst here add
Intel's copyright statement and tweak some formatting.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 34 +++
A simple assert to ensure that we don't overflow start + size when
initialising the drm_mm, or its scanner.
In future, we may want to switch to tracking the value of ranges (rather
than size) so that we can cover the full u64, for example like resource
tracking.
Signed-off-by: Chris Wilson
Revie
Acknowledging that we were building up the hole was more useful to me
when reading the code, than knowing the relationship between this node
and the previous node.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 16
1 file changed, 8 inse
First we introduce a smattering of infrastructure for writing selftests.
The idea is that we have a test module that exercises a particular
portion of the exported API, and that module provides a set of tests
that can either be run as an ensemble via kselftest or individually via
an igt harness (in
For power-of-two alignments, we can avoid the 64bit divide and do a
simple bitwise add instead.
v2: s/alignment_mask/remainder_mask/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 1 +
2 files changed, 9 insertion
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/3a6e524e/attachment-0001.html>
The scan state occupies a large proportion of the struct drm_mm and is
rarely used and only contains temporary state. That makes it suitable to
moving to its struct and onto the stack of the callers.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c
Check that after applying the driver's color adjustment, restricted
eviction scanning finds a suitable hole.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 116
Check that we add arbitrary blocks to a restrited eviction scanner in
order to find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c |
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
v2: Refactor out some common eviction code for later
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
d
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/drm_mm/align64
Testcase: igt/gem_exec_alignment
Signed-of
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
v2: Use all allocation flags
v3: Don't pass in invalid ranges - these will be asserted later.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h
mm->color_adjust() compares the hole with its neighbouring nodes. They
only abutt before we restrict the hole, so we have to apply color_adjust
before we apply the range restriction.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 16 ++--
1 f
The range restriction should be applied after the color adjustment, or
else we may inadvertently apply the color adjustment to the restricted
hole (and not against its neighbours).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 15 +--
1 file
Check that after applying the driver's color adjustment, eviction
scanning finds a suitable hole.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 156 +++
2
Protect ourselves from a caller passing in node.start + node.size that
will overflow and trick us into reserving that node.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/
When we evict from the GTT to make room for an object, the hole we
create is put onto the MRU stack inside the drm_mm range manager. On the
next search pass, we can speed up a PIN_HIGH allocation by referencing
that stack for the new hole.
v2: Pull together the 3 identical implements (ahem, a coup
Since commit ea7b1dd44867 ("drm: mm: track free areas implicitly"),
to test whether there are any nodes allocated within the range manager,
we merely have to ask whether the node_list is empty.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 19 +-
Fairly commonly we want to inspect the node list on the struct drm_mm,
which is buried within an embedded node. Bring it to the surface with a
bit of syntatic sugar.
Note this was intended to be split from commit ad579002c8ec ("drm: Add
drm_mm_for_each_node_safe()") before being applied, but my ti
Doing the check is trivial (low cost in comparison to overall eviction)
and helps simplify the code.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 53 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 10 ++-
i
Insulate users from changes to the internal hole tracking within
struct drm_mm_node by using an accessor for hole_follows.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c| 12 ++--
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
d
Remove a superfluous helper as drm_mm_insert_node is equivalent to
insert_node_in_range with a range of [0, U64_MAX].
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 166 ---
include/drm/drm_mm.h | 90 +
Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
after drm_mm_scan_add_block() we can further simplify the list
manipulations when generating the temporary scan-hole.
v2: Highlight the games being played with the lists to track the scan
holes without allocation.
Signed-off-by
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
v2: Check for invalid node reservation.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 100 +
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
v5: Fix RCU unwin
Simple test to just exercise calling the debug dumper on the drm_mm.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 35
2 files changed, 36 insertions(+
Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and
validation checking using BUG_ON. Ideally these paths should all be
exercised by CI selftests (with the asserts enabled).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 45 +
Compute the minimal required hole during scan and only evict those nodes
that overlap. This enables us to reduce the number of nodes we need to
evict to the bare minimum.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c| 60 ++
Check that we can request alignment to any power-of-two or prime using a
plain drm_mm_node_insert(), and also handle a reasonable selection of
primes.
v2: Exercise all allocation flags
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h |
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
v2: s/no_color_touching/separate_adjacent_colors/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either t
Using mm->color_adjust makes the eviction scanner much tricker since we
don't know the actual neighbours of the target hole until after it is
created (after scanning is complete). To work out whether we need to
evict the neighbours because they impact upon the hole, we have to then
check the hole a
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 114 +++
2 files changed, 115 insertions(
On 22.12.2016 02:58, zhoucm1 wrote:
> On 2016å¹´12æ22æ¥ 02:46, Nicolai Hähnle wrote:
>> +static inline bool __sched
>> +__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
>> +{
>> +return a->stamp - b->stamp <= LONG_MAX &&
>> + (a->stamp != b->stamp || a > b)
On Thu, Dec 22, 2016 at 10:36:01AM +0200, Ander Conselvan De Oliveira wrote:
> On Wed, 2016-12-21 at 12:12 -0800, Dhinakaran Pandiyan wrote:
> > This check is useful for drivers that do not have DRIVER_ATOMIC set but
> > have atomic modesetting internally implemented. Wrap the check into a
> > func
On Thu, 2016-12-22 at 08:02 +0100, Daniel Vetter wrote:
> On Wed, Dec 21, 2016 at 05:21:18PM -0500, Rob Clark wrote:
> > On Wed, Dec 21, 2016 at 3:41 PM, Imre Deak wrote:
> > > On Thu, 2016-02-25 at 16:15 -0500, Rob Clark wrote:
> > > > Add a new drm_debug bit for turning on DPCD logging, to aid d
On to, 2016-12-22 at 08:36 +, Chris Wilson wrote:
> Prime numbers are interesting for testing components that use multiplies
> and divides, such as testing DRM's struct drm_mm alignment computations.
>
> v2: Move to lib/, add selftest
> v3: Fix initial constants (exclude 0/1 from being primes)
On Thu, Dec 22, 2016 at 11:52:45AM +0200, Joonas Lahtinen wrote:
> On to, 2016-12-22 at 08:36 +, Chris Wilson wrote:
> > Prime numbers are interesting for testing components that use multiplies
> > and divides, such as testing DRM's struct drm_mm alignment computations.
> >
> > v2: Move to lib
Hi Dave, last i915 fixes for the merge window before v4.10-rc1.
Wishing you all the things people usually wish each other this time of
the year.
BR,
Jani.
The following changes since commit 7a9e10253e9e52451bbe80ddb2874368dbd240a3:
drm/i915: Move priority bumping for flips earlier (2016-12-0
On Wed, 21 Dec 2016, vathsala nagaraju wrote:
> PSR2 vsc revision number hb2( as per table 6-11)is updated to
> 4 or 5 based on Y cordinate and Colorimetry Format as below
> 04h = 3D stereo + PSR/PSR2 + Y-coordinate.
> 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry
> Form
On Wed, 21 Dec 2016, vathsala nagaraju wrote:
> Function hsw_psr_setup handles vsc header setup for psr1 and
> skl_psr_setup_vsc handles vsc header setup for psr2.
>
> Setup VSC header in function skl_psr_setup_vsc for psr2 support,
> as per edp 1.4 spec, table 6-11:VSC SDP HEADER Extension for ps
dri-devel/attachments/20161222/58d27f15/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/a4e51cc1/attachment-0001.html>
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/9eac5d0c/attachment.html>
On Thu, Dec 22, 2016 at 10:02:26AM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 21-12-2016 15:29, Shashank Sharma wrote:
>
> [snip]
>
> > +
> > + /**
> > +* @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding.
> > +* various sinks can support 10/12/16 bit per channel deep
>
From: Shawn Guo
It enables HDMI audio support through SPDIF interface based on generic
hdmi-audio-codec driver. The HDMI hardware supports more audio
interfaces than SPDIF, like I2S, which may be added later.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/Kconfig| 1 +
drivers/gpu
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
v5: Fix RCU unwin
On Tue, Dec 20, 2016 at 7:09 AM, Shawn Guo wrote:
> From: Shawn Guo
>
> It enables VOU VL (Video Layer) to support overlay plane with scaling
> function. VL0 has some quirks on scaling support. We chose to skip it
> and only adds VL1 and VL2 into DRM core for now.
>
> Signed-off-by: Shawn Guo
On Thu, Dec 22, 2016 at 8:11 AM, Shawn Guo wrote:
> From: Shawn Guo
>
> It enables HDMI audio support through SPDIF interface based on generic
> hdmi-audio-codec driver. The HDMI hardware supports more audio
> interfaces than SPDIF, like I2S, which may be added later.
>
> Signed-off-by: Shawn Gu
On Thu, Dec 22, 2016 at 2:02 AM, Daniel Vetter wrote:
> On Wed, Dec 21, 2016 at 05:21:18PM -0500, Rob Clark wrote:
>> On Wed, Dec 21, 2016 at 3:41 PM, Imre Deak wrote:
>> > On Thu, 2016-02-25 at 16:15 -0500, Rob Clark wrote:
>> >> Add a new drm_debug bit for turning on DPCD logging, to aid debugg
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/4f0e0b8b/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/a32d466b/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/dbf5813a/attachment.html>
On Wed, Nov 23, 2016 at 12:05 PM, Thomas Petazzoni
wrote:
> On Wed, 23 Nov 2016 11:12:32 +0200, Tomi Valkeinen wrote:
>> Or do you mean that we should keep the drivers in staging until there's
>> a matching DRM driver, but drop any plans to move the drivers from
>> staging to drivers/video/? If s
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/1fbdae53/attachment.html>
|--- |NOTOURBUG
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/d3617968/attachment.html>
trl+Alt+F2 / Ctrl+Alt+F1). Even better: After moving to Wayland
(F25) I did not notice the bug anymore.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archive
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/4ac8642b/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=107001
Felix Schwarz changed:
What|Removed |Added
CC||felix.schwarz at oss.schwarz.e
ail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161222/811f36bb/attachment.html>
I haven't paid as close attention to Xorg issues sine the stroke last
year, and I hadn't needed to reboot the box in the living room in
several months.
When I did need to, I found that hdmi audio was unlistenable. It
sounded like it was mixed witht white noise.
If I boot vmlinuz-3.19.0 is works
On 12/07/2016 10:55 PM, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:
>>
>> å¾æç iPad å³é
>>
>>> Thierry Reding æ¼ 2016å¹´12æ6æ¥
>>> ä¸å11:46 寫éï¼
>>>
On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
The Chunghwa CLAA070WP03
This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.
v2:
Change return type to bool (Ville)
PSR2 vsc revision number hb2( as per table 6-11)is updated to
4 or 5 based on Y cordinate and Colorimetry Format as below
04h = 3D stereo + PSR/PSR2 + Y-coordinate.
05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry
Format indication. A DP Source device is allowed to indicate
Hi Shashank,
On 21-12-2016 15:29, Shashank Sharma wrote:
> HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
> called hdmi-forum vendor specific data block (HF-VSDB). This block
> contains information about sink's support for HDMI 2.0 compliant
> features. These features are:
>
Hi Shashank,
On 21-12-2016 15:29, Shashank Sharma wrote:
[snip]
> +
> + /**
> + * @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding.
> + * various sinks can support 10/12/16 bit per channel deep
> + * color encoding. edid_yuv420_dc_modes = 0 means sink doesn't
> +
Hi Shashank,
On 21-12-2016 15:29, Shashank Sharma wrote:
> This patch adds a small helper function, which clears the cached
> information about a hot-pluggable display, from connector. On event
> This will run on event of a hot-unplug, keeping the connector's display
> info up-to-date, avoiding a
22.12.2016 08:07, Daniel Vetter пиÑеÑ:
> On Wed, Dec 21, 2016 at 03:30:04PM +0100, Michael Thayer wrote:
>> 21.12.2016 10:05, Daniel Vetter wrote:
>>> On Tue, Dec 20, 2016 at 11:38:52AM +0100, Michael Thayer wrote:
The suggested X and Y connector properties are intended as a way for
i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
atomic_commit. drm_object_property_get_value() does not read the correct
value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
the driver uses atomic modeset is a better check instead as the property
values
Done, hope I got it right this time.
-DK
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, December 22, 2016 12:52 AM
To: Ander Conselvan De Oliveira
Cc: Pandiyan, Dhinakaran ; intel-gfx at
lists.freedesktop.org; Daniel Ve
91 matches
Mail list logo
