Missing files in to-linus-2.5 BK tree; build problems

Hi David,
The files perfmon_itanium.h, perfmon_generic.h and
perfmon_mckinley.h are missing from the bk archive. I believe they should have been added at:

      [email protected] 2002-05-24 18:45:43-0700 [email protected]

Also, what did you decide to do with the scatter-gather list changes
(member `address' no longer exists)? The changes to sb_iommu.c are
non-trivial, because it looks as if the address field was overloaded...

Peter C

Peter Chubb <[email protected]> writes:

|> Also, what did you decide to do with the scatter-gather list changes
|> (member `address' no longer exists)?   The changes to sb_iommu.c are
|> non-trivial, because it looks as if the address field was
|> overloaded...

Just look at how lib/swiotlb.c is handling this and replace all references to the address member by zero.

Andreas.

Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Peter,
I promised David I would resolve that. I wrote the original code for parisc-linux and Alex Williamson ported that to HP ZX1 chipset.

My excuses are I don't muck with bk, don't have a 2.5 tree lying around, and have been fighting 2.4-related fires that relate to HP shipping a revenue generating product.

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

apologies,
grant

Grant> My excuses are I don't muck with bk, don't have a 2.5 tree Grant> lying around, and have been fighting 2.4-related fires that Grant> relate to HP shipping a revenue generating product.

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

Note that the to-linus-2.5 tree is intended for Linus only. It's not complete in any fashion (well, some day it will be...). I am working on the latest 2.5 patch, but keep getting delayed (and of course Linus keeps cranking out new versions...).

	--david

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

@@ -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 [email protected]
You are lost in a maze of BitKeeper repositories, all almost the same.

David> Note that the to-linus-2.5 tree is intended for Linus only. David> It's not complete in any fashion (well, some day it will David> be...). I am working on the latest 2.5 patch, but keep getting David> delayed (and of course Linus keeps cranking out new David> versions...).

Doesn't he just!

It seems to me that there are several categories of things in the patches you've been cranking out.

1. Support for devices not in the main tree (e.g., the i460GX, the qlogic 2200, etc)

2. Extra features (like the early printk support) that in their current form are too ugly to go into the mainline, but are really useful for IA64.

3. Changes in architecture specific code for
-- matching changes in mainline code (e.g., the scatterlist change, the TLB shootdown change, etc)
-- enhancements to IA64-specific code (like the new perfmon support) -- New subarchitectures (e.g., SN1, ZX1)

4. Changes in mainline to fix things that break on IA64. (e.g., ACPI)

It seems to me that it *should* be possible to get all except category 2 synced into the mainline code. One of the things I've been trying to do occasionally is to compile a ia64-patched kernel on different architectures to see what breaks. Surprisingly little does.

BTW, I upgraded the BIOS on lemon.gelato.unsw.edu.au, the machine that had the time haring off into the future. It seems OK now.

One of the BIOS notes said that the AGP aperture for the I460GX was fixed not to overlap the PCI space. Does this mean that some of the hacks in the DRM are no longer necessary?

--
Peter C [email protected]
You are lost in a maze of BitKeeper repositories, all almost the same.

Peter> It seems to me that it *should* be possible to get all except Peter> category 2 synced into the mainline code. One of the things Peter> I've been trying to do occasionally is to compile a Peter> ia64-patched kernel on different architectures to see what Peter> breaks. Surprisingly little does.

Yes, absolutely. I'm working on that, but it's slower than I'd like it to be. The DRM patches are next, but not being a DRM expert doesn't help. Of course, I always appreciate help (as long as I'm informed on who's submitting what).

Peter> BTW, I upgraded the BIOS on lemon.gelato.unsw.edu.au, the Peter> machine that had the time haring off into the future. It Peter> seems OK now.

Great!

Peter> One of the BIOS notes said that the AGP aperture for the Peter> I460GX was fixed not to overlap the PCI space. Does this Peter> mean that some of the hacks in the DRM are no longer Peter> necessary?

I don't think so. The "hacks" are not workarounds; they reflect the fact that on Itanium, CPU accesses to (AGP) memory do not go through AGP GART translation (somebody please correct me if I got the details wrong...).

	--david

Peter,
certainly.

		if ((u64)sba_sg_iova(startsg) & PIDE_FLAG) {
			u32 pide = (u64)sba_sg_iova(startsg) & ~PIDE_FLAG;