On Tue, 17 Sep 2019 13:32:05 +0200
Daniel Vetter wrote:
> On Tue, Sep 17, 2019 at 11:27 AM Michel Dänzer wrote:
> >
> > On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
> > > On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
> > >> Am 17.09.19 um 10:17 schrieb Daniel Vetter:
> > >>> On Tue,
On 2019/9/18 上午10:57, Tian, Kevin wrote:
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Tuesday, September 17, 2019 6:17 PM
On 2019/9/17 下午4:09, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, September 12, 2019 5:40 PM
Currently, except for the crate and remove. The rest fields of
Without deferred IO support, hyperv_fb driver informs the host to refresh
the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
is screen update or not. This patch supports deferred IO for screens in
graphics mode and also enables the frame buffer on-demand refresh. The
highest
On 2019/9/17 下午8:42, Cornelia Huck wrote:
On Thu, 12 Sep 2019 17:40:12 +0800
Jason Wang wrote:
Currently, except for the crate and remove. The rest fields of
mdev_parent_ops is just designed for vfio-mdev driver and may not help
for kernel mdev driver. So follow the device id support by previ
On 2019/9/17 下午8:07, Cornelia Huck wrote:
On Thu, 12 Sep 2019 17:40:11 +0800
Jason Wang wrote:
Mdev bus only support vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
one example is virtio-mdev[1] driver. This means we need to
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Tuesday, September 17, 2019 6:17 PM
>
> On 2019/9/17 下午4:09, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Thursday, September 12, 2019 5:40 PM
> >>
> >> Currently, except for the crate and remove. The rest fields of
> >> mdev_parent_op
On Wed, 18 Sep 2019 01:54:43 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, September 18, 2019 1:31 AM
> >
> > [cc +Parav]
> >
> > On Thu, 12 Sep 2019 17:40:10 +0800
> > Jason Wang wrote:
> >
> > > Hi all:
> > >
> > > During the development of virtio-mdev[1]. I fi
> From: Alex Williamson
> Sent: Wednesday, September 18, 2019 1:31 AM
>
> [cc +Parav]
>
> On Thu, 12 Sep 2019 17:40:10 +0800
> Jason Wang wrote:
>
> > Hi all:
> >
> > During the development of virtio-mdev[1]. I find that mdev needs to be
> > extended to support devices other than vfio mdev devi
From: Srinivasan S
This patch avoids DP MST payload error message in dmesg, as it is trying
to read the payload from the disconnected DP MST device. After the unplug
the connector status is disconnected and we should not be looking for the
payload and hence remove the error and throw the warning.
https://bugs.freedesktop.org/show_bug.cgi?id=111727
Bug ID: 111727
Summary: [Panfrost] Kernel panic in weston running glmark2
Product: DRI
Version: unspecified
Hardware: ARM
OS: Linux (All)
Status: NEW
Sev
On Tue, Sep 17, 2019 at 03:11:27PM +0200, Daniel Vetter wrote:
> On Fri, Aug 2, 2019 at 11:43 AM Lowry Li (Arm Technology China)
> wrote:
> >
> > From: "Lowry Li (Arm Technology China)"
> >
> > Adds to print the event message when error happens and the same event
> > will not be printed until nex
On Tue, Sep 17, 2019 at 10:14 AM Jordan Crouse wrote:
>
> On Mon, Sep 16, 2019 at 01:34:55PM -0700, Rob Clark wrote:
> > On Mon, Sep 16, 2019 at 1:12 PM Drew Davenport
> > wrote:
> > >
> > > The arguments related to IOMMU port name have been unused since
> > > commit 944fc36c31ed ("drm/msm: use
drmVersion::name = amdgpu, radeon, intel, etc.
drmVersion::desc = vega10, vega12, vega20, ...
The common Mesa code will use name and desc to select the driver.
The AMD-specific Mesa code will use desc to identify the chip.
Mesa won't receive any PCI IDs for future chips.
Marek
On Tue, Sep 17,
On Tue, 17 Sep 2019 at 18:40, Thierry Reding wrote:
>
> On Tue, Sep 17, 2019 at 01:49:57PM +1000, Ben Skeggs wrote:
> > On Tue, 17 Sep 2019 at 01:04, Thierry Reding
> > wrote:
> > >
> > > From: Thierry Reding
> > >
> > > The GPUs found on Tegra SoCs have registers that can be used to read the
>
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #28 from mib...@gmx.at ---
Created attachment 145406
--> https://bugs.freedesktop.org/attachment.cgi?id=145406&action=edit
failed suspend 5.2.14
Still occasionally happens on 5.2.14. Hard to figure out what's causing this
since it
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #49 from Shmerl ---
Could be just a similar symptom, but I have a freeze with The Bard's Tale IV
with the same error message:
https://bugs.freedesktop.org/show_bug.cgi?id=111591
It's going through radeonsi path though.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #83 from tempel.jul...@gmail.com ---
Andrew, with your patch the issue is still there in a weak shape:
When I open the inventory in TES IV Oblivion, don't move the cursor for some
seconds and then move it again, there is always a fram
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.5-wip
head: e9c28167d325cfdc37de35b2fd32d28f1943fcc4
commit: 4a1115c618328be01954d5d0a696d289d26776a1 [185/201] drm/amd/display:
Initialize HDCP work queue
reproduce: make htmldocs
If you fix the issue, kindly add following tag
Re
On Tue, 17 Sep 2019 12:37:27 +0200, Maciej Falkowski wrote:
> Convert Samsung Image Rotator to newer dt-schema format.
>
> Signed-off-by: Maciej Falkowski
> Signed-off-by: Marek Szyprowski
> ---
> v3:
> - remove unneded comments and descriptions
> - remove unneded maxItems field from clock-names
From: Sean Paul
Currently the self refresh idle timer is a const set by the crtc. This
is fine if the self refresh entry/exit times are well-known for all
panels used on that crtc. However panels and workloads can vary quite a
bit, and a timeout which works well for one doesn't work well for
anot
From: Sean Paul
Artifacts of previous revisions.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_self_refresh_helper.c | 1 -
include/drm/drm_crtc.h| 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
b/drivers/gp
On Thu, Sep 12, 2019 at 11:32:28AM +0800, allen wrote:
> From: Allen Chen
>
> Add a DT binding documentation for IT6505.
>
> Signed-off-by: Allen Chen
>
Drop the blank line.
> Signed-off-by: Pi-Hsun Shih
>
> ---
> cros-ec does not have an associated driver that uses the standard Linux USB-
Reviewed-by: Lyude Paul
On Tue, 2019-09-17 at 14:09 +0200, Daniel Vetter wrote:
> Current code is quite a mess unfortunately, so also add a todo.rst
> entry to maybe fix it up eventually.
>
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 12 +++
On 9/4/19, 7:57 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
>
Acked-by: Jingoo Han
>
> ---
> drivers/video/fbdev/s3c-fb.c | 3 +--
> 1 file changed, 1 inser
This patch removes the deprecated Android.mk files and replaces
them with Android.bp files.
This is needed in order to build libdrm/master against recent
Android releases and AOSP/master, as some of the Treble build
options required since Android O cannot be expressed in
Andorid.mk files.
Patch o
On Thu, 12 Sep 2019 23:32:56 +0200, Andreas Kemnade wrote:
> add enable-gpios to describe HWEN pin
>
> Signed-off-by: Andreas Kemnade
> Acked-by: Daniel Thompson
> ---
> changes in v2: added example
> changes in v3: added Acked-by
> changes in v4: moved enable-gpios to the right position
> in
Not sure I understand enough about why BAR2 is needed or what it's used for to
give a proper review on this one, probably better to wait for skeggsb to take
a look at this
On Mon, 2019-09-16 at 16:36 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Fill in BAR2 callbacks for instance memo
I don't see any problems with this, since nvkm_device_del() is mainly in
charge of just releasing memory allocations as is drm_dev_put().
Reviewed-by: Lyude Paul
On Mon, 2019-09-16 at 16:36 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> When Nouveau is instantiated on top of a platfor
On Wed, Sep 11, 2019 at 05:06:33PM +0100, Kieran Bingham wrote:
> Hi Jacopo,
>
> On 06/09/2019 14:54, Jacopo Mondi wrote:
> > Document the newly added 'cmms' property which accepts a list of phandle
> > and channel index pairs that point to the CMM units available for each
> > Display Unit output
On Fri, Sep 06, 2019 at 03:54:28PM +0200, Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded)
On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong wrote:
>
> Hi,
>
> On 17/09/2019 18:07, Liviu Dudau wrote:
> > On Tue, Sep 17, 2019 at 02:53:01PM +0200, Daniel Vetter wrote:
> >> On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> >>> Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which d
[cc +Parav]
On Thu, 12 Sep 2019 17:40:10 +0800
Jason Wang wrote:
> Hi all:
>
> During the development of virtio-mdev[1]. I find that mdev needs to be
> extended to support devices other than vfio mdev device. So this
> series tries to extend the mdev to be able to differ from different
> device
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The rule mentionned in the past was to disambiguate with object IDs. However
some drivers break this rule (that's why the ordering is documented as
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #82 from tempel.jul...@gmail.com ---
(In reply to Andrew Eikum from comment #81)
> I've submitted a patch to Wine to throttle our calls to XResetScreenSaver to
> once every five seconds: https://source.winehq.org/patches/data/169958
>
On Mon, Sep 16, 2019 at 01:34:55PM -0700, Rob Clark wrote:
> On Mon, Sep 16, 2019 at 1:12 PM Drew Davenport
> wrote:
> >
> > The arguments related to IOMMU port name have been unused since
> > commit 944fc36c31ed ("drm/msm: use upstream iommu") and can be removed.
> >
> > Signed-off-by: Drew Dave
Hi,
On 17/09/2019 18:07, Liviu Dudau wrote:
> On Tue, Sep 17, 2019 at 02:53:01PM +0200, Daniel Vetter wrote:
>> On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
>>> Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the
>>> framebuffer
>>> is allocated in a protected sys
With the removal of the panel-dpi from the omap drivers, the
LCD no longer works. This patch points the device tree to
a newly created panel named "logicpd,type28"
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/logicpd-torpedo-
This patch adds documentation of device tree bindings for the WVGA panel
Logic PD Type 28 display.
Signed-off-by: Adam Ford
diff --git a/Documentation/devicetree/bindings/display/panel/logicpd,type28.txt
b/Documentation/devicetree/bindings/display/panel/logicpd,type28.txt
new file mode 100644
i
Previously, there was an omap panel-dpi driver that would
read generic timings from the device tree and set the display
timing accordingly. This driver was removed so the screen
no longer functions. This patch modifies the panel-simple
file to setup the timings to the same values previously used.
On Tue, Sep 17, 2019 at 02:53:01PM +0200, Daniel Vetter wrote:
> On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> > Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the
> > framebuffer
> > is allocated in a protected system memory.
> > Essentially, we want to support
Hi Yoshihiro,
This looks like an elegant solution that I can implement.
Many thanks for pointing me in a good direction.
> From: Yoshihiro Shimoda, Sent: Tuesday, September 17, 2019 05:39 PM
>
> Hi Gareth,
>
> > From: Gareth Williams, Sent: Monday, September 16, 2019 10:56 PM
> >
> > Hi Laurent
On 9/17/19 5:05 PM, Rohan Garg wrote:
Hi
We're not closing a device, are we?
Ah, yes, I'll fix this in v2.
Do we have a mechanism in place to stop a malicious unprivileged app
from allocating all kernel memory to gem labels?
I'm unsure why this is a concern since a malicious app could a
Hi
> Might be worth mentioning in the comment here that `len` includes the
> trailing NULL.
>
Ack, I'll address this in v2.
Cheers
Rohan Garg
signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lis
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #81 from Andrew Eikum ---
(In reply to Nicholas Kazlauskas from comment #74)
> (In reply to Michel Dänzer from comment #73)
> > Looks like some client repeatedly calls XForceScreenSaver (probably to
> > prevent the monitors from blan
Hi
>
> We're not closing a device, are we?
>
Ah, yes, I'll fix this in v2.
>
> Do we have a mechanism in place to stop a malicious unprivileged app
> from allocating all kernel memory to gem labels?
>
I'm unsure why this is a concern since a malicious app could also potentially
allocate lo
Provide a dummy static inline function in the header instead.
Cc: Daniel Vetter
Cc: Lowry Li (Arm Technology China)
Cc: james qian wang (Arm Technology China)
Fixes: 4d74b25ee395 ("drm/komeda: Adds error event print functionality")
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/displ
On Tue, Sep 17, 2019 at 4:47 PM Koenig, Christian
wrote:
>
> Am 17.09.19 um 15:45 schrieb Daniel Vetter:
> > On Tue, Sep 17, 2019 at 01:24:10PM +, Koenig, Christian wrote:
> >> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> >>> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
On 2019-09-17 2:09 p.m., Daniel Vetter wrote:
> commit 4f5368b5541a902f6596558b05f5c21a9770dd32
> Author: Daniel Vetter
> Date: Fri Jun 14 08:17:23 2019 +0200
>
> drm/kms: Catch mode_object lifetime errors
>
> uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
> all exc
Am 17.09.19 um 15:45 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 01:24:10PM +, Koenig, Christian wrote:
>> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
>>> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> On Mon, Sep 1
On 2019-09-17 1:20 p.m., Christian König wrote:
> Am 17.09.19 um 11:27 schrieb Michel Dänzer:
>> On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
>>> On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
Am 17.09.19 um 10:17 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 10:12 AM Christian Kö
On Tue, Sep 17, 2019 at 3:40 PM Benjamin Gaignard
wrote:
>
> Le mar. 17 sept. 2019 à 14:46, Daniel Vetter a écrit :
> >
> > On Mon, Sep 16, 2019 at 03:16:49PM +0200, Benjamin Gaignard wrote:
> > > Le lun. 9 sept. 2019 à 12:29, Benjamin Gaignard
> > > a écrit :
> > > >
> > > > Fix warnings when W
On Tue, Sep 17, 2019 at 01:24:10PM +, Koenig, Christian wrote:
> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> > On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
> >> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> >>> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wr
Le mar. 17 sept. 2019 à 14:46, Daniel Vetter a écrit :
>
> On Mon, Sep 16, 2019 at 03:16:49PM +0200, Benjamin Gaignard wrote:
> > Le lun. 9 sept. 2019 à 12:29, Benjamin Gaignard
> > a écrit :
> > >
> > > Fix warnings when W=1.
> > > No code changes, only clean up in sti internal structures and fu
https://bugs.freedesktop.org/show_bug.cgi?id=111232
--- Comment #10 from bibitocarlos ---
Tried with "iommu=offiommu=off amdgpu.ppfeaturemask=0x3fff", no change,
green screen.
--
You are receiving this mail because:
You are the assignee for the bug.__
On Tue, Sep 10, 2019 at 10:10:49AM -0700, Rob Clark wrote:
> On Tue, Sep 10, 2019 at 9:34 AM Robin Murphy wrote:
> > On 06/09/2019 22:44, Rob Clark wrote:
> > > NOTE that in discussion of previous revisions, RMRR came up. This is
> > > not really a replacement for RMRR (nor does RMRR really provi
On Fri, Sep 13, 2019 at 06:27:00PM -0400, Lyude Paul wrote:
> Some random issues with documentation that I noticed while working on
> nouveau the other day. There are no functional changes in this series.
Nice! On all three:
Reviewed-by: Daniel Vetter
>
> Lyude Paul (3):
> drm/encoder: Fix
On Fri, Sep 13, 2019 at 02:29:01PM +0200, Gerd Hoffmann wrote:
> drm_gem_object_funcs->vm_ops alone can't handle everything which needs
> to be done for mmap(), tweaking vm_flags for example. So add a new
> mmap() callback to drm_gem_object_funcs where this code can go to.
>
> Note that the vm_op
Den 17.09.2019 14.55, skrev Daniel Vetter:
> On Tue, Sep 10, 2019 at 04:59:57PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 10.09.2019 15.51, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 10.09.19 um 15:34 schrieb Noralf Trønnes:
Den 10.09.2019 14.48, skrev Thomas Zimmermann:
> Hi
>
Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
>> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
>>> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
Ping? Any further comment on this or can't we merge at least the
On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> This patch is an early RFC to judge the direction we are following in
> our virtualization efforts in Chrome OS. The purpose is to start a
> discussion on how to handle buffer sharing between multiple virtio
> devices.
>
> On a side no
On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> > On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> >> Ping? Any further comment on this or can't we merge at least the locking
> >> change?
> > I was at plumbers ...
On Fri, Aug 2, 2019 at 11:43 AM Lowry Li (Arm Technology China)
wrote:
>
> From: "Lowry Li (Arm Technology China)"
>
> Adds to print the event message when error happens and the same event
> will not be printed until next vsync.
>
> Changes since v2:
> 1. Refine komeda_sprintf();
> 2. Not using S
Thanks David,
I'll try to fix the test to match AMD's restrictions.
The v7 here was to fix another existing test :
dEQP-VK.api.external.fence.sync_fd.transference_temporary
Cheers,
-Lionel
On 17/09/2019 15:36, Zhou, David(ChunMing) wrote:
Hi Lionel,
The update looks good to me.
I tried you
On Thu, Sep 12, 2019 at 08:42:28AM +0200, Thomas Zimmermann wrote:
> Before updating the display from the console's shadow buffer, the dirty
> worker now waits for vblank. This allows several screen updates to pile
> up and acts as a rate limiter.
>
> v2:
> * don't hold helper->lock while wa
On Wed, Sep 11, 2019 at 10:12:27AM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a literal string, fix it.
>
> Signed-off-by: Colin Ian King
Applied, thanks.
-Daniel
> ---
> drivers/gpu/drm/selftests/test-drm_framebuffer.c | 2 +-
> 1 file changed, 1 inse
On Tue, Sep 10, 2019 at 04:59:57PM +0200, Noralf Trønnes wrote:
>
>
> Den 10.09.2019 15.51, skrev Thomas Zimmermann:
> > Hi
> >
> > Am 10.09.19 um 15:34 schrieb Noralf Trønnes:
> >>
> >>
> >> Den 10.09.2019 14.48, skrev Thomas Zimmermann:
> >>> Hi
> >>>
> >>> Am 10.09.19 um 13:52 schrieb Gerd Ho
On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the
> framebuffer
> is allocated in a protected system memory.
> Essentially, we want to support EGL_EXT_protected_content in our komeda
> driver.
>
> Signed-off-by: Ay
On Mon, Sep 16, 2019 at 03:16:49PM +0200, Benjamin Gaignard wrote:
> Le lun. 9 sept. 2019 à 12:29, Benjamin Gaignard
> a écrit :
> >
> > Fix warnings when W=1.
> > No code changes, only clean up in sti internal structures and functions
> > descriptions.
> >
> > Signed-off-by: Benjamin Gaignard
>
On 17/09/2019 09:42, Koenig, Christian wrote:
Hi Steven,
thought about that issue a bit more and I think I came up with a solution.
What you could do is to split up drm_sched_cleanup_jobs() into two
functions.
One that checks if jobs to be cleaned up are present and one which does
the actual c
On Thu, 12 Sep 2019 17:40:12 +0800
Jason Wang wrote:
> Currently, except for the crate and remove. The rest fields of
> mdev_parent_ops is just designed for vfio-mdev driver and may not help
> for kernel mdev driver. So follow the device id support by previous
> patch, this patch introduces devic
Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>> Ping? Any further comment on this or can't we merge at least the locking
>> change?
> I was at plumbers ...
>> Christian.
>>
>> Am 11.09.19 um 12:53 schrieb Christian König:
>>> Am 03.0
On 13/09/2019 18:24, Alyssa Rosenzweig wrote:
I'm conflicted on this series.
I'm on holiday, but thought I had to reply...
On the one hand, userspace should obviously not be able to crash the
kernel. So the crash should be fixed in one way or another.
On the other hand, userspace really has
On Fri, Sep 13, 2019 at 01:24:54PM -0400, Alyssa Rosenzweig wrote:
> I'm conflicted on this series.
>
> On the one hand, userspace should obviously not be able to crash the
> kernel. So the crash should be fixed in one way or another.
>
> On the other hand, userspace really has to supply all the
Hi Lionel,
The update looks good to me.
I tried your signal-order test, seems it isn't ready to run, not sure if I can
reproduce your this issue.
-David
From: Lionel Landwerlin
Sent: Tuesday, September 17, 2019 7:03 PM
To: dri-devel@lists.freedesktop.org
Cc: Lio
On Mon, Sep 09, 2019 at 02:46:47PM +0200, Thomas Zimmermann wrote:
>
>
> Am 04.09.19 um 07:47 schrieb Gerd Hoffmann:
> > New helper to print named bits of some value (think flags fields).
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > include/drm/drm_print.h | 3 +++
> > drivers/gpu/drm
Applied. Thanks!
Alex
On Mon, Sep 2, 2019 at 4:16 PM Kai-Heng Feng
wrote:
>
> Laptops with AMD APU doesn't restore display backlight brightness after
> system resume.
>
> This issue started when DC was introduced.
>
> Let's use BL_CORE_SUSPENDRESUME so the backlight core calls
> update_status c
On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> Ping? Any further comment on this or can't we merge at least the locking
> change?
I was at plumbers ...
>
> Christian.
>
> Am 11.09.19 um 12:53 schrieb Christian König:
> > Am 03.09.19 um 10:05 schrieb Daniel Vetter:
> > > On Th
On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> On Fri 06-09-19 08:45:39, Tejun Heo wrote:
> > Hello, Daniel.
> >
> > On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > > > Hmm... what'd be the fundamental difference from slab or socket memory
> > > > which are hand
Alright; I'm not familiar with patchwork but sounds good.
On Mon, Sep 16, 2019 at 05:36:24PM -0500, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 12:43 PM Alyssa Rosenzweig
> wrote:
> >
> > Patch 1 is:
> >
> > Acked-by: Alyssa Rosenzweig
> >
> > Patch 2 is:
> >
> > Reviewed-by: Al
On Tue, Aug 27, 2019 at 07:13:41AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Also this patch series also adjust vram helpers, and I think it has a
> > slightly different goal: Just aligning mmap paths a bit more between
> > ttm and not-ttm based drivers.
>
> Not just ttm/not-ttm. gem_driver->fop
commit 4f5368b5541a902f6596558b05f5c21a9770dd32
Author: Daniel Vetter
Date: Fri Jun 14 08:17:23 2019 +0200
drm/kms: Catch mode_object lifetime errors
uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
all except i915) register all the dp stuff in their init code, which
Current code is quite a mess unfortunately, so also add a todo.rst
entry to maybe fix it up eventually.
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 12
drivers/gpu/drm/drm_connector.c | 10 --
drivers/gpu/drm/drm_dp_helper.c | 8 +++
On Thu, 12 Sep 2019 17:40:11 +0800
Jason Wang wrote:
> Mdev bus only support vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> one example is virtio-mdev[1] driver. This means we need to add device
> id support in bus match met
On Tue, Sep 17, 2019 at 11:22:35AM +, Koenig, Christian wrote:
> Am 17.09.19 um 11:24 schrieb Gerd Hoffmann:
> > Not obvious why this is needed. According to Deniel Vetter this is most
> > likely a historic artefact dating back to the days where drm drivers
> > exposed hardware registers as mm
On Tue, Sep 17, 2019 at 11:27 AM Michel Dänzer wrote:
>
> On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
> > On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
> >> Am 17.09.19 um 10:17 schrieb Daniel Vetter:
> >>> On Tue, Sep 17, 2019 at 10:12 AM Christian König
> >>> wrote:
> Am 17.09.19 u
From: "Lowry Li (Arm Technology China)"
Adds to support register dump on lpu and dou of pipeline and gcu on D71
Changes since v1:
- For a constant format without additional arguments, use seq_puts()
instead of seq_printf().
Signed-off-by: Lowry Li (Arm Technology China)
---
.../arm/display/ko
Am 17.09.19 um 11:24 schrieb Gerd Hoffmann:
> Not obvious why this is needed. According to Deniel Vetter this is most
> likely a historic artefact dating back to the days where drm drivers
> exposed hardware registers as mmap'able gem objects, to avoid dumping
> touching those registers.
Clearly
Am 17.09.19 um 11:27 schrieb Michel Dänzer:
On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
Am 17.09.19 um 10:17 schrieb Daniel Vetter:
On Tue, Sep 17, 2019 at 10:12 AM Christian König
wrote:
Am 17.09.19 um 07:47 schrieb Jani Nikula:
On Mon,
The Vulkan timeline semaphores allow signaling to happen on the point
of the timeline without all of the its dependencies to be created.
The current 2 implementations (AMD/Intel) of the Vulkan spec on top of
the Linux kernel are using a thread to wait on the dependencies of a
given point to materi
Hi all,
Just explaining what is being changed here compared to v6 :
We just noticed that some of our CTS runs are flaky because when
importing a dma fence into a drm syncobj we do not update the atomic
binary payload. This leads to issues when the userspace drivers tries
to add new points to the
Convert Samsung Image Rotator to newer dt-schema format.
Signed-off-by: Maciej Falkowski
Signed-off-by: Marek Szyprowski
---
v3:
- remove unneded comments and descriptions
- remove unneded maxItems field from clock-names property
---
.../bindings/gpu/samsung-rotator.txt | 28 --
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #48 from Marko Popovic ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #15)
> (In reply to Marko Popovic from comment #14)
> >
> > Yes, always happens at the same place with Citra emulator
>
> Could you capture a trace of
https://bugs.freedesktop.org/show_bug.cgi?id=108898
--- Comment #6 from Eero Tamminen ---
These still happen with latest git version of kernel, Mesa etc.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing li
On 2019/9/17 下午4:09, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, September 12, 2019 5:40 PM
Currently, except for the crate and remove. The rest fields of
mdev_parent_ops is just designed for vfio-mdev driver and may not help
for kernel mdev driver. So follow the device id support by p
On 2019/9/17 下午3:55, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, September 12, 2019 5:40 PM
Mdev bus only support vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
one example is virtio-mdev[1] driver. This means we need
On Wed, Sep 11, 2019 at 02:03:49PM +0200, Thomas Zimmermann wrote:
> The ast and mgag200 drivers pin() and kmap() cursor buffers; essentially
> reimplementing vmap(). We can share some code by using the respective
> functionality from GEM VRAM buffer objects.
>
> Thomas Zimmermann (3):
> drm/vra
> It may not be worth blocking on this, so
>
> Acked-by: Thomas Zimmermann
>
> But I still think it's not a good interface because it exposes internal
> details.
>
> Please consider another idea: how about splitting off the ttm_bo_get()
> and vma-flags setup of ttm_fbdev_mmap() into a separat
Hi Gerd
Am 17.09.19 um 10:34 schrieb Gerd Hoffmann:
> On Fri, Sep 13, 2019 at 03:05:34PM +0200, Thomas Zimmermann wrote:
>
>>> +void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
>>> vm_area_struct *vma)
>>> +{
>>> + vma->vm_ops = &ttm_bo_vm_ops;
>>> +
>>> + /*
>>> +* Note:
On 2019-09-17 11:23 a.m., Michel Dänzer wrote:
> On 2019-09-17 10:23 a.m., Koenig, Christian wrote:
>> Am 17.09.19 um 10:17 schrieb Daniel Vetter:
>>> On Tue, Sep 17, 2019 at 10:12 AM Christian König
>>> wrote:
Am 17.09.19 um 07:47 schrieb Jani Nikula:
> On Mon, 16 Sep 2019, Marek Olšák
VM_IO is wrong here, shmem uses normal ram not io memory.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6efedab1501
1 - 100 of 153 matches
Mail list logo
