On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding wrote:
>
> On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
and does not require tests to be written in userspace
Add core facilities for defining unit tests; this provides a common way
to define test cases, functions that execute code which is under test
and determine whether the code under test behaves as expected; this also
provides a way to group together related test cases in test suites (here
we call
A number of test features need to do pretty complicated string printing
where it may not be possible to rely on a single preallocated string
with parameters.
So provide a library for constructing the string as you go similar to
C++'s std::string.
Signed-off-by: Brendan Higgins
---
Changes Since
On Tue, Feb 5, 2019 at 8:36 AM Daniel Vetter wrote:
>
> On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote:
> > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at
On Fri, 15 Feb 2019 at 1:15 AM, Rob Herring wrote:
> On Thu, Feb 14, 2019 at 9:27 AM Rob Clark wrote:
> >
> > I mean, I guess it should be possible with an ugly non-upstreamable
> > hack, maybe using a notifier_chain to call from the temp sensor driver
> > to the hdmi bridge driver. I'm not
Now the driver has been converted to a platform driver, the legacy
printk() calls without any log level can be replaced by proper dev_*()
calls.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/atafb.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
On Falcon, Atari frame buffer initialization relies on preprogrammed
register values. These register values are changed to blank the
console.
Hence when using kexec to boot into a new kernel while the console is
blanked, the new kernel cannot determine the current video
configuration, and the
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.
v2:
wait for cp_irq is merged with this patch. Rebased.
v3:
wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
Style
Hi,
Using libdrm-2.4.97, mesa fails to build on ARM with:
[ 456s] In file included from
../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
[ 456s] from
../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34,
[ 456s] from
From: Priit Laes
[ Upstream commit 5e1bc251cebc84b41b8eb5d2434e54d939a85430 ]
Although TMDS clock is required for HDMI to properly function,
nobody called clk_prepare_enable(). This fixes reference counting
issues and makes sure clock is running when it needs to be running.
Due to TDMS clock
From: "Kristian H. Kristensen"
[ Upstream commit 99c66bc051e7407fe0bf0607b142ec0be1a1d1dd ]
Prevents deadlock when fifo is full and reader closes file.
Signed-off-by: Kristian H. Kristensen
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_rd.c | 7 ++-
1
https://bugs.freedesktop.org/show_bug.cgi?id=97055
--- Comment #23 from AlyssaPatterson ---
Read carefully entire description and tried to understand what exactly issue
you faced during using the amdgpu driver on HP Pavilion 17-g133cl with A10
Carrizo+Topaz and solutions provided by the experts
From: Arnd Bergmann
[ Upstream commit a840f690d3c6f2f27425ca7e7bd2d635cdec07d7 ]
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:368:13: error:
'dpu_plane_danger_signal_ctrl' defined but not used [-Werror=unused-function]
Fixes: 7b2e7adea732 ("drm/msm/dpu: Make dpu_plane_danger_signal_ctrl void")
Printing (hashed) virtual addresses is useless.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/atafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index fcd2dd670a658fe3..e9d31a4299ee9901 100644
---
CONFIG_FB_ATARI is bool, hence the Atari frame buffer driver cannot be
built as a module. In addition, the module support code refers to a
function atafb_deinit(), which never existed.
Replace module_init() by device_initcall().
Signed-off-by: Geert Uytterhoeven
---
Hi all,
This patch series fixes the frame buffer on Atari Falcon when using
kexec while blanked, and does some miscellaneous cleanups.
This has been tested on ARAnyM.
Thanks!
Geert Uytterhoeven (4):
fbdev: atafb: Stop printing virtual screen_base
fbdev: atafb: Remove obsolete
On Fri, Feb 15, 2019 at 11:17:53AM +0100, Philipp Zabel wrote:
> Hi Daniel,
>
> On Thu, 2019-02-14 at 21:20 +0100, Daniel Vetter wrote:
> > On Thu, Feb 14, 2019 at 03:50:57PM +0100, Daniel Vetter wrote:
> > > On Thu, Feb 14, 2019 at 03:19:18PM +0100, Philipp Zabel wrote:
> > > > Hi Daniel,
> > >
On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
wrote:
>
> On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom
> wrote:
> >
> > On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> > > On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> > > > On Fri, Feb 15, 2019 at 3:55 AM
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v4.20.8, v4.19.21, v4.14.99, v4.9.156,
v4.4.174, v3.18.134.
v4.20.8: Build OK!
On Fri, Feb 15, 2019 at 11:07:22AM -0500, Michael Labriola wrote:
> On Fri, Feb 15, 2019 at 12:57 AM Juergen Gross wrote:
> >
> > On 14/02/2019 18:57, Christoph Hellwig wrote:
> > > On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote:
> > >>> The thing which is different between Xen PV
Am 15.02.19 um 16:52 schrieb Lionel Landwerlin:
On 15/02/2019 14:32, Koenig, Christian wrote:
Am 15.02.19 um 15:23 schrieb Lionel Landwerlin:
Hi Christian, David,
For timeline semaphore we need points to signaled in order.
I'm struggling to understand how this fence-chain implementation
The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.
Signed-off-by: Peter Ujfalusi
---
This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
1920x1200 panel from One Stop Displays.
Signed-off-by: Peter Ujfalusi
---
.../bindings/display/panel/osd,osd101t2045-53ts.txt | 11 +++
1 file changed, 11 insertions(+)
create mode 100644
This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
1920x1200 panel from One Stop Displays.
Note: the panel is similar to OSD101T2045-53TS, but it needs additional
MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
Signed-off-by: Peter Ujfalusi
---
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
>
[snip]
> Some thoughts, as this ABI break has the potential to be pretty painful.
>
> 1) Unfortunately, this ABI is exposed *through* libion via
> ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
>
Hi Daniel,
On Thu, 2019-02-14 at 21:20 +0100, Daniel Vetter wrote:
> On Thu, Feb 14, 2019 at 03:50:57PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 14, 2019 at 03:19:18PM +0100, Philipp Zabel wrote:
> > > Hi Daniel,
> > >
> > > On Thu, 2019-02-14 at 14:06 +0100, Daniel Vetter wrote:
> > > > On
https://bugs.freedesktop.org/show_bug.cgi?id=100979
Przemek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Adding dri-devel.
On Thu, Feb 14, 2019 at 2:53 AM Emily Deng wrote:
>
> For multiple GPUs which has the same BDF, but has different domain ID,
> the drmOpenByBusid will return the wrong fd when startx.
>
> The reproduce sequence as below:
> 1. Call drmOpenByBusid to open Card0, then will return
On Fri, Feb 15, 2019 at 9:52 AM Lionel Landwerlin via dri-devel <
dri-devel@lists.freedesktop.org> wrote:
> On 15/02/2019 14:32, Koenig, Christian wrote:
> > Am 15.02.19 um 15:23 schrieb Lionel Landwerlin:
> >> Hi Christian, David,
> >>
> >> For timeline semaphore we need points to signaled in
https://bugs.freedesktop.org/show_bug.cgi?id=109085
--- Comment #4 from Octavio Paez ---
(In reply to Łukasz Skocz from comment #1)
> Created attachment 142846 [details]
> another dmesg output
Hey Lukasz!
Have you found any solution to this issue?
Does your lspci -v looks similar to mine?
Mine
Hi,
On 2/7/19 9:59 AM, Thomas Zimmermann wrote:
Almost all TTM-based drivers use the same values for the mmap-able
range of BO addresses. Each driver therefore duplicates the
DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not
configurable by drivers.
This patch set replaces
On 15/02/2019 14:32, Koenig, Christian wrote:
Am 15.02.19 um 15:23 schrieb Lionel Landwerlin:
Hi Christian, David,
For timeline semaphore we need points to signaled in order.
I'm struggling to understand how this fence-chain implementation
preserves ordering of the seqnos.
One of the scenario
On Thu, Feb 14, 2019 at 06:16:01PM -0500, Rob Clark wrote:
> On Thu, Feb 14, 2019 at 2:19 AM Dan Carpenter
> wrote:
> >
> > The copy_to/from_user() functions return the number of bytes remaining
> > to be copied but we should return -EFAULT to the user.
> >
> > Fixes: f05c83e77460 ("drm/msm: add
On Fri, Feb 15, 2019 at 11:08 AM Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in some cases, the code comment is modified
> in
On Fri, Feb 15, 2019 at 10:25:03AM -0200, Helen Koike wrote:
> Hello,
>
> The legacy_cursor_update flag in the drm_atomic_state struct was being
> used to track if the update was asyncronous or not for the cursor plane.
> Which is really similar to what the async_update flag do, so I was
> trying
The function intel_compute_rc_parameters is part of the dsc spec
and is not driver-specific. Other drm drivers might like to use
it. The function is not changed; just moved and renamed.
Reviewed-by: Harry Wentland
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dsc.c | 135
drm_dsc could use some work so that drm drivers other than
i915 can make use of it their own DSC implementations
Move rc compute, a function that forms part of the DSC spec,
into drm. Update it to DSC 1.2. Also split the PPS packing and
SDP header init functions, to allow for drivers with
their
The DP 1.4 spec defines the SDP header and SDP contents for
a Picture Parameter Set (PPS) that must be sent in advance
of DSC transmission to define the encoding characteristics.
This was done in one struct, drm_dsc_pps_infoframe, which
conatined the SDP header and PPS. Because the PPS is
a
On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom wrote:
>
> On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> > On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> > > On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake wrote:
> > > >
> > > > Hi,
> > > >
> > > > Using libdrm-2.4.97, mesa
[Shouldn't send mails before coffee kicks in, some things got lost below]
On Fri, Feb 15, 2019 at 10:20 AM Daniel Vetter wrote:
>
> On Thu, Feb 14, 2019 at 05:47:06PM -0500, Rob Clark wrote:
> > On Thu, Feb 14, 2019 at 4:00 AM Daniel Vetter
> > wrote:
> > >
> > > Clear rules avoid arguing.
> >
On 15/02/2019 10:13, Jyri Sarha wrote:
> Calling drm_fbdev_cma_fini() after drm_dev_unregister() started to
> cause a crash when unloading tilcdc some time between 4.14 and
> 4.19. Instead of changing the unload order it looks like using
> drm_fbdev_generic_setup() is the direction to go.
>
>
On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake wrote:
> >
> > Hi,
> >
> > Using libdrm-2.4.97, mesa fails to build on ARM with:
> >
> > [ 456s] In file included from
> > ../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
> > [
Hi David,
Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9
On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard,
wrote:
> On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > Here is a series implementing the burst mode support for DSI.
> >
> > It's been tested on an A33 board with the panel supported on the last
> > patch, which should
Am 15.02.19 um 15:23 schrieb Lionel Landwerlin:
> Hi Christian, David,
>
> For timeline semaphore we need points to signaled in order.
> I'm struggling to understand how this fence-chain implementation
> preserves ordering of the seqnos.
>
> One of the scenario I can see an issue happening is
On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> On Friday, 2019-02-15 07:11:55 -0500, Rob Clark wrote:
> > On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake wrote:
> > >
> > > Hi,
> > >
> > > Using libdrm-2.4.97, mesa fails to build on ARM with:
> > >
> > > [ 456s] In file included from
On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> Hi,
>
> Here is a series implementing the burst mode support for DSI.
>
> It's been tested on an A33 board with the panel supported on the last
> patch, which should remove all quirks due to a different SoC from the
> equation.
I
On Fri, Feb 15, 2019 at 3:55 AM Daniel Drake wrote:
>
> Hi,
>
> Using libdrm-2.4.97, mesa fails to build on ARM with:
>
> [ 456s] In file included from
> ../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
> [ 456s] from
>
On Fri, Feb 15, 2019 at 09:48:47AM +0800, Qiang Yu wrote:
> On Thu, Feb 14, 2019 at 11:27 PM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Wed, Feb 06, 2019 at 09:14:56PM +0800, Qiang Yu wrote:
> > > Signed-off-by: Qiang Yu
> > > ---
> > > include/uapi/drm/drm_fourcc.h | 9 +
> > > 1 file
On Thu, Feb 14, 2019 at 05:47:06PM -0500, Rob Clark wrote:
> On Thu, Feb 14, 2019 at 4:00 AM Daniel Vetter wrote:
> >
> > Clear rules avoid arguing.
> >
> > I think it'd be good to have an equally solid list on the kms side.
> > But kms is much more meant to be a standard, and the list of
Add support for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop
Displays to the panel-simple driver
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/panel/panel-simple.c | 34
1 file changed, 34 insertions(+)
diff --git
Hi Christian, David,
For timeline semaphore we need points to signaled in order.
I'm struggling to understand how this fence-chain implementation
preserves ordering of the seqnos.
One of the scenario I can see an issue happening is when you have a
timeline with points 1 & 2 and userspace
On 15/02/2019 10:13, Jyri Sarha wrote:
> Most of the struct tilcdc_panel_info data members, that are also
> exposed in dts binding, are essentially display IP register bits that
> should not need customization per connected display basis. This patch
> removes them, both from the binding and the
Hi,
Add support for OSD101T2045-53TS and OSD101T2587-53TS from One Stop Displays.
The two panel is similar with one big difference: OSD101T2587-53TS requires the
MIPI_DSI_TURN_ON_PERIPHERAL message, thus can not be handled by panel-simple.
Regards,
Peter
---
Peter Ujfalusi (4):
dt-bindings:
Hi,
I have added (most of) you to Cc: because I think you have either
recently or significantly touched zpos property code. Could I ask
for a review or ack of this patch from zpos point of view?
If you have tested this patch, a Tested-by: would be appreciated
as well.
regards
Philipp
On Mon,
https://bugs.freedesktop.org/show_bug.cgi?id=109017
--- Comment #8 from Alex Deucher ---
Please attach your dmesg output and xorg log with amdgpu.dc=1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hi Simon,
On Wed, Jan 23, 2019 at 11:03:04AM +0100, Simon Horman wrote:
> On Wed, Jan 23, 2019 at 11:55:52AM +0200, Laurent Pinchart wrote:
> > On Wed, Jan 23, 2019 at 09:56:57AM +0100, Simon Horman wrote:
> >> On Wed, Jan 23, 2019 at 12:54:04AM +0200, Laurent Pinchart wrote:
> >>> The LVDS1
Hello,
The legacy_cursor_update flag in the drm_atomic_state struct was being
used to track if the update was asyncronous or not for the cursor plane.
Which is really similar to what the async_update flag do, so I was
trying to get rid of the legacy_cursor_update flag (just for cleanup).
So I
On Tue, 2019-02-12 at 13:29 +, Colin King wrote:
> From: Colin Ian King
>
> There are a couple of statements that are indented too deeply, fix
> this by removing tabs. Also add a space after a comma to clean up
> a cppcheck warning.
>
> Signed-off-by: Colin Ian King
> ---
>
On 15.02.2019 06:09, Vasily Khoruzhick wrote:
> From: Icenowy Zheng
>
> The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
> for portable devices. This driver adds initial support for RGB to eDP
> mode, without HPD and interrupts.
>
> This is a configuration usually seen in
This is an RFC. I'm not sure this is the right solution, but it
highlights the problem I'm trying to solve.
The dma32_zone limits the acc_size of all allocated BOs to 2GB. On a
64-bit system with hundreds of GB of system memory and GPU memory,
this can become a bottle neck. We're seeing TTM
https://bugs.freedesktop.org/show_bug.cgi?id=109649
Bug ID: 109649
Summary: [raven] gfx ring timeout when running clover apps
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
YueHaibing writes:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vc4/vc4_txp.c: In function 'vc4_txp_connector_atomic_check':
> drivers/gpu/drm/vc4/vc4_txp.c:252:29: warning:
> variable 'gem' set but not used [-Wunused-but-set-variable]
> struct drm_gem_cma_object *gem;
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190215]
[cannot apply to v5.0-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
https://bugs.freedesktop.org/show_bug.cgi?id=109650
Bug ID: 109650
Summary: [amd-staging-drm-next] - Polaris 20 dc - idle power
regession 3x [bisected]
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
port in hdcp_port data is equipped to handle -ve values.
v3:
mei comp is matched for global i915 comp
From: Tomas Winkler
Export to_mei_cl_device macro, it is needed also in mei client drivers.
Signed-off-by: Tomas Winkler
Signed-off-by: Ramalingam C
---
drivers/misc/mei/bus.c | 1 -
include/linux/mei_cl_bus.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
On Fri, Feb 15, 2019 at 02:04:57PM +0530, Ramalingam C wrote:
> For the reusability of the enum port in other driver modules
> (like mei_hdcp), enum port definition is moved from I915 local header
> intel_display.h to drm/i915_drm.h
>
> Signed-off-by: Ramalingam C
> Acked-by: Daniel Vetter
Quoting Brendan Higgins (2019-02-14 13:37:22)
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> index 0b4ad6690310d..bb34431398526 100644
> --- a/kunit/test-test.c
> +++ b/kunit/test-test.c
[...]
> +
> +#define KUNIT_RESOURCE_NUM 5
> +static void kunit_resource_test_cleanup_resources(struct
On 2/15/19 1:58 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 11:22 AM Andrew F. Davis wrote:
>>
>> On 2/15/19 1:01 PM, John Stultz wrote:
>>> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
> 2) For patches that cause
On Fri, Feb 15, 2019 at 02:05:00PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is
Requests for the verification of AKE_Send_H_prime.
ME will calculate the H and comparing it with received H_Prime.
The result will be returned as status.
Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and
Time period for HDCP2.2 link check.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
Reviewed-by: Uma Shankar
---
include/drm/drm_hdcp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 7260b31af276..d4e98b11b4aa 100644
---
Am 15.02.19 um 19:16 schrieb Jason Ekstrand:
On Fri, Feb 15, 2019 at 11:51 AM Christian König
mailto:ckoenig.leichtzumer...@gmail.com>>
wrote:
Am 15.02.19 um 17:49 schrieb Jason Ekstrand:
On Fri, Feb 15, 2019 at 9:52 AM Lionel Landwerlin via dri-devel
mailto:dri-devel@lists.freedesktop.org>>
On Fri, Feb 15, 2019 at 12:33 PM Koenig, Christian
wrote:
> Am 15.02.19 um 19:16 schrieb Jason Ekstrand:
>
> On Fri, Feb 15, 2019 at 11:51 AM Christian König <
> ckoenig.leichtzumer...@gmail.com> wrote:
>
>> Am 15.02.19 um 17:49 schrieb Jason Ekstrand:
>>
>> On Fri, Feb 15, 2019 at 9:52 AM
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.
At AKE, the HDCP Receiver’s public key
https://bugs.freedesktop.org/show_bug.cgi?id=109085
--- Comment #5 from Łukasz Skocz ---
> Have you found any solution to this issue?
I have not. I managed to improve the stability somewhat by adding
"radeon.msi=0" to the kernel line, now it only crashes on Citra and nothing
else (or maybe it's
On Fri, Feb 15, 2019 at 11:22 AM Andrew F. Davis wrote:
>
> On 2/15/19 1:01 PM, John Stultz wrote:
> > On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
> >> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
> >>> 2) For patches that cause ABI breaks, it might be good to make it
>
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 more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/PAIRING
v4:
msg_sz
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
Signed-off-by: Tomas Winkler
Signed-off-by: Ramalingam C
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c
Provides Pairing info to ME to store.
Pairing is a process to fast track the subsequent authentication
with the same HDCP sink.
On Success, received HDCP pairing info is stored in non-volatile
memory of ME.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
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 of mem [Uma]
Inline req for init function removed
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:
Typo in commit msg is fixed [Uma]
v4:
Rebased as part of patch reordering.
On Fri, Feb 15, 2019 at 11:01 AM Jordan Crouse wrote:
>
> On Thu, Feb 14, 2019 at 06:16:01PM -0500, Rob Clark wrote:
> > On Thu, Feb 14, 2019 at 2:19 AM Dan Carpenter
> > wrote:
> > >
> > > The copy_to/from_user() functions return the number of bytes remaining
> > > to be copied but we should
Hi Peter.
Good with more panel drivers.
Some comments in the following, please do not blindly follow them but
check that this is OK.
Sam
On Fri, Feb 15, 2019 at 04:03:15PM +0200, Peter Ujfalusi via dri-devel wrote:
> The panel is similar to OSD101T2045-53TS (which is handled by
Mei hdcp driver is designed as component slave for the I915 component
master.
v2: Rebased.
v3:
Notifier chain is adopted for cldev state update [Tomas]
v4:
Made static dummy functions as inline in mei_hdcp.h
API for polling client device status
IS_ENABLED used in header, for config status
This series enables the HDCP2.2 Type 0 for I915. The sequence for
HDCP2.2 authentication and encryption is implemented as a generic flow
between HDMI and DP. Encoder specific implementations are moved
into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client
Request ME to verify the downstream topology information received.
ME FW will validate the Repeaters receiver id list and
downstream topology.
On Success ME FW will provide the Least Significant
128bits of VPrime, which forms the repeater ack.
v2: Rebased.
v3:
cldev is passed as first
Request to ME to configure a port as authenticated.
On Success, ME FW will mark the port as authenticated and provides
HDCP cipher with the encryption keys.
Enabling the Authentication can be requested once all stages of
HDCP2.2 authentication is completed by interacting with ME FW.
Only after
On Fri, Feb 15, 2019 at 11:51 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 15.02.19 um 17:49 schrieb Jason Ekstrand:
>
> On Fri, Feb 15, 2019 at 9:52 AM Lionel Landwerlin via dri-devel <
> dri-devel@lists.freedesktop.org> wrote:
>
>> On 15/02/2019 14:32, Koenig, Christian
https://bugzilla.kernel.org/show_bug.cgi?id=202537
--- Comment #11 from Bernd Steinhauser (li...@bernd-steinhauser.de) ---
Ok, so finally I think I've been able to track this down.
Not 100% sure, because for the final test versions I had to apply a few patches
to fix bugs that otherwise would've
https://bugs.freedesktop.org/show_bug.cgi?id=109648
Michael Eagle changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
One of the issues w/ the /dev/ion interface is that we have to
provide the complexity of a heap query interface and we end up
multiplexing all the heap access through that one interface via
a bit mask (which currently limits the heaps to 32).
There has been a long running todo to provide per-heap
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.0-rc4 next-20190215]
[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
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190215]
[cannot apply to v5.0-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
96 matches
Mail list logo
