Quoting mtk14994 (2019-02-20 18:34:11)
> Dear Stephen,
> > + unsigned char mux_flags;
> >
> > Why isn't it an unsigned long? Isn't this supposed to match the
> > frameworks version of the clk flags?
>
> > it is unsigned char mux_flags ,becasuse struct clk_mux {
>
>
>
> u8
On Thu, Feb 21, 2019 at 02:56:56PM +0100, Maarten Lankhorst wrote:
> Hey
>
> Op 21-02-2019 om 12:14 schreef james qian wang (Arm Technology China):
> > The writeback job will not be added to writeback queue if the state is
> > check only or check failed, to avoid leak, need to cleanup writeback
On Wed, Feb 20, 2019 at 11:40 PM John Stultz wrote:
>
> Here is a very early peek at my dmabuf pools patchset, which
> tries to destage a fair chunk of ION functionality.
>
> This build and boots, but I've not gotten to testing the actual
> pool devices yet (need to write some kselftests)! I just
Gerd Hoffmann (2):
drm: move i915_kick_out_vgacon to vgaarb
drm/qxl: remove conflicting framebuffers earlier
include/drm/drm_fb_helper.h | 14 +++---
include/linux/vgaarb.h | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 43 -
Add error checking while being at it.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index bb81e310eb6d..578d867a81d5 100644
---
Also rename it and call it automatically from
drm_fb_helper_remove_conflicting_pci_framebuffers()
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fb_helper.h | 14 +++---
include/linux/vgaarb.h | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 43
Hi,
> PCI_COMMAND_MEM and PCI_COMMAND_IO. There doesn't seem to be any
> separate bits really. That's at least what I've gleaned from vgaarb.c.
> The magic legacy vga decode bits only seem to exist on bridges, maybe
> we can extract that logic from vgaarb.c (yes this is all a bit
> spiralling
Am 21.02.19 um 22:02 schrieb Thomas Hellstrom:
> Hi,
>
> On Thu, 2019-02-21 at 20:24 +, Kuehling, Felix wrote:
>> On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote:
>>> On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote:
On 2019-02-21 2:59 a.m., Koenig, Christian wrote:
> On x86
The hmm_devmem_add() function doesn't return NULL, it returns error
pointers.
Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Good Morning,
On Thursday, 21 February 2019 22:00:40 CET Li, Sun peng (Leo) wrote:
>
> On 2019-02-20 12:24 a.m., Mathias Fröhlich wrote:
> > Hi,
> >
> > ping?
> > ... to the dc folks?
> >
> > best
> > Mathias
>
> Hi Mathias,
>
> Sorry for the wait, change looks good to me.
>
> Reviewed-by:
On Thu, Feb 21, 2019 at 10:44:06AM -0800, Alistair Francis wrote:
> On Thu, Feb 21, 2019 at 3:52 AM kra...@redhat.com wrote:
> >
> > On Thu, Feb 21, 2019 at 12:33:03AM +, Alistair Francis wrote:
> > > When running RISC-V QEMU with the Bochs device attached via PCIe the
> > > probe of the
Hi Alex,
Please help, thanks.
Best wishes
Emily Deng
>-Original Message-
>From: Alex Deucher
>Sent: Friday, February 22, 2019 12:13 AM
>To: Deng, Emily ; Maling list - DRI developers de...@lists.freedesktop.org>
>Cc: amd-gfx list
>Subject: Re: [PATCH libdrm] libdrm: Fix issue
Hi Gerd,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc4 next-20190221]
[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
Hi Linus,
This contains a single i915 tiled display fix, and a set of amdgpu/radeon fixes.
amdgpu/radeon:
runtime PM fix
bulk moves disable (fix is too large for 5.0)
and a set of display fixes that are all cc'ed stable so we didn't want
to leave them until -next.
Dave.
drm-fixes-2019-02-22:
Hi Gerd,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0-rc4 next-20190221]
[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
Hi YueHaibing,
Thank you for the patch.
On Sat, Feb 16, 2019 at 07:34:59AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/bridge/cdns-dsi.c: In function 'cdns_dsi_bridge_enable':
> drivers/gpu/drm/bridge/cdns-dsi.c:986:6: warning:
> variable 'bpp'
Hi Brian,
On Thu, Feb 21, 2019 at 01:44:56PM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 02:23:10PM +0200, Laurent Pinchart wrote:
> > On Thu, Feb 21, 2019 at 12:19:13PM +, Brian Starkey wrote:
>
> [snip]
>
> >> I used a pre-existing internal tool which does exactly that.
> >
> >
On Thu, Feb 21, 2019 at 08:48:41AM +0530, Souptick Joarder wrote:
> Hi Ira,
>
> On Wed, Feb 20, 2019 at 11:01 AM wrote:
> >
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter to be gup_flags.
> >
> > This patch does not
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #21 from Bjorn Helgaas (bhelg...@google.com) ---
Thanks! Unless somebody has a better idea, I would try building 4.17.19 with
the print options.
Config differences that might conceivably be related:
--- config-4.17.txt
On Thu, 21 Feb 2019 at 13:41, YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/nouveau/nouveau_dmem.c: In function 'nouveau_dmem_free':
> drivers/gpu/drm/nouveau/nouveau_dmem.c:103:22: warning:
> variable 'drm' set but not used [-Wunused-but-set-variable]
Hi Brian,
On Thu, Feb 21, 2019 at 06:12:03PM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 12:32:07PM +0200, Laurent Pinchart wrote:
> > As writeback jobs contain a framebuffer, drivers may need to prepare and
> > cleanup them the same way they can prepare and cleanup framebuffers for
> >
https://bugs.freedesktop.org/show_bug.cgi?id=109534
--- Comment #2 from vanyasm...@gmail.com ---
I've faced with same problem on following configuration:
> $ glxinfo | grep Device
> Device: AMD JUNIPER (DRM 2.50.0 / 4.18.0-15-generic, LLVM 7.0.0) (0x68ba)
> $ glxinfo | grep 'OpenGL version
https://bugzilla.kernel.org/show_bug.cgi?id=202511
Michael A. Leonetti (mikealeone...@gmail.com) changed:
What|Removed |Added
Attachment #281261|0 |1
Hi Brian,
On Thu, Feb 21, 2019 at 04:02:37PM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 12:42:25PM +0200, Laurent Pinchart wrote:
> > On Thu, Feb 21, 2019 at 12:32:05PM +0200, Laurent Pinchart wrote:
> >> The drm_writeback_queue_job() function takes ownership of the passed job
> >> and
The allocation for the clock bulk data does a classic sizeof(pointer)
instead of sizeof(struct) so the array ends up incorrectly sized
for the clock data.
Cc: sta...@vger.kernel.org
Fixes: 8e54eea ("drm/msm: Add a helper function to parse clock names")
Signed-off-by: Jordan Crouse
---
Hi Dave, Daniel,
Fixes for 5.1:
amdgpu:
- Fix missing fw declaration after dropping old CI DPM code
- Fix debugfs access to registers beyond the MMIO bar size
- Fix context priority handling
- Add missing license on some new files
- Various cleanups and bug fixes
radeon:
- Fix missing break in
Hi David,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc4 next-20190221]
[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
https://bugs.freedesktop.org/show_bug.cgi?id=109731
Bug ID: 109731
Summary: DRM functionality is not working as per the
requirements
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=109730
--- Comment #2 from Alex Deucher ---
Possibly related to this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=201519
if so, does this patch help?
https://bugs.freedesktop.org/show_bug.cgi?id=109730
Bug ID: 109730
Summary: On resume: atombios stuck in loop for more than 5secs
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=109730
--- Comment #1 from Dominic Tubach ---
Created attachment 143434
--> https://bugs.freedesktop.org/attachment.cgi?id=143434=edit
lspci
--
You are receiving this mail because:
You are the assignee for the
Hi,
On Thu, 2019-02-21 at 20:24 +, Kuehling, Felix wrote:
> On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote:
> > On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote:
> > > On 2019-02-21 2:59 a.m., Koenig, Christian wrote:
> > > > On x86 with HIGHMEM there is no dma32 zone. Why do we
On 2019-02-20 12:24 a.m., Mathias Fröhlich wrote:
> Hi,
>
> ping?
> ... to the dc folks?
>
> best
> Mathias
Hi Mathias,
Sorry for the wait, change looks good to me.
Reviewed-by: Leo Li
...and merged.
Thanks for cleaning this up.
Leo
>
> On Wednesday, 13 February 2019 21:38:03 CET Alex
On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote:
> On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote:
>> On 2019-02-21 2:59 a.m., Koenig, Christian wrote:
>>> On x86 with HIGHMEM there is no dma32 zone. Why do we need one on
> x86_64? Can we make x86_64 more like HIGHMEM instead?
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
Native 420 and 422 transfer modes are new in DSC1.2
In these modes, each two pixels of a slice are treated as one
pixel, so the slice width is half as large (round down) for
the purposes of calucating the groups per line and chunk size
in bytes
In native 422 mode, each pixel has four components,
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #19 from Michael A. Leonetti (mikealeone...@gmail.com) ---
Created attachment 281263
--> https://bugzilla.kernel.org/attachment.cgi?id=281263=edit
4.18 config
Would you like me to build the 4.17.19 kernel with the print options
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #18 from Michael A. Leonetti (mikealeone...@gmail.com) ---
Created attachment 281261
--> https://bugzilla.kernel.org/attachment.cgi?id=281261=edit
4.17.19 config
Absolutely. Let me post the two configs then.
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #17 from Bjorn Helgaas (bhelg...@google.com) ---
Created attachment 281259
--> https://bugzilla.kernel.org/attachment.cgi?id=281259=edit
per-cpu alloc info (broken)
FWIW, I pulled out the per-cpu alloc info and what looks like the
https://bugs.freedesktop.org/show_bug.cgi?id=108854
--- Comment #14 from Tom Seewald ---
(In reply to Tom St Denis from comment #13)
> The wave dump seems to be empty... Is that the complete output? Was there
> anything printed to stderr (like there are no waves)?
Yes it says "no active
https://bugs.freedesktop.org/show_bug.cgi?id=109727
Bug ID: 109727
Summary: RX 580 - Login fails, unable to go further than GDM,
black screen
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS:
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
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
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
ME FW contributes a vital role in HDCP2.2 authentication.
HDCP2.2 driver needs to communicate to ME FW for each step of the
HDCP2.2 authentication.
ME FW prepare and HDCP2.2 authentication parameters and encrypt them
as per spec. With such parameter Driver prepares HDCP2.2 auth messages
and
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
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
Requests ME to start the second stage of HDCP2.2 authentication,
called Locality Check.
On Success, ME FW will provide LC_Init message to send to hdcp sink.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd used for ssize_t
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
FOR TESTING PURPOSE ONLY.
By default INTEL_MEI_HDCP is set to y. This patch is created to
test the interface between I915 and MEI_HDCP.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/mei/Kconfig
Request to ME to verify the M_Prime received from the HDCP sink.
ME FW will calculate the M and compare with M_prime received
as part of RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
On successful completion of this stage, downstream propagation of
the stream management info is
Request to ME to verify the LPrime received from HDCP sink.
On Success, ME FW will verify the received Lprime by calculating and
comparing with L.
This represents the completion of Locality Check.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are
Request to ME to prepare the encrypted session key.
On Success, ME provides Encrypted session key. Function populates
the HDCP2.2 authentication msg SKE_Send_Eks.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t
Request the ME to terminate the HDCP2.2 session for a port.
On Success, ME FW will mark the intel port as Deauthenticated and
terminate the wired HDCP2.2 Tx session started due to the cmd
WIRED_INITIATE_HDCP2_SESSION.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant
Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.
On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else
Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to ME FW.
On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.
v2: Rebased.
v3:
cldev is add as a
Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.
This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.
v2: Rebased.
v3:
Extra comments are removed.
v4:
%s/\/\*\*/\/\*
v5:
Extra lines are
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
Hi Laurent,
On Thu, Feb 21, 2019 at 12:32:07PM +0200, Laurent Pinchart wrote:
> As writeback jobs contain a framebuffer, drivers may need to prepare and
> cleanup them the same way they can prepare and cleanup framebuffers for
> planes. Add two new optional connector helper operations,
>
https://bugs.freedesktop.org/show_bug.cgi?id=108854
--- Comment #13 from Tom St Denis ---
The wave dump seems to be empty... Is that the complete output? Was there
anything printed to stderr (like there are no waves)?
--
You are receiving this mail because:
You are the assignee for the
Hi,
On Thu, Feb 21, 2019 at 12:32:06PM +0200, Laurent Pinchart wrote:
> Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and
> deleted when the jobs complete. This results in both a memory leak of
> the job and a leak of the framebuffer if the atomic commit returns
> before the job
On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote:
> On 2019-02-21 2:59 a.m., Koenig, Christian wrote:
> > On x86 with HIGHMEM there is no dma32 zone. Why do we need one on
> > > > x86_64? Can we make x86_64 more like HIGHMEM instead?
> > > >
> > > > Regards,
> > > > Felix
> > > >
>
https://bugs.freedesktop.org/show_bug.cgi?id=109692
Andrey Grodzovsky changed:
What|Removed |Added
CC||christian.koe...@amd.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=109695
--- Comment #2 from a...@tutanota.com ---
To check for the availability of the syscall, one can try it in a child process
and see if the child is terminated by a signal, e.g. like this:
#include
#include
#include
#include
#include
static
On 2019-02-21 2:59 a.m., Koenig, Christian wrote:
> On x86 with HIGHMEM there is no dma32 zone. Why do we need one on
>>> x86_64? Can we make x86_64 more like HIGHMEM instead?
>>>
>>> Regards,
>>> Felix
>>>
>> IIRC with x86, the kernel zone is always smaller than any dma32 zone,
>> so we'd
On Thu, Feb 21, 2019 at 05:40:05PM +0100, Hans de Goede wrote:
> Hi,
>
> On 21-02-19 16:59, Daniel Vetter wrote:
> > Found while grepping around.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Hans de Goede
> > Cc: Greg Kroah-Hartman
> > Cc: Sam Ravnborg
> > Cc: Daniel Vetter
> > Cc: Liviu
Laurent Pinchart writes:
> The drm_writeback_queue_job() function takes ownership of the passed job
> and requires the caller to manually set the connector state
> writeback_job pointer to NULL. To simplify drivers and avoid errors
> (such as the missing NULL set in the vc4 driver), pass the
Hi,
On 21-02-19 16:59, Daniel Vetter wrote:
Found while grepping around.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Liviu Dudau
---
drivers/staging/vboxvideo/vbox_irq.c | 5 +
1 file changed, 5 insertions(+)
diff
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 the right fd0, and
On Thu, Feb 21, 2019 at 04:59:51PM +0100, Daniel Vetter wrote:
> Found while grepping around.
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
> Cc: Greg Kroah-Hartman
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Liviu Dudau
> ---
> drivers/staging/vboxvideo/vbox_irq.c | 5 +
> 1
On Thu, Feb 21, 2019 at 12:42:25PM +0200, Laurent Pinchart wrote:
> Forgot to CC Eric, sorry about that.
>
> On Thu, Feb 21, 2019 at 12:32:05PM +0200, Laurent Pinchart wrote:
> > The drm_writeback_queue_job() function takes ownership of the passed job
> > and requires the caller to manually set
Quoting Chris Wilson (2019-02-21 12:03:18)
> Quoting Chengguang Xu (2019-02-21 02:08:19)
> > unlikely has already included in IS_ERR(), so just
> > remove redundant likely/unlikely annotation.
> >
> > Signed-off-by: Chengguang Xu
> Reviewed-by: Chris Wilson
And pushed, thanks for the patch.
Found while grepping around.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Liviu Dudau
---
drivers/staging/vboxvideo/vbox_irq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/vboxvideo/vbox_irq.c
This is the default for atomic drivers.
Signed-off-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/bochs/bochs_kms.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
This is the default for atomic drivers.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Luc Van Oostenryck
Cc: Rodrigo Vivi
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
On Thu, Feb 21, 2019 at 04:09:12PM +0100, Gerd Hoffmann wrote:
> > > +int drm_fb_helper_kick_out_vgacon(void);
> > > +
> >
> > Don't you need a dummy version as well for this one, like how it's done
> > for the other functions, to cover the case when DRM_FBDEV_EMULATION is
> > not selected?
>
>
Also rename it and call it automatically from
drm_fb_helper_remove_conflicting_pci_framebuffers()
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fb_helper.h | 18 ++---
drivers/gpu/drm/drm_fb_helper.c | 35 +
drivers/gpu/drm/i915/i915_drv.c | 43
https://bugs.freedesktop.org/show_bug.cgi?id=109714
Adam Jackson changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
On Thu, Feb 21, 2019 at 4:11 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > I was thinking of checking whether pdev is a VGA class device and whether
> > it decodes vga access, and in that case automatically calling
>
> How can I figure that? Ok, class is easy, but decode? pci.h offers
> functions to
Hi,
> I was thinking of checking whether pdev is a VGA class device and whether
> it decodes vga access, and in that case automatically calling
How can I figure that? Ok, class is easy, but decode? pci.h offers
functions to set vga decode but not to get that info ...
thanks,
Gerd
> > +int drm_fb_helper_kick_out_vgacon(void);
> > +
>
> Don't you need a dummy version as well for this one, like how it's done
> for the other functions, to cover the case when DRM_FBDEV_EMULATION is
> not selected?
Good question.
I guess it makes sense to kick out vgacon even with
On Thu, Feb 21, 2019 at 02:06:23PM +0100, Gerd Hoffmann wrote:
> On Thu, Feb 21, 2019 at 01:20:11PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote:
> > > Problem: qxl switches from native mode back into vga compatibility mode
> > > when it notices
On Thu, 21 Feb 2019, Gerd Hoffmann wrote:
> On Thu, Feb 21, 2019 at 03:08:39PM +0200, Jani Nikula wrote:
>> On Thu, 21 Feb 2019, Gerd Hoffmann wrote:
>> > It'll be useful for other drivers too, so move it to drm_fb_helper.c
>> > (and rename it of course). Also add docs.
>> >
>> > Signed-off-by:
>
> Request to ME to prepare the encrypted session key.
>
> On Success, ME provides Encrypted session key. Function populates the
> HDCP2.2 authentication msg SKE_Send_Eks.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
> Request the ME to terminate the HDCP2.2 session for a port.
>
> On Success, ME FW will mark the intel port as Deauthenticated and terminate
> the wired HDCP2.2 Tx session started due to the cmd
> WIRED_INITIATE_HDCP2_SESSION.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter
>
> 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
On Thu, Feb 21, 2019 at 01:39:33PM +0100, Gerd Hoffmann wrote:
> > > +/**
> > > + * drm_fb_helper_kick_out_vgacon - deactivate vgacon driver.
> > > + *
> > > + * Deactivate vgacon driver so it stops accessing vga io ports.
> > > + * Should be called after
> > > + *
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #8 from Tom St Denis ---
Just a follow up. If you "chmod +s" umr as a non-root user then even if you
sudo it it won't have permissions to read the debugfs files.
Make sure you "sudo chmod +s" the binary or simply just "sudo umr".
> ack
>
> 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:
>
On Thu, Feb 21, 2019 at 12:19:13PM +, Brian Starkey wrote:
> Hi Laurent,
>
> On Thu, Feb 21, 2019 at 12:02:57PM +0200, Laurent Pinchart wrote:
> > Hi Brian,
> >
> > On Thu, Feb 21, 2019 at 09:50:19AM +, Brian Starkey wrote:
> > > On Thu, Feb 21, 2019 at 10:23:17AM +0200, Laurent Pinchart
Den 21.02.2019 12.35, skrev Gerd Hoffmann:
> It'll be useful for other drivers too, so move it to drm_fb_helper.c
> (and rename it of course). Also add docs.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_fb_helper.h | 2 ++
> drivers/gpu/drm/drm_fb_helper.c | 39
>
> ME FW contributes a vital role in HDCP2.2 authentication.
> HDCP2.2 driver needs to communicate to ME FW for each step of the
> HDCP2.2 authentication.
>
> ME FW prepare and HDCP2.2 authentication parameters and encrypt them as
> per spec. With such parameter Driver prepares HDCP2.2 auth
Hey
Op 21-02-2019 om 12:14 schreef james qian wang (Arm Technology China):
> The writeback job will not be added to writeback queue if the state is
> check only or check failed, to avoid leak, need to cleanup writeback job
> in connector_destroy_state if the job existed.
>
> Signed-off-by: James
>
> 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]
>
On Thu, Feb 21, 2019 at 02:23:10PM +0200, Laurent Pinchart wrote:
> On Thu, Feb 21, 2019 at 12:19:13PM +, Brian Starkey wrote:
[snip]
> >
> > I used a pre-existing internal tool which does exactly that.
>
> Any hope of sharing the sources ?
>
Not in a timescale or form which would be
>
> Request to ME to verify the M_Prime received from the HDCP sink.
>
> ME FW will calculate the M and compare with M_prime received as part of
> RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
>
> On successful completion of this stage, downstream propagation of the stream
>
> Requests ME to start the second stage of HDCP2.2 authentication, called
> Locality Check.
>
> On Success, ME FW will provide LC_Init message to send to hdcp sink.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
> v4:
>
> Request to ME to verify the LPrime received from HDCP sink.
>
> On Success, ME FW will verify the received Lprime by calculating and
> comparing with L.
>
> This represents the completion of Locality Check.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant
1 - 100 of 183 matches
Mail list logo
