https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #1 from Alex Deucher ---
Can you attach the xorg log and dmesg output from your system?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
On Mon, 2018-09-17 at 21:16 +0300, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 02:10:02PM -0400, Lyude Paul wrote:
> > On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > > > Userspace asked them to be forced off, so why
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.
v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP
Cc: Chris Wilson
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_ioctl.c
On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote:
> Adding lcdif nodes to a power domain currently doesn't work, it results
> in black/corrupted screens or hangs. While the driver does enable
> runtime pm it does not deal correctly with the block being unpowered.
>
> ---
>
> All
https://bugs.freedesktop.org/show_bug.cgi?id=107873
--- Comment #10 from Ahmed Elsayed ---
(In reply to Ahmed Elsayed from comment #6)
> I can start the game with Vulkan but it stops loading at 99%, but with
> opengl, I can hear the menu sounds but I can see only the red fog.
>
> I filed a bug
Hi Leonard.
On Mon, Aug 27, 2018 at 02:10:40PM +0300, Leonard Crestez wrote:
> Since power to the lcdif block can be lost on suspend implement
> PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
> the current mode.
>
> Signed-off-by: Leonard Crestez
> Reviewed-by: Stefan
https://bugs.freedesktop.org/show_bug.cgi?id=107873
--- Comment #11 from Ahmed Elsayed ---
(In reply to Timothy Arceri from comment #9)
> (In reply to Zebediah Figura from comment #7)
> > Do you mean that this is a bug present in Staging but not in upstream Wine?
> > In particular, is the
On Mon, Sep 17, 2018 at 01:37:33PM -0400, Lyude Paul wrote:
> As pointed out by Daniel Vetter, we should be usinng
> drm_drv_uses_atomic_modeset() for determining whether or not we want to
> make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
> the former isn't an accurate
On Mon, Sep 17, 2018 at 11:01:15AM +0100, Daniel Stone wrote:
> Hi,
>
> On Sat, 15 Sep 2018 at 00:56, Lucas De Marchi
> wrote:
> > -To apply for commit rights ("Developer" role in gitlab) send a mail to
> > -dri-devel@lists.freedesktop.org and please ping the maintainers if your
> > request
>
On Mon, Sep 17, 2018 at 4:29 PM Mathieu Malaterre wrote:
>
>
>
> On Fri, Apr 13, 2018 at 9:59 AM Huang Rui wrote:
>>
>> On Thu, Apr 12, 2018 at 09:33:33PM +0200, Mathieu Malaterre wrote:
>> > In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
>> > 255 is done. Since it is
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #14 from Mike Lothian ---
Tonight when I have access to my laptop I'll try switching those two the '2'
versions and see if it stops the issues, unless anyone else has any better
ideas
--
You are receiving this mail because:
You
On Thu, Sep 13, 2018 at 01:23:00PM +0530, Archit Taneja wrote:
> I have moved on to other stuff for now. Haven't been able to make time
> to review bridge related work. Andrzej has been doing it by himself
> for a while now.
>
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Gustavo Padovan
>
https://bugzilla.kernel.org/show_bug.cgi?id=201147
rezbit@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107375
--- Comment #3 from Paul Menzel ---
With v4.19-rc4-22-gad3273d5f1b9 (Merge tag 'ext4_for_linus_stable' of
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) this now got worse,
and `amdgpu_device_ip_resume_phase2()` now takes 1.166 s.
On Thu, Sep 13, 2018 at 10:46:15AM -0600, Jordan Crouse wrote:
> enum dpu_ad isn't used and can be safely removed.
>
> Signed-off-by: Jordan Crouse
Nice catch! I've pushed it to dpu-staging
Sean
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 6 --
> 1 file changed, 6 deletions(-)
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #15 from Michel Dänzer ---
(In reply to Mike Lothian from comment #13)
> hw/xfree86/dri2/dri2.c:if (drmGetDevice(info->fd, ) || dev->bustype
> != DRM_BUS_PCI) {
> hw/xfree86/drivers/modesetting/dri2.c:info.deviceName =
>
https://bugzilla.kernel.org/show_bug.cgi?id=200621
--- Comment #25 from Jon (jon...@gmail.com) ---
Here are the newest:
id 3dd692e5e80f6bac71c1f4caa570bd449b68a752
reason: WARNING: CPU: 12 PID: 2159 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254
generic_reg_wait+0xe7/0x160
https://bugzilla.kernel.org/show_bug.cgi?id=200621
--- Comment #24 from Jon (jon...@gmail.com) ---
Had another crash again today. Here's some output from abrt-cli that I thought
might be helpful. (there are dozens of theses):
id 50200875b8db5b1f4a2a8e9e1b4b9cbf28370c7c
reason: WARNING:
On 17.09.2018 12:16, Sean Paul wrote:
> On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote:
>> Adding lcdif nodes to a power domain currently doesn't work, it results
>> in black/corrupted screens or hangs. While the driver does enable
>> runtime pm it does not deal correctly with the
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.c
between commit:
55ac5a1614f9 ("drm/i915: Attach the pci match data to the device upon
creation")
from the drm tree and commit:
1feb64c49d7f ("drm/i915: Clear DRIVER_ATOMIC on a
As pointed out by Daniel Vetter, we should be usinng
drm_drv_uses_atomic_modeset() for determining whether or not we want to
make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
the former isn't an accurate representation of whether or not the driver
is actually using atomic
On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > Userspace asked them to be forced off, so why would we care about what a
> > probe tells us?
>
> I believe there should be force checks in the callers already.
> Or are we
https://bugzilla.kernel.org/show_bug.cgi?id=200695
--- Comment #11 from Andrey Arapov (andrey.ara...@nixaid.com) ---
Oh, that option is gone from 4.18.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
Userspace asked them to be forced off, so why would we care about what a
probe tells us?
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_probe_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> Userspace asked them to be forced off, so why would we care about what a
> probe tells us?
I believe there should be force checks in the callers already.
Or are we missing some?
>
> Signed-off-by: Lyude Paul
> ---
>
On Fri, 2018-09-14 at 10:11 +0200, Daniel Vetter wrote:
> On Thu, Sep 13, 2018 at 11:02 PM, Lyude Paul wrote:
> > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends
> > on
> > the driver supporting atomic, maybe it would be good to make it so that we
> > set
> >
On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > Userspace asked them to be forced off, so why would we care about what a
> > probe tells us?
>
> I believe there should be force checks in the callers already.
> Or are we
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Andrey Arapov (andrey.ara...@nixaid.com) changed:
What|Removed |Added
CC|
On Mon, Sep 17, 2018 at 02:10:02PM -0400, Lyude Paul wrote:
> On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> > On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > > Userspace asked them to be forced off, so why would we care about what a
> > > probe tells us?
> >
> > I
Hi Satish,
On Fri, 7 Sep 2018 at 23:04, Satish Nagireddy
wrote:
> The requirement is to render interlaced alternate buffers. In case of
> alternate, top field and bottom field are in two different buffers.
>
> The question is, can we pass existing flags DRM_MODE_PRESENT_TOP_FIELD
> and
https://bugs.freedesktop.org/show_bug.cgi?id=106921
--- Comment #5 from Greg White ---
Update: I swapped the card into a machine and tried it with Windows. It still
crashed. I replaced the card and all is well.
--
You are receiving this mail because:
You are the assignee for the
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Claude Heiland-Allen (cla...@mathr.co.uk) changed:
What|Removed |Added
Kernel Version|4.18.0-rc7, 4.18.5, 4.18.6, |4.17.19,
https://bugs.freedesktop.org/show_bug.cgi?id=105819
--- Comment #9 from Greg White ---
Update: I swapped the card into a machine and tried it with Windows. It still
crashed. I replaced the card and all is well.
--
You are receiving this mail because:
You are the assignee for the
On Mon, Sep 17, 2018 at 02:08:34PM +0200, Christian König wrote:
> Move all entries between @first and including @last before @head.
>
> This is useful for LRU lists where a whole block of entries should be
> moved to the end of the list.
>
> Used as a band aid in TTM, but better placed in the
FYI, we noticed the following commit (built with gcc-6):
commit: 79ef5c1b820e59bcc240e133cd9df59b2b20415f ("[PATCH] drm/atomic: Use
drm_drv_uses_atomic_modeset() for debugfs creation")
url:
On 09/17/2018 08:08 PM, Christian König wrote:
Move all entries between @first and including @last before @head.
This is useful for LRU lists where a whole block of entries should be
moved to the end of the list.
Used as a band aid in TTM, but better placed in the common list headers.
https://bugs.freedesktop.org/show_bug.cgi?id=107873
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105530
--- Comment #13 from Andrew Sheldon ---
I should say that part of the bug seems to be worked around with amdgpu.dc=0 in
that the stuttering is gone. But the other issue, that of the output looking
like it's running at half the framerate in
Hi Simon,
On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote:
> On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > > connected
Hi Simon,
On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote:
> On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote:
> > On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> > > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > > > The
On 17.09.2018 11:25, Lisovskiy, Stanislav wrote:
On Fri, 2018-09-14 at 20:05 +0300, Juha-Pekka Heikkilä wrote:
Lisovskiy, Stanislav kirjoitti 14.9.2018 klo 17.30:
On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:
On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav
wrote:
On
https://bugs.freedesktop.org/show_bug.cgi?id=107873
--- Comment #8 from Timothy Arceri ---
(In reply to Zebediah Figura from comment #7)
> Do you mean that this is a bug present in Staging but not in upstream Wine?
> In particular, is the patchset "opengl32-Revert_Disable_Ext" to blame?
I'm
https://bugzilla.kernel.org/show_bug.cgi?id=199139
--- Comment #12 from Eduard (wirch.edu...@gmail.com) ---
Created attachment 278579
--> https://bugzilla.kernel.org/attachment.cgi?id=278579=edit
fail log 4.18
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=199139
--- Comment #13 from Eduard (wirch.edu...@gmail.com) ---
Created attachment 278581
--> https://bugzilla.kernel.org/attachment.cgi?id=278581=edit
Xorg 4.18
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=105530
--- Comment #14 from Andrew Sheldon ---
Okay, so on the secondary issue of the perceived framerate dropping in some
cases, it appears to be related to GPU load. If the GPU usage reaches 100% the
perceived framerate drops dramatically, whereas
Hi Simon,
On Monday, 17 September 2018 10:50:55 EEST Simon Horman wrote:
> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> >
https://bugzilla.kernel.org/show_bug.cgi?id=199139
--- Comment #14 from Eduard (wirch.edu...@gmail.com) ---
Attached dmesg output right after boot (boot log 4.18) and the additional
failure lines after display woke up from power save (fail log 4.18). As well as
Xorg log (Xorg 4.18).
The problem
Hi Noralf, Daniel,
On 14/09/2018 18:33, Noralf Trønnes wrote:
>
> Den 14.09.2018 10.23, skrev Neil Armstrong:
>> Hi Daniel,
>>
>> On 13/09/2018 16:55, Daniel Vetter wrote:
>>> On Thu, Sep 13, 2018 at 04:26:53PM +0200, Neil Armstrong wrote:
Hi Daniel,
On 13/09/2018 15:21, Daniel
On Fri, 2018-09-14 at 14:59 +, Alexandru-Cosmin Gheorghe wrote:
> On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote:
> > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote:
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Intel-gfx
Hi,
On Mon, Sep 17, 2018 at 08:27:18AM +, Lisovskiy, Stanislav wrote:
> On Fri, 2018-09-14 at 14:59 +, Alexandru-Cosmin Gheorghe wrote:
> > On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote:
> > > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote:
> > > > Hi,
> >
On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote:
> Hi Simon,
>
> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote:
> > On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote:
> > > On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> > > > On
https://bugzilla.kernel.org/show_bug.cgi?id=199139
--- Comment #11 from Eduard (wirch.edu...@gmail.com) ---
Created attachment 278577
--> https://bugzilla.kernel.org/attachment.cgi?id=278577=edit
boot log 4.18
--
You are receiving this mail because:
You are watching the assignee of the bug.
The Allwinner R40 HDMI PHY is currently the only one that seems to be
able to select between two PLL inputs.
Add a compatible string for it, and the pll-1 clock input definition.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Rebased when removing original A64 binding patch.
Sorry, I am still not clear why the call chain I proposed is incorrect...
I find a conditional in amdgpu_mm_wreg():
if (!(acc_flags & AMDGPU_REGS_NO_KIQ) && amdgpu_sriov_runtime(adev))
return amdgpu_virt_kiq_wreg(adev, reg, v);
Is amdgpu_virt_kiq_wreg() never called from WREG32()
On Tue, Sep 11, 2018 at 2:04 PM Souptick Joarder wrote:
>
> On Mon, Aug 6, 2018 at 8:16 PM Souptick Joarder wrote:
> >
> > convert drm_atomic_helper_suspend/resume() to use
> > drm_mode_config_helper_suspend/resume().
> >
> > Fixed one sparse warning by making hibmc_drm_interrupt
> > static.
> >
On 2018/9/15 17:23, Koenig, Christian wrote:
No, the problem is the function pointer analysis.
In other words the KIQ ring is sometimes used in atomic and even
interrupt context.
But the UVD ring is never used in atomic context.
But I don't see a way a static analysis could ever figure
Thanks for your reply.
On 2018/9/15 17:01, Koenig, Christian wrote:
Sorry to say that but your analysis tool is buggy.
The proposed call paths will never trigger.
Could you please explain which piece of the call path is incorrect?
I am not very sure of my function pointer analysis.
Does
'vaddr_out' is malloced in _vkms_get_crc() and should be freed before
leaving from the error handling cases, otherwise it will cause memory
leak.
Fixes: db7f419c06d7 ("drm/vkms: Compute CRC with Cursor Plane")
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/vkms/vkms_crc.c | 1 +
1 file changed,
On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> Acked-by: Darren Hart (VMware)
>
> As for a longer term solution, would it be possible to init fops in such
> a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> so we don't have to duplicate this boilerplate
The A64 HDMI PHY seems to be not able to use the second video PLL as
clock parent in experiments.
Drop the support for the second PLL from A64 HDMI PHY driver.
Fixes: b46e2c9f5f64 ("drm/sun4i: Add support for A64 HDMI PHY")
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- none.
The R40 HDMI PHY seems to be different to the A64 one, the A64 one
has no input mux, but the R40 one has.
Drop the A64 fallback compatible from the HDMI PHY node in R40 DT.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- none.
arch/arm/boot/dts/sun8i-r40.dtsi | 3 +--
1 file changed, 1
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
In function ‘dcn10_update_mpcc’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1903:9:
warning: missing braces around initializer [-Wmissing-braces]
Signed-off-by: Peng Hao
---
The driver may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.17 are:
[FUNC] mutex_lock_nested
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c, 1477:
mutex_lock_nested in amdgpu_dpm_enable_uvd
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c, 1154:
The R40 SoC has a HDMI PHY that is possible to mux two video PLLs.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- none.
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
When adding support for A64 HDMI PHY in 4.19, we assumed that the two
PLL-VIDEOs can both feed the HDMI PHY clock. However experiments show
that the mux bit discovered in R40 blob is not applicable on A64. This
is not discovered, as normally with a single display pipeline only
PLL-VIDEO0 will be
From: Soheil Yasrebi
Fixed a coding style issue.
Signed-off-by: Soheil Yasrebi
---
drivers/gpu/drm/drm_modes.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 02db9ac82d7a..1eed35c549e8 100644
---
On Fri, 2018-09-14 at 20:05 +0300, Juha-Pekka Heikkilä wrote:
>
> Lisovskiy, Stanislav kirjoitti 14.9.2018 klo 17.30:
> > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:
> > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav
> > > wrote:
> > > > On Fri, 2018-09-07 at 11:45
Am 14.09.2018 um 12:37 schrieb Chunming Zhou:
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
On 2018年09月17日 16:37, Christian König wrote:
Am 14.09.2018 um 12:37 schrieb Chunming Zhou:
This patch is for VK_KHR_timeline_semaphore extension, semaphore is
called syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer
payload
identifying a point in a
https://bugs.freedesktop.org/show_bug.cgi?id=107940
--- Comment #2 from Michel Dänzer ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #3 from Michel Dänzer ---
Please attach the Xorg log file and the output of dmesg and xrandr.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=107940
--- Comment #3 from Michel Dänzer ---
Please attach the Xorg log file and the output of dmesg and xrandr.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Hi,
On Sat, 15 Sep 2018 at 00:56, Lucas De Marchi wrote:
> -To apply for commit rights ("Developer" role in gitlab) send a mail to
> -dri-devel@lists.freedesktop.org and please ping the maintainers if your
> request
> -is stuck.
> +To apply for commit rights ("Developer" role in gitlab), check
Hi Geert,
On Monday, 17 September 2018 12:48:12 EEST Geert Uytterhoeven wrote:
> On Mon, Sep 17, 2018 at 11:09 AM Laurent Pinchart wrote:
> > On Monday, 17 September 2018 11:51:06 EEST Simon Horman wrote:
> >> On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> >>> On Monday, 17
https://bugzilla.kernel.org/show_bug.cgi?id=201139
Michel Dänzer (mic...@daenzer.net) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=105530
--- Comment #15 from Michel Dänzer ---
(In reply to Andrew Sheldon from comment #14)
> Is this expected behaviour?
I'm afraid it might be at this point, due to TearFree always incurring an
additional GPU copy.
> If so, it might be useful to
Move all entries between @first and including @last before @head.
This is useful for LRU lists where a whole block of entries should be
moved to the end of the list.
Used as a band aid in TTM, but better placed in the common list headers.
Signed-off-by: Christian König
---
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #9 from Ransu ---
Adding
amdgpu.runpm=0
helps big time but I know this means both the AMD and Intel would be running
all the time, this is not ideal. As I said before I would like to have the
Intel GPU running as my main and only
https://bugs.freedesktop.org/show_bug.cgi?id=107956
Lakshmi changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=107956
Lakshmi changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving this mail
Hi Ulrich,
On Monday, 17 September 2018 13:53:43 EEST Ulrich Hecht wrote:
> > On September 14, 2018 at 11:10 AM Laurent Pinchart wrote:
> >
> > The THC63LVD1024 is restricted to a pixel clock frequency in the range
> > of 8 to 135 MHz. Implement the bridge .mode_valid() operation
> >
Hi Kieran,
On Mon, Sep 17, 2018 at 11:56:23AM +0100, Kieran Bingham wrote:
> Hi Alexandru,
>
> On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> > Hi Kieran,
> >
> > Sorry for that and thanks for getting to the bottom of it.
>
> No worries,
>
>
> > On Fri, Sep 14, 2018 at 11:28:05PM
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #10
Hi Kieran,
Sorry for that and thanks for getting to the bottom of it.
On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
> Hi Laurent,
>
> I've looked through a bit further to try to understand this issue and I
> think I have identified a possible/probable cause.
>
> Before
Hi Laurent,
On Mon, Sep 17, 2018 at 11:09 AM Laurent Pinchart
wrote:
> On Monday, 17 September 2018 11:51:06 EEST Simon Horman wrote:
> > On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> > > On Monday, 17 September 2018 10:50:55 EEST Simon Horman wrote:
> > > > On Fri, Sep 14,
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #4 from Ransu ---
Created attachment 141597
--> https://bugs.freedesktop.org/attachment.cgi?id=141597=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Ransu changed:
What|Removed |Added
Attachment #141597|Xorg.0.log |Xorg.0.log (log 1)
description|
Hi Alexandru,
On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> Hi Kieran,
>
> Sorry for that and thanks for getting to the bottom of it.
No worries,
> On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
>> Hi Laurent,
>>
>> I've looked through a bit further to try to
Hi Simon,
On Monday, 17 September 2018 10:33:43 EEST Simon Horman wrote:
> On Fri, Sep 14, 2018 at 12:10:42PM +0300, Laurent Pinchart wrote:
> > From: Takeshi Kihara
> >
> > Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> > tree.
> >
> > Signed-off-by: Takeshi Kihara
Hi Simon,
On Monday, 17 September 2018 11:51:06 EEST Simon Horman wrote:
> On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> > On Monday, 17 September 2018 10:50:55 EEST Simon Horman wrote:
> > > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > > > The
https://bugs.freedesktop.org/show_bug.cgi?id=107595
--- Comment #13 from Michel Dänzer ---
(In reply to Przemek from comment #12)
> Pontus Gråskæg, if kernel compiled from the latest git repo sync
> (git://people.freedesktop.org/~agd5f/linux) does not work for you feel free
> to reopen it.
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
https://bugzilla.kernel.org/show_bug.cgi?id=201147
--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Looks like CONFIG_DRM_AMD_DC_DCN1_0 isn't enabled in the kernel build
configuration. This is a configuration error, which will no longer be possible
in 4.19.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #6 from Ransu ---
Created attachment 141599
--> https://bugs.freedesktop.org/attachment.cgi?id=141599=edit
dmesg -w (log 1)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #5 from Ransu ---
Created attachment 141598
--> https://bugs.freedesktop.org/attachment.cgi?id=141598=edit
xrandr information (log 1)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #7 from Ransu ---
Created attachment 141600
--> https://bugs.freedesktop.org/attachment.cgi?id=141600=edit
xorg.config (log 1)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #8 from Ransu ---
All attachments for this comment was marked "log 1" This includes my current
xorg.conf
At the time of the attachments the kernel command line was as follows with
sensitive information left out.
drm_mode_setcrtc() retries modesetting in case one of the functions it
calls returns -EDEADLK. connector_set, mode and fb are freed before
retrying, but they are not set to NULL. This can cause
drm_mode_setcrtc() to use those variables.
For example: On the first try
https://bugs.freedesktop.org/show_bug.cgi?id=107953
--- Comment #1 from Nick Tenney ---
Realized I forgot to include some important info for the initial report:
Card: Sapphire Nitro RX 580 4 GB
Monitor: Monoprice 35 3440x1440@100 Hz via DP 1.2 connection
Distro: Arch Linux testing repositories,
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #11 from Mike Lothian ---
I did a quick grep on libraries that contain drmGetDevice and drmGetDevice2 and
did a diff
-Binary file /usr/lib64/libva-drm.so.2.200.0 matches
@@ -6 +4,0 @@
-Binary file
1 - 100 of 119 matches
Mail list logo
