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 driver or hardware

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:48 AM, Ilia Mirkin wrote: > On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin wrote: >> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä >> wrote: >>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote: >>>> On Fri, Apr 21, 2017 at

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 9:40 AM, Ilia Mirkin wrote: > On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä > 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ä >>> wrote: >>> > On F

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 Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä 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ä >> wrote: >> > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin 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.

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä 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 wrote: >> > While working on graphics support for virtual machines on ppc64 (which >> > exists in

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] drm: fourcc byteorder: brings header file comments in line with reality.

sure are at least somewhat wrong. Furthermore the hardware is relatively rare and developers with time to work on improving it are even rarer. I'd like to reiterate that the status quo does end up in a functioning system. Let's try not to break that. Cheers, -ilia > > Cc: Ville Syrjälä > Cc: D

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 11:19 PM, Ilia Mirkin wrote: > 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

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

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 emulation code uses >>>

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 Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote: > On 17/04/17 03:43 PM, Ilia Mirkin wrote: >> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote: >>>> However, I totally agree with Alex that someone with a BE machine >>>> should review the whole s

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: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin 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-nouveau worked just fine >

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: 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: Hi, how can I disable the behaviour in

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 Tue, Apr 11, 2017 at 3:31 AM, Pekka Paalanen wrote: > On Mon, 10 Apr 2017 12:10:14 -0400 > Ilia Mirkin wrote: > >> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote: > >> > I also wonder if a real BE machine could have different results than >> > the

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 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 stdvga & bochs-drm >> driver. Xorg with

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: [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 and > only format

[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/mpeg: mthd returns true on success now

Signed-off-by: Ilia Mirkin 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/engine/mpeg/nv31.c | 2 +- d

[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

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

=70388 Signed-off-by: Ilia Mirkin 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. Perhaps this works for them

Re: Linux 4.10.2

On Mon, Mar 13, 2017 at 11:38 AM, Robert Nelson wrote: > On Mon, Mar 13, 2017 at 10:35 AM, Konstantin Ryabitsev > wrote: >> On Mon, Mar 13, 2017 at 10:32:59AM -0500, Robert Nelson wrote: >>> >>> rcnee@debian:~$ git clone >>>

Re: Linux 4.10.2

On Mon, Mar 13, 2017 at 11:38 AM, Robert Nelson wrote: > On Mon, Mar 13, 2017 at 10:35 AM, Konstantin Ryabitsev > wrote: >> On Mon, Mar 13, 2017 at 10:32:59AM -0500, Robert Nelson wrote: >>> >>> rcnee@debian:~$ git clone >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>

Re: Linux 4.10.2

On Mon, Mar 13, 2017 at 8:36 AM, Jiri Slaby <jsl...@suse.cz> wrote: > On 03/12/2017, 09:11 PM, Ilia Mirkin wrote: >> The link shows v4.10.1 for me and says that the v4.10.2 tag is >> unknown. Fetching from >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux

Re: Linux 4.10.2

On Mon, Mar 13, 2017 at 8:36 AM, Jiri Slaby wrote: > On 03/12/2017, 09:11 PM, Ilia Mirkin wrote: >> The link shows v4.10.1 for me and says that the v4.10.2 tag is >> unknown. Fetching from >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git, >>

Re: Linux 4.10.2

On Sun, Mar 12, 2017 at 3:05 PM, Greg KH wrote: > On Sun, Mar 12, 2017 at 01:51:24PM -0500, Robert Nelson wrote: >> On Sun, Mar 12, 2017 at 8:05 AM, Greg KH wrote: >> > I'm announcing the release of the 4.10.2 kernel. >> > >> > All users of

Re: Linux 4.10.2

On Sun, Mar 12, 2017 at 3:05 PM, Greg KH wrote: > On Sun, Mar 12, 2017 at 01:51:24PM -0500, Robert Nelson wrote: >> On Sun, Mar 12, 2017 at 8:05 AM, Greg KH wrote: >> > I'm announcing the release of the 4.10.2 kernel. >> > >> > All users of the 4.10 kernel series must upgrade. >> > >> > The

Re: DRM i915

On Sun, Jan 8, 2017 at 5:01 PM, Nathaniel Russell wrote: > Any help figuring this out would be greatly appreciated. > Linux version 4.8.15 (root@reddog) (gcc version 5.4.0 (GCC) ) #1 Sun Dec 18 > 22:48:37 CST 2016 > > > > > pci :00:00.0: Intel G33 Chipset > [

Re: DRM i915

On Sun, Jan 8, 2017 at 5:01 PM, Nathaniel Russell wrote: > Any help figuring this out would be greatly appreciated. > Linux version 4.8.15 (root@reddog) (gcc version 5.4.0 (GCC) ) #1 Sun Dec 18 > 22:48:37 CST 2016 > > > > > pci :00:00.0: Intel G33 Chipset > [7.173121] pci :00:00.0:

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

On Wed, Jan 4, 2017 at 10:17 PM, Randy Dunlap <rdun...@infradead.org> wrote: > On 01/04/17 19:09, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap <rdun...@infradead.org> wrote: >>> On 01/04/17 06:25, Ilia Mirkin wrote: >>>> On Wed,

Re: [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: >>>>

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

On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap <rdun...@infradead.org> wrote: > On 01/04/17 06:25, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter <dan...@ffwll.ch> wrote: >>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:

Re: [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

Re: [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

Re: [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

Re: [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': >

Re: [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': >

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

On Mon, Oct 31, 2016 at 2:31 AM, Alexandre Courbot <gnu...@gmail.com> wrote: > On Mon, Oct 31, 2016 at 1:34 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> Hi Alex, >> >> As you're well-aware, your commit >> 8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouv

Re: [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

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

Re: 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:

Re: 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

Re: 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

Re: 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

Re: Kernel Freeze with American Megatrends BIOS

On Tue, Aug 30, 2016 at 11:44 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer > <roland.sin...@desertbit.com> wrote: >> I tried these scenarios: >> >> 1. Booted the system without the bbswitch module.

Re: 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

Re: 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

Re: 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

Re: 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

Re: 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, Jun

Re: UBSAN: Undefined behaviour in drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31

On Thu, May 12, 2016 at 4:08 PM, James Bottomley wrote: > On Thu, 2016-05-12 at 19:02 +0300, Meelis Roos wrote: >> This is from a dual-AthlonMP 32-bit x86 system with onboard Adaptec >> SCSI >> controller, once during bootup. >> >> [4.896307] >>

Re: UBSAN: Undefined behaviour in drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31

On Thu, May 12, 2016 at 4:08 PM, James Bottomley wrote: > On Thu, 2016-05-12 at 19:02 +0300, Meelis Roos wrote: >> This is from a dual-AthlonMP 32-bit x86 system with onboard Adaptec >> SCSI >> controller, once during bootup. >> >> [4.896307] >>

Re: 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 >>

Re: 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 >>

Re: [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

Re: [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

Re: [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: >> > >

Re: [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

Re: [PATCH 3/5] Staging: panel: Remove ULL

On Tue, Dec 29, 2015 at 3:08 PM, Ksenija Stanojevic wrote: > Remove ULL since it's useless. > > Signed-off-by: Ksenija Stanojevic > --- > drivers/staging/panel/panel.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/panel/panel.c

Re: [PATCH 3/5] Staging: panel: Remove ULL

On Tue, Dec 29, 2015 at 3:08 PM, Ksenija Stanojevic wrote: > Remove ULL since it's useless. > > Signed-off-by: Ksenija Stanojevic > --- > drivers/staging/panel/panel.c | 12 ++-- > 1 file changed, 6 insertions(+), 6

Kernel v4.3 - RCU hang, USB + SCSI implicated

Hello, This is a follow-up to an earlier report where I was directed by Oliver Neukum to repost to linux-scsi. I got lazy and forgot, but the same issue happened a second time. Original posting at: https://lkml.org/lkml/2015/11/16/569 This is an Intel Haswell system, DELL U2415 monitor (which

Kernel v4.3 - RCU hang, USB + SCSI implicated

Hello, This is a follow-up to an earlier report where I was directed by Oliver Neukum to repost to linux-scsi. I got lazy and forgot, but the same issue happened a second time. Original posting at: https://lkml.org/lkml/2015/11/16/569 This is an Intel Haswell system, DELL U2415 monitor (which

Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov wrote: > On 27 November 2015 at 15:10, Daniel Vetter wrote: >> It only leads to bloodshed and tears - we don't bother to restore a >> working legacy vga hw setup. >> >> On haswell with the new dynamic power well code this leads to even >> more

Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov wrote: > On 27 November 2015 at 15:10, Daniel Vetter wrote: >> It only leads to bloodshed and tears - we don't bother to restore a >> working legacy vga hw setup. >> >> On haswell with the new

Re: 4.3 nouveau regression: nv04_fbcon_imageblit(?) deadlock

On Thu, Nov 26, 2015 at 12:10 PM, Meelis Roos wrote: > Hello, this is a report about a PC with 3 nvidia cards - PCI-E NV44, AGP > NV34 and PCI NV05. Only NV44 has monitor attached currently. > > 4.2.0 (both packaged and self-compiled) worked fine, 4.3.0 and 4.4-rc2 > exhibit a problem: after the

Re: 4.3 nouveau regression: nv04_fbcon_imageblit(?) deadlock

On Thu, Nov 26, 2015 at 12:10 PM, Meelis Roos wrote: > Hello, this is a report about a PC with 3 nvidia cards - PCI-E NV44, AGP > NV34 and PCI NV05. Only NV44 has monitor attached currently. > > 4.2.0 (both packaged and self-compiled) worked fine, 4.3.0 and 4.4-rc2 > exhibit a

Re: nouveau: iowrite32 oops & warning at drivers/gpu/drm/nouveau/nouveau_fence.c:198

Hi Tommi, Not sure if these apply here but there are a couple of outstanding locking fixes available in http://cgit.freedesktop.org/~darktama/nouveau/ -- specifically these two: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=2f3a56ad019e378a352e9cb7a559f478826f1a87

Re: nouveau: iowrite32 oops & warning at drivers/gpu/drm/nouveau/nouveau_fence.c:198

Hi Tommi, Not sure if these apply here but there are a couple of outstanding locking fixes available in http://cgit.freedesktop.org/~darktama/nouveau/ -- specifically these two: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=2f3a56ad019e378a352e9cb7a559f478826f1a87

Kernel v4.3 - RCU hang, USB implicated

Hello all, I'm not sure if USB hung because RCU died, or actually caused the RCU death itself. Hopefully the below is useful in determining the issue. I have a pretty standard system with a Haswell i7-4790 CPU, and these USB controllers: 00:14.0 USB controller [0c03]: Intel Corporation 8

Kernel v4.3 - RCU hang, USB implicated

Hello all, I'm not sure if USB hung because RCU died, or actually caused the RCU death itself. Hopefully the below is useful in determining the issue. I have a pretty standard system with a Haswell i7-4790 CPU, and these USB controllers: 00:14.0 USB controller [0c03]: Intel Corporation 8

Re: [PATCH 09/13] drm/irq: Make pipe unsigned and name consistent

On Wed, Aug 12, 2015 at 11:32 AM, Daniel Vetter wrote: > On Wed, Aug 12, 2015 at 05:00:31PM +0200, Thierry Reding wrote: >> From: Thierry Reding >> >> Name all references to the pipe number (CRTC index) consistently to make >> it easier to distinguish which is a pipe number and which is a

Re: [PATCH 09/13] drm/irq: Make pipe unsigned and name consistent

On Wed, Aug 12, 2015 at 11:32 AM, Daniel Vetter wrote: > On Wed, Aug 12, 2015 at 05:00:31PM +0200, Thierry Reding wrote: >> From: Thierry Reding >> >> Name all references to the pipe number (CRTC index) consistently to make >> it easier to distinguish which

Re: [PATCH v2] nouveau: fix OpenFirmware support

On Wed, Oct 14, 2015 at 11:20 AM, Laurent Vivier wrote: > > > Le 14/10/2015 16:52, Ilia Mirkin a écrit : >> On Wed, Oct 14, 2015 at 10:20 AM, Olaf Hering wrote: >>> On Sun, Oct 11, Laurent Vivier wrote: >>> >>>> On PowerMac G5 (and I think

Re: [PATCH v2] nouveau: fix OpenFirmware support

On Wed, Oct 14, 2015 at 11:20 AM, Olaf Hering wrote: > On Wed, Oct 14, Ilia Mirkin wrote: > >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=25d295882a1adfcdaaad85369289677b87c7c8f0 > > Thanks. > Almost perfect, lacks a stable tag. Code sh

Re: [PATCH v2] nouveau: fix OpenFirmware support

On Wed, Oct 14, 2015 at 10:20 AM, Olaf Hering wrote: > On Sun, Oct 11, Laurent Vivier wrote: > >> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() >> returns NULL. But in fact the OpenFirmware has given us the size >> we can store in image->size. > >> CC:

Re: [PATCH v2] nouveau: fix OpenFirmware support

On Wed, Oct 14, 2015 at 11:20 AM, Laurent Vivier <laur...@vivier.eu> wrote: > > > Le 14/10/2015 16:52, Ilia Mirkin a écrit : >> On Wed, Oct 14, 2015 at 10:20 AM, Olaf Hering <o...@aepfle.de> wrote: >>> On Sun, Oct 11, Laurent Vivier wrote: >>> >>

Re: [PATCH v2] nouveau: fix OpenFirmware support

On Wed, Oct 14, 2015 at 11:20 AM, Olaf Hering <o...@aepfle.de> wrote: > On Wed, Oct 14, Ilia Mirkin wrote: > >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=25d295882a1adfcdaaad85369289677b87c7c8f0 > > Thanks. > Almost perfect, lacks a stabl

Re: [PATCH v2] nouveau: fix OpenFirmware support

On Wed, Oct 14, 2015 at 10:20 AM, Olaf Hering wrote: > On Sun, Oct 11, Laurent Vivier wrote: > >> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() >> returns NULL. But in fact the OpenFirmware has given us the size >> we can store in image->size. > >>

Re: [PATCH] nouveau: fix OpenFirmware support

On Sat, Oct 10, 2015 at 7:45 PM, Laurent Vivier wrote: > > > Le 10/10/2015 21:56, Ilia Mirkin a écrit : >> On Sat, Oct 10, 2015 at 3:29 PM, Laurent Vivier wrote: >>> >>> >>> Le 10/10/2015 20:41, Ilia Mirkin a écrit : >>>> Hi Laurent, >

Re: [PATCH] nouveau: fix OpenFirmware support

On Sat, Oct 10, 2015 at 3:29 PM, Laurent Vivier wrote: > > > Le 10/10/2015 20:41, Ilia Mirkin a écrit : >> Hi Laurent, >> >> On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: >>> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pc

Re: [PATCH] nouveau: fix OpenFirmware support

Hi Laurent, On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: > On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() > returns NULL. But in fact the OpenFirmware has given us the size > we can store in image->size. > > This size is stored in bios->size by of_init() as

Re: [PATCH] nouveau: fix OpenFirmware support

Hi Laurent, On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: > On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() > returns NULL. But in fact the OpenFirmware has given us the size > we can store in image->size. > > This size is stored in

Re: [PATCH] nouveau: fix OpenFirmware support

On Sat, Oct 10, 2015 at 3:29 PM, Laurent Vivier <laur...@vivier.eu> wrote: > > > Le 10/10/2015 20:41, Ilia Mirkin a écrit : >> Hi Laurent, >> >> On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier <laur...@vivier.eu> wrote: >>> On PowerMac G5 (and I thi

Re: [PATCH] nouveau: fix OpenFirmware support

On Sat, Oct 10, 2015 at 7:45 PM, Laurent Vivier <laur...@vivier.eu> wrote: > > > Le 10/10/2015 21:56, Ilia Mirkin a écrit : >> On Sat, Oct 10, 2015 at 3:29 PM, Laurent Vivier <laur...@vivier.eu> wrote: >>> >>> >>> Le 10/10/2015 20:41, Ilia Mirk

Re: No more new fbdev drivers, please

On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee wrote: > BTW, I had a doubt about drm drivers. Is there any library or test suite > to test the driver? I am almost halfway in making a KMS driver for SM712 > but still don't know how to test it properly. I was thinkig of asking > Daniel offlist

Re: No more new fbdev drivers, please

On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee wrote: > BTW, I had a doubt about drm drivers. Is there any library or test suite > to test the driver? I am almost halfway in making a KMS driver for SM712 > but still don't know how to test it properly. I was thinkig

Re: AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

On Sun, Sep 13, 2015 at 6:01 PM, Ondrej Zary wrote: > On Sunday 13 September 2015 21:12:25 Ilia Mirkin wrote: >> On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary >> wrote: >> > Hello, >> > I have a PC Chips A31G board with AGPro slot and found that no

Re: AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary wrote: > Hello, > I have a PC Chips A31G board with AGPro slot and found that nouveau does not > work properly with it. Console works but reverts to software mode, X11 hangs > with mouse cursor only. > > The slot is physically AGP 1.5V but is wired to

Re: AGP cards in PCI mode (fake slots like AGPro, AGP Express, AGI, AGX, XGP)

On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary wrote: > Hello, > I have a PC Chips A31G board with AGPro slot and found that nouveau does not > work properly with it. Console works but reverts to software mode, X11 hangs > with mouse cursor only. > > The slot is

<    1   2   3   4   >