Hi,
> > +struct vfio_device_query_gfx_plane {
> > + __u32 argsz;
> > + __u32 flags;
> > + struct vfio_device_gfx_plane_info plane_info;
> > + __u32 plane_type;
> > + __s32 fd; /* dma-buf fd */
> > + __u32 plane_id;
> > +};
> > +
>
> It would be better to have comment here about what
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + * struct vfio_device_query_gfx_plane)
> + * Return: 0 on success, -errno on failure.
> + */
> +
> +struct vfio_device_gfx_plane_info {
> + __u64 start;
> + __u64 drm_format_mod;
> +
Hi,
Still against dinf, here's current gvt fixes for 4.13.
Thanks.
--
The following changes since commit 7581d5ca2bb269cfc2ce2d0cb489aac513167f6b:
drm/i915/fbdev: Check for existence of ifbdev->vma before operations
(2017-07-10 10:33:03 +0300)
are available in the git repository at:
http
== Series Details ==
Series: Adding NV12 support for SKL display (rev4)
URL : https://patchwork.freedesktop.org/series/25377/
State : warning
== Summary ==
Series 25377v4 Adding NV12 support for SKL display
https://patchwork.freedesktop.org/api/1.0/series/25377/revisions/4/mbox/
Test kms_flip
From: Daniel Vetter
---
integration-manifest | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 integration-manifest
diff --git a/integration-manifest b/integration-manifest
new file mode 100644
index 000..c407669
--- /dev/null
+++ b/integration-manifest
@
From: Chandra Konduru
This patch adds NV12 to list of supported formats for
primary plane
v2: Rebased (Chandra Konduru)
v3: Rebased (me)
v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats
v5: Reb
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The lo
From: Chandra Konduru
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats
v4: Ad
From: Chandra Konduru
This patch updates scaler max limit support for NV12
v2: Rebased (me)
v3: Rebased (me)
v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Tested-by: Clinton Taylor
Reviewed-by: Clinton Taylor
Signed-of
From: Chandra Konduru
This patch adds NV12 to format_is_yuv() function
for sprite planes.
v2:
-Use intel_ prefix for format_is_yuv (Ville)
v3: Rebased (me)
v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to th
From: Chandra Konduru
This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling
v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler
v3:
This patch series is adding NV12 support for Skylake display after
rebasing on latest drm-intel-nightly. Initial series of the patches
can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html
Feature has been currently tested with custom linux based test tool
IGT te
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
lo
Hi,
This is the version 10 ABI interface. I took Gerd's advice to submit the
interface only. If everything is fine, I can submit the whole patch set.
So, how do you think about this ABI interface.
Thanks.
BR,
Tina
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...
On Fri, Jul 7, 2017 at 10:17 AM, Chris Wilson
wrote:
> The goal here was to minimise doing any thing or any check inside the
> kernel that was not strictly required. For a userspace that assumes
> complete control over the cache domains, the kernel is usually using
> outdated information and may
merged, thanks
On Mon, Jul 10, 2017 at 12:25 PM, Vivi, Rodrigo wrote:
> On Mon, 2017-07-10 at 13:29 +0300, Jani Nikula wrote:
>> On Thu, 06 Jul 2017, Rodrigo Vivi wrote:
>> > Ideally .rst would referrence .rst with :ref:`` but since
>> > these documentation are different repository we cannot lin
== Series Details ==
Series: drm/i915/cnl: Add missing type case.
URL : https://patchwork.freedesktop.org/series/27080/
State : success
== Summary ==
Series 27080v1 drm/i915/cnl: Add missing type case.
https://patchwork.freedesktop.org/api/1.0/series/27080/revisions/1/mbox/
Test gem_exec_susp
Paulo had noticed that inside cnl_ddi_vswing_program
the case was handling voltage but with no indication
of type where a missing type could also take us to that
path. So my first attempt was to add a message to
let clear who trigger that path.
However DK had a better idea that is to handle the
mi
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Track minimum acceptable cdclk
instead of "minimum dotclock"
URL : https://patchwork.freedesktop.org/series/27078/
State : warning
== Summary ==
Series 27078v1 Series without cover letter
https://patchwork.freedesktop.org/ap
Hi Dave,
Here's an updated pull request that encapsulates my earlier -next-fixes PR. I've
included the summary below for completeness.
The vblank timestamp patch fixes a quite noticable regression, so it'd be nice
to
sneak this in before rc1 is cut. The other 2 patches in this pull will only be
h
From: Ville Syrjälä
Make the min_pixclk thing less confusing by changing it to track
the minimum acceptable cdclk frequency instead. This means moving
the application of the guardbands to a slightly higher level from
the low level platform specific calc_cdclk() functions.
The immediate benefit i
From: Ville Syrjälä
Currently the .modeset_calc_cdclk() hooks check the final cdclk value
against the max allowed. That's not really sufficient since the low
level calc_cdclk() functions effectively clamp the minimum required
cdclk to the max supported by the platform. Hence if the minimum
requir
On Mon, 2017-07-10 at 13:29 +0300, Jani Nikula wrote:
> On Thu, 06 Jul 2017, Rodrigo Vivi wrote:
> > Ideally .rst would referrence .rst with :ref:`` but since
> > these documentation are different repository we cannot link
> > like this. However I believe the main usage is through the
> > compiled
On Mon, 2017-07-10 at 21:40 +0300, Ville Syrjälä wrote:
> On Mon, Jul 10, 2017 at 11:18:14AM -0700, Rodrigo Vivi wrote:
> > On clock recovery this function is called to find out
> > the max voltage swing level that we could go.
> >
> > However gen 9 functions use the old buffer translation tables
merged to dinq. thanks for the review
On Fri, Jul 7, 2017 at 10:58 AM, Imre Deak wrote:
> On Thu, Jul 06, 2017 at 01:45:08PM -0700, Rodrigo Vivi wrote:
>> This is a follow-up after enabling DC states with
>> commit: "drm/i915/DMC/CNL: Load DMC on CNL".
>>
>> Cc: Anusha Srivatsa
>> Cc: Imre Deak
== Series Details ==
Series: drm/i915/cnl: Fix DP max voltage
URL : https://patchwork.freedesktop.org/series/27076/
State : success
== Summary ==
Series 27076v1 drm/i915/cnl: Fix DP max voltage
https://patchwork.freedesktop.org/api/1.0/series/27076/revisions/1/mbox/
Test gem_exec_suspend:
On Mon, Jul 10, 2017 at 11:18:14AM -0700, Rodrigo Vivi wrote:
> On clock recovery this function is called to find out
> the max voltage swing level that we could go.
>
> However gen 9 functions use the old buffer translation tables
> to figure that out. That table is not valid for CNL
> causing an
On Mon, 2017-07-10 at 21:11 +0300, Ville Syrjälä wrote:
> On Mon, Jul 10, 2017 at 05:34:11PM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Mon, 2017-07-10 at 16:02 +0300, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Follow the GLK path when computing cdclk
On clock recovery this function is called to find out
the max voltage swing level that we could go.
However gen 9 functions use the old buffer translation tables
to figure that out. That table is not valid for CNL
causing an invalid number of entries and an invalid selection
on the max voltage swi
On Mon, Jul 10, 2017 at 05:34:11PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Mon, 2017-07-10 at 16:02 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Follow the GLK path when computing cdclk and related limits. CNL
> > pipes also produce two pixels per clock, so
On 07/09/2017 11:53 PM, Vidya Srinivas wrote:
From: Chandra Konduru
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_for
On Mon, Jul 10, 2017 at 10:34:22AM -0700, Rodrigo Vivi wrote:
> cool, with
>
> v2 of patch 1
> v2 of patch 2
> patch 3
>
> display works properly here on cnl.
>
> On Mon, Jul 10, 2017 at 6:02 AM, wrote:
> > From: Ville Syrjälä
> >
> > Follow the GLK path when computing cdclk and related limit
cool, with
v2 of patch 1
v2 of patch 2
patch 3
display works properly here on cnl.
On Mon, Jul 10, 2017 at 6:02 AM, wrote:
> From: Ville Syrjälä
>
> Follow the GLK path when computing cdclk and related limits. CNL
> pipes also produce two pixels per clock, so that's what we should
> really us
On Mon, 2017-07-10 at 16:02 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Follow the GLK path when computing cdclk and related limits. CNL
> pipes also produce two pixels per clock, so that's what we should
> really use. However for the purposes of pixel rate calculatio
On Fri, Jul 07, 2017 at 10:26:30AM -0700, Marc MERLIN wrote:
> On Fri, Jul 07, 2017 at 11:47:25AM +0100, Chris Wilson wrote:
> > Quoting Marc MERLIN (2017-07-07 06:40:51)
> > > Is this the right place to send this?
> > > Can anyone help?
> > >
> > > On Wed, Jul 05, 2017 at 11:33:01PM -0700, Marc M
On 10/07/17 17:11, Paul Kocialkowski wrote:
On Mon, 2017-07-10 at 16:56 +0300, Martin Peres wrote:
On 10/07/17 15:06, Paul Kocialkowski wrote:
On Mon, 2017-07-10 at 13:33 +0300, Martin Peres wrote:
On 10/07/17 13:31, Paul Kocialkowski wrote:
On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote
Link to FDO regression list:
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=DRM%2FIntel&f0=OP&f1=OP&f2=short_desc&f3=keywords&f4=CP&f5=CP&j1=OR&known_name=i915%20regressions&list_id=600614&o2=anywordssubstr&o3=anywordss
== Series Details ==
Series: drm/i915: Fix pre-g4x GPU reset, again (rev4)
URL : https://patchwork.freedesktop.org/series/26554/
State : success
== Summary ==
Series 26554v4 drm/i915: Fix pre-g4x GPU reset, again
https://patchwork.freedesktop.org/api/1.0/series/26554/revisions/4/mbox/
Test ge
On 7/10/2017 7:20 AM, Mika Kuoppala wrote:
Chris Wilson writes:
Although a banned context will be told to -EIO off if they try to submit
more requests, we have a discrepancy between whole device resets and
per-engine resets where we report the GPU reset but not the engine
resets. This leaves a
On Mon, Jul 10, 2017 at 2:15 PM, Jani Nikula
wrote:
> On Thu, 06 Jul 2017, Daniel Vetter wrote:
>> With deferred fbdev setup we always need to forward hotplug events,
>> even if fbdev isn't fully set up yet. Otherwise the deferred setup
>> will neer happen.
>>
>> Originally this check was added i
From: Ville Syrjälä
Eliminate plane->state and crtc->state usage from
intel_plane_atomic_check_with_state() and its callers. Instead pass the
proper states in or dig them up from the top level atomic state.
Note that intel_plane_atomic_check_with_state() itself isn't allowed to
use the top level
On Mon, Jul 10, 2017 at 3:26 PM, Maarten Lankhorst
wrote:
>>> The real fix is not taking struct_mutex during atomic commit, which will
>>> mean
>>> no deadlock can happen.
>>>
>>> Is this the bug being fixed here or am I missing something?
>> This would avoid both struct_mutex and modeset locks i
Highlights:
- 18 bugs open during the week
- 126 bugs closed during the week
- 7 bugs in resolved state during the week
- 316 total bugs remain open
- 16 bugs labeled ReadyForDev during the week
- 119 total bugs labeled ReadyForDev remain
== Series Details ==
Series: Revert "drm/i915: Add heuristic to determine better way to adjust
brightness"
URL : https://patchwork.freedesktop.org/series/27065/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK inc
This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
This patch has been identified to introduce a backlight regression
on at least two different platforms; either the heuristic is broken
(if so the patch needs to be reworked) or the in-kernel DPCD backlight
support is broken (if so it's
Chris Wilson writes:
> Although a banned context will be told to -EIO off if they try to submit
> more requests, we have a discrepancy between whole device resets and
> per-engine resets where we report the GPU reset but not the engine
> resets. This leaves a bit of mystery as to why the context
Chris Wilson writes:
> Since we make call i915_gem_context_mark_guilty() concurrently when
> resetting different engines in parallel, we need to make sure that our
> updates are safe for the unlocked access.
>
> Signed-off-by: Chris Wilson
> Cc: Michel Thierry
> Cc: Mika Kuoppala
And we dont
On Mon, 2017-07-10 at 16:56 +0300, Martin Peres wrote:
> On 10/07/17 15:06, Paul Kocialkowski wrote:
> > On Mon, 2017-07-10 at 13:33 +0300, Martin Peres wrote:
> > > On 10/07/17 13:31, Paul Kocialkowski wrote:
> > > > On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
> > > > >
> > > > > As well
Hello
I exeprience problems with Intel graphics driver. It hangs during loading.
I'm not a big specialist in Linux drivers and I can't debug video driver
and fix problem manually. But may be there are some people that can help me
- I can install something and check and whatever.
I suspect this dm
On Mon, Jul 10, 2017 at 03:26:18PM +0200, Maarten Lankhorst wrote:
> Op 10-07-17 om 14:18 schreef Ville Syrjälä:
> > On Mon, Jul 10, 2017 at 11:31:55AM +0200, Maarten Lankhorst wrote:
> >> Op 10-07-17 om 08:43 schreef Daniel Vetter:
> >>> On Fri, Jul 07, 2017 at 06:18:12PM +0300, Ville Syrjälä wrot
On 10/07/17 15:06, Paul Kocialkowski wrote:
On Mon, 2017-07-10 at 13:33 +0300, Martin Peres wrote:
On 10/07/17 13:31, Paul Kocialkowski wrote:
On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
As well, one advantage we do have here from the chamelium end is
that
you can only really be scre
On Mon, Jul 10, 2017 at 11:04:31AM +0200, Maarten Lankhorst wrote:
> Op 06-07-17 om 22:24 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Eliminate plane->state and crtc->state usage from
> > intel_plane_atomic_check_with_state() and its callers. Instead pass the
> > proper
Op 10-07-17 om 14:18 schreef Ville Syrjälä:
> On Mon, Jul 10, 2017 at 11:31:55AM +0200, Maarten Lankhorst wrote:
>> Op 10-07-17 om 08:43 schreef Daniel Vetter:
>>> On Fri, Jul 07, 2017 at 06:18:12PM +0300, Ville Syrjälä wrote:
On Fri, Jul 07, 2017 at 04:05:28PM +0200, Daniel Vetter wrote:
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Fix up CNL cdclk related limits
(rev3)
URL : https://patchwork.freedesktop.org/series/26988/
State : success
== Summary ==
Series 26988v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26988/rev
From: Ville Syrjälä
Make the min_pixclk thing less confusing by changing it to track
the minimum acceptable cdclk frequency instead. This means moving
the application of the guardbands to a slightly higher level from
the low level platform specific calc_cdclk() functions.
The immediate benefit i
From: Ville Syrjälä
Follow the GLK path when computing cdclk and related limits. CNL
pipes also produce two pixels per clock, so that's what we should
really use. However for the purposes of pixel rate calculations we
will assume one pixel per clock to keep the voltage higher, at least
until the
On Mon, Jul 10, 2017 at 11:31:55AM +0200, Maarten Lankhorst wrote:
> Op 10-07-17 om 08:43 schreef Daniel Vetter:
> > On Fri, Jul 07, 2017 at 06:18:12PM +0300, Ville Syrjälä wrote:
> >> On Fri, Jul 07, 2017 at 04:05:28PM +0200, Daniel Vetter wrote:
> >>> On Fri, Jul 7, 2017 at 3:21 PM, Ville Syrjälä
On Thu, 06 Jul 2017, Daniel Vetter wrote:
> With deferred fbdev setup we always need to forward hotplug events,
> even if fbdev isn't fully set up yet. Otherwise the deferred setup
> will neer happen.
>
> Originally this check was added in
>
> commit c45eb4fed12d278d3619f1904885bd0d7bcbf036 (tag:
On Mon, 2017-07-10 at 13:33 +0300, Martin Peres wrote:
> On 10/07/17 13:31, Paul Kocialkowski wrote:
> > On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
> > >
> > > As well, one advantage we do have here from the chamelium end is
> > > that
> > > you can only really be screen grabbing from on
On 7 July 2017 at 17:57, Lionel Landwerlin
wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 135
> +++
> 1 file changed, 135 insertions(+)
>
> diff --git a/tests/perf.c b/tests/perf.c
> index db28ba1f..14bbb361 100644
> ---
== Series Details ==
Series: YCBCR 4:2:0 handling for LSPCON
URL : https://patchwork.freedesktop.org/series/27061/
State : success
== Summary ==
Series 27061v1 YCBCR 4:2:0 handling for LSPCON
https://patchwork.freedesktop.org/api/1.0/series/27061/revisions/1/mbox/
Test gem_exec_suspend:
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
V4: Rebase
V5: Added r-b from A
LSPCON chips support YCBCR420 outputs. To be able to get
YCBCR420 output from LSPCON chip, the source should:
- Generate YCBCR444 HDMI output
- Set AVI infoframes for a YCBCR420 output.
LSPCON FW gets the information from AVI infoframes, and generates
YCBCR420 output from a YCBCR444 input. This pa
LSPCON chips can't pick the HDMI AVI infoframes from direct link.
In order to pass AVI infoframes from display controller to LSPCON,
we have to write infoframe packets into vendor specified AUX address.
Also, LSPCON vendors provide AUX offsets, to inform the LSPCON
chip that the AVI IF packets are
Intel LSPCON chip is provided by 2 vendors:
- Megachips America (MCA)
- Parade technologies (Parade tech)
Its important to know the vendor of this chip, as the address to
write AVI infoframes is different for those two.
This patch reads the vendor OUI signature, and marks into LSPCON
encoder stru
We have an existing function to prepare AVI infoframes for HDMI,
this patch moves that function from HDMI layer, to DDI layer, so
that we can reuse the function for DP(LSPCON) displays too.
This patch:
- Moves the intel_hdmi_set_avi_infoframes function in ddi layer.
- Adds code to accommodate LSPC
This patch adds a helper function in DP dual mode layer to
read the vendor's IEEE OUI signature from a Dual mode adapter.
This will be used to differentiate between different LSPCON
vendors, to address their custom programming requirements.
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Shashank
When output colorspace is YCBCR420, we have to load the
corresponding colorspace in AVI infoframe. This patch fills
the colorspace of AVI infoframe as per the output mode.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Added r-b from Ander
V6: Checking RGB/YCBCR420 output only (Ville)
Reviewed-by: Ander Co
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
sc
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, which uses recommended bspec
values to perf
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.
It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbc
This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.
V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling fo
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc
A source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
This patch adds a function to add the output colorspace
information in the AVI infoframes.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Rebase
V6: Made patch independent of HDMI out
YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connec
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.
This patch moves the
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which c
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
LSPCON is a DP->HDMI active dongle, enumerated as DP dual
mode adapter on Intel GEN9 platforms. It's provided by two
different vendors
- Mega Chips America (MCA)
- Parade Technologies (Parade)
In order to support YCBCR 4:2:0 outputs, these are the essential
steps:
- Convert
On 7 July 2017 at 18:08, Lionel Landwerlin
wrote:
> From: Matthew Auld
>
> The motivation behind this new interface is expose at runtime the
> creation of new OA configs which can be used as part of the i915 perf
> open interface. This will enable the kernel to learn new configs which
> may be ex
On 10/07/17 13:31, Paul Kocialkowski wrote:
On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
As well, one advantage we do have here from the chamelium end is that
you can only really be screen grabbing from one port at a time. So you
could actually just track stuff internally in the igt_cha
On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
> --snip--
> (also sorry this one took a while to get to, had to do a lot of
> thinking because I never really solved the problems mentioned here
> when
> I tried working on this...)
>
> On Thu, 2017-07-06 at 16:33 +0300, Paul Kocialkowski wrote
On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
> --snip--
> (also sorry this one took a while to get to, had to do a lot of
> thinking because I never really solved the problems mentioned here
> when
> I tried working on this...)
>
> On Thu, 2017-07-06 at 16:33 +0300, Paul Kocialkowski wrote
On Thu, 06 Jul 2017, Rodrigo Vivi wrote:
> Ideally .rst would referrence .rst with :ref:`` but since
> these documentation are different repository we cannot link
> like this. However I believe the main usage is through the
> compiled html pages and since we already reference another
> .html here
On Thu, 06 Jul 2017, Rodrigo Vivi wrote:
> All process related docs has moved to the new "process" folder,
> but also all .txt migrated to .rst as well.
We could point at the generated documentation at [1] or [2] instead of
git trees now.
BR,
Jani.
[1] https://www.kernel.org/doc/html/latest/
[2
On Thu, 2017-07-06 at 18:23 -0400, Lyude Paul wrote:
> On Thu, 2017-07-06 at 14:35 +0300, Paul Kocialkowski wrote:
> > On Thu, 2017-07-06 at 10:41 +0300, Martin Peres wrote:
> > > On 06/07/17 00:44, Lyude Paul wrote:
> > > > On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote:
> > > > > When
On 07/07, Lionel Landwerlin wrote:
> Now that we have the ability to load configs from userspace, we don't
> need to store all the configs in the kernel anymore. Let's just keep
> the test configs for test purposes.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_oa_bdw.c
Op 10-07-17 om 08:43 schreef Daniel Vetter:
> On Fri, Jul 07, 2017 at 06:18:12PM +0300, Ville Syrjälä wrote:
>> On Fri, Jul 07, 2017 at 04:05:28PM +0200, Daniel Vetter wrote:
>>> On Fri, Jul 7, 2017 at 3:21 PM, Ville Syrjälä
>>> wrote:
On Fri, Jul 07, 2017 at 02:03:38PM +0200, Daniel Vetter w
Op 06-07-17 om 22:24 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Make drm_connector_get() return the connector. This allows the nice
> pattern of 'foo->connector = drm_connector_get(connector)'
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
> ---
> drivers/
Op 06-07-17 om 22:24 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> We already have the correct new crtc state so just use that instead of
> crtc->state.
>
For patches 1-3 and 5-7:
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing
Op 06-07-17 om 22:24 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Eliminate plane->state and crtc->state usage from
> intel_plane_atomic_check_with_state() and its callers. Instead pass the
> proper states in or dig them up from the top level atomic state.
>
> Note that intel_p
Op 07-07-17 om 13:01 schreef Daniel Vetter:
> On Thu, Jul 06, 2017 at 03:03:15PM +0200, Maarten Lankhorst wrote:
>> Op 06-07-17 om 13:09 schreef Tomeu Vizoso:
>>> Looks good to me:
>>>
>>> Reviewed-by: Tomeu Vizoso
>>>
>>> I guess you have tested this with IGT? In any case, I think it would
>>> be
On Fri, 07 Jul 2017, Rodrigo Vivi wrote:
> patch merged to dinq. thanks for reviewing.
Did you report the VBT issue? Whenever we paper over bugs in other
components, we're sending a message it's fine. It's not.
BR,
Jani.
>
> On Thu, Jul 6, 2017 at 2:52 PM, Clint Taylor
> wrote:
>>
>>
>> On 0
== Series Details ==
Series: Adding NV12 support for SKL display (rev3)
URL : https://patchwork.freedesktop.org/series/25377/
State : success
== Summary ==
Series 25377v3 Adding NV12 support for SKL display
https://patchwork.freedesktop.org/api/1.0/series/25377/revisions/3/mbox/
Test kms_curs
Op 07-07-17 om 02:15 schreef Gustavo Padovan:
> Hi Maarten,
>
> 2017-07-06 Maarten Lankhorst :
>
>> I wanted to make kms_atomic_transition pass, but the nonblocking modeset
>> fencing tests were bogus.
>>
>> This series changes the semantics for fencing slightly. It only keeps the
>> out fences
>>
98 matches
Mail list logo
