From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andi Kleen <ak@suse.de>, Andrew Morton <akpm@osdl.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH] ppc64 iommu rewrite part 4/5
Date: Sat, 28 Feb 2004 00:04:28 +1100 [thread overview]
Message-ID: <1077887067.22954.1.camel@gaston> (raw)
In-Reply-To: <p73oerk4ree.fsf@verdi.suse.de>
On Fri, 2004-02-27 at 23:51, Andi Kleen wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > +#if !defined(CONFIG_PCI) || PCI_DMA_BUS_IS_PHYS
>
> Can you make that a run time test? On x86-64 PCI_DMA_BUS_IS_PHYS is
> defined to a variable.
Sure, here's a revised version:
diff -urN linux-2.5/drivers/ide/ide-probe.c linux-iommu/drivers/ide/ide-probe.c
--- linux-2.5/drivers/ide/ide-probe.c 2004-02-28 00:02:30.971890984 +1100
+++ linux-iommu/drivers/ide/ide-probe.c 2004-02-28 00:02:07.145513144 +1100
@@ -50,6 +50,7 @@
#include <linux/spinlock.h>
#include <linux/pci.h>
#include <linux/kmod.h>
+#include <linux/pci.h>
#include <asm/byteorder.h>
#include <asm/irq.h>
@@ -904,6 +905,7 @@
request_queue_t *q;
ide_hwif_t *hwif = HWIF(drive);
int max_sectors = 256;
+ int max_sg_entries = PRD_ENTRIES;
/*
* Our default set up assumes the normal IDE case,
@@ -926,11 +928,22 @@
max_sectors = hwif->rqsize;
blk_queue_max_sectors(q, max_sectors);
- /* IDE DMA can do PRD_ENTRIES number of segments. */
- blk_queue_max_hw_segments(q, PRD_ENTRIES);
+#ifdef CONFIG_PCI
+ /* When we have an IOMMU, we may have a problem where pci_map_sg()
+ * creates segments that don't completely match our boundary
+ * requirements and thus need to be broken up again. Because it
+ * doesn't align properly neither, we may actually have to break up
+ * to more segments than what was we got in the first place, a max
+ * worst case is twice as many.
+ * This will be fixed once we teach pci_map_sg() about our boundary
+ * requirements, hopefully soon
+ */
+ if (!PCI_DMA_BUS_IS_PHYS)
+ max_sg_entries >>= 1;
+#endif /* CONFIG_PCI */
- /* This is a driver limit and could be eliminated. */
- blk_queue_max_phys_segments(q, PRD_ENTRIES);
+ blk_queue_max_hw_segments(q, max_sg_entries);
+ blk_queue_max_phys_segments(q, max_sg_entries);
/* assign drive and gendisk queue */
drive->queue = q;
next prev parent reply other threads:[~2004-02-27 13:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1077884018.22925.371.camel@gaston.suse.lists.linux.kernel>
2004-02-27 12:51 ` [PATCH] ppc64 iommu rewrite part 4/5 Andi Kleen
2004-02-27 13:04 ` Benjamin Herrenschmidt [this message]
2004-02-27 12:13 Benjamin Herrenschmidt
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=1077887067.22954.1.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.