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
signature.
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
[ 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:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8:
[ 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:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8:
[ 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:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8:
[ 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:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1521:2-8:
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 Xorg
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 t
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:
// se
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 pu
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 mode
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 1006
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 changed,
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 th
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 git://people.fr
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
> framework
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 s
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 And
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 loc
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 A5
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: Gwan-
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 in
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 4:
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 H
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 1.5.
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 4:4:4.
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
Video_Stream_Conf
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
forYCbCr4
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 fi
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 t
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
--
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 0
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
Platfor
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
> a
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: N
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.___
dri-de
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 path
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 sta
https://bugs.freedesktop.org/show_bug.cgi?id=101473
qmaster...@gmail.com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
101 - 140 of 140 matches
Mail list logo
