Use Abaqus torturing the amdgpu driver more times will running into locking
first busy BO deadlock .Then the caller will
return EAGAIN and eventually dm_plane_helper_prepare_fb popups out pinned
failed message .For this case, the patch#7
can we add EAGAIN as ERESTARTSYS which filter out the
anyone can pick up to gitlab for libdrm?
Thanks,
-David
On 2019年05月22日 18:46, Koenig, Christian wrote:
Am 22.05.19 um 11:07 schrieb Chunming Zhou:
a) delta: only DRM_CAP_SYNCOBJ_TIMELINE
b) Generated using make headers_install.
c) Generated from origin/drm-misc-next commit
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #22 from Mauro Gaspari ---
I ran more tests:
1. Installed Arch Linux, vulkan, llvm8 and ran wine games with DXVK. With same
kernel parameters on grub, no freezes, no crashes. Great performance.
2. Installed Ubuntu Budgie 19.04,
Hey Linus,
Nothing too unusual here for rc2.
i915:
- boosting fix
- bump ready task fixes
- GVT - reset fix, error return, TRTT handling fix
amdgpu:
- DMCU firmware loading fix
- Polaris 10 pci id for kfd
- picasso screen corruption fix
- SR-IOV fixes
- vega driver reload fixes
- SMU locking
User may send null writeback configurations for writeback connector like:
- Only bind the writeback connector to crtc.
- set a fb_id(0) to writeback_fb_id_property
All above configurations are meaningless for writeback, but since they are
still valid configurations, accept them.
Depends on:
-
Since the component_state->input[i] is only valid when it is active, the
content of input[i] is undefined if it is inactive. The user must check the
state->active_inputs with input index firstly before using state->input[i].
Refine the function to_d71_input_id and directly move such check into it.
Booting up with DMA_API_DEBUG_SG=y generates a warning below due to the
driver forgot to set dma_parms appropriately. Set it after
vmw_dma_masks(), so it can choose a size either DMA_BIT_MASK(64) or
DMA_BIT_MASK(44).
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to
In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
is dereferenced in the following codes. However, memory allocation
functions such as kstrdup() may fail and returns NULL. Dereferencing
this null pointer may cause the kernel go wrong. Thus we should check
this kstrdup()
https://bugs.freedesktop.org/show_bug.cgi?id=110749
--- Comment #2 from Cyrax ---
Created attachment 144338
--> https://bugs.freedesktop.org/attachment.cgi?id=144338=edit
Xorg log before starting the game
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110749
Cyrax changed:
What|Removed |Added
Priority|medium |highest
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=110749
--- Comment #1 from Cyrax ---
OS : Arch Linux with linux-next-git kernel
https://aur.archlinux.org/packages/linux-next-git
With latest libdrm-git, mesa-git and llvm-git packages installed.
local/linux-next-git 20190523.r0.gf48b97e163b3-1
https://bugs.freedesktop.org/show_bug.cgi?id=110749
Bug ID: 110749
Summary: [Vega 11] [amdgpu retry page fault
VM_L2_PROTECTION_FAULT_STATUS] System lock up during
playing Steam version of Saints Row 3
Product: DRI
https://bugs.freedesktop.org/show_bug.cgi?id=110701
--- Comment #26 from Yury Zhuravlev ---
(In reply to Christoph Haag from comment #25)
> (In reply to Yury Zhuravlev from comment #24)
> > (In reply to Marek Olšák from comment #23)
> > > Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae.
On Fri, 2019-05-24 at 01:28 +0300, Imre Deak wrote:
> On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> > Patch mostly looks good to me, one comment below
> >
> > On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > > Fix the breakage resulting in the stacktrace below, due to tx
On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> Patch mostly looks good to me, one comment below
>
> On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > Fix the breakage resulting in the stacktrace below, due to tx queue
> > being full when trying to send an up-reply.
Hi all,
After merging the drm-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'load_dmcu_fw':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:667:7: error:
implicit declaration of
Patch mostly looks good to me, one comment below
On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> Fix the breakage resulting in the stacktrace below, due to tx queue
> being full when trying to send an up-reply. txmsg->seqno is -1 in this
> case leading to a corruption of the mstb object by
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #16 from Jan Ziak (http://atom-symbol.net)
<0xe2.0x9a.0...@gmail.com> ---
I confirm that reverting "mesa: unreference current winsys buffers when
unbinding winsys buffers" fixes the rendering issues in Spotify and Visual
Studio
On Thu, May 23, 2019 at 06:43:46PM +0100, Catalin Marinas wrote:
> On Thu, May 23, 2019 at 09:38:19AM -0700, Kees Cook wrote:
> > What on this front would you be comfortable with? Given it's a new
> > feature isn't it sufficient to have a CONFIG (and/or boot option)?
>
> I'd rather avoid
Fix the breakage resulting in the stacktrace below, due to tx queue
being full when trying to send an up-reply. txmsg->seqno is -1 in this
case leading to a corruption of the mstb object by
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
in process_single_up_tx_qlock().
[ +0,005162]
On Thu, May 23, 2019 at 10:36 AM Steven Rostedt wrote:
>
> >
> > Of course, you probably want the usual "at least use 'int'" semantics,
> > in which case the "type" should be "(x)+0":
> >
> > #define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
> >
> > and the 8-bit and 16-bit cases
Quoting Dongli Zhang (2019-05-21 05:40:39)
> This patch removes IO_TLB_SEGPAGES which is no longer used since
> commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
>
> As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
> IO_TLB_SEGPAGES should be defined on
On Thu, May 23, 2019 at 01:16:45PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This rename makes it more clear that everything initialized in the _init
> function must be cleaned up in a6xx_gmu_remove. This will hopefully
> dissuade people from using device managed resources (for reasons laid
On Thu, May 23, 2019 at 01:16:44PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> of_find_device_by_node() grabs a dev reference, so make sure we clear it
> on error and remove.
>
> Changes in v2:
> - Added to the set (Jordan)
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
Reviewed-by:
On Thu, May 23, 2019 at 01:16:43PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> The gmu driver is initialized and cleaned up with calls from the gpu driver.
> As
> such, the platform device stays valid after a6xx_gmu_remove is called and the
> device managed resources are not freed. In the
On Thu, May 23, 2019 at 01:16:42PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> pdcptr and seqptr aren't necessarily valid, check them before trying to
> unmap them.
>
> Changes in v2:
> - None
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
It has always been sad to me that iounmap() has
On Mon, May 20, 2019 at 02:33:11PM +0530, Jagan Teki wrote:
> pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical
> MIPI clock topology in Allwinner DSI controller.
>
> TCON dotclock driver is computing the desired DCLK divider based on
> panel pixel clock along with input DCLK min,
On Mon, May 20, 2019 at 02:33:10PM +0530, Jagan Teki wrote:
> The current code is computing vertical video start delay as
>
> delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
>
> On which the second parameter
>
> mode->vsync_end - mode->vdisplay = front porch + sync timings
>
>
On Thu, May 23, 2019 at 01:16:41PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> a6xx_gmu_stop() already calls this function via shutdown or force_stop,
> so it's not necessary to call it twice. Previously this would have
> knocked the irq refcount out of sync, but now with the irqs_enabled flag
On Thu, May 23, 2019 at 01:16:40PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> The driver checks for gmu->mmio as a sign that the device has been
> initialized, however there are failures in probe below the mmio init.
> If one of those is hit, mmio will be non-null but freed.
>
> In that
On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote:
> start value in video start delay computation done in below commit
> is as per the legacy bsp drivers/video/sunxi/legacy..
> "drm/sun4i: dsi: Change the start delay calculation"
> (sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2)
>
> This
On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote:
> According to "DRM kernel-internal display mode structure" in
> include/drm/drm_modes.h the current driver is trying to include
> sync timings along with front porch value while checking and
> computing drq set bits in non-burst mode.
>
On Thu, 2019-05-23 at 22:07 +0200, Sebastian Reichel wrote:
> This macro is only used by omapdrm, which should print
> debug messages using the DRIVER category instead of the
> default CORE category.
[]
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h
[]
>
https://bugs.freedesktop.org/show_bug.cgi?id=110712
--- Comment #1 from Haxk20 ---
Im have not been able to get dmesg in the past few days and will not be able to
get one in upcoming few days but hopefully i will be able to get one by the end
of the month.
If somebody could post dmesg in the
While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM
This adds the required infrastructure for manually updated displays,
such as DSI command mode panels. While those panels often support
partial updates we currently always do a full refresh.
The display will be refreshed when something calls the dirty callback,
such as libdrm's drmModeDirtyFB().
Hi,
Here is another round of the DSI command mode panel patchset
integrating the feedback from PATCHv5. The patches are based
on v5.2-rc1 tag. It does not contain the patches required for
OMAP3 support (it needs a workaround for a hardware bug) and
for automatic display rotation. They should get
This macro is only used by omapdrm, which should print
debug messages using the DRIVER category instead of the
default CORE category.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_drv.h | 4 ++--
1
This prepares framedone interrupt handling for
manual display update support.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 50 +
https://bugs.freedesktop.org/show_bug.cgi?id=110701
--- Comment #25 from Christoph Haag ---
(In reply to Yury Zhuravlev from comment #24)
> (In reply to Marek Olšák from comment #23)
> > Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae. Closing.
>
> The original issue was about Vega and on
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #15 from alvarex ---
>
> Using master + this commit reverted: no more corruption in chromium.
I reverted the commit on 19.1.0 rc3 and it works as well.
--
You are receiving this mail because:
You are the assignee for the
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #5 from numz...@yandex.ru ---
The flicker seems to be due to
https://bugs.freedesktop.org/show_bug.cgi?id=102646, despite the fact Arch wiki
tells that affects 120+ Hz only (my monitor runs at 75 Hz). At least fixing
clocks fixes the
https://bugs.freedesktop.org/show_bug.cgi?id=110721
Mathieu Belanger changed:
What|Removed |Added
CC||0xe2.0x9a.0...@gmail.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=110736
Mathieu Belanger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #13 from Mathieu Belanger ---
That bug was affecting Discord, Brave and Chromium.
Fixed by reverting : 811fa9a79cf
--
You are receiving this mail because:
You are the assignee for the
Den 23.05.2019 15.44, skrev Noralf Trønnes:
> struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
> use that directly instead and attach it as a modeset array onto
> drm_client_dev. drm_fb_helper will use this array to store its modesets
> which means it will always initialize
https://bugs.freedesktop.org/show_bug.cgi?id=110736
--- Comment #3 from Mathieu Belanger ---
I would also add that the previous git version I did compile did not have the
problem (Fri May 10 17:39:53 2019)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110736
--- Comment #2 from Mathieu Belanger ---
Created attachment 144332
--> https://bugs.freedesktop.org/attachment.cgi?id=144332=edit
Brave browser
Here a screenshot of a Brave browser tab
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110736
--- Comment #1 from Mathieu Belanger ---
I have the same bug
It started yesterday after a reboot.
Between the reboot and the previous reboot I did emerge -e the whole things so
I'm not totally sure it's mesa related
I have the bug in:
*
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #4 from numz...@yandex.ru ---
Just downgraded xf86-video-amdgpu back to 19.0.0-1. The flicker disappeared.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #3 from numz...@yandex.ru ---
New information:
1. Screen turns black at module insertion, be it during bootup or later. But
resuming from hibernation works.
2. On the system, the converter I use is problematic itself. When I
On Thu, 23 May 2019 09:51:29 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
>
> So that at least handles the constant case that the normal "roundup()"
> case also handles.
>
From: Sean Paul
The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.
In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn
From: Sean Paul
This rename makes it more clear that everything initialized in the _init
function must be cleaned up in a6xx_gmu_remove. This will hopefully
dissuade people from using device managed resources (for reasons laid
out in the previous patch).
Changes in v2:
- None
Cc: Jordan Crouse
From: Sean Paul
The gmu driver is initialized and cleaned up with calls from the gpu driver. As
such, the platform device stays valid after a6xx_gmu_remove is called and the
device managed resources are not freed. In the case of gpu probe failures or
unbind, these resources will remain managed.
From: Sean Paul
pdcptr and seqptr aren't necessarily valid, check them before trying to
unmap them.
Changes in v2:
- None
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Sean Paul
a6xx_gmu_stop() already calls this function via shutdown or force_stop,
so it's not necessary to call it twice. Previously this would have
knocked the irq refcount out of sync, but now with the irqs_enabled flag
it's just housekeeping.
Changes in v2:
- None
Cc: Jordan Crouse
From: Sean Paul
of_find_device_by_node() grabs a dev reference, so make sure we clear it
on error and remove.
Changes in v2:
- Added to the set (Jordan)
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +++---
1 file changed, 11
On Thu, May 23, 2019 at 02:13:20PM +0800, CK Hu wrote:
> Hi, Sean:
>
> On Wed, 2019-05-22 at 16:21 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Fixes the following build warning:
> > drivers/gpu/drm/mediatek/mtk_hdmi.c:327:2: warning: enumeration value
> > ‘HDMI_INFOFRAME_TYPE_DRM’ not
On Thu, May 23, 2019 at 02:38:37PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Sean Paul [mailto:s...@poorly.run]
> >Sent: Thursday, May 23, 2019 7:25 PM
> >To: dri-devel@lists.freedesktop.org
> >Cc: Sean Paul ; Shankar, Uma ;
> >Sharma, Shashank ; Ville Syrjälä
> >;
On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
>
> I haven't yet tested this, but what about something like the following:
So that at least handles the constant case that the normal "roundup()"
case also handles.
At the same time, in the case you are talking about, I really do
suspect
Hi Linus, Gerd.
> This moves the modesetting code from drm_fb_helper to drm_client so it
> can be shared by all internal clients.
Could one of you take a look at this series.
Daniel already ack'ed the series on irc, but an extra pair of eyes
is never bad.
For my part I have been through them
On Thu, May 23, 2019 at 03:44:49PM +0100, Catalin Marinas wrote:
> There is also the obvious requirement which I didn't mention: new user
> space continues to run on new/subsequent kernel versions. That's one of
> the points of contention for this series (ignoring MTE) with the
> maintainers
With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the
docs build fails with:
Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent:
Global GTT Fence Handling
~
reST markup error:
Documentation/gpu/i915.rst:403: (SEVERE/4) Title
On Thu, May 23, 2019 at 6:54 AM Maxime Ripard wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
>
On Thu, May 23, 2019 at 5:55 PM Daniel Vetter wrote:
>
> On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote:
> >
> > On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote:
> > > Hi Daniel and Dave,
> > >
> > > We keep adding support for panels at a high rate, is it still worth
> > >
On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote:
>
> On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote:
> > Hi Daniel and Dave,
> >
> > We keep adding support for panels at a high rate, is it still worth listing
> > them individually under cross subsystem changes?
> >
> > First
On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote:
> Hi Daniel and Dave,
>
> We keep adding support for panels at a high rate, is it still worth listing
> them individually under cross subsystem changes?
>
> First pull req for v5.3 here, enjoy!
> As I was writing this mail, I
Hi Daniel and Dave,
We keep adding support for panels at a high rate, is it still worth listing
them individually under cross subsystem changes?
First pull req for v5.3 here, enjoy!
As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame for
the unhandled
HDR case in switch,
Hi,
On Thu, 2019-05-23 at 16:26 +0200, Noralf Trønnes wrote:
> Ease entry for anyone wanting to pick up the bootsplash work by providing
> a couple of pointers.
>
> Signed-off-by: Noralf Trønnes
I think a native DRM bootsplash would be a great thing to have!
Reviewed-by: Paul Kocialkowski
On Thu, 23 May 2019 08:10:44 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
> >
> > +# define roundup_64(x, y) (\
> > +{ \
> > + typeof(y) __y = y;
On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
>
> +# define roundup_64(x, y) (\
> +{ \
> + typeof(y) __y = y; \
> + typeof(x) __x = (x) + (__y - 1);\
>
On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
>
> From: Icenowy Zheng
>
> Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus. eDP output goes
> to an Innolux N116BGE panel.
>
> Enable it in the device tree.
>
>
>-Original Message-
>From: Sean Paul [mailto:s...@poorly.run]
>Sent: Thursday, May 23, 2019 7:25 PM
>To: dri-devel@lists.freedesktop.org
>Cc: Sean Paul ; Shankar, Uma ;
>Sharma, Shashank ; Ville Syrjälä
>; Maarten Lankhorst
>; Maxime Ripard
>; Sean Paul ; David Airlie
>; Daniel Vetter ;
Ease entry for anyone wanting to pick up the bootsplash work by providing
a couple of pointers.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #13 from Andre Klapper ---
> its actually been more then two months since reporting it, its not fixed yet
You (or anyone else) needs to volunteer to investigate and provide a patch.
--
You are receiving this mail because:
You are
Hi Daniel,
On Thu, 23 May 2019 15:11:15 +0200 Daniel Vetter wrote:
>
> That commit is on top of drm-misc, and somehow the .txt version has
> been resurrect in drm-misc-next (so needs to be re-deleted too).
My mistake, the conflict went away (due to the back merge) so my
scripts assumed the file
Am 23.05.19 um 13:50 schrieb Zhou, David(ChunMing):
> 在 2019/5/23 19:03, Christian König 写道:
>> [CAUTION: External Email]
>>
>> Am 23.05.19 um 12:24 schrieb zhoucm1:
>>>
>>> On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #12 from Utku Helvacı (tuxutku) ---
its actually been more then two months since reporting it, its not fixed yet
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #11 from Utku Helvacı (tuxutku) ---
I have bisected the bug, also i have reported it:
https://bugzilla.kernel.org/show_bug.cgi?id=201077
its been a month since reporting it to linux kernel amd team, they acknowledged
the problem.
From: Steven Rostedt (VMware)
In discussing a build failure on x86_32 due to the use of roundup() on
a 64 bit number, I realized that there's no generic equivalent
roundup_64(). It is implemented in two separate places in the kernel,
but there really should be just one that all can use.
From: Sean Paul
Fixes the following warnings:
../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
'hdr_metadata' description in
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 707 ++-
drivers/gpu/drm/drm_fb_helper.c | 692
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
All drivers add all their connectors so there's no need to keep around an
array of available connectors. Instead we just put the useable (not
writeback) connectors in a temporary array using
drm_client_for_each_connector_iter() everytime we probe the outputs.
Other places where it's necessary to
An example to showcase the client API.
TODO:
- A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be
This moves the modesetting code from drm_fb_helper to drm_client so it
can be shared by all internal clients.
Changes this time:
- Improve commit messages
All patches have been reviewed now, thanks alot for reviewing!
Noralf.
Noralf Trønnes (8):
drm/atomic: Move
struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
use that directly instead and attach it as a modeset array onto
drm_client_dev. drm_fb_helper will use this array to store its modesets
which means it will always initialize a drm_client, but it will not
register the client
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */
I should mentioned that this is going to make the find_fence() function
a fair bit more complex :)
On 23/05/2019 14:35, Lionel Landwerlin wrote:
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to
find_fence
From: Lionel Landwerlin
To:
On Thu, May 23, 2019 at 3:04 PM Stephen Rothwell wrote:
>
> Hi Maxime,
>
> On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
> wrote:
> >
> > On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > >
Hi Maxime,
On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between
On Thu, May 23, 2019 at 10:50:41AM +0300, Laurent Pinchart wrote:
> Hi Torsten,
>
> Thank you for the patch.
Thank you for the thorough review!
> On Thu, May 23, 2019 at 08:53:56AM +0200, Torsten Duwe wrote:
> > +{
> > + struct anx6345 *anx6345 = connector_to_anx6345(connector);
> > + int
On Thu, May 23, 2019 at 11:05:40AM +0200, Maxime Ripard wrote:
> > +Optional properties:
> > +
> > + - Video ports for RGB input and eDP output using the DT bindings
> > + defined in [1]
>
> The output node can be optional, but the input one is probably going
> to be needed all the time, since
On Tue, May 21, 2019 at 02:15:19PM +0200, Ondřej Jirman wrote:
> Hi Maxime,
>
> On Tue, May 21, 2019 at 01:46:11PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > Orange Pi 3 board requires
1 - 100 of 155 matches
Mail list logo
