XF4 (mach64) help please

XF4 (mach64) help please

[Iain Sandoe]

Hi,
I'm having problems with XF4.0.99.02-0b .. and don't really know where to
start with debugging.  This is the first version of Xf4 I've tried -
installed as per HOW to from 3.3.6/Xpmac.

I've read (and acted upon, AFAICT) the readmes, and Franz's comments in
Kaoru's ftp directory.

1/  Key-mappings are screwed (big time) with any combination of "Option
XkbModel" I've tried - this is very unfortunate because I can't do SysRq or
VT switches - too much time spent watching fsck...

2/  The Mach64 driver is not loading.

3/  The fbdev driver loads & runs but usually crashes on X restart (which
occurs on log-out) - leaving me with a locked machine and another fsck...

uname -a:
Linux minerva 2.4.4-pre3 #1 Mon Apr 16 13:56:10 BST 2001 ppc unknown

rpm -qa|grep XFree
XFree86-twm-4.0.99.2-0b
XFree86-Xnest-4.0.99.2-0b
XFree86-Xvfb-4.0.99.2-0b
XFree86-xf86cfg-4.0.99.2-0b
XFree86-drivers-4.0.99.2-0b
XFree86-cyrillic-fonts-4.0.99.2-0b
XFree86-xdm-4.0.99.2-0b
XFree86-libs-4.0.99.2-0b
XFree86-tools-4.0.99.2-0b
XFree86-xfs-4.0.99.2-0b
XFree86-4.0.99.2-0b
XFree86-100dpi-fonts-4.0.99.2-0b
XFree86-75dpi-fonts-4.0.99.2-0b
XFree86-devel-4.0.99.2-0b
XFree86-doc-4.0.99.2-0b

tail of XFree86.0.log:

(II) ATI: ATI driver (version 6.2.3) for chipsets: ati
(II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 RE (PCI),
 ATI Rage 128 RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 RK (PCI),
 ATI Rage 128 RL (AGP), ATI Rage 128 Pro PD (PCI),
 ATI Rage 128 Pro PF (AGP), ATI Rage 128 Mobility LE (PCI),
 ATI Rage 128 Mobility LF (AGP), ATI Rage 128 Mobility MF (AGP),
 ATI Rage 128 Mobility ML (AGP)
(II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP),
 ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP)
(II) ATI:  Candidate "Device" section "Card0".
(WW) xf86UnMapVidMem: cannot find region for [0x30014c00,0x1c00]
(II) ATI:  Shared PCI/AGP Mach64 in slot 0:18:0 detected.
(II) ATI:  Shared PCI/AGP Mach64 in slot 0:18:0 assigned to active "Device"
section "Card0".
(II) Loading sub module "atimisc"
(II) LoadModule: "atimisc"
(II) Loading /usr/X11R6/lib/modules/drivers/atimisc_drv.o
(II) Module ati: vendor="The XFree86 Project"
 compiled for 4.0.99.2, module version = 6.2.3
 Module class: XFree86 Video Driver
 ABI class: XFree86 Video Driver, version 0.4
(II) resource ranges after probing:
 [0] -1 0xffffffff - 0xffffffff (0x1) MX[B]
 [1] -1 0x00000000 - 0x00000000 (0x1) MX[B]
 [2] -1 0xf3000000 - 0xf307ffff (0x80000) MX[B]
 [3] -1 0x80801000 - 0x80801fff (0x1000) MX[B]
 [4] -1 0x80804000 - 0x80804fff (0x1000) MX[B]
 [5] -1 0x80800000 - 0x808000ff (0x100) MX[B]
 [6] -1 0x80802000 - 0x80802fff (0x1000) MX[B](B)
 [7] -1 0x81000000 - 0x81ffffff (0x1000000) MX[B](B)
 [8] -1 0x0000ffff - 0x0000ffff (0x1) IX[B]
 [9] -1 0x00000000 - 0x00000000 (0x1) IX[B]
 [10] -1 0x00010000 - 0x000100ff (0x100) IX[B]
 [11] -1 0x00000c00 - 0x00000cff (0x100) IX[B](B)
(==) ATI(0): Chipset:  "ati".
(**) ATI(0): Depth 24, (**) framebuffer bpp 32
(--) ATI(0): ATI 3D Rage Pro graphics controller detected.
(--) ATI(0): Chip type 4750 "GP", version 4, foundry UMC, class 0, revision
0x01.
(--) ATI(0): PCI bus interface detected;  block I/O base is 0x0000.
(--) ATI(0): ATI Mach64 adapter detected.
(--) ATI(0): Internal RAMDAC (subtype 1) detected.
(==) ATI(0): RGB weight 888
(==) ATI(0): Default visual is TrueColor
(==) ATI(0): Using gamma correction (1.0, 1.0, 1.0)
(II) ATI(0): Using Mach64 accelerator CRTC.
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
 compiled for 4.0.99.2, module version = 0.0.2
 ABI class: XFree86 Video Driver, version 0.4
fbdevHWInit failed
crapping out here
(WW) ATI(0): xf86UnMapVidMem: cannot find region for [0x30016c00,0x1c00]
(II) UnloadModule: "ati"
(II) UnloadModule: "fbdevhw"
(II) Unloading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) UnloadModule: "atimisc"
(II) Unloading /usr/X11R6/lib/modules/drivers/atimisc_drv.o
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

====
Is there anything I can do to find out what's going on?

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 (mach64) help please

[Michel Dänzer]

Iain Sandoe wrote:

> 1/  Key-mappings are screwed (big time) with any combination of "Option
> XkbModel" I've tried - this is very unfortunate because I can't do SysRq or
> VT switches - too much time spent watching fsck...

You could try Option "XkbDisable" until you know how to configure XKB (I still
use it ;).


> 2/  The Mach64 driver is not loading.
>
> 3/  The fbdev driver loads & runs but usually crashes on X restart (which
> occurs on log-out) - leaving me with a locked machine and another fsck...

I beg your pardon? :) I'd be interested to see a log of that, preferrably with
debugging output enabled, but this smells like a framebuffer device bug.


> fbdevHWInit failed
> crapping out here

Do you use atyfb in console? The ati driver only works with that with option
"UseFBDev". No idea what it will do without that option, you'd have to find
out.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 (mach64) help please

[Ani Joshi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 966 bytes --]



On Mon, 16 Apr 2001, Michel [iso-8859-1] Dänzer wrote:

> > fbdevHWInit failed
> > crapping out here
>
> Do you use atyfb in console? The ati driver only works with that with option
> "UseFBDev". No idea what it will do without that option, you'd have to find
> out.

No, the "UseFBDev" option is totally useless in that version of the driver
as it is hardcoded to force the use of fbdevhw.

The attatched patch fixes the ati driver properly without the use of
fbdev.  Don't bother to try the option, it is not even implemented in the
driver.  The patch is against a current cvs tree.  If you try to hand
patch it against that older version with the fbdev hacks you will run into
problems as getting rid of the hacks is painful and time consuming.

I'm fairly sure this patch will be fine for all nonGX mach64's, although
I'm not entirely sure about the Lx/Mobility ones as I don't have one to
hack with.  Feedback is very welcome.


ani

[-- Attachment #2: Type: TEXT/PLAIN, Size: 9468 bytes --]

diff -uNr ati.orig/atimach64.c ati/atimach64.c
--- ati.orig/atimach64.c	Mon Apr 16 19:09:31 2001
+++ ati/atimach64.c	Mon Apr 16 19:09:25 2001
@@ -111,7 +111,13 @@
     }
 
     bus_cntl = inr(BUS_CNTL);
+#if !defined(__powerpc__)
     pATIHW->bus_cntl = (bus_cntl & ~BUS_HOST_ERR_INT_EN) | BUS_HOST_ERR_INT;
+#else
+    pATIHW->bus_cntl = bus_cntl;
+    pATIHW->config_cntl = inr(CONFIG_CNTL);
+#endif
+#if !defined(__powerpc__)
     if (pATI->Chip < ATI_CHIP_264VTB)
     {
         pATIHW->bus_cntl &= ~(BUS_FIFO_ERR_INT_EN | BUS_ROM_DIS);
@@ -175,12 +181,17 @@
         else
             pATIHW->config_cntl |= SetBits(2, CFG_MEM_AP_SIZE);
     }
+#endif /* !__powerpc__ */
 
     if (pATI->Chip >= ATI_CHIP_264VTB)
     {
+#if !defined(__powerpc__)
         pATIHW->mem_cntl = (pATI->LockData.mem_cntl &
             ~(CTL_MEM_LOWER_APER_ENDIAN | CTL_MEM_UPPER_APER_ENDIAN)) |
             SetBits(CTL_MEM_APER_BYTE_ENDIAN, CTL_MEM_LOWER_APER_ENDIAN);
+#else
+	pATIHW->mem_cntl = inr(MEM_CNTL);
+#endif
 
         switch (pATI->bitsPerPixel)
         {
@@ -190,13 +201,21 @@
                 break;
 
             case 16:
+#if X_BYTE_ORDER == X_LITTLE_ENDIAN
                 pATIHW->mem_cntl |= SetBits(CTL_MEM_APER_WORD_ENDIAN,
                     CTL_MEM_UPPER_APER_ENDIAN);
+#else
+		pATIHW->mem_cntl |= 0x4000000;
+#endif
                 break;
 
             case 32:
+#if X_BYTE_ORDER == X_LITTLE_ENDIAN
                 pATIHW->mem_cntl |= SetBits(CTL_MEM_APER_LONG_ENDIAN,
                     CTL_MEM_UPPER_APER_ENDIAN);
+#else
+		pATIHW->mem_cntl |= 0x8000000;
+#endif
                 break;
         }
     }
@@ -781,6 +800,7 @@
         }
     }
 
+#if !defined(__powerpc__)
     /* Aperture setup */
     outr(MEM_VGA_WP_SEL, pATIHW->mem_vga_wp_sel);
     outr(MEM_VGA_RP_SEL, pATIHW->mem_vga_rp_sel);
@@ -789,6 +809,7 @@
 
     outr(CONFIG_CNTL, pATIHW->config_cntl);
     outr(BUS_CNTL, pATIHW->bus_cntl);
+#endif
 
     if (pATI->Chip >= ATI_CHIP_264VTB)
         outr(MEM_CNTL, pATIHW->mem_cntl);
@@ -1600,6 +1621,24 @@
          */
         switch (iDWord)
         {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+            case  0:  xf86WriteMmio32Be(pDst +  0, 0, *(pSrc +  0));
+            case  1:  xf86WriteMmio32Be(pDst +  1, 0, *(pSrc +  1));
+            case  2:  xf86WriteMmio32Be(pDst +  2, 0, *(pSrc +  2));
+            case  3:  xf86WriteMmio32Be(pDst +  3, 0, *(pSrc +  3));
+            case  4:  xf86WriteMmio32Be(pDst +  4, 0, *(pSrc +  4));
+            case  5:  xf86WriteMmio32Be(pDst +  5, 0, *(pSrc +  5));
+            case  6:  xf86WriteMmio32Be(pDst +  6, 0, *(pSrc +  6));
+            case  7:  xf86WriteMmio32Be(pDst +  7, 0, *(pSrc +  7));
+            case  8:  xf86WriteMmio32Be(pDst +  8, 0, *(pSrc +  8));
+            case  9:  xf86WriteMmio32Be(pDst +  9, 0, *(pSrc +  9));
+            case 10:  xf86WriteMmio32Be(pDst + 10, 0, *(pSrc + 10));
+            case 11:  xf86WriteMmio32Be(pDst + 11, 0, *(pSrc + 11));
+            case 12:  xf86WriteMmio32Be(pDst + 12, 0, *(pSrc + 12));
+            case 13:  xf86WriteMmio32Be(pDst + 13, 0, *(pSrc + 13));
+            case 14:  xf86WriteMmio32Be(pDst + 14, 0, *(pSrc + 14));
+            case 15:  xf86WriteMmio32Be(pDst + 15, 0, *(pSrc + 15));
+#else
             case  0:  MMIO_OUT32(pDst +  0, 0, *(pSrc +  0));
             case  1:  MMIO_OUT32(pDst +  1, 0, *(pSrc +  1));
             case  2:  MMIO_OUT32(pDst +  2, 0, *(pSrc +  2));
@@ -1616,6 +1655,7 @@
             case 13:  MMIO_OUT32(pDst + 13, 0, *(pSrc + 13));
             case 14:  MMIO_OUT32(pDst + 14, 0, *(pSrc + 14));
             case 15:  MMIO_OUT32(pDst + 15, 0, *(pSrc + 15));
+#endif
 
             default:    /* Muffle compiler */
                 break;
@@ -1682,7 +1722,10 @@
      * Use scanline version of colour expansion, not only for the non-ix86
      * case, but also to avoid PCI retries.
      */
-    pXAAInfo->ScanlineCPUToScreenColorExpandFillFlags =
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+    pXAAInfo->ScanlineCPUToScreenColorExpandFillFlags = BIT_ORDER_IN_BYTE_MSBFIRST;
+#endif
+    pXAAInfo->ScanlineCPUToScreenColorExpandFillFlags |=
         LEFT_EDGE_CLIPPING | LEFT_EDGE_CLIPPING_NEGATIVE_X |
         CPU_TRANSFER_PAD_DWORD | SCANLINE_PAD_DWORD;
     if (pATI->XModifier != 1)
diff -uNr ati.orig/atipreinit.c ati/atipreinit.c
--- ati.orig/atipreinit.c	Mon Apr 16 19:09:31 2001
+++ ati/atipreinit.c	Mon Apr 16 19:09:25 2001
@@ -640,6 +640,7 @@
 
 #endif /* AVOID_CPIO */
 
+#if !defined(__powerpc__)
     pATI->Block0Base = 0;       /* Might no longer be valid */
     if ((pVideo = pATI->PCIInfo))
     {
@@ -655,6 +656,10 @@
                 pATI->Block0Base += 0x0400U;
         }
     }
+#else
+    if ((pVideo = pATI->PCIInfo))
+       pATI->Block0Base = pVideo->memBase[0] + 0x7ff000;
+#endif
 
     pScreenInfo->racIoFlags =
         RAC_FB | RAC_COLORMAP | RAC_VIEWPORT | RAC_CURSOR;
@@ -779,6 +784,7 @@
         case ATI_ADAPTER_MACH64:
             /* Find and mmap() MMIO area */
             Block0Base = pATI->Block0Base;
+#if !defined(__powerpc__)
             do
             {
                 /* Only allow auxiliary aperture if it exists */
@@ -808,6 +814,9 @@
                 ATIMapMach64(pScreenInfo->scrnIndex, pATI);
             } while (0);
             pATI->Block0Base = Block0Base;
+#else
+            ATIMapMach64(pScreenInfo->scrnIndex, pATI);
+#endif
 
 #ifdef AVOID_CPIO
 
@@ -977,6 +986,7 @@
         pATI->ClockDescriptor = ATIClockDescriptors[ATI_CLOCK_FIXED];
         pATI->ClockNumberToProgramme = -1;
 
+#if !defined(__powerpc__)
         ROMTable = BIOSWord(0x48U);
         if ((ROMTable + 0x12U) > BIOSSize)
             ROMTable = 0;
@@ -1022,6 +1032,7 @@
             }
         }
         else
+#endif /* !__powerpc__ */
         {
             /*
              * Compensate for BIOS absence.  Note that the reference
diff -uNr ati.orig/atiprobe.c ati/atiprobe.c
--- ati.orig/atiprobe.c	Mon Apr 16 19:09:31 2001
+++ ati/atiprobe.c	Mon Apr 16 19:09:25 2001
@@ -641,6 +641,15 @@
         pATI->PCIInfo = pVideo;
         ChipType = pVideo->chipType;
 
+# if defined(__powerpc__)
+        pATI->Block0Base = pVideo->memBase[0] + 0x7ff000;
+        if (ATIDetectMach64(pATI, ChipType, Chip)) {
+            return pATI;
+        } else {
+            return NULL;
+        } 
+#endif   
+
         /*
          * Probe through auxiliary MMIO aperture if one exists.  Because such
          * apertures can be enabled/disabled only through PCI, this probes no
@@ -1331,6 +1340,7 @@
 
     if (xf86PciVideoInfo)
     {
+#if !defined(__powerpc__)
         if (nATIGDev)
         {
 
@@ -1699,6 +1709,7 @@
 #endif /* AVOID_CPIO */
 
         }
+#endif
 
         /* Lastly, look for block I/O devices */
         for (i = 0;  (pVideo = xf86PciVideoInfo[i++]);  )
@@ -1750,7 +1761,11 @@
             /* Probe for it */
             xf86SetPciVideo(pVideo, MEM_IO);
 
+#if defined(__powerpc__)
+	    pATI = ATIMach64Probe(pVideo, pVideo->memBase[0], MEM_IO, Chip);
+#else
             pATI = ATIMach64Probe(pVideo, pVideo->ioBase[1], BLOCK_IO, Chip);
+#endif
             if (pATI)
             {
                 sprintf(Identifier, "Shared PCI/AGP Mach64 in slot %d:%d:%d",
diff -uNr ati.orig/atiregs.h ati/atiregs.h
--- ati.orig/atiregs.h	Mon Apr 16 19:09:31 2001
+++ ati/atiregs.h	Mon Apr 16 19:09:25 2001
@@ -53,9 +53,14 @@
 #define SPARSE_IO_PORT		(SPARSE_IO_BASE | IO_BYTE_SELECT)
 #define BLOCK_IO_PORT		(BLOCK_IO_BASE | IO_BYTE_SELECT)
 
+#if !defined(__powerpc__)
 #define IOPortTag(_SparseIOSelect, _BlockIOSelect)	\
 	(SetBits(_SparseIOSelect, SPARSE_IO_SELECT) |	\
 	 SetBits(_BlockIOSelect, DWORD_SELECT))
+#else
+#define IOPortTag(_SparseIOSelect, _BlockIOSelect)     \
+	SetBits(_BlockIOSelect, BLOCK_SELECT | MM_IO_SELECT)
+#endif
 #define SparseIOTag(_IOSelect)	IOPortTag(_IOSelect, 0)
 #define BlockIOTag(_IOSelect)	IOPortTag(0, _IOSelect)
 
diff -uNr ati.orig/atiscreen.c ati/atiscreen.c
--- ati.orig/atiscreen.c	Mon Apr 16 19:09:31 2001
+++ ati/atiscreen.c	Mon Apr 16 19:09:25 2001
@@ -225,8 +225,10 @@
 
 #endif /* AVOID_CPIO */
 
+#if !defined(__powerpc__)
     /* Initialise DGA support */
     (void)ATIDGAInit(pScreenInfo, pScreen, pATI);
+#endif
 
     /* Setup acceleration */
     if (!ATIInitializeAcceleration(pScreenInfo, pScreen, pATI))
diff -uNr ati.orig/atividmem.c ati/atividmem.c
--- ati.orig/atividmem.c	Mon Apr 16 19:09:31 2001
+++ ati/atividmem.c	Mon Apr 16 19:09:25 2001
@@ -133,7 +133,11 @@
 )
 {
     if (pATI->pMMIO)
+#if !defined(__powerpc__)
         xf86UnMapVidMem(iScreen, pATI->pMMIO, getpagesize());
+#else
+	xf86UnMapVidMem(iScreen, pATI->pMMIO, 0x1c00);
+#endif
 
     pATI->pMMIO = pATI->pBlock[0] = pATI->pBlock[1] = NULL;
 }
@@ -261,9 +265,15 @@
     {
         unsigned long MMIOBase = pATI->Block0Base & ~(PageSize - 1);
 
-        if (pVideo)
+        if (pVideo) {
             pATI->pMMIO = xf86MapPciMem(iScreen, VIDMEM_MMIO,
+#if !defined(__powerpc__)
                 Tag, MMIOBase, PageSize);
+#else
+		Tag, MMIOBase, 0x1c00);
+	    pATI->pMMIO += 0xc00;
+#endif
+	}
         else
             pATI->pMMIO = xf86MapVidMem(iScreen, VIDMEM_MMIO,
                 MMIOBase, PageSize);

Re: XF4 (mach64) help please

[Iain Sandoe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="", Size: 1703 bytes --]


Hi Ani,

excellent...

> The attatched patch fixes the ati driver properly without the use of
> fbdev.  Don't bother to try the option, it is not even implemented in the
> driver.  The patch is against a current cvs tree.  If you try to hand
> patch it against that older version with the fbdev hacks you will run into
> problems as getting rid of the hacks is painful and time consuming.
>
> I'm fairly sure this patch will be fine for all nonGX mach64's, although
> I'm not entirely sure about the Lx/Mobility ones as I don't have one to
> hack with.  Feedback is very welcome.

Yes, it works wonderfully:

built against 4.0.99.3 pulled this morning (05:30 BST)
2.4.4-pre3 (BK yesterday)

----

Please note that "make World" fails for me (with build Servers only as an
option in host.def)  [the mesa stuff, amongst other things falls over]

However, the drivers build and I copied ati_drv.o, ati_misc.o over Kaoru's
4.0.99.2-0b rpms.  (I also copied libfbdevhw.a - but, of course, that no
longer loads).

----

Results:

+ no more flickering lines 2cm from left of screen
+ excellent scroll acceleration.

I'll do X11perf if you're interested - otherwise there's plenty of other
things to do... ;-)

Two points:

1/  the cursor disappears after about 5 seconds __only__ when it's over the
active window (it stays there fine when over an inactive window or the
desktop) -- KDE 2.0beta.

2/  how difficult would it be to plumb the scroll acceleration back into the
console driver?  (would one need access to the NDA stuff?) -- the scrolling
of console is a real problem in blocking sound :-/

thanks for the excellent work,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 (mach64) help please

[William Blew]

On Thu, 19 Apr 2001, Iain Sandoe wrote:

> 2/  how difficult would it be to plumb the scroll acceleration back into the
> console driver?  (would one need access to the NDA stuff?) -- the scrolling
> of console is a real problem in blocking sound :-/

For mach64 at least, I would start by porting the CopyScreen2Screen XXA
operation into the kernel and then using it during scrolling.

This would involve both a port of the operation itself and of the setup of
the mach64 2D engine as per the ati driver.
--
William Blew, wblew@home.com
Gamer by Choice, Geek by Birth


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 (mach64) help please

[Ani Joshi]

On Thu, 19 Apr 2001, William Blew wrote:

> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>
> > 2/  how difficult would it be to plumb the scroll acceleration back into the
> > console driver?  (would one need access to the NDA stuff?) -- the scrolling
> > of console is a real problem in blocking sound :-/
>
> For mach64 at least, I would start by porting the CopyScreen2Screen XXA
> operation into the kernel and then using it during scrolling.

This is already done by atyfb in the kernel, however the problem lies in
the entire fbcon layer where there is some improper locking/interrupts
going on there.  This was discussed here and on linux-fbdev a few months
ago and I believe will be addressed in 2.5.


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 (mach64) help please

[Iain Sandoe]

On Thu, Apr 19, 2001,  Ani Joshi wrote:
> On Thu, 19 Apr 2001, William Blew wrote:
>
>> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>>
>> > 2/  how difficult would it be to plumb the scroll acceleration back into
the
>> > console driver?  (would one need access to the NDA stuff?) -- the scrolling
>> > of console is a real problem in blocking sound :-/
>>
>> For mach64 at least, I would start by porting the CopyScreen2Screen XXA
>> operation into the kernel and then using it during scrolling.
>
> This is already done by atyfb in the kernel,

then why is the atyfb scroll (and fbdevhw) _so_ much slower than the X
'native' driver ... the same reason as below?

>however the problem lies in
> the entire fbcon layer where there is some improper locking/interrupts
> going on there.  This was discussed here and on linux-fbdev a few months
> ago and I believe will be addressed in 2.5.

and there is a (temporary) fix for it (I believe) involving a patch from
Andrew Morton - (which I haven't had time to try on PPC yet).  Will that fix
the slow console scroll as well?

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 (mach64) help please

[Geert Uytterhoeven]

On Thu, 19 Apr 2001, Iain Sandoe wrote:
> On Thu, Apr 19, 2001,  Ani Joshi wrote:
> > On Thu, 19 Apr 2001, William Blew wrote:
> >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
> >> > 2/  how difficult would it be to plumb the scroll acceleration back into
> the
> >> > console driver?  (would one need access to the NDA stuff?) -- the scrolling
> >> > of console is a real problem in blocking sound :-/
> >>
> >> For mach64 at least, I would start by porting the CopyScreen2Screen XXA
> >> operation into the kernel and then using it during scrolling.
> >
> > This is already done by atyfb in the kernel,
>
> then why is the atyfb scroll (and fbdevhw) _so_ much slower than the X
> 'native' driver ... the same reason as below?

Because xterm uses jump scroll? Try scrolling line by line in X11.

> >however the problem lies in
> > the entire fbcon layer where there is some improper locking/interrupts

Read: the entire console layer. Fbcon cannot (read: couldn't) use interrupts
because the upper console layer disables (disabled) interrupts.

> > going on there.  This was discussed here and on linux-fbdev a few months
> > ago and I believe will be addressed in 2.5.
>
> and there is a (temporary) fix for it (I believe) involving a patch from
> Andrew Morton - (which I haven't had time to try on PPC yet).  Will that fix
> the slow console scroll as well?

It's supposed to. Haven't tried it yet, though.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 (mach64) help please

[Iain Sandoe]

On  Thu, Apr 19, 2001, Geert Uytterhoeven wrote:
> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>> On Thu, Apr 19, 2001,  Ani Joshi wrote:
>> > On Thu, 19 Apr 2001, William Blew wrote:
>> >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>> >> > 2/  how difficult would it be to plumb the scroll acceleration back into
>> the
>> >> > console driver?  (would one need access to the NDA stuff?) -- the
scrolling
>> >> > of console is a real problem in blocking sound :-/
>> >>
>> >> For mach64 at least, I would start by porting the CopyScreen2Screen XXA
>> >> operation into the kernel and then using it during scrolling.
>> >
>> > This is already done by atyfb in the kernel,
>>
>> then why is the atyfb scroll (and fbdevhw) _so_ much slower than the X
>> 'native' driver ... the same reason as below?
>
> Because xterm uses jump scroll? Try scrolling line by line in X11.

hmmm.  I was comparing "before" and "after" changing to Ani's new ati_drv.o
(before was using libfbdevhw.a) - in all other respects the configuration
was identical.

this is mach64 (3DU Pro) on G3/beige - the difference seemed to be striking
enough to comment (but I guess I could wind it back and do an X11Perf).

>> >however the problem lies in
>> > the entire fbcon layer where there is some improper locking/interrupts
>
> Read: the entire console layer. Fbcon cannot (read: couldn't) use interrupts
> because the upper console layer disables (disabled) interrupts.
>
>> > going on there.  This was discussed here and on linux-fbdev a few months
>> > ago and I believe will be addressed in 2.5.
>>
>> and there is a (temporary) fix for it (I believe) involving a patch from
>> Andrew Morton - (which I haven't had time to try on PPC yet).  Will that fix
>> the slow console scroll as well?
>
> It's supposed to. Haven't tried it yet, though.

I will ASAP - AFAICT the various blocking issues are the main problem with
(pmac) sound now.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/