https://bugzilla.kernel.org/show_bug.cgi?id=196379
Chen Yu (yu.c.c...@intel.com) changed:
What|Removed |Added
Status|NEW |NEEDINFO
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #12 from Vedran Miletić ---
Interestingly enough, not exactly the same result, amdgpu again:
[39371/39371] skip: 3231, pass: 15458, warn: 13, fail: 20668, crash: 1
Then on the next try:
[39371/39371] skip: 3231, pass: 15456, warn:
https://bugs.freedesktop.org/show_bug.cgi?id=101739
--- Comment #1 from Roland Scheidegger ---
My naive conclusion from the description would be that the hw is doing earlyz
optimizations when it shouldn't (so, the depth updates happen before the final
sample mask modified by the alpha value is kn
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #11 from Vedran Miletić ---
dmesg with radeon:
[ 1443.752932] show_signal_msg: 8 callbacks suppressed
[ 1443.752936] glslparsertest[31344]: segfault at 20 ip 7f10f2a45a25 sp
7ffd7c7b4ea0 error 4 in radeonsi_dri.so[7f10f271300
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #10 from Vedran Miletić ---
Fedora does not enable AMDGPU CIK, but I rebuilt the kernel manually. Same
story with Xorg/Wayland with the amdgpu kernel driver.
As for piglit, managed to run till the end this time (with radeon):
[39371/
On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce
On Sat, Jul 15, 2017 at 12:14 PM, Ilia Mirkin wrote:
> On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
>> Greetings,
>>
>> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
>> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>>
>> lspci -nn -d 10de:
>> 01:00.0 VG
On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce
Am 15.07.2017 um 09:12 schrieb Arvind Yadav:
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
text data bss dec hex filenam
Am 15.07.2017 um 05:32 schrieb Michel Dänzer:
On 15/07/17 04:47 AM, Felix Kuehling wrote:
On 17-07-13 11:26 PM, Michel Dänzer wrote:
On 14/07/17 06:08 AM, Felix Kuehling wrote:
Allows gdb to access contents of user mode mapped BOs. VRAM access
requires the driver to implement a new callback in
On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote:
> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
> usage we could convert to WARN_ONCE?
Shooting the messenger is generally considered uncool :)
-Mike
___
dri-devel mail
On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote:
> On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote:
>> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
>> wrote:
>>> On Thu, 13 Jul 2017, Stéphane Marchesin
>>> wrote:
So, if you think this is wrong, can you fix this warning in a way
On Fri, 2017-07-14 at 14:42 -0500, Josh Poimboeuf wrote:
>
> Does this fix it?
Yup, both READONLY __bug_table and "extra stern" warning are gone.
> diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> index 39e702d..aa6b202 100644
> --- a/arch/x86/include/asm/bug.h
> +++ b/arch
On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
> > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
>
> > > Urgh, is for some mysterious reason the __bug_table section of modules
> > > ending up in RO memory?
> > >
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
4931072 01565 61d drivers/gpu/d
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
12256 360 976 135923518 gpu/drm/nouve
The conversion is a nice catch, but i'd like to have a bit more context,
see below!
With a better description:
Tobias Klausmann
On 7/14/17 5:10 PM, Karol Herbst wrote:
Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?
Reviewed-By: Karo
On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
wrote:
> On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
>> So, if you think this is wrong, can you fix this warning in a way that
>> you'd like?
>
> As I replied previously [1], with more background, fixing the warnings
> properly, in a way that actual
Now that ARC properly supports DMA mmapping we can use the
standard CMA helper to map dumb buffers. This makes ARC PGU
works with standard DRM consumer applications like, for
example, mpv via DRM.
This fixes the use of dumb buffers.
Signed-off-by: Jose Abreu
Fixes: 0c4250e7b15e ("drm: Add suppor
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
13765 800 20 1458538f9 gpu/drm/vmwgf
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Arvind Yadav (5):
[PATCH 1/5] drm: radeon: constify pci_device_id.
[PATCH 2/5] drm: vmwgfx: constify pci_device_id.
Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?
Reviewed-By: Karol Herbst
On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann
wrote:
> On 7/14/17 3:41 PM, Mike Galbraith wrote:
>>
>> On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
6560 23212 72 298447494 gpu/drm/radeo
On Fri, 2017-07-14 at 17:05 +0200, Tobias Klausmann wrote:
> On 7/14/17 3:41 PM, Mike Galbraith wrote:
> > On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
> >> All DRM did was to slip a
> >> WARN_ON_ONCE() that nouveau triggers into a kernel module where such
> >> things no longer warn,
The current code uses two different enum types for PCH transcoders and
performs implicit conversions between the two types. This is error prone
and causes clang to raise warnings like this:
drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
from enumeration type 'enum pipe' to
On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
> All DRM did was to slip a
> WARN_ON_ONCE() that nouveau triggers into a kernel module where such
> things no longer warn, they blow the box out of the water.
BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WAR
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
2704 808 03512 db8
gpu/drm/hisil
DRM drivers should supply a compat version if they're going to provide
an ioctl implementation at all. This can confuse 32-bit user space on a
64-bit system.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/vgem/vgem_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vgem/v
On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote:
> On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote:
> > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:
> >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:
> >> >
> >> > Some display stuff did change for 4.13 for GM20x+ boa
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Arvind Yadav (5):
[PATCH 1/5] drm: radeon: constify pci_device_id.
[PATCH 2/5] drm: vmwgfx: constify pci_device_id.
On 7/14/17 3:41 PM, Mike Galbraith wrote:
On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.
BTW, turn that irksome WARN_ON_ONCE() in
On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote:
> > Ok, a network outage gave me time to go hunting. Indeed it is a bad
> > interaction with the tree DRM merged into. All DRM did was to slip a
> > WARN_ON_ONCE() that nouve
El Fri, Jul 14, 2017 at 03:43:35PM -0700 Grant Grundler ha dit:
> On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote:
> > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler
> > wrote:
> >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
> >> wrote:
> >>> On Thu, 13 Jul 2017, Stéphane Marchesin
>
On Friday, July 14, 2017 7:38:01 AM PDT Lucas Stach wrote:
> While this is no build dependency, etnaviv will only work correctly on most
> systems if CMA and DMA_CMA are enabled. Select both options if available to
> avoid users ending up with a non-working GPU due to a lacking kernel config.
>
>
Greetings,
box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
kernel: master.today (v4.12-11690-gccd5d1b91f22)
lspci -nn -d 10de:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 8600
GT] [10de:0402] (rev a1)
abreviated dmesg:
...
[3.720990
From: Hans Verkuil
This driver adds support for the Tegra CEC IP. It is based on the
NVIDIA drivers/misc/tegra-cec driver in their 3.10 kernel.
This has been converted to the CEC framework and cleaned up.
Tested with my Jetson TK1 board. It has also been tested with the
Tegra X1 in an embedded
From: Hans Verkuil
In order to support CEC the HDMI driver has to inform the CEC driver
whenever the physical address changes. So when the EDID is read the
CEC driver has to be informed and whenever the hotplug detect goes
away.
This is done through the cec-notifier framework.
The link between
From: Hans Verkuil
Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the
Jetson TK1.
Signed-off-by: Hans Verkuil
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4
arch/arm/boot/dts/tegra124.dtsi | 12 +++-
2 files changed, 15 insertions(+), 1 deletion(
From: Hans Verkuil
This documents the binding for the Tegra CEC module.
Signed-off-by: Hans Verkuil
---
.../devicetree/bindings/media/tegra-cec.txt| 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
di
From: Hans Verkuil
This patch series adds support for the Tegra CEC functionality.
It has two prerequisites:
this cec-notifier patch: https://patchwork.linuxtv.org/patch/42521/
and this workaround: http://www.spinics.net/lists/dri-devel/msg147038.html
A proper fix needs to be found for that w
On Sat, Jul 15, 2017 at 11:10:07AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-07-14 23:46:54)
> > @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct
> > drm_atomic_state *state,
> > struct drm_connector_state *new_conn_state;
> > struct drm_crt
Quoting Daniel Vetter (2017-07-15 10:53:28)
> For modern drivers the DRM core doesn't use struct_mutex at all, which
> means it's defacto a driver-private lock. But since we still need it
> for legacy drivers we can't initialize it in drivers, which means all
> the different instances share one loc
Some DP/HDMI sink need to receive the audio infoframe to play sound,
especially some multi-channel AV receiver, they need the
channel_allocation from infoframe to config the speakers. Send the
audio infoframe via SDP will make them work properly.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/r
On Fri, Jul 14, 2017 at 11:25:14AM +0200, Arnd Bergmann wrote:
> gcc-7 warns about the result of a constant multiplication used as
> a boolean:
>
> drivers/ata/libata-core.c: In function 'ata_timing_quantize':
> drivers/ata/libata-core.c:3164:30: warning: '*' in boolean context, suggest
> '&&' in
Quoting Daniel Vetter (2017-07-14 23:46:54)
> @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct
> drm_atomic_state *state,
> struct drm_connector_state *new_conn_state;
> struct drm_crtc *crtc;
> struct drm_crtc_state *new_crtc_state;
> + stru
Quoting Daniel Vetter (2017-07-15 10:53:28)
> For modern drivers the DRM core doesn't use struct_mutex at all, which
> means it's defacto a driver-private lock. But since we still need it
> for legacy drivers we can't initialize it in drivers, which means all
> the different instances share one loc
For modern drivers the DRM core doesn't use struct_mutex at all, which
means it's defacto a driver-private lock. But since we still need it
for legacy drivers we can't initialize it in drivers, which means all
the different instances share one lockdep key. Despite that they might
be placed in total
The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().
In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
again, which means the plane->fb pointer won't change, hence can't
leak.
- Drivers using drm_atomi
48 matches
Mail list logo