https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #25 from Robert Strube ---
acpi=off is the only parameter necessary to get the eGPU up and running.
Setting this parameter allows the Thunderbolt PCI bridge to correctly have it's
resources allocated. This incidentally also
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #24 from Robert Strube ---
Created attachment 142209
--> https://bugs.freedesktop.org/attachment.cgi?id=142209=edit
dmesg log booting system with PM *DISABLED* and *WITH* eGPU
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #23 from Robert Strube ---
Edit: taking a closer look at the dmesg I see that disabling the PM did indeed
eliminate the PCI resource issues. So for some reason having PM enabled
affects the PCI resource allocation for the
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #22 from Robert Strube ---
OK! My hunch about the PM was right! The card is fully initialized now, so the
issue doesn't appear to be a PCI resource issue!
I took the brute force approach, compiled my own custom kernel that
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #21 from Robert Strube ---
Hi guys,
Apologies for the deluge of posts here, I've been trying really hard to
investigate this issue!
So I took a closer look at the PCI resource issues that you mentioned, I've
also been looking and
Make igt for cross-driver, I think you should rename it first, not an intel
specific. NO company wants their employee working on other company stuff.
You can rename it to DGT(drm graphics test), and published following libdrm,
or directly merge to libdrm, then everyone can use it and develop
https://bugs.freedesktop.org/show_bug.cgi?id=108096
Dieter Nützel changed:
What|Removed |Added
Summary|[amd-staging-drm-next] SDDM |[amd-staging-drm-next] SDDM
Hi Dave,
Fixes for 4.20:
- Powerplay updates for vega20
- Powerplay fixes
- DC fix for CZ and ST
- GPUVM fix
- SR-IOV fix
The following changes since commit f2bfc71aee75feff33ca659322b72ffeed5a243d:
Merge tag 'drm-intel-next-fixes-2018-10-18' of
git://anongit.freedesktop.org/drm/drm-intel
https://bugs.freedesktop.org/show_bug.cgi?id=107536
--- Comment #3 from Alex Deucher ---
Is this reproducible or was it a one time event?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Noralf Trønnes writes:
> Den 25.10.2018 18.29, skrev Eric Anholt:
>> Eric Anholt writes:
>>
>>> I was going to start working on making the vc4 driver work with
>>> tinydrm panels, but it turned out tinydrm didn't have the panel I had
>>> previously bought. So, last night I ported the fbtft
i915 will make use of this to fail early during framebuffer creation.
Suggested-by: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_plane.c | 1 +
include/drm/drm_plane.h | 11 +++
2 files changed, 12
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 issues with their machine suddenly booting up very
slowly after having
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750]
IMPORTANT -
As a note: I have not had the customer who this second patch is for test
this yet, I'm sending this ahead of time to make sure this is something
that isn't too crazy for upstream to accept. I'm not planning on pushing
this after review until I've verified this actually fixes
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
>
> On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> > As far as I can tell the panel that was added in commit da50bd4258db
> > ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> > wasn't actually an Innolux
Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.
Looking at the datasheet for the same panel that was tested for the
original commit, I see
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the
As far as I can tell the bindings that were added in commit
9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings") weren't actually for Innolux TV123WAM but were actually for
Innolux P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the
As far as I can tell the panel that was added in commit da50bd4258db
("drm/panel: simple: Add Innolux TV123WAM panel driver support")
wasn't actually an Innolux TV123WAM but was actually an Innolux
P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh
If the HPD signal isn't hooked up to this panel we need a 200 ms
delay. In the datasheet this is shown as the maximum time that HPD
will take to be asserted after power is given to the panel.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool
Den 25.10.2018 18.29, skrev Eric Anholt:
Eric Anholt writes:
I was going to start working on making the vc4 driver work with
tinydrm panels, but it turned out tinydrm didn't have the panel I had
previously bought. So, last night I ported the fbtft staging
driver over to DRM.
It seems to
On Wed, Oct 24, 2018 at 11:43:11AM -0700, Eric Anholt wrote:
> This adds a new binding for Himax HX8357D display panels. It includes
> a compatible string for one display (more can be added in the future).
>
> The YX350HV15 panel[1] is found in the Adafruit PiTFT 3.5" Touch
> Screen for Raspberry
On Fri, Oct 05, 2018 at 05:52:18PM -0700, Abhinav Kumar wrote:
> Add support for Truly NT35597 panel driver used in MSM reference
> platforms. This panel driver supports both single DSI and dual
> DSI modes.
>
> However, this patch series adds support only for dual DSI mode.
>
> Changes in v10:
Quoting Chris Wilson (2018-10-25 21:20:21)
> Quoting Chris Wilson (2018-10-25 21:15:17)
> > Quoting Christian König (2018-10-04 14:12:43)
> > > No need for that any more. Just replace the list when there isn't enough
> > > room any more for the additional fence.
> >
> > Just a heads up. After
On Wed, 24 Oct 2018 14:54:56 +0200, =?UTF-8?q?S=C3=A9bastien=20Szymanski?=
wrote:
> This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
> that it can be connected on the TFT header of Armadeus Dev boards.
On Thu, 25 Oct 2018 22:13:37 +0200
Noralf Trønnes wrote:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
>
Quoting Chris Wilson (2018-10-25 21:15:17)
> Quoting Christian König (2018-10-04 14:12:43)
> > No need for that any more. Just replace the list when there isn't enough
> > room any more for the additional fence.
>
> Just a heads up. After this series landed, we started hitting a
> use-after-free
Quoting Christian König (2018-10-04 14:12:43)
> No need for that any more. Just replace the list when there isn't enough
> room any more for the additional fence.
Just a heads up. After this series landed, we started hitting a
use-after-free when iterating the shared list.
<4> [109.613162]
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
CMA helper drivers have been converted to drm_fbdev_generic_setup()
so the fbdev code can be removed.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
Changes since version 1:
- Rebased
drivers/gpu/drm/Kconfig | 4 --
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
This patchset moves the drivers using the CMA helper fully over to the
generic fbdev emulation.
These are the remaining patches that didn't get a driver maintainer ack
or has been rebased.
For context, this is part 1 of the generic fbdev emulation:
drm: Add generic fbdev emulation
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by
On Wed, Oct 24, 2018 at 06:28:02PM -0400, Lyude Paul wrote:
> On Wed, 2018-10-24 at 15:28 -0700, Manasi Navare wrote:
> > DSC can be supported per DP connector. This patch adds a per connector
> > debugfs node to expose DSC support capability by the kernel.
> > The same node can be used from
On Thu, Oct 25, 2018 at 05:03:06PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:30PM -0700, Manasi Navare wrote:
> > From: Gaurav K Singh
> >
> > This patch enables decompression support in sink device
> > before link training and disables the same during the
> > DDI disabling.
>
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #20 from Robert Strube ---
One more thing I thought of. Would it help if I posted my dmesg log with the
GTX 1060 connected as an eGPU?
As I mentioned previously this card *is* working with nouveau. I haven't
tested with the
On Thu, Oct 25, 2018 at 05:09:42PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:34PM -0700, Manasi Navare wrote:
> > DSC PPS secondary data packet infoframes are filled with
> > DSC picure parameter set metadata according to the DSC standard.
> > These infoframes are sent to the
On Thu, Oct 25, 2018 at 05:15:34PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:36PM -0700, Manasi Navare wrote:
> > Display Stream Splitter registers need to be programmed to enable
> > the joiner if two DSC engines are used and also to enable
> > the left and the right DSC
On Thu, Oct 25, 2018 at 05:16:58PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:37PM -0700, Manasi Navare wrote:
> > 1. Disable Left/right VDSC branch in DSS Ctrl reg
> > depending on the number of VDSC engines being used
> > 2. Disable joiner in DSS Ctrl reg
> >
> > v3 (From
On Mon, 22 Oct 2018 13:46:39 -0700, Douglas Anderson wrote:
> As far as I can tell the bindings that were added in commit
> 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings") weren't actually for Innolux TV123WAM but were actually for
> Innolux P120ZDG-BF1.
>
> As
On Thu, Oct 25, 2018 at 05:22:18PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:38PM -0700, Manasi Navare wrote:
> > A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> > whereas all other transcoders use the power wells associated with the
> > transcoders for
https://bugs.freedesktop.org/show_bug.cgi?id=108542
--- Comment #4 from Nicholas Kazlauskas ---
(In reply to davide26079 from comment #3)
> (In reply to Nicholas Kazlauskas from comment #1)
> > Thanks for the bisection.
> >
> > Would you mind posting a full dmesg log for your 4.18.8 kernel?
>
On Mon, Oct 22, 2018 at 01:46:34PM -0700, Douglas Anderson wrote:
> Some eDP panels that are designed to be always connected to a board
> use their HPD signal to signal that they've finished powering on and
> they're ready to be talked to.
>
> However, for various reasons it's possible that the
https://bugs.freedesktop.org/show_bug.cgi?id=108542
--- Comment #3 from davide26...@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #1)
> Thanks for the bisection.
>
> Would you mind posting a full dmesg log for your 4.18.8 kernel?
done. Dunno if that's what you asked for, I am just
https://bugs.freedesktop.org/show_bug.cgi?id=108542
--- Comment #2 from davide26...@gmail.com ---
Created attachment 142207
--> https://bugs.freedesktop.org/attachment.cgi?id=142207=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
On 2018-10-25 11:45, Doug Anderson wrote:
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
>
> On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> > As far as I can tell the panel that was added in commit da50bd4258db
> > ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> > wasn't actually an Innolux
From: Gustavo Padovan
When the execbuf call receives an in-fence it will get the dma_fence
related to that fence fd and wait on it before submitting the draw call.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
Suggested-by: Rob Herring
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c
From: Gustavo Padovan
Refactor fence creation to remove the potential allocation failure from
the cmd_submit and atomic_commit paths. Now the fence should be allocated
first and just after we should proceed with the rest of the execution.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert
From: Gustavo Padovan
To reflect the (backward compatible) changes in the uabi we are bumping
the driver's version.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Gustavo Padovan
On the out-fence side we get fence returned by the submitted draw call
and attach it to a sync_file and send the sync_file fd to userspace. On
error -1 is returned to userspace.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
Suggested-by: Rob Herring
---
This series implements fence support for drm/virtio and
has been tested using qemu, kmscube and the below branches.
Rob Herring solved a reference counting issue and
suggested a context check for the execbuf ioctl, his
changes have been included in the below commits to
keep the tree working at
Add a new field called fence_fd that will be used by userspace to send
in-fences to the kernel and receive out-fences created by the kernel.
This uapi enables virtio to take advantage of explicit synchronization of
dma-bufs.
There are two new flags:
* VIRTGPU_EXECBUF_FENCE_FD_IN to be used when
https://bugs.freedesktop.org/show_bug.cgi?id=108513
Daniel Vetter changed:
What|Removed |Added
Version|DRI git |unspecified
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108513
--- Comment #2 from Daniel Vetter ---
ack
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Thu, Oct 18, 2018 at 08:40:11PM +0800, Icenowy Zheng wrote:
> 在 2018-10-18四的 14:23 +0300，Laurent Pinchart写道：
> > Hi Icenowy,
> >
> > On Thursday, 18 October 2018 13:00:05 EEST Icenowy Zheng wrote:
> > > 在 2018-10-18四的 11:53 +0300，Laurent Pinchart写道：
> > > > On Thursday, 18 October 2018
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote:
>
> Remove some duplicated include.
>
> Signed-off-by: YueHaibing
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 -
> drivers/gpu/drm/amd/powerplay/inc/smu7_common.h | 4
>
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function
> 'radeon_legacy_tv_init_restarts':
> drivers/gpu/drm/radeon/radeon_legacy_tv.c:435:21: warning:
> variable 'pll' set but not used
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Support for AMDGPU specific FreeSync properties and ioctls are dropped
> from amdgpu_dm in favor of supporting drm variable refresh rate
> properties.
>
> The notify_freesync and set_freesync_property functions are dropped
> from
On Mon, Oct 22, 2018 at 01:46:39PM -0700, Douglas Anderson wrote:
> As far as I can tell the bindings that were added in commit
> 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings") weren't actually for Innolux TV123WAM but were actually for
> Innolux P120ZDG-BF1.
>
On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> wasn't actually an Innolux TV123WAM but was actually an Innolux
> P120ZDG-BF1.
>
> As far
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> ---
> Documentation/gpu/drm-kms.rst | 7 +++
> drivers/gpu/drm/drm_connector.c | 22
On Mon, Oct 22, 2018 at 01:46:37PM -0700, Douglas Anderson wrote:
> Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
> ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
> reason we needed that mystery delay is that we weren't paying
> attention to HPD.
>
> Looking at
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> This patch introduces the 'vrr_enabled' CRTC property to allow
> dynamic control over variable refresh rate support for a CRTC.
>
> This property should be treated like a content hint to the driver -
> if the hardware or driver is not capable
On Mon, Oct 22, 2018 at 01:46:35PM -0700, Douglas Anderson wrote:
> Some eDP panels that are designed to be always connected to a board
> use their HPD signal to signal that they've finished powering on and
> they're ready to be talked to.
>
> However, for various reasons it's possible that the
On Mon, Oct 22, 2018 at 01:46:34PM -0700, Douglas Anderson wrote:
> Some eDP panels that are designed to be always connected to a board
> use their HPD signal to signal that they've finished powering on and
> they're ready to be talked to.
>
> However, for various reasons it's possible that the
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
>
> Atomic drivers should attach
Op 25-10-18 om 14:01 schreef Chunming Zhou:
>
> 在 2018/10/25 18:36, Maarten Lankhorst 写道:
>> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>>> 389 but uses
On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
I'm curious to know whether this will/could work over PRIME
>>> I don't see why this shouldn't
On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a
On Thu, Oct 25, 2018 at 12:17:11PM -0400, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> We used an oscilloscope to observe the actual polarity of the
> DI's pixel clock, and saw the following:
>
> DI_GENERAL bit 17 is SET:
> pixel data is stable on the pixel clock's FALLING
Sean Paul writes:
> On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> This is just to collect feedback on this idea, and see whether the
>> overall dri-devel community stands on all this. I think the past few
>> cross-vendor uapi extensions all came with igts
Quoting Chunming Zhou (2018-10-25 16:08:31)
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks held.
>
>
Eric Anholt writes:
> I was going to start working on making the vc4 driver work with
> tinydrm panels, but it turned out tinydrm didn't have the panel I had
> previously bought. So, last night I ported the fbtft staging
> driver over to DRM.
>
> It seems to work (with DT at
>
Without this, the xserver relies on what the 3D driver exposes and
assumes that the display can handle it, and then the DRM driver
happily tries to scan out a tiled format.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_simple_kms_helper.c | 8
Am Do., 25. Okt. 2018 um 15:35 Uhr schrieb Emil Velikov
:
>
> On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner
> wrote:
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> > xf86drm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/xf86drm.c b/xf86drm.c
> > index
On Thu, Oct 25, 2018 at 12:10 PM Alex Gonzalez wrote:
>
> The ConnectCore 6UL SBC Pro has an AUO/Goodix LCD accessory kit that is
> connected on the LVDS interface through an on-board LVDS transceiver.
>
> This change adds support for the touch interface.
>
> Signed-off-by: Alex Gonzalez
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> This change adds support for the AUO G101EVN010 lcdif panel for the
> mxsfb DRM driver.
>
> Signed-off-by: Alex Gonzalez
> ---
> arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
>
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> Select CONFIG_TOUCHSCREEN_GOODIX so that we can have functional touch
> screen by default on Digi International's AUO/Goodix LCD accessory kit used
> with the ConnectCore 6UL SBC Pro (ccimx6ulsbcpro) board.
>
> Signed-off-by: Alex Gonzalez
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Alex Deucher changed:
What|Removed |Added
CC||harry.wentl...@amd.com
--- Comment #1
https://bugs.freedesktop.org/show_bug.cgi?id=108554
Bug ID: 108554
Summary: In kernel 4.14.59, monitor resolution is detected
correctly. In kernels after that, they are not
detected correctly.
Product: DRI
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Robert Strube changed:
What|Removed |Added
Attachment #142205|fresh dmesg log booting |fresh dmesg log booting
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #19 from Robert Strube ---
Created attachment 142205
--> https://bugs.freedesktop.org/attachment.cgi?id=142205=edit
fresh dmesg log booting system *wite* eGPU connected at boot
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #18 from Robert Strube ---
Created attachment 142204
--> https://bugs.freedesktop.org/attachment.cgi?id=142204=edit
sudo cat /proc/iomem *with* eGPU connected at boot
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #17 from Robert Strube ---
Created attachment 142203
--> https://bugs.freedesktop.org/attachment.cgi?id=142203=edit
lspci *with* eGPU attached at boot
--
You are receiving this mail because:
You are the assignee for the
Den 27.09.2018 13.45, skrev Yannick FERTRE:
Hi Noralf,
many thanks for your patch.
Acked-by: Yannick Fertré
Applied to drm-misc-next, thanks.
Noralf.
On 09/08/2018 03:46 PM, Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev
Den 03.10.2018 21.24, skrev Neil Armstrong:
Hi Noralf,
Le 08/09/2018 15:46, Noralf Trønnes a écrit :
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks.
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Generated by: scripts/coccinelle/locks/call_kern.cocci
v2:
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #16 from Robert Strube ---
Created attachment 142202
--> https://bugs.freedesktop.org/attachment.cgi?id=142202=edit
fresh dmesg log booting system *without* eGPU
--
You are receiving this mail because:
You are the assignee for
https://bugzilla.kernel.org/show_bug.cgi?id=201505
--- Comment #5 from Jan Ziak (http://atom-symbol.net)
(0xe2.0x9a.0...@gmail.com) ---
Created attachment 279151
--> https://bugzilla.kernel.org/attachment.cgi?id=279151=edit
bisect.log
I bisected the issue but encountered some inconsistencies
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Robert Strube changed:
What|Removed |Added
Attachment #142200|lspci (no eGPU) |lspci with eGPU *not*
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #15 from Robert Strube ---
Created attachment 142201
--> https://bugs.freedesktop.org/attachment.cgi?id=142201=edit
sudo cat /proc/iomem when eGPU *not* connected
sudo cat /proc/iomem when eGPU *not* connected
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #14 from Robert Strube ---
Created attachment 142200
--> https://bugs.freedesktop.org/attachment.cgi?id=142200=edit
lspci (no eGPU)
lspci -t -nn -v output when the eGPU is *not* connected.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=108318
--- Comment #9 from John Galt ---
R600_DEBUG=nir works around this issue. If requested, I can provide apidoc of
this rendering issue.
--
You are receiving this mail because:
You are the assignee for the
1 - 100 of 174 matches
Mail list logo
