[Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Thomas Hellstrom]

On 06/11/2010 07:24 PM, Andrew Morton wrote:
> On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom 
>  wrote:
>
>
>
>
 David, I have a vague feeling that we've been round this loop before..

 Why does agp_alloc_page_array() use __GFP_NORETRY?  It's pretty unusual
 and it's what caused this spew.

 There's nothing in the changelog and the only relevant commentary
 appears to be "This speeds things up and also saves memory for small
 AGP regions", which is inscrutable.  Can you please add a usable
 comment there?

  
>>> cc'ing Thomas, who added this, I expect we could drop the NORETRY or
>>> just add NOWARN. Though an order 1 page alloc failure isn't a pretty
>>> sight, not sure how a vmalloc fallback could save us.
>>>
>>>
>>>
>> Hmm. IIRC that was an untested speed optimization back from the time
>> when I was
>> reading ldd3. I think the idea was to avoid slow allocations of (order>
>> 0) if they weren't
>> immediately available and fall back to vmalloc single page allocations.
>> It might be that that functionality is no longer preserved and only the
>> __GFP_NORETRY remains.
>> I think it should be safe to remove the NORETRY if it's annoying, but it
>> should probably be equally safe to add a NOWARN and keep the vmalloc
>> fallback.
>>  
> An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we
> use them for kernel stacks all the time.  I'd say just remove the
> __GFP_NORETRY and be happy.
>
> In fact if the allocations are always this small I'd say we can remove
> the vmalloc fallback too.  However if under some circumstances the
> allocations can be "large", say order-4 or higher then allocation
> failures are still a risk.
>
>

Actually, At that time I was working with a SiS GPU (128MiB system), and 
was getting persistent failures for order 1 GFP_KERNEL page allocations 
(albeit not in this codepath). So while they are highly unlikely for 
modern systems, it might be worthwhile keeping the fallback.

/Thomas

No subject

mesa upgrade to f4bcd0ca some hours later. At the time I installed lugaru (and
did not see any crash) I had just installed 2.6.34-996.201005261005 (drm-next
from mainline kernel PPA). Hours before I had installed 2.6.34-999.201005231006
(linus tree). So I must have been running one of those kernels.

Both these kernels hang when I try them now with mesa 20100523 fa552261
(installed), and also with 20100429 f7cf8b46 (git checkout, using
LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH).

So maybe I was just lucky when I tried lugaro out the first times. I think I
played with it more than 10 minutes. The way I reproduce the hang now is simply
by choosing Tutorial and then do nothing. Just let the rabbit stand there and
jump by itself. After 10-30 seconds the machine locks up. The sound goes into a
stuttering (sub-second) loop and I have to power off with the power button.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm/radeon/kms/atom: add crtc disable function

[Alex Deucher]

Disables the crts as per dpms and also disables the ppll
associated with the crtc.  This should save additional power.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |  152 
 1 files changed, 96 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 8c2d647..a22d5a3 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -669,56 +669,25 @@ static void atombios_crtc_set_dcpll(struct drm_crtc *crtc)
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*));
 }

-static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
+static void atombios_crtc_program_pll(struct drm_crtc *crtc,
+ int crtc_id,
+ int pll_id,
+ u32 encoder_mode,
+ u32 encoder_id,
+ u32 clock,
+ u32 ref_div,
+ u32 fb_div,
+ u32 frac_fb_div,
+ u32 post_div)
 {
-   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
-   struct drm_encoder *encoder = NULL;
-   struct radeon_encoder *radeon_encoder = NULL;
u8 frev, crev;
-   int index;
+   int index = GetIndexIntoMasterTable(COMMAND, SetPixelClock);
union set_pixel_clock args;
-   u32 pll_clock = mode->clock;
-   u32 ref_div = 0, fb_div = 0, frac_fb_div = 0, post_div = 0;
-   struct radeon_pll *pll;
-   u32 adjusted_clock;
-   int encoder_mode = 0;

memset(, 0, sizeof(args));

-   list_for_each_entry(encoder, >mode_config.encoder_list, head) {
-   if (encoder->crtc == crtc) {
-   radeon_encoder = to_radeon_encoder(encoder);
-   encoder_mode = atombios_get_encoder_mode(encoder);
-   break;
-   }
-   }
-
-   if (!radeon_encoder)
-   return;
-
-   switch (radeon_crtc->pll_id) {
-   case ATOM_PPLL1:
-   pll = >clock.p1pll;
-   break;
-   case ATOM_PPLL2:
-   pll = >clock.p2pll;
-   break;
-   case ATOM_DCPLL:
-   case ATOM_PPLL_INVALID:
-   default:
-   pll = >clock.dcpll;
-   break;
-   }
-
-   /* adjust pixel clock as needed */
-   adjusted_clock = atombios_adjust_pll(crtc, mode, pll);
-
-   radeon_compute_pll(pll, adjusted_clock, _clock, _div, 
_fb_div,
-  _div, _div);
-
-   index = GetIndexIntoMasterTable(COMMAND, SetPixelClock);
if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, ,
   ))
return;
@@ -727,47 +696,49 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
case 1:
switch (crev) {
case 1:
-   args.v1.usPixelClock = cpu_to_le16(mode->clock / 10);
+   if (clock == ATOM_DISABLE)
+   return;
+   args.v1.usPixelClock = cpu_to_le16(clock / 10);
args.v1.usRefDiv = cpu_to_le16(ref_div);
args.v1.usFbDiv = cpu_to_le16(fb_div);
args.v1.ucFracFbDiv = frac_fb_div;
args.v1.ucPostDiv = post_div;
-   args.v1.ucPpll = radeon_crtc->pll_id;
-   args.v1.ucCRTC = radeon_crtc->crtc_id;
+   args.v1.ucPpll = pll_id;
+   args.v1.ucCRTC = crtc_id;
args.v1.ucRefDivSrc = 1;
break;
case 2:
-   args.v2.usPixelClock = cpu_to_le16(mode->clock / 10);
+   args.v2.usPixelClock = cpu_to_le16(clock / 10);
args.v2.usRefDiv = cpu_to_le16(ref_div);
args.v2.usFbDiv = cpu_to_le16(fb_div);
args.v2.ucFracFbDiv = frac_fb_div;
args.v2.ucPostDiv = post_div;
-   args.v2.ucPpll = radeon_crtc->pll_id;
-   args.v2.ucCRTC = radeon_crtc->crtc_id;
+   args.v2.ucPpll = pll_id;
+   args.v2.ucCRTC = crtc_id;
args.v2.ucRefDivSrc = 1;
break;
case 3:
-   args.v3.usPixelClock = cpu_to_le16(mode->clock / 10);
+   args.v3.usPixelClock = cpu_to_le16(clock / 10);
args.v3.usRefDiv = 

[PATCH 1/2] drm/kms: add crtc disable function

[Alex Deucher]

More explicit than dpms. Same as the encoder disable function.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/drm_crtc_helper.c |5 -
 include/drm/drm_crtc_helper.h |3 +++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 9b2a541..fa1323f 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -241,7 +241,10 @@ void drm_helper_disable_unused_functions(struct drm_device 
*dev)
struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
crtc->enabled = drm_helper_crtc_in_use(crtc);
if (!crtc->enabled) {
-   crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
+   if (crtc_funcs->disable)
+   (*crtc_funcs->disable)(crtc);
+   else
+   (*crtc_funcs->dpms)(crtc, DRM_MODE_DPMS_OFF);
crtc->fb = NULL;
}
}
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 1121f77..7e3c976 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -63,6 +63,9 @@ struct drm_crtc_helper_funcs {

/* reload the current crtc LUT */
void (*load_lut)(struct drm_crtc *crtc);
+
+   /* disable crtc when not in use - more explicit than dpms off */
+   void (*disable)(struct drm_crtc *crtc);
 };

 struct drm_encoder_helper_funcs {
-- 
1.7.0.1

[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28459

--- Comment #12 from Alex Deucher  2010-06-11 15:55:20 PDT 
---
Created an attachment (id=36226)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36226
 Review: https://bugs.freedesktop.org/review?bug=28459=36226

fix r1xx/r2xx/r3xx

This patch combines Roland's patch with the same fixes for r1xx and r2xx. 
Roland, if you want to sign off on it, I'll send it to Dave.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm/radeon/kms/atom: add crtc disable function

[Keith Packard]

On Fri, 11 Jun 2010 18:00:09 -0400, Alex Deucher  
wrote:

> Disables the crts as per dpms and also disables the ppll
> associated with the crtc.  This should save additional power.

Any reason the pll isn't just disabled for dpms as well?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100611/ae31cd25/attachment.pgp>

[Bug 28474] [r300g] lugaru/etc locks up laptop

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28474

--- Comment #5 from Marek Ol??k  2010-06-11 15:09:04 PDT 
---
This is weird. I think all hardlocks a driver can provoke are more or less
instant. I believe something is wrong in the kernel.

IIRC Corbin had some issues with RV410 too.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: fix dpms state on resume

[Alex Deucher]

From: Cedric Godin 

When suspending, we turn the display hw off, at resume the screen will stay 
black.
This patch turn it on. Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16180

Signed-off-by: Cedric Godin 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_device.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index f10faed..5f31731 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -779,6 +779,7 @@ int radeon_suspend_kms(struct drm_device *dev, pm_message_t 
state)

 int radeon_resume_kms(struct drm_device *dev)
 {
+   struct drm_connector *connector;
struct radeon_device *rdev = dev->dev_private;

if (rdev->powered_down)
@@ -797,6 +798,12 @@ int radeon_resume_kms(struct drm_device *dev)
radeon_resume(rdev);
radeon_pm_resume(rdev);
radeon_restore_bios_scratch_regs(rdev);
+
+   /* turn on display hw */
+   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
+   }
+
radeon_fbdev_set_suspend(rdev, 0);
release_console_sem();

-- 
1.7.0.1

[Bug 28474] [r300g] lugaru/etc locks up laptop

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28474

Tormod Volden  changed:

   What|Removed |Added

Summary|[gallium] lugaru/etc locks  |[r300g] lugaru/etc locks up
   |up laptop   |laptop

--- Comment #4 from Tormod Volden  2010-06-11 
14:33:41 PDT ---
I have no idea any longer. My install log does not match my memory, and I guess
that means EBRAIN. It seems I never used 20100523 (fa552261) but in fact
upgraded straight from 20100429 (f7cf8b46) to 20100528 (f4bcd0ca). So now I
checked out f7cf8b46 from git but it also locked up.

[Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Andrew Morton]

On Fri, 11 Jun 2010 22:22:28 +0200
Thomas Hellstrom  wrote:

> >>> cc'ing Thomas, who added this, I expect we could drop the NORETRY or
> >>> just add NOWARN. Though an order 1 page alloc failure isn't a pretty
> >>> sight, not sure how a vmalloc fallback could save us.
> >>>
> >>>
> >>>
> >> Hmm. IIRC that was an untested speed optimization back from the time
> >> when I was
> >> reading ldd3. I think the idea was to avoid slow allocations of (order>
> >> 0) if they weren't
> >> immediately available and fall back to vmalloc single page allocations.
> >> It might be that that functionality is no longer preserved and only the
> >> __GFP_NORETRY remains.
> >> I think it should be safe to remove the NORETRY if it's annoying, but it
> >> should probably be equally safe to add a NOWARN and keep the vmalloc
> >> fallback.
> >>  
> > An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we
> > use them for kernel stacks all the time.  I'd say just remove the
> > __GFP_NORETRY and be happy.
> >
> > In fact if the allocations are always this small I'd say we can remove
> > the vmalloc fallback too.  However if under some circumstances the
> > allocations can be "large", say order-4 or higher then allocation
> > failures are still a risk.
> >
> >
> 
> Actually, At that time I was working with a SiS GPU (128MiB system), and 
> was getting persistent failures for order 1 GFP_KERNEL page allocations 
> (albeit not in this codepath). So while they are highly unlikely for 
> modern systems, it might be worthwhile keeping the fallback.

128MB total RAM?  Those were the days.

Various page reclaim changes have been made in the past year or so
which _should_ improve that (eg, lumpy reclaim) but yeah, it's by no
means a certainty.

The vmalloc fallback hardly hurts anyone.  But it does mean that hardly
anyone ever executes that codepath, so it won't get tested much.

There was a patch recently which added an API formalising the
alloc_pages-then-vmalloc fallback approach.  It didn't get merged,
although there weren't strong feelings either way really.  One benefit
of that approach is that the alloc/free code itself would get more
testing coverage, but callers can still screw things up by failing to
handle vmalloc memory correctly for DMA mapping purposes.

Oh well, where were we?  Remove that __GFP_NORETRY?

[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28459

--- Comment #11 from Pavel Ondra?ka  2010-06-11 12:07:10 
PDT ---
Thank you Roland, with your patch Heroes of Newerth works fine again. This bug
can be closed after your patch is committed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #4 from Da Fox  2010-06-11 11:36:50 
PDT ---
Created an attachment (id=36221)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=36221)
Kernel log for one day

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #3 from Jerome Glisse  2010-06-11 
11:29:02 PDT ---
Please attach full dmesg thanks

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Thomas Hellstrom]

On 06/11/2010 01:15 AM, Dave Airlie wrote:
> On Thu, 2010-06-10 at 15:38 -0700, Andrew Morton wrote:
>
>> (switched to email.  Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Mon, 7 Jun 2010 17:32:04 GMT
>> bugzilla-daemon at bugzilla.kernel.org wrote:
>>
>>  
>>> https://bugzilla.kernel.org/show_bug.cgi?id=16148
>>>
>>> Summary: page allocation failure. order:1, mode:0x50d0
>>> Product: Memory Management
>>> Version: 2.5
>>>  Kernel Version: 2.6.35-rc1
>>>Platform: All
>>>  OS/Version: Linux
>>>Tree: Mainline
>>>  Status: NEW
>>>Severity: normal
>>>Priority: P1
>>>   Component: Page Allocator
>>>  AssignedTo: akpm at linux-foundation.org
>>>  ReportedBy: devnull at plzk.org
>>>  Regression: No
>>>
>>>
>>> Created an attachment (id=26687)
>>>   -->  (https://bugzilla.kernel.org/attachment.cgi?id=26687)
>>> dmesg
>>>
>>> Never seen this before.
>>>
>>> 2.6.35-rc1 #1 SMP Mon May 31 21:31:02 CEST 2010 x86_64 GNU/Linux
>>>
>>> [48126.787684] Xorg: page allocation failure. order:1, mode:0x50d0
>>> [48126.787691] Pid: 1895, comm: Xorg Tainted: GW   2.6.35-rc1 #1
>>> [48126.787694] Call Trace:
>>> [48126.787709]  [] __alloc_pages_nodemask+0x5f5/0x6f0
>>> [48126.787716]  [] alloc_pages_current+0x95/0x100
>>> [48126.787720]  [] new_slab+0x2ba/0x2c0
>>> [48126.787724]  [] __slab_alloc+0x14b/0x4e0
>>> [48126.787730]  [] ? 
>>> security_vm_enough_memory_kern+0x21/0x30
>>> [48126.787736]  [] ? agp_alloc_page_array+0x5a/0x70
>>> [48126.787740]  [] __kmalloc+0x11f/0x1c0
>>> [48126.787744]  [] agp_alloc_page_array+0x5a/0x70
>>> [48126.787747]  [] agp_generic_alloc_user+0x64/0x140
>>> [48126.787750]  [] agp_allocate_memory+0x9a/0x140
>>> [48126.787755]  [] drm_agp_allocate_memory+0x9/0x10
>>> [48126.787758]  [] drm_agp_bind_pages+0x57/0x100
>>> [48126.787765]  [] i915_gem_object_bind_to_gtt+0x144/0x340
>>> [48126.787768]  [] i915_gem_object_pin+0xb5/0xd0
>>> [48126.787772]  [] i915_gem_do_execbuffer+0x6cc/0x14f0
>>> [48126.78]  [] ? __is_ram+0x0/0x10
>>> [48126.787783]  [] ? lookup_memtype+0xce/0xe0
>>> [48126.787787]  [] ? i915_gem_execbuffer+0x91/0x390
>>> [48126.787790]  [] i915_gem_execbuffer+0x1d5/0x390
>>> [48126.787794]  [] ? i915_gem_sw_finish_ioctl+0x90/0xc0
>>> [48126.787799]  [] drm_ioctl+0x32a/0x4b0
>>> [48126.787802]  [] ? i915_gem_execbuffer+0x0/0x390
>>> [48126.787807]  [] vfs_ioctl+0x38/0xd0
>>> [48126.787810]  [] do_vfs_ioctl+0x8a/0x580
>>> [48126.787814]  [] sys_ioctl+0x81/0xa0
>>> [48126.787820]  [] system_call_fastpath+0x16/0x1b
>>>
>>>
>> David, I have a vague feeling that we've been round this loop before..
>>
>> Why does agp_alloc_page_array() use __GFP_NORETRY?  It's pretty unusual
>> and it's what caused this spew.
>>
>> There's nothing in the changelog and the only relevant commentary
>> appears to be "This speeds things up and also saves memory for small
>> AGP regions", which is inscrutable.  Can you please add a usable
>> comment there?
>>  
> cc'ing Thomas, who added this, I expect we could drop the NORETRY or
> just add NOWARN. Though an order 1 page alloc failure isn't a pretty
> sight, not sure how a vmalloc fallback could save us.
>
>

Hmm. IIRC that was an untested speed optimization back from the time 
when I was
reading ldd3. I think the idea was to avoid slow allocations of (order > 
0) if they weren't
immediately available and fall back to vmalloc single page allocations.
It might be that that functionality is no longer preserved and only the 
__GFP_NORETRY remains.
I think it should be safe to remove the NORETRY if it's annoying, but it 
should probably be equally safe to add a NOWARN and keep the vmalloc 
fallback.

Now if we still get a "definitive" page allocation failure in this 
codepath, that's not good, but hardly the AGP driver's fault.  Has Intel 
added some kind of accounting for pinned pages yet?


>> Presumably this was added in response to some observed behaviour, but
>> what was it??
>>
>>
>> If the __GFP_NORETRY is indeed useful and legitimate and given that we
>> have a vmalloc fallback, I'd suggest that we add __GFP_NOWARN there as
>> well to keep the bug reports away.
>>
>> btw, agp_memory.vmalloc_flag can be done away with - it's conventional
>> to use is_vmalloc_addr() for this.
>>  
> Lols, conventional my ass, we wanted to add that thing years ago for
> this purpose and got told that would be an insane interface, then the
> same person added the interface a year later and never fixed AGP to use
> it.
>
>


Indeed. I even recall the phrase "Too ugly to live" :).

> I'll try and write a patch.
>
> Dave.
>
>
/Thomas

[Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Andrew Morton]

On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom  
wrote:

> >>>
> >>>
> >> David, I have a vague feeling that we've been round this loop before..
> >>
> >> Why does agp_alloc_page_array() use __GFP_NORETRY?  It's pretty unusual
> >> and it's what caused this spew.
> >>
> >> There's nothing in the changelog and the only relevant commentary
> >> appears to be "This speeds things up and also saves memory for small
> >> AGP regions", which is inscrutable.  Can you please add a usable
> >> comment there?
> >>  
> > cc'ing Thomas, who added this, I expect we could drop the NORETRY or
> > just add NOWARN. Though an order 1 page alloc failure isn't a pretty
> > sight, not sure how a vmalloc fallback could save us.
> >
> >
> 
> Hmm. IIRC that was an untested speed optimization back from the time 
> when I was
> reading ldd3. I think the idea was to avoid slow allocations of (order > 
> 0) if they weren't
> immediately available and fall back to vmalloc single page allocations.
> It might be that that functionality is no longer preserved and only the 
> __GFP_NORETRY remains.
> I think it should be safe to remove the NORETRY if it's annoying, but it 
> should probably be equally safe to add a NOWARN and keep the vmalloc 
> fallback.

An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we
use them for kernel stacks all the time.  I'd say just remove the
__GFP_NORETRY and be happy.

In fact if the allocations are always this small I'd say we can remove
the vmalloc fallback too.  However if under some circumstances the
allocations can be "large", say order-4 or higher then allocation
failures are still a risk.

[Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Dave Airlie]

On Thu, 2010-06-10 at 15:38 -0700, Andrew Morton wrote:
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Mon, 7 Jun 2010 17:32:04 GMT
> bugzilla-daemon at bugzilla.kernel.org wrote:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=16148
> > 
> >Summary: page allocation failure. order:1, mode:0x50d0
> >Product: Memory Management
> >Version: 2.5
> > Kernel Version: 2.6.35-rc1
> >   Platform: All
> > OS/Version: Linux
> >   Tree: Mainline
> > Status: NEW
> >   Severity: normal
> >   Priority: P1
> >  Component: Page Allocator
> > AssignedTo: akpm at linux-foundation.org
> > ReportedBy: devnull at plzk.org
> > Regression: No
> > 
> > 
> > Created an attachment (id=26687)
> >  --> (https://bugzilla.kernel.org/attachment.cgi?id=26687)
> > dmesg
> > 
> > Never seen this before.
> > 
> > 2.6.35-rc1 #1 SMP Mon May 31 21:31:02 CEST 2010 x86_64 GNU/Linux
> > 
> > [48126.787684] Xorg: page allocation failure. order:1, mode:0x50d0
> > [48126.787691] Pid: 1895, comm: Xorg Tainted: GW   2.6.35-rc1 #1
> > [48126.787694] Call Trace:
> > [48126.787709]  [] __alloc_pages_nodemask+0x5f5/0x6f0
> > [48126.787716]  [] alloc_pages_current+0x95/0x100
> > [48126.787720]  [] new_slab+0x2ba/0x2c0
> > [48126.787724]  [] __slab_alloc+0x14b/0x4e0
> > [48126.787730]  [] ? 
> > security_vm_enough_memory_kern+0x21/0x30
> > [48126.787736]  [] ? agp_alloc_page_array+0x5a/0x70
> > [48126.787740]  [] __kmalloc+0x11f/0x1c0
> > [48126.787744]  [] agp_alloc_page_array+0x5a/0x70
> > [48126.787747]  [] agp_generic_alloc_user+0x64/0x140
> > [48126.787750]  [] agp_allocate_memory+0x9a/0x140
> > [48126.787755]  [] drm_agp_allocate_memory+0x9/0x10
> > [48126.787758]  [] drm_agp_bind_pages+0x57/0x100
> > [48126.787765]  [] i915_gem_object_bind_to_gtt+0x144/0x340
> > [48126.787768]  [] i915_gem_object_pin+0xb5/0xd0
> > [48126.787772]  [] i915_gem_do_execbuffer+0x6cc/0x14f0
> > [48126.78]  [] ? __is_ram+0x0/0x10
> > [48126.787783]  [] ? lookup_memtype+0xce/0xe0
> > [48126.787787]  [] ? i915_gem_execbuffer+0x91/0x390
> > [48126.787790]  [] i915_gem_execbuffer+0x1d5/0x390
> > [48126.787794]  [] ? i915_gem_sw_finish_ioctl+0x90/0xc0
> > [48126.787799]  [] drm_ioctl+0x32a/0x4b0
> > [48126.787802]  [] ? i915_gem_execbuffer+0x0/0x390
> > [48126.787807]  [] vfs_ioctl+0x38/0xd0
> > [48126.787810]  [] do_vfs_ioctl+0x8a/0x580
> > [48126.787814]  [] sys_ioctl+0x81/0xa0
> > [48126.787820]  [] system_call_fastpath+0x16/0x1b
> > 
> 
> David, I have a vague feeling that we've been round this loop before.. 
> 
> Why does agp_alloc_page_array() use __GFP_NORETRY?  It's pretty unusual
> and it's what caused this spew.
> 
> There's nothing in the changelog and the only relevant commentary
> appears to be "This speeds things up and also saves memory for small
> AGP regions", which is inscrutable.  Can you please add a usable
> comment there?

cc'ing Thomas, who added this, I expect we could drop the NORETRY or
just add NOWARN. Though an order 1 page alloc failure isn't a pretty
sight, not sure how a vmalloc fallback could save us.

> 
> Presumably this was added in response to some observed behaviour, but
> what was it??
> 
> 
> If the __GFP_NORETRY is indeed useful and legitimate and given that we
> have a vmalloc fallback, I'd suggest that we add __GFP_NOWARN there as
> well to keep the bug reports away.
> 
> btw, agp_memory.vmalloc_flag can be done away with - it's conventional
> to use is_vmalloc_addr() for this.

Lols, conventional my ass, we wanted to add that thing years ago for
this purpose and got told that would be an insane interface, then the
same person added the interface a year later and never fixed AGP to use
it.

I'll try and write a patch.

Dave.

[Bug 27756] [KMS] sauerbraten crash with drmRadeonCmdBuffer: -22 -> Texture of unit 0 needs 8320 bytes but is 8192

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27756

Fabio Pedretti  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Fabio Pedretti  2010-06-11 09:01:12 
PDT ---


*** This bug has been marked as a duplicate of bug 28459 ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28459

Fabio Pedretti  changed:

   What|Removed |Added

 CC||fabio.ped at libero.it

--- Comment #10 from Fabio Pedretti  2010-06-11 
09:01:12 PDT ---
*** Bug 27756 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28459

--- Comment #9 from Fabio Pedretti  2010-06-11 09:01:00 
PDT ---
(In reply to comment #8)
> Created an attachment (id=36214)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36214
 Review: https://bugs.freedesktop.org/review?bug=28459=36214

> possible fix
> 
> If my theory is right, the attached patch might help (that's just a quick try,
> r100/r200 would need the same).

I was having the same crash problem with sauerbraten game (bug #27756) and this
patch seems to fix it (tested with linux 2.6.34). When submitting the patch
could you push it also to linux stable branch 2.6.32/33/34? 

There are still 2 similar bugs that would be nice to have fixed: bug #27755 and
bug #27507.

Thanks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28459

--- Comment #8 from Roland Scheidegger  2010-06-11 
05:35:00 PDT ---
Created an attachment (id=36214)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36214
 Review: https://bugs.freedesktop.org/review?bug=28459=36214

possible fix

If my theory is right, the attached patch might help (that's just a quick try,
r100/r200 would need the same).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 1/3] Add _DRM_HIDDEN macro

[Julien Cristau]

On Thu, Jun 10, 2010 at 23:50:09 +0200, Julien Cristau wrote:

> Introduce a new internal header since that doesn't seem to exist yet.
> Or maybe I should rename xf86atomic.h instead.
> ---
>  xf86drm-internals.h |   12 
>  1 files changed, 12 insertions(+), 0 deletions(-)
>  create mode 100644 xf86drm-internals.h
> 
Sorry, forgot to include it in Makefile.am.  If the rest of the series
is acked I can resend with the fix.

Cheers,
Julien

REGRESSION: dpms-on broken (drm_radeon,displayport) -- bisected

[Lars Doelle]

Hi Alex,
Hi All,


> Attached patch should fix it.

Yes, it does.


Alex, All, great job!

Thanks and kind regards

  Lars

[PATCH 3/3] radeon: don't export internal functions

[Julien Cristau]

Also drop prototypes for nonexistent functions.
---
 radeon/bof.h |   41 +++--
 1 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/radeon/bof.h b/radeon/bof.h
index 014affb..239c98a 100644
--- a/radeon/bof.h
+++ b/radeon/bof.h
@@ -28,6 +28,7 @@

 #include 
 #include 
+#include "xf86drm-internals.h"

 #define BOF_TYPE_STRING0
 #define BOF_TYPE_NULL  1
@@ -51,34 +52,30 @@ typedef struct bof {
longoffset;
 } bof_t;

-extern int bof_file_flush(bof_t *root);
-extern bof_t *bof_file_new(const char *filename);
-extern int bof_object_dump(bof_t *object, const char *filename);
-
 /* object */
-extern bof_t *bof_object(void);
-extern bof_t *bof_object_get(bof_t *object, const char *keyname);
-extern int bof_object_set(bof_t *object, const char *keyname, bof_t *value);
+extern _DRM_HIDDEN bof_t *bof_object(void);
+extern _DRM_HIDDEN bof_t *bof_object_get(bof_t *object, const char *keyname);
+extern _DRM_HIDDEN int bof_object_set(bof_t *object, const char *keyname, 
bof_t *value);
 /* array */
-extern bof_t *bof_array(void);
-extern int bof_array_append(bof_t *array, bof_t *value);
-extern bof_t *bof_array_get(bof_t *bof, unsigned i);
-extern unsigned bof_array_size(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_array(void);
+extern _DRM_HIDDEN int bof_array_append(bof_t *array, bof_t *value);
+extern _DRM_HIDDEN bof_t *bof_array_get(bof_t *bof, unsigned i);
+extern _DRM_HIDDEN unsigned bof_array_size(bof_t *bof);
 /* blob */
-extern bof_t *bof_blob(unsigned size, void *value);
-extern unsigned bof_blob_size(bof_t *bof);
-extern void *bof_blob_value(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_blob(unsigned size, void *value);
+extern _DRM_HIDDEN unsigned bof_blob_size(bof_t *bof);
+extern _DRM_HIDDEN void *bof_blob_value(bof_t *bof);
 /* string */
-extern bof_t *bof_string(const char *value);
+extern _DRM_HIDDEN bof_t *bof_string(const char *value);
 /* int32 */
-extern bof_t *bof_int32(int32_t value);
-extern int32_t bof_int32_value(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_int32(int32_t value);
+extern _DRM_HIDDEN int32_t bof_int32_value(bof_t *bof);
 /* common functions */
-extern void bof_decref(bof_t *bof);
-extern void bof_incref(bof_t *bof);
-extern bof_t *bof_load_file(const char *filename);
-extern int bof_dump_file(bof_t *bof, const char *filename);
-extern void bof_print(bof_t *bof);
+extern _DRM_HIDDEN void bof_decref(bof_t *bof);
+extern _DRM_HIDDEN void bof_incref(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_load_file(const char *filename);
+extern _DRM_HIDDEN int bof_dump_file(bof_t *bof, const char *filename);
+extern _DRM_HIDDEN void bof_print(bof_t *bof);

 static inline int bof_is_object(bof_t *bof){return (bof->type == 
BOF_TYPE_OBJECT);}
 static inline int bof_is_blob(bof_t *bof){return (bof->type == BOF_TYPE_BLOB);}
-- 
1.7.1

[PATCH 2/3] libkms: don't export internal functions

[Julien Cristau]

---
 libkms/internal.h |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libkms/internal.h b/libkms/internal.h
index 63122d1..efb781a 100644
--- a/libkms/internal.h
+++ b/libkms/internal.h
@@ -30,6 +30,7 @@
 #define INTERNAL_H_

 #include "libkms.h"
+#include "xf86drm-internals.h"

 struct kms_driver
 {
@@ -62,12 +63,12 @@ struct kms_bo
unsigned handle;
 };

-int linux_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int linux_create(int fd, struct kms_driver **out);

-int vmwgfx_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int vmwgfx_create(int fd, struct kms_driver **out);

-int intel_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int intel_create(int fd, struct kms_driver **out);

-int nouveau_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int nouveau_create(int fd, struct kms_driver **out);

 #endif
-- 
1.7.1

[PATCH 1/3] Add _DRM_HIDDEN macro

[Julien Cristau]

Introduce a new internal header since that doesn't seem to exist yet.
Or maybe I should rename xf86atomic.h instead.
---
 xf86drm-internals.h |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)
 create mode 100644 xf86drm-internals.h

diff --git a/xf86drm-internals.h b/xf86drm-internals.h
new file mode 100644
index 000..bf5ff51
--- /dev/null
+++ b/xf86drm-internals.h
@@ -0,0 +1,12 @@
+#ifndef XF86DRM_INTERNALS_H
+#define XF86DRM_INTERNALS_H
+
+#if defined(__GNUC__) && (__GNUC__ >= 4)
+# define _DRM_HIDDEN  __attribute__((visibility("hidden")))
+#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
+# define _DRM_HIDDEN  __hidden
+#else /* not gcc >= 4 and not Sun Studio >= 8 */
+# define _X_HIDDEN
+#endif /* GNUC >= 4 */
+
+#endif
-- 
1.7.1

[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28459

Fabio Pedretti fabio@libero.it changed:

   What|Removed |Added

 CC||fabio@libero.it

--- Comment #10 from Fabio Pedretti fabio@libero.it 2010-06-11 09:01:12 
PDT ---
*** Bug 27756 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #3 from Jerome Glisse gli...@freedesktop.org 2010-06-11 11:29:02 
PDT ---
Please attach full dmesg thanks

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: fix dpms state on resume

[Alex Deucher]

From: Cedric Godin cedric.go...@skynet.be

When suspending, we turn the display hw off, at resume the screen will stay 
black.
This patch turn it on. Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16180

Signed-off-by: Cedric Godin cedric.go...@skynet.be
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_device.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index f10faed..5f31731 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -779,6 +779,7 @@ int radeon_suspend_kms(struct drm_device *dev, pm_message_t 
state)
 
 int radeon_resume_kms(struct drm_device *dev)
 {
+   struct drm_connector *connector;
struct radeon_device *rdev = dev-dev_private;
 
if (rdev-powered_down)
@@ -797,6 +798,12 @@ int radeon_resume_kms(struct drm_device *dev)
radeon_resume(rdev);
radeon_pm_resume(rdev);
radeon_restore_bios_scratch_regs(rdev);
+
+   /* turn on display hw */
+   list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+   drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
+   }
+
radeon_fbdev_set_suspend(rdev, 0);
release_console_sem();
 
-- 
1.7.0.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28459

--- Comment #11 from Pavel Ondračka dra...@centrum.cz 2010-06-11 12:07:10 PDT 
---
Thank you Roland, with your patch Heroes of Newerth works fine again. This bug
can be closed after your patch is committed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Thomas Hellstrom]

On 06/11/2010 10:37 PM, Andrew Morton wrote:

On Fri, 11 Jun 2010 22:22:28 +0200
Thomas Hellstromthellst...@vmware.com  wrote:

   

cc'ing Thomas, who added this, I expect we could drop the NORETRY or
just add NOWARN. Though an order 1 page alloc failure isn't a pretty
sight, not sure how a vmalloc fallback could save us.



   

Hmm. IIRC that was an untested speed optimization back from the time
when I was
reading ldd3. I think the idea was to avoid slow allocations of (order
0) if they weren't
immediately available and fall back to vmalloc single page allocations.
It might be that that functionality is no longer preserved and only the
__GFP_NORETRY remains.
I think it should be safe to remove the NORETRY if it's annoying, but it
should probably be equally safe to add a NOWARN and keep the vmalloc
fallback.

 

An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we
use them for kernel stacks all the time.  I'd say just remove the
__GFP_NORETRY and be happy.

In fact if the allocations are always this small I'd say we can remove
the vmalloc fallback too.  However if under some circumstances the
allocations can be large, say order-4 or higher then allocation
failures are still a risk.


   

Actually, At that time I was working with a SiS GPU (128MiB system), and
was getting persistent failures for order 1 GFP_KERNEL page allocations
(albeit not in this codepath). So while they are highly unlikely for
modern systems, it might be worthwhile keeping the fallback.
 

128MB total RAM?  Those were the days.

Various page reclaim changes have been made in the past year or so
which _should_ improve that (eg, lumpy reclaim) but yeah, it's by no
means a certainty.

The vmalloc fallback hardly hurts anyone.  But it does mean that hardly
anyone ever executes that codepath, so it won't get tested much.

There was a patch recently which added an API formalising the
alloc_pages-then-vmalloc fallback approach.  It didn't get merged,
although there weren't strong feelings either way really.  One benefit
of that approach is that the alloc/free code itself would get more
testing coverage, but callers can still screw things up by failing to
handle vmalloc memory correctly for DMA mapping purposes.

Oh well, where were we?  Remove that __GFP_NORETRY?
   


Yeah, I think that's the sanest thing to do!

/Thomas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon/kms/atom: add crtc disable function

[Alex Deucher]

Disables the crts as per dpms and also disables the ppll
associated with the crtc.  This should save additional power.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/atombios_crtc.c |  152 
 1 files changed, 96 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 8c2d647..a22d5a3 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -669,56 +669,25 @@ static void atombios_crtc_set_dcpll(struct drm_crtc *crtc)
atom_execute_table(rdev-mode_info.atom_context, index, (uint32_t 
*)args);
 }
 
-static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
+static void atombios_crtc_program_pll(struct drm_crtc *crtc,
+ int crtc_id,
+ int pll_id,
+ u32 encoder_mode,
+ u32 encoder_id,
+ u32 clock,
+ u32 ref_div,
+ u32 fb_div,
+ u32 frac_fb_div,
+ u32 post_div)
 {
-   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc-dev;
struct radeon_device *rdev = dev-dev_private;
-   struct drm_encoder *encoder = NULL;
-   struct radeon_encoder *radeon_encoder = NULL;
u8 frev, crev;
-   int index;
+   int index = GetIndexIntoMasterTable(COMMAND, SetPixelClock);
union set_pixel_clock args;
-   u32 pll_clock = mode-clock;
-   u32 ref_div = 0, fb_div = 0, frac_fb_div = 0, post_div = 0;
-   struct radeon_pll *pll;
-   u32 adjusted_clock;
-   int encoder_mode = 0;
 
memset(args, 0, sizeof(args));
 
-   list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
-   if (encoder-crtc == crtc) {
-   radeon_encoder = to_radeon_encoder(encoder);
-   encoder_mode = atombios_get_encoder_mode(encoder);
-   break;
-   }
-   }
-
-   if (!radeon_encoder)
-   return;
-
-   switch (radeon_crtc-pll_id) {
-   case ATOM_PPLL1:
-   pll = rdev-clock.p1pll;
-   break;
-   case ATOM_PPLL2:
-   pll = rdev-clock.p2pll;
-   break;
-   case ATOM_DCPLL:
-   case ATOM_PPLL_INVALID:
-   default:
-   pll = rdev-clock.dcpll;
-   break;
-   }
-
-   /* adjust pixel clock as needed */
-   adjusted_clock = atombios_adjust_pll(crtc, mode, pll);
-
-   radeon_compute_pll(pll, adjusted_clock, pll_clock, fb_div, 
frac_fb_div,
-  ref_div, post_div);
-
-   index = GetIndexIntoMasterTable(COMMAND, SetPixelClock);
if (!atom_parse_cmd_header(rdev-mode_info.atom_context, index, frev,
   crev))
return;
@@ -727,47 +696,49 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
case 1:
switch (crev) {
case 1:
-   args.v1.usPixelClock = cpu_to_le16(mode-clock / 10);
+   if (clock == ATOM_DISABLE)
+   return;
+   args.v1.usPixelClock = cpu_to_le16(clock / 10);
args.v1.usRefDiv = cpu_to_le16(ref_div);
args.v1.usFbDiv = cpu_to_le16(fb_div);
args.v1.ucFracFbDiv = frac_fb_div;
args.v1.ucPostDiv = post_div;
-   args.v1.ucPpll = radeon_crtc-pll_id;
-   args.v1.ucCRTC = radeon_crtc-crtc_id;
+   args.v1.ucPpll = pll_id;
+   args.v1.ucCRTC = crtc_id;
args.v1.ucRefDivSrc = 1;
break;
case 2:
-   args.v2.usPixelClock = cpu_to_le16(mode-clock / 10);
+   args.v2.usPixelClock = cpu_to_le16(clock / 10);
args.v2.usRefDiv = cpu_to_le16(ref_div);
args.v2.usFbDiv = cpu_to_le16(fb_div);
args.v2.ucFracFbDiv = frac_fb_div;
args.v2.ucPostDiv = post_div;
-   args.v2.ucPpll = radeon_crtc-pll_id;
-   args.v2.ucCRTC = radeon_crtc-crtc_id;
+   args.v2.ucPpll = pll_id;
+   args.v2.ucCRTC = crtc_id;
args.v2.ucRefDivSrc = 1;
break;
case 3:
-   args.v3.usPixelClock = cpu_to_le16(mode-clock / 10);
+   args.v3.usPixelClock = cpu_to_le16(clock / 10);
   

Re: [PATCH 2/2] drm/radeon/kms/atom: add crtc disable function

[Keith Packard]

On Fri, 11 Jun 2010 18:00:09 -0400, Alex Deucher alexdeuc...@gmail.com wrote:

 Disables the crts as per dpms and also disables the ppll
 associated with the crtc.  This should save additional power.

Any reason the pll isn't just disabled for dpms as well?

-- 
keith.pack...@intel.com


pgpZYxJhMeA0P.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel