INIT_MMAP on sparc64

INIT_MMAP on sparc64

[Sten]

I have been playing around with linux on an ultra60,
and have had some struggles with the kernel.
The most annoying one is that somewhere in between
kernels 2.4.7 and 2.4.12 someone delete the define
of INIT_MMAP from the processor.h of sparc64, which
doesnt really help when trying to compile a kernel.

Putting in the define of 2.4.7 got me on the way.
So putting it back might be a nice idea ;)

Ow well, still better as solaris, for my purposes
atleast.

--

Sten Spans

Re: INIT_MMAP on sparc64

[David S. Miller]

Don't use AC kernels, I do not keep track of them and therefore
Sparc64 builds are likely to not work.

Use Linus's kernels, I keep him uptodate with all the latest
changes and I make sure his releases compile on sparc64.

Franks a lot,
David S. Miller
davem@redhat.com

Re: INIT_MMAP on sparc64

[Sten]

On Sun, 21 Oct 2001, David S. Miller wrote:

>
> Don't use AC kernels, I do not keep track of them and therefore
> Sparc64 builds are likely to not work.
>
> Use Linus's kernels, I keep him uptodate with all the latest
> changes and I make sure his releases compile on sparc64.

ahah, I had quite a few problems getting framebuffer, dri
and all to work on each kernel that I overlooked that.

With the linux 2.4.12 I cant seem to get dri to compile
for instance.

drivers/char/drm/drm.o: In function `ffb_vm_shm_nopage':
drivers/char/drm/drm.o(.text+0x4ba8): undefined reference to
`virt_to_bus_not_defined_use_pci_map'
drivers/char/drm/drm.o: In function `ffb_vm_dma_nopage':
drivers/char/drm/drm.o(.text+0x4e4c): undefined reference to
`virt_to_bus_not_defined_use_pci_map'
make: *** [vmlinux] Error 1

The main annoiance is the 3.5mb size limitation
which one reaches quite quickly.

ow well, I am gonna trow a some time at the 3ware driver
to see how long it'll take before I give up trying to get
it to work on sparc64 ;).


So long and give the penguin some fish.

--
Sten Spans

Re: INIT_MMAP on sparc64

[David S. Miller]

DRI works perfectly fine in my current sources, patches below.

Wrt the 3.5MB size limitation, use modules man.

diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/drivers/char/drm/drm_drv.h linux/drivers/char/drm/drm_drv.h
--- vanilla/linux/drivers/char/drm/drm_drv.h	Fri Sep 14 14:04:07 2001
+++ linux/drivers/char/drm/drm_drv.h	Thu Oct 18 09:03:58 2001
@@ -1047,6 +1047,25 @@
 
 	atomic_inc( &dev->counts[_DRM_STAT_UNLOCKS] );
 
+#if __HAVE_KERNEL_CTX_SWITCH
+	/* We no longer really hold it, but if we are the next
+	 * agent to request it then we should just be able to
+	 * take it immediately and not eat the ioctl.
+	 */
+	dev->lock.pid = 0;
+	{
+		__volatile__ unsigned int *plock = &dev->lock.hw_lock->lock;
+		unsigned int old, new, prev, ctx;
+
+		ctx = lock.context;
+		do {
+			old  = *plock;
+			new  = ctx;
+			prev = cmpxchg(plock, old, new);
+		} while (prev != old);
+	}
+	wake_up_interruptible(&dev->lock.lock_queue);
+#else
 	DRM(lock_transfer)( dev, &dev->lock.hw_lock->lock,
 			    DRM_KERNEL_CONTEXT );
 #if __HAVE_DMA_SCHEDULE
@@ -1061,6 +1080,7 @@
 			DRM_ERROR( "\n" );
 		}
 	}
+#endif /* !__HAVE_KERNEL_CTX_SWITCH */
 
 	unblock_all_signals();
 	return 0;
diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/drivers/char/drm/drm_vm.h linux/drivers/char/drm/drm_vm.h
--- vanilla/linux/drivers/char/drm/drm_vm.h	Thu Oct 18 19:06:21 2001
+++ linux/drivers/char/drm/drm_vm.h	Sat Oct 20 04:40:42 2001
@@ -531,10 +531,17 @@
 			vma->vm_flags |= VM_IO;	/* not in core dump */
 		}
 		offset = DRIVER_GET_REG_OFS();
+#ifdef __sparc__
+		if (io_remap_page_range(vma->vm_start,
+					VM_OFFSET(vma) + offset,
+					vma->vm_end - vma->vm_start,
+					vma->vm_page_prot, 0))
+#else
 		if (remap_page_range(vma->vm_start,
 				     VM_OFFSET(vma) + offset,
 				     vma->vm_end - vma->vm_start,
 				     vma->vm_page_prot))
+#endif
 				return -EAGAIN;
 		DRM_DEBUG("   Type = %d; start = 0x%lx, end = 0x%lx,"
 			  " offset = 0x%lx\n",
diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/drivers/char/drm/ffb_drv.c linux/drivers/char/drm/ffb_drv.c
--- vanilla/linux/drivers/char/drm/ffb_drv.c	Sun Aug 12 11:23:32 2001
+++ linux/drivers/char/drm/ffb_drv.c	Thu Oct 18 09:03:58 2001
@@ -1,4 +1,4 @@
-/* $Id: ffb_drv.c,v 1.15 2001/08/09 17:47:51 davem Exp $
+/* $Id: ffb_drv.c,v 1.16 2001/10/18 16:00:24 davem Exp $
  * ffb_drv.c: Creator/Creator3D direct rendering driver.
  *
  * Copyright (C) 2000 David S. Miller (davem@redhat.com)
@@ -45,16 +45,16 @@
 #define DRIVER_PRESETUP()	do {		\
 	int _ret;				\
 	_ret = ffb_presetup(dev);		\
-	if(_ret != 0) return _ret;		\
+	if (_ret != 0) return _ret;		\
 } while(0)
 
 /* Free private structure */
 #define DRIVER_PRETAKEDOWN()	do {				\
-	if(dev->dev_private) kfree(dev->dev_private);		\
+	if (dev->dev_private) kfree(dev->dev_private);		\
 } while(0)
 
 #define DRIVER_POSTCLEANUP()	do {				\
-	if(ffb_position != NULL) kfree(ffb_position);		\
+	if (ffb_position != NULL) kfree(ffb_position);		\
 } while(0)
 
 /* We have to free up the rogue hw context state holding error or 
@@ -66,7 +66,9 @@
 	int idx;							\
 									\
 	idx = context - 1;						\
-	if (fpriv && fpriv->hw_state[idx] != NULL) {			\
+	if (fpriv &&							\
+	    context != DRM_KERNEL_CONTEXT &&				\
+	    fpriv->hw_state[idx] != NULL) {				\
 		kfree(fpriv->hw_state[idx]);				\
 		fpriv->hw_state[idx] = NULL;				\
 	}								\

Re: INIT_MMAP on sparc64

[Benjamin LaHaise]

On Sun, Oct 21, 2001 at 06:15:23PM -0700, David S. Miller wrote:
> 
> DRI works perfectly fine in my current sources, patches below.

On a side note of coding style, the following:

> +#ifdef __sparc__
> +		if (io_remap_page_range(vma->vm_start,
> +					VM_OFFSET(vma) + offset,
> +					vma->vm_end - vma->vm_start,
> +					vma->vm_page_prot, 0))
> +#else
>  		if (remap_page_range(vma->vm_start,
>  				     VM_OFFSET(vma) + offset,
>  				     vma->vm_end - vma->vm_start,
>  				     vma->vm_page_prot))
> +#endif

should really be turned into io_remap_page_range(...) unconditionally 
and add a #define for io_remap_page_range in the arch specific code.  
Having #ifdef's all over generic code is just ugly.

		-ben

Re: INIT_MMAP on sparc64

[Sten]

On Sun, 21 Oct 2001, David S. Miller wrote:

>
> DRI works perfectly fine in my current sources, patches below.
>
> Wrt the 3.5MB size limitation, use modules man.

mjes, the kernel module loader is nice, it's just
that I know what hardware I have and like to build
a kernel with what I need.

Ow well. I wonder if the dri driver is as funny as the hme one ;)

-- 

Sten Spans

Re: INIT_MMAP on sparc64

[David S. Miller]

   From: Sten <sten@blinkenlights.nl>
   Date: Tue, 23 Oct 2001 00:39:35 +0200 (CEST)
   
   mjes, the kernel module loader is nice, it's just
   that I know what hardware I have and like to build
   a kernel with what I need.
   
"arch/sparc64/defconfig" handles every onboard necessary device any
machine in my sparc64 collection has, and that kernel is under 3.5MB

It probably encompasses all the hardware you really need too :-)

Franks a lot,
David S. Miller
davem@redhat.com

Re: INIT_MMAP on sparc64

[Sten]

On Mon, 22 Oct 2001, David S. Miller wrote:

>    From: Sten <sten@blinkenlights.nl>
>    Date: Tue, 23 Oct 2001 00:39:35 +0200 (CEST)
>
>    mjes, the kernel module loader is nice, it's just
>    that I know what hardware I have and like to build
>    a kernel with what I need.
>
> "arch/sparc64/defconfig" handles every onboard necessary device any
> machine in my sparc64 collection has, and that kernel is under 3.5MB
>
> It probably encompasses all the hardware you really need too :-)

Well the thing is that I like todo evil things,
like connecting sgi flatpanels to creator3d's, using
non sun blessed ( aka sub 1000$ ) ethernet cards or
sticking in wierd raid cards.

Which is why I like linux ;)

Having source is great because I can break it,
and maybe learn something in the process.

--

Sten Spans

Re: INIT_MMAP on sparc64

[David S. Miller]

   From: Sten <sten@blinkenlights.nl>
   Date: Tue, 23 Oct 2001 00:50:42 +0200 (CEST)

   Well the thing is that I like todo evil things,
   like connecting sgi flatpanels to creator3d's, using
   non sun blessed ( aka sub 1000$ ) ethernet cards or
   sticking in wierd raid cards.
   
   Which is why I like linux ;)
   
   Having source is great because I can break it,
   and maybe learn something in the process.

All of this is irrelevant to going over the 3.5MB mark,
I contend that your machine simply does not need it no matter
what obscure stuff you stick into it :-)

Turn off the PCI device names, that is usually what eats up a
lot of space and lspci provides the same info anyways...

Franks a lot,
David S. Miller
davem@redhat.com

Re: INIT_MMAP on sparc64

[Sten]

On Mon, 22 Oct 2001, David S. Miller wrote:

>    From: Sten <sten@blinkenlights.nl>
>    Date: Tue, 23 Oct 2001 00:50:42 +0200 (CEST)
>
>    Well the thing is that I like todo evil things,
>    like connecting sgi flatpanels to creator3d's, using
>    non sun blessed ( aka sub 1000$ ) ethernet cards or
>    sticking in wierd raid cards.
>
>    Which is why I like linux ;)
>
>    Having source is great because I can break it,
>    and maybe learn something in the process.
>
> All of this is irrelevant to going over the 3.5MB mark,
> I contend that your machine simply does not need it no matter
> what obscure stuff you stick into it :-)

I wonder if pci to isa adaptors exist ;)

> Turn off the PCI device names, that is usually what eats up a
> lot of space and lspci provides the same info anyways...

jup, that's what I came up with as well.

Off to bed now, many more boxen to upgrade tomorrow,
gotta love ptrace. Especially when they annouce the hole
on friday 16:30 just when you prepare for going home.

--

Sten Spans

Re: INIT_MMAP on sparc64

[Jeff Garzik]

"David S. Miller" wrote:
> Turn off the PCI device names, that is usually what eats up a
> lot of space and lspci provides the same info anyways...

...after updating lspci's copy of pci.ids, of course :)

-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno

Re: INIT_MMAP on sparc64

[Mr. James W. Laferriere]

	Hello Dave ,

On Sun, 21 Oct 2001, David S. Miller wrote:
> DRI works perfectly fine in my current sources, patches below.
>
> Wrt the 3.5MB size limitation, use modules man.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	Why man ! ,  Alpha does not have this limit ?  Why Sparc ?
	THese are valid ?'s I beleive .  Tia ,  JimL

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: INIT_MMAP on sparc64

[David S. Miller]

   From: "Mr. James W. Laferriere" <babydr@baby-dragons.com>
   Date: Mon, 22 Oct 2001 19:18:38 -0400 (EDT)

   	Why man ! ,  Alpha does not have this limit ?  Why Sparc ?

It has to do with a combination of what OBP guarentees the boot
loader and limitations within the boot signature.

It would require a lot of SILO and kernel work to eliminate.

Franks a lot,
David S. Miller
davem@redhat.com