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 wrote:
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 conce
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
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
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
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
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 changed,
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.
> >
> > The gp
able, just mark it as such
> 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/2
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 GM107G
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
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 s
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 userspace
uninitialized_var() 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
&g
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 si
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:
> > >
> > >
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.
>
> Signed-o
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 Binuti
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
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'
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 testin
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 P
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
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
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 1
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
> lo
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
> +++ b/drivers/gpu/drm/nouveau/nouveau_connec
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
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 ---
> drivers/gpu/drm/nouveau/dispnv50
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:
> >> >
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
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 suit
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
> &
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:
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:
> https://askubuntu.com/questions/4662/where-is-the-x-org-config-file
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, compi
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 CoverityScan
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
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
>
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
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 hopeful
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 +--
> drivers/gpu/drm/nouveau/nvkm/engin
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:
>> >>
>> >
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,
>
>
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
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:
>> > https://git.kernel.org/tip/6d60ce384d1d5ca32b595244db4077
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
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:
>>> > @@
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:
>>> > @@
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: ->
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: ->
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 t
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 G
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 Em
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
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:
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 "is_panel_b
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
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
On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce
On Sat, Jul 15, 2017 at 12:14 PM, Ilia Mirkin wrote:
> On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
>> Greetings,
>>
>> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
>> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>>
On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce
On 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 a
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 never
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
>>
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
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 wrote:
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 be
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 limi
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
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
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
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
t know whether they're broken, and comments we're
pretty 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 t
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
>&
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
>>> e.g.
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 stack
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 fi
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 th
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
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
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 supp
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
=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 work
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
>>> Clo
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,
>> I d
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 updat
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: det
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:
>>>>
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
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 s
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':
> tvnv17.c:(.text.nouveau_do_suspend
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 exte
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
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 o
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
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
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
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 14,
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]
>>
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
>> nouveau_fbcon_imageblit().
1 - 100 of 203 matches
Mail list logo
