On Wed, Mar 12, 2014 at 9:04 PM, Emil Velikov
wrote:
> On 13/03/14 00:45, Ilia Mirkin wrote:
>>
>> On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
>> wrote:
>>>
>>> In theory it's possible for any of the nouveau_getparam calls to
>>> fail whist the
On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
wrote:
> Current handling relies on atoi which does not detect errors
> additionally, any integer value will be considered as a valid
> percent.
>
> Resolve that by using strtol and limiting the value within
> the 5-100 (percent) range.
>
>
On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov
wrote:
> In theory it's possible for any of the nouveau_getparam calls to
> fail whist the last one being successful.
>
> Thus at least one of the following (hard requirements) drmVersion,
> chipset and vram/gart memory size will be filled with
On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman wrote:
> On 9 February 2014 02:57, Ilia Mirkin wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman
>> wrote:
>>> Interestingly, there was graphical failure booting 3.6.11, even
>>> nvidia-current f
On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman wrote:
> On 9 February 2014 02:57, Ilia Mirkin wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman
>> wrote:
>>> Interestingly, there was graphical failure booting 3.6.11, even
>>> nvidia-current f
On Fri, Feb 21, 2014 at 2:55 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> When kernel mode-setting is disabled, mark the driver as legacy to pick
> up the special semantics required for userspace mode-setting.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/i915/i915_drv.c |
On Thu, Feb 20, 2014 at 4:02 PM, Paul Bolle wrote:
> Building radeon_ttm.o on 32 bit x86 triggers a warning:
> In file included from include/asm-generic/bug.h:13:0,
> from [...]/arch/x86/include/asm/bug.h:38,
> from include/linux/bug.h:4,
>
On Sun, Feb 16, 2014 at 2:15 PM, Rafa? Mi?ecki wrote:
> 2014-02-16 19:55 GMT+01:00 Ilia Mirkin :
>> On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki wrote:
>>> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
>>>> (b) bisect. you can (almost) definitely restrict the bisect t
On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki wrote:
> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
>> (b) bisect. you can (almost) definitely restrict the bisect to
>> drivers/gpu/drm/nouveau. if you have additional computational power, i
>> would recommend looking into d
Having a \n in the middle of a format string means that the next line
doesn't get the prefixes unlike every other line printed by the trace.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
untiled check to explicitly include all pre-nv50 cards.
Reported-by: Ronald
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74613
Signed-off-by: Ilia Mirkin
---
Hmmm... this seems like a really fragile semantic, I wonder if more
mem->mm_node usages have to be audited. But this one's quick and easy
On Fri, Feb 14, 2014 at 9:32 PM, Ilia Mirkin wrote:
> On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin wrote:
>> So... I was wondering what the impact of splitting up the card compilation by
>> e.g. generation would be. Depending on the split things would get fairly
>> intertwi
On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin wrote:
> So... I was wondering what the impact of splitting up the card compilation by
> e.g. generation would be. Depending on the split things would get fairly
> intertwined, so I thought I'd start small. This just splits NVC0 from
> eve
difficult for me to
extend this to categories like<nve0+>, or
maybe even more fine-grained, esp since nvd0 is when a lot of changes
happened. Or maybe less-fine-grained and keep the nvc0/nve0 cards under one
option.
Feedback appreciated.
Not-Signed-off-by: Ilia Mirkin
---
drivers/g
Reported-by: Torsten Wagner
Reported-by: Michael Gulick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67628
Cc: stable at vger.kernel.org # 3.9+
Signed-off-by: Ilia Mirkin
---
Ben did a quick test that makes it seem like this is the right thing to
do. And it makes sense based on the surrou
It's really confusing for NV_DEBUG's printing to be controlled via
drm.debug while everything else is controlled via nouveau.debug. These
messages can be turned on with nouveau.debug=DRM=debug.
Signed-off-by: Ilia Mirkin
---
Updated version that makes the top-level DRM client have a separate
It's really confusing for NV_DEBUG's printing to be controlled via
drm.debug while everything else is controlled via nouveau.debug. These
messages can be turned on with nouveau.debug=CLIENT=debug.
Signed-off-by: Ilia Mirkin
---
It's a bit annoying that the DRM messages are conflated
The hdmi device is required for runtime pm. However it is not available
on many esp older devices, which were all seeing these error messages.
Take this opportunity to also convert to nv_debug instead of the DRM_*
messages, like the rest of nouveau does.
Signed-off-by: Ilia Mirkin
---
drivers
On Tue, Feb 11, 2014 at 6:09 AM, Rafa? Mi?ecki wrote:
> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
>> (b) bisect. you can (almost) definitely restrict the bisect to
>> drivers/gpu/drm/nouveau. if you have additional computational power, i
>> would recommend looking into d
On Mon, Feb 10, 2014 at 3:05 PM, Rafa? Mi?ecki wrote:
> 2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
>> There was also an issue with libdrm_nouveau for pre-nv50 chips, when
>> compiled with gcc-4.8 some time back... fixed in... 2.4.48 or so?
>
> I use openSUSE 12.2 (x86_64) whi
On Mon, Feb 10, 2014 at 10:12 AM, Rafa? Mi?ecki wrote:
> 2014-02-09 23:12 GMT+01:00 Ilia Mirkin :
>> On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote:
>>> Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
>>> noticed nasty display corruptio
On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote:
> Hi guys,
>
> Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and
> noticed nasty display corruptions when using nouveau. It seems that
> changing parts of the screen are appearing for a fraction of second in
> random places.
abi16->handles is a u64, so make sure to use 1ULL << val when modifying.
Signed-off-by: Ilia Mirkin
---
Noticed this when doing the previous patch. I'm not sure whether this affects
64-bit builds or not, didn't care to look at the assembly or check the
standard.
drivers/gpu/dr
The ffsll function is a lot slower than the __ffs64 built-in which
compiles to a single instruction on 64-bit. It's also nice to avoid
custom versions of standard functions. Note that __ffs == ffs - 1.
Signed-off-by: Ilia Mirkin
---
I wrote a user-space program to test these out and make sure
Commit ea7dce901 ("drm/nv50/gr: print mpc trap name when it's not an mp
trap") added an nv_error call that was missing the priv parameter. This
causes GPFs if the error is ever hit.
Signed-off-by: Ilia Mirkin
---
Sorry, my bad! But... I hit it and it killed my computer. So things ar
On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman wrote:
> Interestingly, there was graphical failure booting 3.6.11, even
> nvidia-current fails to initialise, but these two issues could be due
> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
> nouveau.noaccel=1 works great for the
On Sat, Feb 8, 2014 at 2:58 AM, Daniel J Blueman wrote:
> Hi guys,
>
> With a GeForce 320M GPU running linux 3.13.2 and Xorg 1.15.0, I'm
> seeing significant graphical corruption and later unrecoverable GPU
> lockup, accompanied by thousands of ILLEGAL_MTHD or related kernel
> messages [1]. I see
Suggested-by: Marcin Ko?cielnicki
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index aa0fbbe..ef0c9c4
Suggested-by: Marcin Ko?cielnicki
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 81638d7..471347e 100644
See https://bugs.freedesktop.org/show_bug.cgi?id=74492
Reported-by: Ronald
Suggested-by: Marcin Ko?cielnicki
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 10 ++---
drivers/gpu/drm/nouveau/core
Signed-off-by: Ilia Mirkin
---
This syncs it up with what's in envytools. Some of the names are a bit
different, but I'm inclined to trust envytools as the correct thing.
drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 29
1 file changed, 15 insertions(+), 14
On Sun, Feb 2, 2014 at 9:44 PM, Alexandre Courbot
wrote:
> One beginner question: is it appropriate to send kernel patches to the
> nouveau list in addition to dri-devel? The moderation messages I receive
> make me think that this list might rather be intended for general
> discussion.
I
Hi Alexandre,
On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot
wrote:
> I guess my email address might surprise some of you, so let me anticipate some
> questions you might have. :P Yes, this work is endorsed by NVIDIA. Several
> other
> NVIDIAns (CC'd), including core GPU experts, have
Some very trivial comments below:
On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot
wrote:
> Add support for initializing the priv ring of GK20A. This is done by the
> BIOS on desktop GPUs, but needs to be done by hand on Tegra.
>
> Signed-off-by: Alexandre Courbot
> ---
>
On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach wrote:
> Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot:
>> Add a clumsy-but-working FB support for GK20A. This chip only uses system
>> memory, so we allocate a big chunk using CMA and let the existing memory
>> managers work on it.
On Thu, Jan 30, 2014 at 3:33 AM, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 1:53 AM, Ilia Mirkin wrote:
>> Since commit 0fa9061ae8c ("drm/nouveau/mc: handle irq-related setup
>> ourselves"), drm_device->irq_enabled remained unset. This is needed in
>> o
necek
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org # 3.10+
---
TBH, not sure why this fixes things, as irq_enabled == false should have
caused the vblank wait to not wait, since the condition would be
immediately true.
Jan, mind double-checking that this version of the patch fixes t
?id=73791
Reported-by: Andreas Reis
Tested-by: Andreas Reis
Signed-off-by: Ilia Mirkin
---
3.13 release time is approaching, so I'm expanding the To list, as this is a
crashing bug for potentially a lot of people (not sure how common the MXM
stuff is) and it'd be silly not to include the fix
This replaces the custom disable checks throughout the implementations.
As a side-effect this will honor hw disables on video decoding engines
as well as PDISP on nvc0:nvd0.
Signed-off-by: Ilia Mirkin
---
Not strictly needed, but I think it's nice to unify it all. (And it also
handles the video
This will turn off PDISPLAY/PCRYPT/PCOPY0/video engines on cards where
they are marked as disabled either by the hardware of VBIOS.
See https://bugs.freedesktop.org/show_bug.cgi?id=58378
Signed-off-by: Ilia Mirkin
---
An earlier version of this patch was tested. I added the DISP disable since
Signed-off-by: Ilia Mirkin
---
I decided to let the user still specify config=BLA=1 to override the hw
disable in case we get something wrong or for double-checking stuff, but I
suspect it won't really be used much. I'm not terribly fond of the message
text, if you come up with something better
not contain a detectable script, so always return 0 for them.
See https://bugs.freedesktop.org/show_bug.cgi?id=68835
Reported-by: Mauro Molinari
Signed-off-by: Ilia Mirkin
---
Unfortunately the bug reporter doesn't really know how to compile kernels and
my bet is that the system his NV04 is in isn't
On Thu, Dec 12, 2013 at 12:07 PM, Rob Clark wrote:
> If driver failed to load (for example, -EPROBE_DEFER), we'd end up doing
> drm_put_minor() both from drm_dev_register() and drm_dev_free(), the
> second time with a bogus pointer.
FYI, I sent a similar patch ~week ago that changed put_minor
The intent was to only enable it by default for optimus, e.g. see the
runtime_idle callback. The suspend callback may be called directly, e.g.
as a result of nouveau_crtc_set_config.
Reported-by: Stefan Lippers-Hollmann
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org
---
See http
Some firmware images may be large (64K), so using kmalloc memory is
inappropriate for them. Use vmalloc instead, to avoid high-order
allocation failures.
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org
---
Couldn't get video decoding started on a long-running system due to high-order
off-by: Ilia Mirkin
---
v2: use drm_unplug_minor instead of just removing the puts, as suggested by
David Herrman.
drivers/gpu/drm/drm_stub.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index f53d524..66dd
All instances of drm_dev_register are followed by drm_dev_free on
failure. Don't free dev->control/render/primary on failure, as they will
be freed by drm_dev_free since commit 8f6599da8e (drm: delay minor
destruction to drm_dev_free()).
Reported-by: Bruno Pr?mont
Signed-off-by: Ilia Mir
On Wed, Dec 4, 2013 at 6:15 AM, Ilia Mirkin wrote:
> On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont
> wrote:
>> [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22
>> [ 657.802123] general protection fault: [#1] SMP
>> [ 657.802130] Modules l
On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont
wrote:
> Hi,
>
> With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau:
> [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type
> mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95)
> [
Reported-by: Jim Davis
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 38a4db5..4aff04f 100644
--- a/drivers/gpu/drm/nouveau
On Tue, Nov 26, 2013 at 8:35 PM, Stefan Lippers-Hollmann
wrote:
> Hi
>
> On Wednesday 27 November 2013, Ilia Mirkin wrote:
>> On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann
>> wrote:
>> > Hi
>> >
>> > On Tuesday 26 November 2013, Ilia
On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann
wrote:
> Hi
>
> On Tuesday 26 November 2013, Ilia Mirkin wrote:
>> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann
>> wrote:
>> > v3.11 is fine, with and without monitor attached.
>> &g
On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann
wrote:
> v3.11 is fine, with and without monitor attached.
> v3.12 is fine as long as X.org isn't started (but may fail to reboot
> cleanly). If a monitor is connected I don't observe any problems,
> it freezes without a
On Sun, Oct 27, 2013 at 11:01 PM, Robert Hancock
wrote:
> On 10/27/2013 09:54 AM, Ilia Mirkin wrote:
>>
>> Certain combinations of hardware can't actually support the maximum
>> detected speed. Add a quirk list that lists pairs of hostbridge/chip pci
>> ids and the
Certain combinations of hardware can't actually support the maximum
detected speed. Add a quirk list that lists pairs of hostbridge/chip pci
ids and the mode that they should work with.
See https://bugs.freedesktop.org/show_bug.cgi?id=20341
Reported-by: Jason Detring
Signed-off-by: Ilia Mirkin
On Fri, Oct 11, 2013 at 12:50 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Fri, Oct 11, 2013 at 12:33 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
I was just looking at
https://bugs.freedesktop.org/show_bug.cgi?id=20341 (see last comment).
Basically he's able to to use the card with agpmode
I was just looking at
https://bugs.freedesktop.org/show_bug.cgi?id=20341 (see last comment).
Basically he's able to to use the card with agpmode=2 but not the
auto-detected agpmode=4. I also saw that the radeon driver has a large
quirks list, and it seems silly to reproduce it in nouveau.
However
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
This has received light testing on NV18 and NV34 cards, using the modetest
tool. Userspace support to use this for xv is not yet ready.
I decided against creating a new pvideo engine -- that just seems way too
heavy-handed compared to the ~10
This is helpful for differentiating between multiple devices that use
the same module.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
tests/modetest/modetest.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
tests/modetest/modetest.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 9d6e279..51c4e6d 100644
--- a/tests/modetest/modetest.c
+++ b/tests
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
>>> wrote:
>>>> On Thu, Aug 29, 2013 at 12
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin
>>> wrote:
>>>> On Wed, Aug 28, 2013 at 8
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin wrote:
>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin
>>> wrote:
>>>> On Wed, Aug 28, 2013 a
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin wrote:
>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>>>> On Wed, Aug 28, 2013 a
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
>> > MSIs were only problematic on some old, broken chipsets. But now that we
>> > already see systems where PCI legacy
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013
-off-by: Ilia Mirkin
---
This will only happen if i2c_algo_bit.bit_test=1.
drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 8 +---
drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
drivers/gpu/drm/nouveau/core/subdev/i2c/base.c| 2 ++
drivers/gpu/drm/nouveau/core
Deifel hpdei...@gmx.de
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
This will only happen if i2c_algo_bit.bit_test=1.
drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 8 +---
drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
drivers/gpu/drm/nouveau/core/subdev/i2c
The code expects non-VRAM mem nodes to have a pages list. If that's not
set, it will do a null deref down the line. Warn on that condition and
return an error.
See https://bugs.freedesktop.org/show_bug.cgi?id=64774
Reported-by: Pasi K?rkk?inen
Tested-by: Pasi K?rkk?inen
Signed-off-by: Ilia
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: sta...@vger.kernel.org # 3.8+
---
I don't exactly understand what's going on, but this is just a
straightforward way to avoid a null deref that you see happens in the
bug. I haven't figured out the root cause of this, but it's getting
well
On Mon, Aug 12, 2013 at 6:43 AM, Maarten Lankhorst
wrote:
> Some registers were not initialized in init, this causes them to be
> uninitialized after suspend.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
>
On Mon, Aug 12, 2013 at 6:43 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Some registers were not initialized in init, this causes them to be
uninitialized after suspend.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git
Commit dceef5d87 (drm/nouveau/fb: initialise vram controller as pfb
sub-object) moved some code around and introduced these null derefs.
pfb->ram is set to the new ram object outside of this ctor.
Reported-by: Ronald Uitermark
Tested-by: Ronald Uitermark
Signed-off-by: Ilia Mirkin
---
driv
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c | 12 ++--
drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c
b/drivers
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
v2 -> v3:
- rename ida struct name to... ida. (i'm ready to accept my "creative name
of the yea
On Wed, Aug 7, 2013 at 4:00 AM, Ville Syrj?l?
wrote:
> On Tue, Jul 30, 2013 at 03:51:49AM -0400, Ilia Mirkin wrote:
>> This makes it so that reloading a module does not cause all the
>> connector ids to change, which are user-visible and sometimes used
>> for configurat
On Wed, Aug 7, 2013 at 4:00 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Jul 30, 2013 at 03:51:49AM -0400, Ilia Mirkin wrote:
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v2 - v3:
- rename ida struct name to... ida. (i'm ready to accept my creative name
On Tue, Aug 6, 2013 at 8:40 PM, Rob Clark wrote:
> On Tue, Aug 6, 2013 at 8:12 PM, Dave Airlie wrote:
>> On Tue, Jul 30, 2013 at 5:51 PM, Ilia Mirkin wrote:
>>> This makes it so that reloading a module does not cause all the
>>> connector ids to change, which are user
On Tue, Aug 6, 2013 at 8:40 PM, Rob Clark robdcl...@gmail.com wrote:
On Tue, Aug 6, 2013 at 8:12 PM, Dave Airlie airl...@gmail.com wrote:
On Tue, Jul 30, 2013 at 5:51 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
This makes it so that reloading a module does not cause all the
connector ids
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
v1 -> v2: correct loop condition... not sure how that slipped past
me... the code started out by being <
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
Only mild testing... reloaded nouveau a few times, all the connectors
kept their original ids.
drivers/gpu/drm
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Only mild testing... reloaded nouveau a few times, all the connectors
kept their original ids
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v1 - v2: correct loop condition... not sure how that slipped past
me... the code started out
On Fri, Jul 26, 2013 at 8:39 PM, Ilia Mirkin wrote:
> Hello,
>
> I've started seeing the following warning in 3.11-rc2. [In the
> interest of full disclosure, I do have a patch applied that tries to
> implement drm_planes, which I might have done completely incorrectly,
>
Hello,
I've started seeing the following warning in 3.11-rc2. [In the
interest of full disclosure, I do have a patch applied that tries to
implement drm_planes, which I might have done completely incorrectly,
but looking around it doesn't seem related. I'm definitely not
invoking any of the
On Fri, Jul 26, 2013 at 2:28 PM, konrad wilk wrote:
> I just saw this on a box of mine (rc1 worked) I hadn't done yet a bisection.
> Any suggestions?
>
> ring 0 polarity 1
> [6.023776] Already setup the GSI :22
> ^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G[6.036680] nouveau [
>
On Fri, Jul 26, 2013 at 2:28 PM, konrad wilk konrad.w...@oracle.com wrote:
I just saw this on a box of mine (rc1 worked) I hadn't done yet a bisection.
Any suggestions?
ring 0 polarity 1
[6.023776] Already setup the GSI :22
^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G[6.036680]
Hello,
I've started seeing the following warning in 3.11-rc2. [In the
interest of full disclosure, I do have a patch applied that tries to
implement drm_planes, which I might have done completely incorrectly,
but looking around it doesn't seem related. I'm definitely not
invoking any of the
On Fri, Jul 26, 2013 at 8:39 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Hello,
I've started seeing the following warning in 3.11-rc2. [In the
interest of full disclosure, I do have a patch applied that tries to
implement drm_planes, which I might have done completely incorrectly
This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).
Reported-and-tested-by: Max Baldwin
Signed-off-by: Ilia Mirkin
---
The actual
This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).
Reported-and-tested-by: Max Baldwin archerse...@gmail.com
Signed-off-by: Ilia Mirkin
the mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- factored out similar logic between vp and bsp into a new xtensa.c, similar
to falcon
- moved firmware loading to init rather than c
the mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v1 - v2:
- factored out similar logic between vp and bsp into a new xtensa.c, similar
to falcon
- moved firmware loading to init
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 04-06-13 20:38, Ilia Mirkin schreef:
>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
>>> These chipsets include the VP2 engine which is composed of a bitstream
>>> processor (BS
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Hey,
Op 04-06-13 20:38, Ilia Mirkin schreef:
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
These chipsets include the VP2 engine which is composed of a bitstream
processor (BSP
401 - 500 of 514 matches
Mail list logo
