Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

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

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann wrote: > The conversion is a nice catch, but i'd like to have a bit more context, see > below! > > With a better description: > > Tobias Klausmann I don't think it was

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith wrote: > 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

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efa...@gmx.de> 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+ boards. If it's no

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith <efa...@gmx.de> wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]:

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Some details that may be useful in analysis of the bug: 1. lspci -nn -d 10de: 2. What displays, if any, you have plugged into the NVIDIA board when this happens? 3. Any boot parameters, esp relating to ACPI, PM, or related? Cheers, -ilia On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith

Re: [Bug 99900] nouveau: freeze / crash after kernel update to 4.10

On Tue, Jun 20, 2017 at 12:54 PM, Olof Johansson wrote: > Hey, > > This was reported back in February and it seems nobody's given a shit? > Apparently not -- including you. Someone who was interested in seeing this issue fixed would certainly have provided a kernel bisection

Re: [PATCH 19/19] ARM: sun6i: a31s: Enable HDMI display output on the MSI Primo81 tablet

On Wed, Jun 7, 2017 at 6:36 PM, Rob Herring wrote: > On Fri, Jun 02, 2017 at 09:42:19PM +0200, Maxime Ripard wrote: >> On Fri, Jun 02, 2017 at 06:10:24PM +0800, Chen-Yu Tsai wrote: >> > The MSI Primo81 tablet has a micro HDMI connector at the bottom. >> > This is connected to the

Re: [PATCH 4/4] drm/tinydrm: Add RePaper e-ink driver

On Wed, Jun 7, 2017 at 7:52 AM, Noralf Trønnes wrote: > Hi Emil, > > > Den 07.06.2017 11.30, skrev Emil Velikov: >> >> Hi Noralf, >> >> Small drive-by comment, noticed while going through my morning coffee. >> By no means a full review. >> >> On 2 June 2017 at 12:49, Noralf

[RFC PATCH 3/3] drm/nouveau/dispnv04: fix exposed format list

, as tested with modetest. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 36 - 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/di

[RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes

n't at all tested on my NV05 or NV1x hardware. Should probably do that before we push this out. But since I've already been sitting on these patches for a few weeks, thought I'd get them out there. Ilia Mirkin (3): drm/nouveau/overlay: improve error detection, fix pitch setting drm/nouveau/overlay

[RFC PATCH 2/3] drm/nouveau/overlay: add NV21 support

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c index ee7df9ef2695..96354a

[RFC PATCH 1/3] drm/nouveau/overlay: improve error detection, fix pitch setting

. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 80 +++--- 1 file changed, 52 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

On Tue, May 2, 2017 at 11:06 AM, Gerd Hoffmann wrote: > Radeon and nvidia (nv40) cards where mentioned. I'll try to summarize > (feel free to correct me if I'm wrong). > > nvidia has support for 8 bit-per-color formats only on bigendian hosts. > Not sure whenever this is a

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Sat, Apr 22, 2017 at 9:48 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote: >>> On S

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä > <ville.syrj...@linux.intel.com> wrote: >> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote: >>> On Fri, Apr 21, 2017 at 12:59

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote: >> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote: >> > On Fri, Ap

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote: >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann <kra...@redhat.com> wrote: >> > While working on graphics support

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> > Cc: Daniel Vetter <daniel.vet...@intel.com> > Cc: Pekka Paalanen <ppaala...@gmail.com> > Cc: Ilia Mirkin <imir...@alum.mit.edu> > Cc: Michel Dänzer <mic...@daenzer.net> > Cc: Alex Deucher <alexdeuc...@gmail

Re: [PATCH v2 4/5] nouveau_hwmon: Add support for auto_point attributes

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > This patch creates a special group attributes for attrs like "*auto_point*". > We check if we have support for them, and if we do, we gather them all in > an attribute_group's structure which is the parameter

Re: [Nouveau] [PATCH v2 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > +static char *input_label = "GPU core"; This needs to be static const char input_label[] = "GPU core"; or at least static const char *const input_label = "GPU core"; -ilia

Re: [Nouveau] [PATCH v2 1/5] nouveau_hwmon: Add config for all sensors and their settings

All kernel patches must have a Signed-off-by: $user. See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > This is a preparation for

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer <mic...@daenzer.net> wrote: >> On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >>> Hi, >>> >>>>> Quite true that this pr

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote: > On 18/04/17 07:14 PM, Gerd Hoffmann wrote: >> Hi, >> Quite true that this proves nothing. However one should note that fbcon -> fbdev works, >>> >>> BTW, this supports Gerd's patch, since the KMS fbdev

[PATCH libdrm] modetest: fix printing of fourcc on BE machines

fourcc is not a string, it's a packed integer. This happens to work out on LE, but gets reversed on BE. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- tests/modetest/modetest.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/tests/modetest/modete

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer <mic...@daenzer.net> wrote: > On 17/04/17 03:43 PM, Ilia Mirkin wrote: >> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>>> However, I totally agree with Alex that someone with a BE mac

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> However, I totally agree with Alex that someone with a BE machine >> should review the whole stack before we could be confident with anything. > > Here's what I'm confident about: xf86-video-

Re: KMS question

On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher wrote: > On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: >> 2017-04-13 16:05 keltezéssel, Alex Deucher írta: >>> >>> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote:

Re: [Nouveau] [PATCH v3 10/10] drm/nouveau: Enable stereoscopic 3D output over HDMI

On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater wrote: > Enable stereoscopic output for HDMI and DisplayPort connectors on > NV50+ (G80+) hardware. We do not enable stereoscopy on older > hardware in case there is some older board that still has HDMI >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 11, 2017 at 3:31 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Mon, 10 Apr 2017 12:10:14 -0400 > Ilia Mirkin <imir...@alum.mit.edu> wrote: > >> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > >> >

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > On Mon, 10 Apr 2017 16:17:27 +0200 > Gerd Hoffmann wrote: > >> Hi, >> >> > which software have you used as representative of "reality"? >> >> ppc64 (big endian) virtual machine, running with qemu

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann wrote: > Hi, > >> which software have you used as representative of "reality"? > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one

Re: [Nouveau] [PATCH v2 00/10] Enable HDMI Stereoscopy

On Wed, Mar 29, 2017 at 10:24 AM, Alastair Bridgewater wrote: > On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä > wrote: >> >> On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote: >> > And the tenth patch enables

Re: [PATCH] drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one

On Sun, Mar 26, 2017 at 6:14 PM, Ben Skeggs <skeg...@gmail.com> wrote: > On 03/19/2017 06:23 AM, Ilia Mirkin wrote: >> >> The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP >> and PCI varieties, rather than a core PCIE chip with a bridge for >>

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank <shashank.sha...@intel.com> wrote: > On 3/23/2017 5:17 PM, Ilia Mirkin wrote: >> >> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma >> <shashank.sha...@intel.com> wrote: >>> >>> HDMI 1.4b su

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec,

Re: [RFC libdrm 0/2] Replace the build system with meson

On Tue, Mar 21, 2017 at 11:13 AM, Grazvydas Ignotas wrote: > everyone building graphics stacks or contributing to > mesa should already be comfortable with cmake thanks to piglit and > llvm, which might not be the case for meson. Or they could be contributing to mesa because

[PATCH] drm/nouveau/mpeg: mthd returns true on success now

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: sta...@vger.kernel.org # v4.3+ --- This is just a nice-to-have, as it only affects an error print afterwards. drivers/gpu/drm/nouveau/nvkm/en

[PATCH] drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one

=70388 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: sta...@vger.kernel.org --- OK, so I'm not 100% sure about my claims, but I don't have the necessary hardware to test it out. Right now, AGP nv41+ boards are getting the nv04 mmu, while PCI nv41+ boards are getting the PCIE one. P

Re: [RFC libdrm 0/2] Replace the build system with meson

On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote: > Why bother, and why would we want this? >│~ > > First it's written in python, which means the potential developer base > is massive. And it provides a

Re: nouveau preventing shutdown after suspend-resume

On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita <jprv...@gmail.com> wrote: > Hello Ilia, > > On 17 February 2017 at 11:14, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita >> <jprv...@gmail.com> wrot

Re: nouveau preventing shutdown after suspend-resume

On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita wrote: > I'm happy to file > a bugzilla entry and provide any other needed information or help with > testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo > bugzilla? Nouveau bugs are tracked on the fdo

Re: [PATCH] drm/nouveau/core: recognise GP107 chipset

I believe what's missing at this point is a mmiotrace of the NVIDIA driver to make sure that there's nothing different about this GPU. If you can make one (see https://wiki.ubuntu.com/X/MMIOTracing for a guide - should end up ~100MB uncompressed), please send a compressed one to

[PATCH v2] drm/nouveau/devinit/gf100-: try to avoid double-running vbios scripts

0 Cc: <sta...@vger.kernel.org> # v4.6+ Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- v1 -> v2: add vga.h include (had it sitting in my local tree but forgot to amend the commit with it) drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c | 20 1 fi

[PATCH] drm/nouveau/devinit/gf100-: try to avoid double-running vbios scripts

20 Cc: sta...@vger.kernel.org # v4.6+ Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Not sure if this is safe to do esp on GM20x+ boards? drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm/nou

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 11:57 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau > <damien.lesp...@intel.com> wrote: >> On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote: >>> On Wed, Jan 18, 2017 at 11

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau <damien.lesp...@intel.com> wrote: > On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote: >> On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote: >> > Damien - did you ever test these mandatory modes on an a

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 6:45 AM, Damien Lespiau <damien.lesp...@intel.com> wrote: > On Wed, Jan 18, 2017 at 12:10:56AM -0500, Ilia Mirkin wrote: >> On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater >> <alastair.bridgewa...@gmail.com> wrote: >> > HDMI sp

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater wrote: > HDMI specification 1.4a, table 8-15 is very explicitly a "must > support at least one of" table, not a "must support all of" table. > It is not hard to find hardware that does not support some of the >

Re: [Nouveau] [PATCH] drm/nouveau: Fix HDA ELD handling (thus, HDMI audio) on gt215

reat find! Here are some more tags: Fixes: 120b0c39c756 ("drm/nv50-/disp: audit and version SOR_HDA_ELD method") Cc: sta...@vger.kernel.org # v3.17+ Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu> > --- > drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c | 2 +- > 1 fil

[PATCH] drm/nouveau: fix bug id typo in comment

The issue was recorded in fd.o bug 27501, not 25701. Signed-off-by: Ilia Mirkin --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fb

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

On Wed, Jan 4, 2017 at 10:17 PM, Randy Dunlap wrote: > On 01/04/17 19:09, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap >> wrote: >>> On 01/04/17 06:25, Ilia Mirkin wrote: >>>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote: >

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap wrote: > On 01/04/17 06:25, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote: >>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>>> From: Randy Dunlap >>>> &g

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote: > On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >> From: Randy Dunlap >> >> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >> CONFIG_DRM_NOUVEAU=y. >> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the

[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

On Mon, Jan 2, 2017 at 6:31 AM, vathsala nagaraju wrote: > Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system > to go to deep sleep while in psr2.PSR2_STATUS bit 31:28 > should report value 8 , if system enters deep sleep state. > > Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set, >

[PATCH] drm/exynos/decon5433: configure sysreg in case of hardware trigger

On Wed, Dec 28, 2016 at 5:30 AM, Andrzej Hajda wrote: > In case of HW trigger mode, sysreg register should be configured to > enable TE functionality. The patch refactors also trigger setup function. > > Signed-off-by: Andrzej Hajda > --- > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40 >

[PATCH] drm: hdlcd: Work properly in big-endian mode

On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy wrote: > By comparison, the same use-cases (fbcon and fb-test) under the same > big-endian kernel do *not* show the same problem with nouveau driving a > PCIe 7600GT card, which led me to believe it was HDLCD-specific. Just to randomly insert info

[Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot wrote: > On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote: >> On 07/12/16 06:39 PM, Alexandre Courbot wrote: >>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin >>> wrote: >>>> That's right -- nouveau c

4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

That's right -- nouveau currently requires 4k page sizes to work. This is a software limitation, not a hardware one though. On Dec 1, 2016 5:13 PM, "Jeremy Linton" wrote: Hi, I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau driver failed to claim the device with : [drm]

[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote: > The newly introduced LED handling for nouveau fails to link when the > driver is built-in but the LED subsystem is a loadable module: > > drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': >

[Nouveau] Nouveau regression since kernel 4.3: loading NVIDIA's firwmare files

On Mon, Oct 31, 2016 at 2:31 AM, Alexandre Courbot wrote: > On Mon, Oct 31, 2016 at 1:34 AM, Ilia Mirkin wrote: >> Hi Alex, >> >> As you're well-aware, your commit >> 8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouveau/gr: use >> NVIDIA-provided external

Nouveau regression since kernel 4.3: loading NVIDIA's firwmare files

Hi Alex, As you're well-aware, your commit 8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouveau/gr: use NVIDIA-provided external firmwares) broke tons of existing setups for people who were using extracted firmware files (stored in the "nouveau" firmware directory) as a result of nouveau's ctxsw

Kernel Freeze with American Megatrends BIOS

On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer wrote: > I configured bbswitch to not set any states automatically... > So it's possible to obtain and verify the GPU power state. > > However I removed the bbswitch module and booted with nouveau. > > Kernel 4.7.2: nouveau switches the discrete GPU

Kernel Freeze with American Megatrends BIOS

On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer wrote: > My conclusion: > > 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs. >I would love to help here. nouveau + bbswitch will always end in tears. You're going behind the driver's back and messing around with state it believes it

Kernel Freeze with American Megatrends BIOS

On Tue, Aug 30, 2016 at 11:44 AM, Ilia Mirkin wrote: > On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer > wrote: >> I tried these scenarios: >> >> 1. Booted the system without the bbswitch module. The nouveau module >>was loaded and is responsible for t

Kernel Freeze with American Megatrends BIOS

On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer wrote: > I tried these scenarios: > > 1. Booted the system without the bbswitch module. The nouveau module >was loaded and is responsible for the power management of the GPU. >The graphical session freezes after some minutes... > > 2. Booted

[PATCH] Re: Mullins support in xf86-video-amdgpu

On Mon, Aug 22, 2016 at 10:57 PM, Reid Hekman wrote: > On 08/22/2016 08:27 PM, Michel Dänzer wrote: >> >> On 23/08/16 10:18 AM, Reid Hekman wrote: >>> >>> >>> I was encouraged by a commit I saw today to add Sea Islands PCI ids to >>> xf86-video-amdgpu. However I did not see MULLINS included.

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

On Fri, Jul 15, 2016 at 12:40 PM, Alex Deucher wrote: > On Fri, Jul 15, 2016 at 12:31 PM, Ilia Mirkin wrote: >> On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher >> wrote: >>> On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin >>> wrote: >>>> On

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu wrote: > On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote: >> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote: >> > Hi, >> > >> > Here are two patches to fix an issue reported on kernel bugzilla (infin

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher wrote: > On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin wrote: >> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote: >>> Hi, >>> >>> Here are two patches to fix an issue reported on kernel bugzilla (infinite &g

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote: > Hi, > > Here are two patches to fix an issue reported on kernel bugzilla (infinite > loop > due to unchecked function) and a more important fix to fix hanging Optimus > machines when runtime PM is enabled (with pm/pci patches). > > These are the

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

On Sun, Jun 26, 2016 at 2:04 PM, Andy Lutomirski wrote: > Eeek! My desire to hack on EXA is pretty low. If there was some Well, the EXA hacking was all done a long time ago. You'd just need to add support for sticking 4 vertices into a buffer. (Maxwell killed direct vertex submit, which was

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski wrote: > On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote: >> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin >> wrote: >>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote: >>>> On Sat,

DRM DMA Engine

On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu wrote: > Hi Daniel, > > Sorry to bother you again. I promise this is the last time :) > > On 15-06-2016 11:15, Daniel Vetter wrote: >> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu >> wrote: >>> On 15-06-2016 09:52, Daniel Vetter wrote: On Tue,

[PATCH] amdgpu: fix asic initialization for virtualized environments

On Jun 11, 2016 12:09 AM, "Andres Rodriguez" wrote: > > When executing in a PCI passthrough based virtuzliation environemnt, the > hypervisor will usually attempt to send a PCIe bus reset signal to the > ASIC when the VM reboots. In this scenario, the card is not correctly > initialized, but we

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote: > On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote: >> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2. >> > > I just upgraded to 11.2. I'm getting errors like this in the log: > > [ 5

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2. Cheers, -ilia On Sat, May 28, 2016 at 4:51 PM, Andy Lutomirski wrote: > I have the signed firmware (I think) and I'm running a fresh 4.6 > kernel. I got an image to show up briefly, rendering the Fedora > sign-in

[PATCH 2/3] drm: Add DP port types from DP 1.3 specification

On May 3, 2016 9:49 AM, "Mika Kahola" wrote: > > DP specification 1.3 defines DP downstream ports for > DP++ and wireless devices. Let's add these to port > definitions. > > Signed-off-by: Mika Kahola > --- > include/drm/drm_dp_helper.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

[Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces

On Fri, Apr 15, 2016 at 11:22 AM, Pierre Moreau wrote: > On 11:06 AM - Apr 15 2016, Ilia Mirkin wrote: >> On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau >> wrote: >> > Currently, every backlight interface created by Nouveau uses the same name, >> > nv_backlig

[Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces

On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau wrote: > Currently, every backlight interface created by Nouveau uses the same name, > nv_backlight. This leads to a sysfs warning as it tries to create an already > existing folder. This patch adds a incremented number to the name, but keeps > the

Nouveau crashes in 4.6-rc on arm64

On Fri, Apr 8, 2016 at 12:47 AM, Alexandre Courbot wrote: > Hi Robin, > > On 04/07/2016 08:50 PM, Robin Murphy wrote: >> >> Hello, >> >> With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the >> look of it by dereferencing some offset from NULL inside >>

[PATCH] drm: Make drm.h uapi header safe for C++

On Wed, Mar 30, 2016 at 9:47 AM, Daniel Vetter wrote: > virtual is a protected keyword in C++ and can't be used at all. Ugh. > > This aligns the kernel versions of the drm headers with the ones in > libdrm. > > Cc: Emil Velikov > Signed-off-by: Daniel Vetter > --- > include/uapi/drm/drm.h | 4

[PATCH] nouveau: need to handle failed allocation

On Thu, Jan 28, 2016 at 7:09 PM, Insu Yun wrote: > drm_property_create_range can be failed in memory pressure. > So, it needs to be handled. > > Signed-off-by: Insu Yun > --- > drivers/gpu/drm/nouveau/nouveau_display.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git

Trying nouveau reclocking

The warn in question is static u32 nvkm_mc_intr_mask(struct nvkm_mc *mc) { u32 intr = mc->func->intr_mask(mc); if (WARN_ON_ONCE(intr == 0x)) intr = 0; /* likely fallen off the bus */ return intr; } Which is basically a sign of total death. Is this

[PATCH 3/3] vc4: Add headers and .pc files for VC4 userspace development.

On Mon, Jan 25, 2016 at 2:27 PM, Eric Anholt wrote: > The headers were originally written in Mesa, imported to the kernel, > and improved upon in vc4-gpu-tools. These come from the v-g-t copies > and will replace the Mesa and v-g-t copies, and hopefully be used from > new tests in igt, as well.

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

On Fri, Jan 22, 2016 at 12:47 PM, Ville Syrjälä wrote: > On Fri, Jan 22, 2016 at 05:40:54PM +, Emil Velikov wrote: >> On 22 January 2016 at 17:29, Ilia Mirkin wrote: >> > On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák >> > wrote: >> >> On Fri

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák wrote: > On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov > wrote: >> On 21 January 2016 at 16:58, Marek Olšák wrote: >>> On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov >>> wrote: On 21 January 2016 at 12:08, Marek Olšák wrote: > On

[PATCH 1/2] etnaviv: add gpu param for number of varyings

On Tue, Jan 19, 2016 at 3:11 AM, Christian Gmeiner wrote: > 2016-01-19 8:16 GMT+01:00 Ilia Mirkin : >> On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner >> wrote: >>> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3. >>> Userspace still need

[PATCH 1/2] etnaviv: add gpu param for number of varyings

On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner wrote: > The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3. > Userspace still needs to validate the returned values as it can be 0 > like on the imx6q. > > Signed-off-by: Christian Gmeiner > --- >

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

Reviewed-by: Ilia Mirkin On Tue, Jan 12, 2016 at 4:14 PM, Marek Olšák wrote: > From: Marek Olšák > > It warns for all "{}" initializers. Well, I want us to use {}. > --- > configure.ac | 3 ++- > intel/intel_decode.c | 2 -- > 2 files change

[PATCH 1/2] drm: bridge: sil902x

On Wed, Jan 6, 2016 at 10:26 AM, Sascha Hauer wrote: > On Wed, Jan 06, 2016 at 02:53:30PM +0100, Boris Brezillon wrote: >> Hi Sascha, >> >> On Wed, 6 Jan 2016 14:47:36 +0100 >> Sascha Hauer wrote: >> >> > Hi Boris, >> > >> > On Wed, Jan 06, 2016 at 12:25:50PM +0100, Boris Brezillon wrote: >> > >

AMD guys: commit messages?

On Tue, Dec 8, 2015 at 8:43 AM, Ernst Sjöstrand wrote: > Hello list! > > I lurk here and try to follow Mesa/DRI and most specifically Radeon > driver development, report bugs, test new stuff and help get the bugs > closed and so on... > > However I see that the commit messages for AMD/Radeon are

[PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

On Tue, Dec 8, 2015 at 3:49 AM, Daniel Vetter wrote: > We want this for consistency with existing page_flip semantics. > > Since this spurred quite a discussion on IRC also document why we > reject even generation when the pipe is off: It's not that it's hard event generation? > to implement,

[PATCH 02/12] drm/etnaviv: add devicetree bindings

On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux wrote: > On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote: >> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux >> wrote: >> > Moreover, DRI3 is not yet available for Gallium, so if we're

[PATCH 02/12] drm/etnaviv: add devicetree bindings

On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux wrote: > Moreover, DRI3 is not yet available for Gallium, so if we're talking > about Xorg, then functional DRI2 is a requirement, and that _needs_ > to have a single device for the rendering instances. Xorg has no way > to pass multiple

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux wrote: > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote: >> Signed-off-by: Lucas Stach > > Acked-by: Russell King > > Although, I would like to be copied on patches, I don't think we > have a

[PATCH 13/28] drm/nouveau: Use private save/restore hooks

On Fri, Dec 4, 2015 at 3:45 AM, Daniel Vetter wrote: > I want to remove the core ones since with atomic drivers system > suspend/resume is solved much differently. And there's only 2 drivers > (gma500 besides nouveau) really using them. > > Cc: Ben Skeggs > Signed-off-by: Daniel Vetter > --- >

Implementing Miracast?

On Thu, Dec 3, 2015 at 11:10 AM, Laurent Pinchart wrote: > Hi Ilia, > > On Thursday 03 December 2015 11:03:28 Ilia Mirkin wrote: >> On Thu, Dec 3, 2015 at 10:53 AM, Laurent Pinchart wrote: >> > On Thursday 03 December 2015 10:42:50 Ilia Mirkin wrote: >> >> On T

Implementing Miracast?

On Thu, Dec 3, 2015 at 10:53 AM, Laurent Pinchart wrote: > On Thursday 03 December 2015 10:42:50 Ilia Mirkin wrote: >> On Thu, Dec 3, 2015 at 10:34 AM, Laurent Pinchart >> >> wrote: >> > Hi Jaakko, >> > >> > On Thursday 03 December 2015

Implementing Miracast?

On Thu, Dec 3, 2015 at 10:34 AM, Laurent Pinchart wrote: > Hi Jaakko, > > On Thursday 03 December 2015 14:42:51 Hannikainen, Jaakko wrote: >> Hello, >> >> We're developing Miracast (HDMI over Wireless connections). The current >> progress is that it 'works' in the userspace but doesn't have any

<    1   2   3   4   5   6   >