Re: CVS Update: drm (branch: trunk)
Felix Kühling wrote: Log message: Add all radeon pci ids known by ddx, but only r350/rv350 and below (new chips may be problematic). Not quite. It's still missing 0x3150 which is the M24 in my notebook. Fglrx identifies it as "MOBILITY RADEON X600 (M24 3150)". It works just fine with the free drivers as an RV350 (Mesa treats it as an RV350 too), though the radeon driver in Xorg seems to think it's an RV380. It thinks it is a rv380 because it IS a rv380 (and that's why I haven't added it) - the rest of the ids can be found in #5413 (for dri and drm it doesn't matter if it's rv350 or rv380 at all, since drm uses its own method of figuring out if it's pcie or agp, and dri doesn't care at all). (AFAIK there are no functional differences between the rv3xx chips, except the bus interface is different, so: rv350, 0.13um manufacturing, AGP, marketing name radeon 9600/9550/9600Pro / M10, M12(?) rv360, 0.13um low-k, AGP, radeon 9600XT / M11(?) rv370, 0.11um, PCI-E, X300[SE]/X550[SE] / M22(?) rv380, 0.13um low-k, PCI-E, X600/X550[SE?] / M24(?) I'm a bit unsure about the mobile names right now...) I added this line to drm_pciids.txt and otherwise used the latest binary snapshot (from today): If you add it manually, you should proably add it as a rv380 (this was not possible before my patch) even though the current code doesn't care. Glad it works for you, but Dave Airlie had some concerns about adding all new ids as it still seems to cause lockups sometimes (the rs400 ones definitely will lockup, with the other ids it's unclear why/when). Roland --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
Am Samstag, den 25.02.2006, 09:51 + schrieb Roland Scheidegger:
> CVSROOT: /cvs/dri
> Module name: drm
> Repository: drm/shared-core/
> Changes by: [EMAIL PROTECTED] 06/02/25 09:51:15
>
> Log message:
> Add all radeon pci ids known by ddx, but only r350/rv350 and below
> (new chips may be problematic).
Not quite. It's still missing 0x3150 which is the M24 in my notebook.
Fglrx identifies it as "MOBILITY RADEON X600 (M24 3150)". It works just
fine with the free drivers as an RV350 (Mesa treats it as an RV350 too),
though the radeon driver in Xorg seems to think it's an RV380.
radeon_probe.c:{ PCI_CHIP_RV380_3150, PCI_CHIP_RV380_3150, RES_SHARED_VGA }
I added this line to drm_pciids.txt and otherwise used the latest binary
snapshot (from today):
--- drm_pciids.txt 25 Feb 2006 09:51:15 - 1.32
+++ drm_pciids.txt 27 Feb 2006 01:37:11 -
@@ -1,4 +1,5 @@
[radeon]
+0x1002 0x3150 CHIP_RV350|CHIP_IS_MOBILITY "ATI Radeon X600 Mobility"
0x1002 0x4136 CHIP_RS100|CHIP_IS_IGP "ATI Radeon RS100 IGP 320"
0x1002 0x4137 CHIP_RS200|CHIP_IS_IGP "ATI Radeon RS200 IGP 340"
0x1002 0x4144 CHIP_R300 "ATI Radeon AD 9500"
Regards,
Felix
> Leave the existing entries for new chips in though. Remove ids not
> known by ddx (secondary ids, non-existant,...). Correct some entries
> (name/family). Make the radeon family enum look more alike the ddx/dri
> versions. See #5413
>
> Modified files:
> drm/shared-core/:
> drm_pciids.txt radeon_cp.c radeon_drv.h
>
> Revision ChangesPath
> 1.32 +42 -53drm/shared-core/drm_pciids.txt
> 1.74 +2 -0 drm/shared-core/radeon_cp.c
> 1.67 +7 -6 drm/shared-core/radeon_drv.h
--
| Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Thu, 2005-11-10 at 11:15 +, Dave Airlie wrote: > > > Log message: > > > Fix cpu_to_le32 same as kernel not sure it is correct for ppc > > > > Looks correct, but as the PCIe GART table is in the framebuffer, the > > card's byte swapping needs to be disabled for this. > > Yes thats what I wanted paulus/benh to check out, I was unsure how the > swappers were setup... so we can probably dump the cpu_to_le32 for the > PCIe GART.. Actually, I think it's easier and cleaner to leave it and just disable the swapping of the card while manipulating the table instead of setting up the swapping of the card according to the endianness of the host CPU. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
> > Log message: > > Fix cpu_to_le32 same as kernel not sure it is correct for ppc > > Looks correct, but as the PCIe GART table is in the framebuffer, the > card's byte swapping needs to be disabled for this. Yes thats what I wanted paulus/benh to check out, I was unsure how the swappers were setup... so we can probably dump the cpu_to_le32 for the PCIe GART.. Dave. > > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Thu, 2005-11-10 at 02:14 -0800, Dave Airlie wrote: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/linux-core/ > Changes by: [EMAIL PROTECTED] 05/11/10 02:14:48 > > Log message: > Fix cpu_to_le32 same as kernel not sure it is correct for ppc Looks correct, but as the PCIe GART table is in the framebuffer, the card's byte swapping needs to be disabled for this. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Tue, 2005-11-08 at 12:25 -0800, Eric Anholt wrote:
> CVSROOT: /cvs/dri
> Module name: drm
> Repository: drm/shared-core/
> Changes by: [EMAIL PROTECTED] 05/11/08 12:25:00
>
> Log message:
> Initial port of savage to FreeBSD for the AGP and !ShadowStatus case. Adds
> drm_mtrr_{add,del} for handling the MTRR setup. Still has a LOR issue with
> DRM_VERIFYAREA_READ/DRM_COPY_FROM_USER_UNCHECKED in savage_bci.c -- this
> won't
^^
that should read savage_state.c. Also, for those playing at home, "LOR"
means "lock order reversal" -- one of a few different ways of getting
the fine-grained locking in FreeBSD wrong.
> work with the fine-grained locking in use, and just doing a single copyin
> to a
> temporary will probably work fine. Also note that the module leaks
> approximately 4 kb on unload.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Changes to xf86drm.c (was Re: CVS Update: drm (branch: trunk))
On Thursday 20 October 2005 15:01, Ian Romanick wrote: > Adam Jackson wrote: > > CVSROOT: /cvs/dri > > Module name: drm > > Repository: drm/libdrm/ > > Changes by: [EMAIL PROTECTED] 05/10/20 10:32:32 > > > > Log message: > > Remove bogus Xlib dependency. > > > > Modified files: > > drm/libdrm/: > > xf86drm.c > > > > Revision ChangesPath > > 1.52 +2 -3 drm/libdrm/xf86drm.c > > This change results in the following code segment. Is that *really* > what you intended? It looks a little nutty to me. I think xf86_ansic.h > already wraps malloc and free, so do we even need _DRM_MALLOC and > _DRM_FREE at all anymore? > > # ifdef DRM_USE_MALLOC > # define _DRM_MALLOC malloc > # define _DRM_FREE free > # else > # define _DRM_MALLOC malloc > # define _DRM_FREE free > # endif Obviously, the more preprocessor statements involved, the better it works. This was admittedly a five-second hack to eliminate a useless (and wrong!) dependency on Xlib. But you're right, the libcwrapper does wrap malloc, so that code is totally useless. Feel free to clean it up if I don't get to it first. - ajax pgpbwdYc1CMmm.pgp Description: PGP signature
Changes to xf86drm.c (was Re: CVS Update: drm (branch: trunk))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Jackson wrote: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/libdrm/ > Changes by: [EMAIL PROTECTED] 05/10/20 10:32:32 > > Log message: > Remove bogus Xlib dependency. > > Modified files: > drm/libdrm/: > xf86drm.c > > Revision ChangesPath > 1.52 +2 -3 drm/libdrm/xf86drm.c This change results in the following code segment. Is that *really* what you intended? It looks a little nutty to me. I think xf86_ansic.h already wraps malloc and free, so do we even need _DRM_MALLOC and _DRM_FREE at all anymore? # ifdef DRM_USE_MALLOC # define _DRM_MALLOC malloc # define _DRM_FREE free # else # define _DRM_MALLOC malloc # define _DRM_FREE free # endif -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDV+lrX1gOwKyEAw8RAtuQAJwLP9TpSkVdGKHrGLhOPZDzX4QAogCfclXK kS9eb4jwmLFhZr8NlFi6tlI= =wGuP -END PGP SIGNATURE- --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Thu, 2005-09-29 at 23:41 -0700, Dave Airlie wrote: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/bsd-core/ > Changes by: [EMAIL PROTECTED] 05/09/29 23:41:10 > > Log message: > Add support to turn writeback off via radeon module option It would be better to use PCI transfers instead, they should be reliable everywhere. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > > Shouldn't the power management be per device instead of global to DRM? > > In fbdev it is per device. If it is per device we don't need the > > global class. > > The class is global, but the call is to the power() function is device > specific. Maybe this is incorrect though for multiple cards, and should > be moved to per device classes. I added ref counting to the global class so it should work now with multiple cards. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > But as you are registering the sysdev in the case of the DRM being loaded > without fbdev, don't you risk the case where the suspend/resume > calls get called twice, once by the PCI driver and then later by sysdev ? That's a problem too, but it is complicated to fix the fbdev error case. I can put code back in that will work most of the time. The problem error cases are when multiple DRM drviers are loaded. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Fri, Jun 24, 2005 at 05:19:30PM -0400, Jon Smirl wrote: > On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 24, 2005 at 12:31:06PM -0700, Jon Smirl wrote: > > > CVSROOT: /cvs/dri > > > Module name: drm > > > Repository: drm/linux-core/ > > > Changes by: [EMAIL PROTECTED] 05/06/24 12:31:06 > > > > > > Log message: > > > More err path clean up for drm_pm > > > Add mandatory sysdev shutdown function > > > > > > Modified files: > > > drm/linux-core/: > > > drm_drv.c drm_pm.c > > > > > > Revision ChangesPath > > > 1.120drm/linux-core/drm_drv.c > > > 1.4 drm/linux-core/drm_pm.c > > > > Jon, > > > > I've noticed you've moved drm_pm_init(). > > > > The reason it was were it was before is that the sysdev approach needn't > > and shouldn't be used when fbdev isn't loaded. > > > > Alan. > > Shouldn't the power management be per device instead of global to DRM? > In fbdev it is per device. If it is per device we don't need the > global class. The class is global, but the call is to the power() function is device specific. Maybe this is incorrect though for multiple cards, and should be moved to per device classes. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Fri, Jun 24, 2005 at 05:07:53PM -0400, Jon Smirl wrote: > On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > > Jon, > > > > I've noticed you've moved drm_pm_init(). > > > > The reason it was were it was before is that the sysdev approach needn't > > and shouldn't be used when fbdev isn't loaded. > > > > Alan. > > It was too complicated gettting all the error paths right. Easier to > just add it all of the time, it doesn't hurt anything. But as you are registering the sysdev in the case of the DRM being loaded without fbdev, don't you risk the case where the suspend/resume calls get called twice, once by the PCI driver and then later by sysdev ? Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > On Fri, Jun 24, 2005 at 12:31:06PM -0700, Jon Smirl wrote: > > CVSROOT: /cvs/dri > > Module name: drm > > Repository: drm/linux-core/ > > Changes by: [EMAIL PROTECTED] 05/06/24 12:31:06 > > > > Log message: > > More err path clean up for drm_pm > > Add mandatory sysdev shutdown function > > > > Modified files: > > drm/linux-core/: > > drm_drv.c drm_pm.c > > > > Revision ChangesPath > > 1.120drm/linux-core/drm_drv.c > > 1.4 drm/linux-core/drm_pm.c > > Jon, > > I've noticed you've moved drm_pm_init(). > > The reason it was were it was before is that the sysdev approach needn't > and shouldn't be used when fbdev isn't loaded. > > Alan. Shouldn't the power management be per device instead of global to DRM? In fbdev it is per device. If it is per device we don't need the global class. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Jon Smirl <[EMAIL PROTECTED]> wrote: > On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > > Jon, > > > > I've noticed you've moved drm_pm_init(). > > > > The reason it was were it was before is that the sysdev approach needn't > > and shouldn't be used when fbdev isn't loaded. > > > > Alan. > > It was too complicated gettting all the error paths right. Easier to > just add it all of the time, it doesn't hurt anything. That's how I ran into the pm problems to begin with. I had a bug in my sarea work that caused an error return and then the pm code started giving me problems. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > Jon, > > I've noticed you've moved drm_pm_init(). > > The reason it was were it was before is that the sysdev approach needn't > and shouldn't be used when fbdev isn't loaded. > > Alan. It was too complicated gettting all the error paths right. Easier to just add it all of the time, it doesn't hurt anything. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Sat, 2005-06-18 at 21:15 -0700, Jon Smirl wrote: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/shared-core/ > Changes by: [EMAIL PROTECTED] 05/06/18 21:15:58 > > Log message: > Remove I2C support from radeon driver. > Same support is available from radeonfb. > > Modified files: > drm/linux-core/: > Makefile.kernel > drm/shared-core/: > radeon_cp.c radeon_drv.h > Removed files: > drm/linux-core/: > radeon_i2c.c radeon_i2c.h Thank you! -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
Adam Jackson wrote: On Monday 28 March 2005 16:21, Thomas Hellstrom wrote: CVSROOT: /cvs/dri Module name: drm Repository: drm/shared-core/ Changes by: [EMAIL PROTECTED] 05/03/28 13:21:42 Log message: Via updates: * New PCI command parser. Moved from via_dma.c to via_verifier.c so functions with similar functionality are close to eachother. * Moved video related functions to via_video.c, which might be extended in the future, as new video functionality is added. * New device-specific generic IRQ IOCTL, similar to the general VBLANK IOCTL, but with support for multiple device IRQ sources and functionality. * Support for Unichrome Pro PM800/CN400 video DMA commands in verifier and PCI parser. * Support for Unichrome Pro PM800/CN400 HQV IRQs in the new generic IRQ IOCTL. * Bumped minor. New version 2.6.0. This broke the build, for at least linux-core: make[2]: *** No rule to make target `/dri/tinderbox/drm/linux-core/via_video.o', needed by `/dri/tinderbox/drm/linux-core/drm.o'. Stop. make[1]: *** [_module_/dri/tinderbox/drm/linux-core] Error 2 Looks like via_video.c just didn't get added. - ajax Hi! sorry for this :(. Fixed now. /Thomas
Re: CVS Update: drm (branch: trunk)
On Monday 28 March 2005 16:21, Thomas Hellstrom wrote: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/shared-core/ > Changes by: [EMAIL PROTECTED] 05/03/28 13:21:42 > > Log message: > Via updates: > * New PCI command parser. Moved from via_dma.c to via_verifier.c so > functions with similar functionality are close to eachother. > * Moved video related functions to via_video.c, which might be extended > in the future, as new video functionality is added. > * New device-specific generic IRQ IOCTL, similar to the general VBLANK > IOCTL, but with support for multiple device IRQ sources and functionality. > * Support for Unichrome Pro PM800/CN400 video DMA commands in verifier and > PCI parser. * Support for Unichrome Pro PM800/CN400 HQV IRQs in the new > generic IRQ IOCTL. * Bumped minor. New version 2.6.0. This broke the build, for at least linux-core: make[2]: *** No rule to make target `/dri/tinderbox/drm/linux-core/via_video.o', needed by `/dri/tinderbox/drm/linux-core/drm.o'. Stop. make[1]: *** [_module_/dri/tinderbox/drm/linux-core] Error 2 Looks like via_video.c just didn't get added. - ajax pgpUcX4say4H6.pgp Description: PGP signature
Re: CVS Update: drm (branch: trunk)
Am Donnerstag, den 20.01.2005, 20:43 -0500 schrieb Adam Jackson: > On Thursday 20 January 2005 18:28, Felix Kühling wrote: > > Am Donnerstag, den 20.01.2005, 11:05 -0800 schrieb Adam Jackson: > > > CVSROOT: /cvs/dri > > > Module name: drm > > > Repository: drm/shared/ > > > Changes by: [EMAIL PROTECTED] 05/01/20 11:05:42 > > > > > > Log message: > > > Add a Savage3D PCI ID > > > > > > Modified files: > > > drm/shared-core/: > > > drm_pciids.txt > > > drm/shared/: > > > drm_pciids.txt > > > > > > Revision ChangesPath > > > 1.13 +1 -0 drm/shared-core/drm_pciids.txt > > > 1.11 +1 -0 drm/shared/drm_pciids.txt > > > > It seems the problem was a typo. I couldn't find the PCI ID 0x8c20 > > anywhere in the X.org or kernel trees while 0x8a20 (the one you added) > > can be found in both. I'm not sure anymore where this list of PCI IDs > > came from originally, but I'm pretty sure 0x8c20 can be safely removed. > > 0x8c21 should also be moved down to 0x8a21, it seems: > > http://pciids.sourceforge.net/iii/?i=5333 > Yeah, I fixed both IDs in CVS. BTW, some ProSavage names in pciids.sf.net are a little questionable or inconsistent. Am I right in assuming that pciids.sf.net is the upstream PCI IDs source used in the Linux kernel? Should I report a bug only there or against the kernel too? > Other savage3d woes to be detailed later... What woes? > > - ajax -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Thursday 20 January 2005 18:28, Felix KÃhling wrote: > Am Donnerstag, den 20.01.2005, 11:05 -0800 schrieb Adam Jackson: > > CVSROOT: /cvs/dri > > Module name: drm > > Repository: drm/shared/ > > Changes by: [EMAIL PROTECTED] 05/01/20 11:05:42 > > > > Log message: > > Add a Savage3D PCI ID > > > > Modified files: > > drm/shared-core/: > > drm_pciids.txt > > drm/shared/: > > drm_pciids.txt > > > > Revision ChangesPath > > 1.13 +1 -0 drm/shared-core/drm_pciids.txt > > 1.11 +1 -0 drm/shared/drm_pciids.txt > > It seems the problem was a typo. I couldn't find the PCI ID 0x8c20 > anywhere in the X.org or kernel trees while 0x8a20 (the one you added) > can be found in both. I'm not sure anymore where this list of PCI IDs > came from originally, but I'm pretty sure 0x8c20 can be safely removed. 0x8c21 should also be moved down to 0x8a21, it seems: http://pciids.sourceforge.net/iii/?i=5333 Other savage3d woes to be detailed later... - ajax pgpnkwZ8DEoic.pgp Description: PGP signature
Re: CVS Update: drm (branch: trunk)
Am Donnerstag, den 20.01.2005, 11:05 -0800 schrieb Adam Jackson: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/shared/ > Changes by: [EMAIL PROTECTED] 05/01/20 11:05:42 > > Log message: > Add a Savage3D PCI ID > > Modified files: > drm/shared-core/: > drm_pciids.txt > drm/shared/: > drm_pciids.txt > > Revision ChangesPath > 1.13 +1 -0 drm/shared-core/drm_pciids.txt > 1.11 +1 -0 drm/shared/drm_pciids.txt It seems the problem was a typo. I couldn't find the PCI ID 0x8c20 anywhere in the X.org or kernel trees while 0x8a20 (the one you added) can be found in both. I'm not sure anymore where this list of PCI IDs came from originally, but I'm pretty sure 0x8c20 can be safely removed. -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Thu, 2004-09-30 at 16:47, Jon Smirl wrote: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/linux-core/ > Changes by: [EMAIL PROTECTED] 04/09/30 16:47:45 > > Log message: > Make the debug memory functions compile for the core model. Has anybody ever used the drm memory debug functions? I would be inclined to see them go away. Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Mon, 13 Sep 2004 02:11:52 +0200, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote: > pci_request_regions() seems to allocate all possible IO and mem regions > defined in the PCI BARs. I understand that putting this code in > drm_probe presents an easy way to get the reservations, although I have > some concerns: > > What if the card/driver in effect doesn't use all regions? Maybe using > pci_request_regions() is the way to go in linux, then please forget > this inquiry. In the (few) BSD kernel PCI driver code I've seen, they > all reserve exactly the range(s) they need, not all ranges covered by > the BARs (though this could of course be the same). > > Wouldn't it be better/cleaner/more work to have each specific driver to > request exactly the regions it wants to use? Reserving everything goes with the one device/one driver mentality. The code only reserves resources for a specific PCI function, it won't reserve resources from the other functions on a multi-function PCI card. For example on the radeon it only reserves the resources of the first device, not the secondary one. What would be an example of a card where reserving everything causes a problem? -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 12.09.2004, at 21:24, Jon Smirl wrote: Log message: Fix error path in probe() to release resources if there is an error. It's not particularly about this very change, more about the general concept. I see you moved the pci_request_regions() to the OS specific part. This is very good, thanks a lot. I'm not experienced with linux kernel code, so please forgive me if I got something wrong. pci_request_regions() seems to allocate all possible IO and mem regions defined in the PCI BARs. I understand that putting this code in drm_probe presents an easy way to get the reservations, although I have some concerns: What if the card/driver in effect doesn't use all regions? Maybe using pci_request_regions() is the way to go in linux, then please forget this inquiry. In the (few) BSD kernel PCI driver code I've seen, they all reserve exactly the range(s) they need, not all ranges covered by the BARs (though this could of course be the same). Wouldn't it be better/cleaner/more work to have each specific driver to request exactly the regions it wants to use? thanks simon -- /"\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News PGP.sig Description: This is a digitally signed message part
