https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #80 from Mauro Gaspari ---
(In reply to Alex Deucher from comment #79)
> the ta bin is optional. It's only used for server cards with xgmi and ras
> features. Consumer cards don't support those features and don't use it.
Alex,
Tha
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #79 from Alex Deucher ---
the ta bin is optional. It's only used for server cards with xgmi and ras
features. Consumer cards don't support those features and don't use it.
--
You are receiving this mail because:
You are the assig
On Fri, Aug 02, 2019 at 09:45:15AM -0700, Gurchetan Singh wrote:
> On Wed, Jul 31, 2019 at 11:40 PM Gerd Hoffmann wrote:
> >
> > On Wed, Jul 31, 2019 at 07:25:13PM -0700, Gurchetan Singh wrote:
> > > The main use for udmabuf is sending guest memory pages
> > > to the host.
> > >
> > > It's general
https://bugs.freedesktop.org/show_bug.cgi?id=105282
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On 8/4/19 8:11 PM, Nathaniel Russell wrote:
> I'm getting an error message when the uvcvideo module is loaded into
> the kernel. Can somebody help me figure this out please?
>
Looks more like it is related to i915 driver:
[ 18.728238] [ cut here ]
[ 18.728248] timed o
Thanks Nathan. The patch is reviewed-by: Evan Quan
> -Original Message-
> From: Nathan Chancellor
> Sent: Monday, August 05, 2019 4:37 AM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhou, David(ChunMing)
>
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesk
On Mon, 5 Aug 2019 at 08:23, Mikhail Gavrilov
wrote:
>
> Hi folks,
> Two weeks ago when commit 22051d9c4a57 coming to my system.
> Started happen randomly errors:
> "gnome-shell: page allocation failure: order:4,
> mode:0x40cc0(GFP_KERNEL|__GFP_COMP),
> nodemask=(null),cpuset=/,mems_allowed=0"
> S
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder v
From: John Hubbard
Provide a more capable variation of put_user_pages_dirty_lock(),
and delete put_user_pages_dirty(). This is based on the
following:
1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page*() var
From: John Hubbard
Changes since v5:
* Patch #1: Fixed a bug that I introduced in v4:
drivers/infiniband/sw/siw/siw_mem.c needs to refer to
umem->page_chunk[i].plist, rather than umem->page_chunk[i].
Changes since v4:
* Christophe Hellwig's review applied: deleted siw_free_plist() and
__
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder v
https://bugs.freedesktop.org/show_bug.cgi?id=110199
--- Comment #13 from 1...@protonmail.com ---
I can confirm this issue exists on rx560
i have discovered a workaround,
if you copy the stock powerplaytable to a file with
cat /sys/class/drm/card0/device/pp_table > pptable
then load the stock p
On 2019-08-02 16:07, Jason Gunthorpe wrote:
> When using mmu_notififer_unregister_no_release() the caller must ensure
> there is a SRCU synchronize before the mn memory is freed, otherwise use
> after free races are possible, for instance:
>
> CPU0 CPU1
>
The drivers core bumps runtime PM refcount during of entering into
suspend to workaround some problem where parent device may become turned
off before its children. For now CRTCs are only getting disabled on
suspend and in order to actually suspend the display controllers hardware,
the runtime PM n
There are no errors that can be reported by this function,
so drop the return code.
Fix the only bridge driver that checked the return result.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Ve
Move inline functions from include/drm/drm_panel.h to drm_panel.c.
This is in preparation for follow-up patches that will add extra
logic to the functions.
As they are no longer static inline, EXPORT them.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maarten Lankhorst
Cc
Replace open coded version with call to drm_panel_get_modes().
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
d
Panels often supports backlight as specified in a device tree.
Update the drm_panel infrastructure to support this to
simplify the drivers.
With this the panel driver just needs to add the following to the
probe() function:
err = drm_panel_of_backlight(panel);
if (err)
return
Inline comments provide better space for additional comments.
Comments was slightly edited to follow the normal style,
but no change to actual content.
Used the opportuniy to change the order in drm_panel_funcs
to follow the order they will be used by a panel.
Signed-off-by: Sam Ravnborg
Cc: Maar
To prepare the driver to receive drm_connector only in the get_modes()
callback, move bus_flags handling to ili9322_get_modes().
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 34 +---
1 file changed, 16 insert
Use drm_panel infrastrucute:
- drm_panel has guards for calling disable/enable twice
- drm_panel has backlight support
To use the drm_panel infrastructure use the drm_panel_*
variants for prepare/enable/disable/unprepare.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Sam Ravnborg
---
dri
drm_panel_attach() will check if there is a controller
already attached - drop the check in the driver.
Use drm_panel_get_modes() so the driver no longer uses the function
pointer.
Signed-off-by: Sam Ravnborg
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Many panel drivers duplicate logic to prevent prepare to be called
for a panel that is already prepared.
Likewise for enable.
Implement this logic in drm_panel so the individual drivers
no longer needs this.
A panel is considered prepared/enabled only if the prepare/enable call
succeeds.
For disab
Use the drm_panel_get_modes function.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra
Call via drm_panel_get_modes().
Signed-off-by: Sam Ravnborg
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c
Use the function drm_panel_get_modes().
Signed-off-by: Sam Ravnborg
Cc: Alexios Zavras
Cc: Thomas Gleixner
Cc: Allison Randal
Cc: Sam Ravnborg
Cc: Enrico Weigelt
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
Use the drm_panel_(enable|disable|get_modes) functions.
Signed-off-by: Sam Ravnborg
Cc: Benjamin Gaignard
Cc: Vincent Abriou
---
drivers/gpu/drm/sti/sti_dvo.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo
The first 9 patches replaces direct use of the drm_panel
function pointers with their drm_panel_* counterparts.
The function pointers are only supposed to be used by
the drm_panel infrastructure and direct use are discouraged.
ili9322 is updated to handle bus_flags in get_modes like everyone else.
Use drm_panel_get_modes() to access modes.
This has a nice side effect to simplify the code.
Signed-off-by: Sam Ravnborg
Cc: Stefan Agner
Cc: Alison Wang
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/
Use the drm_panel_get_modes() function.
Signed-off-by: Sam Ravnborg
Cc: Marek Vasut
Cc: Stefan Agner
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/mxsfb/mxsfb_out.c | 2 +-
1 fil
Use the drm_panel_get_modes() function to get the modes.
This patch leave one test for the function pointer:
panel->funcs->get_modes
This is used to check if the panel may have any modes.
There is no direct replacement.
We may be able to just check that drm_panel_get_modes() return > 0,
but a
Hi
I did some further analysis on this problem and found that the blinking
cursor affects performance of the vm-scalability test case.
I only have a 4-core machine, so scalability is not really testable. Yet
I see the effects of running vm-scalibility against drm-tip, a revert of
the mgag200 patc
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #14 from Damian Kaczmarek ---
Another workaround is to switch to the text terminal (Ctrl+Alt+F2) before
suspending.
Occuring on Thinkpad T495, Ryzej 3700U, openSUSE Tumbleweed (kernel 5.2.2-1)
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=108641
--- Comment #4 from steelwin...@gmail.com ---
Created attachment 144946
--> https://bugs.freedesktop.org/attachment.cgi?id=144946&action=edit
Shader suspected of causing defect
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=108641
--- Comment #3 from steelwin...@gmail.com ---
Situation still occurs on Mesa 19.1.3, refreshed RenderDoc capture at
https://www47.zippyshare.com/v/fL6gXv7u/file.html
I might be conflating things, but there's also a shader scheduling error:
##po
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #78 from Mauro Gaspari ---
(In reply to Sylvain BERTRAND from comment #77)
> On Sun, Aug 04, 2019 at 05:05:52AM +, bugzilla-dae...@freedesktop.org
> wrote:
> > By the way, Interesting to see that even my ubuntu budgie LTS with va
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #77 from Sylvain BERTRAND ---
On Sun, Aug 04, 2019 at 05:05:52AM +, bugzilla-dae...@freedesktop.org
wrote:
> By the way, Interesting to see that even my ubuntu budgie LTS with valve
> mesa-aco and different kernel, has the same w
Hi Peter,
Thank you for the patch.
On Wed, Jul 31, 2019 at 12:42:33PM +0300, Peter Ujfalusi wrote:
> dma_sync_wait() is calling it so no need to call it in the driver.
>
> Signed-off-by: Peter Ujfalusi
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 -
> 1
Hi Peter,
Thank you for the patch.
On Wed, Jul 31, 2019 at 12:42:32PM +0300, Peter Ujfalusi wrote:
> Instead of dma_dev->device_prep_dma_memcpy() use the existing macro to
> prepare the memcpy.
>
> Signed-off-by: Peter Ujfalusi
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/o
On Tue, Jul 30, 2019 at 04:01:23PM +0100, Emil Velikov wrote:
> On 2019/07/26, Andrzej Pietrasiewicz wrote:
> > It is difficult for a user to know which of the i2c adapters is for which
> > drm connector. This series addresses this problem.
> >
> > The idea is to have a symbolic link in connector'
Hi Andrzej,
On Fri, Jul 26, 2019 at 07:22:54PM +0200, Andrzej Pietrasiewicz wrote:
> It is difficult for a user to know which of the i2c adapters is for which
> drm connector. This series addresses this problem.
>
> The idea is to have a symbolic link in connector's sysfs directory, e.g.:
>
> ls
Improve the documentation of the ddc field by using DDC and I2C
consistently, and explaining more clearly what the field points to.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_connector.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_connecto
Hi Andrzej,
On Sun, Aug 04, 2019 at 03:04:37PM +0300, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch, and sorry for the late review (I've been
> travelling for the past few weeks).
>
> On Fri, Jul 26, 2019 at 07:22:55PM +0200, Andrzej Pietrasiewicz wrote:
> > Add generic code
Hi Andrzej,
Thank you for the patch, and sorry for the late review (I've been
travelling for the past few weeks).
On Fri, Jul 26, 2019 at 07:22:55PM +0200, Andrzej Pietrasiewicz wrote:
> Add generic code which creates symbolic links in sysfs, pointing to ddc
> interface used by a particular video
https://bugs.freedesktop.org/show_bug.cgi?id=111240
Denys changed:
What|Removed |Added
CC||alfabus...@gmail.com
--- Comment #3 from Denys
Drop use of the deprecated drmP.h header file.
While touching the list of include files divide them
into blocks and sort within each block.
Fix fallout.
Signed-off-by: Sam Ravnborg
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: David Airlie
Cc: Daniel Vetter
Cc: mal...@foss.arm.com
---
drivers/gpu/d
Drop use of the deprecated drmP.h header file.
For all touched files divide include files into blocks,
and sort them within the blocks.
Fix fallout.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/dc.c| 13 ++
This set of patches is one of the final steps before
we have succeeded to stop using drmP.h in all of drm/.
There is a few patches in flight through other trees
and the plan is that all users shall be gone in the
upstream kernel after next merge window.
The patches has seen build test with variou
Drop use of the deprecated drmP.h header file.
While touching the list of include files group them and sort them.
Fix fallout from the header file removal.
Signed-off-by: Sam Ravnborg
Cc: Russell King
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/armada/armada_crtc.c| 10 +++-
Drop use of the deprecated drmP.h header file.
Fix fallout.
Signed-off-by: Sam Ravnborg
Cc: Russell King
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gp
https://bugs.freedesktop.org/show_bug.cgi?id=111240
--- Comment #2 from Denys ---
On the Arch you have more fps then Ubuntu, probably Kernel 5.1 better then 5.0.
Just now update Kernel to 5.0.0-23-generic, it seems nothing change, same 26-27
fps on basic preset.
Christoph Haag, do you know the
51 matches
Mail list logo