From: Dave Airlie
vgem seems to oops on the intel CI due to the vgem debugfs init
hitting this path now.
Check if we have mode_config funcs before checking one.
Signed-off-by: Dave Airlie
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm
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.
Signed-o
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:
https://github.com/0day-ci/linux/commits/Lyude-Paul/drm-atomic-Use-drm_drv_uses_atomic_modeset-for-debugfs
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.
Signed-o
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 space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
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 co
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 bug._
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 bug._
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, 4.18.
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 per-
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
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 [a
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: C
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 alwa
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, 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 w
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 list
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 A
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 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 pa
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 repre
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 patchse
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 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 DRM_MODE_P
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 belie
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 miss
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 mail
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 miss
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
> ---
> drivers/gpu/drm/
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Andrey Arapov (andrey.ara...@nixaid.com) changed:
What|Removed |Added
CC||andrey.ara...@n
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
b/drivers/gpu/drm/drm_probe_help
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 mode
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
> > DRIVER_ATOM
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) || dev->bustype
> != DRM_BUS_PCI) {
> hw/xfree86/drivers/modesetting/dri2.c:info.deviceName =
>
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
> C
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=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.
`p
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=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 are
On Mon, Sep 10, 2018 at 04:32:30PM +0200, Jernej Škrabec wrote:
> Dne ponedeljek, 10. september 2018 ob 16:23:54 CEST je Maxime Ripard
> napisal(a):
> > On Fri, Sep 07, 2018 at 03:22:34PM +0800, Icenowy Zheng wrote:
> > > The R40 HDMI PHY seems to be different to the A64 one, the A64 one
> > > has
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #13 from Mike Lothian ---
I'm not sure, I'm hoping I might be pointing the devs in the right direction
I'm not sure if drmGetDeviceNameFromFd vs drmGetDeviceNameFromFd2 could cause
the issue too - I think it might
I found in the xs
On 17/09/18 17:41, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote:
>> 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
On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote:
> 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 v
https://bugs.freedesktop.org/show_bug.cgi?id=107595
--- Comment #14 from Przemek ---
Yeh, "Kaveri" - logical approach.(In reply to Michel Dänzer from comment #13)
> (In reply to Przemek from comment #12)
> > Pontus Gråskæg, if kernel compiled from the latest git repo sync
> > (git://people.freede
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #12 from Ransu ---
If this is a library file issue how should I go fixing this? Does this need a
upstream or mainline fix?
--
You are receiving this mail because:
You are the assignee for the bug._
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,
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:37PM +0300, Laurent Pinchart wrote:
> On selected SoCs, the DU can use the clock output by the LVDS encoder
> PLL as its input dot clock. This feature is optional, but on the D3 and
> E3 SoC it is often the only way to obtain a precise dot clock frequency,
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:38PM +0300, Laurent Pinchart wrote:
> All Gen3 SoCs supported so far have a fixed association between DPAD0
> and DU channels, which led to hardcoding that association when writing
> the corresponding hardware register. The D3 and E3 will break that
> mech
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:36PM +0300, Laurent Pinchart wrote:
> The rcar_du_crtc_get() function is always immediately followed by a call
> to rcar_du_crtc_setup(). Call the later from the former to simplify the
> code, and add a comment to explain how the get and put calls are
> ba
Hi Laurent,
On Fri, Sep 14, 2018 at 12:10:35PM +0300, Laurent Pinchart wrote:
> The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> in the other R-Car Gen3 family members:
>
> - The LVDS PLL architecture is more complex and requires computing PLL
> parameters manually.
> -
https://bugzilla.kernel.org/show_bug.cgi?id=201163
--- Comment #5 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
# cat /sys/kernel/debug/dri/0/amdgpu_firmware_info
VCE feature version: 0, firmware version: 0x34040300
UVD feature version: 0, firmware version: 0x015b0b00
MC feature version: 0,
https://bugzilla.kernel.org/show_bug.cgi?id=201163
--- Comment #4 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Adding umr output. Obtained with this command:
sudo umr -O verbose,follow_ib -R gfx[0:2047]
sudo umr -O many,bits -r *.gfx80.mmGRBM_STATUS
sudo umr -O many,bits -r *.gfx80.HEAD
Hi Ulrich,
On Monday, 17 September 2018 13:53:58 EEST Ulrich Hecht wrote:
> > On September 14, 2018 at 11:10 AM Laurent Pinchart wrote:
> >
> > The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> > in the other R-Car Gen3 family members:
> >
> > - The LVDS PLL architecture
https://bugzilla.kernel.org/show_bug.cgi?id=201163
--- Comment #3 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 278601
--> https://bugzilla.kernel.org/attachment.cgi?id=278601&action=edit
umr
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=201163
--- Comment #2 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 278599
--> https://bugzilla.kernel.org/attachment.cgi?id=278599&action=edit
trace-cmd
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=201163
--- Comment #1 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 278597
--> https://bugzilla.kernel.org/attachment.cgi?id=278597&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=201163
Bug ID: 201163
Summary: amdgpu: carrizo: Stalls using vaapi encoder
Product: Drivers
Version: 2.5
Kernel Version: 4.18.0
Hardware: All
OS: Linux
Tree: Mainlin
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 /usr/lib64/libva-wayland.so.2.200.0
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #10 from
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 +0100
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
> > accordingly.
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
---
drivers/gpu/drm/ttm/
https://bugs.freedesktop.org/show_bug.cgi?id=107956
Lakshmi changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving this mail b
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=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 a
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 __drm_mode_set_config_internal(
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 understan
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #7 from Ransu ---
Created attachment 141600
--> https://bugs.freedesktop.org/attachment.cgi?id=141600&action=edit
xorg.config (log 1)
--
You are receiving this mail because:
You are the assignee for the bug.
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.
BOOT_IMAGE=/vmlin
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #6 from Ransu ---
Created attachment 141599
--> https://bugs.freedesktop.org/attachment.cgi?id=141599&action=edit
dmesg -w (log 1)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #5 from Ransu ---
Created attachment 141598
--> https://bugs.freedesktop.org/attachment.cgi?id=141598&action=edit
xrandr information (log 1)
--
You are receiving this mail because:
You are the assignee for the bug.___
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|
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #4 from Ransu ---
Created attachment 141597
--> https://bugs.freedesktop.org/attachment.cgi?id=141597&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.___
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 ha
https://bugzilla.kernel.org/show_bug.cgi?id=201139
Michel Dänzer (mic...@daenzer.net) changed:
What|Removed |Added
CC||harry.wentl...@amd.co
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 ma
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 p
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 Se
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 mailin
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 mailin
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Assignee|xorg-driver-...@lis
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=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://lists
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.
Pleas
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 t
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 commit
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 R8A779
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 Fr
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
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 R8A779
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,
> >
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 to
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
> > supporting
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
follo
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 [mailto:intel-gfx-bou
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 +0
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 if
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 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 Vet
1 - 100 of 119 matches
Mail list logo
