On Tue, Sep 15, 2009 at 08:57:28PM +0100, Dave Airlie wrote:
> > Novell did not have to upstream itself, so please stop suggesting that
> > this was Novell doing stuff behind closed doors.
>
> If Greg did this as part of staging I also objected to this on lkml at
> one time.
Huh? I added this c
> Are you saying "Yes, it is right to carry version information in the
> drm.h file"?
No I'm still in no way convinced of this, the fact Thomas doesn't see it
as a requirement either, and *no* other drm driver does it, is all
pointing towards its unnecessary. You seem to think its obvious but we
On Fri, Sep 11, 2009 at 11:00:27PM +0100, Dave Airlie wrote:
>
> Okay incompatible interfaces are not acceptable unless they are major
> version number changes. Minor or patch version changes should not break
> the kernel interface in any way unless its a major security hole being
> solved, and
:37 AM
To: Bruce Chang
Cc: [email protected]; Joseph Chan; [email protected]; Benjamin Pan
(Fremont)
Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by
3D scaling+ACPI
> Hello Luc and Dave:
> Thank you very much for your comment on the UniChrome DR
The attached Xorg.0.log.openchromeok.P4M800 file is the log
> file for the platform of P4M800/CN700 with the Ver 1.5 UniChrome DRM patch.
> The ver1.5 DRM can be init with OpenChrome driver under Ubuntu9.04+Kernel
> updated.
> Se will follow Thomas's suggestion to divide the
Luc Verhaegen wrote:
> On Fri, Sep 11, 2009 at 05:54:34AM +0100, Dave Airlie wrote:
>
>>> What should the canonical source of such versioning information be?
>>>
>>> * This header file defines the interface, and this versioning included
>>> in the same headerfile should then niquely identify th
Bruce, others.
This patch series raises a number of questions.
1) It seems to do a lot more than just fixing a hang issue. See below.
2) There are code cleanups mixed with other stuff, which makes the
patches difficult to read.
Can you supply the code cleanups as separate patches?
As for the ad
> >
> > No thats where you got it wrong, a driver should never *require* version
> > of interface at runtime == version of interface at build time. We
> > rarely make incompatible major number changes in the kernel drivers,
> > (radeon kms being the first in my memory). DRM drivers ship in the
> >
On Fri, Sep 11, 2009 at 05:54:34AM +0100, Dave Airlie wrote:
>
> >
> > What should the canonical source of such versioning information be?
> >
> > * This header file defines the interface, and this versioning included
> > in the same headerfile should then niquely identify this interface.
> > *
Cc: [email protected]; Joseph Chan; [email protected]; Benjamin
Pan (Fremont)
Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by
3D scaling+ACPI
On Fri, Sep 11, 2009 at 05:15:04PM +0800, [email protected] wrote:
> Hello Luc:
> Can I know
On Fri, Sep 11, 2009 at 05:15:04PM +0800, [email protected] wrote:
> Hello Luc:
> Can I know which chipset should I use if I like to verify the DRM
> driver with UniChrome driver in SLED11? Is CX700M platform OK? Or
> CN700?
>
> Thanks and Best Regards
The three devices currently fully
To: Luc Verhaegen
Cc: Bruce Chang; Joseph Chan; [email protected]; Benjamin Pan
(Fremont)
Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by
3D scaling+ACPI
>
> These patches break both free drivers out there. They not only break
> the API,
On Fri, Sep 11, 2009 at 05:48:18AM +0200, Luc Verhaegen wrote:
> On Fri, Sep 11, 2009 at 01:29:21PM +1000, Daniel Stone wrote:
> > On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
> > >
> > > And why did you suddenly start to care, while you pretty much ignored
> > > this dead before
>
> What should the canonical source of such versioning information be?
>
> * This header file defines the interface, and this versioning included
> in the same headerfile should then niquely identify this interface.
> * driver builds against this header and should then require this version
>
On Fri, Sep 11, 2009 at 05:02:47AM +0100, Dave Airlie wrote:
>
> They shouldn't have to. At build time they just require a certain version,
> you shouldn't be building half the features into the driver because it
> has an old _drm.h file. In an ideal world we would have all this stuff
> hidden at
> >
> > Because it probably wasn't noticed, feel free to resend it.
> >
> > I'm not sure why you need a version inside the via_drm.h but I'm
> > willing to accept that the via driver development process is messed up
> > enough to require it. No other driver has needed it.
>
> How do graphics d
On Fri, Sep 11, 2009 at 01:29:21PM +1000, Daniel Stone wrote:
> On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
> >
> > And why did you suddenly start to care, while you pretty much ignored
> > this dead before? Would that be for technical reasons?
>
> Luc,
> When was the last prod
On Fri, Sep 11, 2009 at 04:26:55AM +0100, Dave Airlie wrote:
>
> >
> > As a first answer, without going in depth, as i just returned from my
> > thursday constitutional.
> >
> > Do you have an explanation as to why this commit never made it to the
> > kernel?
>
> Because it probably wasn't no
On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
> On Fri, Sep 11, 2009 at 11:58:01AM +1000, Dave Airlie wrote:
> > Granted if these ioctls are to be used by *chrome to workaround this
> > bug as well, then
> > it would be good if patches to those driver were made available so as
> >
>
> As a first answer, without going in depth, as i just returned from my
> thursday constitutional.
>
> Do you have an explanation as to why this commit never made it to the
> kernel?
Because it probably wasn't noticed, feel free to resend it.
I'm not sure why you need a version inside the
On Fri, Sep 11, 2009 at 11:58:01AM +1000, Dave Airlie wrote:
> >
> > These patches break both free drivers out there. They not only break the
> > API, they also require some of these ioctls to be used correctly for
> > correct initialisation. There seems to be no attempt at working with
> > these t
>
> These patches break both free drivers out there. They not only break the
> API, they also require some of these ioctls to be used correctly for
> correct initialisation. There seems to be no attempt at working with
> these two drivers to fix this specific issue.
I'm looking for the API break b
On Thu, Sep 10, 2009 at 06:19:52PM +0800, [email protected] wrote:
> Hello Sirs:
> The following patch is based on 2.6.31 mainline kernel for the
>system hang issue caused by 3D scaling + ACPI. Please kindly help to
>integrate into mainline kernel.
>
> Thanks and Best Regards
> =
Hello Sirs:
The following patch is based on 2.6.31 mainline kernel for the system hang
issue caused by 3D scaling + ACPI. Please kindly help to integrate into
mainline kernel.
Thanks and Best Regards
=
Bruce C. Chang(張祖明)
VIA Technologies, Inc.
Hello Sirs:
The following patch is based on 2.6.31 mainline kernel for the system hang
issue caused by 3D scaling + ACPI. The modified c files includes
1. via_dmablit.c
2. via_dma.c
3. via_drv.c
4. via_irq.c
5. via_map.c
6. via_mm.c
7. via_verifier.c
Signed-off-by: Bruce Chang
diff -ruN old/
Hello Sirs:
The following patch is based on 2.6.31 mainline kernel for the system hang
issue caused by 3D scaling + ACPI. The modified header files includes
1. via_3d_reg.h
2. via_drv.h
3. via_verifier.h
4. via_drm.h
Signed-off-by: Bruce Chang
diff -ruN old/drivers/gpu/drm/via/via_3d_reg.h
n
Hi,
here's simple patch that fixes offset checking for R300_ZB_ZPASS_ADDR reg
writes.
Maciej Cencora
From 9f07360c523bb942d5b9e8dae15752eefa227c73 Mon Sep 17 00:00:00 2001
From: Maciej Cencora
Date: Thu, 2 Apr 2009 15:09:36 +0200
Subject: [PATCH] drm/radeon: check offsets for R300_ZB_ZPASS_ADDR
Hi Linus,
Can you please pull the 'drm-patches' branch from
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
It only contains one fix for an error printout that was unwise.
Dave.
drivers/char/drm/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(
> Well I already looked at it and thought it's impossible this happens
> ;-). Just for completeness, I tested with the drm patches too which
> didn't change anything.
Unless I missed something in my tests... RADEONDRIRefreshArea() is never
called. I verified that ShadowFBInit() does succeed tho
missed a patch chunk.. should be fixed now ..
Dave.
> >
> > Packet problem?
> >
> > Shawn.
> >
> > On Thursday 16 February 2006 18:25, Benjamin Herrenschmidt wrote:
> > > I finally commited the X driver side of the radeon memory map patches to
ge check (reg=4e28 sz=1)
> [4296305.078000] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
>
> Packet problem?
>
> Shawn.
>
> On Thursday 16 February 2006 18:25, Benjamin Herrenschmidt wrote:
> > I finally commited the X driver side of the radeon memory map patches to
>
acket problem?
Shawn.
On Thursday 16 February 2006 18:25, Benjamin Herrenschmidt wrote:
> I finally commited the X driver side of the radeon memory map patches to
> the xorg CVS. This is the matching DRM patch. David, please commit to
> DRM CVS if you are ok with it.
>
> http://gat
flicker). This is without the drm patch, but I doubt it
makes a difference. To be more exact, the 3d window itself is fine, just
the window borders, background etc. flickers, so it looks like the
refresharea stuff might no longer be working.
I didn't see anything obvious, so this will
avy flicker). This is without the drm patch, but I doubt it
> makes a difference. To be more exact, the 3d window itself is fine, just
> the window borders, background etc. flickers, so it looks like the
> refresharea stuff might no longer be working.
I didn't see anything obvious,
avy flicker). This is without the drm patch, but I doubt it
> makes a difference. To be more exact, the 3d window itself is fine, just
> the window borders, background etc. flickers, so it looks like the
> refresharea stuff might no longer be working.
Ok, will h
Benjamin Herrenschmidt wrote:
I finally commited the X driver side of the radeon memory map patches to
the xorg CVS.
I just noticed this breaks page flipping here (rv250), obviously with
xaa only (heavy flicker). This is without the drm patch, but I doubt it
makes a difference. To be more
I finally commited the X driver side of the radeon memory map patches to
the xorg CVS. This is the matching DRM patch. David, please commit to
DRM CVS if you are ok with it.
http://gate.crashing.org/~benh/radeon-memmap-drm-5.diff
Ben
On Saturday 16 July 2005 12:11 pm, Vladimir Dergachev wrote:
>* the patch includes changes to BSD code as well - these
> need to be checked by people familiar with the platform
You missed a trivial Makefile patch. Other than that, it looks good.
Thanks,
Jung-uk Kim
Index: bsd-core/radeo
Hi all,
Here is a first cut at patch against mainline DRM CVS to add R300
support.
Notes:
* the tarball includes a regular patch and two files that need to
be added to drm/shared-core directory
* the patch includes changes to BSD code as well - these need to
Hi, Dave.
> Hi,
>Okay the VIA DRM people have asked to include it in the kernel, it
> only allows accelerated XvMC for non-root users, and 3d for root users
> (the 3d paths are still not secure)...
>
> The bk tree at
>
> bk://drm.bkbits.net/drm-via
>
> the patch against Linus latest (along
Hi,
Okay the VIA DRM people have asked to include it in the kernel, it
only allows accelerated XvMC for non-root users, and 3d for root users
(the 3d paths are still not secure)...
The bk tree at
bk://drm.bkbits.net/drm-via
the patch against Linus latest (along with some cleanup patches.
Anyone tested it on SMP yet? I think the mga driver is dodgy the others
seem okay but until someone with an MGA/SMP/preempt does it ... I'm not
sure about it..
Dave.
On Sun, 29 Aug 2004, Jon Smirl wrote:
> This change is not going to break a non-SMP system but it may break an
> SMP one. This n
Read my comment at the end where iritations not time should be passed to
this macro. The time we set is allways '1'.
--- Francois Romieu <[EMAIL PROTECTED]> wrote:
> Mike Mestnik <[EMAIL PROTECTED]> :
> [DRM_UDELAY patch]
>
> Does actually a DRM_UDELAY(d) with d > 100 appear somewhere in the
>
Mike Mestnik <[EMAIL PROTECTED]> :
[DRM_UDELAY patch]
Does actually a DRM_UDELAY(d) with d > 100 appear somewhere in the sources ?
--
Ueimor
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
This change is not going to break a non-SMP system but it may break an
SMP one. This needs to be tested on a SMP system before it can be
committed. I thought the reports were that it breaks on SMP.
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> Coulden't cause DRI/DRM to break on my non-SMP radeo
Coulden't cause DRI/DRM to break on my non-SMP radeon preempt system.
Could this be commited, in one form or another?
cvs diff: Diffing .
Index: drm_os_linux.h
===
RCS file: /cvs/dri/drm/linux/drm_os_linux.h,v
retrieving revision 1.2
On Fri, 2004-08-27 at 09:44 +0100, Dave Airlie wrote:
> DRM_INFO("Used old pci detect: framebuffer loaded\n");
Most cards have a framebuffer... this is about framebuffer _devices_. :)
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
On Fri, 27 Aug 2004 09:44:51 +0100 (IST) Dave Airlie wrote:
|
| DRM_INFO("Used old pci detect: framebuffer loaded\n");
|
| we print that... it should be enough I think..
|
| Dave.
| On Fri, 27 Aug 2004, Mike Mestnik wrote:
|
| > Not to be a nit prick, but shoulden't there at least be a warni
DRM_INFO("Used old pci detect: framebuffer loaded\n");
we print that... it should be enough I think..
Dave.
On Fri, 27 Aug 2004, Mike Mestnik wrote:
> Not to be a nit prick, but shoulden't there at least be a warning that
> VesaFB and the DRM are using the same Hardware? Thought this is
> su
Not to be a nit prick, but shoulden't there at least be a warning that
VesaFB and the DRM are using the same Hardware? Thought this is
supported.
"Warning: VesaFB and the DRM are using the\n"
"same Hardware, Thought this is supported."
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> Here is the curr
Looks good to me please feel free to commit to CVS, myself and the lk are
an impasse but I'll try and break it over the weekend :-)
Dave.
On Thu, 26 Aug 2004, Jon Smirl wrote:
> Here is the current version of the patch. As soon as Dave approves it
> will go in.
>
> The problem was a conflict be
Here is the current version of the patch. As soon as Dave approves it
will go in.
The problem was a conflict between VesaFB and DRM. The patch detects
VesaFB and puts DRM in stealth mode.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
New an
I haven't checked xorg cvs, but this patch may be needed there as well.
-- Forwarded message --
From: Lafriks <[EMAIL PROTECTED]>
Date: Thu, 26 Aug 2004 11:54:50 +0300
Subject: drm patch
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Hi,
Wanted to report that without
Hi,
Wanted to report that without this patch my ATI Radeon IGP 345M
didn't have direct rendering support with yesterday mesa-cvs and
dri-cvs. After applying patch I have dri support :) Hope this patch will
be included in cvs soon... it's great ;)
Lafriks
p.s. patch by Jon Smirl:
= linux/d
I wrote:
This appears to work for Linux 2.6; I haven't been able to test it
anywhere
else. However, it should be quite close to no change at all
everywhere else.
Oh, and as I've said before, I can't *really* test it, because I don't
have the cards in question. :-P It builds and the module a
Nathanael Nerode wrote:
Nathanael Nerode wrote:
Yeesh. Attached are the patch and the new files. I couldn't find a good
way to abstract this any further than I already did without breaking
other abstractions; hence the extra files.)
Tell me what sort of changelog you'd like.
This appears to wor
Nathanael Nerode wrote:
Yeesh. Attached are the patch and the new files. I couldn't find a good
way to abstract this any further than I already did without breaking
other abstractions; hence the extra files.)
Tell me what sort of changelog you'd like.
This appears to work for Linux 2.6; I haven'
> you sure you were running top of tree?
Yeah, I did this patch with cvs diff -u in my mach64-0-0-7-branch check out.
That should work right?
I fixed this a while back in
> http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xf
>ree86/os-support/shared/drm/kernel/Attic/mac
> I needed this patch to get the kernel module to insert properly.
>
> Mostly it adds an irq handler for mach64, which I based on the rage128 one.
you sure you were running top of tree? I fixed this a while back in
http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/o
I needed this patch to get the kernel module to insert properly.
Mostly it adds an irq handler for mach64, which I based on the rage128 one.
This patch was made from the xc/xc/programs/Xserver/hw/xfree86/os-support
directory.
Dave, I'll try your new 2D driver tonight. With the one before, I co
://www.redhat.com ftp://people.redhat.com/mharris
-- Forwarded message --
Date: Tue, 9 Jul 2002 09:02:48 -0400
From: Arjan van de Ven <[EMAIL PROTECTED]>
To: Mike A. Harris <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Subject: DRM patch for i810/i830 memor
61 matches
Mail list logo
