Thanks Christian proposal and David draft the solution implement .
The pinned Bos failed not observed from prepare_fb ,but Abaqus job can't
finished through the whole night .
Regards the NULL fist BO EBUSY error case , which comes from
amdgpu_cs_bo_validate perform period as the below call
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #8 from Alexander Mezin ---
(In reply to Jan Vesely from comment #6)
> if yes can you confirm if the games hang when running with
> OCL_ICD_VENDORS=/var/empty/ ?
> (alternatively, you can just move libMesaOpenCL.* out of library
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #4 from Marek Olšák ---
This is fixed by these patches:
https://patchwork.freedesktop.org/series/60491/
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110658
Bug ID: 110658
Summary: MXGP3 (Steam, native Linux port, UE4): graphical
glitches
Product: Mesa
Version: 19.0
Hardware: Other
OS: All
Status:
On Thu, May 09, 2019 at 05:40:48PM -0600, Logan Gunthorpe wrote:
>
> Based on some of the other commenters, I was under the impression that
> kselftests had in-kernel tests but I'm not sure where or if they exist. If
> they do exists, it seems like it would make sense to convert those to kunit
>
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #7 from Alexander Mezin ---
(In reply to Jan Vesely from comment #6)
> Can you post the output of 'clinfo'?
Sure
Number of platforms 1
Platform Name Clover
Linux kernel 5.0 , amd rx580 gpu card
1 or many graphics program become uninterrupted(STAT D) when run 64
graphics program of sub-window concurrently.
We have to reboot machine to release the uninterrupted(STAT D) program.
We have such kernel log:
kernel: RenderThread D 0 393786 337242
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #40 from Christian Zigotzky ---
Hi All,
Great news! :-) Allan successfully tested the latest patched Git kernel with
his two graphics cards today.
OK, we know the bad commit and we have a patch. What’s next?
Cheers,
Christian
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr
On Wed, 2019-05-08 at 20:58 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:56AM +0300, Gwan-gyeong Mun wrote:
> > Data M/N calculations were assumed a bpp as RGB format. But when we
> > are
> > using YCbCr 4:2:0 output format on DP, we should change bpp
> > calculations
> > as YCbCr
On Wed, 2019-05-08 at 20:56 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:54AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> >
> > Setup VSC header and data block
On Wed, 2019-05-08 at 20:32 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:53AM +0300, Gwan-gyeong Mun wrote:
> > SDP VSC Header and Data Block follow DP 1.4a spec, section
> > 2.2.5.7.5,
> > chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
> >
> > Signed-off-by:
On Mon, Apr 29, 2019 at 10:14:57PM +0200, Andrea Parri wrote:
> These barriers only apply to the read-modify-write operations; in
> particular, they do not apply to the atomic_set() primitive.
>
> Replace the barriers with smp_mb()s.
>
> Fixes: b1fc2839d2f92 ("drm/msm: Implement preemption for
On 09/05/2019 09:21, Tomeu Vizoso wrote:
> Dan Carpenter's static analysis tool reported:
>
> drivers/gpu/drm/panfrost/panfrost_drv.c:222 panfrost_ioctl_submit()
> error: we previously assumed 'sync_out' could be null (see line 216)
>
> Indeed, sync_out could be NULL if userspace doesn't send a
On Thu 09 May 00:12 PDT 2019, Brian Masney wrote:
> On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote:
> > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> >
> > > On Wed, May 8, 2019 at 7:16 PM Brian Masney wrote:
> > > >
> > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn
On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then
On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
>
> The second item, arguably, does have significant overlap with kselftest.
> Whether you are running short tests in a light weight UML environment or
> higher level tests in an heavier VM the two could be using the same
>
Hi Dave, Daniel,
Fixes for 5.2:
- Fix a crash on gpu reset at driver load time
- ATPX hotplug fix for when the dGPU is powered off
- PLL fix for r5xx asics
- SR-IOV fixes
The following changes since commit 422449238e9853458283beffed77562d4b40a2fa:
Merge branch 'drm-next-5.2' of
On Thu, May 09, 2019 at 11:12:12AM -0700, Frank Rowand 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
Change-Id: I3750fc657b956b52750a36cb303c54fa6a265b44
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index da7b4fe8ade3..2568fd730161
This new drmcgrp resource limits the largest GEM buffer that can be
allocated in a cgroup.
Change-Id: I0830d56775568e1cf215b56cc892d5e7945e9f25
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h | 2 ++
kernel/cgroup/drm.c| 59 ++
2 files
Change-Id: I6830d3990f63f0c13abeba29b1d330cf28882831
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h| 32 ++
include/linux/cgroup_subsys.h | 4
init/Kconfig | 5 +
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c |
Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho
---
include/drm/drm_cgroup.h | 24
include/linux/cgroup_drm.h | 10
kernel/cgroup/drm.c| 118 -
3 files changed, 151 insertions(+), 1 deletion(-)
create
The drm resource being measured and limited here is the GEM buffer
objects. User applications allocate and free these buffers. In
addition, a process can allocate a buffer and share it with another
process. The consumer of a shared buffer can also outlive the
allocator of the buffer.
For the
This is a follow up to the RFC I made last november to introduce a cgroup
controller for the GPU/DRM subsystem [a]. The goal is to be able to provide
resource management to GPU resources using things like container. The cover
letter from v1 is copied below for reference.
Usage examples:
//
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring
https://bugs.freedesktop.org/show_bug.cgi?id=110457
--- Comment #7 from Cameron Banfield ---
I am having very similar issues and see similar errors in logs. The most recent
error was:
kernel: amdgpu :06:00.0: [gfxhub] no-retry page fault (src_id:0 ring:24
vmid:1 pasid:32768, for process
[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
[ Upstream commit 2ae2c3316fb77dcf64275d011596b60104c45426 ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
Paul Kocialkowski writes:
> The binner BO is not required until the V3D is in use, so avoid
> allocating it at probe and do it on the first non-dumb BO allocation.
>
> Keep track of which clients are using the V3D and liberate the buffer
> when there is none left, using a kref. Protect the logic
James Clarke writes:
> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
> types, which differs from the BSDs' headers. Thus we should include
> stdint.h to ensure we have all the required integer types.
>
> Signed-off-by: James Clarke
Reviewed-by: Eric Anholt
On Thu, May 9, 2019 at 7:00 PM wrote:
> > -Original Message-
> > From: Theodore Ts'o
> >
> > On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote:
> > > 1) Tests that exercises typically algorithmic or intricate, complex
> > >code with relatively few outside dependencies, or
> Hi,
>
> On 5/1/19 4:01 PM, Brendan Higgins wrote:
> > Add documentation for KUnit, the Linux kernel unit testing framework.
> > - Add intro and usage guide for KUnit
> > - Add API reference
> >
> > Signed-off-by: Felix Guo
> > Signed-off-by: Brendan Higgins
> > ---
> > Documentation/index.rst
Hello,
On Tue, May 07, 2019 at 12:50:50PM -0700, Welty, Brian wrote:
> There might still be merit in having a 'device mem' cgroup controller.
> The resource model at least is then no longer mixed up with host memory.
> RDMA community seemed to have some interest in a common controller at
> least
On Thu, May 9, 2019 at 4:56 PM Petr Mladek wrote:
>
> On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> > console_trylock, called from within printk, can be called from pretty
> > much anywhere. Including try_to_wake_up. Note that this isn't common,
> > usually the box is in pretty bad shape at
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #6 from Jan Vesely ---
Can you post the output of 'clinfo'?
GPU hangs in clover are usually signs of old LLVM, or old mesa (that does not
catch function calls).
Do you use ocl-icd?
if yes can you confirm if the games hang when
On Tue, May 7, 2019 at 12:18 PM Jordan Crouse wrote:
>
> 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
s/NULl/NULL
> if needed.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Kristian H.
Hi Mark,
Den 15.04.2019 10.53, skrev Mark Brown:
> The patch
>
>spi: Add spi_is_bpw_supported()
>
> has been applied to the spi tree at
>
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.2
>
I can't see this in for-5.2 or linux-next. You also gave me a topic
On Tue, May 7, 2019 at 11:02 AM Jordan Crouse wrote:
>
> 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.
Yes please, this has confused me more than once.
On Wed, May 08, 2019 at 10:58:18AM +, Wen He wrote:
> This patch trying to fix monitor freeze issue caused by drm error
> 'flip_done timed out' on LS1028A platform. this set try is make a loop
> around the second setting CVAL and try like 5 times before giveing up.
>
> Signed-off-by: Liviu
>
Oh, I know where this is coming from.
The problem is that we remove the BOs from the LRU during CS and so we
can't wait for the CS to finish up.
Already working on this problem for Marek's similar issue,
Christian.
Am 09.05.19 um 16:46 schrieb Zhou, David(ChunMing):
I know that before, it
On Wed, May 8, 2019 at 10:47 AM Wang Hai wrote:
>
> Fix the following sparse warnings:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce120/dce120_resource.c:483:21:
> warning: symbol 'dce120_clock_source_create' was not declared. Should it be
> static?
>
I know that before, it will issue warning only when debug option is enabled.
Removing that is ok to me.
I only help Prike draft your idea, and Prike is trying this patch on his side.
The latest feedback he gave me is first_bo is always null, code doesn't run
into busy path, which is very
On Thu, May 9, 2019 at 12:12 AM Brian Masney wrote:
>
> On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote:
> > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> >
> > > On Wed, May 8, 2019 at 7:16 PM Brian Masney wrote:
> > > >
> > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn
I've foudn one more problem with this.
With lockdep enabled I get a warning because ttm_eu_reserve_buffers()
has called ww_acquire_done() on the ticket (which essentially means we
are done, no more locking with that ticket).
The simplest solution is probably to just remove the call to
https://bugs.freedesktop.org/show_bug.cgi?id=108898
--- Comment #4 from Eero Tamminen ---
Any updates on this (VegaM) bug? These recoverable hangs are still happening
with git versions of kernel, Mesa and linux-firmware. Unlike with the hard hang
bug 108900, this test-case is freely available.
On Thu, May 09, 2019 at 03:06:09PM +0200, Daniel Vetter wrote:
> On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote:
> > On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > > outside of the spinlock. This
On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote:
> 1) Tests that exercises typically algorithmic or intricate, complex
>code with relatively few outside dependencies, or where the dependencies
>are considered worth mocking, such as the basics of container data
>structures
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: c16fd9be70faf3c49a61700efd16018dd910e390
commit: 6498bf5800a302ef69e7f4914e727893f278bb2f [4/6] drm: revocation check at
drm subsystem
reproduce:
# apt-get install sparse
git checkout
Fixes: 6498bf5800a3 ("drm: revocation check at drm subsystem")
Signed-off-by: kbuild test robot
---
drm_hdcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 5e54095..dc0beb3 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=110381
--- Comment #5 from Nicholas Kazlauskas ---
(In reply to Paul Menzel from comment #4)
> (In reply to Nicholas Kazlauskas from comment #3)
> > We're able to reproduce the problem.
> >
> > I believe that we found the issue was caused by the new
On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote:
> On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > outside of the spinlock. This isn't correct in full generality, but
> > good enough for console_lock:
>
https://bugs.freedesktop.org/show_bug.cgi?id=110381
--- Comment #4 from Paul Menzel ---
(In reply to Nicholas Kazlauskas from comment #3)
> We're able to reproduce the problem.
>
> I believe that we found the issue was caused by the new common helper DRM
> for DP MST hotplug. A fix is in the
https://bugs.freedesktop.org/show_bug.cgi?id=110381
--- Comment #3 from Nicholas Kazlauskas ---
We're able to reproduce the problem.
I believe that we found the issue was caused by the new common helper DRM for
DP MST hotplug. A fix is in the works for this issue.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=107607
--- Comment #8 from Paul Menzel ---
(In reply to Nicholas Kazlauskas from comment #7)
> Can you clarify the problem you're observing?
>
> Do all the displays go blank after switching inputs?
There is exactly one monitor/display.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=110381
--- Comment #2 from Paul Menzel ---
This still happens with Linux 5.1. I had to give the system away, so won’t have
access to it.
I had hoped for more help of the AMD developers to track down regressions.
--
You are receiving this mail
Quoting Daniel Vetter (2019-05-09 13:09:03)
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then lockdep
On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
>
> - console_lock doesn't use interruptible or killable or
On Thu, 09 May 2019, Daniel Drake wrote:
> Hi,
>
>
> On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>>
>> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
>> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
>> > > From: Daniel Drake
>> > >
>> > > On many (all?) the Gemini Lake
https://bugs.freedesktop.org/show_bug.cgi?id=109294
Tvrtko Ursulin changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #39 from Christian Zigotzky ---
Hi All,
Allan has successfully tested the eleventh test kernel.
He wrote:
Christian
DRM11 boots to Firepro.
ace
--
We have a result!
git bisect good
The following commit is responsible for
Quoting Michael Yang (2019-05-09 05:34:11)
> If all the sync points were signaled in both fences a and b,
> there was only one sync point in merged fence which is a_fence[0].
> The Fence structure in android framework might be confused about
> timestamp if there were any sync points which were
Hi,
On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>
> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > > From: Daniel Drake
> > >
> > > On many (all?) the Gemini Lake systems we work with, there is frequent
> > > momentary
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #38 from Christian Zigotzky ---
Hi All,
Allan tested the tenth test kernel today.
He wrote:
Christian
DRM10 also boots to SI card.
ace
--
Link to the test thread:
Hi Dave & Daniel,
Still rather quiet, most issues seem to have been fixed during CI testing.
For i915, just two fixes to the request semaphore ordering code.
For GVT a couple regression and static checker fixes.
Best Regards,
Joonas
***
drm-intel-next-fixes-2019-05-09:
- Two fixes for the
The current buffer check halves the frame rate on non-plus i.MX6Q,
as the IDMAC current buffer pointer is not yet updated when
ipu_plane_atomic_update_pending is called from the EOF irq handler.
Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic update
status")
Tested-by:
On Thu, May 02, 2019 at 03:07:20PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-02 14:56:03)
> > Move the open helper around to avoid the forward decl, and give
> > drm_setup a drm_legacy_ prefix since it's all legacy stuff in there.
> >
> > v2: Move drm_legacy_setup into
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #54 from Marco (rodomar...@protonmail.com) ---
It seems that I've managed to "fix" it by putting the amdgpu module load early
at boot with mkinitcpio.conf; after 30/40 reboots I still haven't seen a crash
since; but since the problem
https://bugs.freedesktop.org/show_bug.cgi?id=110635
--- Comment #2 from tempel.jul...@gmail.com ---
The mesa-git build of mine was from after that commit, and a profile already
applies it to Dying Light as well. :)
--
You are receiving this mail because:
You are the assignee for the
Hi Pekka,
Le lundi 06 mai 2019 à 11:28 +0300, Pekka Paalanen a écrit :
> On Wed, 17 Apr 2019 20:10:15 +0200
> Paul Kocialkowski wrote:
>
> > There's also the possibility of writing up a drm-render DDX to handle
> > these 2D blitters that can make things a lot faster when running a
> > desktop
On Thu, 9 May 2019 at 14:45, Linus Torvalds
wrote:
>
> Dave,
>
> On Wed, May 8, 2019 at 8:28 PM Dave Airlie wrote:
> >
> > This is the main drm pull request for 5.2.
>
> Thanks. I've merged it, but I got a couple of conflicts with fixes
> (reverts) to mainline in the meantime.
>
> The one to the
Dan Carpenter's static analysis tool reported:
drivers/gpu/drm/panfrost/panfrost_drv.c:222 panfrost_ioctl_submit()
error: we previously assumed 'sync_out' could be null (see line 216)
Indeed, sync_out could be NULL if userspace doesn't send a sync object
ID for the out fence.
Signed-off-by:
On Wed, May 08, 2019 at 09:30:42PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-08 13:53:30)
> > On Wed, May 8, 2019 at 2:06 PM Chris Wilson
> > wrote:
> > >
> > > Currently there is an underlying assumption that i915_request_unsubmit()
> > > is synchronous wrt the GPU -- that is
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #5 from Alexander Mezin ---
And BTW with kernel 4.19.40 and latest git firmware
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=2579167548be33afb1fe2a9a5c141561ee5a8bbe)
monitors switch off on
On 5/8/19 6:44 PM, Theodore Ts'o wrote:
> On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote:
>>
>> If KUnit is added to the kernel, and a subsystem that I am submitting
>> code for has chosen to use KUnit instead of kselftest, then yes, I do
>> *have* to use KUnit if my submission needs
On 5/8/19 6:58 PM, Theodore Ts'o wrote:
> On Wed, May 08, 2019 at 05:43:35PM -0700, Frank Rowand wrote:
>> kselftest provides a mechanism for in-kernel tests via modules. For
>> example, see:
>>
>> tools/testing/selftests/vm/run_vmtests invokes:
>> tools/testing/selftests/vm/test_vmalloc.sh
The documentation the `_match_string()` helper mentions that `n`
should be:
* @n: number of strings in the array or -1 for NULL terminated arrays
The behavior of the function is different, in the sense that it exits on
the first NULL element in the array, regardless of whether `n` is -1 or a
The msm_gem_object structure contains resv and _resv fields that are
no longer needed since the reservation object is now stored on
drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb()
both referenced the wrong reservation object, and would lead to an
attempt to dereference a NULL
The `lcd_types` array is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.
This reduces the array by 1 element, since the NULL (at the end of the
array) is no longer needed.
Signed-off-by: Alexandru Ardelean
---
The change is mostly cosmetic.
The `armada_37xx_pin_group` struct is defined as.
struct armada_37xx_pin_group {
const char *name;
unsigned intstart_pin;
unsigned intnpins;
u32 reg_mask;
u32 val[NB_FUNCS];
From: Allen Chen
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
Signed-off-by: Jitao Shi
Signed-off-by: Yilun Lin
Signed-off-by: Allen Chen
---
drivers/gpu/drm/bridge/Kconfig | 22 +
drivers/gpu/drm/bridge/Makefile |1 +
> -Original Message-
> From: Wen He
> Sent: 2019年5月8日 17:42
> To: dri-devel@lists.freedesktop.org; p.za...@pengutronix.de
> Cc: Leo Li ; Wen He
> Subject: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE
>
> The new LS1028A DP driver code causes a link failure when DRM_IMX
The change is mostly cosmetic.
The `energy_perf_strings` array is static, so match_string() can be used
(which will implicitly do a ARRAY_SIZE(energy_perf_strings)).
The only small benefit here, is the reduction of the array size by 1
element.
Signed-off-by: Alexandru Ardelean
---
The new LS1028A DP driver code causes a link failure when DRM_IMX built-in,
but platform is ARCH_LAYERSCAPE:
drivers/gpu/drm/imx/ipuv3-crtc.c:51: undefined reference to `ipu_prg_enable'
drivers/gpu/drm/imx/ipuv3-crtc.c:52: undefined reference to `ipu_dc_enable'
On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean wrote:
> This change re-introduces `match_string()` as a macro that uses
> ARRAY_SIZE() to compute the size of the array.
> The macro is added in all the places that do
> `match_string(_a, ARRAY_SIZE(_a), s)`, since the change is pretty
On Wed 08 May 19:25 PDT 2019, Rob Clark wrote:
> On Wed, May 8, 2019 at 7:16 PM Brian Masney wrote:
> >
> > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > >
This patch trying to fix monitor freeze issue caused by drm error
'flip_done timed out' on LS1028A platform. this set try is make a loop
around the second setting CVAL and try like 5 times before giveing up.
Signed-off-by: Liviu
Signed-off-by: Wen He
---
drivers/gpu/drm/arm/malidp_drv.c | 13
Add the MDP5, DSI and DSI PHY blocks for the display found on the
msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan
Marek.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
Changes since v1:
- None
arch/arm/boot/dts/qcom-msm8974.dtsi | 132
On Wed, 2019-05-08 at 15:20 +0300, Dan Carpenter wrote:
>
>
> On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
> > -static const char * const phy_types[] = {
> > - "emmc 5.0 phy",
> > - "emmc 5.1 phy"
> > -};
> > -
> > enum xenon_phy_type_enum {
> >
From: Allen Chen
Add a DT binding documentation for IT6505.
Signed-off-by: Allen Chen
---
.../bindings/display/bridge/ite,it6505.txt | 30 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 31 insertions(+)
create mode 100644
The `rdmacg_resource_names` array is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.
The change is mostly cosmetic.
No functionality change.
Signed-off-by: Alexandru Ardelean
---
kernel/cgroup/rdma.c | 2 +-
1 file changed, 1
1 - 100 of 137 matches
Mail list logo
