public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Chubb <peter@chubb.wattle.id.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems
Date: Thu, 30 May 2002 04:56:43 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905618@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905608@msgid-missing>

>>>>> On Wed, 29 May 2002 12:29:00 -0700, Grant Grundler <grundler@cup.hp.com> said:

Grant> If someone has a tarball of the current to-linus tree I could
Grant> d/l, I could look at this sooner.

Can you take a look at this and see if you think it's sane?
I'm only doing this to get a clean compilation

--- /tmp/geta3892	Thu May 30 14:53:10 2002
+++ sba_iommu.c	Thu May 30 14:53:05 2002
@@ -216,9 +216,10 @@
 static int reserve_sba_gart = 1;
 static struct pci_dev sac_only_dev;
 
-#define sba_sg_iova(sg) (sg->address)
+#define sba_sg_iova(sg) (page_address((sg)->page) + (sg)->offset)
 #define sba_sg_len(sg) (sg->length)
 #define sba_sg_buffer(sg) (sg->orig_address)
+#define sba_sg_clear_iova(sg) (sg->page = NULL,sg->offset = 0)
 
 /* REVISIT - fix me for multiple SBAs/IOCs */
 #define GET_IOC(dev) (sba_list->ioc)
@@ -229,8 +230,8 @@
 ** DMA_CHUNK_SIZE is used by the SCSI mid-layer to break up
 ** (or rather not merge) DMA's into managable chunks.
 ** On parisc, this is more of the software/tuning constraint
-** rather than the HW. I/O MMU allocation alogorithms can be
-** faster with smaller size is (to some degree).
+** rather than the HW. I/O MMU allocation algorithms can be
+** faster with smaller sizes (to some degree).
 */
 #define DMA_CHUNK_SIZE  (BITS_PER_LONG*PAGE_SIZE)
 
@@ -1037,10 +1038,12 @@
 		*/
 		if ((u64)sba_sg_iova(startsg) & PIDE_FLAG) {
 			u32 pide = (u64)sba_sg_iova(startsg) & ~PIDE_FLAG;
+			char *vaddr;
 			dma_offset = (unsigned long) pide & ~IOVP_MASK;
-			sba_sg_iova(startsg) = 0;
 			dma_sg++;
-			sba_sg_iova(dma_sg) = (char *)(pide | ioc->ibase);
+			vaddr = (char *)(pide | ioc->ibase);
+			dma_sg->page = virt_to_page(vaddr);
+			dma_sg->offset = (u64)vaddr * ~PAGE_MASK;
 			pdirp = &(ioc->pdir_base[pide >> IOVP_SHIFT]);
 			n_mappings++;
 		}
@@ -1115,7 +1118,8 @@
 	int n_mappings = 0;
 
 	while (nents > 0) {
-		unsigned long vaddr = (unsigned long) (startsg->address); 
+		unsigned long vaddr = (unsigned long) sba_sg_iova(startsg);
+						       
 
 		/*
 		** Prepare for first/next DMA stream
@@ -1127,7 +1131,7 @@
 
 		/* PARANOID: clear entries */
 		sba_sg_buffer(startsg) = sba_sg_iova(startsg);
-		sba_sg_iova(startsg) = 0;
+		sba_sg_clear_iova(startsg);
 		sba_sg_len(startsg) = 0;
 
 		/*
@@ -1162,7 +1166,7 @@
 				vcontig_end += sba_sg_len(startsg);
 				dma_len     += sba_sg_len(startsg);
 				sba_sg_buffer(startsg) = (char *)vaddr;
-				sba_sg_iova(startsg) = 0;
+				sba_sg_clear_iova(startsg);
 				sba_sg_len(startsg) = 0;
 				continue;
 			}
@@ -1178,9 +1182,9 @@
 			**
 			** Once we start a new VCONTIG chunk, dma_offset
 			** can't change. And we need the offset from the first
-			** chunk - not the last one. Ergo Successive chunks
-			** must start on page boundaries and dove tail
-			** with it's predecessor.
+			** chunk - not the last one. Ergo each successive chunk
+			** must start on a page boundary and dove-tail
+			** with its predecessor.
 			*/
 			sba_sg_len(vcontig_sg) = vcontig_len;
 
@@ -1196,7 +1200,7 @@
 				vcontig_end = vcontig_len + vaddr;
 				dma_len += vcontig_len;
 				sba_sg_buffer(startsg) = (char *)vaddr;
-				sba_sg_iova(startsg) = 0;
+				sba_sg_clear_iova(startsg);
 				continue;
 			} else {
 				break;
@@ -1211,9 +1215,13 @@
 		sba_sg_len(vcontig_sg) = vcontig_len;
 		dma_len = (dma_len + dma_offset + ~IOVP_MASK) & IOVP_MASK;
 		ASSERT(dma_len <= DMA_CHUNK_SIZE);
-		sba_sg_iova(dma_sg) = (char *) (PIDE_FLAG 
+		{ 
+			u64 vaddr = (PIDE_FLAG 
 			| (sba_alloc_range(ioc, dma_len) << IOVP_SHIFT)
 			| dma_offset);
+			dma_sg->page = virt_to_page(vaddr);
+			dma_sg->offset = vaddr & ~PAGE_MASK;
+		}
 		n_mappings++;
 	}
 
@@ -1248,7 +1256,8 @@
 	if (dev->dma_mask >= ioc->dma_mask) {
 		for (sg = sglist ; filled < nents ; filled++, sg++){
 			sba_sg_buffer(sg) = sba_sg_iova(sg);
-			sba_sg_iova(sg) = (char *)virt_to_phys(sba_sg_buffer(sg));
+			sg->page = virt_to_page(sba_sg_buffer(sg));
+			sg->offset = (u64)sba_sg_buffer(sg) & ~PAGE_MASK;
 		}
 #ifdef CONFIG_PROC_FS
 		spin_lock_irqsave(&ioc->res_lock, flags);
@@ -1260,10 +1269,13 @@
 #endif
 	/* Fast path single entry scatterlists. */
 	if (nents = 1) {
+		dma_addr_t vaddr;
 		sba_sg_buffer(sglist) = sba_sg_iova(sglist);
-		sba_sg_iova(sglist) = (char *)sba_map_single(dev,
+		vaddr = sba_map_single(dev,
 						sba_sg_buffer(sglist),
 						sba_sg_len(sglist), direction);
+		sglist->page = virt_to_page(vaddr);
+		sglist->offset = (u64)vaddr & ~PAGE_MASK;
 #ifdef CONFIG_PROC_FS
 		/*
 		** Should probably do some stats counting, but trying to
@@ -1628,7 +1640,7 @@
 			sba_dev->ioc[i].pdir_base[0] = 0x8000badbadc0ffeeULL;
 
 			for (reserved_iov = 0xA0000 ; reserved_iov < 0xC0000 ; reserved_iov += IOVP_SIZE) {
-				u64 *res_ptr = sba_dev->ioc[i].res_map;
+				u64 *res_ptr = (u64 *)sba_dev->ioc[i].res_map;
 				int index = PDIR_INDEX(reserved_iov);
 				int res_word;
 				u64 mask;
@@ -1759,7 +1771,7 @@
 
 	for (i = 0; i < PCI_NUM_RESOURCES; i++) {
 		if (pci_resource_flags(device, i) = IORESOURCE_MEM) {
-			hpa = ioremap(pci_resource_start(device, i),
+			hpa = (u64)ioremap(pci_resource_start(device, i),
 				pci_resource_len(device, i));
 			break;
 		}


--
Peter Chubb				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.


  parent reply	other threads:[~2002-05-30  4:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-29  3:56 [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems Peter Chubb
2002-05-29  8:05 ` [Linux-ia64] Missing files in to-linus-2.5 BK tree; build Andreas Schwab
2002-05-29 19:29 ` [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems Grant Grundler
2002-05-30  4:01 ` David Mosberger
2002-05-30  4:56 ` Peter Chubb [this message]
2002-05-30  5:49 ` Peter Chubb
2002-05-30  5:58 ` David Mosberger
2002-05-31  1:00 ` Grant Grundler

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=marc-linux-ia64-105590701905618@msgid-missing \
    --to=peter@chubb.wattle.id.au \
    --cc=linux-ia64@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