mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Richard Curnow <Richard.Curnow@superh.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Greg KH <greg@kroah.com>, ink@jurassic.park.msu.ru
Subject: Simplification in pbus_size_mem
Date: Thu, 20 Nov 2003 12:28:38 +0000	[thread overview]
Message-ID: <20031120122838.GA4575@malvern.uk.w2k.superh.com> (raw)

The following patch is against 2.4, but the 2.6 code looks identical.

===== setup-bus.c 1.6 vs edited =====
--- 1.6/drivers/pci/setup-bus.c Thu Dec 12 22:14:01 2002
+++ edited/setup-bus.c  Thu Nov 20 11:54:28 2003
@@ -311,18 +311,8 @@
                }
        }
 
-       align = 0;
-       min_align = 0;
-       for (order = 0; order <= max_order; order++) {
-               unsigned long align1 = 1UL << (order + 20);
+       min_align = 1UL << (max_order + 20);
 
-               if (!align)
-                       min_align = align1;
-               else if (ROUND_UP(align + min_align, min_align) < align1)
-                       min_align = align1 >> 1;
-               align += aligns[order];
-       }
-       size = ROUND_UP(size, min_align);
        if (!size) {
                b_res->flags = 0;
                return;


This is fixing the allocation on a system which looks like this

* 96Mb PCI memory aperture
* Kyro graphics card, requiring 64Mb + 768kb prefetchable
* USB card requiring 4x4k non-prefetchable

Without the change, 'min_align' is computed as 32Mb (the algorithm in the
loop basically seems to make 'min_align' end up as 1/2 the largest
alignment requirement that was found?), hence in the pass where the
prefetchable block is sized, 'size' ends up as 96Mb, which means there
is no space left in which to place the non-prefetchable blocks for the
USB card.

With the patch above, the alignment requirement for the prefetchable
memory actually ends up as the alignment required for the framebuffer,
and the size isn't rounded up unnecessarily.  The USB card gets
allocated successfully as a result.

I couldn't be sure what the code in the loop is attempting to do, so I'm
sure I'm overlooking something subtle.  Any comments?

-- 
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
  P.    /// richard.curnow@superh.com  ///  rc@rc0.org.uk
Curnow  \\\ http://www.superh.com/    ///  www.rc0.org.uk

             reply	other threads:[~2003-11-20 12:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-20 12:28 Richard Curnow [this message]
2003-11-20 14:16 ` Ivan Kokshaysky
2003-11-20 15:25   ` Richard Curnow
2003-11-20 16:36     ` Ivan Kokshaysky
2003-11-24 15:28       ` Richard Curnow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031120122838.GA4575@malvern.uk.w2k.superh.com \
    --to=richard.curnow@superh.com \
    --cc=greg@kroah.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®