On 5/7/19 7:04 PM, Noralf Trønnes wrote:
Hi,
Could someone please have a look at this one?
Noralf.
Den 26.04.2019 14.47, skrev Noralf Trønnes:
The logic for freeing an imported buffer with a virtual address is
broken. It will free the buffer instead of unmapping the dma buf.
Fix by reversing
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 ++--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 120
> +++-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 2 +
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> drivers/pwm/pwm-atmel-hlcdc.c
https://bugs.freedesktop.org/show_bug.cgi?id=110639
Bug ID: 110639
Summary: enc->enc_pic.enc_pic_order_cnt_type always zero even
if pic->pic_order_cnt_type non-zero that application
set
Product: Mesa
Version: 18.
Hi, Jitao:
On Tue, 2019-04-16 at 14:05 +0800, Jitao Shi wrote:
> Add mt8183 dsi driver data. Enable size control and
> reg commit control.
>
Reviewed-by: CK Hu
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --gi
Hi, Jitao:
On Tue, 2019-04-16 at 14:05 +0800, Jitao Shi wrote:
> Our new DSI chip has frame size control.
> So add the driver data to control for different chips.
>
Reviewed-by: CK Hu
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +
> 1 file changed, 5 inserti
Hi, Jitao:
On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> New DSI IP has shadow register and working reg. The register
> values are writen to shadow register. And then trigger with
> commit reg, the register values will be moved working register.
This patch looks good, but the message is n
On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> Config the different CMDQ reg address in driver data.
>
For MT8173, you change reg_cmd_off from 0x180 to 0x200, so this patch is
a bug fix. You should add a 'Fixes' tag.
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c |
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Shmerl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109619
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110637
Bug ID: 110637
Summary: Enabling OpenCL in Libreoffice kills Vega 64
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #35 from Ilia Mirkin ---
If I had to put money on one of the left-over commits, I'd go with
commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa
Author: Aaron Ma
Date: Sat Sep 1 02:20:00 2018 +0800
vgaarb: Keep adding VGA device
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #34 from Christian Zigotzky ---
Hi All,
Allan successfully tested the eighth test kernel on his X5000 today.
He wrote:
Christian
DRM8 boots to Firepro. Can you ascertain anything as yet as to where the issue
lies?
Cheers
ace
--
On Wed, Mar 13, 2019 at 09:20:26PM -0300, Helen Koike wrote:
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are performed in the new_state and the respective
> cleanups are perf
On 5/6/2019 8:26 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
>> The patch series enables device drivers to use cgroups to control the
>> following resources within a GPU (or other accelerator device):
>> * control allocation of device memory (re
In the failure path for dpu_kms_init() it is possible to get to the MMU
destroy function with uninitialized MMU structs. Check for NULl and skip
if needed.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
di
The GPU specific pm_suspend code assumes that the hardware is active
when the function is called, which it usually is when called as part
of pm_runtime. But during unbind, the pm_suspend functions are called
blindly resulting in a bit of a when the hardware wasn't already
active (or booted, in the
If enabling clocks fails in msm_dss_enable_clk() the code to unwind the
settings starts at 'i' which is the clock that just failed. While this
isn't harmful it does result in a number of warnings from the clock
subsystem while trying to unpreare/disable the very clock that had
just failed to prepar
I somewhat accidently injected an error in the DPU KMS init that caused it to
fail and a handful of NULL deferences and errors ended up popping out. Here are
some fixes in the interest of robustness.
Jordan Crouse (3):
drm/msm/dpu: Fix error recovery after failing to enable clocks
drm/msm/dpu:
An error while initializing the msm driver ends up calling
drm_atomic_helper_shutdown() without first initializing the funcs
in mode_config. While I'm not 100% sure this isn't a ordering
problem in msm adding a check to drm_mode_alloc seems like
a nice and safe solution.
Signed-off-by: Jordan Crou
On Tue, May 7, 2019 at 11:34 AM Dylan Baker wrote:
>
> This patch and the previous one landed with a fixes tag nominating them for
> the
> staging/19.0 branch, but they don't apply, and to get the to apply requires
> pulling in several other android build system patches. If you'd like those in
>
Hi John,
This patch and the previous one landed with a fixes tag nominating them for the
staging/19.0 branch, but they don't apply, and to get the to apply requires
pulling in several other android build system patches. If you'd like those in
the 19.0 stable branch can you put together an MR again
Quoting Emil Velikov (2019-05-03 03:41:42)
> On Thu, 2 May 2019 at 23:19, Rob Clark wrote:
> >
> > On Thu, May 2, 2019 at 2:57 PM Dan Willemsen wrote:
> > >
> > > On Thu, May 2, 2019 at 1:52 PM John Stultz wrote:
> > > >
> > > > We need solutions for the xgettext and the python-mako usage.
> > >
Hi Thierry.
> pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM
OK to add the "pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM"
patch via drm-misc?
Then we can add all 6 patches in one go.
Sam
(Kept remaining of mail for reference)
>
> Hi,
>
> These patches adds suppo
Hi Guido.
Looks good now, stumbled upon a few details I missed in last round.
With these considered / fixed you can add my
Reviewed-by: Sam Ravnborg
Sam
> +#define CM(x)( \
> + ((x) < 32)?0xe0|((x)-16) : \
> + ((x) < 64
On Tue, May 07, 2019 at 06:37:07PM +0530, Jagan Teki wrote:
> HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> resolution. It has built in Goodix, GT9271 captive touchscreen
> with backlight adjustable via PWM.
>
> Add support for it.
>
> Cc: Thierry Reding
> Cc: Sam Ravnborg
On Tue, May 07, 2019 at 06:37:06PM +0530, Jagan Teki wrote:
> HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> resolution. It has built in Goodix, GT9271 captive touchscreen
> with backlight adjustable via PWM.
>
> Add dt-bindings documentation for it.
> Cc: Thierry Reding
> Cc:
These are a few support changes in advance of per-instance pagetables. These
can be added to msm-next immediately since they don't require anything external
support and they are mostly benign on their own without the more aggressive
changes coming up later.
Jordan Crouse (3):
drm/msm/adreno: Ena
When we move to 64 bit addressing for a5xx and a6xx targets we will start
seeing pagefaults at larger addresses so format them appropriately in the
log message for easier debugging.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
Pass the index of the MMU domain in struct msm_file_private instead
of assuming gpu->id throughout the submit path. This clears the way
to change ctx->aspace to a per-instance pagetable.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c| 2 ++
drivers/gpu/drm/msm/msm_drv.h
A5XX and newer GPUs can be run in either 32 or 64 bit mode. The GPU
registers and the microcode use 64 bit virtual addressing in either
case but the upper 32 bits are ignored if the GPU is in 32 bit mode.
There is no performance disadvantage to remaining in 64 bit mode even
if we are only generatin
On Tue, May 07, 2019 at 10:01:19AM +0200, Greg KH wrote:
> > My understanding is that the intent of KUnit is to avoid booting a kernel on
> > real hardware or in a virtual machine. That seems to be a matter of
> > semantics
> > to me because isn't invoking a UML Linux just running the Linux kerne
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #90 from komqin...@zoho.eu ---
Created attachment 144188
--> https://bugs.freedesktop.org/attachment.cgi?id=144188&action=edit
Geany without a bug
--
You are receiving this mail because:
You are the assignee for the bug.__
On 2019-05-06 12:30 p.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In amdgpu_gem_userptr_ioctl(
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #89 from komqin...@zoho.eu ---
Created attachment 144187
--> https://bugs.freedesktop.org/attachment.cgi?id=144187&action=edit
Bug in Geany
--
You are receiving this mail because:
You are the assignee for the bug._
On 2019-05-06 12:30 p.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In radeon_gem_userptr_ioctl(
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Need ACK for the uevent from userspace consumer.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
Signed-off-by: Ramalingam C
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
Need a ACK for uevent generating uAPI from userspace.
v2:
state update
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
v2:
Rebased.
v2:
Rebased.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 44 --
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.
v2:
Rebased.
v3:
%s/*_ksvs_revocated/*_check_ksvs_revoked [Daniel]
unwanted noise is removed.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
--
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected dis
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
v2:
Rebased.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c |
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
Need ACK from this uevent from userspace consumer.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 13 +++--
include/drm/drm_c
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disab
This series adds the content type capability for HDCP through a
drm connetor proeprty "HDCP Content Type". By default this property will
be "Type 0". And this property is exposed by the drivers which has the
HDCP2.2 capability to enable the userspace to configure for "Type 1".
HDCP Content Type:
On every hdcp revocation check request SRM is read from fw file
/lib/firmware/display_hdcp_srm.bin
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and
Existing functions for converting a 3bytes(be24) of big endian value
into u32 of little endian and vice versa are renamed as
s/drm_hdcp2_seq_num_to_u32/drm_hdcp_be24_to_cpu
s/drm_hdcp2_u32_to_seq_num/drm_hdcp_cpu_to_be24
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
cc: Tomas Winkler
Hi Fabio
On Tue, May 07, 2019 at 12:33:39PM -0300, Fabio Estevam wrote:
> [Adding Sam, who is helping to review/collect panel-simple patches]
>
> On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
> wrote:
> >
> > This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> > Santek
Hi,
Could someone please have a look at this one?
Noralf.
Den 26.04.2019 14.47, skrev Noralf Trønnes:
> The logic for freeing an imported buffer with a virtual address is
> broken. It will free the buffer instead of unmapping the dma buf.
> Fix by reversing the if ladder and first check if the b
On Tue, May 7, 2019 at 1:15 AM Mario Kleiner wrote:
>
> Nag nag: The below documentation patch, acked-by Daniel and r-b'd by
> Nicholas seems to not have made it into drm-next yet?
Pushed to drm-misc-next-fixes
Thanks!
Alex
>
> thanks,
> -mario
>
> On Thu, Apr 18, 2019 at 2:45 PM Kazlauskas, N
Fix up to mean the evoc list, not the event list.
-Daniel
On Tue, May 7, 2019 at 5:34 PM Daniel Vetter wrote:
>
> Adding evoc list.
> -Daniel
>
> On Tue, May 7, 2019 at 3:28 PM Karthik Guru wrote:
> >
> > Hey
> >
> > Could you please tell me if applications are open for XORG EVOC?
> >
> > Also,
Hi Sébastien,
On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
wrote:
>
> To make use of the new eLCDIF DRM driver OF graph description is
> required. Describe the display using OF graph nodes.
>
> Cc: sta...@vger.kernel.org # v4.19
The Cc to stable applies to bugfixes, which is not the case
Adding evoc list.
-Daniel
On Tue, May 7, 2019 at 3:28 PM Karthik Guru wrote:
>
> Hey
>
> Could you please tell me if applications are open for XORG EVOC?
>
> Also, whats the procedure for writing a proposal for any of the projects
>
> Thanks!
> ___
> dr
[Adding Sam, who is helping to review/collect panel-simple patches]
On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
wrote:
>
> This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
> that it can be conne
On 5/7/19 2:01 AM, Greg KH wrote:
On Mon, May 06, 2019 at 08:14:12PM -0700, Frank Rowand wrote:
On 5/1/19 4:01 PM, Brendan Higgins wrote:
## TLDR
I rebased the last patchset on 5.1-rc7 in hopes that we can get this in
5.2.
Shuah, I think you, Greg KH, and myself talked off thread, and we agre
On 4/9/19 12:44 PM, Uma Shankar wrote:
> HDR metadata block is introduced in CEA-861.3 spec.
> Parsing the same to get the panel's HDR metadata.
>
> v2: Rebase and added Ville's POC changes to the patch.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> v5: Addressed Shashank's
https://bugs.freedesktop.org/show_bug.cgi?id=110635
Bug ID: 110635
Summary: briefly flashing corruption when playing various OGL
games
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Hey
Could you please tell me if applications are open for XORG EVOC?
Also, whats the procedure for writing a proposal for any of the projects
Thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On Tue, May 07, 2019 at 12:05:32PM +0200, Daniel Vetter wrote:
> On Mon, May 06, 2019 at 04:43:34PM +0200, Daniel Vetter wrote:
> > On Fri, May 03, 2019 at 11:28:13PM +0530, jagdsh.li...@gmail.com wrote:
> > > From: Jagadeesh Pagadala
> > >
> > > Remove duplicate headers which are included twice.
On Mon, May 6, 2019 at 8:34 PM Rob Herring wrote:
>
> On Mon, May 6, 2019 at 4:56 AM Jagan Teki wrote:
> >
> > Hi Sam,
> >
> > On Thu, May 2, 2019 at 1:04 AM Sam Ravnborg wrote:
> > >
> > > Hi Jagan
> > >
> > > On Wed, May 01, 2019 at 05:44:47PM +0530, Jagan Teki wrote:
> > > > HD702E lcd is Fri
FriendlyELEC HD702E is one of optional LCD panel for
NanoPC T4 eDP interface.
It features 800x1280 resolutions, with built in GT9271 captive
touchscreen and adjustable backlight via PWM.
eDP panel connections are:
- VCC3V3_SYS: 3.3V panel power supply
- GPIO4_C2: PWM0_BL pin
- GPIO4_D5_LCD_BL_EN:
HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
resolution. It has built in Goodix, GT9271 captive touchscreen
with backlight adjustable via PWM.
Add support for it.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Rev
HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
resolution. It has built in Goodix, GT9271 captive touchscreen
with backlight adjustable via PWM.
Add dt-bindings documentation for it.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=105819
--- Comment #12 from xom ---
Only solution to this problem I have found is to downgrade to LTS 4.14 kernel.
GPU has never had any issues in windows.
Linux abyss 4.14.116-1-lts414 #1 SMP Tue May 7 01:33:27 MDT 2019 x86_64
GNU/Linux
xom[~]$ gl
Acked-by: Satyeshwar Singh
-Original Message-
From: Roper, Matthew D
Sent: Monday, May 6, 2019 2:59 PM
To: Daniel Vetter
Cc: C, Ramalingam ; Vetter, Daniel
; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; Singh, Satyeshwar
Subject: Re: [Intel-gfx] [PATCH v6 03/10]
On Tue, May 07, 2019 at 01:25:42PM +0300, Ville Syrjälä wrote:
> On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
> >
> >
> > >-Original Message-
> > >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> > >Sent: Saturday, May 4, 2019 3:48 PM
> > >To: Shankar, Uma ; intel-...@lists
On Tue, Apr 09, 2019 at 10:14:35PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> It also implements get() and set() functions for HDR output
> metadata property.The blob data
On Tue, Apr 09, 2019 at 10:14:42PM +0530, Uma Shankar wrote:
> This patch enables modeset whenever HDR metadata
> needs to be updated to sink.
>
> v2: Addressed Shashank's review comments.
>
> v3: Added Shashank's RB.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Uma Shankar
> Reviewed-by:
Am 07.05.19 um 13:45 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we need
memory for (or rather the ww_mutex of it
add ticket for display bo, so that it can preempt busy bo.
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++-
1 file changed, 16 insertions(+), 5 deletions(-)
On 5/7/19 1:24 PM, Christian König wrote:
Am 07.05.19 um 13:22 schrieb zhoucm1:
On 2019年05月07日 19:13, Koenig, Christian wrote:
Am 07.05.19 um 13:08 schrieb zhoucm1:
On 2019年05月07日 18:53, Koenig, Christian wrote:
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
heavy gpu job could occupy memory
Am 07.05.19 um 13:37 schrieb Thomas Hellstrom:
> [CAUTION: External Email]
>
> On 5/7/19 1:24 PM, Christian König wrote:
>> Am 07.05.19 um 13:22 schrieb zhoucm1:
>>>
>>>
>>> On 2019年05月07日 19:13, Koenig, Christian wrote:
Am 07.05.19 um 13:08 schrieb zhoucm1:
>
> On 2019年05月07日 18:53, K
v2: use one transfer ioctl
Signed-off-by: Chunming Zhou
---
xf86drm.c | 33 +
xf86drm.h | 6 ++
2 files changed, 39 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 17e3d880..acd16fab 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4257,6 +4257,21 @@ drm_pu
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu.h| 22 ++
amdgpu/amdgpu_cs.c | 16
2 files changed, 38 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index d2480dbe..9d9b0832 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1685,6 +1685
v2: adapt to new one transfer ioctl
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu-symbol-check | 3 ++
amdgpu/amdgpu.h| 51
amdgpu/amdgpu_cs.c | 68 ++
3 files changed, 122 insertions(+)
diff --git a/amdgpu/a
v2: drop DRM_SYNCOBJ_CREATE_TYPE_TIMELINE, fix timeout calculation,
fix some warnings
v3: add export/import and cpu signal testing cases
Signed-off-by: Chunming Zhou
---
tests/amdgpu/Makefile.am | 3 +-
tests/amdgpu/amdgpu_test.c | 11 ++
tests/amdgpu/amdgpu_test.h | 21 +++
test
v2: symbos are stored in lexical order.
v3: drop export/import and extra query indirection
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu-symbol-check | 2 ++
amdgpu/amdgpu.h| 39 ++
amdgpu/amdgpu_cs.c | 23 ++
3 files
v2: drop export/import
Signed-off-by: Chunming Zhou
---
xf86drm.c | 44
xf86drm.h | 6 ++
2 files changed, 50 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 2c19376b..17e3d880 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4256,3 +4256,47 @@
Signed-off-by: Chunming Zhou
---
include/drm/amdgpu_drm.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index d0701ffc..3d0318e6 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -528,6 +528,8 @@ struct drm_a
Am 07.05.19 um 13:22 schrieb zhoucm1:
On 2019年05月07日 19:13, Koenig, Christian wrote:
Am 07.05.19 um 13:08 schrieb zhoucm1:
On 2019年05月07日 18:53, Koenig, Christian wrote:
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user
fail to g
On 2019年05月07日 19:13, Koenig, Christian wrote:
Am 07.05.19 um 13:08 schrieb zhoucm1:
On 2019年05月07日 18:53, Koenig, Christian wrote:
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user
fail to get memory.
basically pick up Christian
Am 07.05.19 um 13:08 schrieb zhoucm1:
>
>
> On 2019年05月07日 18:53, Koenig, Christian wrote:
>> Am 07.05.19 um 11:36 schrieb Chunming Zhou:
>>> heavy gpu job could occupy memory long time, which lead other user
>>> fail to get memory.
>>>
>>> basically pick up Christian idea:
>>>
>>> 1. Reserve the
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (De
On 2019年05月07日 18:53, Koenig, Christian wrote:
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run in
Hello Tomeu Vizoso,
The patch 6ff408e6dc20: "drm/panfrost: Add sanity checks to submit
IOCTL" from Apr 24, 2019, leads to the following static checker
warning:
drivers/gpu/drm/panfrost/panfrost_drv.c:222 panfrost_ioctl_submit()
error: we previously assumed 'sync_out' could be null
On Tue, May 7, 2019 at 4:47 AM Guido Günther wrote:
>
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
>
> The driver supp
On Tue, May 7, 2019 at 4:47 AM Guido Günther wrote:
>
> Add support for the MIXEL DPHY IP as found on NXP's i.MX8MQ SoCs.
>
> Signed-off-by: Guido Günther
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Rob Herring
Reviewed-by: Fabio Estevam
___
dri-deve
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 73db4ec12f05160528884c0b2c845b1c6b7c6718
commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (D
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
> heavy gpu job could occupy memory long time, which lead other user fail to
> get memory.
>
> basically pick up Christian idea:
>
> 1. Reserve the BO in DC using a ww_mutex ticket (trivial).
> 2. If we then run into this EBUSY condition in TTM check if
Am 07.05.19 um 11:36 schrieb Chunming Zhou:
> add ticket for display bo, so that it can preempt busy bo.
>
> Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
> Signed-off-by: Chunming Zhou
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
> 1 file changed, 17 i
On Tue, May 07, 2019 at 09:50:19AM +1000, Dave Airlie wrote:
> On Fri, 3 May 2019 at 22:17, Daniel Vetter wrote:
> >
> > On Fri, May 03, 2019 at 10:29:48AM +0100, Liviu Dudau wrote:
> > > On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> > > > On Fri, May 3, 2019 at 11:11 AM Liviu D
On Tue, May 07, 2019 at 09:03:45AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Jonas Karlman [mailto:jo...@kwiboo.se]
> >Sent: Saturday, May 4, 2019 3:48 PM
> >To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> >dri-
> >de...@lists.freedesktop.org
> >Cc: dcasta...@ch
On Mon, May 06, 2019 at 04:43:34PM +0200, Daniel Vetter wrote:
> On Fri, May 03, 2019 at 11:28:13PM +0530, jagdsh.li...@gmail.com wrote:
> > From: Jagadeesh Pagadala
> >
> > Remove duplicate headers which are included twice.
> >
> > Signed-off-by: Jagadeesh Pagadala
>
> I collected some acks f
On Mon, May 06, 2019 at 05:27:24PM +0200, Daniel Vetter wrote:
> On Mon, May 06, 2019 at 05:57:53PM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > On Mon, May 06, 2019 at 04:46:29PM +0200, Daniel Vetter wrote:
> > > It's mandatory and considered core state
Fix the kbuild test rebot reported warnings:
- symbol was not declared. Should it be static?
- missing braces around initializer
Depends on:
- https://patchwork.freedesktop.org/series/58976/
V2: Update Signed-off-by name to make it same with author entirely.
Reported-by: kbuild test robot
Signe
On Thu, 02 May 2019, Daniel Thompson wrote:
> On Thu, May 02, 2019 at 06:42:39AM -0400, Brian Masney wrote:
> > On Thu, May 02, 2019 at 11:07:51AM +0100, Daniel Thompson wrote:
> > > On 24/04/2019 10:25, Brian Masney wrote:
> > > > lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
Hi, Jitao:
On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> DSI panel driver need attach function which is inculde in
> mipi_dsi_host_ops.
>
> If mipi_dsi_host_register is not in probe, dsi panel will
> probe fail or more delay.
I think this patch just prevent delay, not to prevent dsi pane
On 2019年05月07日 17:03, Christian König wrote:
[CAUTION: External Email]
Ping!
in fact, already address your comments, just wait for Prike test result,
anyway, send v6 first.
-David
Marek is going to need this for its GDS patches as well.
Christina.
Am 30.04.19 um 11:10 schrieb Christian
add ticket for display bo, so that it can preempt busy bo.
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/
1 - 100 of 155 matches
Mail list logo
