Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

On Mon, Apr 12, 2021 at 4:01 PM Aaron Plattner wrote: > > On 4/12/21 12:36 PM, Roy Spliet wrote: > > Hello Aaron, > > > > Thanks for your insights. A follow-up query and some observations > > in-line. > > > > Op 12-04-2021 om 20:06 schreef Aaron Plattner: > >> On 4/10/21 1:48 PM, Roy Spliet

Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size

On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote: > > Found this while trying to make some changes to the kms_cursor_crc test. > curs507a_acquire checks that the width and height of the cursor framebuffer > are equal (asyw->image.{w,h}). This is actually wrong though, as we only > want to be

Re: [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen wrote: > > Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100: > > Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100: > > > I'd recommend using xf86-video-nouveau in any case, but some distros > > > > I would like try this out.

Re: [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen wrote: > > Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100: > > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen > > wrote: > > > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100: > > > > diff --git a/drivers/gpu/drm/nou

Re: [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen wrote: > > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100: > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c > > b/drivers/gpu/drm/nouveau/dispnv50/disp.c > > index c6367035970e..5f4f09a601d4 100644 > > ---

Re: [Nouveau] [RFC v3 05/10] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit

On Fri, Feb 5, 2021 at 6:45 PM Lyude Paul wrote: > > Get rid of the extraneous switch case in here, and just open code > edp_backlight_mode as we only ever use it once. > > Signed-off-by: Lyude Paul > --- > .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++- > 1 file

Re: 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)

On Tue, Dec 29, 2020 at 10:52 AM Marc MERLIN wrote: > > On Sat, Dec 26, 2020 at 03:12:09AM -0800, Ilia Mirkin wrote: > > > after boot, when it gets the right trigger (not sure which ones), it > > > loops on this evern 2 seconds, mostly forever. > > > &

Re: [PATCH 5.10 064/717] drm/edid: Fix uninitialized variable in drm_cvt_modes()

h > Changes since v2: > * Remove now unused variable > > Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage") > Signed-off-by: Lyude Paul > Reviewed-by: Ilia Mirkin > Link: > https://patchwork.freedesktop.org/patch/msgid/20201105235703.1328115-1-l

Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)

On Sun, Dec 27, 2020 at 12:03 PM Marc MERLIN wrote: > > This started with 5.5 and hasn't gotten better since then, despite some > reports > I tried to send. > > As per my previous message: > I have a Thinkpad P70 with hybrid graphics. > 01:00.0 VGA compatible controller: NVIDIA Corporation

Re: [PATCH v8 4/4] NOTFORMERGE: drm/logicvc: Add plane colorkey support

FWIW this is something I added, hoping it was going to get used at some point, but I never followed up with support in xf86-video-nouveau for Xv. At this point, I'm not sure I ever will. I encoded the "enabled" part into the value with a high bit (1<<24) -- not sure that was such a great idea. All

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng wrote: > > [+Cc nouveau] > > On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai wrote: > [snip] > > > Quite possibly the system doesn't power up HDA controller when there's > > > no external monitor. > > > So when it's connected to external monitor, it's

Re: [Nouveau] Nouveau video --- [ cut here ] ----- crash dump 5.10.0-rc6

Unfortunately this isn't a crash, but rather a warning that things are timing out. By the time you get this, the display is most likely hung. Was there anything before this, e.g. an error state dump perhaps? What GPU are you using, what displays, and how are they connected? What kind of

Re: [PATCH v3] drm/edid: Fix uninitialized variable in drm_cvt_modes()

usage") > Signed-off-by: Lyude Paul For the very little it's worth, Reviewed-by: Ilia Mirkin > --- > drivers/gpu/drm/drm_edid.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 631125b46e04..b8

Re: [PATCH v2] drm/edid: Fix uninitialized variable in drm_cvt_modes()

On Tue, Nov 3, 2020 at 5:15 PM Lyude Paul wrote: > > Noticed this when trying to compile with -Wall on a kernel fork. We > potentially > don't set width here, which causes the compiler to complain about width > potentially being uninitialized in drm_cvt_modes(). So, let's fix that. > > Changes

Re: [PATCH] drm/edid: Fix uninitialized variable in drm_cvt_modes()

On Tue, Nov 3, 2020 at 2:47 PM Lyude Paul wrote: > > Sorry! Thought I had responded to this but apparently not, comments down below > > On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote: > > On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote: > > > > > >

Re: [PATCH] drm/edid: Fix uninitialized variable in drm_cvt_modes()

On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote: > > Noticed this when trying to compile with -Wall on a kernel fork. We > potentially > don't set width here, which causes the compiler to complain about width > potentially being uninitialized in drm_cvt_modes(). So, let's fix that. > >

Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian

On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote: > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote: > > > > Hello, > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > > [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6) > > 8.3.0, GNU ld (GNU

Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()

On Fri, Sep 25, 2020 at 6:08 PM Lyude Paul wrote: > > On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote: > > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote: > > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > > > Can we use 6bpc on arbitrary DP m

Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()

On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote: > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > I don't thi

Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()

Can we use 6bpc on arbitrary DP monitors, or is there a capability for it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul wrote: > > While I thought I had this correct (since it actually did reject modes > like I expected during

Re: [Nouveau] 2dd4d163cd9c ("drm/nouveau: remove open-coded version of remove_conflicting_pci_framebuffers()")

Hi Boris, There was a fixup to that patch that you'll also have to revert first -- 7dbbdd37f2ae7dd4175ba3f86f4335c463b18403. I guess there's some subtle difference between the old open-coded logic and the helper, they were supposed to be identical. Cheers, -ilia On Thu, Jun 18, 2020 at 4:09

Re: [Nouveau] NVIDIA GP107 (137000a1) - acr: failed to load firmware

On Thu, Jun 4, 2020 at 12:04 PM Zeno Davatz wrote: > > Thank you, Ilia > > On Thu, Jun 4, 2020 at 5:25 PM Ilia Mirkin wrote: > > > There's a lot more firmware files than that ... everything in the > > gp107 directory. Also this would only be necessary if nouveau i

Re: [Nouveau] NVIDIA GP107 (137000a1) - acr: failed to load firmware

On Thu, Jun 4, 2020 at 11:16 AM Zeno Davatz wrote: > > On Thu, Jun 4, 2020 at 4:36 PM Ilia Mirkin wrote: > > > > Starting with kernel 5.6, loading nouveau without firmware (for GPUs > > where it is required, such as yours) got broken. > > > > You are loading n

Re: [Nouveau] NVIDIA GP107 (137000a1) - acr: failed to load firmware

Starting with kernel 5.6, loading nouveau without firmware (for GPUs where it is required, such as yours) got broken. You are loading nouveau without firmware, so it fails. The firmware needs to be available to the kernel at the time of nouveau loading. Cheers, -ilia On Thu, Jun 4, 2020 at

Re: [Nouveau] [PATCH] nouveau: add fbdev dependency

Isn't this already fixed by https://cgit.freedesktop.org/drm/drm/commit/?id=7dbbdd37f2ae7dd4175ba3f86f4335c463b18403 On Wed, May 27, 2020 at 9:43 AM Arnd Bergmann wrote: > > Calling directly into the fbdev stack only works when the > fbdev layer is built into the kernel as well, or both are >

Re: [PATCH v3 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes

On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote: > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c > b/drivers/gpu/drm/nouveau/nouveau_connector.c > index 43bcbb6d73c4..6dae00da5d7e 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_connector.c > +++

Re: [PATCH v2 1/4] drm/komeda: Add a new helper drm_color_ctm_s31_32_to_qm_n()

On Mon, Oct 14, 2019 at 9:16 PM james qian wang (Arm Technology China) wrote: > On Mon, Oct 14, 2019 at 11:58:48AM -0400, Ilia Mirkin wrote: > > On Fri, Oct 11, 2019 at 1:43 AM james qian wang (Arm Technology China) > > wrote: > > > + * > > > + * Convert and clam

Re: [PATCH 13/36] drm/nouveau: use bpp instead of cpp for drm_format_info

On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang wrote: > > cpp[BytePerPlane] can't describe the 10bit data format correctly, > So we use bpp[BitPerPlane] to instead cpp. > > Signed-off-by: Sandy Huang > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 --- >

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >> >

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

Hi Greg, This feels like it's missing a From: line. commit b513a18cf1d705bd04efd91c417e79e4938be093 Author: Lyude Paul Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures Is this an artifact of your notification-of-patches process and I never noticed

Re: [Nouveau] [PATCH 20/22] mm: move hmm_vma_fault to nouveau

On Wed, Jul 3, 2019 at 1:49 PM Ralph Campbell wrote: > On 6/30/19 11:20 PM, Christoph Hellwig wrote: > > hmm_vma_fault is marked as a legacy API to get rid of, but quite suites > > the current nouvea flow. Move it to the only user in preparation for > > I didn't quite parse the phrase "quite

Re: nouveau: DRM: GPU lockup - switching to software fbcon

On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky wrote: > > On (06/19/19 01:20), Ilia Mirkin wrote: > > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky > > wrote: > > > > > > On (06/14/19 11:50), Sergey Senozhatsky wrote: > > > > dmesg > &

Re: drm/nouveau/bios/ramcfg, setting of RON pull value

On Sat, Feb 16, 2019 at 10:02 AM Colin Ian King wrote: > > Hi, > > Static Analysis with CoverityScan as detected an issue with the setting > of the RON pull value in function nvkm_gddr3_calc in > drm/nouveau/bios/ramcfg.c > > This was introduced by commit: c25bf7b6155cb ("drm/nouveau/bios/ramcfg:

Re: Nouveau module X server not starting on a NP900X5N Kaby Lake machine

On Tue, Jan 1, 2019 at 5:30 PM Jan Vlietland wrote: > > Hi Ilia, many thanks for answering my mail. > > Tonight I tried to see what happens if I generate a xorg.conf file and place > it in /etc/X11/xorg.conf, as described here: >

Re: Nouveau module results in total lockups without any dmesg trace on a NP900X5N Kaby Lake machine

On Tue, Jan 1, 2019 at 4:06 PM Jan Vlietland wrote: > > Hi Ben, David and Daniel , > > First of all happy new year. Based on advice of Greg K-H herewith a mail > about a number of Nouveau issues with my laptop. > > I installed various Kali linux versions up to Linux 4.20.0-rc7 > (downloaded,

Re: [Nouveau] [PATCH][next] drm/nouveau/disp: avoid potential overflow on shift of int value

On Sun, May 27, 2018 at 5:54 PM, Colin King wrote: > From: Colin Ian King > > The constant values being shifted are 32 bit integers and may potentially > overflow on the shift. Avoid this potential overflow by making them > unsigned long long

Re: [Nouveau] [PATCH][next] drm/nouveau/disp: avoid potential overflow on shift of int value

On Sun, May 27, 2018 at 5:54 PM, Colin King wrote: > From: Colin Ian King > > The constant values being shifted are 32 bit integers and may potentially > overflow on the shift. Avoid this potential overflow by making them > unsigned long long values before the shift. > > Detected by

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer <mic...@daenzer.net> wrote: > On 2018-04-28 06:30 PM, Ilia Mirkin wrote: >> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer <mic...@daenzer.net> wrote: >>> From: Michel Dänzer <michel.daen...@amd.com>

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer wrote: > On 2018-04-28 06:30 PM, Ilia Mirkin wrote: >> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote: >>> From: Michel Dänzer >>> >>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE ena

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled) > try to allocate huge pages. However, not all drivers can take advantage > of huge pages, but they

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled) > try to allocate huge pages. However, not all drivers can take advantage > of huge pages, but they would incur the overhead for allocating and

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos <mr...@linux.ee> wrote: >>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: >> >> NV5 in another PC (secondary ca

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin wrote: > On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote: >>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: >> >> NV5 in another PC (secondary card in x86-64) made the systrem crash on >> bo

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote: >> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: > > NV5 in another PC (secondary card in x86-64) made the systrem crash on > boot, in nvkm_therm_clkgate_fini. Mind booting with nouveau.debug=trace?

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote: >> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: > > NV5 in another PC (secondary card in x86-64) made the systrem crash on > boot, in nvkm_therm_clkgate_fini. Mind booting with nouveau.debug=trace? That should

Re: [RFC v2 3/4] drm/nouveau: Add support for BLCG on Kepler2

On Thu, Jan 25, 2018 at 10:35 PM, Lyude Paul wrote: > Same as the previous patch, but for Kepler2 now > > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + > drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--

Re: [RFC v2 3/4] drm/nouveau: Add support for BLCG on Kepler2

On Thu, Jan 25, 2018 at 10:35 PM, Lyude Paul wrote: > Same as the previous patch, but for Kepler2 now > > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + > drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +-- >

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith <efa...@gmx.de> wrote: > On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote: >> On Tue, Dec 19, 2017 at 8:45 AM, Christian König >> <ckoenig.leichtzumer...@gmail.com> wrote: >> > Am 19.12.2017 um 11:39 schrieb M

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith wrote: > On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote: >> On Tue, Dec 19, 2017 at 8:45 AM, Christian König >> wrote: >> > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: >> >> >> >

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Tue, Dec 19, 2017 at 8:45 AM, Christian König wrote: > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: >> >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: >>> >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: On 12/18/17 7:06 PM, Mike Galbraith wrote:

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Tue, Dec 19, 2017 at 8:45 AM, Christian König wrote: > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: >> >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: >>> >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: On 12/18/17 7:06 PM, Mike Galbraith wrote: > > Greetings, >

Re: [tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

On Tue, Dec 12, 2017 at 9:43 AM, Peter Zijlstra <pet...@infradead.org> wrote: > On Tue, Dec 12, 2017 at 09:21:10AM -0500, Ilia Mirkin wrote: >> The "thing" being mmiotrace, or the "thing" being page-unaligned addresses? > > mmiotrace > >> I

Re: [tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

On Tue, Dec 12, 2017 at 9:43 AM, Peter Zijlstra wrote: > On Tue, Dec 12, 2017 at 09:21:10AM -0500, Ilia Mirkin wrote: >> The "thing" being mmiotrace, or the "thing" being page-unaligned addresses? > > mmiotrace > >> If the former, its primary use-case

Re: [tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

On Tue, Dec 12, 2017 at 9:04 AM, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > >> On Tue, Dec 12, 2017 at 02:55:30AM -0800, tip-bot for Karol Herbst wrote: >> > Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687 >> > Gitweb: >> >

Re: [tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

On Tue, Dec 12, 2017 at 9:04 AM, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > >> On Tue, Dec 12, 2017 at 02:55:30AM -0800, tip-bot for Karol Herbst wrote: >> > Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687 >> > Gitweb: >> >

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> >> wrote: >>> On Friday 1

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote: >> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary >> wrote: >>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>>> On Fri, Nov 17, 2017 at 12

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> > wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, O

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary > wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >>> >>> wrote: >>> > @@

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> > wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, O

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary > wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >>> >>> wrote: >>> > @@

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> wrote: > On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >> >> <li...@rainbow-software.org> wrote: >> > @@ -483,8 +483,8 @@

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary wrote: > On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >> >> wrote: >> > @@ -483,8 +483,8 @@ >> > nouveau :02:00.0: disp:0860: ->

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary wrote: > @@ -483,8 +483,8 @@ > nouveau :02:00.0: disp:0860: -> 0500 > nouveau :02:00.0: disp:0864: > nouveau :02:00.0: disp:0868: -> 04000500 > -nouveau

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary wrote: > @@ -483,8 +483,8 @@ > nouveau :02:00.0: disp:0860: -> 0500 > nouveau :02:00.0: disp:0864: > nouveau :02:00.0: disp:0868: -> 04000500 > -nouveau :02:00.0: disp:086c: ->

Re: Blank console but X11 works on MCP79 - old regression since 3.8

With a new kernel, mind grabbing a dmesg with drm.debug=0x1e nouveau.debug=debug (or maybe even =trace)? Maybe also see if fbcon/fbdev have any debug things that can be turned on? Sounds like things are generally working, just the fbcon -> nouveaufb path seems somehow buggered. Another thing to

Re: Blank console but X11 works on MCP79 - old regression since 3.8

With a new kernel, mind grabbing a dmesg with drm.debug=0x1e nouveau.debug=debug (or maybe even =trace)? Maybe also see if fbcon/fbdev have any debug things that can be turned on? Sounds like things are generally working, just the fbcon -> nouveaufb path seems somehow buggered. Another thing to

Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure

On Wed, Aug 30, 2017 at 8:22 PM, Tim Harvey wrote: > On Wed, Aug 30, 2017 at 3:06 PM, Andrew Lunn wrote: >> On Wed, Aug 30, 2017 at 12:53:56PM -0700, Tim Harvey wrote: >>> Greetings, >>> >>> I'm seeing RX frame errors when using the mv88e6xxx DSA driver on

Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure

On Wed, Aug 30, 2017 at 8:22 PM, Tim Harvey wrote: > On Wed, Aug 30, 2017 at 3:06 PM, Andrew Lunn wrote: >> On Wed, Aug 30, 2017 at 12:53:56PM -0700, Tim Harvey wrote: >>> Greetings, >>> >>> I'm seeing RX frame errors when using the mv88e6xxx DSA driver on >>> 4.13-rc7. The board I'm using is a

Re: [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote: > From: Colin Ian King > > The null check on the array msto is incorrect since msto is never > null. The null check should be instead on msto[i] since this is > being dereferenced in the call

Re: [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote: > From: Colin Ian King > > The null check on the array msto is incorrect since msto is never > null. The null check should be instead on msto[i] since this is > being dereferenced in the call to drm_mode_connector_attach_encoder. > > Thanks to

Re: nouveau driver locks up with 4.11 kernel

On Mon, Aug 14, 2017 at 4:29 PM, Michal Hocko <mho...@kernel.org> wrote: > On Mon 14-08-17 15:27:20, Ilia Mirkin wrote: >> On Mon, Aug 14, 2017 at 3:18 PM, Michal Hocko <mho...@kernel.org> wrote: > [...] >> > nouveau :03:00.0: fifo: channel 6 [mpv/vo[3535]]

Re: nouveau driver locks up with 4.11 kernel

On Mon, Aug 14, 2017 at 4:29 PM, Michal Hocko wrote: > On Mon 14-08-17 15:27:20, Ilia Mirkin wrote: >> On Mon, Aug 14, 2017 at 3:18 PM, Michal Hocko wrote: > [...] >> > nouveau :03:00.0: fifo: channel 6 [mpv/vo[3535]] kick timeout >> > nouveau: mpv/vo[3535

Re: nouveau driver locks up with 4.11 kernel

On Mon, Aug 14, 2017 at 3:18 PM, Michal Hocko wrote: > Hi, > I am having issues with nouveau driver in 4.11 Debian distribution > kernel. I can start X session but the screen locks up e.g. when I try to > exit mplayer fullscreen mode. The lock is swamped with tons of > nouveau

Re: nouveau driver locks up with 4.11 kernel

On Mon, Aug 14, 2017 at 3:18 PM, Michal Hocko wrote: > Hi, > I am having issues with nouveau driver in 4.11 Debian distribution > kernel. I can start X session but the screen locks up e.g. when I try to > exit mplayer fullscreen mode. The lock is swamped with tons of > nouveau :03:00.0: fifo:

Re: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge.

On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote: > Laurent Pinchart writes: > >> Hi Eric, >> >> (CC'ing Daniel) >> >> Thank you for the patch. >> >> On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote: >>> This will let drivers reduce the error

Re: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge.

On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote: > Laurent Pinchart writes: > >> Hi Eric, >> >> (CC'ing Daniel) >> >> Thank you for the patch. >> >> On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote: >>> This will let drivers reduce the error cleanup they need, in >>> particular the

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

I believe the solution is to not call drm_crtc_vblank_off for atomic modesetting in nouveau_display_fini. I think Ben's working on it. On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann wrote: > mimic the behavior of vblank_disable_fn(), another caller of >

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

I believe the solution is to not call drm_crtc_vblank_off for atomic modesetting in nouveau_display_fini. I think Ben's working on it. On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann wrote: > mimic the behavior of vblank_disable_fn(), another caller of > drm_vblank_disable_and_save(). > > This

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

On Sun, Jul 16, 2017 at 12:43 AM, Mike Galbraith <efa...@gmx.de> wrote: > On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote: >> >> OK, so this issue appears to be that we're calling >> drm_crtc_vblank_off() on a crtc for which vblank is already disabled. >> My g

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

On Sun, Jul 16, 2017 at 12:43 AM, Mike Galbraith wrote: > On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote: >> >> OK, so this issue appears to be that we're calling >> drm_crtc_vblank_off() on a crtc for which vblank is already disabled. >> My guess is that th

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: [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 Corporation G84

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

On Sat, Jul 15, 2017 at 12:14 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith <efa...@gmx.de> wrote: >> Greetings, >> >> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside >> kernel:

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

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) >>

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: [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 Corporation G84

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: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 meant as a serious patch. WARN_ON_ONCE should work. The fix isn't to remove

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: [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 :) That's

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 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+ boards. If it's not >> &

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

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith 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]: NVIDIA Corporation GM204

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: [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: Weird green patterns on video

On Sun, Jun 4, 2017 at 1:05 PM, Alexandre-Xavier L-L wrote: > Hello, > > Someone sent me a picture of a device that he tried to add support for > in V4L2. The device causes a kind of diagonal pattern made of green > lines on his image. I wonder what could be causing this. Has

Re: Weird green patterns on video

On Sun, Jun 4, 2017 at 1:05 PM, Alexandre-Xavier L-L wrote: > Hello, > > Someone sent me a picture of a device that he tried to add support for > in V4L2. The device causes a kind of diagonal pattern made of green > lines on his image. I wonder what could be causing this. Has anyone > seen this

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

  1   2   3   4   >