https://bugs.freedesktop.org/show_bug.cgi?id=105423
Max changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Peter,
thanks a million for the extensive testing and reviewing.
I'll go through the issues you've found below, but it appears to me
that they're all either in the "works as intended" category or are
caused by something unrelated to this series:
On Mon, Mar 05, 2018 at 09:58:31PM +0100, Pete
Hi,
On Friday 09 March 2018 07:21 PM, Jacopo Mondi wrote:
Hello,
after some discussion on the proposed bindings for generic lvds decoder and
Thine THC63LVD1024, I decided to drop the THC63 specific part and just live with
a transparent decoder that does not support any configuration from DT.
https://bugs.freedesktop.org/show_bug.cgi?id=105379
--- Comment #3 from Andrew Sheldon ---
(In reply to Matias N. Goldberg from comment #2)
> I'm no mesa dev but could you test with and before
> bc65dcab3bc48673ff6180afb036561a4b8b1119 ?
>
> This might be a dupe of https://bugs.freedesktop.org/s
From: Jérôme Glisse
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 17
drivers/gpu/drm/nouveau/include/nvif/vmm.h| 2 +
drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 25
drivers/gpu/drm/nouveau/nvif/vmm.c
From: Jérôme Glisse
HMM does not have any of the usual memory object properties. For HMM
inside any range the following is true:
- not all page in a range are valid
- not all page have same permission (read only, read and write)
- not all page are in same memory (system memory, GPU me
From: Jérôme Glisse
Allow userspace to create a virtual address range hole for GEM
object.
Signed-off-by: Jérôme Glisse
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm
From: Jérôme Glisse
Helpers to create area of virtual address under HMM control for a nouveau
client. GPU access to HMM area are valid as long as the hole vma exist in
the process virtual address space.
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_hmm.c | 28
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
index 059fafe0e771..
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvif/class.h | 2 +
drivers/gpu/drm/nouveau/include/nvif/clb069.h | 8 ++
.../gpu/drm/nouveau/include/nvkm/engine/fault.h| 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +
drivers
From: Jérôme Glisse
User API to create HMM area.
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 9 +
drivers/gpu/drm/nouveau/include/nvif/vmm.h | 2 +
drivers/gpu/drm/nouveau/nvif/vmm.c | 51 ++
dr
From: Jérôme Glisse
SVM (Share Virtual Memory) through HMM (Heterogeneous Memory Management)
to nouveau client. SVM means that any valid pointer (private anonymous,
share memory or mmap of regular file) on the CPU is also valid on the
GPU. To achieve SVM with nouveau we use HMM kernel infrastruct
From: Jérôme Glisse
HMM area is a virtual address range under HMM control, GPU access inside
such range is like CPU access. For thing to work properly HMM range should
cover everything except a reserved range for GEM buffer object.
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/d
From: Jérôme Glisse
This patch modify the page table iterator to support empty range when
unmaping a range (ie when it is not trying to populate the range).
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 75 ++-
1 file c
From: Jérôme Glisse
Adds support for 64-bits read.
Signed-off-by: Jérôme Glisse
---
drivers/gpu/drm/nouveau/include/nvkm/core/memory.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
b/drivers/gpu/drm/nouveau/include/nvkm/core/mem
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvkm/core/device.h | 3 +++
drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h | 4
drivers/gpu/drm/nouveau/nvkm/core/subdev.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/Kbuild | 1 +
drivers
From: Jérôme Glisse
(mm is cced just to allow exposure of device driver work without ccing
a long list of peoples. I do not think there is anything usefull to
discuss from mm point of view but i might be wrong, so just for the
curious :)).
git://people.freedesktop.org/~glisse/linux branch: nouve
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.c | 20 +++-
drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h | 2 ++
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=105426
--- Comment #2 from Józef Kucia ---
Please attach the full terminal output.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=105423
--- Comment #2 from Max ---
Thanks to Nick Sarnie on Discord, he found that disable completely DC fix the
issue.
I fix it with "amdgpu.dc=0" in my grub.conf
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=105426
--- Comment #1 from i...@yahoo.com ---
The problem appears with Wine-3.0rc1 or newer (including Wine-3.3).
It does not appear with Wine-2.22.
--
You are receiving this mail because:
You are the assignee for the bug._
On Thu, 2018-03-08 at 09:22 +0200, Jani Nikula wrote:
> On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote:
> >
> > From: Matt Atwood
> >
> > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme
> > from 8
> > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> >
This fixes bad color output. When I was first testing the device I
had the DPI hardware set to 666 mode, but apparently in the refactor
to use the bus_format information from the panel driver, I failed to
actually update the panel.
Signed-off-by: Eric Anholt
Fixes: e8b6f561b2ee ("drm/panel: simp
In the cleanup, I didn't notice that we needed to dereference the
connector for the bus_format. Fix the regression by looking up the
first (and only) connector attached to us, and assume that its
bus_format is what we want. Some day it would be good to have that
part of display_info attached to t
On Fri, Mar 09, 2018 at 04:40:16PM +0100, Sylwester Nawrocki wrote:
> The #sound-dai-cells DT property is required to describe link between
> the HDMI IP block and the SoC's audio subsystem.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes since v2:
> - the property has been moved to "Requi
https://bugs.freedesktop.org/show_bug.cgi?id=105426
Alex Deucher changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
Use the newly exposed VSP1 interface to enable interlaced frame support
through the VSP1 lif pipelines.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/r
https://bugs.freedesktop.org/show_bug.cgi?id=105379
--- Comment #2 from Matias N. Goldberg ---
I'm no mesa dev but could you test with and before
bc65dcab3bc48673ff6180afb036561a4b8b1119 ?
This might be a dupe of https://bugs.freedesktop.org/show_bug.cgi?id=105339
Unless you're sure your error
https://bugs.freedesktop.org/show_bug.cgi?id=105339
Matias N. Goldberg changed:
What|Removed |Added
Summary|Deadlock inside |Deadlock inside
https://bugs.freedesktop.org/show_bug.cgi?id=105339
--- Comment #5 from Matias N. Goldberg ---
I traced the regression to commit:
commit bc65dcab3bc48673ff6180afb036561a4b8b1119
Author: Nicolai Hähnle
Date: Fri Nov 10 10:58:10 2017 +0100
radeonsi: avoid syncing the driver thread in si_fe
https://bugs.freedesktop.org/show_bug.cgi?id=101672
--- Comment #26 from MirceaKitsune ---
Moved to a new bug report which addresses the new issue with fresh logs:
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=101672
MirceaKitsune changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
Retraining MST is rather difficult. In order to do it properly while
guaranteeing that we'll never run into a spot where we commit a
physically impossible configuration, we have to do a lot of checks on
atomic commits which affect MST topologies. All of this work is going to
need to be repeated for
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if t
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps tha
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're d
https://bugs.freedesktop.org/show_bug.cgi?id=105423
--- Comment #1 from Max ---
Ok, i found an interesting thing. I have this issue when i unbind my GPU on
Kernel 4.15 but i have no issue when i do it on kernel 4.14.
I'll try to git bisect between kernel 4.15 and kernel 4.14.
--
You are receiv
Ville Syrjala writes:
> From: Ville Syrjälä
>
> Only create framebuffers with supported format/modifier combinations by
> checking that at least one plane supports the requested combination.
>
> Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
> the planes have (mostly) unif
Stefan Schake writes:
> This series improves the handling of alpha formats with the VC4 HVS
> compositor. Alpha formats are marked as premultiplied as is standard
> for DRM. Further fix a display corruption issue when planes with
> per-pixel alpha try blending from the (nonexistent) background by
Instead of relying on the DRM functions just implement our own export
functions. This adds support for taking care of unpinned DMA-buf.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 -
drivers/gpu/drm/amd/a
Make sure the transfered BO is never destroy before the transfer BO.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu
This set of patches adds an option invalidate_mappings callback to each DMA-buf
attachment which can be filled in by the importer.
This callback allows the exporter to provided the DMA-buf content without
pinning it. The reservation objects lock acts as synchronization point for
buffer moves an
Instead of relying on the DRM functions just implement our own import
functions. This adds support for taking care of unpinned DMA-buf.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 64 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 25 +
include/linux/dma-buf.h | 36
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 25 +
include/linux/dma-buf.h | 36
https://bugs.freedesktop.org/show_bug.cgi?id=105423
Bug ID: 105423
Summary: Unable to unbind my 2nd GPU (Rx580)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severi
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #45 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
(In reply to Michel Dänzer from comment #43)
> (In reply to Ricardo Ribalda from comment #42)
> > With current LLVM7 master X does not start at all. I get the following
> > outpu
https://bugzilla.kernel.org/show_bug.cgi?id=198883
Nicolai Hähnle (nhaeh...@gmail.com) changed:
What|Removed |Added
CC||nhaeh...@gmail.com
Rob Herring wrote on Fri [2018-Mar-02 13:19:13 -0600]:
> On Fri, Mar 2, 2018 at 7:48 AM, Benoit Parrot wrote:
> > Add 'plane' child node to generic DISPC node as an optional
> > property.
>
> Why? What problem are you solving?
Ah yes, I guess on its own it does not mean much...
How about:
Cur
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 4
drivers/gpu/drm/i915/intel_color.c| 8
drivers/gpu/drm/i915/intel_drv.h
Implement Plane Gamma feature for BDW and Gen9 platforms.
v2: Used newly added drm_color_lut_ext structure for enhanced
precision for Gamma LUT entries.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c | 5 +++-
drivers/gpu/drm/i915/i915_reg.h | 24 +++
driv
Enable and initialize plane color features.
v2: Rebase and some cleanup
v3: Updated intel_plane_color_init to call
drm_plane_color_create_prop function, which will
in turn create plane color properties.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers
Define helper function to enable Plane color features
to attach plane color properties to plane structure.
v2: Rebase
v3: Modiefied the function to use updated property names.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 42 ++
include/d
Add plane gamma as blob property and size as a
range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documen
Add a blob property for plane CSC usage.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by
Add Plane Degamma as a blob property and plane degamma size as
a range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Adde
This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data, CSC used for gamut
conversion, and gamma used to again non-linearize data as per panel
supported color space. These can be utilize by user space to convert
planes from one format to an
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.
S
Hi Dave,
Here are the -misc-next pulls for the last 2 weeks. Sorry for the hold-up
last week.
drm-misc-next-2018-03-09-3:
drm-misc-next for 4.17:
UAPI Changes:
plane: Add color encoding/range properties (Jyri)
nouveau: Replace iturbt_709 property with color_encoding property (Ville)
Core Chan
On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote:
> (I wrote an email that seems to have been lost)
>
> Quoting Jordan Crouse (2018-03-09 08:03:55)
> > On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote:
> > > On 08-03-18, 13:14, Jordan Crouse wrote:
> > > > It seems to me th
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #17 from omegap...@startmail.com ---
The patch was not enough, and my comments on that bug have been ignored - the
key bit is:
I've tracked part of the problem
On 03/09/2018 04:51 PM, Jacopo Mondi wrote:
> The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
> to the on-chip LVDS encoder output on one side and to HDMI encoder
> ADV7511w on the other one.
>
> As the decoder does not need any configuration it has been so-far
> omitted
https://bugs.freedesktop.org/show_bug.cgi?id=105308
--- Comment #13 from Michel Dänzer ---
https://patchwork.freedesktop.org/patch/209464/ fixes this for me with DC
disabled.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #16 from Michel Dänzer ---
(In reply to OmegaPhil from comment #15)
> I'm going to sit on this for a week to make sure its actually solved.
A month has passed, is there a verdict yet?
--
You are receiving this mail because:
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=103791
--- Comment #21 from Michel Dänzer ---
(In reply to Anthony Parsons from comment #18)
> Running xrandr doesn't seem to work as a workaround but flipping VTs does.
Have you tried turning it off and on again? (Who gets the reference? :)
xrandr -
(I wrote an email that seems to have been lost)
Quoting Jordan Crouse (2018-03-09 08:03:55)
> On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote:
> > On 08-03-18, 13:14, Jordan Crouse wrote:
> > > It seems to me that performance_state has a direct relationship with genpd
> > > which is g
On Friday, 2018-03-09 15:48:51 +, Emil Velikov wrote:
> On 9 March 2018 at 11:47, Eric Engestrom wrote:
>
> >> > + dep_atomic_ops = []
> >> >
> >> The dummy dep_atomic_ops is needed for almost all cases in the if/else
> >> ladder. The exception being the .found() case.
> >
> > Actually,
Hi Linus,
Please pull fbdev fix for v4.16-rc5 (just a single fix to close
kernel data leak in FBIOGETCMAP_SPARC ioctl).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:
Li
https://bugs.freedesktop.org/show_bug.cgi?id=105369
--- Comment #10 from cd ---
A freeze occured while working with the laptop:
uname -r
4.16.0-rc1-085145ebf0e9
[20516.321517] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=448660, last emitted seq=448663
[20516.3
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #43 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Ricardo Ribalda from comment #42)
> With current LLVM7 master X does not start at all. I get the following
> output:
Did you recompile current Mesa Git master against that a
On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote:
> On 08-03-18, 13:14, Jordan Crouse wrote:
> > It seems to me that performance_state has a direct relationship with genpd
> > which is good for CPU votes but in this case, we're just passing along raw
> > data
> > to an independent micr
https://bugzilla.kernel.org/show_bug.cgi?id=198985
--- Comment #3 from Fredrik (fred...@planet-express.se) ---
Still missing from 4.15.8
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-de
On 9 March 2018 at 11:47, Eric Engestrom wrote:
>> > + dep_atomic_ops = []
>> >
>> The dummy dep_atomic_ops is needed for almost all cases in the if/else
>> ladder. The exception being the .found() case.
>
> Actually, because of the way the `if` chain is written, the dep_atomic_ops
> has to
On Fri, Mar 09, 2018 at 03:49:00PM +0530, Rajendra Nayak wrote:
> Hey Jordan/Viresh,
>
> On 03/09/2018 09:13 AM, Viresh Kumar wrote:
> > On 08-03-18, 13:14, Jordan Crouse wrote:
> >> It seems to me that performance_state has a direct relationship with genpd
> >> which is good for CPU votes but in
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #42 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
With current LLVM7 master X does not start at all. I get the following output:
root@qt5122:~# X
X.Org X Server 1.19.3
Release Date: 2017-03-15
X Protocol Version 11, Revision 0
The #sound-dai-cells DT property is required to describe link between
the HDMI IP block and the SoC's audio subsystem.
Signed-off-by: Sylwester Nawrocki
---
Changes since v2:
- the property has been moved to "Required properties" paragraph,
I didn't add Rob's Reviewed-by due to this change
--
From: Ville Syrjälä
Replace the messy framebuffer format/modifier validation code
with a single call to drm_any_plane_has_format(). The code was
extremely annoying to maintain as you had to have a lot of platform
checks for different formats. The new code requires zero maintenance.
v2: Nuke the
From: Ville Syrjälä
Only create framebuffers with supported format/modifier combinations by
checking that at least one plane supports the requested combination.
Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
the planes have (mostly) uniform capabilities. But I was lazy and
From: Ville Syrjälä
Put an empty line between the variable declarations and the code, and
use tabs for alignment.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_framebuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/dri
From: Ville Syrjälä
Add a function to check whether there is at least one plane that
supports a specific format and modifier combination. Drivers can
use this to reject unsupported formats/modifiers in .fb_create().
v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_fo
https://bugs.freedesktop.org/show_bug.cgi?id=104201
--- Comment #2 from Harry Wentland ---
Our display code in 4.15 would mostly be older than the version of
amd-staging-drm-next that you tested earlier.
Would you be able to give amd-staging-drm-next a spin again and see if it's
still an issue t
Hi Russell,
On Fri, Mar 9, 2018 at 8:34 AM, Russell King - ARM Linux
wrote:
> On Fri, Mar 09, 2018 at 12:20:59PM +0100, Lucas Stach wrote:
>> All the DRM GEM dma-buf import/export operations are done through the
>> virtual DRM master device. As this isn't instanciated from DT anymore
>> we need t
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #16 from Harry Wentland ---
The ticket is on our backlog and we'll try to get to it in a week or so.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=100919
Thomas R. changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Fri, Mar 09, 2018 at 11:07:14AM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal
>
> If the user-space does not support aspect-ratio, then getblob called
> with the blob id of a user-mode, should clear the aspect-ratio
> information in the blob data.
>
> Currently for a given blob id, t
https://bugs.freedesktop.org/show_bug.cgi?id=104201
--- Comment #1 from Vedran Miletić ---
This seems to no longer be the case in 4.15.7 (I should note, after a clean
reinstall of Fedora for an unrelated reason), did anything change?
--
You are receiving this mail because:
You are the assignee
Hi Russell,
Am Freitag, den 09.03.2018, 11:44 + schrieb Russell King - ARM Linux:
> Hi Lucas,
>
> Please retain my authorship of my patch, which was sent on 23 Oct 2017.
> The patch you have below is 100% identical to that which I sent.
I'll gladly do so if you provide me a proper Signed-off
On Thursday, 2018-03-08 18:10:03 +, Emil Velikov wrote:
> On 5 March 2018 at 12:03, Eric Engestrom wrote:
> > Ping? :)
> > Both for this patch and the equivalent autotools patch it replies to.
> >
> The autotools one needs the CFLAGS added - meson does it automatically for us.
I'll let Peter
Apologies if this is not the right list for this question. Kernel
MAINTAINERS file suggests it is but please let me know if I should
repost elsewhere.
I have a custom OpenCL application running under Ubuntu 16.04.04, HWE
Kernel 4.13 and amdgpu-pro 17.50 drivers. This is running on a Fujitsu
D
Am Dienstag, den 13.02.2018, 16:36 -0200 schrieb Fabio Estevam:
> > From: Fabio Estevam
>
> etnaviv_sched_dependency() and etnaviv_sched_run_job() are only
> used in this file, so make them static.
>
> This fixes the following sparse warnings:
>
> drivers/gpu/drm/etnaviv/etnaviv_sched.c:30:18:
The old way did clamp the jiffy conversion and thus caused the timeouts
to become negative after some time. Also it didn't work with userspace
which actually fills the upper 32bits of the 64bit timestamp value.
Fix this by using the solution developed and tested by Russell.
Suggested-by: Russell
All the DRM GEM dma-buf import/export operations are done through the
virtual DRM master device. As this isn't instanciated from DT anymore
we need to make sure the DMA ops are set up correctly.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ++-
1 file changed, 2 inser
On 03/09/2018 03:35 AM, Inki Dae wrote:
> 2018년 03월 08일 20:22에 Sylwester Nawrocki 이(가) 쓴 글:
>> On 03/08/2018 09:15 AM, Inki Dae wrote:
[...]
>>> Is there a possibility for other boards based on Exynos4210/4212/5420/5433
>>> SoC to use this property later?
>>
>> All these SoCs have the HDMI IP bloc
Hey,
On 03/09/2018 10:55 AM, Alexandru-Cosmin Gheorghe wrote:
Hi Daniel,
On Fri, Mar 09, 2018 at 09:29:24AM +, Daniel Stone wrote:
Hi John,
On 8 March 2018 at 19:43, John Stultz wrote:
On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
@@ -76,8 +76,6 @@ uint32_t
DrmGenericImporter::C
On 9 March 2018 at 10:59, Eric Engestrom wrote:
> On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wvla, remove VLA usage.
>>
>> Also, fixed as part of the directive to remove all VLAs from
>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>
>> Sig
On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA usage.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva
Sorry for my reply on
https://bugs.freedesktop.org/show_bug.cgi?id=105414
Bug ID: 105414
Summary: R9 285 agd5f 4.17-wip DC flip_done timed out
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Hey Jordan/Viresh,
On 03/09/2018 09:13 AM, Viresh Kumar wrote:
> On 08-03-18, 13:14, Jordan Crouse wrote:
>> It seems to me that performance_state has a direct relationship with genpd
>> which is good for CPU votes but in this case, we're just passing along raw
>> data
>> to an independent microc
On Wednesday, 2018-03-07 13:47:03 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with a fixed-length array instead. Also, remove variable 'len'.
>
> Notice that no new IDs have been added in seven years.
>
> Signed-off-by: Gustavo A. R. Silva
>
1 - 100 of 128 matches
Mail list logo
