> -Original Message-
> From: YueHaibing [mailto:yuehaib...@huawei.com]
> Sent: Thursday, November 08, 2018 10:15 AM
> To: Koenig, Christian ; Huang, Ray
> ; Zhang, Jerry ; David Airlie
>
> Cc: YueHaibing ; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org;
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #41 from bmil...@gmail.com ---
Guys, please take a closer look at this, its actually a lot worse than what OP
describes and affect a lot of other use cases, vsync is a vital feature for any
kind of PC activity, literally everything
https://bugs.freedesktop.org/show_bug.cgi?id=107261
--- Comment #11 from Brad ---
To add to my previous comment, this tends to happen when:
1) Resuming from suspend
2) Automatically powering the monitors back on even if the computer had not
suspended (e.g., after turning off due to powersave)
https://bugs.freedesktop.org/show_bug.cgi?id=107261
--- Comment #10 from Brad ---
Getting a similar error (AMD Ryzen 1700 with Radeon RX 550 with ASUS Prime B450
plus motherboard).
---
Nov 07 19:50:39 phoenix kernel: ata2: softreset failed (device not ready)
Nov 07 19:50:44 phoenix kernel:
Hi Dave,
Fixes for 4.20:
- DC MST fixes
- DC FBC fix
- Vega20 updates to support the latest vbios
- KFD type fixes for ioctl headers
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the git repository at:
https://bugzilla.kernel.org/show_bug.cgi?id=201625
--- Comment #13 from drigohighlander (drigos...@gmail.com) ---
No, the blender used is the 64bits version. (I checked now), and, besides that,
I dont have a multlib system installed necessary to run 32 bits programs on 64
bits system.
Note that
https://bugzilla.kernel.org/show_bug.cgi?id=201625
--- Comment #14 from drigohighlander (drigos...@gmail.com) ---
No, the blender used is the 64bits version. (I checked now), and, besides that,
I dont have a multlib system installed necessary to run 32 bits programs on 64
bits system.
Note that
On 11/8/18 10:15 AM, YueHaibing wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function
'ttm_eu_fence_buffer_objects':
drivers/gpu/drm/ttm/ttm_execbuf_util.c:190:24: warning:
variable 'driver' set but not used [-Wunused-but-set-variable]
It
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
Same thing we did in i915, but for nouveau now.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
include/drm/drm_dp_mst_helper.h | 77 +
1 file changed, 77 insertions(+)
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 59f005b419cf..3faceb66f5cb 100644
---
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.
Cc: Daniel Vetter
Lyude Paul (5):
drm/dp_mst: Add some
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
It was parsing the manufacturer id of the sink for each entry in
quirk list.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_edid.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
This function will be helpful to drivers that wants to add its own
quirks to sinks.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_edid.c | 20
include/drm/drm_edid.h | 1 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git
>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, November 6, 2018 6:40 PM
>To: Srivatsa, Anusha
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Ville
>Syrjala
>; Jani Nikula
>Subject: Re: [v7 1/4] i915/dp/fec: Add fec_enable to the crtc state.
>
>On
On Wed, 2018-11-07 at 22:59 +0100, Daniel Vetter wrote:
> On Wed, Nov 07, 2018 at 04:39:57PM -0500, Lyude Paul wrote:
> > On Wed, 2018-11-07 at 16:23 -0500, Lyude Paul wrote:
> > > On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote:
> > > > On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul
For reasons that I'm sure made perfect sense at the time we were
opting to defer the iova alloc / pin on the ringbuffer until HW
init time so when we moved to iova reference counting we ended
up adding a reference count every time the hardware started.
Not that it mattered (because the ring is
For debugging purposes it is useful to assign descriptions
to buffers so that we know what they are used for. Add
a field to the buffer object and use that to name the various
kernel side allocations which ends up looking like like this
in /d/dri/X/gem:
flags id ref offset kaddr
Add a new function to get and pin the iova memory in one
step (basically renaming the old msm_gem_get_iova function)
and switch msm_gem_get_iova() to only allocate an iova but
not map it in the IOMMU. This is only currently used by
msm_ioctl_gem_info() since all other users of of the iova
expect
Add a reference count to track how many times a particular
chunk of iova memory is pinned (mapped) in the iomu and
add msm_gem_unpin_iova to give up references.
It is important to note that msm_gem_unpin_iova replaces
msm_gem_put_iova because the new implicit behavior
that an assigned iova in a
Add headers for the 'gem' debugfs file to make it easier to remember
what all the values mean and move the list of virtual address regions
to the next line and add the name and map status to make it clearer
what we are looking at.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem.c |
Add a name field to struct drm_msm_gem_new to allow userspace
to specify a name/description for gem buffers to improve
debugging and tracking.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 5 +++--
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 16
Buffer objects allocated with msm_gem_kernel_new() are mostly
freed the same way so we can save a few lines of code with a
common function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 ++---
drivers/gpu/drm/msm/adreno/a5xx_power.c | 13 +
The scatter gather table doesn't need to be passed in for the
MMU unmap function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 4 ++--
drivers/gpu/drm/msm/msm_iommu.c | 3 +--
Split the operation of msm_gem_get_iova into two operations:
1) allocate an iova and 2) map (pin) the backing memory int the
iommu. This is the first step toward allowing memory pinning
to occur independently of the iova management.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h
Currently in the msm driver iova addresses are mapped in the IOMMU at
allocation time and stay there for the life of the buffer. This may not
be desirable for long lived user space buffers that could be temporarily
swapped or moved.
This first set of patches breaks up the allocation and mapping
On Tue, Nov 06, 2018 at 12:37:59PM -0800, Manasi Navare wrote:
> On Tue, Nov 06, 2018 at 04:42:56PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 02, 2018 at 07:09:03PM -0700, Manasi Navare wrote:
> > > On Fri, Nov 02, 2018 at 02:31:26PM -0700, Manasi Navare wrote:
> > > > DSC params like the
https://bugs.freedesktop.org/show_bug.cgi?id=108096
Dieter Nützel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #32 from Duncan Roe ---
X displays normally with this patch set (as amended) applied to Linux 4.19.1
commit 07a03b97b9ce2a6430344386eeab9b16283b893f on branch linux-4.19.y of the
stable tree.
There was an oddity the first time I
https://bugs.freedesktop.org/show_bug.cgi?id=108096
Dieter Nützel changed:
What|Removed |Added
Resolution|NOTOURBUG |FIXED
--- Comment #26 from Dieter
On Wed, Nov 07, 2018 at 04:39:57PM -0500, Lyude Paul wrote:
> On Wed, 2018-11-07 at 16:23 -0500, Lyude Paul wrote:
> > On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote:
> > > On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote:
> > > > There has been a TODO waiting for quite a long
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #78 from Scott Moreau ---
This also happens to me exactly as described in comment #75 when running a
freesync monitor @75Hz. The problem is fixed with high or low dpm setting as in
the comment, auto setting has the problem. This is
On Wed, 2018-11-07 at 16:23 -0500, Lyude Paul wrote:
> On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote:
> > On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote:
> > > There has been a TODO waiting for quite a long time in
> > > drm_dp_mst_topology.c:
> > >
> > > /* We cannot rely
On Wed, Nov 7, 2018 at 4:13 PM Daniel Vetter wrote:
>
> On Wed, Nov 07, 2018 at 03:55:33PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Add a description for dev and remove the excess one for native. Fixes
> > the following warnings:
> >
> > ../drivers/gpu/drm/drm_fourcc.c:112: warning:
On Wed, 2018-11-07 at 21:59 +0100, Daniel Vetter wrote:
> On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote:
> > There has been a TODO waiting for quite a long time in
> > drm_dp_mst_topology.c:
> >
> > /* We cannot rely on port->vcpi.num_slots to update
> > *
https://bugzilla.kernel.org/show_bug.cgi?id=201625
--- Comment #12 from Alex Deucher (alexdeuc...@gmail.com) ---
Are you running a 32 bit blender on a 64 bit distro? Maybe you don't have the
32 bit OpenGL driver installed?
--
You are receiving this mail because:
You are watching the assignee
On Wed, Nov 07, 2018 at 03:55:33PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Add a description for dev and remove the excess one for native. Fixes
> the following warnings:
>
> ../drivers/gpu/drm/drm_fourcc.c:112: warning: Function parameter or member
> 'dev' not described in
On Tue, Nov 06, 2018 at 08:21:14PM -0500, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
>
> /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>*
From: Sean Paul
Add a description for dev and remove the excess one for native. Fixes
the following warnings:
../drivers/gpu/drm/drm_fourcc.c:112: warning: Function parameter or member
'dev' not described in 'drm_driver_legacy_fb_format'
../drivers/gpu/drm/drm_fourcc.c:112: warning: Excess
Hi Dave,
First fixes pull for 4.20, some NULL protection for sun4i.
drm-misc-fixes-2018-11-07:
- sun4i: tcon->panel NULL deref protections (Giulio)
Cc: Giulio Benetti
Cheers, Sean
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04
On Wed, Nov 07, 2018 at 09:31:51PM +0100, Daniel Vetter wrote:
> On Wed, Nov 7, 2018 at 9:29 PM Sean Paul wrote:
> >
> > On Wed, Nov 07, 2018 at 09:18:16PM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote:
> > > > Hey Dave,
> > > >
> > > > First
On Fri, Oct 19, 2018 at 11:29:49AM +0200, Daniel Vetter wrote:
> On Fri, Oct 19, 2018 at 11:27:11AM +0200, Christian König wrote:
> > From: Christian König
> >
> > Still contains some bugs.
> >
> > This reverts commit 48197bc564c7a1888c86024a1ba4f956e0ec2300.
>
> Thanks for the super-quick
On Wed, Nov 7, 2018 at 9:29 PM Sean Paul wrote:
>
> On Wed, Nov 07, 2018 at 09:18:16PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote:
> > > Hey Dave,
> > >
> > > First pull for drm-next this cycle. There's been a lot of changes, so I
> > > hope
From: Colin Ian King
The allocation for vfpriv is being leaked on an error return path,
fix this by kfree'ing it before returning.
Detected by CoverityScan, CID#1475380 ("Resource Leak")
Fixes: 6a37c49a94a9 ("drm/virtio: Handle context ID allocation errors")
Signed-off-by: Colin Ian King
---
On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote:
> Hey Dave,
>
> First pull for drm-next this cycle. There's been a lot of changes, so I
> hope I recorded everything from the changelog correctly.
>
> drm-misc-next-2018-11-07:
> drm-misc-next for v4.21, part 1:
>
> UAPI
On Wed, Nov 07, 2018 at 09:18:16PM +0100, Daniel Vetter wrote:
> On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote:
> > Hey Dave,
> >
> > First pull for drm-next this cycle. There's been a lot of changes, so I
> > hope I recorded everything from the changelog correctly.
> >
> >
On 11/06/2018 06:28 PM, Brendan Higgins wrote:
> On Fri, Nov 2, 2018 at 11:44 AM Shuah Khan wrote:
>>
>> On 10/23/2018 05:57 PM, Brendan Higgins wrote:
>
>>> + * Example:
>>> + *
>>> + * .. code-block:: c
>>> + *
>>> + * void add_test_basic(struct test *test)
>>> + * {
>>> + *
Thanks for noticing this one! With the changes that Ville mentioned in their
response:
Reviewed-by: Lyude Paul
If you need me to push this for you; poke me here or on IRC
On Wed, 2018-11-07 at 18:11 +0200, Stanislav Lisovskiy wrote:
> Unfortunately drm_dp_get_mst_branch_device which is called
Do some cleanup in the static inline functions defined in
dpu_media_info.h by cleaning up gotos and unneeded local
variables.
v3: Added spaces between operators per Seal Paul and Sam Ravnborg
Signed-off-by: Jordan Crouse
---
.../gpu/drm/msm/disp/dpu1/msm_media_info.h| 164
Remove more static inline functions that are lightly used and/or
very simple and easy to build into the calling functions.
v3: Removed uneeded parens per Sean Paul
v2: Removed another unused function from dpu_hw_lm.c and add back
dpu_crtc_get_client_type() since there was a question regarding
its
Reviewed-by: Dylan Baker
Quoting Eric Engestrom (2018-11-07 08:50:30)
> Signed-off-by: Eric Engestrom
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 49bf2f740fb3627f2948..5ef17fc11fee25f98b3d 100644
> ---
On Tue, 6 Nov 2018 11:52:36 +
Fabrizio Castro wrote:
> While adding SiI9022A support to the iwg23s board, it came
> up that when the HDMI transmitter is in pass through mode the
> device is not compliant with the I2C specification anymore,
> as it requires a far bigger tbuf, due to a delay
On Tue, Nov 06, 2018 at 04:30:16PM -0500, Lyude Paul wrote:
> Unfortunately, it seems that the HPD IRQ storm problem from the early
> days of Intel GPUs was never entirely solved, only mostly. Within the
> last couple of days, I got a bug report from one of our customers who
> had been having
https://bugzilla.kernel.org/show_bug.cgi?id=201625
--- Comment #11 from drigohighlander (drigos...@gmail.com) ---
Sorry I wrote with my phone, and Im from Brazil my dictonaries and auto
corrector its disabled, so I mistyped some words, I dont know how to fix my
comment.
Shidt -> Shift
Noe -> Now
https://bugzilla.kernel.org/show_bug.cgi?id=201625
--- Comment #10 from drigohighlander (drigos...@gmail.com) ---
Ok the blender viewport does uses OpenGL.
I think its not a feature per se, just the viewport. To simply reproduce it
follow these steps:
Open Blender
hit 'x' to delete the cube
On Wed, 2018-11-07 at 14:44 +, Eric Engestrom wrote:
> Reported-by: Jan Vesely
> Signed-off-by: Eric Engestrom
LGTM.
Reviewed-by: Jan Vesely
Jan
> ---
> xf86drmHash.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/xf86drmHash.c b/xf86drmHash.c
> index
This adds the backlight panel, power, pwm and tcon0 device-tree bindings
required for supporting the 3.5" LCD from LeMaker on the BananaPi M1.
The brightness levels are adjusted with a gamma curve using a 1.8 power,
with indices from 0 to 100 and values ranging from 0 to 255, such as:
level =
This adds the pin muxing definition for configuring the PD pins in LCD0
mode for a RGB888 format to the sun7i device-tree.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
This adds support for the 3.5" LCD panel from LeMaker, sold for use with
BananaPi boards. It comes with a 24-bit RGB888 parallel interface and
requires an active-low DE signal
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file
This adds the device-tree bindings for the LeMaker BL035-RGB-002 3.5"
QVGA TFT LCD panel, compatible with simple-panel.
Signed-off-by: Paul Kocialkowski
---
.../bindings/display/panel/lemaker,bl035-rgb-002.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
This introduces a new device-tree binding vendor prefix for Shenzhen
LeMaker Technology Co., Ltd.
This vendor was already in use but it was not documented until now.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Rob Hering
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1
Some panels need an active-low data enable (DE) signal for the RGB
interface. This requires flipping a bit in the TCON0 polarity register
when setting up the mode for the RGB interface.
Match the associated bus flag and use it to set the polarity inversion
bit for the DE signal when required.
Features such as dithering and pixel data edge configuration currently
rely on the panel registered with the TCON driver. However, bridges are
also supported in addition to panels for RGB setup.
Instead of retrieving the connector from the panel, get it from the
encoder with the dedicated helper.
Passing the encoder to the TCON RGB setup functions allows accessing the
connector from the encoder directly instead of relying on the panel.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
The series adds support for the BL035-RGB-002 LCD panel and the required
device-tree bindings for using it on the BananaPi M1.
Only the changes related to the DRM driver and the panel are submitted
for merge, which does not include the two final commits.
Changes since v2:
* Split the commit
On 11/7/18 1:10 PM, Rodrigo Vivi wrote:
> On Wed, Nov 07, 2018 at 04:56:00PM +, Kazlauskas, Nicholas wrote:
>> On 10/24/18 6:49 PM, Rodrigo Vivi wrote:
>>> On Fri, Oct 12, 2018 at 11:42:32AM -0700, Radhakrishna Sripada wrote:
At times 12bpc HDMI cannot be driven due to faulty cables,
On Wed, Nov 07, 2018 at 04:56:00PM +, Kazlauskas, Nicholas wrote:
> On 10/24/18 6:49 PM, Rodrigo Vivi wrote:
> > On Fri, Oct 12, 2018 at 11:42:32AM -0700, Radhakrishna Sripada wrote:
> >> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> >> level shifters etc. To workaround
Am 07.11.18 um 17:37 schrieb Lucas Stach:
> Am Mittwoch, den 26.09.2018, 13:41 +0200 schrieb Thomas Zimmermann:
>> This patch unifies the naming of DRM functions for reference counting
>> of struct drm_device. The resulting code is more aligned with the rest
>> of the Linux kernel interfaces.
>>
Also, move the sentence about "who would use libdrm" into its own paragraph,
as it is something people discovering libdrm will want to know.
Signed-off-by: Eric Engestrom
---
README.rst | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/README.rst
Thanks to the #error just above, any file including this header can only
see one state for this macro: defined, with the value `1`.
Let's just #undef it once we're done using it in here so that other
files don't misconstrue any meaning to it.
Signed-off-by: Eric Engestrom
---
xf86atomic.h | 2
While at it, let's include xf86atomic.h explicitly, instead of relying
on some other file accidentally including it before including this file.
Signed-off-by: Eric Engestrom
---
freedreno/freedreno_ringbuffer.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=108507
--- Comment #7 from Vladimir Usikov ---
bamp
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Wed, Nov 07, 2018 at 06:11:30PM +0200, Stanislav Lisovskiy wrote:
> Unfortunately drm_dp_get_mst_branch_device which is called from both
> drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely
> on that mgr->mst_primary is not NULL, which seem to be wrong as it can be
> cleared
Boris Brezillon writes:
> On Wed, 24 Oct 2018 12:05:03 +0200
> Boris Brezillon wrote:
>
>> The source image might be only vertically scaled, and in this case
>> ->is_unity will be false, but we'd still have to force ->x_scaling[0]
>> to VC4_SCALING_PPF for YUV conversion to work properly.
>>
On 10/24/18 6:49 PM, Rodrigo Vivi wrote:
> On Fri, Oct 12, 2018 at 11:42:32AM -0700, Radhakrishna Sripada wrote:
>> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
>> level shifters etc. To workaround them we may need to drive the output
>> at a lower bpc. Currently the user
Signed-off-by: Eric Engestrom
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 49bf2f740fb3627f2948..5ef17fc11fee25f98b3d 100644
--- a/meson.build
+++ b/meson.build
@@ -192,7 +192,7 @@ config.set10('HAVE_OPEN_MEMSTREAM',
https://bugzilla.kernel.org/show_bug.cgi?id=201625
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
Everything looks fine in your logs. Does the feature you are using in blender
use OpenGL or OpenCL?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Am Mittwoch, den 26.09.2018, 13:41 +0200 schrieb Thomas Zimmermann:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
Thanks, now
On Wed, Oct 10, 2018 at 04:50:50PM -0700, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes). Compositors that want a UI with
> a solid color background
On Wed, Nov 07, 2018 at 10:52:11AM -0500, Ilia Mirkin wrote:
> On Wed, Nov 7, 2018 at 10:34 AM Thierry Reding
> wrote:
> >
> > On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> > > > From: Thierry Reding
> > >
Unfortunately drm_dp_get_mst_branch_device which is called from both
drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely
on that mgr->mst_primary is not NULL, which seem to be wrong as it can be
cleared with simultaneous mode set, if probing fails or in other case.
mgr->lock mutex
On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
> msm maintains a separate structure to define vblank
> work definitions and a list to track events submitted
> to the workqueue. We can avoid this redundant list
> and its protection mechanism, if we subclass the
> work object to
On Wed, Nov 7, 2018 at 10:34 AM Thierry Reding wrote:
>
> On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Irrespective of whether or not the device has any usable outputs,
On Tue, Nov 06, 2018 at 02:36:26PM -0800, Jeykumar Sankaran wrote:
> To avoid any possible work queues to msm threads, clean up
> the threads after the CRTC objects are released in
> config cleanup.
>
> changes in v2:
> - fix race condition before kthread flush and stop (Sean Paul)
>
https://bugs.freedesktop.org/show_bug.cgi?id=108086
--- Comment #7 from jeckfer...@gmail.com ---
Occurring repeatedly with 18.2.4.
Almost every login.
2nd gen laptop is fine.
It's only on my 4th gen haswell intel.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108591
--- Comment #6 from Chris Wilson ---
(In reply to Chris Wilson from comment #5)
> As expected, elk/ilk is a completely different
> bug,https://patchwork.freedesktop.org/series/52013/
> and ideally shouldn't be grouped up with the igt bug.
On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Irrespective of whether or not the device has any usable outputs, the
> > modesetting helpers will try to register all the resources
Quoting Colin King (2018-11-07 10:22:11)
> From: Colin Ian King
>
> Trivial fix to spelling mistake in DRM_INFO message
>
> Signed-off-by: Colin Ian King
Thank you for the spelling correction, applied.
-Chris
___
dri-devel mailing list
https://bugzilla.kernel.org/show_bug.cgi?id=201585
--- Comment #10 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
(In reply to Nicholas Kazlauskas from comment #9)
> These patches should fix your issue:
>
> https://patchwork.freedesktop.org/series/52164/
I suppose I should mention
https://bugzilla.kernel.org/show_bug.cgi?id=201585
--- Comment #9 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
These patches should fix your issue:
https://patchwork.freedesktop.org/series/52164/
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 11/7/18 9:57 AM, Wentland, Harry wrote:
>
>
> On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
>> These include the drm_connector 'vrr_capable' and the drm_crtc
>> 'vrr_enabled' properties.
>>
>> Signed-off-by: Nicholas Kazlauskas
>> Cc: Harry Wentland
>> Cc: Manasi Navare
>> Cc: Pekka
On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> When variable refresh rate is active the hardware counter can return
> a position >= vtotal. This results in a vpos being returned from
> amdgpu_display_get_crtc_scanoutpos that's a positive value. The
> positive value indicates to the caller
On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Manasi Navare
> Cc: Pekka Paalanen
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
>
The device might be described in the device tree but not connected to
the I2C bus. Update the status property so that the DRM panel logic
returns -ENODEV when someone tries to get the panel attached to this
DT node.
Signed-off-by: Boris Brezillon
Cc: Rob Herring
Cc: Thierry Reding
Cc: Daniel
Reported-by: Jan Vesely
Signed-off-by: Eric Engestrom
---
xf86drmHash.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xf86drmHash.c b/xf86drmHash.c
index 891b732632c36d373ac9..2cf2b80ed9e02310f0ff 100644
--- a/xf86drmHash.c
+++ b/xf86drmHash.c
@@ -105,7 +105,6 @@ static unsigned long
Hi,
Le lundi 05 novembre 2018 à 16:08 -0600, Rob Herring a écrit :
> On Thu, Nov 01, 2018 at 09:00:41PM +0100, Paul Kocialkowski wrote:
> > This introduces a new device-tree binding vendor prefix for Shenzhen
> > LeMaker Technology Co., Ltd.
>
> Would be nice to say this is already in use, but
On Wed, Nov 7, 2018 at 3:10 PM Daniel Vetter wrote:
>
> On Wed, Nov 7, 2018 at 2:40 PM Laurent Pinchart
> wrote:
> >
> > Hi Jyri,
> >
> > (CC'ing Daniel Vetter)
> >
> > On Wednesday, 31 October 2018 18:24:28 EET Jyri Sarha wrote:
> > > Hi Laurent,
> > > Tomi is busy with other things so I have
On Wed, Nov 7, 2018 at 2:40 PM Laurent Pinchart
wrote:
>
> Hi Jyri,
>
> (CC'ing Daniel Vetter)
>
> On Wednesday, 31 October 2018 18:24:28 EET Jyri Sarha wrote:
> > Hi Laurent,
> > Tomi is busy with other things so I have taken over applying these
> > comments. The rest is more or less clear, or
1 - 100 of 145 matches
Mail list logo
