On Wed, Feb 21, 2018 at 12:21:50AM +0200, Jyri Sarha wrote:
> @@ -94,6 +114,8 @@ static void panel_bridge_detach(struct drm_bridge *bridge)
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
>
> drm_panel_detach(panel_bridge->panel);
> +
> + device_link_del(
On Wed, 21 Feb 2018, Linus Walleij wrote:
> On Tue, Feb 20, 2018 at 3:20 PM, Jani Nikula wrote:
>
>> The DOC: line acts as an identifier for the :doc: include. Fixes:
>>
>> ./drivers/gpu/drm/tve200/tve200_drv.c:1: warning: no structured comments
>> found
>>
>> Cc: Linus Walleij
>> Signed-off-by
[+cc Rafael]
On Tue, Feb 20, 2018 at 05:04:00PM +0200, Jyri Sarha wrote:
> On 20/02/18 14:03, Thierry Reding wrote:
> > On Tue, Feb 20, 2018 at 01:28:48PM +0200, Jyri Sarha wrote:
> >> On 20/02/18 12:34, Thierry Reding wrote:
> On Mon, Feb 19, 2018 at 10:06:22PM +0200, Jyri Sarha wrote:
> >>>
As many of you know, I've been writing a Vulkan extension for DRM format
modifiers, named VK_EXT_image_drm_format_modifier.
The extension is very close to completion. I've submitted a branch to
Khronos for review. It's receiving active review inside Khronos from
some non-Mesa closed-source window-
On Tue, Feb 20, 2018 at 11:29 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> DRM_DUMB_VGA_DAC is a user-visible symbol. Selecting it can cause unmet
> direct dependencies such as this (on i386, randconfig):
>
> warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct
>
On Tue, Feb 20, 2018 at 3:20 PM, Jani Nikula wrote:
> The DOC: line acts as an identifier for the :doc: include. Fixes:
>
> ./drivers/gpu/drm/tve200/tve200_drv.c:1: warning: no structured comments found
>
> Cc: Linus Walleij
> Signed-off-by: Jani Nikula
Whoa, good catch!
Reviewed-by: Linus Wa
On Thu 21 Dec 2017, Daniel Vetter wrote:
> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen
> wrote:
>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico
>> wrote:
>>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg
>>> wrote:
I'd like to see concrete examples of actual displ
https://bugs.freedesktop.org/show_bug.cgi?id=105005
--- Comment #11 from Dmitry ---
The kernel update didn't fix the problem, I thought. But now I know what the
bug is about. This happens when you enable vertical sync in the settings of
xfce.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #27 from arne_woer...@yahoo.com ---
Created attachment 137493
--> https://bugs.freedesktop.org/attachment.cgi?id=137493&action=edit
journalctl -r|tac of a resume failure with polaris12_uvd.bin from 20180119-2
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #26 from arne_woer...@yahoo.com ---
Created attachment 137492
--> https://bugs.freedesktop.org/attachment.cgi?id=137492&action=edit
dmesg of boot/suspend/resume with polaris12_uvd.bin from 20180104
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #22 from Harry Wentland ---
Thanks for fixing and testing the patch. I'll get it reviewed and merged.
It looks like the dc_log=1 didn't take. I'd expect a lot more spam from DC if
it took. It should be fine in any 4.15 RC but there
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #17 from Alex Deucher ---
amd-staging-drm-next is still based on 4.15-rc4 which still has the regression
mentioned in comment 14. Can you try 4.15 final or my drm-next-4.17-wip
branch?
--
You are receiving this mail because:
You a
From: Dave Airlie
This exposes to mesa that it can use the fixed ioctl for querying
later cap sets, cap set 1 is forever frozen in time.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 17 +++--
include/uapi/drm/virtgpu_drm.h | 1 +
2 files changed,
Hi Daniel,
Thank you for the patch.
On Tuesday, 20 February 2018 00:53:52 EET Daniel Vetter wrote:
> Motivated by patch review.
>
> The table is really hard to read in source form, hard to edit, and
> we've moved away to more focused sections about specific features and
> how they're exposed in
On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:
> > Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
> > > On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
> > > > > OK, but neither case would in fact n
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #16 from dwagner ---
I noticed in the git log of amd-staging-drm-next that multiple patches
were committed that might be related to S3 resumes, so I retried whether
a kernel compiled from the current amd-staging-drm-next head is able
On Tue, Feb 20, 2018 at 04:17:19PM +0200, Imre Deak wrote:
> On Tue, Feb 20, 2018 at 02:20:17PM +0100, Daniel Vetter wrote:
> > Noticed while reading some unrelated patches. Unfortunately Imre's
> > patch to add our early/late hooks predated the device_link
> > infrastructure by 2 years.
> >
> > C
On Tue, 20 Feb 2018 10:03:56 +0200 Jani Nikula
wrote:
> On Mon, 19 Feb 2018, Pavel Machek wrote:
> > On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> >> Yeah, pls split this into one patch per area, with a suitable patch
> >> subject prefix. Look at git log of each file to get a feeling for w
On Wed, Feb 21, 2018 at 12:21:50AM +0200, Jyri Sarha wrote:
> Currently the master drm driver is not protected against the attached
> panel driver from becoming unavailable. Adding a device_link with
> DL_FLAG_AUTOREMOVE flag unbinds the master drm device (the consumer)
> when the panel device (the
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #21 from dwagner ---
Created attachment 137487
--> https://bugs.freedesktop.org/attachment.cgi?id=137487&action=edit
dmesg output after Harry's recent patch for the "6G" check was applied
--
You are receiving this mail because:
Y
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #20 from dwagner ---
(In reply to Harry Wentland from comment #19)
> Created attachment 137476 [details] [review]
> drm/amd/display: Default HDMI6G support to true. Log VBIOS table error.
>
> Can you see if this helps? Our Windows d
The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7794.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
i
The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched l
From: Pantelis Antoniou
The changeset helpers are easier to use, use them instead of
using the static property.
Signed-off-by: Pantelis Antoniou
Acked-by: Wolfram Sang
["okay" -> "ok"]
Signed-off-by: Laurent Pinchart
---
drivers/i2c/muxes/i2c-demux-pinctrl.c | 12 +++-
1 file changed
The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7792.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
i
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Added power-domains and resets properties to LVDS nodes
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
-
From: Pantelis Antoniou
Adds a changeset helper for moving a subtree to a different place
in the running tree. This is useful in advances cases of dynamic
device tree construction.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Laurent Pinchart
---
drivers/of/dynamic.c | 66 +
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Added power-domains and resets properties to LVDS nodes
- Dropped bogus changes from the rcar-du driver
Changes since v2:
- Fi
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Added power-domains and resets properties to LVDS nodes
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
-
From: Pantelis Antoniou
Add an __of_node_dupv() private method and make __of_node_dup() use it.
This is required for the subsequent changeset accessors which will
make use of it.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Laurent Pinchart
---
drivers/of/dynamic.c | 29 +++
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Added power-domains and resets properties to LVDS nodes
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
-
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Added power-domains and resets properties to LVDS nodes
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
-
From: Pantelis Antoniou
Changesets are very powerful, but the lack of a helper API
makes using them cumbersome. Introduce a simple copy based
API that makes things considerably easier.
To wit, adding a property using the raw API.
struct property *prop;
prop = kzalloc(sizeof(*pro
The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.
Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.
Signed-off-
Hello,
This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.
To fix the, patches 01/16 and
The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Herring
---
Changes since v1:
- Remove the LVDS reg range from the example
- Remove the reg-names property
---
.../devicetree/bindings/
From: Pantelis Antoniou
Add a unitest specific for the new changeset helpers.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Laurent Pinchart
---
drivers/of/unittest.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/of/unittest
The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Herring
---
Changes since v1:
- Move the SoC name before the IP name in compatible strings
- Rename parallel input to parallel RGB input
- F
Currently the master drm driver is not protected against the attached
panel driver from becoming unavailable. Adding a device_link with
DL_FLAG_AUTOREMOVE flag unbinds the master drm device (the consumer)
when the panel device (the supplier) becomes unavailable.
Signed-off-by: Jyri Sarha
Suggeste
On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> Back in 2013, runtime PM for GPUs with integrated HDA controller was
> introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver
> control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime
> suspend/resume on op
https://bugs.freedesktop.org/show_bug.cgi?id=105179
Gregor Münch changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
Philipp Zabel writes:
> Should these be backported to older kernels as well, to avoid burning
> the fbdev console into VR headset OLED displays?
I don't think so; it's a bunch of code to backport, and the matching
code for the X desktop hasn't even landed upstream yet. Wayland doesn't
even have
https://bugs.freedesktop.org/show_bug.cgi?id=105177
--- Comment #5 from Alex Deucher ---
Also please attach your xorg log.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=105177
--- Comment #4 from Alex Deucher ---
Can you attach a picture?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #9 from Öyvind Saether ---
I get random blue color screen flickering perhaps once every few minutes on
each monitor with redshift and a RX 580 and a 3x4k 60Hz setup with kernel
4.15.3 and amdgpu.dc=1. My initial response was that amd
On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> PCI devices not bound to a driver are supposed to stay in D0 during
> runtime suspend.
Doesn't "runtime suspend" mean an individual device is suspended while
the rest of the system remains active?
If so, maybe it would be more direct
https://bugs.freedesktop.org/show_bug.cgi?id=105177
--- Comment #2 from Reimar Imhof ---
Created attachment 137479
--> https://bugs.freedesktop.org/attachment.cgi?id=137479&action=edit
dmesg kernel 4.15.4; connected via hdmi; amdgpu.dc=1
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=105177
--- Comment #3 from Reimar Imhof ---
Created attachment 137480
--> https://bugs.freedesktop.org/attachment.cgi?id=137480&action=edit
dmesg kernel 4.15.4; connected via dvi; amdgpu.dc=1
--
You are receiving this mail because:
You are the assi
https://bugs.freedesktop.org/show_bug.cgi?id=105177
--- Comment #1 from Reimar Imhof ---
Created attachment 137478
--> https://bugs.freedesktop.org/attachment.cgi?id=137478&action=edit
dmesg kernel 4.15.4; connected via hdmi; amdgpu.dc=0
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #25 from Alex Deucher ---
Please attach your full dmesg output from boot.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lis
https://bugs.freedesktop.org/show_bug.cgi?id=105177
Bug ID: 105177
Summary: amdgpu wrong colors with rx460 connected via hdmi
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: no
https://bugs.freedesktop.org/show_bug.cgi?id=105042
Gregor Münch changed:
What|Removed |Added
CC||m.c.sear...@gmail.com
Status
https://bugs.freedesktop.org/show_bug.cgi?id=104285
--- Comment #7 from Gregor Münch ---
This might be a dup of:
https://bugs.freedesktop.org/show_bug.cgi?id=104190
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Mon, Feb 19, 2018 at 10:10:50AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/intel_breadcrumbs.c
>
> between commit:
>
> 117172c8f9d4 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers")
>
> from Linu
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #24 from arne_woer...@yahoo.com ---
with
kernel 4.15.4-2-MANJARO
and
mesa 17.3.5-0
and
linux-firmware 20180119.2a713be-2
the bug is still there...
-arne
--
You are receiving this mail because:
You are the assignee for the bug.__
On Thu, Dec 21, 2017 at 4:56 AM, Daniel Vetter wrote:
> On Thu, Dec 21, 2017 at 11:44:23AM +0530, Archit Taneja wrote:
>> Global shared resources (hwpipes, hwmixers and SMP) for MDP5 are
>> implemented as a part of atomic state by subclassing drm_atomic_state.
>>
>> The preferred approach is to us
https://bugs.freedesktop.org/show_bug.cgi?id=100919
--- Comment #13 from Harry Wentland ---
Are you able to test amd-staging-drm-next
(https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next)? The
issue should be fixed there and you wouldn't have to fiddle with patches.
--
You are
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
The following patch(s) are bugs found by the static compiler
'Parfait'. Care was taken to make sure false positive results
were removed from this patchset.
Parfait Overview
https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13
v1:
Initial release
v2:
- Split origi
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer dereference problem.
- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered. The
return of NULL was removed wit
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.
- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from calls to
drm_crtc_from_index(). There is a possibility, however minute, that
crtc->index may not be found
On Mon, Feb 19, 2018 at 5:06 AM, Sebastian Reichel
wrote:
> Hi,
>
> On Sun, Feb 18, 2018 at 05:24:24PM -0600, Rob Herring wrote:
>> On Thu, Feb 08, 2018 at 07:30:31PM +0100, Sebastian Reichel wrote:
>> > Introduce new "orientation" property for describing in which
>> > orientation a panel has been
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #19 from Harry Wentland ---
Created attachment 137476
--> https://bugs.freedesktop.org/attachment.cgi?id=137476&action=edit
drm/amd/display: Default HDMI6G support to true. Log VBIOS table error.
Can you see if this helps? Our Win
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
https://bugs.freedesktop.org/show_bug.cgi?id=75064
--- Comment #27 from Dominique Dumont ---
Created attachment 137472
--> https://bugs.freedesktop.org/attachment.cgi?id=137472&action=edit
kernel 4.15.rc8 log with drm.debug=0xe and non-working dts-hd
Hello
Unfortunately, DTS_HD still does not
On Tue, Feb 20, 2018 at 12:56 PM, Jani Nikula
wrote:
> On Mon, 19 Feb 2018, Philipp Zabel wrote:
>> This uses the EDID info from Oculus Rift DK1 (OVR-0001), DK2 (OVR-0003),
>> and CV1 (OVR-0004) to mark them as non-desktop.
>
> Not that I know anything about this stuff, but should this series be
On 2/19/2018 8:32 AM, Daniel Vetter wrote:
On Mon, Feb 12, 2018 at 02:51:44PM -0500, Joe Moriarty wrote:
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.
- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from
On 2/19/2018 6:57 AM, Daniel Vetter wrote:
On Mon, Feb 12, 2018 at 02:51:41PM -0500, Joe Moriarty wrote:
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer dereference problem.
- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the
From: "Xiong, James"
Previously a bucket size was used for buffer allocation whether
bo_reuse is false or true. This patch returns NULL in function
drm_intel_gem_bo_bucket_for_size() when bo_reuse is false, the
original requested size is used instead.
Signed-off-by: Xiong, James
---
intel/inte
From: "Xiong, James"
With gem_reuse enabled, when a buffer size is different than
the sizes of buckets, it is aligned to the next bucket's size,
which means about 25% more memory than the requested is allocated
in the worst senario. For example:
Orignal sizeActual
32KB+1Byte 40KB
.
.
.
From: "Xiong, James"
This series 1) align the reuse buffer size to page size instead. The
goal is to reduce memory penalty (up to 25% when reuse is enabled )
while maintain similar performance. A potential overhead is: since a
bucket now contains cached buffers with difference sizes, we need go
t
On Fri, Feb 16, 2018 at 9:12 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> So I finally got around to finish this work! :)
> Here are the updated patchset with fixes for Rob Herring incorporated.
> This follow pretty much the same semantics of other drivers that
> implemented exp
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, February 19, 2018 1:43 AM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Daniel
> Vetter ; Rob Herring ;
> Michal Simek ; Laurent Pi
On Tue, 2018-02-20 at 17:19 +1100, Michael Ellerman wrote:
> Daniel Vetter writes:
> > On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
> > > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
> > > >
> > > > Fix double ;;'s in code.
> > > >
> > > > Signed-off-by: Pavel Machek
> > >
On Tue, Feb 20, 2018 at 04:20:08PM +0200, Jani Nikula wrote:
> The DOC: line acts as an identifier for the :doc: include. Fixes:
>
> ./drivers/gpu/drm/tve200/tve200_drv.c:1: warning: no structured comments found
>
> Cc: Linus Walleij
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
>
On Tue, Feb 20, 2018 at 3:03 AM, Jani Nikula
wrote:
> On Mon, 19 Feb 2018, Pavel Machek wrote:
>> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
>>> Yeah, pls split this into one patch per area, with a suitable patch
>>> subject prefix. Look at git log of each file to get a feeling for what's
>
On Tue, Feb 20, 2018 at 03:49:46PM +0100, Christian König wrote:
> amdgpu needs to verify if userspace sends us valid addresses and the simplest
> way of doing this is to check if the buffer object is locked with the ticket
> of the current submission.
>
> Clean up the access to the ww_mutex inter
OK, I can do that.
Regards,
Samuel Li
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, February 20, 2018 11:23 AM
> To: Li, Samuel
> Cc: Daniel Vetter ; Koenig, Christian
> ; amd-...@lists.freedesktop.org; dri-
> de
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #8 from Harry Wentland ---
Thanks for the video. It helps us understand what you're seeing.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
On Tue, Feb 20, 2018 at 03:46:51PM +, Li, Samuel wrote:
> > ./drivers/gpu/drm/drm_prime.c:342: warning: Function parameter or
> > member 'attach' not described in 'drm_gem_unmap_dma_buf'
> > ./drivers/gpu/drm/drm_prime.c:342: warning: Function parameter or
> > member 'sgt' not described in 'drm
On 2018-02-19 10:27 AM, Daniel Vetter wrote:
> On Thu, Feb 15, 2018 at 03:33:17PM -0500, Alex Deucher wrote:
>> On Thu, Feb 15, 2018 at 2:56 PM, Harry Wentland
>> wrote:
>>> On 2018-02-15 11:40 AM, Daniel Stone wrote:
Hi Harry,
On 15 February 2018 at 16:28, Harry Wentland
wr
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Wed, Jan 24, 2018 at 11:32 AM, Meghana Madhyastha
wrote:
> Move drm helper functions from tinydrm-helpers to linux/backlight for
> ease of use by callers in other drivers.
>
It was a long time coming, but this has finally been applied to
-misc-next. Thanks for sticking with it!
Sean
> Change
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
https://bugs.freedesktop.org/show_bug.cgi?id=104391
--- Comment #1 from Andy Furniss ---
Bump!
Still broken on latest drm-next-4.17-wip.
Tried booting with both screens on, no better.
--
You are receiving this mail because:
You are the assignee for the bug._
On 2018-02-19 03:28 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Include color_enconding and color_range in the plane state dump.
>
> v2: Add kerneldoc (danvet)
>
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Daniel Stone
> Cc: Russell King - ARM Linux
> Cc: Ilia Mirkin
> Cc: Hans V
> ./drivers/gpu/drm/drm_prime.c:342: warning: Function parameter or
> member 'attach' not described in 'drm_gem_unmap_dma_buf'
> ./drivers/gpu/drm/drm_prime.c:342: warning: Function parameter or
> member 'sgt' not described in 'drm_gem_unmap_dma_buf'
> ./drivers/gpu/drm/drm_prime.c:342: warning: Fu
On Tue, Feb 20, 2018 at 2:10 AM, Andrzej Hajda wrote:
> On 19.02.2018 15:28, Rob Herring wrote:
>> On Thu, Feb 15, 2018 at 11:39:15AM +0100, Andrzej Hajda wrote:
>>> These bindings allow to describe most known standard USB connectors
>>> and it should be possible to extend it if necessary.
>>> USB
On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:
> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
> > On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
> > > > OK, but neither case would in fact need the !ctx case right? That's just
> > > > there for completeness sake
Hi Maruthi,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 2d50a98412776a138c305968e0d04b924d27d5a8
commit: 4ab7d004f9ff2e877caa267887360e1804b4edcf [85/454] ASoC: AMD: enable
ACP3x drivers build
config: arm-allmodconfig (
On Tue, Jan 30, 2018 at 04:01:23PM +, Li, Samuel wrote:
>
> Alex helped push this into drm-tip,
> https://cgit.freedesktop.org/drm/drm-tip/commit/drivers/gpu/drm?id=f7a71b0cf9e36c1b0edbfe89ce028a01164b864d
>
> Thanks,
> Samuel Li
>
>
> > -Original Message-
> > From: Daniel Vetter [m
On Tuesday, 2018-02-20 15:02:26 +, Emil Velikov wrote:
> On 20 February 2018 at 10:21, Eric Engestrom
> wrote:
> > On Tuesday, 2018-02-20 17:09:14 +1100, Jonathan Gray wrote:
> >> pthread-stubs is no longer required on OpenBSD and has been removed.
> >> libpthread parts involved moved to libc
On Fri, Feb 16, 2018 at 7:20 PM, Ville Syrjälä
wrote:
> On Fri, Feb 16, 2018 at 06:39:29PM +0100, Maxime Ripard wrote:
>> Some drivers duplicate the logic to create a property to store a per-plane
>> alpha.
>>
>> This is especially useful if we ever want to support extra protocols for
>> Wayland l
On Tuesday, 2018-02-20 15:49:46 +0100, Christian König wrote:
> amdgpu needs to verify if userspace sends us valid addresses and the simplest
> way of doing this is to check if the buffer object is locked with the ticket
> of the current submission.
>
> Clean up the access to the ww_mutex internal
On Wed, Feb 14, 2018 at 2:08 PM, Rob Clark wrote:
> On Wed, Feb 14, 2018 at 1:17 PM, jsanka wrote:
>> On 2/13/2018 12:00 PM, Rob Clark wrote:
>>>
>>> - It looks like, as was the case with mdp4/mdp5 (and really most other
>>> hw)
>>> there are still unequal capabilities for planes (ie. some
Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
OK, but neither case would in fact need the !ctx case right? That's just
there for completeness sake?
Unfortunately not. TTM uses trylock to lock BOs which are about to be
evicted to
On 20/02/18 14:03, Thierry Reding wrote:
> On Tue, Feb 20, 2018 at 01:28:48PM +0200, Jyri Sarha wrote:
>> On 20/02/18 12:34, Thierry Reding wrote:
>>> On Mon, Feb 19, 2018 at 11:59:23PM +0100, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 10:06:22PM +0200, Jyri Sarha wrote:
> Currently ther
On 20 February 2018 at 10:21, Eric Engestrom wrote:
> On Tuesday, 2018-02-20 17:09:14 +1100, Jonathan Gray wrote:
>> pthread-stubs is no longer required on OpenBSD and has been removed.
>> libpthread parts involved moved to libc.
>
> Great news!
> Reviewed-by: Eric Engestrom
>
> Note that meson n
On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
> > OK, but neither case would in fact need the !ctx case right? That's just
> > there for completeness sake?
>
> Unfortunately not. TTM uses trylock to lock BOs which are about to be
> evicted to make room for all the BOs locked wit
On Thu, Feb 15, 2018 at 3:45 PM, Jordan Crouse wrote:
> Remove unused code from dpu_io_util.c. The functions are only
> used inside of the msm driver so remove the EXPORT_SYMBOL
> tags and move the header dpu_io_util.h from include/linux.
>
> Signed-off-by: Jordan Crouse
Thanks,
Reviewed-by: R
1 - 100 of 198 matches
Mail list logo
