All of lore.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 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.