https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #4 from wangjingbin ---
In OpenGL ES spec, GL_RGB32F is texture supported format, but is not color
renderable format, it means that texture with this format could been sampled in
shader. But it cannot be as an attachment for a frameb
On 21.05.2018 23:56, Peter Rosin wrote:
> On 2018-05-21 11:21, Andrzej Hajda wrote:
>> On 21.05.2018 10:53, Peter Rosin wrote:
>>> On 2018-05-21 10:15, Andrzej Hajda wrote:
On 19.05.2018 18:48, Peter Rosin wrote:
> On 2018-05-18 13:51, Andrzej Hajda wrote:
>> On 26.04.2018 10:07, Jyri
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #30 from Matt Arsenault ---
(In reply to Martin Pilarski from comment #27)
> Possibly, but I actually don't know what is meant with "the temp dumps".
The output of RADEON_DEBUG=fs,vs,gs,ps,cs
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #29 from sephirot...@gmail.com ---
Created attachment 139672
--> https://bugs.freedesktop.org/attachment.cgi?id=139672&action=edit
Patch to disable vectorizer
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #3 from wangjingbin ---
Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics
(KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11
-lep
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #28 from sephirot...@gmail.com ---
Thanks Martin for finding the issue!
The vectorizer can be disabled from Mesa side, so it's not needed to recompile
LLVM...
See the attached patch.
I tested it with Debian LLVM 7 and Mesa git and w
https://bugs.freedesktop.org/show_bug.cgi?id=106601
wangjingbin changed:
What|Removed |Added
Summary|The internal format RGB32F |The internal format RGB32F
https://bugs.freedesktop.org/show_bug.cgi?id=106601
wangjingbin changed:
What|Removed |Added
Summary|angle_end2end_test |The internal format RGB32F
https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #2 from wangjingbin ---
Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics
(KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11
-lep
https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #1 from wangjingbin ---
Produce steps:
1. Attached file is the C source code;
2. Build the source file(I built it on Ubuntu 17.04, Intel® HD Graphics
(KabyLake 3x8 GT2)), "gcc -o copySubImageFloatRGB copySubImageFloatRGB.c -lX11
-lep
On 05/22/2018 12:31 AM, Dongwon Kim wrote:
Still need more time to review the whole code changes
Take your time, I just wanted to make sure that all interested parties
are in the discussion, so we all finally have what we all want, not
a thing covering only my use-cases
but I noticed one thin
On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:
On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:
On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
On 05/21/2018 01:40 AM, Oleksandr Andrushc
https://bugs.freedesktop.org/show_bug.cgi?id=106601
Bug ID: 106601
Summary: angle_end2end_test
Texture2DTest.CopySubImageFloat_RGB_RGB/ES2_OPENGL
fails
Product: Mesa
Version: 17.1
Hardware: x86-64 (AMD64
/commits/Jernej-Skrabec/Add-support-for-R40-HDMI-pipeline/20180521-131839
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
On Tue, May 22, 2018 at 3:51 AM, Eric Anholt wrote:
> Qiang Yu writes:
>
>> Signed-off-by: Qiang Yu
>> ---
>> include/uapi/drm/lima_drm.h | 195
>> 1 file changed, 195 insertions(+)
>> create mode 100644 include/uapi/drm/lima_drm.h
>>
>> diff --git a/includ
Add authors and description in Kconfig.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/Kconfig | 8 ++--
drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0893b1d8ede7..a
This commit appends the essential CRTCs infrastructure for VKMS. CRTCs
demands other elements to work correctly, in this sense, this patch adds
a new data struct that centralizes the data structures related to the
output, simple planes management, and single encoder attached to the
connector.
Sign
On Tue, May 22, 2018 at 3:37 AM, Eric Anholt wrote:
> Qiang Yu writes:
>
>> This reverts commit 45c3d213a400c952ab7119f394c5293bb6877e6b.
>>
>> lima driver need preclose to wait all task in the context
>> created within closing file to finish before free all the
>> buffer object. Otherwise pendin
This series of patches add a centralized initialization mechanism, a
single CRTC with a plane, an encoder, and extra module information.
Changes in v2:
- Remove unused definitions
- Improve file names
- Improve code separation
- Remove unnecessary formats
Changes in v3:
- Adds drm_crtc_help
Set a frame buffer default size for width and height (minimum and
maximum).
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_drv.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 35517b095
Sorry I missed this, just fell between the cracks,
Any reason you can't/don't use git pull-request to generate pulls? we
have some scripts that parse pulls for tracking now, but this pull
didn't get into the system as it doesn't use the template.
Dave.
On 18 May 2018 at 02:06, Russell King wrot
Hi Neil,
OK, I'll resend these patches.
Regards,
Qiang
On Mon, May 21, 2018 at 10:16 PM, Neil Armstrong
wrote:
> Hi Yuq,
>
> On 18/05/2018 11:27, Qiang Yu wrote:
>> Meson mali GPU operate in high clock frequency, need
>> this value be high to work in a stable state.
>>
>> Signed-off-by: Qiang Y
---
drivers/gpu/drm/drm_agpsupport.c | 43
include/drm/drm_agpsupport.h | 14 ---
2 files changed, 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 737f0288..9000f0c4 100644
--- a/drivers/gpu/drm/dr
In drm_dp_i2c_drain_msg we do msg.buffer += err which isn't
legal for void *.
---
include/drm/drm_dp_helper.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 62903bae..06f9a61f 100644
--- a/include/drm/drm_dp_helpe
The change adds support for Sharp LQ035Q7DB03 3.5" QVGA panel.
Note that this aged panel is already found in the kernel sources,
for instance in board mach files mach-mx21ads.c, mach-mx27ads.c,
mach-pcm043.c, lpd270.c and imx27-phytec-phycore-rdk.dts.
Signed-off-by: Vladimir Zapolskiy
---
.../b
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #7 from Alex Deucher ---
see also: https://bugzilla.kernel.org/show_bug.cgi?id=199693
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
d
On Mon, May 21, 2018 at 2:58 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used intead of open coded variant.
https://patchwork.kernel.org/patch/10382377/
> Cc: Gustavo Padovan
> Cc: Maarten Lankhorst
> Cc: Sean Paul
> Cc: David Ai
On Mon, May 21, 2018 at 2:57 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used intead of open coded variant.
https://patchwork.kernel.org/patch/10382323/
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: David Airli
On Mon, May 21, 2018 at 2:57 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used intead of open coded variant.
> if (nouveau_tv_norm) {
> + i = match_string(nv17_tv_norm_names,
> +n
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #6 from Lukas Wunner ---
Ah, never mind, the 4.17 output was attached by Thomas Martitz. So without 4.17
dmesg output of your machine it's pretty hard to tell what's going on.
--
You are receiving this mail because:
You are the ass
On Mon, May 21, 2018 at 2:57 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used intead of open coded variant.
https://patchwork.kernel.org/patch/10378815/
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Arvind Yadav
> Cc: dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #5 from Lukas Wunner ---
Ok I found this dmesg ouput of a 4.17 kernel...
https://bugs.freedesktop.org/attachment.cgi?id=139668
However the HDA device :01:00.1 is not enumerated! It *is* enumerated in
the 4.16 dmesg output you've
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #4 from Lukas Wunner ---
What does the following show?
cat /sys/bus/pci/devices/:01:00.0/power/runtime_status# GPU
cat /sys/bus/pci/devices/:01:00.0/power/runtime_usage # GPU
cat /sys/bus/pci/devices/:01:
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #12 from Thomas Martitz ---
Created attachment 139668
--> https://bugs.freedesktop.org/attachment.cgi?id=139668&action=edit
dmesg after resume
I still get the backtrace on drm-next-4.18-wip, unfortunately.
(note that I have also
Still need more time to review the whole code changes but I noticed one thing.
We've been using the term "hyper_dmabuf" for hypervisor-agnostic linux dmabuf
solution and we are planning to call any of our future solution for other
hypervisors the same name. So having same name for this xen-specifi
https://bugs.freedesktop.org/show_bug.cgi?id=106441
--- Comment #3 from Richard B. Kreckel ---
(In reply to kaspar.tint from comment #2)
> Can verify that this issue has resolved it self for me after the upgrade of
> these components:
>
> gnome -> 3.28.1
> mesa -> 18.0.3
> linux -> 4.16.9
> xorg
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #3 from Lukas Wunner ---
Pretty sure there's an issue with the HDA controller on the GPU that prevents
the GPU from suspending. Can you attach dmesg output of a drm-next-4.18-wip
kernel? There's dmesg output in the bug you've linked
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: Haneen Mohammed
commit 7f6df440b8623c441c42d070bf592e2d2c1fa9bb upstream.
This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_li
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Haneen Mohammed
commit 7f6df440b8623c441c42d070bf592e2d2c1fa9bb upstream.
This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_li
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #2 from taij...@posteo.de ---
Yeah, I tried that, but unfortunately that did not work.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
d
https://bugs.freedesktop.org/show_bug.cgi?id=106597
--- Comment #1 from Alex Deucher ---
Does reverting the ATPX quirk from bug 105760 also fix the issue? I wonder if
Lukas' patch fixed the underlying issue and the ATPX workaround is no longer
necessary.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=106597
Bug ID: 106597
Summary: [vga_switcheroo] commit
07f4f97d7b4bf325d9f558c5b58230387e4e57e0 breaks dpm on
Alienware 15R3
Product: DRI
Version: DRI git
Har
https://bugs.freedesktop.org/show_bug.cgi?id=106402
taij...@posteo.de changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105760
taij...@posteo.de changed:
What|Removed |Added
CC||ratch...@gmail.com
--- Comment #11 f
https://bugs.freedesktop.org/show_bug.cgi?id=106402
--- Comment #5 from taij...@posteo.de ---
Also, this is a duplicate of Bug 105760 which is fixed in the current
drm-next-4.18-wip.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106402
--- Comment #4 from taij...@posteo.de ---
to get a kernel log from a previous boot attempt, try something like:
journalctl -kb -1 > error.log
where -1 would be the previous boot, -2 the one before that, etc.
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #10 from taij...@posteo.de ---
This seems to be fixed an the current drm-next-4.18-wip branch.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailin
Qiang Yu writes:
> Signed-off-by: Qiang Yu
> ---
> include/uapi/drm/lima_drm.h | 195
> 1 file changed, 195 insertions(+)
> create mode 100644 include/uapi/drm/lima_drm.h
>
> diff --git a/include/uapi/drm/lima_drm.h b/include/uapi/drm/lima_drm.h
> new file
Qiang Yu writes:
> This reverts commit 45c3d213a400c952ab7119f394c5293bb6877e6b.
>
> lima driver need preclose to wait all task in the context
> created within closing file to finish before free all the
> buffer object. Otherwise pending tesk may fail and get
> noisy MMU fault message.
>
> Move t
Liviu Dudau writes:
> From: Brian Starkey
>
> Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
> enable userspace to get a fence which will signal once the writeback is
> complete. It is not allowed to request an out-fence without a
> framebuffer attached to the connector.
>
https://bugs.freedesktop.org/show_bug.cgi?id=106589
--- Comment #7 from Sylvain BERTRAND ---
I provide the logs since it happened today with the latest code.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailin
https://bugs.freedesktop.org/show_bug.cgi?id=106589
--- Comment #6 from Sylvain BERTRAND ---
Created attachment 139665
--> https://bugs.freedesktop.org/attachment.cgi?id=139665&action=edit
kernel log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106589
--- Comment #5 from Sylvain BERTRAND ---
Created attachment 139664
--> https://bugs.freedesktop.org/attachment.cgi?id=139664&action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #5 from Thomas R. ---
Hm. Well the current state of this machine is: I got an old working AMD DC
kernel (4.11) that is starting to give me trouble, and nothing current that
works. I'd be willing to bisect from there to current, but t
Stefan Wahren writes:
> Hi,
> in order to improve kernelci.org results and avoid false positive cases like
> this [1], i suggested to also test for a working VC4 driver. In order to keep
> it simple, we should do it from userspace.
>
> My first idea was:
>
> test -d /sys/kernel/debug/dri/0 || e
https://bugs.freedesktop.org/show_bug.cgi?id=105500
--- Comment #5 from Balázs Vinarz ---
GCN2 based APUs are not affected with none AMDGPU or Radeon kernel modules.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
Dan Carpenter writes:
> The v3d_fence_create() only returns error pointers on error. It never
> returns NULL.
>
> Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
> V3.x+")
> Signed-off-by: Dan Carpenter
Pushed to drm-misc-next. Thanks!
signature.asc
Description:
On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:
On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
A commit message would be useful.
Sure, v1 will have it
https://bugs.freedesktop.org/show_bug.cgi?id=101262
--- Comment #6 from Mariusz Ceier ---
That bug is due to missing /usr/bin/lspci. Dying Light tries to execve
/usr/bin/lspci in a fork and when it fails it calls exit function instead of
_exit.
exit calls exit handler registered by mesa which ca
https://bugs.freedesktop.org/show_bug.cgi?id=106594
--- Comment #2 from Kai ---
Created attachment 139662
--> https://bugs.freedesktop.org/attachment.cgi?id=139662&action=edit
Game output to STDOUT and STDERR
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106594
--- Comment #1 from Kai ---
Created attachment 139661
--> https://bugs.freedesktop.org/attachment.cgi?id=139661&action=edit
Glitch while placing new staff on the map
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106594
Bug ID: 106594
Summary: [radeonsi,regression,apitrace] Prison Architect
exhibits glitches
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (Al
https://bugs.freedesktop.org/show_bug.cgi?id=104920
--- Comment #7 from gr...@sub.red ---
NOTABUG?
IMHO, it's a documentation issue, *at least*. Please add the info to
https://wiki.freedesktop.org/xorg/RadeonFeature/ or somewhere else.
Also, why is it possible to use radeonsi/vaapi for encoding
Hi Lin,
2018-05-21 11:37 GMT+02:00 Lin Huang :
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if s
On Mon, May 21, 2018 at 01:17:04AM +0800, Randy Li wrote:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li
https://bugs.freedesktop.org/show_bug.cgi?id=106499
--- Comment #3 from Bas Nieuwenhuizen ---
This should be fixed with
https://patchwork.freedesktop.org/patch/224584/
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-d
bc61c97502e2 moved the gtt_range structure, from being in
psb_framebuffer and embedding the GEM object, to being placed in the
drm_framebuffer with the gtt_range being derived from the GEM object.
The conversion missed out the Medfield subdriver, which was not being
built in the default drm-misc c
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at lea
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
Hi All,
The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device reg
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address
Hi Yuq,
On 18/05/2018 11:27, Qiang Yu wrote:
> Meson mali GPU operate in high clock frequency, need
> this value be high to work in a stable state.
>
> Signed-off-by: Qiang Yu
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/
Hi Yuq,
On 18/05/2018 11:27, Qiang Yu wrote:
> From: Andrei Paulau <7134...@gmail.com>
>
> Meson mali GPU operate in high clock frequency, need
> this value be high to work in a stable state.
>
> Signed-off-by: Andrei Paulau <7134...@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb.dts
Hi Lin,
2018-05-21 11:37 GMT+02:00 Lin Huang :
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Lin Huang
> ---
> C
On Friday, 2018-05-18 12:48:17 -0700, Kevin Strasser wrote:
> removed in commit bb45ce4e3ac751315bfd7fbfd9e1425bf515ec0d
>
> Adding it back as it is still needed in the case where we don't find a
> match.
>
> Signed-off-by: Kevin Strasser
Good catch, thanks!
Fixes: bb45ce4e3ac751315bfd "libdrm
Hi Lin,
2018-05-21 11:37 GMT+02:00 Lin Huang :
> we may use rockchip_phy_typec struct in other driver, so split
> it to separate header.
>
That patch does more than just split some structs to a public header,
it also introduces new structs and new parameters related to the
phy_config feature. IMH
match_string() returns the index of an array for a matching string,
which can be used intead of open coded variant.
Cc: Ben Skeggs
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Yisheng Xie
---
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 1
On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
No Changes.
v4:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 f
https://bugzilla.kernel.org/show_bug.cgi?id=199781
--- Comment #3 from Frédéric Pierret (frederic.epi...@orange.fr) ---
Thank for your answer. Some progress but now freeze with two type of errors:
May 21 14:51:58 dom0 kernel: [ cut here ]
May 21 14:51:58 dom0 kernel: nouve
On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
No Changes.
v4:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
driver
Implements the HDMI adaptation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2:
Rebased.
v3:
No Changes.
v4:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/P
Implements the DP adaptation specific HDCP2.2 functions.
These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.
Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
than completions concept. WIP to understand and implement that,
https://bugzilla.kernel.org/show_bug.cgi?id=199781
--- Comment #2 from Frédéric Pierret (frederic.epi...@orange.fr) ---
Created attachment 276085
--> https://bugzilla.kernel.org/attachment.cgi?id=276085&action=edit
dmesg log with nouveau.runpm=0
dmesg log with nouveau.runpm=0
--
You are recei
On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
integrity check for the HDCP version that is enabled.
v2:
Rebased. Function name is changed.
v3:
No Changes.
v4:
No Changes.
Signed-off-by: Ramalingam C
cc: Sean Paul
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu
GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
enabling the 511Bytes per RD/WR cycle on legacy platforms for no
absolute ROIs, this change allows the max bytes per op upto 511Bytes
from Gen9 onwards.
v2:
No Change.
v3:
Inline function for max_xfer_size and renaming of
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
v2:
Included few optimization suggestions [Chris Wilson]
Commit message is updated as per the rebased version.
v3:
No changes.
v4:
Extra comment added and Style issue f
HDCP check link is invoked only on CP_IRQ detection, instead of all
short pulses.
v3:
No Changes.
v4:
Added sean in cc and collected the reviewed-by received.
Signed-off-by: Ramalingam C
cc: Sean Paul
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c | 9 -
1 file chang
As a preparation for making the intel_hdcp_enable as common function
for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved
into _intel_hdcp_enable() function.
v3:
No Changes.
v4:
Style fix.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_h
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
v2:
Rebased.
v3:
No Changes.
v4:
Reviewed-by is collected.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required notifier registration.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out
For reusability purpose, this patch implements the hdcp1.4 bksv's
read and validation as a functions.
For detecting the HDMI panel's HDCP capability this fucntions will be
used.
v2:
Rebased.
v3:
No Changes.
v4:
inline tag is removed with modified error msg.
Signed-off-by: Ramalingam C
---
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2:
Rebased.
v3:
No Changes.
v4:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the H
Implements the enable and disable functions for HDCP2.2 encryption
of the PORT.
v2:
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
No Changes.
v4:
Debug msg is added for timeout at Disable of Encryption [Uma]
%s/HDCP2_CTL/HDCP2_CTL
Signed-off-by: Ramalingam C
---
Implements a sequence of enabling and disabling the HDCP2.2
(auth and encryption).
v2:
Rebased.
v3:
No Changes.
v4:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/dr
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone without disabling the hdcp
encryption. If that fails then complete reauthentication is executed.
v2:
Rebased.
v3:
No Changes.
v4:
Typo in commit msg is fixed [Uma]
Signed-off-by: Ramalingam C
For upcoming implementation of HDCP2.2 in I915, important variable
required for HDCP2.2 are defined.
HDCP_shim is extended to support encoder specific HDCP2.2 flows.
v2:
1.4 shim is extended to support hdcp2.2. [Sean Paul]
platform's/panel's hdcp ver capability is removed. [Sean Paul]
mei r
1 - 100 of 287 matches
Mail list logo
