On Mon, 14 Jan 2019, Kieran Bingham wrote:
> Hi Julia,
>
> Thank you for the patch,
>
> On 13/01/2019 09:44, Julia Lawall wrote:
> > Add an of_node_put when the result of of_graph_get_remote_port_parent is
> > not available.
> >
> > The semantic match that finds this problem is as follows
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #17 from Timur Kristóf ---
Hi Everyone,
I've just tested Linux 5.0-rc1 and have not encountered the problem so far.
Looking into it more, I think the same patch set that fixed the Sapphire RX 590
for Michael @ Phoronix also fixed
Den 14.01.2019 16.00, skrev Noralf Trønnes:
>
>
> Den 14.01.2019 03.15, skrev David Lechner:
>> On 1/13/19 3:19 PM, David Lechner wrote:
>>> On 1/11/19 2:12 PM, Noralf Trønnes wrote:
This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now
Applied. thanks.
Alex
On Mon, Jan 7, 2019 at 8:06 AM Matteo Croce wrote:
>
> Fix spelling mistake: "lenght" -> "length"
>
> Signed-off-by: Matteo Croce
> ---
> drivers/gpu/drm/amd/include/atombios.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi Shayenne,
On 10/01/2019 18:16, Shayenne Moura wrote:
> This patch adjust the print string of drm_display_mode object
> to remove drm_mode_object dependency in meson files.
>
> Signed-off-by: Shayenne Moura
Totally missed this one... please respect MAINTAINERS and CC the linux-amlogic
ML
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #16 from Alex Deucher ---
Does removing amdgpu.dpm=1 from the kernel command line fix the issue?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On 12/12/2018 13:39, Neil Armstrong wrote:
> On 12/12/2018 13:22, Maxime Jourdan wrote:
>> Hi Neil,
>> On Wed, Dec 12, 2018 at 10:55 AM Neil Armstrong
>> wrote:
>>>
>>> Hi Maxime,
>>>
>>> On 10/12/2018 10:28, Maxime Jourdan wrote:
In case we are using simplefb or another conflicting
Hi Julia,
On 13/01/2019 10:44, Julia Lawall wrote:
> Add an of_node_put when the result of of_graph_get_remote_port_parent is
> not available.
>
> An of_node_put is also needed when meson_probe_remote completes. This was
> present at the recursive call, but not in the call from meson_drv_probe.
Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
example) the display gets blurry, looking like an invalid framebuffer width.
This commit fixed atomic crtc modesetting in a totally wrong way and
introduced a local unnecessary ->enabled crtc state.
This commit reverts the
One needs to translate the Gralloc buffer flags for AFBC (eg
MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm modifiers.
This gets passed to libdrm via drmModeAddFB2WithModifiers.
Signed-off-by: Ayan Kumar Halder
/-- Note for reviewer
I was able to get this working for
Hi Martin,
On 09/01/2019 23:18, Martin Blumenstingl wrote:
> Hi Neil,
>
> On Wed, Jan 9, 2019 at 2:36 PM Neil Armstrong wrote:
>>
>> Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
>> example) the display gets blurry, looking like an invalid framebuffer width.
>>
>> This
https://bugzilla.kernel.org/show_bug.cgi?id=202263
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=109332
--- Comment #3 from Michel Dänzer ---
(In reply to Nicholas Kazlauskas from comment #2)
> Maybe this can be a configurable option in the meantime?
> I'm not sure how much work that would be to add and maintain, though.
Yeah, I'm afraid I'm not
https://bugzilla.kernel.org/show_bug.cgi?id=202263
Bug ID: 202263
Summary: AMDGPU: DRM couldn't schedule ib on ring (-22)
Product: Drivers
Version: 2.5
Kernel Version: 4.19.12-1-default
Hardware: Intel
OS: Linux
Den 14.01.2019 03.15, skrev David Lechner:
> On 1/13/19 3:19 PM, David Lechner wrote:
>> On 1/11/19 2:12 PM, Noralf Trønnes wrote:
>>> This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
>>> handler. All flushing will now happen in the pipe functions.
>>>
>>> Also enable the
Hi Julia,
Thank you for the patch,
On 13/01/2019 09:44, Julia Lawall wrote:
> Add an of_node_put when the result of of_graph_get_remote_port_parent is
> not available.
>
> The semantic match that finds this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @r exists@
> local
Hi Tomi,
On Monday, 14 January 2019 13:40:36 EET Tomi Valkeinen wrote:
> On 11/01/19 05:50, Laurent Pinchart wrote:
> > From: Tomi Valkeinen
> >
> > Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
> > bind to probe") moved the of_platform_populate() call from dsi_bind()
https://bugzilla.kernel.org/show_bug.cgi?id=202261
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=202261
--- Comment #1 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
Hardware is an AMD PRO A10-8700B R6 CARRIZO
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
On Mon, 14 Jan 2019, Brian Starkey wrote:
> AFBC is a relatively well-established name, whereas arm-fbc is not a
> term anyone will be familiar with.
First time I ever heard of AFBC. ;)
> We could name the file "arm-afbc.rst", though I am slightly against
> namespacing it that way for the
https://bugzilla.kernel.org/show_bug.cgi?id=202261
Bug ID: 202261
Summary: general protection fault: [#1] PREEMPT SMP
Workqueue: events ttm_bo_delayed_workqueue
Product: Drivers
Version: 2.5
Kernel Version: 5.0.0-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=109206
Nicola Orlando changed:
What|Removed |Added
CC||niki.o...@yahoo.it
--- Comment #5
Hi Jani,
On Mon, Jan 14, 2019 at 02:23:46PM +0200, Jani Nikula wrote:
> On Fri, 11 Jan 2019, Liviu Dudau wrote:
> > On Thu, Jan 03, 2019 at 05:44:26PM -0300, Ezequiel Garcia wrote:
> >> Hi Liviu,
> >>
> >> On Mon, 2018-12-03 at 11:31 +, Ayan Halder wrote:
> >> > From: Brian Starkey
> >> >
https://bugs.freedesktop.org/show_bug.cgi?id=109332
--- Comment #2 from Nicholas Kazlauskas ---
In this case it's not actually the mouse operations themselves causing the
stuttering but the framebuffer change. This is a known limitation with the
async plane updates API in DRM and not something
Am 14.01.19 um 08:02 schrieb Chunming Zhou:
> if lru is changed, we cannot do bulk moving.
> v2:
> root bo isn't bulk moving, skip its change.
>
> Change-Id: Ide0fe920295cc25f7cabcf41a6400519e5783f2a
> Signed-off-by: Chunming Zhou
We could now remove all other cases where we set bulk_movable to
Am 14.01.19 um 08:02 schrieb Chunming Zhou:
> allow driver do somethings when lru changed.
> v2:
> address Michel's comments.
>
> Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
> Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 11
https://bugs.freedesktop.org/show_bug.cgi?id=109342
Sih Sîng-hông changed:
What|Removed |Added
QA Contact||xorg-t...@lists.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=109315
Martin Peres changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede
On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux
wrote:
>
> On Fri, Jan 11, 2019 at 03:36:28PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 11, 2019 at 3:32 PM Russell King - ARM Linux
> > wrote:
> > >
> > > On Fri, Jan 11, 2019 at 03:26:44PM +0100, Rafael J. Wysocki wrote:
> > > > On
https://bugs.freedesktop.org/show_bug.cgi?id=109315
--- Comment #4 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- ICL: all tests - skip - No known gpu found for chipset flags 0x16 (amdgpu)
-}
{+ ICL: all tests - skip - No known gpu found for chipset flags
https://bugs.freedesktop.org/show_bug.cgi?id=109315
--- Comment #3 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* ICL: all tests - skip - No known gpu found for chipset flags 0x16 (amdgpu)
-
On Fri, 11 Jan 2019, Liviu Dudau wrote:
> On Thu, Jan 03, 2019 at 05:44:26PM -0300, Ezequiel Garcia wrote:
>> Hi Liviu,
>>
>> On Mon, 2018-12-03 at 11:31 +, Ayan Halder wrote:
>> > From: Brian Starkey
>> >
>> > AFBC is a flexible, proprietary, lossless compression protocol and
>> > format,
On 11/01/19 05:51, Laurent Pinchart wrote:
> Add support for the OSD070T1718-19TS 7" 800x480 panel from One Stop
> Displays to the panel-simple driver.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29
On 11/01/19 05:51, Laurent Pinchart wrote:
> The OSD Displays OSD070T1718-19TS is a 7" WVGA (800x480) 24bit RGB panel
> and is compatible with the simple-panel bindings.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../display/panel/osddisplays,osd070t1718-19ts.txt | 7 +++
> 1 file
On 11/01/19 05:51, Laurent Pinchart wrote:
> OSD Displays is a panel manufacturer. It has been acquired by New Vision
> Displays in 2015 but continues to operate under its own brand name.
>
> Signed-off-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>
On 11/01/19 05:50, Laurent Pinchart wrote:
> Instead of rolling out custom suspend/resume implementations based on
> state information stored in the driver's data structures, use the atomic
> suspend/resume helpers that rely on a DRM atomic state object.
>
> Signed-off-by: Laurent Pinchart
>
CMA helper drivers have been converted to drm_fbdev_generic_setup()
so the fbdev code can be removed.
v3: Remove CMA specific conditional in the generic fbdev client
v2: Clean up the includes some more (Laurent)
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
https://bugs.freedesktop.org/show_bug.cgi?id=109340
--- Comment #6 from Rafał Miłecki ---
Created attachment 143104
--> https://bugs.freedesktop.org/attachment.cgi?id=143104=edit
Xorg.0.log using xf86-video-modesetting
Michel has suggested trying xf86-video-modesetting. A difference from user
On 11/01/19 05:50, Laurent Pinchart wrote:
> The venc_device structure wss_data field is set to 0 and never otherwise
> modified, remove it.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> Tested-by: Sebastian Reichel
> ---
> drivers/gpu/drm/omapdrm/dss/venc.c | 11
On 11/01/19 05:50, Laurent Pinchart wrote:
> The kobj field from struct omap_dss_device is not used. Remove it.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> Tested-by: Sebastian Reichel
> ---
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
> 1 file changed, 2
On 11/01/19 05:50, Laurent Pinchart wrote:
> The omap_connector_attached_encoder() doesn't exist anymore, remove its
> declaration from omap_connector.h.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> Tested-by: Sebastian Reichel
> ---
>
On 11/01/19 05:50, Laurent Pinchart wrote:
> From: Tomi Valkeinen
>
> Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
> bind to probe") moved the of_platform_populate() call from dsi_bind() to
> dsi_probe(), but failed to move the corresponding
> of_platform_depopulate()
Den 28.11.2018 22.27, skrev Noralf Trønnes:
> 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
>
Am 14.01.19 um 11:53 schrieb Ard Biesheuvel:
> On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote:
>> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
>>> ARM systems do not permit the use of anything other than cached
>>> mappings for system memory, since that memory may be mapped in the
>>> linear
Den 28.11.2018 22.27, skrev Noralf Trønnes:
> 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
>
https://bugs.freedesktop.org/show_bug.cgi?id=109340
--- Comment #5 from Rafał Miłecki ---
Created attachment 143103
--> https://bugs.freedesktop.org/attachment.cgi?id=143103=edit
Xorg.0.log
I'm attaching Xorg.0.log at requested with my actions commented properly
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=97639
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109315
Chris Wilson changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
On 11/01/19 05:50, Laurent Pinchart wrote:
> The mode_valid_path() function validates the mode it receives without
> ever modifying it. Constify the mode pointer argument to make that
> explicit.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Ville Syrjälä
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=106470
Dominik 'Rathann' Mierzejewski changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #94 from Michel Dänzer ---
(In reply to tempel.julian from comment #88)
> (TearFree however doesn't work well in general without amdgpu.dc=1).
Can you elaborate on that? Maybe file another report on it.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=109332
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Component|Driver/AMDgpu
https://bugs.freedesktop.org/show_bug.cgi?id=106470
--- Comment #2 from Hans de Goede ---
Hi Dominik,
I found this bug using google since I was checking to see if your DMI BIOS
version is unique :)
Given that you've filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1601623
Now, I guess this
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #16 from Sibren Vasse ---
@bmilreu: No, Michel beat me to it.
See thread here:
https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032528.html
--
You are receiving this mail because:
You are the assignee for the
The etnaviv_gem_get_pages() never returns NULL. It returns error
pointers on error.
Fixes: a8c21a5451d8 ("drm/etnaviv: add initial etnaviv DRM driver")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #1 from Michel Dänzer ---
Please attach the output of dmesg corresponding to the problem.
Somebody will probably need to isolate the exact commit which introduced the
problem using git bisect.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=109340
--- Comment #4 from Michel Dänzer ---
Please attach the corresponding Xorg log file, preferably captured after
reproducing the problem.
--
You are receiving this mail because:
You are the assignee for the
On 01/14, Maarten Lankhorst wrote:
> Op 13-01-2019 om 21:23 schreef Rodrigo Siqueira:
> > Hi,
> >
> > I resend this patch for CI via “intel-...@lists.freedesktop.org” as
> > Daniel suggested, and I got a feedback that reported an issue as can be
> > seen here:
> >
> >
On Mon, Jan 14, 2019 at 08:54:08AM +, Emil Velikov wrote:
> From: Emil Velikov
>
> There are cases (in mesa and applications) where one would open the
> primary node without properly authenticating the client.
>
> Sometimes we don't check if the authentication succeeds, but there's
> also
On Mon, Jan 14, 2019 at 08:44:10AM +, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently we fail to free and detach the drm_file when drm_setup() fails.
> Use the drm_close_helper to do address that.
>
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/drm_file.c | 4 +++-
> 1 file
Am Montag, 14. Januar 2019, 11:05:56 CET schrieb Daniel Vetter:
> On Sun, Jan 13, 2019 at 07:48:49PM +0100, Heiko Stuebner wrote:
> > Am Sonntag, 13. Januar 2019, 09:47:43 CET schrieb Julia Lawall:
> > > The device node iterators perform an of_node_get on each iteration, so a
> > > jump out of the
On Mon, Jan 14, 2019 at 08:43:05AM +, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently only an authenticated master can authenticate another client.
>
> In practise the client can only be master if CAP_SYS_ADMIN is present,
> although having the CAP also sets the client as
On Sun, Jan 13, 2019 at 07:48:49PM +0100, Heiko Stuebner wrote:
> Am Sonntag, 13. Januar 2019, 09:47:43 CET schrieb Julia Lawall:
> > The device node iterators perform an of_node_get on each iteration, so a
> > jump out of the loop requires an of_node_put.
> >
> > The semantic patch that fixes
On Sat, Jan 12, 2019 at 08:32:51PM +0100, Sam Ravnborg wrote:
> With the removal of drmP.h from drm_modeset_helper.h
> the drmP.h are no longer included by any include files
> in include/drm.
> The drmP.h file is thus only included explicit
> either in .c files or in local .h files.
> This makes
On Sun, Jan 13, 2019 at 06:40:38PM -0200, Rodrigo Siqueira wrote:
> Add maintainers and reviewers for VKMS driver
>
> Signed-off-by: Rodrigo Siqueira
Reviewed-by: Daniel Vetter
Since you have commit rights for drm-misc already I think best if you push
this yourself using the dim tooling:
Le sam. 12 janv. 2019 à 20:33, Sam Ravnborg a écrit :
>
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused drm/stm to fail to build.
>
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from drm_modeset_helper.h.
>
> Build tested on
https://bugs.freedesktop.org/show_bug.cgi?id=108592
Chris Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Op 13-01-2019 om 21:23 schreef Rodrigo Siqueira:
> Hi,
>
> I resend this patch for CI via “intel-...@lists.freedesktop.org” as
> Daniel suggested, and I got a feedback that reported an issue as can be
> seen here:
>
>https://patchwork.freedesktop.org/series/51147/
>
> After a careful analysis
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > Changes since the RFC:
> > - Rework vmwgfx too [CH]
> > - Use a distinct type for the DMA page iterator [CH]
> > - Do not have a #ifdef [CH]
>
> ChristophH: Will you ack?
This looks generally fine.
>
> Are you still OK with
On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote:
> Well I was trying convert the RDMA drivers to use your new iterator variant
> and saw the need for it in locations where we need virtual address of the
> pages
> contained in the SGEs.
As far as i can tell that pg_arr[i] value is
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
From: Emil Velikov
This static inline function doesn't modify any state.
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h
From: Emil Velikov
Currently we fail to free and detach the drm_file when drm_setup() fails.
Use the drm_close_helper to do address that.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Emil Velikov
Will be used to plug an existing memory leak.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index
From: Emil Velikov
Currently only an authenticated master can authenticate another client.
In practise the client can only be master if CAP_SYS_ADMIN is present,
although having the CAP also sets the client as authenticated.
Thus DRM_AUTH in AUTH_MAGIC's "DRM_AUTH | DRM_MASTER" is superfluous.
https://bugs.freedesktop.org/show_bug.cgi?id=109340
--- Comment #3 from Rafał Miłecki ---
This problem also occurs when using drm/drm branch drm-next (5.0.0-rc1) with:
[PATCH v7 00/20] MST refcounting/atomic helpers cleanup
on top of it.
The only difference I've noticed is xrandr complaining
On 12/01/2019 10:07, Lukas Bulwahn wrote:
> In the linux kernel MAINTAINERS file, largely
> "xen-de...@lists.xenproject.org (moderated for non-subscribers)"
> is used to refer to the xen-devel mailing list.
>
> The DRM DRIVERS FOR XEN section entry mentions
> xen-de...@lists.xen.org instead,
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21-wip
head: 364c6471cc8cca8dbaa558077597c525b3d7f9e6
commit: 2c5acb77e1ad3dfa5658f6c8b769e264b53728b4 [79/110] drm/amdgpu: Add sysfs
file for PCIe usage v5
New smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:2138
101 - 178 of 178 matches
Mail list logo
