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
https://bugs.freedesktop.org/show_bug.cgi?id=111240
Denys changed:
What|Removed |Added
CC||alfabus...@gmail.com
--- Comment #3 from Denys
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
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
---
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
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 -
>
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
> ---
>
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
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
Drop the deprecated drmP.h header file, and trim msm_drv.h
to the relevant include files.
This resulted in a suprisingly many edits as many files relied
on headers included via msm_drv.h.
But msm_drv.h is not supposed to carry include files it do not need, so
the individual files have to include
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
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
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.:
>
>
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
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
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=edit
Shader suspected of causing defect
--
You are receiving this mail because:
You are the assignee for the
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:
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
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
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(-)
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:
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
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
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
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
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
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
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
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
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
---
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
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
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
>
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
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
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*()
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=105282
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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"
>
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;
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
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
51 matches
Mail list logo
