[PATCH] drm/radeon/kms: add initial connector properties
From: Dave Airlie This adds: coherent mode: TMDS coherent mode for atom cards. scaling mode: LVDS scaler mode load detect: DAC load detection, DVI-I, VGA, TV tmds pll: legacy TMDS pll selection tv standard: TV standard selection. TODO: other TV ones? dvi subconnector selection using std prop Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_atombios.c| 15 +- drivers/gpu/drm/radeon/radeon_combios.c | 48 +++-- drivers/gpu/drm/radeon/radeon_connectors.c | 241 --- drivers/gpu/drm/radeon/radeon_display.c | 81 drivers/gpu/drm/radeon/radeon_encoders.c| 10 +- drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 29 +++- drivers/gpu/drm/radeon/radeon_mode.h| 20 ++- 7 files changed, 379 insertions(+), 65 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index a8fb392..aeebae1 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -702,9 +702,8 @@ bool radeon_atom_get_clock_info(struct drm_device *dev) return false; } -struct radeon_encoder_int_tmds *radeon_atombios_get_tmds_info(struct - radeon_encoder - *encoder) +bool radeon_atombios_get_tmds_info(struct radeon_encoder *encoder, + struct radeon_encoder_int_tmds *tmds) { struct drm_device *dev = encoder->base.dev; struct radeon_device *rdev = dev->dev_private; @@ -715,7 +714,6 @@ struct radeon_encoder_int_tmds *radeon_atombios_get_tmds_info(struct uint8_t frev, crev; uint16_t maxfreq; int i; - struct radeon_encoder_int_tmds *tmds = NULL; atom_parse_data_header(mode_info->atom_context, index, NULL, &frev, &crev, &data_offset); @@ -725,12 +723,6 @@ struct radeon_encoder_int_tmds *radeon_atombios_get_tmds_info(struct data_offset); if (tmds_info) { - tmds = - kzalloc(sizeof(struct radeon_encoder_int_tmds), GFP_KERNEL); - - if (!tmds) - return NULL; - maxfreq = le16_to_cpu(tmds_info->usMaxFrequency); for (i = 0; i < 4; i++) { tmds->tmds_pll[i].freq = @@ -756,8 +748,9 @@ struct radeon_encoder_int_tmds *radeon_atombios_get_tmds_info(struct break; } } + return true; } - return tmds; + return false; } union lvds_info { diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index 2a027e0..e2ad8f7 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -994,48 +994,37 @@ static const struct radeon_tmds_pll default_tmds_pll[CHIP_LAST][4] = { {{15000, 0xb0155}, {0x, 0xb01cb}, {0, 0}, {0, 0}}, /* CHIP_RS480 */ }; -static struct radeon_encoder_int_tmds -*radeon_legacy_get_tmds_info_from_table(struct radeon_device *rdev) +bool radeon_legacy_get_tmds_info_from_table(struct radeon_encoder *encoder, + struct radeon_encoder_int_tmds *tmds) { + struct drm_device *dev = encoder->base.dev; + struct radeon_device *rdev = dev->dev_private; int i; - struct radeon_encoder_int_tmds *tmds = NULL; - - tmds = kzalloc(sizeof(struct radeon_encoder_int_tmds), GFP_KERNEL); - - if (!tmds) - return NULL; for (i = 0; i < 4; i++) { tmds->tmds_pll[i].value = - default_tmds_pll[rdev->family][i].value; + default_tmds_pll[rdev->family][i].value; tmds->tmds_pll[i].freq = default_tmds_pll[rdev->family][i].freq; } - return tmds; + return true; } -struct radeon_encoder_int_tmds *radeon_combios_get_tmds_info(struct -radeon_encoder -*encoder) +bool radeon_legacy_get_tmds_info_from_combios(struct radeon_encoder *encoder, + struct radeon_encoder_int_tmds *tmds) { struct drm_device *dev = encoder->base.dev; struct radeon_device *rdev = dev->dev_private; uint16_t tmds_info; int i, n; uint8_t ver; - struct radeon_encoder_int_tmds *tmds = NULL; if (rdev->bios == NULL) - return radeon_legacy_get_tmds_info_from_table(rdev); - + return false; + tmds_info = combios_get_table_offset(dev, COMBIOS_DFP_INFO_TABLE); if (tmds_info) { - tmds = - kzalloc(sizeof(struct ra
Power management in KMS
I'm thinking of organizing power management in KMS. There are my ideas, would like to get your opinions. First of all we need a few different power modes. I think radeonhd has nice states for that: 1) OFF /* DPMS off */ 2) IDLE /* DPMS on, no activity for some time */ 3) SLOW_2D /* Simple 2D activity */ 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default AtomBIOS setting. */ 7) MAX /* Use theoretical chip maximum, maybe beyond default - not selected automatically */ Filling states with engine/memory/voltage values can be grabbed from radeonhd. About setting states I see 3 ways: 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). That function asks 2D engine, 3D engine and DPMS for current state and pickups the best solution. Implementation: We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), radeon_state_of_dpms(). 2) From every part (2D, 3D, DPMS) we call setting function with proper argument. Examples: 3D engine calls radeon_set_pm(FAST_3D); 2D engine calls radeon_set_pm(SLOW_2D); DPMS calls radeon_set_pm(IDLE); DPMS calls radeon_set_pm(WAKE_UP); Implementation: We have to store each element's state in our power manager. If we get "SLOW_2D", but FAST_3D is still running, we can not downclock. 3) We have some state properties in radeon_device and every patch calls generic function radeon_pikcup_pm(). Implementation: We have to create some rdev->state_of_2d, rdev->state_of_3d, rdev->state_of_dpms, and use that in radeon_pikcup_pm(). Personally I'm for third method. Do you have some comments? Preferred method? Suggestions? -- Rafał -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: > I'm thinking of organizing power management in KMS. There are my > ideas, would like to get your opinions. > > First of all we need a few different power modes. I think radeonhd has > nice states for that: > 1) OFF /* DPMS off */ > 2) IDLE /* DPMS on, no activity for some time */ > 3) SLOW_2D /* Simple 2D activity */ > 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ > 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? > indirect rendering only? */ > 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default > AtomBIOS setting. */ > 7) MAX /* Use theoretical chip maximum, maybe beyond default - not > selected automatically */ > > Filling states with engine/memory/voltage values can be grabbed from radeonhd. > > About setting states I see 3 ways: > > 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). > That function asks 2D engine, 3D engine and DPMS for current state and > pickups the best solution. > Implementation: > We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), > radeon_state_of_dpms(). > > 2) From every part (2D, 3D, DPMS) we call setting function with proper > argument. Examples: > 3D engine calls radeon_set_pm(FAST_3D); > 2D engine calls radeon_set_pm(SLOW_2D); > DPMS calls radeon_set_pm(IDLE); > DPMS calls radeon_set_pm(WAKE_UP); > Implementation: > We have to store each element's state in our power manager. If we get > "SLOW_2D", but FAST_3D is still running, we can not downclock. > > 3) We have some state properties in radeon_device and every patch > calls generic function radeon_pikcup_pm(). > Implementation: > We have to create some rdev->state_of_2d, rdev->state_of_3d, > rdev->state_of_dpms, and use that in radeon_pikcup_pm(). > > Personally I'm for third method. > > Do you have some comments? Preferred method? Suggestions? > I have been thinking to PM too, getting hint from userspace is i believe somethings we want, how this hint should be given needs more discussion, i was thinking to either use a score (like 100 give me full power, ...) or using asic specific level more or like what you propose with 2donly, fast2d,3d, ... but which would be asic specific because on some asic some stuff doesn't exist (like 2d doesn't on new hw). >From implementation pov i would like to merge all powermanagement we have now into a single callback function, of course reussing common sub functions accross asics. Basicly i want to shrink down the number of callback as i think it became harder to follow what's happening on a given asic. So it would be somethings like radeon_pm and each asic would have it's own function (well some asic will likely share one like r3xx & r4xx). Cheers, Jerome -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
It's about radeon's KMS and PM of course, sorry for not specifing. W dniu 9 września 2009 10:50 użytkownik Rafał Miłecki napisał: > I'm thinking of organizing power management in KMS. There are my > ideas, would like to get your opinions. > > First of all we need a few different power modes. I think radeonhd has > nice states for that: > 1) OFF /* DPMS off */ > 2) IDLE /* DPMS on, no activity for some time */ > 3) SLOW_2D /* Simple 2D activity */ > 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ > 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? > indirect rendering only? */ > 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default > AtomBIOS setting. */ > 7) MAX /* Use theoretical chip maximum, maybe beyond default - not > selected automatically */ > > Filling states with engine/memory/voltage values can be grabbed from radeonhd. > > About setting states I see 3 ways: > > 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). > That function asks 2D engine, 3D engine and DPMS for current state and > pickups the best solution. > Implementation: > We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), > radeon_state_of_dpms(). > > 2) From every part (2D, 3D, DPMS) we call setting function with proper > argument. Examples: > 3D engine calls radeon_set_pm(FAST_3D); > 2D engine calls radeon_set_pm(SLOW_2D); > DPMS calls radeon_set_pm(IDLE); > DPMS calls radeon_set_pm(WAKE_UP); > Implementation: > We have to store each element's state in our power manager. If we get > "SLOW_2D", but FAST_3D is still running, we can not downclock. > > 3) We have some state properties in radeon_device and every patch > calls generic function radeon_pikcup_pm(). > Implementation: > We have to create some rdev->state_of_2d, rdev->state_of_3d, > rdev->state_of_dpms, and use that in radeon_pikcup_pm(). > > Personally I'm for third method. > > Do you have some comments? Preferred method? Suggestions? Dave linked me to http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/drm-radeon-pm.patch?revision=1.2.6.2&view=markup This patch uses timer to check if nothing has been rendered for some time. That would be quite close to first solution. -- Rafał Miłecki -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
2009/9/9 Jerome Glisse > On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: > > I'm thinking of organizing power management in KMS. There are my > > ideas, would like to get your opinions. > > > > First of all we need a few different power modes. I think radeonhd has > > nice states for that: > > 1) OFF /* DPMS off */ > > 2) IDLE /* DPMS on, no activity for some time */ > > 3) SLOW_2D /* Simple 2D activity */ > > 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ > > 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? > > indirect rendering only? */ > > 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default > > AtomBIOS setting. */ > > 7) MAX /* Use theoretical chip maximum, maybe beyond default - not > > selected automatically */ > > > > Filling states with engine/memory/voltage values can be grabbed from > radeonhd. > > > > About setting states I see 3 ways: > > > > 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). > > That function asks 2D engine, 3D engine and DPMS for current state and > > pickups the best solution. > > Implementation: > > We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), > > radeon_state_of_dpms(). > > > > 2) From every part (2D, 3D, DPMS) we call setting function with proper > > argument. Examples: > > 3D engine calls radeon_set_pm(FAST_3D); > > 2D engine calls radeon_set_pm(SLOW_2D); > > DPMS calls radeon_set_pm(IDLE); > > DPMS calls radeon_set_pm(WAKE_UP); > > Implementation: > > We have to store each element's state in our power manager. If we get > > "SLOW_2D", but FAST_3D is still running, we can not downclock. > > > > 3) We have some state properties in radeon_device and every patch > > calls generic function radeon_pikcup_pm(). > > Implementation: > > We have to create some rdev->state_of_2d, rdev->state_of_3d, > > rdev->state_of_dpms, and use that in radeon_pikcup_pm(). > > > > Personally I'm for third method. > > > > Do you have some comments? Preferred method? Suggestions? > > > > I have been thinking to PM too, getting hint from userspace is i believe > somethings we want, how this hint should be given needs more discussion, > i was thinking to either use a score (like 100 give me full power, ...) > or using asic specific level more or like what you propose with 2donly, > fast2d,3d, ... but which would be asic specific because on some asic > some stuff doesn't exist (like 2d doesn't on new hw). > > >From implementation pov i would like to merge all powermanagement we > have now into a single callback function, of course reussing common > sub functions accross asics. Basicly i want to shrink down the number > of callback as i think it became harder to follow what's happening on > a given asic. So it would be somethings like radeon_pm and each asic > would have it's own function (well some asic will likely share one > like r3xx & r4xx). > > Cheers, > Jerome > > This will need separate hint for PCIE-lanes, memory and engine because some applications might transfer large amount of data with very little processing (xv?) while some applications could do complex stuff in GPU and use very little memory bandwidth (OpenCL?). -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
W dniu 9 września 2009 11:10 użytkownik Jerome Glisse napisał: > I have been thinking to PM too, getting hint from userspace is i believe > somethings we want, how this hint should be given needs more discussion, > i was thinking to either use a score (like 100 give me full power, ...) > or using asic specific level more or like what you propose with 2donly, > fast2d,3d, ... but which would be asic specific because on some asic > some stuff doesn't exist (like 2d doesn't on new hw). You should really clarify this :) I thought you want to have whole PM in KMS controlled by user space app. Hope I can quote you selecting just 3 sentences: mjg59: i am not saying that kernel should not do thing on it's own kernel should powerdown when it has good reasons to do so i am all for saving power So if I understand you correctly, you just want to have alternative way of forcing some low power mode (from user space app). I think it's totally fine, just as long as it's additional method on control and base power control is in KMS. -- Rafał -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
W dniu 9 września 2009 11:10 użytkownik Jerome Glisse napisał: > I have been thinking to PM too, getting hint from userspace is i believe > somethings we want, how this hint should be given needs more discussion, > i was thinking to either use a score (like 100 give me full power, ...) > or using asic specific level more or like what you propose with 2donly, > fast2d,3d, ... but which would be asic specific because on some asic > some stuff doesn't exist (like 2d doesn't on new hw). It's more about power level, not reference to used hardware blocks. I get it like "Use power level that is enough for rendering 2D". So it's still valid for r6xx/r7xx. -- Rafał -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23812] New: links2 triggers a lockdep trace in drm-next with KMS on
http://bugs.freedesktop.org/show_bug.cgi?id=23812 Summary: links2 triggers a lockdep trace in drm-next with KMS on Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: astralst...@gen2.org Created an attachment (id=29350) --> (http://bugs.freedesktop.org/attachment.cgi?id=29350) Lockdep trace Links2 (the text/low-graphic browser) with framebuffer support on triggers the attached lockdep trace when exiting. Both KMS and links2 work correctly afterwards. KMS is enabled and working, drm-next commit cecc6b63a5de547a345c491bb4c18c01a15984a4 The card is RV670, Mobility Radeon HD3850. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23017] Direct color dri windowed visual is causing causing full black screen
http://bugs.freedesktop.org/show_bug.cgi?id=23017 --- Comment #11 from Stefan Dirsch 2009-09-09 08:09:40 PST --- The glxgears issue is fixed in Mesa 7.5.1. Not sure if by accident or by intention though. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23337] glxgears blanks the screen when window is focused (regression Mesa 7.4.4 --> 7.5)
http://bugs.freedesktop.org/show_bug.cgi?id=23337 --- Comment #4 from Stefan Dirsch 2009-09-09 08:09:35 PST --- The issue is fixed in Mesa 7.5.1. Not sure if by accident or by intention though. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
For the most part, the driver should just implement sensible power management itself. We don't want users to have to define complex power management policies. In almost every case, if the user triggers a graphics operation then they want it to complete as quickly as possible. Autmatically upclocking in response to this is pretty easy on most hardware. The only real problem comes with reclocking RAM on a multi-head system. This has to be done during the vblank interval to avoid data corruption, but syncing the vblanks on both displays may well be difficult or impossible. There's a small number of cases where we can't reconfigure a power management state on the fly - the number of PCIe lanes is an example of this. Changing it simply takes too long, and we drop several frames in the process. The right kind of interface for that does require some thought. -- Matthew Garrett | mj...@srcf.ucam.org -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #7 from Brian Paul 2009-09-09 08:43:00 PST --- Created an attachment (id=29352) --> (http://bugs.freedesktop.org/attachment.cgi?id=29352) another patch for meta.c (IndexOffset/Bias check) Can you see if this patch helps with the glDrawPixels(GL_STENCIL_INDEX) cases? Also, the -v 2 output would be helpful. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: > 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? > indirect rendering only? */ FWIW: No, compiz (and any other GLX compositing manager, for that matter) works with direct rendering with DRI2. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] New: 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816 Summary: 32bit mesa on 64bit os won't load r600_dri.so due to bad magic Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: kdeko...@yahoo.com First the working case. Using 64 bit Fedora 11 Kernel radeon kernel modules from agd5f's r600 branch libdrm from git compile without experimental apis in both 32bit and 64bit binaries mesa from git in both 32bit and 64bit binaries ddx from git With this setup I can get 64bit and 32bit hardware accelerated 3d, most things work well. I tried to do the same thing with the following drm-next kernel 2.6.31-rc9 libdrm from git compiled with experimentals api in both 32bit and 64bin binaries mesa from git in both 32bit and 64bit binaries ddx from git mesa in 64bit mode works well. applications run accelerated with no problem. mesa in 32bit mode fails LIBGL_DEBUG=verbose gears libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so libGL error: failed to get magic libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so file /usr/lib/dri/r600_dri.so /usr/lib/dri/r600_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped also I see in my dmesg ioctl32(gears:4095): Unknown cmd fd(4) cmd(80046402){t:'d';sz:4} arg(ff8ea6cc) on /dev/dri/card0 Looks to me like the 32bit mesa is not properly getting the cmd to the 64bit drm in the kernel. Since I am in Fedora, I am not running 32bit apps in a chroot. 32bit libs are in /usr/lib and 64bit libs are in /usr/lib64. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23017] Direct color dri windowed visual is causing causing full black screen
http://bugs.freedesktop.org/show_bug.cgi?id=23017 --- Comment #12 from Michel Dänzer 2009-09-09 09:16:08 PST --- (In reply to comment #11) > The glxgears issue is fixed in Mesa 7.5.1. Not sure if by accident or by > intention though. See the reference to bug 23337 in comment #10. :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23785] NWN crashes after loading or starting game
http://bugs.freedesktop.org/show_bug.cgi?id=23785 --- Comment #2 from Nicolai Hähnle 2009-09-09 09:18:37 PST --- Thank you for the report. Could you try running with the environment variable RADEON_DEBUG=vert set? Warning, this will produce a huge amount of output. Only the last lines before the crash are interesting (they will contain a dump of the vertex program which we attempted to compile). I don't have NWN here, and it would make it easier to understand what's going wrong. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23337] glxgears blanks the screen when window is focused (regression Mesa 7.4.4 --> 7.5)
http://bugs.freedesktop.org/show_bug.cgi?id=23337 Michel Dänzer changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #5 from Michel Dänzer 2009-09-09 09:18:03 PST --- Not a duplicate, fixed in 7.5.1 and Git mesa_7_4_branch. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
W dniu 9 września 2009 17:57 użytkownik Michel Dänzer napisał: > On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: >> 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? >> indirect rendering only? */ > > FWIW: No, compiz (and any other GLX compositing manager, for that > matter) works with direct rendering with DRI2. That are comments from radeonhd driver, which doesn't support DRI2. I hope we will find some way to determine if we need speed for SLOW of FAST 3D. -- Rafał -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
I also think it should mostly be handled in the driver. About the only knobs we may want to enable userspace to mess with are say 3 power modes: low power (battery mode), default, and maybe a high power mode later on. The high power mode may require thermal monitoring support depending on the chip. GPM (and whatever kde uses) or the user can then change the mode on the fly in reaction to events like AC -> DC, etc.; much like what is done for backlights now. The driver itself would then handle the power state transitions based on the selection from userspace. For example, if the low power state was selected, the driver would limit the max clocks and voltages based on that. As Matthew mentioned, the driver would adjust the engine clock on the fly when commands come in, and then downclock again after a certain period. There would also be an idle mode where everything would be down to the minimum (i.e., crtcs off, engines idle, etc.). In that case we could drop the clocks and pcie lanes to the lowest level. I don't think there is really any need for 2D vs. 3D mode as most of the useful "2D" accel uses the 3D engine anyway. So whenever we see commands come in, we should treat it the same; upclock to the limit imposed by the currently selected mode. The power tables in the bios could be used for setting limits and usable combinations (the hw can be picky about what combinations of sclks and mclks modes it likes) and for getting the idle (and possibly suspend) power modes. Mem clocks and pcie lanes are trickier since you need to make sure you have enough bandwidth available to supply all currently active clients (displays, 2D, 3D, overlays, etc.). It probably makes sense to only adjust them during a mode set or a forced power state or the idle state. These require some more thought. Driver hints may be useful here. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23785] NWN crashes after loading or starting game
http://bugs.freedesktop.org/show_bug.cgi?id=23785 --- Comment #3 from Nicolai Hähnle 2009-09-09 11:00:18 PST --- Created an attachment (id=29354) --> (http://bugs.freedesktop.org/attachment.cgi?id=29354) Potential patch? Okay, after actually looking at what the line of code actually does, here's a potential (untested) patch that could fix it. Might be just an extremely silly bug after all. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: wait for cp idle before stopping it.
If we stop CP and that it's still processing thing GPU hang might happen, this patch wait for CP idle (the wait can timeout) so we can avoid shutting down CP at bad time. This is especialy usefull when reseting the GPU as it seems GPU reset fails to properly reset CP when the CP wasn't stop after being idle. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/r100.c | 18 drivers/gpu/drm/radeon/r100d.h | 60 2 files changed, 78 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 4ceb675..4dd5ca5 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -490,6 +490,21 @@ int r100_copy_blit(struct radeon_device *rdev, /* * CP */ +static int r100_cp_wait_for_idle(struct radeon_device *rdev) +{ + unsigned i; + u32 tmp; + + for (i = 0; i < rdev->usec_timeout; i++) { + tmp = RREG32(R_000E40_RBBM_STATUS); + if (!G_000E40_CP_CMDSTRM_BUSY(tmp)) { + return 0; + } + udelay(1); + } + return -1; +} + void r100_ring_start(struct radeon_device *rdev) { int r; @@ -718,6 +733,9 @@ int r100_cp_init(struct radeon_device *rdev, unsigned ring_size) void r100_cp_fini(struct radeon_device *rdev) { + if (r100_cp_wait_for_idle(rdev)) { + DRM_ERROR("Wait for CP idle timeout, shutting down CP.\n"); + } /* Disable ring */ r100_cp_disable(rdev); radeon_ring_fini(rdev); diff --git a/drivers/gpu/drm/radeon/r100d.h b/drivers/gpu/drm/radeon/r100d.h index 6da7d92..1d951ab 100644 --- a/drivers/gpu/drm/radeon/r100d.h +++ b/drivers/gpu/drm/radeon/r100d.h @@ -73,4 +73,64 @@ #define CP_PACKET0_GET_ONE_REG_WR(h) (((h) >> 15) & 1) #define CP_PACKET3_GET_OPCODE(h) (((h) >> 8) & 0xFF) +/* Registers */ +#define R_000E40_RBBM_STATUS 0x000E40 +#define S_000E40_CMDFIFO_AVAIL(x)(((x) & 0x7F) << 0) +#define G_000E40_CMDFIFO_AVAIL(x)(((x) >> 0) & 0x7F) +#define C_000E40_CMDFIFO_AVAIL 0xFF80 +#define S_000E40_HIRQ_ON_RBB(x) (((x) & 0x1) << 8) +#define G_000E40_HIRQ_ON_RBB(x) (((x) >> 8) & 0x1) +#define C_000E40_HIRQ_ON_RBB 0xFEFF +#define S_000E40_CPRQ_ON_RBB(x) (((x) & 0x1) << 9) +#define G_000E40_CPRQ_ON_RBB(x) (((x) >> 9) & 0x1) +#define C_000E40_CPRQ_ON_RBB 0xFDFF +#define S_000E40_CFRQ_ON_RBB(x) (((x) & 0x1) << 10) +#define G_000E40_CFRQ_ON_RBB(x) (((x) >> 10) & 0x1) +#define C_000E40_CFRQ_ON_RBB 0xFBFF +#define S_000E40_HIRQ_IN_RTBUF(x)(((x) & 0x1) << 11) +#define G_000E40_HIRQ_IN_RTBUF(x)(((x) >> 11) & 0x1) +#define C_000E40_HIRQ_IN_RTBUF 0xF7FF +#define S_000E40_CPRQ_IN_RTBUF(x)(((x) & 0x1) << 12) +#define G_000E40_CPRQ_IN_RTBUF(x)(((x) >> 12) & 0x1) +#define C_000E40_CPRQ_IN_RTBUF 0xEFFF +#define S_000E40_CFRQ_IN_RTBUF(x)(((x) & 0x1) << 13) +#define G_000E40_CFRQ_IN_RTBUF(x)(((x) >> 13) & 0x1) +#define C_000E40_CFRQ_IN_RTBUF 0xDFFF +#define S_000E40_CF_PIPE_BUSY(x) (((x) & 0x1) << 14) +#define G_000E40_CF_PIPE_BUSY(x) (((x) >> 14) & 0x1) +#define C_000E40_CF_PIPE_BUSY0xBFFF +#define S_000E40_ENG_EV_BUSY(x) (((x) & 0x1) << 15) +#define G_000E40_ENG_EV_BUSY(x) (((x) >> 15) & 0x1) +#define C_000E40_ENG_EV_BUSY 0x7FFF +#define S_000E40_CP_CMDSTRM_BUSY(x) (((x) & 0x1) << 16) +#define G_000E40_CP_CMDSTRM_BUSY(x) (((x) >> 16) & 0x1) +#define C_000E40_CP_CMDSTRM_BUSY 0xFFFE +#define S_000E40_E2_BUSY(x) (((x) & 0x1) << 17) +#define G_000E40_E2_BUSY(x) (((x) >> 17) & 0x1) +#define C_000E40_E2_BUSY 0xFFFD +#define S_000E40_RB2D_BUSY(x)(((x) & 0x1) << 18) +#define G_000E40_RB2D_BUSY(x)(((x) >> 18) & 0x1) +#define C_000E40_RB2D_BUSY 0xFFFB +#define S_000E40_RB3D_BUSY(x)(((x) & 0x1) << 19) +#define G_000E40_RB3D_BUSY(x)(((x) >> 19) & 0x1) +#define C_000E40_RB3D_BUSY 0xFFF7 +#define S_000E40_SE_BUSY(x) (((x) & 0x1) << 20) +#define G_000E40_SE_BUSY(x) (((x) >> 20) & 0x1) +#define C_000E40_SE_
[PATCH] drm/radeon/kms: R3XX/R4XX AGP asic use PCI GART not PCIE GART
R3XX/R4XX AGP asic use the old PCI GART block, not the new PCIE GART. Make sure we pick the right GART when disabling AGP. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/r300.c |6 ++ drivers/gpu/drm/radeon/r420.c |9 +++-- drivers/gpu/drm/radeon/radeon.h|4 drivers/gpu/drm/radeon/radeon_device.c |5 + 4 files changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index a5f82f7..9c17b78 100644 --- a/drivers/gpu/drm/radeon/r300.c +++ b/drivers/gpu/drm/radeon/r300.c @@ -181,6 +181,12 @@ int r300_gart_enable(struct radeon_device *rdev) rdev->asic->gart_set_page = &rv370_pcie_gart_set_page; return rv370_pcie_gart_enable(rdev); } + if (rdev->flags & RADEON_IS_PCI) { + rdev->asic->gart_disable = &r100_pci_gart_disable; + rdev->asic->gart_tlb_flush = &r100_pci_gart_tlb_flush; + rdev->asic->gart_set_page = &r100_pci_gart_set_page; + return r100_pci_gart_enable(rdev); + } return r100_pci_gart_enable(rdev); } diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c index 97426a6..029cee2 100644 --- a/drivers/gpu/drm/radeon/r420.c +++ b/drivers/gpu/drm/radeon/r420.c @@ -100,8 +100,13 @@ int r420_mc_init(struct radeon_device *rdev) void r420_mc_fini(struct radeon_device *rdev) { - rv370_pcie_gart_disable(rdev); - radeon_gart_table_vram_free(rdev); + if (rdev->flags & RADEON_IS_PCIE) { + rv370_pcie_gart_disable(rdev); + radeon_gart_table_vram_free(rdev); + } else { + r100_pci_gart_disable(rdev); + radeon_gart_table_ram_free(rdev); + } radeon_gart_fini(rdev); } diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 24574bc..fe86b20 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -935,5 +935,9 @@ static inline void radeon_ring_write(struct radeon_device *rdev, uint32_t v) /* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */ void r100_cp_disable(struct radeon_device *rdev); +void r100_pci_gart_disable(struct radeon_device *rdev); +int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr); +int r100_pci_gart_enable(struct radeon_device *rdev); +void r100_pci_gart_tlb_flush(struct radeon_device *rdev); #endif diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index f2469c5..da8646a 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -499,10 +499,7 @@ int radeon_device_init(struct radeon_device *rdev, if (radeon_agpmode == -1) { rdev->flags &= ~RADEON_IS_AGP; - if (rdev->family > CHIP_RV515 || - rdev->family == CHIP_RV380 || - rdev->family == CHIP_RV410 || - rdev->family == CHIP_R423) { + if (rdev->family >= CHIP_RV515) { DRM_INFO("Forcing AGP to PCIE mode\n"); rdev->flags |= RADEON_IS_PCIE; } else { -- 1.6.4.1 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: add R4XX mc register access helper.
Atombios will use the mc register access helper and R4XX hw have a bigger mc range than R3XX so add R4XX specific mc register access helper. igned-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/r420.c | 17 drivers/gpu/drm/radeon/r420d.h | 43 drivers/gpu/drm/radeon/radeon.h|4 +++ drivers/gpu/drm/radeon/radeon_device.c |4 +++ 4 files changed, 68 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/radeon/r420d.h diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c index 029cee2..551d699 100644 --- a/drivers/gpu/drm/radeon/r420.c +++ b/drivers/gpu/drm/radeon/r420.c @@ -29,6 +29,7 @@ #include "drmP.h" #include "radeon_reg.h" #include "radeon.h" +#include "r420d.h" /* r420,r423,rv410 depends on : */ void r100_pci_gart_disable(struct radeon_device *rdev); @@ -237,3 +238,19 @@ int r420_debugfs_pipes_info_init(struct radeon_device *rdev) return 0; #endif } + +u32 r420_mc_rreg(struct radeon_device *rdev, u32 reg) +{ + u32 r; + + WREG32(R_0001F8_MC_IND_INDEX, S_0001F8_MC_IND_ADDR(reg)); + r = RREG32(R_0001FC_MC_IND_DATA); + return r; +} + +void r420_mc_wreg(struct radeon_device *rdev, u32 reg, u32 v) +{ + WREG32(R_0001F8_MC_IND_INDEX, S_0001F8_MC_IND_ADDR(reg) | + S_0001F8_MC_IND_WR_EN(1)); + WREG32(R_0001FC_MC_IND_DATA, v); +} diff --git a/drivers/gpu/drm/radeon/r420d.h b/drivers/gpu/drm/radeon/r420d.h new file mode 100644 index 000..8b946c1 --- /dev/null +++ b/drivers/gpu/drm/radeon/r420d.h @@ -0,0 +1,43 @@ +/* + * Copyright 2008 Advanced Micro Devices, Inc. + * Copyright 2008 Red Hat Inc. + * Copyright 2009 Jerome Glisse. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: Dave Airlie + * Alex Deucher + * Jerome Glisse + */ +#ifndef R420D_H +#define R420D_H + +#define R_0001F8_MC_IND_INDEX0x0001F8 +#define S_0001F8_MC_IND_ADDR(x) (((x) & 0x7F) << 0) +#define G_0001F8_MC_IND_ADDR(x) (((x) >> 0) & 0x7F) +#define C_0001F8_MC_IND_ADDR 0xFF80 +#define S_0001F8_MC_IND_WR_EN(x) (((x) & 0x1) << 8) +#define G_0001F8_MC_IND_WR_EN(x) (((x) >> 8) & 0x1) +#define C_0001F8_MC_IND_WR_EN0xFEFF +#define R_0001FC_MC_IND_DATA 0x0001FC +#define S_0001FC_MC_IND_DATA(x) (((x) & 0x) << 0) +#define G_0001FC_MC_IND_DATA(x) (((x) >> 0) & 0x) +#define C_0001FC_MC_IND_DATA 0x + +#endif diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index fe86b20..868d7c1 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -940,4 +940,8 @@ int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr); int r100_pci_gart_enable(struct radeon_device *rdev); void r100_pci_gart_tlb_flush(struct radeon_device *rdev); +/* r420,r423,rv410 */ +u32 r420_mc_rreg(struct radeon_device *rdev, u32 reg); +void r420_mc_wreg(struct radeon_device *rdev, u32 reg, u32 v); + #endif diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index da8646a..d1e356b 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -266,6 +266,10 @@ void radeon_register_accessor_init(struct radeon_device *rdev) rdev->pll_rreg = &r100_pll_rreg; rdev->pll_wreg = &r100_pll_wreg; } + if (rdev->family >= CHIP_R420) { + rdev->mc_rreg = &r420_mc_rreg; + rdev->mc_wreg = &r420_mc_wreg; + } if (rdev->family >= CHIP_RV515) { rdev->mc_rreg = &rv515_mc_rreg; rdev->mc_wreg = &rv51
[PATCH] drm/radeon/kms: call r100_cp_disable rather than duplicating code.
r100_cp_fini was duplicating code of r100_cp_disable, call r100_cp_disable instead. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/r100.c |3 +-- drivers/gpu/drm/radeon/radeon.h |3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 36d0ba2..4ceb675 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -719,8 +719,7 @@ int r100_cp_init(struct radeon_device *rdev, unsigned ring_size) void r100_cp_fini(struct radeon_device *rdev) { /* Disable ring */ - rdev->cp.ready = false; - WREG32(RADEON_CP_CSQ_CNTL, 0); + r100_cp_disable(rdev); radeon_ring_fini(rdev); DRM_INFO("radeon: cp finalized\n"); } diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 3299733..24574bc 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -933,4 +933,7 @@ static inline void radeon_ring_write(struct radeon_device *rdev, uint32_t v) #define radeon_clear_surface_reg(rdev, r) ((rdev)->asic->clear_surface_reg((rdev), (r))) #define radeon_bandwidth_update(rdev) (rdev)->asic->bandwidth_update((rdev)) +/* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */ +void r100_cp_disable(struct radeon_device *rdev); + #endif -- 1.6.4.1 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Don't try to process irq when we are unloading
If module is being unloaded we should not try to handle irq especialy we should not call into drm helper or we could hard hang the computer free_irq will call the irq handler to make sure we behave properly. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/r100.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 5708c07..36d0ba2 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -319,6 +319,9 @@ int r100_irq_process(struct radeon_device *rdev) if (!status) { return IRQ_NONE; } + if (rdev->shutdown) { + return IRQ_NONE; + } while (status) { /* SW interrupt */ if (status & RADEON_SW_INT_TEST) { -- 1.6.4.1 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: R3XX/R4XX AGP asic use PCI GART not PCIE GART
On Wed, Sep 9, 2009 at 4:24 PM, Jerome Glisse wrote: > R3XX/R4XX AGP asic use the old PCI GART block, not the new PCIE GART. > Make sure we pick the right GART when disabling AGP. > Just to clarify which gart block is on what r3xx/r4xx asic; If the card is chip family CHIP_R300, CHIP_R350, CHIP_RV350, or CHIP_R420, it uses the AIC PCI gart. If the chip family is CHIP_RV380, CHIP_R423, or CHIP_RV410, then it uses PCIE gart. Alex > Signed-off-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/r300.c | 6 ++ > drivers/gpu/drm/radeon/r420.c | 9 +++-- > drivers/gpu/drm/radeon/radeon.h | 4 > drivers/gpu/drm/radeon/radeon_device.c | 5 + > 4 files changed, 18 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c > index a5f82f7..9c17b78 100644 > --- a/drivers/gpu/drm/radeon/r300.c > +++ b/drivers/gpu/drm/radeon/r300.c > @@ -181,6 +181,12 @@ int r300_gart_enable(struct radeon_device *rdev) > rdev->asic->gart_set_page = &rv370_pcie_gart_set_page; > return rv370_pcie_gart_enable(rdev); > } > + if (rdev->flags & RADEON_IS_PCI) { > + rdev->asic->gart_disable = &r100_pci_gart_disable; > + rdev->asic->gart_tlb_flush = &r100_pci_gart_tlb_flush; > + rdev->asic->gart_set_page = &r100_pci_gart_set_page; > + return r100_pci_gart_enable(rdev); > + } > return r100_pci_gart_enable(rdev); > } > > diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c > index 97426a6..029cee2 100644 > --- a/drivers/gpu/drm/radeon/r420.c > +++ b/drivers/gpu/drm/radeon/r420.c > @@ -100,8 +100,13 @@ int r420_mc_init(struct radeon_device *rdev) > > void r420_mc_fini(struct radeon_device *rdev) > { > - rv370_pcie_gart_disable(rdev); > - radeon_gart_table_vram_free(rdev); > + if (rdev->flags & RADEON_IS_PCIE) { > + rv370_pcie_gart_disable(rdev); > + radeon_gart_table_vram_free(rdev); > + } else { > + r100_pci_gart_disable(rdev); > + radeon_gart_table_ram_free(rdev); > + } > radeon_gart_fini(rdev); > } > > diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h > index 24574bc..fe86b20 100644 > --- a/drivers/gpu/drm/radeon/radeon.h > +++ b/drivers/gpu/drm/radeon/radeon.h > @@ -935,5 +935,9 @@ static inline void radeon_ring_write(struct radeon_device > *rdev, uint32_t v) > > /* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */ > void r100_cp_disable(struct radeon_device *rdev); > +void r100_pci_gart_disable(struct radeon_device *rdev); > +int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr); > +int r100_pci_gart_enable(struct radeon_device *rdev); > +void r100_pci_gart_tlb_flush(struct radeon_device *rdev); > > #endif > diff --git a/drivers/gpu/drm/radeon/radeon_device.c > b/drivers/gpu/drm/radeon/radeon_device.c > index f2469c5..da8646a 100644 > --- a/drivers/gpu/drm/radeon/radeon_device.c > +++ b/drivers/gpu/drm/radeon/radeon_device.c > @@ -499,10 +499,7 @@ int radeon_device_init(struct radeon_device *rdev, > > if (radeon_agpmode == -1) { > rdev->flags &= ~RADEON_IS_AGP; > - if (rdev->family > CHIP_RV515 || > - rdev->family == CHIP_RV380 || > - rdev->family == CHIP_RV410 || > - rdev->family == CHIP_R423) { > + if (rdev->family >= CHIP_RV515) { > DRM_INFO("Forcing AGP to PCIE mode\n"); > rdev->flags |= RADEON_IS_PCIE; > } else { > -- > 1.6.4.1 > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23816] 32bit mesa on 64bit os won't load r600_dri.so due to bad magic
http://bugs.freedesktop.org/show_bug.cgi?id=23816 --- Comment #1 from Michel Dänzer 2009-09-09 15:12:05 PST --- This is probably a duplicate of bug 22271. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23785] NWN crashes after loading or starting game
http://bugs.freedesktop.org/show_bug.cgi?id=23785 --- Comment #4 from Krzysztof A. Sobiecki 2009-09-09 16:05:31 PST --- Created an attachment (id=29357) --> (http://bugs.freedesktop.org/attachment.cgi?id=29357) Output of RADEON_DEBUG=all for unpatched Mesa I might say that patch fixes crash, but unfortunately it also prevent rendering of some parts of bodies or clothing. On unpatched Mesa starting NWN with RADEON_DEBUG=vert produces empty log. I'm attaching what I have produced using RADEON_DEBUG=all. I will also, in next attachment, post RADEON_DEBUG=vert for patched Mesa. My speculation: I think that bugs lay deeper in code path, as seen in backtrace. Something along produces broken object that is passed to rc_mesa_to_rc_program, with trips over it. I don't know enough about Mesa code to trace it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Don't try to process irq when we are unloading
On Wed, 9 Sep 2009, Jerome Glisse wrote: > If module is being unloaded we should not try to handle irq especialy > we should not call into drm helper or we could hard hang the computer > free_irq will call the irq handler to make sure we behave properly. Should you not just ack all irqs here before returning, else we'll just get called again. Dave. > > Signed-off-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/r100.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c > index 5708c07..36d0ba2 100644 > --- a/drivers/gpu/drm/radeon/r100.c > +++ b/drivers/gpu/drm/radeon/r100.c > @@ -319,6 +319,9 @@ int r100_irq_process(struct radeon_device *rdev) > if (!status) { > return IRQ_NONE; > } > + if (rdev->shutdown) { > + return IRQ_NONE; > + } > while (status) { > /* SW interrupt */ > if (status & RADEON_SW_INT_TEST) { > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #8 from Shuang He 2009-09-09 20:31:19 PST --- (In reply to comment #7) > Created an attachment (id=29352) --> (http://bugs.freedesktop.org/attachment.cgi?id=29352) [details] > another patch for meta.c (IndexOffset/Bias check) > > Can you see if this patch helps with the glDrawPixels(GL_STENCIL_INDEX) cases? > > Also, the -v 2 output would be helpful. > No, this doesn't help. And I'll upload a small case for it -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #9 from Shuang He 2009-09-09 20:35:15 PST --- Created an attachment (id=29361) --> (http://bugs.freedesktop.org/attachment.cgi?id=29361) small case This case simply render a rectangle area in stencil buffer with glDrawPixels(GL_STENCIL). then render a red rectangle to validate the result. This case works with software rendering, but not with i965 driver. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux 2.6.31-rc7
On 2009.08.25 21:20:18 -0700, Linus Torvalds wrote: > > And how about MacBook 2.1, which apparently also goes black? > Linus, sorry for reply this old thread. I just handed on one MacBook with 945GM, and tried to find out the reason of black screen. It is TV detection that caused it. MacBook routes integrated TV DAC to mini-DVI port too, like for VGA. Our TV detect does load detect, which trys to set a mode onto TV port and checked back its status. This TV load-detect makes the LVDS black on MacBook. It looks our load detect function has problem that when we pick up one crtc, we don't check if its has a fb. During first TV detect, choosed crtc obviously has no fb, it would fail in modesetting when setting plane surface. This might have effect on the purpose of load- detect process. I'll see how it should be fixed. But even if I hacked plane setting with all zeros, screen still goes black on my MacBook, although TV detect return is right that there's none found. So this blank issue is within detect process, if you try to load fbcon or X later, setting mode is fine on LVDS. That's why build fbcon in kernel might workaround this issue. I don't know much about our TV detect method details, but looks like here we should check current TV status when system start. Otherwise it seems we can't stopping blank the screen...So I did a temp hacking like, diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c index 5b1c9e9..f3ecbaa 100644 --- a/drivers/gpu/drm/i915/intel_tv.c +++ b/drivers/gpu/drm/i915/intel_tv.c @@ -1451,8 +1451,18 @@ intel_tv_detect(struct drm_connector *connector) struct intel_output *intel_output = to_intel_output(connector); struct intel_tv_priv *tv_priv = intel_output->dev_priv; struct drm_encoder *encoder = &intel_output->enc; + struct drm_i915_private *dev_priv = connector->dev->dev_private; int dpms_mode; int type = tv_priv->type; + static int first_detect = 1; + + if (first_detect) { + first_detect = 0; + if (!(I915_READ(TV_CTL) & TV_ENC_ENABLE)) + return connector_status_disconnected; + else + return connector_status_connected; + } mode = reported_modes[0]; drm_mode_set_crtcinfo(&mode, CRTC_INTERLACE_HALVE_V); which makes LVDS working, but I haven't tested with mini-DVI <-> S-Video. I'm not sure if this is ideal enough for this, but first get port states in system startup for initial setup, and userspace could check and set required config later seems sane to me, as you have also suggested to do. This patch doesn't aim to be upstream, we may set the state in priv struct to check boot state, but I'd like to hear others' comment about this. thanks. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel