0_HDMI_BLOCK1 ? 0 : 1] = false;
^^
offset is 8 bits so this condition is always false.
+ radeon_irq_set(rdev);
+
regards,
up, because timings[] is declared inside
a union and increasing the number of elements here doesn't change the
overall size of the union.
Signed-off-by: Dan Carpenter
---
This patch applies to drm-next.
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index d33c3e0..39e2cc5 1
m == num_est3_modes is one past the end of the est3_modes[].
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7188674..46447b0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1383,7 +1383,7 @@ drm_est3_modes
The original code dereferences "fb_helper_conn" before verifying that
it's non-null.
Signed-off-by: Dan Carpenter
---
It's never null here actually. I could send a patch to remove the check
instead if that's prefered.
diff --git a/drivers/gpu/drm/drm_fb_h
There was a missing mutex_unlock(&dev->struct_mutex) on this error path.
Signed-off-by: Dan Carpenter
---
I thought Jiri sent this patch earlier but a google search for "stanse
struct_mutex i965_reset" didn't find any patches, so I'm resending.
diff --git a/driver
Ping. This off-by-one overflow is still there in -next.
I'm not sure how to fix it because both the declaraion and the
use in add_detailed_modes() look deliberate.
regards,
dan carpenter
On Sun, Mar 28, 2010 at 02:25:58PM +0300, Dan Carpenter wrote:
> Hi list, :)
>
> Just goin
The "connector" variable is used as the cursor in a
list_for_each_entry() and it's always non-null so we don't need to check
it.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 42ceb15..179d146 100644
-
The "encoder" variable can never be null because it is used as loop
cursor in a list_for_each_entry() loop.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f6299bb..950dc8d 100644
--- a/drivers/gpu/drm/i915/intel_
If "gpio->line" is 32 then "nv50_gpio_reg[gpio->line >> 3]" reads past the
end of the array.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nv50_gpio.c
b/drivers/gpu/drm/nouveau/nv50_gpio.c
index c61782b..bb47ad7 100644
--- a/drivers/gpu/drm/n
In the original code there was a typo and we called kfree(pgraph->ctxprog)
two times instead of kfree(pgraph->ctxvals);
Also it's OK to pass NULL variables to kfree(). checkpatch.pl complains
about this so I removed the checks.
Signed-off-by: Dan Carpenter
diff --git a/driv
This is an unlikely memory leak, but we may as well fix it. It's easy
to fix and every static checker will complain if we don't.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 247f8ee..58845e0 100644
--- a/drivers/gpu/
} else
565 error = abs(current_freq - freq);
regards,
dan carpenter
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactiv
On Sun, Mar 28, 2010 at 10:55:14PM +0200, Andi Kleen wrote:
> , Dan Carpenter wrote:
>>
>> In the original code we used "j" as an iterator but we used "i" as an
>> index.
>>
>> - for (j = 0; j< i; j++)
>&g
plained about that because "i" was potentially passed the end
of the array. Which makes sense if we should be using "j" there.
I also thought that we should remove the files for &connector_attrs_opt1
but to do that I had to add separate iterators for &connector_attrs and
&
"fx->lock" is used as the index in "dev_priv->decoder_queue[fx->lock]"
which is an array of "VIA_NR_XVMC_LOCKS" elements.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/via/via_video.c b/drivers/gpu/drm/via/via_video.c
index 6ec04ac..6
This change makes the array larger, "MAX_SUPPORTED_TV_TIMING_V1_2" is 3
and the original size "MAX_SUPPORTED_TV_TIMING" is 2.
Also there were checks that were off by one.
Signed-off-by: Dan Carpenter
---
Compile tested only. Changing the array size seemed like the right
t detailed_data_string str;
struct detailed_data_monitor_range range;
struct detailed_data_wpindex color;
struct std_timing timings[5];
^
struct cvt_timing cvt[4];
} data;
} __attribute_
"agpmem" is never NULL here.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index e4865f9..7732268 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -77,7 +77,7 @@ static void *agp_remap(unsigned l
On Tue, Mar 23, 2010 at 7:04 AM, Sedat Dilek wrote:
> V2 of my proposal.
0001: Reviewed-by: Dan Nicholson
0002: Having a hard requirement on libdrm_radeon needs to be passed by
the radeon developers. If it is deemed OK, then just drop the 3rd and
4th argument to the PKG_CHECK_MODULES and
u_drmif.h
>
> +noinst_HEADERS = \
> + nouveau_private.h
> +
> pkgconfigdir = @pkgconfigdir@
> pkgconfig_DATA = libdrm_nouveau.pc
I don't think this is the best strategy. Having the headers under
_SOURCES already means they'll get distributed. The onl
} else
557 error =
abs(current_freq - freq);
regards,
dan carpenter
--
Download Intel® Parallel Studio Eval
Try the new software tools for y
We should free "params" before returning.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index d355d1d..60595fc 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@
;re clearly using mailman, which has
an archives interface, but they felt the need to implement some dog
slow php forum-like interface over it. Why?
--
Dan
--
Download Intel® Parallel Studio Eval
Try the new software tool
On Mon, Feb 22, 2010 at 7:17 AM, Brian Paul wrote:
> On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson wrote:
>> On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard wrote:
>>> The bash 'cd' command tends to emit random stuff to stdout when the
>>> CDPATH varia
ib to fail.
>
> Signed-off-by: Keith Packard
Congratulations on wading in to mklib, it's not a friendly place. :)
Reviewed-by: Dan Nicholson
--
Download Intel® Parallel Studio Eval
Try the new software to
; if (rdev->ddev->agp->agp_info.aper_size < 32) {
> - dev_warn(rdev->dev, "AGP aperture to small (%dM) "
> + dev_warn(rdev->dev, "AGP aperture to small (%zuM) "
as well.
Jesse, for the glproto check, I think it should be folded into the
DRI2PROTO pkg-config check so that the CFLAGS get pulled in correctly
when building. As it is, we check for the correct glproto, but don't
actua
Thanks for testing. If you see other issues crop
up that prevent parallel building let me know. Mesa has a lot of
custom magic in it's build system, so it gets broken from time to
time.
--
Dan
--
This SF.Net email
ops, just a bug about changing directories and breaking relative paths.
Can you try this new version of the patch? I actually tested it this time,
and I think it does the right thing.
--
Dan
>From 59d8948fe55af2c783d8f7c5554ee44809e78bbd Mon Sep 17 00:00:00 2001
From: Dan Nicholson
Date: Thu, 7
$(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS)
+libmesagallium.a: $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) libmesa.a
@ $(MKLIB) -o mesagallium -static $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS)
# Make archive of gl* API dispatcher functions only
The more correct fix is to have mklib extract in a temporary
directory.
: creating libmesagallium.a
> ranlib: 'libmesagallium.a': No such file
This seems to be the real issue. I have no idea why the file's not
actually being created. It would be nice if mklib actually stopped on
critical errors like these. Can you attach the full build log? It
On Thu, Jan 7, 2010 at 2:40 PM, Sedat Dilek wrote:
> Hi Dan,
>
> [src/mesa/Makefile]
> ...
> -driver_subdirs: libmesa.a libglapi.a
> +driver_subdirs: libmesa.a libmesagallium.a libglapi.a
>
> This one works :-).
>
> $ find mesa/ -name libmesa*
> mesa/s
o rule to make target
> `../../../../../../src/mesa/libmesagallium.a', needed by
> `radeon_dri.so'. Stop.
> ...
>
> Commenting export MAKEFLAGS="-j3" in my build-script is a temporary fix.
> With ccache enabled I have a buil
uct_mutex);
114 dev_priv->mm.suspended = 0;
We do set the dev_priv->mm.suspended here but it's too late.
Not sure the fix though...
regards,
dan carpenter
--
This SF.Net email is sponsor
The check should be >= instead of > or we could potentially
go past the end of the array.
Found by a smatch static checker and compile tested only.
Signed-off-by: Dan Carpenter
--- orig/drivers/gpu/drm/via/via_video.c2009-12-27 13:19:36.0
+0200
+++ devel/drivers/gpu/d
>> to stop having the linux DRM developers stop using a centralized repository
>> for all DRM code. He was quite clearly opposed to it and did not consider
>> it a good choice.
>
> You missing the point as is rnoland. Just because the linux DRM developers
> stopped
I moved the allocation until after the check for (si->totalhigh == 0).
regards,
dan carpenter
Signed-off-by: Dan Carpenter
--- orig/drivers/gpu/drm/ttm/ttm_memory.c 2009-11-28 07:05:54.0
+0200
+++ devel/drivers/gpu/drm/ttm/ttm_memory.c 2009-11-28 07:07:52.0
+0
I moved the fence dereference after the check. rdev is fence->rdev so I
moved the rdev deference as well.
This was found by static analysis so I can't say whether fence is ever
actually null but it's a good thing to do either way.
regards,
dan carpenter
Signed-off-by:
. But if you're in a rush, I think they're safe to
commit.
--
Dan
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day o
(reg) + 4))
> #endif
> +#ifdef readq
> +#define I915_READ64(reg) readq(dev_priv->regs + (reg))
> +#else
> +#define I915_READ64(reg, val) (((uint64_t) readl(dev_priv->regs + (reg))) |
> \
> + ((uint64_t) readl(dev_priv->r
a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b6bedd9..761567f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1278,8 +1278,8 @@ static int intel_crtc_mode_set(struc
B_DIR)/gallium \
> $(MKLIB_OPTIONS) $(XLIB_WINSYS_OBJECTS) \
> - --start-group $(LIBS) --end-group $(GL_LIB_DEPS)
> + -Wl,--start-group $(LIBS) -Wl,--end-group $(GL_LIB_DEPS)
>
>
> depend: $(XLIB_WINSYS_SOURCES)
Thanks for fixing these.
-
this is the right thing to do, but I think it would be
better if we cleaned up the mklib calls to prefix all linker options
with -Wl and then filter those out out of $OBJECTS. Then you catch
single dash or double dash options to t
drm_open_helper() from drm_fops.c had a missing mutex_unlock in a error
path.
This was caught by smatch (http://repo.or.cz/w/smatch.git/). Compile
tested.
regards,
dan carpenter
Signed-off-by: Dan Carpenter
--- orig/drivers/gpu/drm/drm_fops.c 2009-03-26 23:28:21.0 +0300
th --enable-udev is the correct answer, and
> maybe switching this to a WARN so it doesn't blow up.
Hi Dave,
I really think libdrm should have --enable-udev on by default for
linux. The number of people not using udev for managing their devices
is surely in the minority now. What do you thi
On Tue, Dec 9, 2008 at 5:27 PM, Ben Gamari <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-12-09 at 11:19 -0800, Dan Nicholson wrote:
>> I just had a quick scan of the patch, but a couple things jumped out.
>>
>> - The debugfs code should be conditional on CONFIG_DEBUG_FS.
>
nts
- Some of the lowlevel *__*_info functions now only return 0. Could
these be converted to void instead?
--
Dan
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can&#x
Thanks Jesse.
However, I get a compile error about inexistant member hw_status_page in
both i915_dma.c and i915_irq.c. After looking at your kms-7 patchset I
removed both hw_status (which are unused) and changed master_priv for
dev_priv (which points to dev->dev_private).
Dan
diff --gi
ng at the
quirks with `lshal | grep power_management.quirk' (with minor
translation to pm-suspend options).
If you've been running `echo mem > /sys/power/state' the whole time,
then that's a kernel regression.
--
Dan
---
On Tue, Oct 28, 2008 at 9:07 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
>> On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel <[EMAIL PROTECTED]> wrote:
>> > kernel openSUSE 10.3 2.6.22.19-0.1-default
>> &
large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... 64
> ./configure: line 20465: syntax error near unexpected token `PTHREADSTUBS,'
> ./configure: line 20465: `PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)'
Do you h
Anyone have any problems with this?
On Thu, Jun 12, 2008 at 7:12 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> Since the gl pkg-config file doesn't convey any specifics about the
> backend in use, this adds a new pkg-config file for when DRI is in use.
> This can be used by
Since the gl pkg-config file doesn't convey any specifics about the
backend in use, this adds a new pkg-config file for when DRI is in use.
This can be used by the xserver build to determine if the DRI extension
is appropriate.
---
Dan
I don't know if this makes anything a lot bet
dri_sarea.h to the installation a couple days ago.
--
Dan
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse01200
On Feb 13, 2008 6:48 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On Feb 13, 2008 6:40 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> > The glapi source files for the xserver's GLX module are currently
> > generated in the mesa tree and then manually merged int
On Feb 13, 2008 6:40 AM, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> The glapi source files for the xserver's GLX module are currently
> generated in the mesa tree and then manually merged into the the xserver
> tree. This step in the GLX build is error prone as the files
s the mesa build to generate the files in a standard
location in the mesa tree. Likewise, the xserver glx build has the
necessary files symlinked in by symlink-mesa.sh at build time.
I put the files in src/glx/x11 in mesa with the rest of the glx sources.
I'm not sure if this is the best plac
otherwise we'll just get pain in the future..
FWIW, I built mesa_7_0_branch against libdrm-2.3.0 a few times today
and everything went fine. Can't say the same for mesa master against
libdrm-2.3.0, but I believe that's known by you guys (missing
DRM_BO_
m eager to help.
My friend just got a Turion ( Athlon 64 ) laptop with one of these, and
I'm about to get an identical one too.
If any more register dumps are required, or any testing etc (
unfortunately I can't program in C ), then I'm more th
Adam Jackson wrote:
On Monday 19 July 2004 04:20, Daniel Kasak wrote:
>And then there's the issue of driver support when a new xorg X server is
>released that's not binary compatible with ATI's driver.
Where on earth did you hear this? The fglrx drivers work with Xorg
now, and
there's no plans to
Paul Heldens wrote:
On Sun, 2003-07-27 at 23:07, Dan wrote:
Error
The NWN forum says this has to do with impropper initialisation of
opengl subsystem. ? clues someone ?
It's a R250 card with ~3 weeks old trunk snapshot.
Have you applied all the NWN patches? I used to get
Paul Heldens wrote:
glxinfo
...
direct rendering: Yes
...
OpenGL renderer string: Mesa DRI R200 20030328 AGP 1x x86/MMX+/SSE2 TCL
OpenGL version string: 1.3 Mesa 5.0.1
...
When I try to start:
./nwn
Error
The NWN forum says this has to do with impropper initialisation of
opengl su
Radeon to play
movies, but I'd like to change that ...
Dan
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Mo
Alexander Stohr wrote:
In response to the attached list of spam
(18 spam e-mails to dri-devel in only 3 days!)
i have to ask if the dri-devel mailing list
can now be set to subscribers-only policy?
Oh, for the love of God, YES!
I am subscribed to 11 mailing lists, and I get more SPAM from dri
I cvs currently handle UT2k3 well enough to play (I can handle a
bit of weirdness), or should I wait a bit?
Thanks!
Dan
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 --
no other cards...
I've attached iomem and dmesg.
-Dan
On Wed, 2003-02-12 at 23:11, Vladimir Dergachev wrote:
> What does Linux report in /proc/iomem and dmesg ?
> Do you have any other video cards in the system ?
>
> This sounds like PCI resource
a
DRI-related hardware lock, but please also note that the above (current
state of things) happens with 'radeon' even when DRI is not being
loaded!
I would appreciate any ideas that you all might have as to what the
problem may be or where to go next in debugging this.
Regards,
Dan Bur
ct?
However The Register has some good points about what this means for
OpenGL support from hardware manufacturers.
Any comments?
Dan
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Keith Whitwell wrote:
>dan wrote:
>
>>Hi all. I'm trying to get the Mesa-4 branch to compile. If this isn't
>>going to happen now, please excuse me - I will wait. But it's _so_ close...
>>I downloaded the mesa_4_0_branch of Mesa and added it to my host.
Hi all. I'm trying to get the Mesa-4 branch to compile. If this isn't
going to happen now, please excuse me - I will wait. But it's _so_ close...
I downloaded the mesa_4_0_branch of Mesa and added it to my host.conf
'make world' seemed to go OK. At least it got to the end and said 'build
complet
...
Is it possible to get the signal from the BT878 tuner into the Radeon
for hardware mpeg conversion? Maybe a video4linux-loopback-type-thing.
If it IS possible, could someone please point me in the right direction.
And if it's NOT possible, could someone please put me
www.faqs.org/faqs/C-faq/faq/ (item 3.5).
You will never chase a NULL pointer if you code this:
if( p && p->foo ) {}
These expressions are quite idiomatic and show up everywhere e.g. in the
Linux kernel...
Regards,
Dan
___
Dri-devel mailing li
ing to other
users or the kernel...
Dan
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
73 matches
Mail list logo
