On Sat, Apr 6, 2013 at 5:01 AM, Ilia Mirkin wrote:
> On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
>> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>>
>>> The GPF happens at +160, which is in the argument setup for the
>>> cmpxchg in slab_all
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 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 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
---
v2 -> v3:
- rename ida struct name to... ida. (i'm ready to accept my "creative name
of th
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
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
> b/drivers/gpu/drm/nouveau/cor
On Mon, Aug 11, 2014 at 9:42 AM, Tom Li wrote:
> Hello everyone.
>
> I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
> graphics card. Avoid the flicking between the VT-switching on my
> computer is what I want.
> This antiquated card doesn't support 3D and OpenGL stuff, but
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 M
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 an
On Wed, Apr 2, 2014 at 9:52 AM, Alexandre Courbot wrote:
> On Tue, Mar 25, 2014 at 7:34 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
>> [...]
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
>>> b/drivers/gpu/drm/nouveau/core/s
On Wed, Apr 2, 2014 at 10:14 AM, Alexandre Courbot wrote:
+ /* Need to figure out how to handle sw for gk20a */
+ if (device->chipset == 0xea)
+ goto skip_sw_init;
>>>
>>> The commit message makes it sound like SW isn't needed since gk20a
>>> "lacks any display h
close it.
>
> Yours,
> Claas
>
>
> On 27.03.2014 11:54, Patrick Clara wrote:
>> I have tested this patch. I can confirm that now nouveau loads
>> correctly without errors.
>> Thank you
>>
>> 2014-03-27 0:37 GMT+01:00 Ilia Mirkin :
>>> There appear to
On Thu, Apr 10, 2014 at 9:08 AM, Lauri Kasanen wrote:
> This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
> Indeed, inlining it grows radeon.ko by 7%.
>
> However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
> in Urban Terror.
>
> Signed-off-by: Laur
On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
> On Thu, 10 Apr 2014 12:19:10 -0400
> Ilia Mirkin wrote:
>
>> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
>> > reg,
>> > + bool always_in
On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
wrote:
> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will
bytes or u32's? From the code, I'm guessing the latter. (Similar
concern about comment in the code.)
> fail to run from non-prepadded firmware files.
>
> Signed-off
On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
wrote:
> Skip the creation of a software channel for GK20A as software methods
> are not yet supported.
How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
the 3D Controller ones, and I guess even some that come up as VGA
cont
On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler wrote:
> If a display supports backlight control using the nouveau driver, and
> also supports standard ACPI backlight control, there will be two sets of
> controls.
>
> /sys/class/backlight/acpi_video0
> /sys/class/backlight/nv_backlight
>
> This c
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.
>
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
> ---
> drivers/gpu/drm/no
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 prov
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 usually
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 inserti
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
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
--- a
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
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
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
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 thin
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
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.
driv
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. I've
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 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 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 distc
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
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 con
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
eported-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
Signed-off-by: Ilia Mirkin
---
Statuses derived from envytools, as usual. Not 100% sure about the "any"
thing, but it makes sense...
drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/en
houldn't be too difficult for me to
extend this to categories like, 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
---
dri
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
>
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
iled 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
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 --
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 distc
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 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 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 | 8
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
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
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 someth
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
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
g.cgi?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
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
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
Signed-off-by: Ilia Mirkin
---
Based on a recent discussion in #radeon, and also my own observation that the
'full' scaling causes no end of confusion among users.
See https://bugs.freedesktop.org/show_bug.cgi?id=80868 for some more details,
although it is more radeon-specific.
Side
On Thu, Jul 3, 2014 at 8:27 PM, Ben Skeggs wrote:
> On Fri, Jul 4, 2014 at 5:27 AM, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> Based on a recent discussion in #radeon, and also my own observation that the
>> 'full' scaling causes
On Fri, Mar 29, 2013 at 11:22 AM, Michal Hocko wrote:
> On Wed 27-03-13 14:25:36, Ilia Mirkin wrote:
>> Hello,
>>
>> My system died last night apparently due to OOM conditions. Note that
>> I don't have any swap set up, but my understanding is that this is not
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 monitor
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 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
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
Doesn't this require a kernel version that has your other patch? What
happens when this runs on an older kernel? Does it get silently
ignored, or does it end up erroring out? If it errors out, that's
fine. Otherwise some sort of version check should be put in, no?
On Fri, Mar 13, 2015 at 2:27 AM,
On Thu, Mar 19, 2015 at 12:35 PM, Damien Lespiau
wrote:
> That's the only type :set spell found.
---^
But it didn't find this one :)
>
> Signed-off-by: Damien Lespiau
> ---
> RELEASING | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/RELEASING b/RELEAS
How will userspace know that it's safe to use this command on a
particular kernel? Normally the driver's drm version is incremented,
and then userspace is gated it... Or does this not matter here?
On Mon, Mar 30, 2015 at 3:37 PM, Leo Liu wrote:
> Signed-off-by: Leo Liu
> ---
> drivers/gpu/drm/r
On Fri, May 1, 2015 at 6:34 AM, Christian König
wrote:
> From: "monk.liu"
>
> Fixing a memory leak with userptrs.
>
> Signed-off-by: monk.liu
> Signed-off-by: Christian König
> CC: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 13 +
> 1 file changed, 9
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
http://cgit.freedeskt
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 s
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 hilar
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
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_pcirTp
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,
>
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: imirkin at alum
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
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
I think you're right. The intent is to mask off the bits above
bits_per_pixel. So if bits_per_pixel is 24, the mask would be
0xff00. If it's 16, then the mask would be 0x. If it's 32,
then the mask is 0.
In reality, bits_per_pixel is almost exclusively 32, which will end up
with a mask
On Thu, Jul 23, 2015 at 10:32 PM, Ben Skeggs wrote:
> On 24 July 2015 at 01:20, Hans de Goede wrote:
>> MSI interrupts appear to not work for nv46 based cards. Change the mc
>> subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is
>> identical to the nv44 mc code except that it doe
On Mon, Jul 27, 2015 at 11:52 AM, Hans de Goede wrote:
> https://fedorapeople.org/~jwrdegoede/nvidia-bin-nv46-msi-on-glxgears.mmiotrace.gz
>
> AFAIK there are some nouveau tools to parse this a bit, right ? I'm going
> to call it a day for today, if you can give me some pointers what to do with
>
On Wed, Jul 29, 2015 at 3:44 AM, Oded Gabbay wrote:
> The wrong define was used to check if the hqd is still active
>
> Signed-off-by: Oded Gabbay
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/
Is this happening with libdrm 2.4.60? If so, that's a known
(user-side) issue and should be fixed by using any version but that
one.
On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue
wrote:
> Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version
> of the browser and current
On Thu, Jul 30, 2015 at 10:46 AM, Peter Hurley
wrote:
> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>> Is this happening with libdrm 2.4.60? If so, that's a known
>> (user-side) issue and should be fixed by using any version but that
>> one.
>
> What's the fre
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
wrote:
> On 30/07/15 15:52, Bryan O'Donoghue wrote:
>>
>> On 30/07/15 15:49, Peter Hurley wrote:
>>>
>>> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>>>>
>>>> Is this happening w
On Fri, Jul 31, 2015 at 6:27 AM, Bryan O'Donoghue
wrote:
> ah no... 2.4.60 is right...
>
> Yes so Ilia - I've switched out 2.4.60 as per your suggestion to 2.4.56
> (getting the version numbers right :) ) and it's still definitely giving me
> the multiple instances message.
This is going to sound
unsigned mask = ~(~0 >> (32 - (argv[1][0] - '0')));
printf("%08x\n", mask);
}
I guess fbdev/nvidia/nv_accel.c was the source of all this, as the
code is identical, and it probably came first.
FWIW this is
Reviewed-by: Ilia Mirkin
>
> ---
>
> This patch is u
Why did you change request_firmware to request_firmware_direct?
On Thu, Jun 18, 2015 at 10:47 AM, Alexandre Courbot wrote:
> NVIDIA will officially start providing signed firmwares through
> linux-firmware. Change the GR firmware lookup function to look them up
> in addition to the extracted firm
This should help catch odd bugs at the callsites rather than much later
on with completely bogus bo indices.
Signed-off-by: Ilia Mirkin
---
nouveau/pushbuf.c | 4
1 file changed, 4 insertions(+)
diff --git a/nouveau/pushbuf.c b/nouveau/pushbuf.c
index 4f77881..8e7dcdf 100644
--- a/nouveau
On Wed, Jan 7, 2015 at 5:29 PM, Andy Shevchenko
wrote:
> We have to check pointer before usage.
>
> Reported-by: Andrey Karpov
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/nouveau/core/subdev/clock/base.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/dr
On Wed, Jan 7, 2015 at 11:32 PM, Vince Hsu wrote:
>
> On 01/08/2015 10:45 AM, Ilia Mirkin wrote:
>>
>> On Wed, Jan 7, 2015 at 5:29 PM, Andy Shevchenko
>> wrote:
>>>
>>> We have to check pointer before usage.
>>>
>>> Re
On Thu, Jan 8, 2015 at 12:40 AM, Vince Hsu wrote:
> On 01/08/2015 12:57 PM, Ilia Mirkin wrote:
>>
>> On Wed, Jan 7, 2015 at 11:32 PM, Vince Hsu wrote:
>>>
>>> On 01/08/2015 10:45 AM, Ilia Mirkin wrote:
>>>>
>>>> On Wed, Jan 7, 2015 at 5:2
On Wed, Jul 1, 2015 at 12:51 PM, Colin King wrote:
> From: Colin Ian King
>
> Various usif_ioctl helper functions do not initialize the
> return variable ret and some of the error handling return
> paths just return garbage values that were on the stack (or
> in a register). I believe that in al
On Wed, Jul 1, 2015 at 1:18 PM, Colin Ian King
wrote:
> On 01/07/15 18:12, Emil Velikov wrote:
>> On 1 July 2015 at 17:56, Ilia Mirkin wrote:
>>> On Wed, Jul 1, 2015 at 12:51 PM, Colin King
>>> wrote:
>>>> From: Colin Ian King
>>>>
>>
On Wed, Jul 1, 2015 at 1:59 PM, Emil Velikov
wrote:
> On 1 July 2015 at 18:37, Ilia Mirkin wrote:
>> On Wed, Jul 1, 2015 at 1:18 PM, Colin Ian King
>> wrote:
>>> On 01/07/15 18:12, Emil Velikov wrote:
>>>> On 1 July 2015 at 17:56, Ilia Mirkin wrote:
&
On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew wrote:
> Hello,
>
> I am currently looking into ways to support fixed virtual address allocations
> and sparse mappings in nouveau, as a step towards supporting CUDA.
>
> CUDA requires that the GPU virtual address for a given buffer match the
> CPU virtu
On Mon, Oct 19, 2015 at 3:47 PM, Rob Clark wrote:
> Also, there is some trivial shader variant handling in mesa st which
> would have to be ported to NIR. Or, perhaps, just somehow expose the
> shader key to the driver. (Currently most drivers are doing much more
> variant handling within the dr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin
---
drm/nouveau/nouveau_gem.c | 5 +++--
lib/include/nvif/os.h | 6 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drm/nouveau/nouveau_gem.c b/drm/nouveau/nouveau_gem.c
index ce74ab1
On Oct 23, 2015 6:32 AM, "Eric Anholt" wrote:
>
> Caught by the kbuild test robot.
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 3 ++-
> drivers/gpu/drm/vc4/vc4_hvs.c | 8
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4
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 pointer
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
401 - 500 of 521 matches
Mail list logo
