Hi
Am 07.02.19 um 20:07 schrieb Thomas Hellstrom:
>
>> diff --git a/include/drm/ttm/ttm_bo_driver.h
>> b/include/drm/ttm/ttm_bo_driver.h
>> index cbf3180cb612..c0bed72492f3 100644
>> --- a/include/drm/ttm/ttm_bo_driver.h
>> +++ b/include/drm/ttm/ttm_bo_driver.h
>> @@ -49,6 +49,8 @@
>> #define TT
On Thu, 2019-02-07 at 22:26 +, Jason Gunthorpe wrote:
> Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists
> w/o
> backing pages") introduced the sg_page_iter_dma_address() function
> without
> providing a way to use it in the general case. If the sg_dma_len() is
> not
> equa
Am Sa., 2. Feb. 2019 um 16:42 Uhr schrieb Rob Herring :
>
> Many users of drm_gem_object embed a struct reservation_object into
> their subclassed struct, so let's add one to struct drm_gem_object.
> This will allow removing the reservation object from the subclasses
> and removing the ->gem_prime_
Use linux/mman.h to make sure we get all mmap flags we need.
Signed-off-by: Michael S. Tsirkin
---
include/drm/drmP.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index bdb0d5548f39..a3184416ddc5 100644
--- a/include/drm/drmP.h
+++
> -Original Message-
> From: Winkler, Tomas
> Sent: Friday, February 8, 2019 3:42 AM
> To: C, Ramalingam ; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
>
> Subject: RE: [PATCH v11 39/42] misc/mei/hdcp: Component framework for I91
> -Original Message-
> From: Winkler, Tomas
> Sent: Friday, February 8, 2019 3:05 AM
> To: C, Ramalingam ; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
>
> Subject: RE: [PATCH v11 28/42] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx
>
https://bugs.freedesktop.org/show_bug.cgi?id=107261
--- Comment #16 from Zheng Luo ---
The problem is still not fixed and happens frequently at hibernation/shutdown.
Even worse, it seems to corrupt the firmware that the machine sometimes refuse
to boot (black screen, only caps lock on, fans spinn
u/drm/arm/display/komeda/komeda_dev.c:170:3: error: implicit
declaration of function 'devm_iounmap'; did you mean 'pci_iounmap'?
[-Werror=implicit-function-declaration]
devm_iounmap(dev, mdev->reg_base);
^~~~
pci_iounmap
and lots more ...
Probably caused
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 'sun6i_dsi_probe':
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1053:9: warning: 'ret' may be used
uninitialized in this function [-Wmay
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commit:
9f58892ea996 ("drm/i915: Pull all the reset functionality together into
i915_reset.c")
from the drm tree and commit:
d0e93599d396 ("drm/i915: prepare for drmP.h
Hi Andreas,
Thank you for the patch.
On Tue, Feb 05, 2019 at 07:38:13AM +0100, Andreas Kemnade wrote:
> This adds an additional backlight property as described
> in panel-common.txt
>
> Signed-off-by: Andreas Kemnade
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/di
Hi Linus,
Missed fixes last week as had nothing until amdgpu showed up on
Saturday. Other stuff has since rolled in along with some more amdgpu
fixes, so we have two weeks of those, and some i915, vmwgfx, sun4i,
rockchip and omap fixes.
Dave.
amdgpu/radeon:
- fix crash on passthrough for SI
- fe
Hi Andreas,
Thank you for the patch.
On Tue, Feb 05, 2019 at 07:38:12AM +0100, Andreas Kemnade wrote:
> This panel has a backlight, so fetch it from devicetree using the
> corresponding property as documented in panel-common.txt. It is
> implemented the same way as in panel-dpi.c
> This ensures t
Hi Dave,
The following changes since commit 2cc3b81dfa7f7de0d647e7f1473de811eef8b0de:
Merge tag 'drm-intel-next-2019-02-02' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-02-04 15:37:58
+1000)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.gi
On Fri, Feb 8, 2019 at 12:28 AM Daniel Vetter wrote:
>
> Component framework is extended to support multiple components for
> a struct device. These will be matched with different masters based on
> its sub component value.
>
> We are introducing this, as I915 needs two different components
> with
Since we need multiple components for I915 for different purposes
(Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
by the previous patch (mentioned below).
Author: Daniel Vetter
Date: Mon Jan 28 17:08:20 2019 +0530
components: multiple component
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst| 5 +
drivers/gpu/drm
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be matched to two
differe
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes much more the "assemble a pile
On Thu, Feb 07, 2019 at 03:26:13PM -0800, Eric Anholt wrote:
> We always decrement at GEM free, so make sure we increment at GEM
> creation for dma-bufs.
Indeed. Reviewed-by: Daniel Vetter
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/v3d/v3d_bo.c | 6 ++
> 1 file changed, 6 inse
We always decrement at GEM free, so make sure we increment at GEM
creation for dma-bufs.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_bo.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index a08766d39eab..b1766f096
On Fri, Jan 04, 2019 at 10:35:43PM +, Jason Gunthorpe wrote:
> Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> backing pages") introduced the sg_page_iter_dma_address() function without
> providing a way to use it in the general case. If the sg_dma_len is not
> equal
"Koenig, Christian" writes:
> Am 07.12.18 um 20:16 schrieb Eric Anholt:
>> The entity->dependency can go away completely once we've called
>> drm_sched_entity_add_dependency_cb() (if the cb is called before we
>> get around to tracing). The tracepoint is more useful if we trace
>> every dependen
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #26 from Paul Dufresne ---
Created attachment 143335
--> https://bugs.freedesktop.org/attachment.cgi?id=143335&action=edit
sudo lspci -nnvvk > lspci_while_flickering.txt
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #25 from Paul Dufresne ---
Created attachment 143334
--> https://bugs.freedesktop.org/attachment.cgi?id=143334&action=edit
output of sudo dmidecode > dmidecode.txr
--
You are receiving this mail because:
You are the assignee for
"Gustavo A. R. Silva" writes:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entr
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #24 from Paul Dufresne ---
Created attachment 14
--> https://bugs.freedesktop.org/attachment.cgi?id=14&action=edit
dufrp's dmesg for kernel 5.0rc5 (xstarted as root) with no flickering
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #23 from Paul Dufresne ---
Created attachment 143332
--> https://bugs.freedesktop.org/attachment.cgi?id=143332&action=edit
dufrp's Xorg.0.log for kernel 5.0rc5 (xstart as root) with no flickering
--
You are receiving this mail be
On Thu, Feb 7, 2019 at 11:40 PM Daniel Vetter wrote:
>
> On Wed, Feb 06, 2019 at 11:57:04PM +0100, Rafael J. Wysocki wrote:
> > ) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter
> > wrote:
> > >
> > > Component framework is extended to support multiple components for
> > > a struct device. These wi
On Wed, Feb 06, 2019 at 11:57:04PM +0100, Rafael J. Wysocki wrote:
> ) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter wrote:
> >
> > Component framework is extended to support multiple components for
> > a struct device. These will be matched with different masters based on
> > its sub component val
On Wed, Feb 06, 2019 at 11:57:04PM +0100, Rafael J. Wysocki wrote:
> ) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter wrote:
> >
> > Component framework is extended to support multiple components for
> > a struct device. These will be matched with different masters based on
> > its sub component val
On Thu, Feb 07, 2019 at 11:22:39PM +0100, Daniel Vetter wrote:
> On Thu, Feb 07, 2019 at 09:36:46AM +0100, Linus Walleij wrote:
> > +static const struct drm_mode_config_funcs mode_config_funcs = {
> > + .fb_create = drm_gem_fb_create,
>
> You need drm_gem_fb_create_with_dirty here because you ha
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=108514
Paul Dufresne changed:
What|Removed |Added
CC||dufres...@gmail.com
--- Comment #22 fro
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #21 from Paul Dufresne ---
Created attachment 143330
--> https://bugs.freedesktop.org/attachment.cgi?id=143330&action=edit
dmesg for kernel 5.0rc5 with flickering and debug=4
--
You are receiving this mail because:
You are the as
On Thu, Feb 07, 2019 at 04:07:33PM -0500, Sean Paul wrote:
> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> > The only thing now that makes drm_dev_unplug() special is that it sets
> > drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> > can remove drm_dev
>
> 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
> manageme
>
> 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 [To
>
> 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
>
> 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]
>
On Thu, Feb 07, 2019 at 10:02:17PM +0100, Linus Walleij wrote:
> On Thu, Feb 7, 2019 at 10:17 AM Daniel Vetter wrote:
> > On Thu, Feb 07, 2019 at 09:36:44AM +0100, Linus Walleij wrote:
>
> > > This makes it possible to pass a connector with an already
> > > attached external encoder into the simp
> 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 pass
> 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 com
> 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]
> Red
>
> 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:
>
>
> 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]
>
On Sat, Jan 26, 2019 at 01:25:22PM +0100, Sam Ravnborg wrote:
> Updated patchset, with merged patches removed, new patches added.
>
> > From the original mail:
>
> - drmP.h is now stripped down to include files
> and forward declarations.
> - All header files in include/
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #20 from Paul Dufresne ---
Created attachment 143329
--> https://bugs.freedesktop.org/attachment.cgi?id=143329&action=edit
dufresnep's xorg log for kernel 4.15.0 with drm.debug=0 strangely without
flickering
--
You are receiving
> 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:
> cl
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #19 from Paul Dufresne ---
Created attachment 143328
--> https://bugs.freedesktop.org/attachment.cgi?id=143328&action=edit
dufresnep's dmesg for kernel 4.15.0-45-generic with drm.debug=0 with strangely
no flickering
--
You are re
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, February 06, 2019 23:04
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma
> Cc: C, Ramalingam
> Subject: [PATCH v11 29/42] misc/mei/hdcp: Verify
On Sun, Feb 03, 2019 at 04:42:00PM +0100, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git
On Sun, Feb 03, 2019 at 04:41:58PM +0100, Noralf Trønnes wrote:
> drm_dev_unplug() has been stripped down and is going away. Open code its
> 2 remaining function calls.
>
> Cc: Dave Airlie
> Cc: Sean Paul
Reviewed-by: Sean Paul
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/udl/udl
> 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 messag
On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Maybe s/u
On Thu, Feb 7, 2019 at 10:17 AM Daniel Vetter wrote:
> On Thu, Feb 07, 2019 at 09:36:44AM +0100, Linus Walleij wrote:
> > This makes it possible to pass a connector with an already
> > attached external encoder into the simple KMS helper.
> >
> > This is helpful for my MCDE drivers, as it is pret
On Sun, Feb 03, 2019 at 04:41:55PM +0100, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspac
https://bugs.freedesktop.org/show_bug.cgi?id=108031
--- Comment #5 from Alexander Schlarb ---
Using the latest Debian kernel (4.19.0-2, which apparently corresponds to Linux
version 4.19.16, with 4.19.0-1 having corresponded to 4.19.13) this issue does
not affect me anymore.
I looked through the
On Wed, Feb 06, 2019 at 01:31:01PM -0500, Lyude Paul wrote:
> Looks like when making the final revision of:
>
> 022debad063e ("drm/atomic: Add drm_atomic_state->duplicated")
>
> I forgot to remove some of the comments that I had added to
> drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 22fff0d3aecd..1f22ce542a04 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3
No compatible string for it yet, just the version-dependent changes.
They've now tied the hub and the core interrupt lines into a single
interrupt line coming out of the block. It also turns out I made a
mistake in modeling the V3D v3.3 and v4.1 bridge as a part of V3D
itself -- the bridge is goin
The register now has another field, QRMAXCNT for how many TMU requests
get serviced before thread switch. We were accidentally reducing it
from its default of 0x3 (4 requests) to 0x0 (1).
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_gem.c | 4 +++-
drivers/gpu/drm/v3d/v3d_regs.h | 2
You'll get garbage measurements if the registers always read back
0xdeadbeef
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index eb2b2d2f8553..a24
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #18 from Paul Dufresne ---
Created attachment 143327
--> https://bugs.freedesktop.org/attachment.cgi?id=143327&action=edit
dufresnep's Xorg.0.log for kernel 4.15.0-45 (Mint 19) with drm.debug=4 lots of
flickering
--
You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #17 from Paul Dufresne ---
Created attachment 143326
--> https://bugs.freedesktop.org/attachment.cgi?id=143326&action=edit
dufresnep's dmesg for kernel 4.15.0-45-generic (Linux Mint) with drm.debug=4
with a lot of flickering
--
Y
On Thu, Feb 07, 2019 at 08:40:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 07, 2019 at 02:33:57AM +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 d
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #16 from Paul Dufresne ---
Created attachment 143325
--> https://bugs.freedesktop.org/attachment.cgi?id=143325&action=edit
Paul Dufresne's Xorg.0.log for k3.14.79 no_flickering
--
You are receiving this mail because:
You are the
On Thu, Feb 07, 2019 at 02:33:57AM +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 equipped
Qiang Yu writes:
> On Thu, Feb 7, 2019 at 3:17 AM Eric Anholt wrote:
>>
>> Qiang Yu writes:
>> > +int lima_gem_wait(struct drm_file *file, u32 handle, u32 op, u64
>> > timeout_ns)
>> > +{
>> > + bool write = op & LIMA_GEM_WAIT_WRITE;
>> > + struct drm_gem_object *obj;
>> > + struct
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #15 from Paul Dufresne ---
Created attachment 143324
--> https://bugs.freedesktop.org/attachment.cgi?id=143324&action=edit
Paul's dmesg with drm.debug=4 on kernel 3.14_79 (No flickering)
--
You are receiving this mail because:
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #9 from Christian König (christian.koe...@amd.com) ---
Yeah, I also would be really interested what the root cause is.
As far as I know we don't have any large per CPU data in amdgpu, so no idea how
this can happen.
--
You are recei
Am 07.02.19 um 16:33 schrieb Qiang Yu:
> On Thu, Feb 7, 2019 at 5:39 PM Christian König
> wrote:
>> Am 07.02.19 um 10:09 schrieb Daniel Vetter:
>>> On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
Kernel DRM driver for ARM Mali 400/450 GPUs.
Since last RFC, all feedback has
On Thu, 2019-02-07 at 09:59 +0100, Thomas Zimmermann wrote:
> Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same
> value. The only exception is vboxvideo, which is being converted to
> the
> new offset by this patch. Unifying the constants in a single place
> simplifies the drive
On Tue, Feb 05, 2019 at 07:22:32PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, February 5, 2019 11:43 PM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=109150
--- Comment #2 from Emil Velikov ---
The log says
systemd-logind: logind integration requires -keeptty and -keeptty was not
provided, disabling logind integration
Thus the FD is handled manually and for some reason fails on your end. Normally
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #8 from Bjorn Helgaas (bhelg...@google.com) ---
Even if this is "special", e.g., some strange kconfig or build/install issue,
this is a really painful issue to debug. It would be tremendous if we could
fail more gracefully, with some
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #7 from Michael A. Leonetti (mikealeone...@gmail.com) ---
It could be special. If so I'd love to know what it is that I'm doing wrong. So
far all of the 4.17 kernels I've tried works and Windows works on the laptop.
I'll see if I can g
On 2/7/2019 8:43 PM, Winkler, Tomas wrote:
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 [Uma]
v5:
Re
On Thu, Feb 07, 2019 at 11:21:52PM +0800, Qiang Yu wrote:
> On Thu, Feb 7, 2019 at 5:09 PM Daniel Vetter wrote:
> >
> > On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
> > > Kernel DRM driver for ARM Mali 400/450 GPUs.
> > >
> > > Since last RFC, all feedback has been addressed. Most Mal
On Thu, Feb 7, 2019 at 5:39 PM Christian König
wrote:
>
> Am 07.02.19 um 10:09 schrieb Daniel Vetter:
> > On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
> >> Kernel DRM driver for ARM Mali 400/450 GPUs.
> >>
> >> Since last RFC, all feedback has been addressed. Most Mali DTS
> >> change
On Thu, Feb 7, 2019 at 10:20 AM Ard Biesheuvel
wrote:
>
> On Wed, 6 Feb 2019 at 19:38, Christian König
> wrote:
> >
> > Am 06.02.19 um 18:23 schrieb Ard Biesheuvel:
> > > On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel
> > > wrote:
> > >> On Fri, 25 Jan 2019 at 12:30, Christian König
> > >> wrote
On Thu, Feb 7, 2019 at 5:09 PM Daniel Vetter wrote:
>
> On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
> > Kernel DRM driver for ARM Mali 400/450 GPUs.
> >
> > Since last RFC, all feedback has been addressed. Most Mali DTS
> > changes are already upstreamed by SoC maintainers. The kerne
> 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 [Uma]
> v5:
> Rebase as Part of reordering.
> C
>
> Header defines the interface for the I915 and MEI_HDCP drivers.
> This interface is specific to the usage of mei_hdcp from gen9+ platforms for
> ME FW based HDCP2.2 services.
>
> And Generic HDCP2.2 protocol specific definitions are added at
> drm/drm_hdcp.h.
>
> v2:
> Commit msg is enhanc
> All HDCP1.4 routines are gathered together, followed by the generic functions
> those can be extended for HDCP2.2 too.
>
> Signed-off-by: Ramalingam C
> Acked-by: Daniel Vetter
> Reviewed-by: Uma Shankar
Reviewed-by: Tomas Winkler
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 118 +++
>
> From: Daniel Vetter
>
> While typing these I think doing an s/component_master/aggregate/ would be
> useful:
> - it's shorter :-)
> - I think component/aggregate is much more meaningful naming than
> component/puppetmaster or something like that. At least to my
> English ear "aggregate"
Hi,
On Wed, Feb 06, 2019 at 02:28:39AM +0800, Chen-Yu Tsai wrote:
> > +static u16 sun6i_dsi_get_drq_edge1(struct sun6i_dsi *dsi,
> > + struct drm_display_mode *mode,
> > + u16 line_num)
> > +{
> > + struct mipi_dsi_device *dev
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #17 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
I can reproduce the issue but vsync needs to be on. I'd recommend turning vsync
off for now to avoid flickering.
The issue lies in how amdgpu_dm handles waiting for vblank
Op 06-02-2019 om 19:32 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> The fuzzy drm_calc_{h,v}scale_relaxed() helpers are no longer used.
> Throw them in the bin.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_rect.c | 108 -
> include/drm/drm_
Hi all,
In commit
4cbfa1e6c09e ("drm/vmwgfx: Fix setting of dma masks")
Fixes tag
Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
has these problem(s):
- ':' unexpected after SHA1
In commit
479d59026fe4 ("drm/vmwgfx: Also check for crtc status while check
Hi Dave,
Just adding s5pv210 SoC support of rotator module and changing
email address of scaler module author.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 2cc3b81dfa7f7de0d647e7f1473de811eef8b0de:
Merge tag 'drm-intel-next-2
https://bugs.freedesktop.org/show_bug.cgi?id=108689
Francesco Balestrieri changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |tvrtko.ursulin@linux.intel.
On Mon, Jan 28, 2019 at 06:22:58PM +0100, Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> co
Hi
Am 07.02.19 um 09:59 schrieb Thomas Zimmermann:
> Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same
> value. The only exception is vboxvideo, which is being converted to the
> new offset by this patch. Unifying the constants in a single place
> simplifies the driver code.
J
Am 07.02.19 um 10:36 schrieb Koenig, Christian:
> Am 07.02.19 um 09:59 schrieb Thomas Zimmermann:
>> 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
Hi,
On 14/01/2019 17:36, Ayan Halder wrote:
> On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
>> channel video format.
>>
>> P012 is a planar 4:2:0 YUV 12 bits per channel
>>
>> P016 is a planar 4:2:0 YUV with interleav
Am 07.02.19 um 10:09 schrieb Daniel Vetter:
On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
Kernel DRM driver for ARM Mali 400/450 GPUs.
Since last RFC, all feedback has been addressed. Most Mali DTS
changes are already upstreamed by SoC maintainers. The kernel
driver and user-kernel
Am 07.02.19 um 09:59 schrieb Thomas Zimmermann:
> 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 replac
https://bugs.freedesktop.org/show_bug.cgi?id=108898
--- Comment #1 from Eero Tamminen ---
Hangs are still happening with the latest Mesa (a203eaa4f4fb) and drm-tip
kernel (v5.0-rc4) git versions:
[ 2776.782754] Iteration 3/3: bin/testfw_app --gfx glfw --gl_api desktop_core
--width 1920 --height 1
Hi Kishon,
On Wed, Feb 06, 2019 at 06:00:19PM +0530, Kishon Vijay Abraham I wrote:
> On 06/02/19 5:55 PM, Maxime Ripard wrote:
> > On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote:
> >> On 05/02/19 2:16 PM, Daniel Vetter wrote:
> >>> On Mon, Feb 04, 2019 at 03:33:31PM +0530,
1 - 100 of 133 matches
Mail list logo
