xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[R Shapiro]

[I'm posting to dev since xf 4 support for linuxppc still seems to be
in the development stage]

Subject says it all, really.  I can't get the xf 4.0.x driver to work
either on a rev. a beige G3 with rage II or a rev. b beige G3 with
rage pro.  Should it be working, or am I wasting my time trying?  Fwiw
the r128 driver works great on my G4....

Specifics: with the ati driver selected, xf throws away my mode def,
since it thinks (incorrectly) that there isn't enough vram, and then
quits since it can't find any valid modes. In both cases I'm running
4.0.1 from Franz Sirl's linuxppc page.  I also tried 4.0.0 from the
Howarth page and got exactly the same results.  I haven't tried
compiling xf myself but I'm perfectly willing to do so if that's
likely to help (eg if there are some known ati patches missing from
the Sirl rpms).

The rev. a machine is running 2.2.15pre3 from the 2000 cd, booted via
BootX with "no video driver" checked.  The rev. b machine is running a
2.2.16 kernel compiled from kernel.org sources, booted directly from
OF.  Both are started with kernel args video=atyfb:vmode:20,cmode:16.

I can run xf 4.0.x using the fbdev driver, more or less, with an
otherwise identical XF86Config, though xf with fbdev is noticably
slower than Xpmac.rev10.  Also the screen is oddly "wrapped" on the
rage II machine with the fbdev driver: I can see the full screen but
the virtual edge starts about 75% in, instead of matching the physical
edge, and then wraps around.  I don't see this artifact on the rage
pro G3.

Eventually I want to get multiple monitors going.  I already have what
I think is a valid config file for it, but I'm guessing I'll never be
able to do it with fbdev.

A search of the lists on this topic suggested only that there were
some known issues with the ati driver some time ago, but I couldn't
find anything like a definitive answer specific to the beige G3s.

If you have any suggestions at all, please cc: me directly -- I'll see
it more quickly that way.

Thanks -

--
reshapiro@mediaone.net


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michel Dänzer]

R Shapiro schrieb:

> Specifics: with the ati driver selected, xf throws away my mode def,
> since it thinks (incorrectly) that there isn't enough vram,

Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?

> and then quits since it can't find any valid modes. In both cases I'm
> running 4.0.1 from Franz Sirl's linuxppc page.

While we're at it, can you please send me the URL of those?

> I also tried 4.0.0 from the Howarth page and got exactly the same results.

I think they're too old to work with Mach based ATI chips.

> I haven't tried compiling xf myself but I'm perfectly willing to do so if
> that's likely to help (eg if there are some known ati patches missing from
> the Sirl rpms).

I thought they contained the necessary stuff from Ani Joshi's rsync tree. If
you try to build yourself, you absolutely need that.


> The rev. a machine is running 2.2.15pre3 from the 2000 cd, booted via
> BootX with "no video driver" checked.

I don't think this can work with the ati driver, it needs atyfb.


> The rev. b machine is running a 2.2.16 kernel compiled from kernel.org
> sources, booted directly from OF.  Both are started with kernel args
> video=atyfb:vmode:20,cmode:16.
>
> I can run xf 4.0.x using the fbdev driver, more or less, with an
> otherwise identical XF86Config, though xf with fbdev is noticably
> slower than Xpmac.rev10.

No big surprise as the fbdev driver doesn't have any hardware acceleration.


> Also the screen is oddly "wrapped" on the rage II machine with the fbdev
> driver: I can see the full screen but the virtual edge starts about 75% in,
> instead of matching the physical edge, and then wraps around.  I don't see
> this artifact on the rage pro G3.

This is a known problem, which is also kind of fixed in Ani's tree AFAIK. I'm
currently working with Geert Uytterheuven to get the definite fix.


> Eventually I want to get multiple monitors going.  I already have what
> I think is a valid config file for it, but I'm guessing I'll never be
> able to do it with fbdev.

That should work if you have multiple framebuffer devices. Use

    Option	"fbdev" "/dev/fb1"

for the second one etc.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[R Shapiro]

Michel Dänzer writes:
 > > Specifics: with the ati driver selected, xf throws away my mode def,
 > > since it thinks (incorrectly) that there isn't enough vram,
 >
 > Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?

The xf probe says 2MB, but in fact I have 4MB.  The dmesg line says:

atyfb: 3D RAGE PRO (PQFP, PCI) [0x4750 rev 0x7c] 4M SGRAM, 14.31818
MHz XTAL, 230 MHz PLL, 75 Mhz MCLK


I tried both UseFBDev on and off.  It didn't seem to make any
difference.  Btw, which is correct setting if I'm not using the fbdev
driver?


 > > and then quits since it can't find any valid modes. In both cases I'm
 > > running 4.0.1 from Franz Sirl's linuxppc page.
 >
 > While we're at it, can you please send me the URL of those?


 ftp://devel.linuxppc.org/users/fsirl/xf4/RPMS/


 > I thought they contained the necessary stuff from Ani Joshi's rsync tree. If
 > you try to build yourself, you absolutely need that.

I just rebuilt it myself, with the rsync xfree, on the G4.  The
rebuilt version works fine there (I'm using it now) with the r128
driver.  I won't be able to test the newly built ati driver on the G3s
until Monday.  Can I just move that driver to the drivers diretory of
the current installation on the two G3s, or do I need to do a complete
rebuild/reinstall on each of them?


 > > The rev. a machine is running 2.2.15pre3 from the 2000 cd, booted via
 > > BootX with "no video driver" checked.
 >
 > I don't think this can work with the ati driver, it needs atyfb.

OK, I'll uncheck that box.  What about the "force video" BootX option
-- on or off?  I did try all four combinations of these two and never
got anything to work with ati.  Unchecking the box seemed to confuse
MOL on the console, so I left it checked.



 > > I can run xf 4.0.x using the fbdev driver, more or less, with an
 > > otherwise identical XF86Config, though xf with fbdev is noticably
 > > slower than Xpmac.rev10.
 >
 > No big surprise as the fbdev driver doesn't have any hardware acceleration.


That's what I figured.  If I can get it going properly, and get it to
support multiple monitors (especially xinerama mode - that would be
ideal), I'm happy to live with the slight decrease in speed.  But of
course real ati support would be nicer....

 >
 > That should work if you have multiple framebuffer devices. Use
 >
 >     Option	"fbdev" "/dev/fb1"
 >
 > for the second one etc.

Ah ha, I didn't think of that.  I'll make the change in the Device
entries.

Speaking of configs, I have a Device entry and a Screen entry for each
physical display but they're all sharing the same Monitor entry (all
three physical monitors are identical).   It that likely to work?



Many thanks for the quick and thorough reply.

--
reshapiro@mediaone.net


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michael Schmitz]

>  > > Specifics: with the ati driver selected, xf throws away my mode def,
>  > > since it thinks (incorrectly) that there isn't enough vram,
>  >
>  > Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?
>
> The xf probe says 2MB, but in fact I have 4MB.  The dmesg line says:

That might be due to a bug in the ati driver (last time I rsynced in
mid-July, there was a bug in Mach64PPCPreInit:


	pScrn->videoRam = fbdevHWGetVidmem(pScrn) / 1024;

	/* hack */
	pScrn->videoRam = 2048;

	/* TODO kludge for GI chip */

	pATI->VideoRAM = pScrn->videoRam;

The hack to unconditionally set pScrn->videoRam to 2M should be removed,
that should be all. I was planning to send Ani another patch as soon as
the 16 bit color stuff was solved but I never got around to it (neither
solving the 16 bit problem nor sending a diff), sorry.

> I just rebuilt it myself, with the rsync xfree, on the G4.  The
> rebuilt version works fine there (I'm using it now) with the r128
> driver.  I won't be able to test the newly built ati driver on the G3s
> until Monday.  Can I just move that driver to the drivers diretory of
> the current installation on the two G3s, or do I need to do a complete
> rebuild/reinstall on each of them?

Just copy ati_drv.o over.

	Michael


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[R Shapiro]

Michael Schmitz writes:
 > That might be due to a bug in the ati driver (last time I rsynced in
 > mid-July, there was a bug in Mach64PPCPreInit:
 > [...]
 > 	/* hack */
 > 	pScrn->videoRam = 2048;
 > [...]
 > The hack to unconditionally set pScrn->videoRam to 2M should be removed,


The rsync of atimach64ppc.c I got earlier today doesn't have this
unconditonal assignment hack anymore.  The hardwired vram setting
certainly could have caused at least some of the problems I was
running into on Friday.  I'll try this new ati driver first thing
Monday and report back.



--
reshapiro@mediaone.net


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michael Schmitz]

>  > 	/* hack */
>  > 	pScrn->videoRam = 2048;
>  > [...]
>  > The hack to unconditionally set pScrn->videoRam to 2M should be removed,
>
>
> The rsync of atimach64ppc.c I got earlier today doesn't have this
> unconditonal assignment hack anymore.  The hardwired vram setting

It was too obvious to go undetected for long :-). Now if the kernel
framebuffer driver (atyfb, and don't check the 'no video driver' option
when using BootX) reportds the correct vram size the X server should see
the correct size as well.

If you have trouble with the predefined modes, just use the ones returned
by fbset -x.

I'll rsync again to see what else may have changed.

	Michael


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Geert Uytterhoeven]

On Sun, 24 Sep 2000, Michael Schmitz wrote:
> >  > 	/* hack */
> >  > 	pScrn->videoRam = 2048;
> >  > [...]
> >  > The hack to unconditionally set pScrn->videoRam to 2M should be removed,
> >
> >
> > The rsync of atimach64ppc.c I got earlier today doesn't have this
> > unconditonal assignment hack anymore.  The hardwired vram setting
>
> It was too obvious to go undetected for long :-). Now if the kernel
> framebuffer driver (atyfb, and don't check the 'no video driver' option
> when using BootX) reportds the correct vram size the X server should see
> the correct size as well.

However, I see a problem. Atyfb reports the video RAM size minus the cursor
area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
end up with 1 MB too few :-(

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: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michael Schmitz]

> On Sun, 24 Sep 2000, Michael Schmitz wrote:
> > >  > 	/* hack */
> > >  > 	pScrn->videoRam = 2048;
> > >  > [...]
> > >  > The hack to unconditionally set pScrn->videoRam to 2M should be removed,
> > >
> > >
> > > The rsync of atimach64ppc.c I got earlier today doesn't have this
> > > unconditonal assignment hack anymore.  The hardwired vram setting
> >
> > It was too obvious to go undetected for long :-). Now if the kernel
> > framebuffer driver (atyfb, and don't check the 'no video driver' option
> > when using BootX) reportds the correct vram size the X server should see
> > the correct size as well.
>
> However, I see a problem. Atyfb reports the video RAM size minus the cursor
> area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
> end up with 1 MB too few :-(

Rather 1k too few if you mean the truncation error - or is the cursor area
really 1 MB?

My LT Pro reports 8188 kB. Seems I can live without the four that have
gone missing.

	Michael


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Geert Uytterhoeven]

On Mon, 25 Sep 2000, Michael Schmitz wrote:
> > On Sun, 24 Sep 2000, Michael Schmitz wrote:
> > > >  > 	/* hack */
> > > >  > 	pScrn->videoRam = 2048;
> > > >  > [...]
> > > >  > The hack to unconditionally set pScrn->videoRam to 2M should be removed,
> > > >
> > > >
> > > > The rsync of atimach64ppc.c I got earlier today doesn't have this
> > > > unconditonal assignment hack anymore.  The hardwired vram setting
> > >
> > > It was too obvious to go undetected for long :-). Now if the kernel
> > > framebuffer driver (atyfb, and don't check the 'no video driver' option
> > > when using BootX) reportds the correct vram size the X server should see
> > > the correct size as well.
> >
> > However, I see a problem. Atyfb reports the video RAM size minus the cursor
> > area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
> > end up with 1 MB too few :-(
>
> Rather 1k too few if you mean the truncation error - or is the cursor area
> really 1 MB?

You're right. I was thinking MB instead of kB...

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: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Kostas Gewrgiou]

On Sun, 24 Sep 2000, Geert Uytterhoeven wrote:

>
> On Sun, 24 Sep 2000, Michael Schmitz wrote:
> > >  > 	/* hack */
> > >  > 	pScrn->videoRam = 2048;
> > >  > [...]
> > >  > The hack to unconditionally set pScrn->videoRam to 2M should be removed,
> > >
> > >
> > > The rsync of atimach64ppc.c I got earlier today doesn't have this
> > > unconditonal assignment hack anymore.  The hardwired vram setting
> >
> > It was too obvious to go undetected for long :-). Now if the kernel
> > framebuffer driver (atyfb, and don't check the 'no video driver' option
> > when using BootX) reportds the correct vram size the X server should see
> > the correct size as well.
>
> However, I see a problem. Atyfb reports the video RAM size minus the cursor
> area. If you divide that number of bytes by 1024 to get pScrn->videoRam, you
> end up with 1 MB too few :-(
>

  Hmm does this mean that mmapping the framebuffer doesn't give you the
start of vram but vram+offset ? if yes then we have a big problem here.

BTW you'll end up 1KB too few not 1MB, pScrn->videoRam is in KBytes :)

 Kostas


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michael Schmitz]

>
>   Hmm does this mean that mmapping the framebuffer doesn't give you the
> start of vram but vram+offset ? if yes then we have a big problem here.

No, atyfb reserved some space at the end of vram (MMIO mirrored there,
please try to memset (0) that area for kicks. Makes you think you're
melting your display).

	Michael


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michel Dänzer]

R Shapiro wrote:
>
> Michel Dänzer writes:
>  > > Specifics: with the ati driver selected, xf throws away my mode def,
>  > > since it thinks (incorrectly) that there isn't enough vram,
>  >
>  > Does it probe the correct amount of VRAM? Do you use Option "UseFBDev" ?
>
> The xf probe says 2MB, but in fact I have 4MB.  The dmesg line says:
>
> atyfb: 3D RAGE PRO (PQFP, PCI) [0x4750 rev 0x7c] 4M SGRAM, 14.31818
> MHz XTAL, 230 MHz PLL, 75 Mhz MCLK

Which looks good. I am confident that the xfree86-pmac rsync driver will probe
that correctly using fbdev.


> I tried both UseFBDev on and off.  It didn't seem to make any
> difference.  Btw, which is correct setting if I'm not using the fbdev
> driver?

I don't think any version of the ati driver will work without "UseFBDev" on
PPC yet, and you need atyfb for that.


>  > > and then quits since it can't find any valid modes. In both cases I'm
>  > > running 4.0.1 from Franz Sirl's linuxppc page.
>  >
>  > While we're at it, can you please send me the URL of those?
>
>  ftp://devel.linuxppc.org/users/fsirl/xf4/RPMS/

Thanks, I've forwarded this to the apus-user list.


> Speaking of configs, I have a Device entry and a Screen entry for each
> physical display but they're all sharing the same Monitor entry (all
> three physical monitors are identical).   It that likely to work?

Don't know, if it doesn't work, just duplicate the Sections and give them
different Identifiers.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michel Lanners]

On  23 Sep, this message from Michel Dänzer echoed through cyberspace:
>> Also the screen is oddly "wrapped" on the rage II machine with the fbdev
>> driver: I can see the full screen but the virtual edge starts about 75% in,
>> instead of matching the physical edge, and then wraps around.  I don't see
>> this artifact on the rage pro G3.
>
> This is a known problem, which is also kind of fixed in Ani's tree AFAIK. I'm
> currently working with Geert Uytterheuven to get the definite fix.

Is this the already-known problem of handling an offset for the screen
start within the framebuffer memory?

Because I'm experiencing this as well with fbdev, and the problem is the
same for all Apple non-accelerated framebuffers (control, platinum,
valkyrie), AFAICT. So it would be helpful if this problem would get
fixed once and for all. FWIW, no propblem with XF3.x.

Thanks

Michel (the other one)

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michel Dänzer]

Michel Lanners wrote:
>
> On  23 Sep, this message from Michel Dänzer echoed through cyberspace:
> >> Also the screen is oddly "wrapped" on the rage II machine with the fbdev
> >> driver: I can see the full screen but the virtual edge starts about 75%
> >> in, instead of matching the physical edge, and then wraps around.  I
> >> don't see this artifact on the rage pro G3.
> >
> > This is a known problem, which is also kind of fixed in Ani's tree AFAIK.
> > I'm currently working with Geert Uytterheuven to get the definite fix.
>
> Is this the already-known problem of handling an offset for the screen
> start within the framebuffer memory?

Yes.


> Because I'm experiencing this as well with fbdev, and the problem is the
> same for all Apple non-accelerated framebuffers (control, platinum,
> valkyrie), AFAICT. So it would be helpful if this problem would get
> fixed once and for all. FWIW, no propblem with XF3.x.

That's why I'm working with Geert, who wrote the 3.x code :)

I'm currently having problems with the MMIO mapping of his code, will
investigate. The Vidmem mapping works for me (although it also worked before),
so any volunteers for testing please line up to me for a patch :)


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Martin Costabel]

Michel Dänzer wrote:
>
> Michel Lanners wrote:
[]
> > Because I'm experiencing this as well with fbdev, and the problem is the
> > same for all Apple non-accelerated framebuffers (control, platinum,
> > valkyrie), AFAICT. So it would be helpful if this problem would get

For what it's worth: I have *no* problem with Franz's 4.0.1 RPMs and a
valkyrie display. It works for 8 bit color without and for 15 bit color
with a modeline in XFConfig. It doesn't work for 16 bit color (and more
than that is out of reach for valkyrie with 1MB VRAM).

> > fixed once and for all. FWIW, no propblem with XF3.x.
>
> That's why I'm working with Geert, who wrote the 3.x code :)
>
> I'm currently having problems with the MMIO mapping of his code, will
> investigate. The Vidmem mapping works for me (although it also worked before),
> so any volunteers for testing please line up to me for a patch :)

I'd volunteer if you provide a precompiled server binary. For compiling
XFree86 myself, my machine is too slow.

--
Martin

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michel Dänzer]

Martin Costabel wrote:
>
> Michel Dänzer wrote:
> >
> > Michel Lanners wrote:
> []
> > > Because I'm experiencing this as well with fbdev, and the problem is the
> > > same for all Apple non-accelerated framebuffers (control, platinum,
> > > valkyrie), AFAICT. So it would be helpful if this problem would get
>
> For what it's worth: I have *no* problem with Franz's 4.0.1 RPMs and a
> valkyrie display. It works for 8 bit color without and for 15 bit color
> with a modeline in XFConfig. It doesn't work for 16 bit color (and more
> than that is out of reach for valkyrie with 1MB VRAM).

The X 4 fbdev code used to pass the depth incorrectly in the PUTSCREENINFO
ioctl. I have a fix for that too and will submit it with the rest.


> > > fixed once and for all. FWIW, no propblem with XF3.x.
> >
> > That's why I'm working with Geert, who wrote the 3.x code :)
> >
> > I'm currently having problems with the MMIO mapping of his code, will
> > investigate. The Vidmem mapping works for me (although it also worked
> > before), so any volunteers for testing please line up to me for a patch :)
>
> I'd volunteer if you provide a precompiled server binary. For compiling
> XFree86 myself, my machine is too slow.

All you'd need to update would be the libfbdevhw.a and fbdev_drv.o modules. I
think I'll put them up RSN at

http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2

Beware: DON'T use this with an accelerated driver right now.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michel Dänzer]

Michel Dänzer wrote:

> > > > Because I'm experiencing this as well with fbdev, and the problem is
> > > > the same for all Apple non-accelerated framebuffers (control,
> > > > platinum, valkyrie), AFAICT. So it would be helpful if this problem
> > > > would get
> >
> > For what it's worth: I have *no* problem with Franz's 4.0.1 RPMs and a
> > valkyrie display. It works for 8 bit color without and for 15 bit color
> > with a modeline in XFConfig. It doesn't work for 16 bit color (and more
> > than that is out of reach for valkyrie with 1MB VRAM).
>
> The X 4 fbdev code used to pass the depth incorrectly in the PUTSCREENINFO
> ioctl. I have a fix for that too and will submit it with the rest.
>
> > > > fixed once and for all. FWIW, no propblem with XF3.x.
> > >
> > > That's why I'm working with Geert, who wrote the 3.x code :)
> > >
> > > I'm currently having problems with the MMIO mapping of his code, will
> > > investigate. The Vidmem mapping works for me (although it also worked
> > > before), so any volunteers for testing please line up to me for a patch
> > > :)
> >
> > I'd volunteer if you provide a precompiled server binary. For compiling
> > XFree86 myself, my machine is too slow.
>
> All you'd need to update would be the libfbdevhw.a and fbdev_drv.o modules.
> I think I'll put them up RSN at
>
> http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2
>
> Beware: DON'T use this with an accelerated driver right now.

This warning should be obsolete now, I've updated the tarball and for those
who like to build themselves I've also put up a diff:

http://n.ethz.ch/student/daenzerm/download/X-fbdev.diff.gz


Please test and let me know how it works, if noone complains I'll submit it to
XFree86.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Kohkichi Hosoda]

>>>>> On Fri, 29 Sep 2000 12:35:30 +0200, Michel Dänzer <daenzerm@student.ethz.ch> said:

>> http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2
>>
>> Beware: DON'T use this with an accelerated driver right
>> now.

Michel> This warning should be obsolete now, I've updated the tarball

I tried your binary with ati driver from
penguinppc.org::xfree86-pmac on iMac revB.  It worked for 15
bit color but did not used to work for 24 bit color.  After
installation of your binary, it works well!!

Result of x11perf --scroll500 under your binary + ati driver;

Sync time adjustment is 0.2300 msecs.

    300 reps @  19.5974 msec (    51.0/sec): Scroll 500x500 pixels
    300 reps @  19.4797 msec (    51.3/sec): Scroll 500x500 pixels
    300 reps @  19.3297 msec (    51.7/sec): Scroll 500x500 pixels
    300 reps @  19.3649 msec (    51.6/sec): Scroll 500x500 pixels
    300 reps @  19.1724 msec (    52.2/sec): Scroll 500x500 pixels
   1500 trep @  19.3888 msec (    51.6/sec): Scroll 500x500 pixels

I know this is not so fast especially for r128 people, but
for me this is great improvement.

Thanks a lot.

Kohkichi Hosoda

E-mail address: khosoda@venus.dti.ne.jp


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michel Dänzer]

Kohkichi Hosoda wrote:
>
> >>>>> On Fri, 29 Sep 2000 12:35:30 +0200, Michel Dänzer <daenzerm@student.ethz.ch> said:
>
> >> http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2
> >>
> >> Beware: DON'T use this with an accelerated driver right
> >> now.
>
> Michel> This warning should be obsolete now, I've updated the tarball
>
> I tried your binary with ati driver from
> penguinppc.org::xfree86-pmac on iMac revB.  It worked for 15
> bit color but did not used to work for 24 bit color.  After
> installation of your binary, it works well!!

That's great! How did it fail before?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Kohkichi Hosoda]

>> I tried your binary with ati driver from
>> penguinppc.org::xfree86-pmac on iMac revB.  It worked for
>> 15 bit color but did not used to work for 24 bit color.
>> After installation of your binary, it works well!!

Michel> That's great! How did it fail before?

Well, I'm confused.  When I tried 24 bit color with default
fbdev and ati a week ago, it did not work.  Now, however, it
works well although it is slower than 24 bit color with your
binary.

Result of x11perf --scroll500 with default fbdev and ati;

Sync time adjustment is 0.1741 msecs.

    200 reps @  26.9526 msec (    37.1/sec): Scroll 500x500 pixels
    200 reps @  27.0679 msec (    36.9/sec): Scroll 500x500 pixels
    200 reps @  27.0197 msec (    37.0/sec): Scroll 500x500 pixels
    200 reps @  27.1500 msec (    36.8/sec): Scroll 500x500 pixels
    200 reps @  26.9818 msec (    37.1/sec): Scroll 500x500 pixels
   1000 trep @  27.0344 msec (    37.0/sec): Scroll 500x500 pixels

With yur binary, it is around 1.5 times faster, as described
in the previous mail.

It's weird, but I can't figure out why default fbdev started
to work with 24 bit color again.  According to my poor
memory, XFree86.0.log used to show "Fatal server error:
failed to initialize core devices" in the last part,
although I'm not sure.

Anyway, thanks a lot for providing a better driver.

Kohkichi Hosoda

E-mail address: khosoda@venus.dti.ne.jp

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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Geert Uytterhoeven]

On Sat, 23 Sep 2000, Michel Lanners wrote:
> On  23 Sep, this message from Michel Dänzer echoed through cyberspace:
> >> Also the screen is oddly "wrapped" on the rage II machine with the fbdev
> >> driver: I can see the full screen but the virtual edge starts about 75% in,
> >> instead of matching the physical edge, and then wraps around.  I don't see
> >> this artifact on the rage pro G3.
> >
> > This is a known problem, which is also kind of fixed in Ani's tree AFAIK. I'm
> > currently working with Geert Uytterheuven to get the definite fix.
>
> Is this the already-known problem of handling an offset for the screen
> start within the framebuffer memory?
>
> Because I'm experiencing this as well with fbdev, and the problem is the
> same for all Apple non-accelerated framebuffers (control, platinum,
> valkyrie), AFAICT. So it would be helpful if this problem would get
> fixed once and for all. FWIW, no propblem with XF3.x.

Should be fixed after applying the untested patch I sent to Michel D.

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: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[Michael Schmitz]

> Is this the already-known problem of handling an offset for the screen
> start within the framebuffer memory?
>
> Because I'm experiencing this as well with fbdev, and the problem is the
> same for all Apple non-accelerated framebuffers (control, platinum,

Sounds like Apple. It's been a problem on the m68k Apple framebuffers as
well, and got fixed for those by Geert in 3.3. The fix got lost or
incorrectly applied in 4.0 ...

	Michael


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

Re: xf 4.0.0/1 with rage II/rage pro -- should the ati driver work?

[William Blew]

On Sat, 23 Sep 2000, R Shapiro wrote:

> Subject says it all, really.  I can't get the xf 4.0.x driver to work
> either on a rev. a beige G3 with rage II or a rev. b beige G3 with
> rage pro.  Should it be working, or am I wasting my time trying?  Fwiw
> the r128 driver works great on my G4....

As if a couple of weeks ago I looked at the mach64 drivers that are being
developed. While I think the progress has been good, I would not describe
their mach64 support under linuxPPC as being ready for use. They still
need quite a bit of work, particularly with the 3D rage pro (mach64's GT
family) support.

> Specifics: with the ati driver selected, xf throws away my mode def,
> since it thinks (incorrectly) that there isn't enough vram, and then
> quits since it can't find any valid modes. In both cases I'm running
> 4.0.1 from Franz Sirl's linuxppc page.  I also tried 4.0.0 from the
> Howarth page and got exactly the same results.  I haven't tried
> compiling xf myself but I'm perfectly willing to do so if that's
> likely to help (eg if there are some known ati patches missing from
> the Sirl rpms).

This is because the ati driver (linuxPPC via the framebuffer device) is
not yet correctly probing all of the mach64 chipset's families. This
includes the size of the card's frame buffer ram and its ram type, at
least (it detects my 6MB of SGRAM as EDO).

Further, last I checked, when inadequate ram (incorrect for 3D rage pro)
eliminates a video mode, that mode is still getting sent to the kernel,
even with its incorrect clock rate, etal. This causes a kernel reject of
the mode setting IOCTL.

> If you have any suggestions at all, please cc: me directly -- I'll see
> it more quickly that way.

I am using 3.3.6 still (due to the above issues). However, if you are
interested in development work, there is some porting of the frame buffer
driver related interface that can be done from the FB driver to the ATI
(under LinuxPPC) driver that would help in resolving these issues.
--
William Blew, wblew@home.com
Gamer by Choice, Geek by Birth


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[R Shapiro]

Mostly good news:

1.  On the rev. a beige G3 w/Mach64 Rage II, the fbdev driver I built
yesterday from the latest rsync fixes the skew/wrap oddity.  In other
words, it seems to work fine on this platform now.


2. On the same machine, I now have a working multi(3)-headed X!  I'm
very impressed that the linuxppc X development team got this going so
quickly.  It only works with the fbdev driver (see below), but I'm not
complaining.  The only issue I've run into so far is the known bug
with screenblanking, which I can fix easily enough via xset.

I can't test xinerama on this platform because the three screen don't
all run at same depth (two use depth 15/16, one uses depth 8).  And my
preferred window manager (blackbox) doesn't seem to happy running more
than once from the same .blackboxrc (fvwm will do for now).  But these
are details...


3.  On the same machine, the ati driver I built yesterday hoses linux
completely and doesn't leave a core file.  I'm happy to help the
developers try to debug this, but I'm not sure what information I can
provide in this situation (it's also not my machine, so I can't always
crash it at will).


4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
be working.  The XF probe still gets the wrong amount of vram, and it
still throws away the mode I constructed via fbset -x.  But it finds
another valid mode somewhere else (where are these default modes
coming from anyway?) and it definitely feels accelerated.  I'm a
little worried that it may be driving the monitor too hard but I'm not
sure how to find out.  xpydinfo doesn't say anything useful.  The
output from startx includes this:

(II) ATI(0): Monitor0: Using hsync range of  30.00- 94.00 kHz
(II) ATI(0): Monitor0: Using vrefresh range of  48.00-120.00 Hz

which are the numbers I put in the XF86Config (taken straight from the
monitor manual).  But somehow it looks like it's running too high a
sync rate.



All in all, worth coming in to work on a Sunday for :)


--
rshapiro@bbn.com


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michel Dänzer]

R Shapiro wrote:

> 2. On the same machine, I now have a working multi(3)-headed X!  I'm
> very impressed that the linuxppc X development team got this going so
> quickly.  It only works with the fbdev driver (see below), but I'm not
> complaining.  The only issue I've run into so far is the known bug
> with screenblanking, which I can fix easily enough via xset.

What bug with screenblanking?


> I can't test xinerama on this platform because the three screen don't
> all run at same depth (two use depth 15/16, one uses depth 8).

What about just testing it with the two heads who run at 16 bpp, or run all
heads in depth 8?


> 3.  On the same machine, the ati driver I built yesterday hoses linux
> completely and doesn't leave a core file.  I'm happy to help the
> developers try to debug this, but I'm not sure what information I can
> provide in this situation (it's also not my machine, so I can't always
> crash it at will).

The server log and maybe the XF86Config are always a good start for
information.


> 4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
> be working.  The XF probe still gets the wrong amount of vram,

Hint to Ani or whoever is working on the ati driver: Why not get the VRAM size
from the framebuffer device?

> and it still throws away the mode I constructed via fbset -x.

What reason does it give for rejecting it?

> But it finds another valid mode somewhere else (where are these default
> modes coming from anyway?)

They're built into the server binary. Mostly VESA standard modes AFAICT.

> and it definitely feels accelerated.  I'm a little worried that it may be
> driving the monitor too hard but I'm not sure how to find out.  xpydinfo
> doesn't say anything useful.

xvidtune gives information about the modes.

> The output from startx includes this:
>
> (II) ATI(0): Monitor0: Using hsync range of  30.00- 94.00 kHz
> (II) ATI(0): Monitor0: Using vrefresh range of  48.00-120.00 Hz
>
> which are the numbers I put in the XF86Config (taken straight from the
> monitor manual).  But somehow it looks like it's running too high a
> sync rate.

Look at the log (/var/log/XFree86.0.log), there should be values for all modes
used and rejected.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[R Shapiro]

Michel Dänzer writes:
 > What bug with screenblanking?

Using the fbdev driver with xf 4.0.1, the default screenblanker kills
the server as soon as the blanker is activated.  This can easily be
replicated via 'xset s activate' or by letting the screenblanker
activate itself by timing out. The ati driver and the r128 driver
don't have this problem, only fbdev.

I've seen this on all three platforms where I've tested 4.0.1, either
using Franz Sirl's rpms or using the version I built with sources
rsync'd yesterday.

Martin Costabel reported this back in July on the users list so I
assumed it was a known but low-priority bug (it's easily gotten around
via 'xset s noblank').




 > > I can't test xinerama on this platform because the three screen don't
 > > all run at same depth (two use depth 15/16, one uses depth 8).
 >
 > What about just testing it with the two heads who run at 16 bpp, or run all
 > heads in depth 8?

I won't have access to the machine for a few days: the multi screen X
will be used off and on for demos all week :) But I'll test this as
soon as I can fiddle with the config file again.

What's the right syntax for starting in this mode?  startx -- +xinerama ?



--
rshapiro@bbn.com

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Martin Costabel]

R Shapiro wrote:
>
> Michel Dänzer writes:
>  > What bug with screenblanking?
>
> Using the fbdev driver with xf 4.0.1, the default screenblanker kills
> the server as soon as the blanker is activated.  This can easily be
> replicated via 'xset s activate' or by letting the screenblanker
> activate itself by timing out. The ati driver and the r128 driver
> don't have this problem, only fbdev.
>
> I've seen this on all three platforms where I've tested 4.0.1, either
> using Franz Sirl's rpms or using the version I built with sources
> rsync'd yesterday.
>
> Martin Costabel reported this back in July on the users list so I
> assumed it was a known but low-priority bug (it's easily gotten around
> via 'xset s noblank').

I had this at the beginning after switching to Franz' RPMs, but it went
away soon, I don't remember why, maybe with Franz' 0.36a instead of
0.30c. Now screen blanking is OK, except that it blanks selectively,
i.e. parts of the screen with active widgets, clocks or ads or whatever,
remain visible. This has also been observed before by someone else (or
maybe it's a feature?).

The most annoying bug for me is that sometimes keys repeat (almost)
indefinitely. Most frequently mouse clicks on scroll arrows that scroll
all the way to the end of the file, but I had it also with the delete
(backwards) key that instead of only 2 characters erased 90% of the
whole text. This bug is random, but its probability is variable:
sometimes it happens practically always and sometimes almost never.

--
Martin

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Kostas Gewrgiou]

On Mon, 25 Sep 2000, Martin Costabel wrote:

>
> The most annoying bug for me is that sometimes keys repeat (almost)
> indefinitely. Most frequently mouse clicks on scroll arrows that scroll
> all the way to the end of the file, but I had it also with the delete
> (backwards) key that instead of only 2 characters erased 90% of the
> whole text. This bug is random, but its probability is variable:
> sometimes it happens practically always and sometimes almost never.

 I noticed the same thing also only in kernels with the input layer though,
i haven't heard of any similar problems in the x86 side and since the code
in x is the same i suspect that the problem is in the kernel side.

  Kostas


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

Re: xf 4.0.1 fbdev screenblanking

[R Shapiro]

Martin Costabel writes:
 > I had this at the beginning after switching to Franz' RPMs, but it went
 > away soon, I don't remember why, maybe with Franz' 0.36a instead of
 > 0.30c.

I was seeing it in 0.36, and it's still there with the complete rsync
and rebuild I did on Saturday.  It may be an intermittent problem but
I don't think it's been fixed yet.



--
rshapiro@bbn.com


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display, xinerama

[R Shapiro]

Michel Dänzer writes:
 > > I can't test xinerama on this platform because the three screen don't
 > > all run at same depth (two use depth 15/16, one uses depth 8).
 >
 > What about just testing it with the two heads who run at 16 bpp, or run all
 > heads in depth 8?


I just did it tried running +xinerama with all three monitors at 8pp.
It works!  Blackbox is happy to move windows across screens, or even
leave a window half on one and half on another.  Basically just like
the multiple monitor support that MacOS has always had.

Very nice :)

Btw for those who might want to try this, +xinerama is a server arg so
the command is  'startx -- +xinerama'.


--
rshapiro@bbn.com


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display, xinerama

[Michel Dänzer]

R Shapiro wrote:

> I just did it tried running +xinerama with all three monitors at 8pp.
> It works!  Blackbox is happy to move windows across screens, or even
> leave a window half on one and half on another.  Basically just like
> the multiple monitor support that MacOS has always had.
>
> Very nice :)

Cool.


> Btw for those who might want to try this, +xinerama is a server arg so
> the command is  'startx -- +xinerama'.

There's also an option for XF86Config, read the manpage - the logical place
would be in the Layout Section.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display, xinerama

[R Shapiro]

Michel Dänzer writes:
 > > Btw for those who might want to try this, +xinerama is a server arg so
 > > the command is  'startx -- +xinerama'.
 >
 > There's also an option for XF86Config, read the manpage - the logical place
 > would be in the Layout Section.

I searched the XF86Config and XFree86 man pages and found no
references to xinerama.  Is it somewhere else?  None of the
ServerLayout settings seem relevant to xinerama as distinguished from
the standard multi-head mode (multiple X screens).

I'd rather put this option in the XF86Config but I can't find a place
for it.


--
rshapiro@bbn.com


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display, xinerama

[Michel Dänzer]

R Shapiro wrote:

>  > > Btw for those who might want to try this, +xinerama is a server arg so
>  > > the command is  'startx -- +xinerama'.
>  >
>  > There's also an option for XF86Config, read the manpage - the logical
>  > place would be in the Layout Section.
>
> I searched the XF86Config and XFree86 man pages and found no
> references to xinerama.  Is it somewhere else?  None of the
> ServerLayout settings seem relevant to xinerama as distinguished from
> the standard multi-head mode (multiple X screens).
>
> I'd rather put this option in the XF86Config but I can't find a place
> for it.

If (wild guess)

    Option "UseXinerama"

in the Layout Section doesn't work, please ask on xpert@XFree86.Org .


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michael Schmitz]

> 3.  On the same machine, the ati driver I built yesterday hoses linux
> completely and doesn't leave a core file.  I'm happy to help the
> developers try to debug this, but I'm not sure what information I can
> provide in this situation (it's also not my machine, so I can't always
> crash it at will).

Does the X server complain about PCI resource conflicts when run as X
--probeonly? Anything about PCI problems in the server log?

If so, send the output of lspci -vv.

BTW: Can you use yaboot for booting?

> 4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
> be working.  The XF probe still gets the wrong amount of vram, and it
> still throws away the mode I constructed via fbset -x.  But it finds

Perhaps the video RAM detection typo which should be gone now ...

	Michael


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[R Shapiro]

Michael Schmitz writes:
 > [ati driver on rev. a Rage II beige G3 hoses linux]
 > Does the X server complain about PCI resource conflicts when run as X
 > --probeonly?

I'll run this test as soon as the Rage II machine is available again.



 > Anything about PCI problems in the server log?

The only server log I have right now is for the X I left running
yesterday with the fbdev driver.  There are a couple of PCI warnings
in this one but no errors (no surprise, since everything is working
well with fbdev):

(**) (null)(2): claimed PCI slot 0:15:0
(II) FBDev(2): using /dev/fb2
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
(II) window:
        [0] -1  0x00000000 - 0x0000ffff (0x10000) IXB
(II) resSize:
(II) window fixed:
        [0] -1  0x00000000 - 0x0000ffff (0x10000) IXB
(WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting


I didn't save any logs from the ati tests that hung linux.  I'll try
to generate one next time the machine is available for crashing :)



 > BTW: Can you use yaboot for booting?

I don't know, can I use yaboot on a rev. a beige G3?  I think the
answer is 'no' but I'm not sure.  I don't think I can use quik either,
since the linux installation is on an ide drive (the rev. b G3 uses
quik but it has scsi drives only, no ide).  Maybe miBoot would work,
I've never tried to use that one before.

Are there known X-related problems using BootX?



 > > 4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
 > > be working.  The XF probe still gets the wrong amount of vram, and it
 > > still throws away the mode I constructed via fbset -x.  But it finds
 >
 > Perhaps the video RAM detection typo which should be gone now ...

Fwiw I'm using the ati driver I built from sources rsync'd on
Saturday.

--
rshapiro@bbn.com


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michael Schmitz]

>  > Anything about PCI problems in the server log?
>
> The only server log I have right now is for the X I left running
> yesterday with the fbdev driver.  There are a couple of PCI warnings
> in this one but no errors (no surprise, since everything is working
> well with fbdev):
>
> (**) (null)(2): claimed PCI slot 0:15:0
> (II) FBDev(2): using /dev/fb2
> (WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
> (II) window:
>         [0] -1  0x00000000 - 0x0000ffff (0x10000) IXB
> (II) resSize:
> (II) window fixed:
>         [0] -1  0x00000000 - 0x0000ffff (0x10000) IXB
> (WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
>

These shouldn't be critical (but they shouldn't happen, either).

>  > BTW: Can you use yaboot for booting?
>
> I don't know, can I use yaboot on a rev. a beige G3?  I think the

Probably not - it could work with the b&w one, that's why I asked.

> Are there known X-related problems using BootX?

You were looking at it, from what I guess. Apple's drivers set up
overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
these. Unfortunatly, the kernel doesn't notice.

>  > > 4. On the rev. b beige G3 w/Mach64 Rage Pro, the ati driver seems to
>  > > be working.  The XF probe still gets the wrong amount of vram, and it
>  > > still throws away the mode I constructed via fbset -x.  But it finds
>  >
>  > Perhaps the video RAM detection typo which should be gone now ...
>
> Fwiw I'm using the ati driver I built from sources rsync'd on
> Saturday.

That should have the stupid typo removed ...

	Michael


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Geert Uytterhoeven]

On Mon, 25 Sep 2000, Michael Schmitz wrote:
> >  > Anything about PCI problems in the server log?
> >
> > The only server log I have right now is for the X I left running
> > yesterday with the fbdev driver.  There are a couple of PCI warnings
> > in this one but no errors (no surprise, since everything is working
> > well with fbdev):
> >
> > (**) (null)(2): claimed PCI slot 0:15:0
> > (II) FBDev(2): using /dev/fb2
> > (WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
> > (II) window:
> >         [0] -1  0x00000000 - 0x0000ffff (0x10000) IXB
> > (II) resSize:
> > (II) window fixed:
> >         [0] -1  0x00000000 - 0x0000ffff (0x10000) IXB
> > (WW) ****INVALID IO ALLOCATION**** b: 0x400 e: 0x4ff correcting
>
> These shouldn't be critical (but they shouldn't happen, either).
>
> > Are there known X-related problems using BootX?
>
> You were looking at it, from what I guess. Apple's drivers set up
> overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
> these. Unfortunatly, the kernel doesn't notice.

Fortunately these PCI assignment bugs should be circumvented by the new PCI
code we're working on.

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: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michael Schmitz]

> > > Are there known X-related problems using BootX?
> >
> > You were looking at it, from what I guess. Apple's drivers set up
> > overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
> > these. Unfortunatly, the kernel doesn't notice.
>
> Fortunately these PCI assignment bugs should be circumvented by the new PCI
> code we're working on.

... in 2.4.x, I believe. Problem is, most people aren't crazy enough to
use 2.4.0 (-test8 in particular).

All you can do in 2.2 is the 'pick and pray' approach: pick an alternate
address for MMIO bases on some heuristics or wild guesses, and pray you
don't trample on other card's resources. Works for me, but I warn anyone
to be careful with that method.

I've posted such a patch to debian-powerpc when one user there had this
problem. That was before I learned booting with yaboot avoids the problem.
If the resource conflict also happens on oldworld machines, I'd still
prefer some suggestions to foolproof the patch (as in: how can I figure
out if a region has been allocated by another card? What bits from the
config registers should I look at?).

	Michael


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Olaf Hering]

On Tue, Sep 26, Michael Schmitz wrote:

> I've posted such a patch to debian-powerpc when one user there had this
> problem. That was before I learned booting with yaboot avoids the problem.
> If the resource conflict also happens on oldworld machines, I'd still
> prefer some suggestions to foolproof the patch (as in: how can I figure
> out if a region has been allocated by another card? What bits from the
> config registers should I look at?).

I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
kerneltree, your patch is still needed - otherwise *kaboom*


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michael Schmitz]

> > I've posted such a patch to debian-powerpc when one user there had this
> > problem. That was before I learned booting with yaboot avoids the problem.
> > If the resource conflict also happens on oldworld machines, I'd still
> > prefer some suggestions to foolproof the patch (as in: how can I figure
> > out if a region has been allocated by another card? What bits from the
> > config registers should I look at?).
>
> I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
> kerneltree, your patch is still needed - otherwise *kaboom*

No surprise there. But I don't consider the patch clean enough for
inclusion with the 2.2 kernels, at least not without safeguarding that the
guessed PCI region isn't occupied.

	Michael


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Olaf Hering]

On Tue, Sep 26, Michael Schmitz wrote:

> > > I've posted such a patch to debian-powerpc when one user there had this
> > > problem. That was before I learned booting with yaboot avoids the problem.
> > > If the resource conflict also happens on oldworld machines, I'd still
> > > prefer some suggestions to foolproof the patch (as in: how can I figure
> > > out if a region has been allocated by another card? What bits from the
> > > config registers should I look at?).
> >
> > I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
> > kerneltree, your patch is still needed - otherwise *kaboom*
>
> No surprise there. But I don't consider the patch clean enough for
> inclusion with the 2.2 kernels, at least not without safeguarding that the
> guessed PCI region isn't occupied.

Yes, it might not be a candidate for kernel.org, but for the local
kernel tree to allow XF4 on the PowerBooks. However, Anis driver works
so far. But if you do a cold boot on the iBook as example some KDE
windows are screwed up, like the "could not open mixer" after a login.
If you boot in MacOs once and reboot into Linux it works again, looks
like an setup problem. I have that on all ati based machines here,
iBook, a beige G3 and the Wallstreet. I boot with miboot most of the
time.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michael Schmitz]

> > > I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
> > > kerneltree, your patch is still needed - otherwise *kaboom*
> >
> > No surprise there. But I don't consider the patch clean enough for
> > inclusion with the 2.2 kernels, at least not without safeguarding that the
> > guessed PCI region isn't occupied.
>
> Yes, it might not be a candidate for kernel.org, but for the local
> kernel tree to allow XF4 on the PowerBooks. However, Anis driver works

I've only tested it on one machine, I have no idea what it does on some of
the less common ones. I'll try to implement the safeguard and send it to
Paul and BenH after that.
I'm out of the office until next week so it won't happen fast.

> so far. But if you do a cold boot on the iBook as example some KDE
> windows are screwed up, like the "could not open mixer" after a login.
> If you boot in MacOs once and reboot into Linux it works again, looks
> like an setup problem. I have that on all ati based machines here,
> iBook, a beige G3 and the Wallstreet. I boot with miboot most of the
> time.

Looks like we should compare the state the card is left in by MacOS and
what we get from a cold boot (I know this is non-trivial) instead of using
the 'boot MacOS first' workaround.

	Michael


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Benjamin Herrenschmidt]

>> I've posted such a patch to debian-powerpc when one user there had this
>> problem. That was before I learned booting with yaboot avoids the problem.
>> If the resource conflict also happens on oldworld machines, I'd still
>> prefer some suggestions to foolproof the patch (as in: how can I figure
>> out if a region has been allocated by another card? What bits from the
>> config registers should I look at?).
>
>I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
>kerneltree, your patch is still needed - otherwise *kaboom*

Allocating a region is nasty. You must find a free physical region (2.2.x
has no support for that) and you must find one that is decoded by the
north bridge (we currently have no code for either reading or writing the
address space decode enable bits of Bandit and UniNorth).

That's step 2 of my PCI patches. I will a set of regions per hose (pci
controller, Apple ones can decode several non-contiguous regions).

With this done, we will be able to really allocate PCI space from the
kernel. I still have to check if the common PCI code provides enough
hooks so I can even add new decoded regions to Bandit/Uninorth, but
that's not terribly important.

One thing: I'd be interested in figuring out what happens if you simply
leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
Will the controller fail ?

What I can do in the meantime is test that we are running _exactly_ on
this machine model, and them remap to a region we know is safe (that's
more or less what you patch do).

Ben.

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

Re: PCI fixups (was: re: xf 4.0.1 with rage II/rage...)

[Michel Lanners]

Hi Ben,

On  26 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
> Allocating a region is nasty. You must find a free physical region (2.2.x
> has no support for that) and you must find one that is decoded by the
> north bridge (we currently have no code for either reading or writing the
> address space decode enable bits of Bandit and UniNorth).
>
> That's step 2 of my PCI patches. I will a set of regions per hose (pci
> controller, Apple ones can decode several non-contiguous regions).
>
> With this done, we will be able to really allocate PCI space from the
> kernel. I still have to check if the common PCI code provides enough
> hooks so I can even add new decoded regions to Bandit/Uninorth, but
> that's not terribly important.

UniNorth, I don't know; but that should not be a problem. If you look at
my latest published PCI patches for 2.3/2.4 kernels, I've attempted to
do exactly that. It crashed in that code but that's a different issue...

Just allocate memory for up to 4 resources per bus, and fill those with
the regions that the hose decodes, flags included, in any order. The PCI
code will try it's best than to allocate resource demands for that bus
out of the provided bus resources, looking for the closest fit.

FWIW, I am reading the resource regions decoded by the hose from the OF
device tree. The encoding is documented somewhere in the OF to PCI
binding doc. I've also added a struct ranges_property in
include/asm-ppc/prom.h.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Re: PCI fixups (was: re: xf 4.0.1 with rage II/rage...)

[Benjamin Herrenschmidt]

>FWIW, I am reading the resource regions decoded by the hose from the OF
>device tree. The encoding is documented somewhere in the OF to PCI
>binding doc. I've also added a struct ranges_property in
>include/asm-ppc/prom.h.

I'm not very confident on the device tree content on those UniNorth
machines. I prefer reading the decoded regions from the address select
register of the bridge itself ;) (There's code in Darwin that shows how
it works).

Where can I find your patch that does this region hacking ?

Ben.

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

Re: PCI fixups (was: re: xf 4.0.1 with rage II/rage...)

[Michel Lanners]

On  27 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
> I'm not very confident on the device tree content on those UniNorth
> machines. I prefer reading the decoded regions from the address select
> register of the bridge itself ;) (There's code in Darwin that shows how
> it works).

I don't mind you doing that ;-) Is there any standard for reading these
things off the bridge?

> Where can I find your patch that does this region hacking ?

http://www.cpu.lu/~mlan/linux/dev/2.4.0-t6-pci.diff

Or, more generally, at:

http://www.cpu.lu/~mlan/linux/dev/pci.html

Have fun!

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Olaf Hering]

On Tue, Sep 26, Benjamin Herrenschmidt wrote:


> One thing: I'd be interested in figuring out what happens if you simply
> leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
> Will the controller fail ?

How do I do that? Can one of you prepare a diff against Bens current
tree? He is at pre10 since last night.

> What I can do in the meantime is test that we are running _exactly_ on
> this machine model, and them remap to a region we know is safe (that's
> more or less what you patch do).

My machine has these data:
cpuinfo:
clock           : 291MHz
machine         : PowerBook
motherboard     : AAPL,PowerBook1998 MacRISC
lspci -n:
00:11.0 Class 0300: 1002:4c47 (rev 80)

This is what 18pre4-ben1 reports:

<6>MacOS display is /pci/ATY,264LT-G
<4>atyfb: alternate regbase 1 phys 0x82fff000 virt 0xd0004000
<4>atyfb: alternate regbase 2 phys 0x82fff000 virt 0xd0007000
<4>atyfb: framebuffer phys 0x82800000 virt 0xd000a000
<4>atyfb: region 2 ofbase 0x10000000 breg 24 io 0 pbase 0x82fff000 size
0x1000 overlaps VRAM  - reassigned to pbase 0x83000000 size 0x1000 !
<4>atyfb: alternate regbase 3 phys 0x83000000 virt 0xd080b000
<4>atyfb: 3D RAGE LT-G [0x4c47 rev 0x80] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 63 Mhz MCLK
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001     03000300      00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<4>atyfb: using alternate regbase 1:
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001     03000300      00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<4>atyfb: using alternate regbase 2:
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001     03000300      00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<4>atyfb: using alternate regbase 3:
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001     03000300      00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<6>atyfb: monitor sense=51e, maps to mode 7
<4>Console: switching to colour frame buffer device 128x48
<4>fb0: ATY Mach64 frame buffer device on /pci/ATY,264LT-G


I have currently no access to other PowerBooks, only the Wallstreets
need the patch. iBook works fine and Lombard should also work.
There is still that init problem, but it is less worse than a hard
crash.




Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Geert Uytterhoeven]

On Tue, 26 Sep 2000, Benjamin Herrenschmidt wrote:
> One thing: I'd be interested in figuring out what happens if you simply
> leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
> Will the controller fail ?

Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how do you
disable BARs for PCI 2.2-compliant devices?

And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
try to relocate them. I guess that's how it crashes on my box with an
unitialized S3...

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: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Benjamin Herrenschmidt]

>> One thing: I'd be interested in figuring out what happens if you simply
>> leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
>> Will the controller fail ?
>
>Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how
do you
>disable BARs for PCI 2.2-compliant devices?
>
>And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
>try to relocate them. I guess that's how it crashes on my box with an
>unitialized S3...

Well, I may be wrong here, but the cause of our problem (the MMIO BAR
overlapping the framebuffer BAR causing XFree to bark) may also be an
XFree problem. I think we never completely figured out if what MacOS does
to the chip is valid or not (because of priority-decoding).

Ben.

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Kostas Gewrgiou]

On Wed, 27 Sep 2000, Geert Uytterhoeven wrote:

>
> On Tue, 26 Sep 2000, Benjamin Herrenschmidt wrote:
> > One thing: I'd be interested in figuring out what happens if you simply
> > leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
> > Will the controller fail ?
>
> Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how do you
> disable BARs for PCI 2.2-compliant devices?
>
> And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
> try to relocate them. I guess that's how it crashes on my box with an
> unitialized S3...

Yeap unless i am wrong it will try to relocate them, for prep i fear that
without correct BusAddrToHostAddr/HostAddrToBusAddr functions in the xserver
this isn't going to work at all :(

Don't expect it to initialize the S3 card in any case, the int10 module
needs ISA IO/mem accesses and both don't work at the moment for linux/ppc
you can imagine what the following code will do to your machine :(

 #define V_RAM 0xA0000
 INTPriv(pInt)->vRam = xf86MapVidMem(screen,VIDMEM_MMIO,V_RAM,size);

 Kostas


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Geert Uytterhoeven]

On Wed, 27 Sep 2000, Kostas Gewrgiou wrote:
> On Wed, 27 Sep 2000, Geert Uytterhoeven wrote:
> > On Tue, 26 Sep 2000, Benjamin Herrenschmidt wrote:
> > > One thing: I'd be interested in figuring out what happens if you simply
> > > leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
> > > Will the controller fail ?
> >
> > Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how do you
> > disable BARs for PCI 2.2-compliant devices?
> >
> > And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
> > try to relocate them. I guess that's how it crashes on my box with an
> > unitialized S3...
>
> Yeap unless i am wrong it will try to relocate them, for prep i fear that
> without correct BusAddrToHostAddr/HostAddrToBusAddr functions in the xserver
> this isn't going to work at all :(
>
> Don't expect it to initialize the S3 card in any case, the int10 module
> needs ISA IO/mem accesses and both don't work at the moment for linux/ppc
> you can imagine what the following code will do to your machine :(
>
>  #define V_RAM 0xA0000
>  INTPriv(pInt)->vRam = xf86MapVidMem(screen,VIDMEM_MMIO,V_RAM,size);

Yes, you have to know the ISA memory base address, which is machine dependent.

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: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Kostas Gewrgiou]

On Thu, 28 Sep 2000, Geert Uytterhoeven wrote:

> > Don't expect it to initialize the S3 card in any case, the int10 module
> > needs ISA IO/mem accesses and both don't work at the moment for linux/ppc
> > you can imagine what the following code will do to your machine :(
> >
> >  #define V_RAM 0xA0000
> >  INTPriv(pInt)->vRam = xf86MapVidMem(screen,VIDMEM_MMIO,V_RAM,size);
>
> Yes, you have to know the ISA memory base address, which is machine dependent.

Thanks to Ben we have the pciconfig_iobase syscall now but nothing to get
the ISA memory base, if someone has the time to add such a syscall fixing
xf86MapVidMem shouldn't be hard at all.

  Kostas.


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Geert Uytterhoeven]

On Tue, 26 Sep 2000, Michael Schmitz wrote:
> > > > Are there known X-related problems using BootX?
> > >
> > > You were looking at it, from what I guess. Apple's drivers set up
> > > overlapping areas for MMIO and VRAM, and X fixes this by disabling one of
> > > these. Unfortunatly, the kernel doesn't notice.
> >
> > Fortunately these PCI assignment bugs should be circumvented by the new PCI
> > code we're working on.
>
> ... in 2.4.x, I believe. Problem is, most people aren't crazy enough to
> use 2.4.0 (-test8 in particular).
>
> All you can do in 2.2 is the 'pick and pray' approach: pick an alternate
> address for MMIO bases on some heuristics or wild guesses, and pray you
> don't trample on other card's resources. Works for me, but I warn anyone
> to be careful with that method.
>
> I've posted such a patch to debian-powerpc when one user there had this
> problem. That was before I learned booting with yaboot avoids the problem.
> If the resource conflict also happens on oldworld machines, I'd still
> prefer some suggestions to foolproof the patch (as in: how can I figure
> out if a region has been allocated by another card? What bits from the
> config registers should I look at?).

You should walk all PCI devices and construct your own resource tree from
pci_dev->base_address[i]. After that you know the conflicts and unassigned
addresses and can look for free space. Unfortunately this is probably nearly
as much work as backporting the 2.4.x PCI resource code (which is tested,
unlike new code you would invent).

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: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michael Schmitz]

> > I've posted such a patch to debian-powerpc when one user there had this
> > problem. That was before I learned booting with yaboot avoids the problem.
> > If the resource conflict also happens on oldworld machines, I'd still
> > prefer some suggestions to foolproof the patch (as in: how can I figure
> > out if a region has been allocated by another card? What bits from the
> > config registers should I look at?).
>
> You should walk all PCI devices and construct your own resource tree from
> pci_dev->base_address[i]. After that you know the conflicts and unassigned
> addresses and can look for free space. Unfortunately this is probably nearly
> as much work as backporting the 2.4.x PCI resource code (which is tested,
> unlike new code you would invent).

Yep, I'm aware of that. I'm way too lazy to backport the PCI resource code
and the problem seemed solved by using yaboot for me. I didn't
fully realize the Wallstreet doesn't have this option.

Instead of walking the whole device tree, I hope to get away with just
picking a free area (assuming pci_dev->base_address[i] == 0 means free)
instead. But I won't get to it before the weekend. If BenH implements a
cleaner way, the better.

	Michael


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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Benjamin Herrenschmidt]

>
>Yep, I'm aware of that. I'm way too lazy to backport the PCI resource code
>and the problem seemed solved by using yaboot for me. I didn't
>fully realize the Wallstreet doesn't have this option.
>
>Instead of walking the whole device tree, I hope to get away with just
>picking a free area (assuming pci_dev->base_address[i] == 0 means free)
>instead. But I won't get to it before the weekend. If BenH implements a
>cleaner way, the better.

Well, since this concerns only one machine, in a given configuration, I
beleive it's safe to just hard-code a new mappping we know won't conflict.

How does OF sets up the mapping of the ATI on the Lombard ? Maybe we can
just stuff that in some fixup routine for the wallstreet...

Ben.

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

Re: xf 4.0.1 with rage II/rage pro -- multi-headed display!

[Michael Schmitz]

> >Instead of walking the whole device tree, I hope to get away with just
> >picking a free area (assuming pci_dev->base_address[i] == 0 means free)
> >instead. But I won't get to it before the weekend. If BenH implements a
> >cleaner way, the better.
>
> Well, since this concerns only one machine, in a given configuration, I
> beleive it's safe to just hard-code a new mappping we know won't conflict.

It at least concerns Wallstreet and Lombard (Pismo has a r128?). Hardcode
and double check it's free, that be it then.

> How does OF sets up the mapping of the ATI on the Lombard ? Maybe we can
> just stuff that in some fixup routine for the wallstreet...

Broken (VRAM included both LE and BE aperture, and MMIO overlaps the end
of the LE aperture (where MMIO actually shows up even without the
separate mapping. I know nothing about decoding priorities though).

atyfb (and, by extension, the fbdev driver _and_ the ati driver with
UseFBDev) use the MMIO alias at the end of the BE aperture (which is why
we reserve that four k segment to prevent it from being used for
framebuffer).

Sketch:

V -- free --- | VRAM LE ........... (MMIO) | VRAM BE ........... (MMIO) |

M                                 |  MMIO  |

V = PCI BAR 0 for VRAM, M = PCI BAR 2 for MMIO (not in the OF device
tree) IIRC. BAR 1 is the IO mapping.

Can't give you the exact addresses off the cuff, but I've described it
here before a week or two after the 4.01 release.

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > > 3.  On the same machine, the ati driver I built yesterday hoses linux
 > > completely and doesn't leave a core file.
 >
 > Does the X server complain about PCI resource conflicts when run as X
 > --probeonly? Anything about PCI problems in the server log?


"startx -- -probeonly" also crashes linux when the ati drivers are
selected.

Here's the log, which ends somewhat abruptly.  The final two lines
reject the two modes I generated with fbset.  Both are considered ok
by the fbdev driver.



XFree86 Version 4.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 1 July 2000
	If the server is older than 6-12 months, or if your card is newer
	than the above date, look for a newer version before reporting
	problems.  (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.17pre10-ben2 ppc [ELF]
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Tue Sep 26 14:44:57 2000
(==) Using config file: "/etc/X11/XF86Config"
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warning, (EE) error, (??) unknown.
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor"
(**) |   |-->Device "device0"
(**) |-->Screen "Screen1" (1)
(**) |   |-->Monitor "Monitor"
(**) |   |-->Device "device1"
(**) |-->Screen "Screen2" (2)
(**) |   |-->Monitor "Monitor"
(**) |   |-->Device "device2"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) Option "XkbModel" "macintosh_old"
(**) XKB: model: "macintosh_old"
(**) FontPath set to "unix/:7100,tcp/blatz:7100"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(II) Module ABI versions:
	XFree86 ANSI C Emulation: 0.1
	XFree86 Video Driver: 0.2
	XFree86 XInput driver : 0.1
	XFree86 Server Extension : 0.1
	XFree86 Font Renderer : 0.1
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 Font Renderer
	ABI class: XFree86 Font Renderer, version 0.1
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 0.1.0
	ABI class: XFree86 Video Driver, version 0.2
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1057,0002 card 0000,0000 rev 40 class 06,00,00 hdr 00
(II) PCI: 00:0d:0: chip 1002,4749 card 1002,0000 rev 5c class 03,00,00 hdr 00
(II) PCI: 00:0f:0: chip 1002,4749 card 1002,0000 rev 5c class 03,00,00 hdr 00
(II) PCI: 00:10:0: chip 106b,0010 card 0000,0000 rev 01 class ff,00,00 hdr 00
(II) PCI: 00:12:0: chip 1002,4754 card 0000,0000 rev 9a class 03,00,00 hdr 00
(II) PCI: End of PCI scan
(II) LoadModule: "scanpci"
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 0.1.0
	ABI class: XFree86 Video Driver, version 0.2
(II) UnloadModule: "scanpci"
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(--) PCI: (0:13:0) ATI Mach64 GI rev 92, Mem @ 0x84000000/24, 0x81801000/12, I/O @ 0x0400/8
(--) PCI: (0:15:0) ATI Mach64 GI rev 92, Mem @ 0x83000000/24, 0x81800000/12, I/O @ 0x0400/8
(--) PCI: (0:18:0) ATI Mach64 GT rev 154, Mem @ 0x82000000/24, I/O @ 0x0400/8
(II) Addressable bus resource ranges are
	[0] -1	0x00000000 - 0xffffffff (0x0) MXB
	[1] -1	0x00000000 - 0x0000ffff (0x10000) IXB
(II) OS-reported resource ranges:
(II) Active PCI resource ranges:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x82000000 - 0x82ffffff (0x1000000) MXB(B)
	[2] -1	0x81820000 - 0x8183ffff (0x20000) MXB(B)
	[3] -1	0x81800000 - 0x81800fff (0x1000) MXB(B)
	[4] -1	0x83000000 - 0x83ffffff (0x1000000) MXB(B)
	[5] -1	0x81840000 - 0x8185ffff (0x20000) MXB(B)
	[6] -1	0x81801000 - 0x81801fff (0x1000) MXB(B)
	[7] -1	0x84000000 - 0x84ffffff (0x1000000) MXB(B)
	[8] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[9] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[10] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
(II) Active PCI resource ranges after removing overlaps:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x82000000 - 0x82ffffff (0x1000000) MXB(B)
	[2] -1	0x81820000 - 0x8183ffff (0x20000) MXB(B)
	[3] -1	0x81800000 - 0x81800fff (0x1000) MXB(B)
	[4] -1	0x83000000 - 0x83ffffff (0x1000000) MXB(B)
	[5] -1	0x81840000 - 0x8185ffff (0x20000) MXB(B)
	[6] -1	0x81801000 - 0x81801fff (0x1000) MXB(B)
	[7] -1	0x84000000 - 0x84ffffff (0x1000000) MXB(B)
	[8] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[9] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[10] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
(II) OS-reported resource ranges after removing overlaps with PCI:
(II) All system resource ranges:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x82000000 - 0x82ffffff (0x1000000) MXB(B)
	[2] -1	0x81820000 - 0x8183ffff (0x20000) MXB(B)
	[3] -1	0x81800000 - 0x81800fff (0x1000) MXB(B)
	[4] -1	0x83000000 - 0x83ffffff (0x1000000) MXB(B)
	[5] -1	0x81840000 - 0x8185ffff (0x20000) MXB(B)
	[6] -1	0x81801000 - 0x81801fff (0x1000) MXB(B)
	[7] -1	0x84000000 - 0x84ffffff (0x1000000) MXB(B)
	[8] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[9] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[10] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	ABI class: XFree86 Server Extension, version 0.1
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 Server Extension
	ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "extmod"
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 Server Extension
	ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension DPMS
(II) Loading extension FontCache
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension GLX
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Reloading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) LoadModule: "pex5"
(II) Loading /usr/X11R6/lib/modules/extensions/libpex5.a
(II) Module pex5: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 Server Extension
	ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension X3D-PEX
(II) LoadModule: "record"
(II) Loading /usr/X11R6/lib/modules/extensions/librecord.a
(II) Module record: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.13.0
	Module class: XFree86 Server Extension
	ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension RECORD
(II) LoadModule: "xie"
(II) Loading /usr/X11R6/lib/modules/extensions/libxie.a
(II) Module xie: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 Server Extension
	ABI class: XFree86 Server Extension, version 0.1
(II) Loading extension XIE
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 Font Renderer
	ABI class: XFree86 Font Renderer, version 0.1
(II) Loading font Type1
(II) Loading font CID
(II) LoadModule: "speedo"
(II) Loading /usr/X11R6/lib/modules/fonts/libspeedo.a
(II) Module speedo: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 Font Renderer
	ABI class: XFree86 Font Renderer, version 0.1
(II) Loading font Speedo
(II) LoadModule: "ati"
(II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
(II) Module ati: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 5.3.5
	Module class: XFree86 Video Driver
	ABI class: XFree86 Video Driver, version 0.2
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="The XFree86 Project"
	compiled for 4.0.1, module version = 1.0.0
	Module class: XFree86 XInput Driver
	ABI class: XFree86 XInput driver, version 0.1
(II) ATI: ATI driver (version 5.3.5) for chipsets: ati, ativga
(--) Chipset ATI Mach64 3D Rage Pro (BGA, PCI) found
(--) Chipset ATI Mach64 3D Rage Pro (BGA, PCI) found
(--) Chipset ATI Mach64 GT (PCI) found
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x82000000 - 0x82ffffff (0x1000000) MXB(B)
	[2] -1	0x81820000 - 0x8183ffff (0x20000) MXB(B)
	[3] -1	0x81800000 - 0x81800fff (0x1000) MXB(B)
	[4] -1	0x83000000 - 0x83ffffff (0x1000000) MXB(B)
	[5] -1	0x81840000 - 0x8185ffff (0x20000) MXB(B)
	[6] -1	0x81801000 - 0x81801fff (0x1000) MXB(B)
	[7] -1	0x84000000 - 0x84ffffff (0x1000000) MXB(B)
	[8] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[9] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[10] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
Found a Mach64 on a PowerPC
(II) resource ranges after probing:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x82000000 - 0x82ffffff (0x1000000) MXB(B)
	[2] -1	0x81820000 - 0x8183ffff (0x20000) MXB(B)
	[3] -1	0x81800000 - 0x81800fff (0x1000) MXB(B)
	[4] -1	0x83000000 - 0x83ffffff (0x1000000) MXB(B)
	[5] -1	0x81840000 - 0x8185ffff (0x20000) MXB(B)
	[6] -1	0x81801000 - 0x81801fff (0x1000) MXB(B)
	[7] -1	0x84000000 - 0x84ffffff (0x1000000) MXB(B)
	[8] 0	0x000a0000 - 0x000affff (0x10000) MSB
	[9] 0	0x000b0000 - 0x000b7fff (0x8000) MSB
	[10] 0	0x000b8000 - 0x000bffff (0x8000) MSB
	[11] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[12] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[13] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[14] 0	0x000003b0 - 0x000003bb (0xc) ISB
	[15] 0	0x000003c0 - 0x000003df (0x20) ISB
(II) Setting vga for screen 0.
(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.1, module version = 0.0.1
	ABI class: XFree86 Video Driver, version 0.2
(**) ATI(0): Depth 8, (--) framebuffer bpp 8
(==) ATI(0): Default visual is PseudoColor
Mapping MMIO @ 0x847ff000 with size 0x1000
testing mmio w/ scratch regs...
SCRATCH_REG0 = 0x3d5d
SCRATCH_REG0 = 0x12345678
SCRATCH_REG1 = 0x0
SCRATCH_REG1 = 0xdeadbeef
Chip Type = 0x4749, Rev = 0x7c
(--) ATI(0): VideoRam: 1 kByte (EDO)
(==) ATI(0): Using gamma correction (1.0, 1.0, 1.0)
(II) ATI(0): Monitor: Using hsync range of   1.00-300.00 kHz
(II) ATI(0): Monitor: Using vrefresh range of   1.00-300.00 Hz
(II) ATI(0): Maximum clock: 120.00 MHz
(WW) ATI(0): Mode "1152x870" deleted (bad mode clock/interlace/doublescan)
(WW) ATI(0): Mode "1280x1024" deleted (bad mode clock/interlace/doublescan)





--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

R Shapiro wrote:
>
> Michael Schmitz writes:
>  > > 3.  On the same machine, the ati driver I built yesterday hoses linux
>  > > completely and doesn't leave a core file.
>  >
>  > Does the X server complain about PCI resource conflicts when run as X
>  > --probeonly? Anything about PCI problems in the server log?
>
> "startx -- -probeonly" also crashes linux when the ati drivers are
> selected.
>
> Here's the log, which ends somewhat abruptly.

[...]

> (--) PCI: (0:13:0) ATI Mach64 GI rev 92, Mem @ 0x84000000/24, 0x81801000/12, I/O @ 0x0400/8
> (--) PCI: (0:15:0) ATI Mach64 GI rev 92, Mem @ 0x83000000/24, 0x81800000/12, I/O @ 0x0400/8
> (--) PCI: (0:18:0) ATI Mach64 GT rev 154, Mem @ 0x82000000/24, I/O @ 0x0400/8

[...]

> (--) ATI(0): VideoRam: 1 kByte (EDO)

That's quite little VRAM :)

Do you have an atyfb for each head? If so, try also passing the "fbdev" option
with the devices for the ati driver.


> The final two lines reject the two modes I generated with fbset.  Both are
> considered ok by the fbdev driver.

[...]

> (II) ATI(0): Maximum clock: 120.00 MHz
> (WW) ATI(0): Mode "1152x870" deleted (bad mode clock/interlace/doublescan)
> (WW) ATI(0): Mode "1280x1024" deleted (bad mode clock/interlace/doublescan)

Are the modes below 120 MHz? Have you tried uncommenting your mode definitions
so that is uses internal modes?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

> >  > Does the X server complain about PCI resource conflicts when run as X
> >  > --probeonly? Anything about PCI problems in the server log?
> >
> > "startx -- -probeonly" also crashes linux when the ati drivers are
> > selected.
> >
> > Here's the log, which ends somewhat abruptly.
>
> [...]
>
> > (--) PCI: (0:13:0) ATI Mach64 GI rev 92, Mem @ 0x84000000/24, 0x81801000/12, I/O @ 0x0400/8
> > (--) PCI: (0:15:0) ATI Mach64 GI rev 92, Mem @ 0x83000000/24, 0x81800000/12, I/O @ 0x0400/8
> > (--) PCI: (0:18:0) ATI Mach64 GT rev 154, Mem @ 0x82000000/24, I/O @ 0x0400/8
>
> [...]
>
> > (--) ATI(0): VideoRam: 1 kByte (EDO)
>
> That's quite little VRAM :)

Yep, that can't really be the 2048 bug anymore.

But that's also quite a lot of mach64 cards. Are there really two GI's in
the machine?

No PCI regions overlap so my patch doesn't apply.

> Do you have an atyfb for each head? If so, try also passing the "fbdev" option
> with the devices for the ati driver.

You will have to pass multipe atyfb= kernel parameters to make the kernel
initialize one framebuffer device for each. Right now I doubt
atyfb_of_init will do the right thing here - could you post the kernel
boot messages again? I wonder if the device you specify via the busid is
the same the kernel initialized as atyfb.

Also helpful: a dump of the OF device tree.

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > > > (--) ATI(0): VideoRam: 1 kByte (EDO)
 > >
 > > That's quite little VRAM :)
 >
 > Yep, that can't really be the 2048 bug anymore.


Fwiw the probed VideoRam on my rev. b beige G3 is also some
ridiculously small number (though not as small as this) yet it runs
the ati driver without any problems.  That one has a single monitor
and Rage Pro video.


 > But that's also quite a lot of mach64 cards. Are there really two GI's in
 > the machine?

It's a three-headed machine: two Rage Pro cards plus the onboard Rage
II.  If I set all three Devices to use fbdev, X happily drives all
three displays (in xinerama, even).  It's only the ati driver that
causes the trouble.



 > You will have to pass multipe atyfb= kernel parameters to make the kernel
 > initialize one framebuffer device for each.

Right now my kernel args are

 video=atyfb:vmode:20,cmode:8

I don't know the syntax for specifying multiple atyfb's.

I'm using BootX to boot.  I tried miBoot but I couldn't get X 4.0.1 to
run at all that way, even with the fbdev driver.  I don't think quik
booting works on this machine, so BootX seems to be the only option.



 > Also helpful: a dump of the OF device tree.

Remind me how to get that and I'll try to generate one.



--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > could you post the kernel boot messages again?

You mean the dmesg?  Here it is.  After that is the XF86Config.

dmesg
-----
device tree used 35560 bytes
Total memory = 128MB; using 512kB for hash table (at c0280000)
Linux version 2.2.15pre3 (benh@sawtooth.wanadoo.fr) (gcc version 2.95.2 19991024 (release/franzo)) #3 Sat Jan 29 18:02:45 CET 2000
PCI bus 0 controlled by pci at 80000000
Registered 1 feature controller(s)
System has 64 possible interrupts
via_calibrate_decr: decrementer_count = 167082 (1002497 ticks)
Console: colour dummy device 80x25
Calibrating delay loop... 534.12 BogoMIPS
Memory: 126664k available (1460k kernel code, 2796k data, 152k init) [c0000000,c8000000]
Dentry hash table entries: 16384 (order 5, 128k)
Buffer cache hash table entries: 131072 (order 7, 512k)
Page cache hash table entries: 32768 (order 5, 128k)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
adb devices: [2]: 2 2 [3]: 3 1
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
TCP: Hash tables configured (ehash 131072 bhash 65536)
NET4: AppleTalk 0.18 for Linux NET4.0
Starting kswapd v 1.5
OHCI USB Driver loading
usbcore: Registered new driver mouse
USB HID boot protocol mouse driver registered.
usbcore: Registered new driver keyboard
usbcore: Registered new driver hub
MacOS display is /pci/ATY,mach64_3DU
atyfb: 3D RAGE (GT) [0x4754 rev 0x9a] 2M SGRAM, 14.31818 MHz XTAL, 200 MHz PLL, 67 Mhz MCLK
BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
7b23a040 86010182 004215b3 25010001     03000200      002806e3   02100503
PLL ad d5 21 44 e8 13 80 b5 8e 9e 98 04 a6 1b 00 00
Console: switching to colour frame buffer device 160x64
fb0: ATY Mach64 frame buffer device on /pci/ATY,mach64_3DU
atyfb: 3D RAGE PRO (BGA, PCI) [0x4749 rev 0x7c] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK
BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
7b33a040 87010182 04651a77 75130c01     03000300      00280509   01f004f1
PLL ad d5 21 64 e4 13 80 b5 8e 9e 98 01 a6 1b 00 00
fb1: ATY Mach64 frame buffer device on /pci/ATY,XCLAIM3DPro
atyfb: 3D RAGE PRO (BGA, PCI) [0x4749 rev 0x7c] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK
BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
7b33a040 87010102 04651a77 75130c01     03000300      00280509   01f004f1
PLL ad d5 21 64 e4 13 80 b5 8e 9e 98 01 a6 1b 00 00
fb2: ATY Mach64 frame buffer device on /pci/ATY,XCLAIM3DPro
ADB keyboard at 2, handler set to 3
ADB mouse at 3, handler set to 4
PowerMac Z8530 serial driver version 2.0
tty00 at 0xf3013020 (irq = 15) is a Z8530 ESCC, port = modem
tty01 at 0xf3013000 (irq = 16) is a Z8530 ESCC, port = printer
pty: 256 Unix98 ptys configured
Macintosh ADB mouse driver installed.
Macintosh non-volatile memory driver v1.0
RAM disk driver initialized:  16 RAM disks of 4096K size
loop: registered device at major 7
pmac_ide: enabling IDE bus ID 0
pmac_ide: enabling IDE bus ID 1
hda: QUANTUM FIREBALL ST6400A, ATA DISK drive
hdc: MATSHITA CR-585, ATAPI CDROM drive
ide0 at 0xf5020000-0xf5020007,0xf5020160 on irq 13
ide1 at 0xf5021000-0xf5021007,0xf5021160 on irq 14
hda: Enabling MultiWord DMA 2
hda: QUANTUM FIREBALL ST6400A, 6149MB w/81kB Cache, CHS=13328/15/63, (U)DMA
hdc: Enabling MultiWord DMA 1
hdc: ATAPI 24X CD-ROM drive, 128kB Cache
Uniform CDROM driver Revision: 2.56
fd0: SWIM3 floppy controller
scsi0 : MESH
scsi : 1 host.
  Vendor: IOMEGA    Model: ZIP 100           Rev: J.03
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi removable disk sda at scsi0, channel 0, id 5, lun 0
scsi : detected 1 SCSI disk total.
sda : READ CAPACITY failed.
sda : status = 0, message = 00, host = 0, driver = 08
sda : extended sense code = 2
sda : block size assumed to be 512 bytes, disk size 1GB.
PPP: version 2.3.7 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
eth0: BMAC at 00:05:02:ee:c7:32
Partition check:
 sda:scsidisk I/O error: dev 08:00, sector 0
 unable to read partition table
 hda: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 152k init 32k prep
Adding Swap: 99996k swap-space (priority -1)
grep uses obsolete /proc/pci interface
DMA sound driver installed, using 4 buffers of 32k.
phy registers:
 0000 0000 0000 0000 0000 0000 0000 0000
 0000 0000 0000 0000 0000 0000 0000 0000
 0000 0000 0000 0000 0000 0000 0000 0000
 0000 0000 0000 0000 0000 0000 0000 0000
MOL module inited


-----
XF86Config -- this is with the fbdev drivers, which works ok.  The
broken version is identical except fbdev->ati.
----

Section "ServerLayout"
	Identifier     "XFree86 Configured"
	Screen        "Screen0"
	Screen        "Screen1" RightOf "Screen0"
	Screen        "Screen2" LeftOf "Screen0"
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "keyboard"

	Option "XkbModel"       "macintosh_old"

#	Option "XkbLayout"      "de"
#	Option "XkbVariant"     "nodeadkeys"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option      "Protocol" "busmouse"
	Option      "Device" "/dev/adbmouse"

# wheel support
#	Option      "ZAxisMapping" "4 5"

EndSection


Section "Files"
# The location of the RGB database.  Note, this is the name of the
# file minus the extension (like ".txt" or ".db").  There is normally
# no need to change the default.

    RgbPath	"/usr/X11R6/lib/X11/rgb"

# Multiple FontPath entries are allowed (which are concatenated together),
# as well as specifying multiple comma-separated entries in one FontPath
# command (or a combination of both methods)

#    FontPath	"/usr/X11R6/lib/X11/fonts/local/"
#    FontPath	"/usr/X11R6/lib/X11/fonts/misc/"
#    FontPath	"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
#    FontPath	"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
#    FontPath	"/usr/X11R6/lib/X11/fonts/Type1/"
#    FontPath	"/usr/X11R6/lib/X11/fonts/CID/"
#    FontPath	"/usr/X11R6/lib/X11/fonts/Speedo/"
#    FontPath	"/usr/X11R6/lib/X11/fonts/75dpi/"
#    FontPath	"/usr/X11R6/lib/X11/fonts/100dpi/"
    FontPath    "unix/:7100"
    FontPath	"tcp/blatz:7100"

# ModulePath can be used to set a search path for the X server modules.
# The default path is shown here.

#    ModulePath	"/usr/X11R6/lib/modules"

EndSection

Section "Module"
	Load  "GLcore"
	Load  "dbe"

# This loads the miscellaneous extensions module, and disables
# initialisation of the XFree86-DGA extension within that module.
    SubSection  "extmod"
      Option    "omit xfree86-dga"   # don't initialise the DGA extension
    EndSubSection

	Load  "glx"
	Load  "pex5"
	Load  "record"
	Load  "xie"
	Load  "type1"
	Load  "speedo"
EndSection


Section "Monitor"
	Identifier   "Monitor"
	VendorName   "Optiquest"
	ModelName    "Optiquest V95"

# Should really get these from the Optiquest spec
	HorizSync   1-300
	VertRefresh 1-300

	Mode "1152x870"
	    # D: 134.445 MHz, H: 86.183 kHz, V: 94.498 Hz
	    DotClock 134.446
	    HTimings 1152 1216 1328 1560
	    VTimings 870 871 874 912
	    Flags    "+HSync" "+VSync"
	EndMode



	Mode "1280x1024"
	    # D: 134.445 MHz, H: 79.647 kHz, V: 74.716 Hz
	    DotClock 134.446
	    HTimings 1280 1344 1456 1688
	    VTimings 1024 1025 1028 1066
	    Flags    "+HSync" "+VSync"
	EndMode



EndSection



# First Display

Section "Device"
	### Available Driver options are:-
        #Option     "NoAccel"
        #Option     "SWcursor"
        Option     "HWcursor"
        #Option     "Dac6Bit"
        #Option     "Dac8Bit"
        Option     "UseFBDev"
	Option	"fbdev" "/dev/fb0"
#	Option      "NoShadowFB"
	Identifier  "device0"
	Driver      "fbdev"
	BusID       "PCI:0:18:0"
EndSection



# For now default to 8bpp, in order to get 1280x1024 resolution.
# Change to 15 as soon as this card has more vram.
Section "Screen"
	Identifier "Screen0"
	Device     "device0"
	Monitor    "Monitor"
        DefaultDepth      8

	SubSection "Display"
		Depth     8
		Modes  "1280x1024"
	EndSubSection

	SubSection "Display"
		Depth     15
		Modes  "1152x870"
	EndSubSection
EndSection








# Second Display

Section "Device"
	### Available Driver options are:-
        #Option     "NoAccel"
        #Option     "SWcursor"
        Option     "HWcursor"
        #Option     "Dac6Bit"
        #Option     "Dac8Bit"
        Option     "UseFBDev"
	Option	"fbdev" "/dev/fb1"
#	Option      "NoShadowFB"
	Identifier  "device1"
	Driver      "fbdev"
	BusID       "PCI:0:13:0"
EndSection




# For now default to 8bpp, since Screen 0 is running at that depth (for 1280x1024 res)
# and xinerama can't run unless all three screen are at the same depth.
# Change to 15 as soon as Screen 0 gets more vram.
Section "Screen"
	Identifier "Screen1"
	Device     "device1"
	Monitor    "Monitor"
        DefaultDepth      8

	SubSection "Display"
		Depth     8
		Modes "1280x1024"
	EndSubSection

	SubSection "Display"
		Depth     15
		Modes "1280x1024"
	EndSubSection
EndSection







# Third Display


Section "Device"
	### Available Driver options are:-
        #Option     "NoAccel"
        #Option     "SWcursor"
        Option     "HWcursor"
        #Option     "Dac6Bit"
        #Option     "Dac8Bit"
        Option     "UseFBDev"
	Option	"fbdev" "/dev/fb2"
#	Option      "NoShadowFB"
	Identifier  "device2"
	Driver      "fbdev"
	BusID       "PCI:0:15:0"
EndSection





# For now default to 8bpp, since Screen 0 is running at that depth (for 1280x1024 res)
# and xinerama can't run unless all three screen are at the same depth.
# Change to 15 as soon as Screen 0 gets more vram.
Section "Screen"
	Identifier "Screen2"
	Device     "device2"
	Monitor    "Monitor"
        DefaultDepth      8

	SubSection "Display"
		Depth     8
		Modes "1280x1024"
	EndSubSection

	SubSection "Display"
		Depth     15
		Modes "1280x1024"
	EndSubSection
EndSection




--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

> MacOS display is /pci/ATY,mach64_3DU
> atyfb: 3D RAGE (GT) [0x4754 rev 0x9a] 2M SGRAM, 14.31818 MHz XTAL, 200 MHz PLL, 67 Mhz MCLK
> BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
> 7b23a040 86010182 004215b3 25010001     03000200      002806e3   02100503
> PLL ad d5 21 44 e8 13 80 b5 8e 9e 98 04 a6 1b 00 00
> Console: switching to colour frame buffer device 160x64
> fb0: ATY Mach64 frame buffer device on /pci/ATY,mach64_3DU
> atyfb: 3D RAGE PRO (BGA, PCI) [0x4749 rev 0x7c] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK
> BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
> 7b33a040 87010182 04651a77 75130c01     03000300      00280509   01f004f1
> PLL ad d5 21 64 e4 13 80 b5 8e 9e 98 01 a6 1b 00 00
> fb1: ATY Mach64 frame buffer device on /pci/ATY,XCLAIM3DPro
> atyfb: 3D RAGE PRO (BGA, PCI) [0x4749 rev 0x7c] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK
> BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
> 7b33a040 87010102 04651a77 75130c01     03000300      00280509   01f004f1
> PLL ad d5 21 64 e4 13 80 b5 8e 9e 98 01 a6 1b 00 00
> fb2: ATY Mach64 frame buffer device on /pci/ATY,XCLAIM3DPro

atyfb handles three displays just fine (could have guessed so, sorry Geert).

So here we have three fb devices in the kernel (you could check with
fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
to cope. You specify the PCI bus ID but not the corresponding framebuffer
device node - I heard someone mention this was possible when I was
fighting the Lombard crashes, could anyone point out the syntax to use
there?

If we can't specify the fb node XFree will have to probe for it (Geert
mentioned an easy way to do that: open the device and compare
pScrn->memPhysBase or fPtr->fix.smem_start to the PCI base address).

BTW Geert: why is fPtr->fboff calculated from fix.smem_len not
fix.smem_start while pScrn->fbOffset is calculated from fix.smem_start?

void*
fbdevHWMapVidmem(ScrnInfoPtr pScrn)
{
        fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);

        TRACE_ENTER("MapVidmem");
        if (NULL == fPtr->fbmem) {
                fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
                fPtr->fbmem = mmap(NULL, fPtr->fix.smem_len, PROT_READ | PROT_W
	                           MAP_SHARED, fPtr->fd, 0);
                if (-1 == (int)fPtr->fbmem) {
	                perror("mmap fbmem");
	                fPtr->fbmem = NULL;
 	   	}
   	}
        pScrn->memPhysBase = (unsigned long)fPtr->fix.smem_start & (unsigned long)(PAGE_MASK);
        pScrn->fbOffset = (unsigned long)fPtr->fix.smem_start & (unsigned long) (~PAGE_MASK);
        return fPtr->fbmem;
}

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > So here we have three fb devices in the kernel (you could check with
 > fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
 > to cope.

The ati driver unable to cope.  The fbdev driver copes without
complaint.


 > You specify the PCI bus ID but not the corresponding framebuffer
 > device node

In the XF86Config?  That has both the bus id and the dev node:

        Option     "UseFBDev"
        Option  "fbdev" "/dev/fb0"
        Driver      "fbdev"
        BusID       "PCI:0:18:0"

Similarly for the second and third devices (/dev/fb1 & PCI:0:13:0,
/dev/fb2 & PCI:0:15:0, respectively).

Hmm, if change the driver to "ati", am I also supposed the change the
device node Option to "ati", ie 'Option "ati" "/dev/fb0"'?  I never
tried that.


--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

>  > So here we have three fb devices in the kernel (you could check with
>  > fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
>  > to cope.
>
> The ati driver unable to cope.  The fbdev driver copes without
> complaint.

That's what I mean - the fbdev driver knows about the correct addresses
(it gets them from the fb.fix strucure).

>  > You specify the PCI bus ID but not the corresponding framebuffer
>  > device node
>
> In the XF86Config?  That has both the bus id and the dev node:
>
>         Option     "UseFBDev"
>         Option  "fbdev" "/dev/fb0"
>         Driver      "fbdev"
>         BusID       "PCI:0:18:0"

S**t. I overlooked that. Ok, I officially declare the ati driver unable to
cope. Please disable the fb_open_pci() call in fbdevhw.c:

Bool
fbdevHWInit(ScrnInfoPtr pScrn, pciVideoPtr pPci, char *device)
{
 	fbdevHWPtr fPtr;

	TRACE_ENTER("Init");

	fbdevHWGetRec(pScrn);
	fPtr = FBDEVHWPTR(pScrn);

	/* open device */
#if 0
	if (pPci)
	        fPtr->fd = fbdev_open_pci(pPci,NULL);
	else
#endif
	    	fPtr->fd = fbdev_open(device,NULL);


> Hmm, if change the driver to "ati", am I also supposed the change the
> device node Option to "ati", ie 'Option "ati" "/dev/fb0"'?  I never
> tried that.

Nope, the syntax should be OK. Question is does the ati driver parse that
option if fb_open_pci is used.

I'm just speculating here, and I've never tried using the traditional fb
open so no guarantee it will work - and you're on your own if the ati
driver insist on using PCI.

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > S**t. I overlooked that. Ok, I officially declare the ati driver unable to
 > cope.

Just to mention: the ati driver *does* work on my other G3, a
single-monitor rev. b Rage Pro running the same XFree 4.0.1 (different
kernel though).  Is it useful to see the log for that one?  I notice
that it's throwing away the mode I got from fbset -x and using one of
the built-in modes instead.  It also gets a silly value back from the
vram probe:

(--) ATI(0): VideoRam: 3 kByte (EDO)


But it runs ok, at least so far.

--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

>  > S**t. I overlooked that. Ok, I officially declare the ati driver unable to
>  > cope.
>
> Just to mention: the ati driver *does* work on my other G3, a
> single-monitor rev. b Rage Pro running the same XFree 4.0.1 (different

Unable to cope with multiple framebuffers :-) Single framebuffer is easy:
PCI and fb should address the same card.

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

Michael Schmitz wrote:

> > Hmm, if change the driver to "ati", am I also supposed the change the
> > device node Option to "ati", ie 'Option "ati" "/dev/fb0"'?  I never
> > tried that.

Certainly not, "fbdev" if anything.


> Nope, the syntax should be OK. Question is does the ati driver parse that
> option if fb_open_pci is used.

I just rsynced Ani's tree, and the ati driver doesn't. Ani, why not?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Kostas Gewrgiou]

On Thu, 28 Sep 2000, Michel [iso-8859-1] Dδnzer wrote:

>
> Michael Schmitz wrote:
>
> > Nope, the syntax should be OK. Question is does the ati driver parse that
> > option if fb_open_pci is used.
>
> I just rsynced Ani's tree, and the ati driver doesn't. Ani, why not?
>

Only the fbdev and glint drivers use this option, all the others get the
fbdev device from the BusID option, unfortunately fbdev_open_pci() will open
the *first* device that matches the device so if you have more than 2
devices it will map the first one again with bad results.
Geert posted recently a patch recently for fbdev_open_pci so it will do the
right thing (i never tested it though) give it a try.

  Kostas


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

Kostas Gewrgiou wrote:
>
> On Thu, 28 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
>
> > Michael Schmitz wrote:
> >
> > > Nope, the syntax should be OK. Question is does the ati driver parse
> > > that option if fb_open_pci is used.
> >
> > I just rsynced Ani's tree, and the ati driver doesn't. Ani, why not?
>
> Only the fbdev and glint drivers use this option, all the others get the
> fbdev device from the BusID option, unfortunately fbdev_open_pci() will open
> the *first* device that matches the device so if you have more than 2
> devices it will map the first one again with bad results.
> Geert posted recently a patch recently for fbdev_open_pci so it will do the
> right thing (i never tested it though) give it a try.

Yep, I've got that in my local CVS tree and will submit it when we've ironed
out the remaining issues.


However, I think the "fbdev" option should also be available, it might be more
straightforward for some users than the bus ID. Would it also be possible to
go the opposite way fbdev -> pcidev and then claim the PCI device?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Kostas Gewrgiou]

On Fri, 29 Sep 2000, Michel [iso-8859-1] Dδnzer wrote:

> However, I think the "fbdev" option should also be available, it might be more
> straightforward for some users than the bus ID. Would it also be possible to
> go the opposite way fbdev -> pcidev and then claim the PCI device?
>

It should be possible to do it, i'll give it a try once i have some free
time. We could get away from the busID requirement in the fbdev driver then
(its very easy to missmatch busID/fbdev and nothing can detect this error)

  Kostas


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Geert Uytterhoeven]

On Wed, 27 Sep 2000, Michael Schmitz wrote:
> So here we have three fb devices in the kernel (you could check with
> fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
> to cope. You specify the PCI bus ID but not the corresponding framebuffer
> device node - I heard someone mention this was possible when I was
> fighting the Lombard crashes, could anyone point out the syntax to use
> there?
>
> If we can't specify the fb node XFree will have to probe for it (Geert
> mentioned an easy way to do that: open the device and compare
> pScrn->memPhysBase or fPtr->fix.smem_start to the PCI base address).

Besides, the current fbdev_open_pci() can't cope with multiple cards of the
same type, and doesn't recognize ATI Mach64.

> BTW Geert: why is fPtr->fboff calculated from fix.smem_len not
> fix.smem_start while pScrn->fbOffset is calculated from fix.smem_start?

That's indeed incorrect. But it's not the only bug in that part of the code
:-)

Hmmm... I just noticed I kept that bug in my version...

For reference, these are my (untested) patches...
Michel, I'll send you a diff relative to my previous version.

diff -urN michel/fbdevhw.c geert-3/fbdevhw.c
--- michel/fbdevhw.c	Mon Aug 28 16:36:59 2000
+++ geert-3/fbdevhw.c	Thu Sep 28 13:15:54 2000
@@ -86,8 +86,10 @@
 	char*				device;
 	int				fd;
 	void*				fbmem;
-	int				fboff;
+	unsigned int			fbmem_len;
+	unsigned int			fboff;
 	void*				mmio;
+	unsigned int			mmio_len;

 	/* current hardware state */
 	struct fb_fix_screeninfo	fix;
@@ -95,6 +97,8 @@

 	/* saved video mode */
 	struct fb_var_screeninfo	saved_var;
+
+	/* FIXME: unused??? [geert] */
 	struct fb_cmap			saved_cmap;
 	unsigned short			*saved_red;
 	unsigned short			*saved_green;
@@ -194,7 +198,7 @@
 		var->sync |= FB_SYNC_VERT_HIGH_ACT;
 	if (mode->Flags & V_PCSYNC)
 		var->sync |= FB_SYNC_COMP_HIGH_ACT;
-#if 0
+#if 1 /* Badly needed for PAL/NTSC on Amiga (amifb)!! [geert] */
 	if (mode->Flags & V_BCAST)
 		var->sync |= FB_SYNC_BROADCAST;
 #endif
@@ -222,7 +226,7 @@
 	mode->Flags |= var->sync & FB_SYNC_HOR_HIGH_ACT ? V_PHSYNC : V_NHSYNC;
 	mode->Flags |= var->sync & FB_SYNC_VERT_HIGH_ACT ? V_PVSYNC : V_NVSYNC;
 	mode->Flags |= var->sync & FB_SYNC_COMP_HIGH_ACT ? V_PCSYNC : V_NCSYNC;
-#if 0
+#if 1 /* Badly needed for PAL/NTSC on Amiga (amifb)!! [geert] */
 	if (var->sync & FB_SYNC_BROADCAST)
 		mode->Flags |= V_BCAST;
 #endif
@@ -247,28 +251,6 @@
 /* -------------------------------------------------------------------- */
 /* open correct framebuffer device                                      */

-static struct fb2pci_entry {
-	CARD32 id;
-	CARD32 vendor;
-	CARD32 chip;
-} fb2pci_map[] = {
-	{ FB_ACCEL_MATROX_MGA2064W,     PCI_VENDOR_MATROX, PCI_CHIP_MGA2064      },
-	{ FB_ACCEL_MATROX_MGA1064SG,    PCI_VENDOR_MATROX, PCI_CHIP_MGA1064      },
-	{ FB_ACCEL_MATROX_MGA2164W,     PCI_VENDOR_MATROX, PCI_CHIP_MGA2164      },
-	{ FB_ACCEL_MATROX_MGA2164W_AGP, PCI_VENDOR_MATROX, PCI_CHIP_MGA2164_AGP  },
-	{ FB_ACCEL_MATROX_MGAG100,      PCI_VENDOR_MATROX, PCI_CHIP_MGAG100      },
-	{ FB_ACCEL_MATROX_MGAG200,      PCI_VENDOR_MATROX, PCI_CHIP_MGAG200      },
-	{ FB_ACCEL_ATI_RAGE128,         PCI_VENDOR_ATI,    PCI_CHIP_RAGE128RE    },
-	{ FB_ACCEL_ATI_RAGE128,         PCI_VENDOR_ATI,    PCI_CHIP_RAGE128RF    },
-	{ FB_ACCEL_ATI_RAGE128,         PCI_VENDOR_ATI,    PCI_CHIP_RAGE128RK    },
-	{ FB_ACCEL_ATI_RAGE128,         PCI_VENDOR_ATI,    PCI_CHIP_RAGE128RL    },
-	{ FB_ACCEL_ATI_RAGE128,         PCI_VENDOR_ATI,    PCI_CHIP_RAGE128PF    },
-	{ FB_ACCEL_ATI_RAGE128,         PCI_VENDOR_ATI,    PCI_CHIP_RAGE128LE    },
-	{ FB_ACCEL_ATI_RAGE128,         PCI_VENDOR_ATI,    PCI_CHIP_RAGE128LF    },
-	{ FB_ACCEL_3DFX_BANSHEE,        PCI_VENDOR_3DFX,   PCI_CHIP_VOODOO3      },
-};
-#define FB2PCICOUNT (sizeof(fb2pci_map)/sizeof(struct fb2pci_entry))
-
 /* try to find the framebuffer device for a given PCI device */
 static int
 fbdev_open_pci(pciVideoPtr pPci, char **namep)
@@ -276,8 +258,9 @@
 	struct	fb_fix_screeninfo fix;
 	char	filename[16];
 	int	fd,i,j;
+	memType res_start, res_end;

-	for (i = 0; i < 4; i++) {
+	for (i = 0; i < 8; i++) {
 		sprintf(filename,"/dev/fb%d",i);
 		if (-1 == (fd = open(filename,O_RDWR,0))) {
 			continue;
@@ -286,15 +269,20 @@
 			close(fd);
 			continue;
 		}
-		/* FIXME: better ask the fbdev driver for bus/device/func,
-                          but there is no way to to this yet. */
-		for (j = 0; j < FB2PCICOUNT; j++) {
-			if (pPci->vendor   == fb2pci_map[j].vendor &&
-			    pPci->chipType == fb2pci_map[j].chip   &&
-			    fix.accel      == fb2pci_map[j].id)
+		for (j = 0; j < 6; j++) {
+			if ((pPci->type[i] & ResPhysMask) != ResMem)
+				continue;
+			res_start = pPci->memBase[j];
+			res_end = res_start+pPci->size[j];
+			if ((0 != fix.smem_len &&
+			     fix.smem_start >= res_start &&
+			     fix.smem_start < res_end) ||
+			    (0 != fix.mmio_len &&
+			     fix.mmio_start >= res_start &&
+			     fix.mmio_start < res_end))
 				break;
 		}
-		if (j == FB2PCICOUNT) {
+		if (j == 6) {
 			close(fd);
 			continue;
 		}
@@ -541,12 +529,19 @@

 	TRACE_ENTER("MapVidmem");
 	if (NULL == fPtr->fbmem) {
-		fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
-		fPtr->fbmem = mmap(NULL, fPtr->fix.smem_len, PROT_READ | PROT_WRITE,
+		fPtr->fboff = fPtr->fix.smem_start & ~PAGE_MASK;
+		fPtr->fbmem_len = (fPtr->fboff+fPtr->fix.smem_len+~PAGE_MASK) &
+				  PAGE_MASK;
+		fPtr->fbmem = mmap(NULL, fPtr->fbmem_len, PROT_READ | PROT_WRITE,
 				   MAP_SHARED, fPtr->fd, 0);
 		if (-1 == (int)fPtr->fbmem) {
 			perror("mmap fbmem");
 			fPtr->fbmem = NULL;
+		} else {
+		    /* Perhaps we'd better add fboff to fbmem and return 0 in
+		       fbdevHWLinearOffset()? Of course we then need to mask
+		       fPtr->fbmem with PAGE_MASK in fbdevHWUnmapVidmem() as
+		       well. [geert] */
 		}
 	}
 	pScrn->memPhysBase = (unsigned long)fPtr->fix.smem_start & (unsigned long)(PAGE_MASK);
@@ -570,7 +565,7 @@

 	TRACE_ENTER("UnmapVidmem");
 	if (NULL != fPtr->fbmem) {
-		if (-1 == munmap(fPtr->fbmem, fPtr->fix.smem_len))
+		if (-1 == munmap(fPtr->fbmem, fPtr->fbmem_len))
 			perror("munmap fbmem");
 		fPtr->fbmem = NULL;
 	}
@@ -580,6 +575,8 @@
 void*
 fbdevHWMapMMIO(ScrnInfoPtr pScrn)
 {
+	unsigned int mmio_off;
+
 	fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);

 	TRACE_ENTER("MapMMIO");
@@ -590,12 +587,17 @@
 			perror("FBIOPUT_VSCREENINFO");
 			return FALSE;
 		}
-		fPtr->mmio = mmap(NULL, fPtr->fix.mmio_len, PROT_READ | PROT_WRITE,
-				  MAP_SHARED, fPtr->fd, fPtr->fix.smem_len);
+		mmio_off = fPtr->fix.mmio_start & ~PAGE_MASK;
+		fPtr->mmio_len = (mmio_off+fPtr->fix.mmio_len+~PAGE_MASK) &
+				  PAGE_MASK;
+		fPtr->mmio = mmap(NULL, fPtr->mmio_len, PROT_READ | PROT_WRITE,
+				  MAP_SHARED, fPtr->fd, fPtr->fbmem_len);
 		if (-1 == (int)fPtr->mmio) {
 			perror("mmap mmio");
 			fPtr->mmio = NULL;
-		}
+		} else
+			fPtr->mmio = (void *)((unsigned long)fPtr->mmio+
+							     mmio_off);
 	}
 	return fPtr->mmio;
 }
@@ -607,9 +609,11 @@

 	TRACE_ENTER("UnmapMMIO");
 	if (NULL != fPtr->mmio) {
-		if (-1 == munmap(fPtr->mmio, fPtr->fix.mmio_len))
+		if (-1 == munmap((void *)((unsigned long)fPtr->mmio & PAGE_MASK),
+				 fPtr->mmio_len))
 			perror("munmap mmio");
 		fPtr->mmio = NULL;
+		/* FIXME: restore var.accel_flags [geert] */
 	}
 	return TRUE;
 }
@@ -691,9 +695,12 @@
 	cmap.transp = NULL;
 	for (i = 0; i < numColors; i++) {
 		cmap.start = indices[i];
-		red   = colors[indices[i]].red   << 8;
-		green = colors[indices[i]].green << 8;
-		blue  = colors[indices[i]].blue  << 8;
+		red   = (colors[indices[i]].red   << 8) |
+			colors[indices[i]].red;
+		green = (colors[indices[i]].green << 8) |
+			colors[indices[i]].green;
+		blue  = (colors[indices[i]].blue  << 8) |
+			colors[indices[i]].blue;
 		if (-1 == ioctl(fPtr->fd,FBIOPUTCMAP,(void*)&cmap))
 			perror("ioctl FBIOPUTCMAP");
 	}

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: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

Geert Uytterhoeven wrote:
>
> On Wed, 27 Sep 2000, Michael Schmitz wrote:
> > So here we have three fb devices in the kernel (you could check with
> > fbset that each is in fact accessible via /dev/fb[0-2]), and XFree unable
> > to cope. You specify the PCI bus ID but not the corresponding framebuffer
> > device node - I heard someone mention this was possible when I was
> > fighting the Lombard crashes, could anyone point out the syntax to use
> > there?
> >
> > If we can't specify the fb node XFree will have to probe for it (Geert
> > mentioned an easy way to do that: open the device and compare
> > pScrn->memPhysBase or fPtr->fix.smem_start to the PCI base address).
>
> Besides, the current fbdev_open_pci() can't cope with multiple cards of the
> same type, and doesn't recognize ATI Mach64.

Which should also be fixed now. Another update :)


Reminder: The binary modules are at

http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2

, the diff is at

http://n.ethz.ch/student/daenzerm/download/X-fbdev.diff.gz


Mr Shapiro, please test if this makes the ati driver work in your triple-head
box.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michel Dänzer writes:
 > Mr Shapiro, please test if this makes the ati driver work in your
 > triple-head box.

No luck.

Booting with BootX, the ati driver still hoses linux when X starts.  I
can send you (or post) the log.  Worse, using the new fbdev driver
itself produces a confused display on the 2nd and 3rd monitor, with
images appearing multiple times.

Booting with miBoot, any attempt to run X with either driver still
hoses linux.

I don't have quik booting working yet, so I couldn't test that.

--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

>  > Mr Shapiro, please test if this makes the ati driver work in your
>  > triple-head box.
>
> No luck.
>
> Booting with BootX, the ati driver still hoses linux when X starts.  I

That's not fixable at the X level (well, technically it is but I can't
figure out how and the X people refuse to consider that method). You will
need to boot via OF and yaboot (or equivalent oldworld) directly, not via
BootX to avoid the PCI resource conflict. Alternative: fix the resource
conflict at the kernel level, new patch by me in the works.

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > That's not fixable at the X level (well, technically it is but I can't
 > figure out how and the X people refuse to consider that method). You will
 > need to boot via OF and yaboot (or equivalent oldworld) directly

I tried miBoot.  Is that equivalent from the X perspective?  I can't
get X to run with any driver at all, old or new, when the machine is
booted with miBoot.

I haven't yet found a way to quik-boot this ide-only beige g3.  I've
been given some suggestions of things to try, but they guy who
actually owns this machine needs to do real work on it today.  I don't
know when I'll get to play with OF/quik booting.


--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

> Michael Schmitz writes:
>  > That's not fixable at the X level (well, technically it is but I can't
>  > figure out how and the X people refuse to consider that method). You will
>  > need to boot via OF and yaboot (or equivalent oldworld) directly
>
> I tried miBoot.  Is that equivalent from the X perspective?  I can't

Show me your lspci -vv log :-)

Re: OF device tree, there's a tool named lsprop you need to run on
/proc/device_tree (see Paul's or BenH's pages for the source or ask me
for a copy).

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > > I tried miBoot.  Is that equivalent from the X perspective?
 >
 > Show me your lspci -vv log :-)

The result in miBoot is the same as in BootX:

00:00.0 Host bridge: Motorola Computer Group MPC106 [Grackle] (rev 40)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0 set, cache line size 08

00:0d.0 VGA compatible controller: ATI Technologies Inc 215GI [Mach64 GI] (rev 5c)
	Subsystem: Unknown device 1002:0000
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 min, 32 set, cache line size 08
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at 84000000 (32-bit, prefetchable)
	Region 1: I/O ports at 0400 [disabled]
	Region 2: Memory at 81801000 (32-bit, non-prefetchable)

00:0f.0 VGA compatible controller: ATI Technologies Inc 215GI [Mach64 GI] (rev 5c)
	Subsystem: Unknown device 1002:0000
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 min, 32 set, cache line size 08
	Interrupt: pin A routed to IRQ 25
	Region 0: Memory at 83000000 (32-bit, prefetchable)
	Region 1: I/O ports at 0400 [disabled]
	Region 2: Memory at 81800000 (32-bit, non-prefetchable)

00:10.0 Class ff00: Apple Computer Inc. Heathrow Mac I/O (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 set, cache line size 08
	Region 0: Memory at f3000000 (32-bit, non-prefetchable)

00:12.0 VGA compatible controller: ATI Technologies Inc 215GT [Mach64 GT] (rev 9a)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 min, 32 set, cache line size 08
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at 82000000 (32-bit, non-prefetchable)
	Region 1: I/O ports at 0400 [disabled]




 > Re: OF device tree, there's a tool named lsprop you need to run on
 > /proc/device_tree (see Paul's or BenH's pages for the source or ask me
 > for a copy).

Monday...

--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

>  > Show me your lspci -vv log :-)
>
> The result in miBoot is the same as in BootX:
>
> 00:0d.0 VGA compatible controller: ATI Technologies Inc 215GI [Mach64 GI] (rev 5c)
> 	Interrupt: pin A routed to IRQ 23
> 	Region 0: Memory at 84000000 (32-bit, prefetchable)
> 	Region 1: I/O ports at 0400 [disabled]
> 	Region 2: Memory at 81801000 (32-bit, non-prefetchable)
>
> 00:0f.0 VGA compatible controller: ATI Technologies Inc 215GI [Mach64 GI] (rev 5c)
> 	Interrupt: pin A routed to IRQ 25
> 	Region 0: Memory at 83000000 (32-bit, prefetchable)
> 	Region 1: I/O ports at 0400 [disabled]
> 	Region 2: Memory at 81800000 (32-bit, non-prefetchable)
>
> 00:12.0 VGA compatible controller: ATI Technologies Inc 215GT [Mach64 GT] (rev 9a)
> 	Interrupt: pin A routed to IRQ 22
> 	Region 0: Memory at 82000000 (32-bit, non-prefetchable)
> 	Region 1: I/O ports at 0400 [disabled]

That does indeed look legit to me, unless XFree decides to disable two out
of three because the (disabled) IO regions are identical.

Assuming the MMIO size is 0x1000 (which is the case for me).

Did the machine survice XFree86 -probeonly? If so, what's the mappings
after that?

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > Did the machine survice XFree86 -probeonly?

Not with the ati driver.  I didn't test it with the fbdev driver.

--
rshapiro@bbn.com


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

Re: lsprop

[Hollis R Blanchard]

On Fri, 29 Sep 2000, Michael Schmitz wrote:
>
> Re: OF device tree, there's a tool named lsprop you need to run on
> /proc/device_tree (see Paul's or BenH's pages for the source or ask me
> for a copy).

There's a link at http://penguinppc.org/dev/pmac.

-Hollis


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Kostas Gewrgiou]

On Fri, 29 Sep 2000, Michael Schmitz wrote:

> That's not fixable at the X level (well, technically it is but I can't
> figure out how and the X people refuse to consider that method). You will
> need to boot via OF and yaboot (or equivalent oldworld) directly, not via
> BootX to avoid the PCI resource conflict. Alternative: fix the resource
> conflict at the kernel level, new patch by me in the works.

Hmm if you think that its fixable in the X level then we should give it
a try, i can't see how though unless we get X to accept this allocations
(are they legal ?). Any relocation is going to break the fbdev side since
there is no way to inform the atyfb driver about this changes.

  Kostas


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

Kostas Gewrgiou wrote:
>
> On Fri, 29 Sep 2000, Michael Schmitz wrote:
>
> > That's not fixable at the X level (well, technically it is but I can't
> > figure out how and the X people refuse to consider that method). You will
> > need to boot via OF and yaboot (or equivalent oldworld) directly, not via
> > BootX to avoid the PCI resource conflict. Alternative: fix the resource
> > conflict at the kernel level, new patch by me in the works.
>
> Hmm if you think that its fixable in the X level then we should give it
> a try, i can't see how though unless we get X to accept this allocations
> (are they legal ?).

I don't know, but I'm pretty sure that Egbert or whoever made the code disable
it has done so for a reason.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

> > That's not fixable at the X level (well, technically it is but I can't
> > figure out how and the X people refuse to consider that method). You will
> > need to boot via OF and yaboot (or equivalent oldworld) directly, not via
> > BootX to avoid the PCI resource conflict. Alternative: fix the resource
> > conflict at the kernel level, new patch by me in the works.
>
> Hmm if you think that its fixable in the X level then we should give it
> a try, i can't see how though unless we get X to accept this allocations
> (are they legal ?). Any relocation is going to break the fbdev side since
> there is no way to inform the atyfb driver about this changes.

I think it is fixable at the X PCI probe level, I just don't know how to
do it (can you say entangled web of maze?).

Another idea (strictly in the Unix tradition): X knows how to mess up the
PCI config from user space so why shouldn't we, before X gets a shot at
it? 'Just' write the correct mapping to the offending BAR from a rc
script. Obvious drawback: the kernel OF tree won't be updated, and the
kernel can't safeguard against insane BAR settings (at least I can't tell
how that would work, one of the PCI gurus please enlighten me). Makes a
nice local DOS tool.

(Don't tell me that's been done already - something like PCI PNP utils
for Linux, anyone?)

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Kostas Gewrgiou]

On Fri, 29 Sep 2000, Michael Schmitz wrote:

> > > That's not fixable at the X level (well, technically it is but I can't
> > > figure out how and the X people refuse to consider that method). You will
> > > need to boot via OF and yaboot (or equivalent oldworld) directly, not via
> > > BootX to avoid the PCI resource conflict. Alternative: fix the resource
> > > conflict at the kernel level, new patch by me in the works.
> >
> > Hmm if you think that its fixable in the X level then we should give it
> > a try, i can't see how though unless we get X to accept this allocations
> > (are they legal ?). Any relocation is going to break the fbdev side since
> > there is no way to inform the atyfb driver about this changes.
>
> I think it is fixable at the X PCI probe level, I just don't know how to
> do it (can you say entangled web of maze?).
>
> Another idea (strictly in the Unix tradition): X knows how to mess up the
> PCI config from user space so why shouldn't we, before X gets a shot at
> it? 'Just' write the correct mapping to the offending BAR from a rc
> script. Obvious drawback: the kernel OF tree won't be updated, and the
> kernel can't safeguard against insane BAR settings (at least I can't tell
> how that would work, one of the PCI gurus please enlighten me). Makes a
> nice local DOS tool.
>
> (Don't tell me that's been done already - something like PCI PNP utils
> for Linux, anyone?)

Hmm fixing the resources from userland wont help you, you have to do it
before atyfb starts up. If i remember right from your logs X didn't had
any problems doing the relocation.

  Kostas


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

> > Another idea (strictly in the Unix tradition): X knows how to mess up the
> > PCI config from user space so why shouldn't we, before X gets a shot at
> > it? 'Just' write the correct mapping to the offending BAR from a rc
> > script. Obvious drawback: the kernel OF tree won't be updated, and the
> > kernel can't safeguard against insane BAR settings (at least I can't tell
> > how that would work, one of the PCI gurus please enlighten me). Makes a
> > nice local DOS tool.
> >
> > (Don't tell me that's been done already - something like PCI PNP utils
> > for Linux, anyone?)
>
> Hmm fixing the resources from userland wont help you, you have to do it
> before atyfb starts up. If i remember right from your logs X didn't had
> any problems doing the relocation.

Wrong - X didn't relocate anything, X just disabled one of the overlapping
regions IIRC (vram with the MMIO mirror region atyfb uses, in my case).
Even assuming X relocates the vram region, atyfb would never know it.
That's the root cause of our problem: X changing the PCI config while
kernel drivers rely on the PCI config remaining unchanged once the driver
inits.

I know it doesn't sound like it can work, but in this particular case
(MMIO regs being accessed not via the MMIO PCI mapping but via one of the
MMIO register mirror areas in video RAM) the user space tool would
actually work if we relocate the MMIO resource - it's not used by the
kernel, and the video RAM mapping can remain untouched by X.

Other solution (on part of X): if relocating one of the two conflicting
resources, pick the one that looks like it isn't video RAM. This only
works with atyfb I guess.

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

Michael Schmitz wrote:
>
> > > Another idea (strictly in the Unix tradition): X knows how to mess up
> > > the PCI config from user space so why shouldn't we, before X gets a shot
> > > at it? 'Just' write the correct mapping to the offending BAR from a rc
> > > script. Obvious drawback: the kernel OF tree won't be updated, and the
> > > kernel can't safeguard against insane BAR settings (at least I can't
> > > tell how that would work, one of the PCI gurus please enlighten me).
> > > Makes a nice local DOS tool.
> > >
> > > (Don't tell me that's been done already - something like PCI PNP utils
> > > for Linux, anyone?)
> >
> > Hmm fixing the resources from userland wont help you, you have to do it
> > before atyfb starts up. If i remember right from your logs X didn't had
> > any problems doing the relocation.
>
> Wrong - X didn't relocate anything, X just disabled one of the overlapping
> regions IIRC (vram with the MMIO mirror region atyfb uses, in my case).
> Even assuming X relocates the vram region, atyfb would never know it.
> That's the root cause of our problem: X changing the PCI config while
> kernel drivers rely on the PCI config remaining unchanged once the driver
> inits.
>
> I know it doesn't sound like it can work, but in this particular case
> (MMIO regs being accessed not via the MMIO PCI mapping but via one of the
> MMIO register mirror areas in video RAM) the user space tool would
> actually work if we relocate the MMIO resource - it's not used by the
> kernel, and the video RAM mapping can remain untouched by X.
>
> Other solution (on part of X): if relocating one of the two conflicting
> resources, pick the one that looks like it isn't video RAM. This only
> works with atyfb I guess.

Yes. If X had to apply a special treatment for each PCI device...

I wouldn't be surprised if it had been a quirk like this which lead to X
acting like it does now.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Geert Uytterhoeven]

On Sun, 1 Oct 2000, Michael Schmitz wrote:
> > > Another idea (strictly in the Unix tradition): X knows how to mess up the
> > > PCI config from user space so why shouldn't we, before X gets a shot at
> > > it? 'Just' write the correct mapping to the offending BAR from a rc
> > > script. Obvious drawback: the kernel OF tree won't be updated, and the
> > > kernel can't safeguard against insane BAR settings (at least I can't tell
> > > how that would work, one of the PCI gurus please enlighten me). Makes a
> > > nice local DOS tool.
> > >
> > > (Don't tell me that's been done already - something like PCI PNP utils
> > > for Linux, anyone?)
> >
> > Hmm fixing the resources from userland wont help you, you have to do it
> > before atyfb starts up. If i remember right from your logs X didn't had
> > any problems doing the relocation.
>
> Wrong - X didn't relocate anything, X just disabled one of the overlapping
> regions IIRC (vram with the MMIO mirror region atyfb uses, in my case).
> Even assuming X relocates the vram region, atyfb would never know it.
> That's the root cause of our problem: X changing the PCI config while
> kernel drivers rely on the PCI config remaining unchanged once the driver
> inits.
>
> I know it doesn't sound like it can work, but in this particular case
> (MMIO regs being accessed not via the MMIO PCI mapping but via one of the
> MMIO register mirror areas in video RAM) the user space tool would
> actually work if we relocate the MMIO resource - it's not used by the
> kernel, and the video RAM mapping can remain untouched by X.

Ever tried setpci (from pciutils)?

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: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

> Ever tried setpci (from pciutils)?

Duh. The syntax is quite messy though, looks like the perfect
shoot-yourself-in-the-foot-and-like-it tool.

I'll recommend it for future problems :-)

	Michael


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

Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Michael Schmitz]

> > I think it is fixable at the X PCI probe level, I just don't know how to
> > do it (can you say entangled web of maze?).
> >
> > Another idea (strictly in the Unix tradition): X knows how to mess up the
> > PCI config from user space so why shouldn't we, before X gets a shot at
> > it? 'Just' write the correct mapping to the offending BAR from a rc
> > script. Obvious drawback: the kernel OF tree won't be updated, and the
> > kernel can't safeguard against insane BAR settings (at least I can't tell
> > how that would work, one of the PCI gurus please enlighten me). Makes a
> > nice local DOS tool.
>
> Hmm fixing the resources from userland wont help you, you have to do it
> before atyfb starts up. If i remember right from your logs X didn't had
> any problems doing the relocation.

While I still think having a userland PCI resource fixup tool would be
nice (at least for debugging purpose) I also promised to come up with a
sanitized version of the atyfb resource fixup patch. Here it is, please
test it (especially Jon, and R. Shapiro) and tell me if it works.

A few remarks on why this patch is necessary, what it does (and doesn't):

On some Powermacs/books with Mach64 graphics, MacOS overrides the PCI
resource mapping set up by OF (IO, MMIO and video RAM all separate,
nonoverlapping regions) to make MMIO overlap the video RAM region. The X
server thinks that's not legit, and disables (or relocates) one of these
regions (video RAM in my case), thereby crashing the kernel on the first
fbdev syscall.
Some of these Powermacs cannot use yaboot (preserving the correct OF
mapping), so another way to fix the overlap mapping as early as possible
is required. 2.3 and 2.4 kernels do this at PCI init time now (thanks to
Geert's PCI resource patch), using the generic memory resource information
in the kernel. 2.2 kernels don't have that generic resource handling so
atyfb is the natural place for the fix here.

My patch first checks that the address OF uses for the atyfb MMIO region
(0x80881000) is not taken by any other PCI device. If another device uses
that area, an alternate area (immediately adjacent to the video RAM area)
is checked. If a free area is found atyfb changes the PCI BAR
corresponding to the MMIO area, the PCI device entry and the OF device
tree node for atyfb.

I'm not positive R. Shapiro's problems with multiple heads are solved by
this (the PCI logs looked sane already), but it definitely helps on
Wallstreet and Lombard models, and perhaps a few others.

Side note:
The MMIO register area is accessible not only by a separate PCI mapping
but also via two aliased register areas at the very end of the LE and BE
video RAM apertures (just make atyfb zero the whole video RAM and you'll
see). atyfb uses one of these areas to access the MMIO registers, that's
why 1) relocating or disabling the video RAM area hurts, and 2) relocating
the separate MMIO mapping after atyfb startup would help remove the
overlap without any adverse effect I can see, aside from the kernel's
view of this PCI resource being at odds with reality. Resolving the PCI
mapping before atyfb starts up keeps X from changing the mapping (no
illegal overlap anymore) and the kernel still has valid resource
information.

The patch is relative to 2.2.17pre20-benh1 but should apply cleanly to
anything between 2.2.14 and 2.2.18. It is not required for 2.3 and 2.4
kernels.

	Michael

--- drivers/video/atyfb.c.benh	Wed Aug 23 20:26:33 2000
+++ drivers/video/atyfb.c	Sat Sep 30 14:29:11 2000
@@ -3241,14 +3241,72 @@
 #endif
 }

+/*
+ * Check PCI resource overlap between any PCI device (but mydev) and this region.
+ * This function does not discriminate between IO and memory space so memory regions
+ * will be considered to overlap IO regions though they might be decoded separate on
+ * machines with separate memory and IO access. This being for PPC I don't care - MSch.
+ */
+__initfunc(int atyfb_check_overlap(struct pci_dev *mydev, unsigned long mybase, unsigned int mysize))
+{
+
+    int i,j;
+    struct pci_dev *pdev;
+
+    for (pdev = pci_devices; pdev; pdev = pdev->next) {
+
+	if (pdev == mydev)
+	    continue;
+
+        for (i = 0, j = 2; i < 6 && pdev->base_address[i]; i++) {
+	    int io, breg = PCI_BASE_ADDRESS_0 + (i << 2);
+	    unsigned long base;
+	    u32 size, pbase;
+
+	    base = pdev->base_address[i];
+
+	    if (!base)
+	        continue;
+
+	    io = (base & PCI_BASE_ADDRESS_SPACE)==PCI_BASE_ADDRESS_SPACE_IO;
+
+	    pci_read_config_dword(pdev, breg, &pbase);
+	    pci_write_config_dword(pdev, breg, 0xffffffff);
+	    pci_read_config_dword(pdev, breg, &size);
+	    pci_write_config_dword(pdev, breg, pbase);
+
+	    if (io) {
+		size &= PCI_BASE_ADDRESS_IO_MASK;
+		base &= PCI_BASE_ADDRESS_IO_MASK;
+	    } else {
+		size &= PCI_BASE_ADDRESS_MEM_MASK;
+		base &= PCI_BASE_ADDRESS_MEM_MASK;
+	    }
+	    size = ~(size) + 1;
+
+	    if ( (base < mybase+mysize-1 && base+size-1 >= mybase)
+	    	 || (mybase < base+size-1 && mybase+mysize-1 >= base) ) {
+		printk("\nPCI resource conflict: %lx-%lx overlaps %lx-%lx !\n",
+		    base, base+size-1, mybase, mybase+mysize-1);
+		return 1;	/* conflicting region overlaps */
+	    }
+
+        }
+    }
+
+    return 0;			/* no conflicting region found */
+
+}
+
+
 #ifdef CONFIG_FB_OF
 __initfunc(void atyfb_of_init(struct device_node *dp))
 {
-    unsigned long addr;
+    unsigned long addr, io_base=NULL;
     u8 bus, devfn;
     u16 cmd;
     struct fb_info_aty *info;
-    int i;
+    int i, i_frame, i_regs, i_io, naddr;

     if (device_is_compatible(dp, "ATY,264LTPro")) {
 	/* XXX kludge for now */
@@ -3283,6 +3341,12 @@
     }
     memset(info, 0, sizeof(struct fb_info_aty));

+    /*
+     * Use register set in the little endian aperture regardless of what was set
+     * up in OF or the PCI registers for MMIO. We could use the registers in the
+     * big endian aperture as well (at least on some LTPro), or set up a separate
+     * PCI mapping. Seems to work either way (again, on my Lombard) - MSch.
+     */
     info->ati_regbase_phys = 0x7ff000+addr;
     info->ati_regbase = (unsigned long)ioremap(info->ati_regbase_phys,
 						   0x2000);
@@ -3296,8 +3360,49 @@
     info->ati_regbase_phys += 0xc00;
     info->ati_regbase += 0xc00;

-    /* enable memory-space accesses using config-space command register */
+    /* search PCI config space for VRAM, IO and MMIO regions */
     if (pci_device_loc(dp, &bus, &devfn) == 0) {
+
+	for (i = 0; i < dp->n_addrs + 2; i++) {
+	    int io, breg = PCI_BASE_ADDRESS_0 + (i << 2);
+	    unsigned long base;
+	    u32 size, pbase;
+
+	    base = dp->addrs[i].address;
+
+	    pcibios_read_config_dword(bus, devfn, breg, &pbase);
+	    pcibios_write_config_dword(bus, devfn, breg, 0xffffffff);
+	    pcibios_read_config_dword(bus, devfn, breg, &size);
+	    pcibios_write_config_dword(bus, devfn, breg, pbase);
+
+	    io = (pbase & PCI_BASE_ADDRESS_SPACE)==PCI_BASE_ADDRESS_SPACE_IO;
+
+	    if (io) {
+		size &= ~1;
+		pbase &= ~1;
+		i_io = i;
+	    }
+
+	    size = ~(size) + 1;
+
+	    if (size == 0)
+	    	break;
+
+	    if (!base) {
+		dp->addrs[i].address = pbase;
+		dp->addrs[i].size = size;
+	    }
+	    if (pbase == addr) {
+		i_frame = i;
+	    } else if (size == 0x1000) {
+		i_regs = i;
+		io_base = pbase;
+            }
+	}
+
+	naddr = i;
+
+        /* enable memory-space accesses using config-space command register */
 	pcibios_read_config_word(bus, devfn, PCI_COMMAND, &cmd);
 	if (cmd != 0xffff) {
 	    cmd |= PCI_COMMAND_MEMORY;
@@ -3318,6 +3423,105 @@
 	    printk("atyfb_init: ioremap() returned NULL\n");
 	    kfree(info);
 	    return;
+    }
+
+    /*
+     * Fix MMIO mapping if MMIO and VRAM PCI mappings set up by MacOS overlap - MSch.
+     * Note that we can't move the VRAM base address to the BE aperture (this would move the whole
+     * VRAM region, not resize it) so it's easier to remap MMIO someplace else.
+     */
+    if ( (dp->addrs[i_frame].address < dp->addrs[i_regs].address+dp->addrs[i_regs].size
+	 && dp->addrs[i_frame].address+dp->addrs[i_frame].size >= dp->addrs[i_regs].address)
+    	 || (dp->addrs[i_regs].address < dp->addrs[i_frame].address+dp->addrs[i_frame].size
+    	    && dp->addrs[i_regs].address+dp->addrs[i_regs].size >= dp->addrs[i_frame].address) ) {
+
+	    struct pci_dev *pdev = pci_find_slot(bus, devfn);
+	    int io, breg = PCI_BASE_ADDRESS_0 + (i_regs << 2);
+	    int flags;
+	    unsigned long base;
+	    u32 size, pbase, new;
+
+	    base = dp->addrs[i_regs].address;
+
+	    pcibios_read_config_dword(bus, devfn, breg, &pbase);
+	    pcibios_write_config_dword(bus, devfn, breg, 0xffffffff);
+	    pcibios_read_config_dword(bus, devfn, breg, &size);
+	    pcibios_write_config_dword(bus, devfn, breg, pbase);
+
+	    io = (pbase & PCI_BASE_ADDRESS_SPACE)==PCI_BASE_ADDRESS_SPACE_IO;
+	    flags = (pbase & PCI_BASE_ADDRESS_MEM_MASK);
+
+	    if (io) {
+		size &= ~1;
+		pbase &= ~1;
+	    }
+	    size = ~(size) + 1;
+
+	    printk("atyfb: region %d ofbase 0x%lx breg %d io %d pbase 0x%lx size 0x%lx overlaps VRAM ",
+		i_regs, base, breg, io, pbase, size);
+
+	    /*
+	     * Best guess: try address used by OF/yaboot, check for overlap with existing devices!
+	     */
+	    new = 0x80881000;
+
+	    if (atyfb_check_overlap(pdev, new, size)) {
+		/*
+		 * Something overlaps our new mapping. Move MMIO before frame buffer and past I/O for now.
+		 * Need to walk PCI resources to find guaranteed free spot (currently we bail out when our
+		 * next best guess is taken as well).
+		 */
+		if (dp->addrs[i_io].address+dp->addrs[i_io].size+dp->addrs[i_regs].size < dp->addrs[i_frame].address) {
+		    new = (dp->addrs[i_io].address&0xff000000) | (dp->addrs[i_regs].address&0x00ffffff);
+		} else {
+		    new = (dp->addrs[i_frame].address+dp->addrs[i_frame].size);
+		}
+		if (atyfb_check_overlap(pdev, new, size)) {
+		    printk("\natyfb: can't resolve overlap, bailing out!\n");
+		    /* gotos are evil */
+		    new = base;
+		}
+	    }
+
+	    new |= flags & 0x0f;
+
+	    pcibios_write_config_dword(bus, devfn, breg, new);
+
+	    pcibios_read_config_dword(bus, devfn, breg, &pbase);
+	    pcibios_write_config_dword(bus, devfn, breg, 0xffffffff);
+	    pcibios_read_config_dword(bus, devfn, breg, &size);
+	    pcibios_write_config_dword(bus, devfn, breg, pbase);
+
+	    if (new != pbase)
+	    	printk("atyfb: failed to remap MMIO region! \n");
+
+	    /* update PCI struct */
+	    if (!pdev)
+	    	printk("atyfb: no pci_dev registered for device!\n");
+	    else
+	    	pdev->base_address[i_regs] = pbase;
+
+	    io = (pbase & PCI_BASE_ADDRESS_SPACE)==PCI_BASE_ADDRESS_SPACE_IO;
+	    flags = (pbase & ~PCI_BASE_ADDRESS_MEM_MASK);
+
+	    if (io) {
+		size &= ~1;
+		pbase &= ~1;
+	    }
+	    size = ~(size) + 1;
+
+	    printk(" - reassigned to pbase 0x%lx size 0x%lx ! \n", pbase, size);
+
+	    /* update OF device tree */
+	    dp->addrs[i_regs].address = pbase;
+
+	    /*
+	     * Note: we only fixed up PCI config and brought the OF device tree
+	     * in line with the new PCI config. regbase still is mapped to the original
+	     * location in the LE aperture which overlaps with the full (LE and BE)
+	     * VRAM. If someone at xfree ever starts to check if regbase falls within
+	     * the PCI region of VRAM, slap them silly - MSch.
+	     */
     }

     if (!aty_init(info, dp->full_name)) {

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Olaf Hering]

Hi,

while we are about to improve the atyfb, is it possible to fix the color
depth switching?
When I boot without a kernel arg I end up with 8 bit at console. I can't
increase the color depth afterwards with fbset, and mol crashes when it
tries to do that. When I specify atyfb:cmode:24 everythings works fine
and I can switch down to 8 and back to 24 and mol starts fine.

This trace may give a hint whats wrong here. Its the kernel with
Michaels ressource fix on a Wallstreet, mol should use 1024x768-60 with
24 bit. I did not try other Mach64 machines yet.


WARNING: This version of ksymoops is obsolete.
WARNING: The current version can be obtained from ftp://ftp.ocs.com.au/pub/ksymoops
Options used: -v /boot/vmlinux (specified)
              -o /lib/modules/2.2.16/ (default)
              -k /proc/ksyms (default)
              -l /proc/modules (default)
              -m /boot/System.map-2.2.16 (specified)
              -c 1 (default)

Warning: memstat symbol __insmod_memstat_O/lib/modules/2.2.16/misc/memstat.o_M39D30ACF_V131600 not found in /lib/modules/2.2.16/misc/memstat.o.  Ignoring /lib/modules/2.2.16/misc/memstat.o entry
Warning: memstat symbol __insmod_memstat_S.data_L316 not found in /lib/modules/2.2.16/misc/memstat.o.  Ignoring /lib/modules/2.2.16/misc/memstat.o entry
Warning: memstat symbol __insmod_memstat_S.rodata_L16 not found in /lib/modules/2.2.16/misc/memstat.o.  Ignoring /lib/modules/2.2.16/misc/memstat.o entry
Warning: memstat symbol __insmod_memstat_S.text_L1084 not found in /lib/modules/2.2.16/misc/memstat.o.  Ignoring /lib/modules/2.2.16/misc/memstat.o entry
Warning: dmasound symbol __insmod_dmasound_O/lib/modules/2.2.16/misc/dmasound.o_M39D30999_V131600 not found in /lib/modules/2.2.16/misc/dmasound.o.  Ignoring /lib/modules/2.2.16/misc/dmasound.o entry
Warning: dmasound symbol __insmod_dmasound_S.bss_L752 not found in /lib/modules/2.2.16/misc/dmasound.o.  Ignoring /lib/modules/2.2.16/misc/dmasound.o entry
Warning: dmasound symbol __insmod_dmasound_S.data_L1932 not found in /lib/modules/2.2.16/misc/dmasound.o.  Ignoring /lib/modules/2.2.16/misc/dmasound.o entry
Warning: dmasound symbol __insmod_dmasound_S.rodata_L1228 not found in /lib/modules/2.2.16/misc/dmasound.o.  Ignoring /lib/modules/2.2.16/misc/dmasound.o entry
Warning: dmasound symbol __insmod_dmasound_S.text_L23400 not found in /lib/modules/2.2.16/misc/dmasound.o.  Ignoring /lib/modules/2.2.16/misc/dmasound.o entry
Sep 30 23:07:41 plum kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 (error 40000000)
Sep 30 23:07:41 plum kernel: NIP: C017EB44 XER: 00000000 LR: C018491C REGS: c4119bd0 TRAP: 0300
Sep 30 23:07:41 plum kernel: MSR: 00009032 [EEIRDRME]
Sep 30 23:07:41 plum kernel: TASK = c4118000[4326] 'mol' mm->pgd c26c0000 Last syscall: 4
Sep 30 23:07:41 plum kernel: last math c4118000
Sep 30 23:07:41 plum kernel: GPR00: 0000000C C4119C80 C4118000 C0613FE8 C029F928 CBEFEF00 0000001F 00130000
Sep 30 23:07:41 plum kernel: GPR08: 00000000 00000000 00000000 00000007 C029F928 01882AE0 C0290000 C3C12000
Sep 30 23:07:41 plum kernel: GPR16: C02A0000 C0210000 00000000 CBEFEF00 CBEFEF3E 00000000 00000000 00000000
Sep 30 23:07:41 plum kernel: GPR24: C4119D97 C029B1B0 00000000 FFFFFFFC 00000400 CBEFEF00 0000001F CBEFEF00
Sep 30 23:07:41 plum kernel: Call backtrace:
Sep 30 23:07:41 plum kernel: C029FFA0 C0613FE8 C017735C C00FF388 C00FFB30 C01073E8 C01099BC
Sep 30 23:07:41 plum kernel: C0104568 C0031588 C0003EC4 0160FDF0 014F52BC 014F4868 014F549C
Sep 30 23:07:41 plum kernel: 014E65C0 014E1824 01804CFC 01831938 0182DBA8 018208F4 01820B14
Sep 30 23:07:41 plum kernel: 0180CEC8 014BE85C 00000000
Sep 30 23:07:41 plum kernel: Kernel panic: kernel access of bad area pc c017eb44 lr c018491c address 0 tsk mol/4326
Sep 30 23:07:41 plum kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000001c (error 40000000)
Sep 30 23:07:41 plum kernel: NIP: C017E95C XER: 00000000 LR: C0184874 REGS: c3e59cf0 TRAP: 0300
Sep 30 23:07:41 plum kernel: MSR: 00009032 [EEIRDRME]
Sep 30 23:07:41 plum kernel: TASK = c3e58000[305] 'gpm' mm->pgd c3db6000 Last syscall: 54
Sep 30 23:07:41 plum kernel: last math c4118000
Sep 30 23:07:41 plum kernel: GPR00: 00000650 C3E59DA0 C3E58000 C020FA14 C029F928 00007065 D00DF6E0 000006E0
Sep 30 23:07:41 plum kernel: GPR08: C029F928 0000001C 00000000 00000000 00000010 0182858C 00000000 01820000
Sep 30 23:07:41 plum kernel: GPR16: 01820D60 01820000 01820000 00000000 00009032 03E59E80 00000000 C0004154
Sep 30 23:07:41 plum kernel: GPR24: C3C12000 00000000 00000018 00000037 C0210000 00000003 00000000 00000400
Sep 30 23:07:41 plum kernel: Call backtrace:
Sep 30 23:07:41 plum kernel: C01054CC 01820D64 C0177238 C00FB30C C010153C C00FF9F8 C01065AC
Sep 30 23:07:41 plum kernel: C003DDAC C0003EC4 00000001 018031F0 0170785C 00000000
Sep 30 23:07:41 plum kernel: Kernel panic: kernel access of bad area pc c017e95c lr c0184874 address 1C tsk gpm/305
Warning, Code line not seen, dumping what data is available

>>NIP: c017eb44 <fbcon_cfb32_putcs+40/26c>
Trace: c029ffa0 <fb_display+678/43ec>
Trace: c0613fe8 <_end+370290/1058c2fc>
Trace: c017735c <fbcon_putcs+fc/124>
Trace: c00ff388 <do_con_write+658/6a0>
Trace: c00ffb30 <con_write+18/3c>
Trace: c01073e8 <opost_block+230/244>
Trace: c01099bc <write_chan+180/2d8>
Trace: c0104568 <tty_write+214/2b0>
Trace: c0031588 <sys_write+124/164>
Trace: c0003ec4 <syscall_ret_1+0/b4>
Trace: 0160fdf0 Before first symbol
Trace: 014f52bc Before first symbol
Trace: 014f4868 Before first symbol
Trace: 014f549c Before first symbol
Trace: 014e65c0 Before first symbol
Trace: 014e1824 Before first symbol
Trace: 01804cfc Before first symbol
Trace: 01831938 Before first symbol
Trace: 0182dba8 Before first symbol
Trace: 018208f4 Before first symbol
Trace: 01820b14 Before first symbol
Trace: 0180cec8 Before first symbol
Trace: 014be85c Before first symbol
Trace: 00000000 Before first symbol
>>NIP: c017eb44 <fbcon_cfb32_putcs+40/26c>
>>NIP: c017e95c <fbcon_cfb32_putc+84/22c>
Trace: c01054cc <tty_open+204/3ac>
Trace: 01820d64 Before first symbol
Trace: c0177238 <fbcon_putc+e8/110>
Trace: c00fb30c <complement_pos+14c/160>
Trace: c010153c <set_selection+460/76c>
Trace: c00ff9f8 <tioclinux+e8/208>
Trace: c01065ac <tty_ioctl+434/520>
Trace: c003ddac <sys_ioctl+288/2ac>
Trace: c0003ec4 <syscall_ret_1+0/b4>
Trace: 00000001 Before first symbol
Trace: 018031f0 Before first symbol
Trace: 0170785c Before first symbol
Trace: 00000000 Before first symbol
>>NIP: c017e95c <fbcon_cfb32_putc+84/22c>


12 warnings issued.  Results may not be reliable.



Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Geert Uytterhoeven]

On Sun, 1 Oct 2000, Olaf Hering wrote:
> while we are about to improve the atyfb, is it possible to fix the color
> depth switching?
> When I boot without a kernel arg I end up with 8 bit at console. I can't
> increase the color depth afterwards with fbset, and mol crashes when it
> tries to do that. When I specify atyfb:cmode:24 everythings works fine
> and I can switch down to 8 and back to 24 and mol starts fine.

Does it also crash when you increase the color depth with fbset?

I don't use MOL (I don't have MacOS), but I never saw this problem.

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: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Michael Schmitz]

> On Sun, 1 Oct 2000, Olaf Hering wrote:
> > while we are about to improve the atyfb, is it possible to fix the color
> > depth switching?
> > When I boot without a kernel arg I end up with 8 bit at console. I can't
> > increase the color depth afterwards with fbset, and mol crashes when it
> > tries to do that. When I specify atyfb:cmode:24 everythings works fine
> > and I can switch down to 8 and back to 24 and mol starts fine.
>
> Does it also crash when you increase the color depth with fbset?

Does atyfb only register console drivers up to 8 bit when booted in 8 bit
mode? Is the engine configuration different with regard to video memory
setup between 8 and 24 bit?

Another atyfb issue: if I cold boot the Lombard with external monitor
attached, the video RAM layout is apparenty set up by OF to match the last
geometry used by MacOS on that screen (I tried 1152x870) but atyfb draws a
framebuffer according to the vmode passed to the kernel (1024x768 in this
case). I need to set the resolution to 1024x768 in MacOS to get a
decent image on the external monitor in Linux. Seems atyfb doesn't
properly init the whole engine here. Any idea where to fix that?
I've noticed the values of MEM_CNTL, EXT_MEM_CNTL and CRT_GEN_CNTL vary
when booting with the different resolutions or booting directly from OF
but so far it doesn't look conclusive.

I'm trying to get a handle on using both LCD and external monitor in
Linux, that's why I started playing with it.

	Michael


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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Benjamin Herrenschmidt]

>
>Does atyfb only register console drivers up to 8 bit when booted in 8 bit
>mode? Is the engine configuration different with regard to video memory
>setup between 8 and 24 bit?
>
>Another atyfb issue: if I cold boot the Lombard with external monitor
>attached, the video RAM layout is apparenty set up by OF to match the last
>geometry used by MacOS on that screen (I tried 1152x870) but atyfb draws a
>framebuffer according to the vmode passed to the kernel (1024x768 in this
>case). I need to set the resolution to 1024x768 in MacOS to get a
>decent image on the external monitor in Linux. Seems atyfb doesn't
>properly init the whole engine here. Any idea where to fix that?
>I've noticed the values of MEM_CNTL, EXT_MEM_CNTL and CRT_GEN_CNTL vary
>when booting with the different resolutions or booting directly from OF
>but so far it doesn't look conclusive.
>
>I'm trying to get a handle on using both LCD and external monitor in
>Linux, that's why I started playing with it.

You have to choices. Either enable both outputs on the same CRTC (works
with old "LG" chips found in some wallstreet's), or program both CRTCs
(Rage LT Pro only). In the later case, you can use a different setup for
the LCD, do real dual-head, have a higher refresh rate for the CRT, etc....

Ben.

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Michael Schmitz]

> >I'm trying to get a handle on using both LCD and external monitor in
> >Linux, that's why I started playing with it.
>
> You have to choices. Either enable both outputs on the same CRTC (works
> with old "LG" chips found in some wallstreet's), or program both CRTCs

Works automagically if I plug in the external after booting. If I have the
external monitor plugged in at boot, the LCD is disabled on boot. But you
probably knew that.

> (Rage LT Pro only). In the later case, you can use a different setup for
> the LCD, do real dual-head, have a higher refresh rate for the CRT, etc....

Fine, but how would I do that? And how do I tell atyfb to set up two
framebuffers for the two separate screens`?

	Michael


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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Geert Uytterhoeven]

On Mon, 2 Oct 2000, Michael Schmitz wrote:
> > (Rage LT Pro only). In the later case, you can use a different setup for
> > the LCD, do real dual-head, have a higher refresh rate for the CRT, etc....
>
> Fine, but how would I do that? And how do I tell atyfb to set up two
> framebuffers for the two separate screens`?

By adding code to atyfb. Sorry for the short answer ;-)

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: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Michael Schmitz]

> > Fine, but how would I do that? And how do I tell atyfb to set up two
> > framebuffers for the two separate screens`?
>
> By adding code to atyfb. Sorry for the short answer ;-)

Har har. I almost guessed that. Once I figure out how to initialize the
chip to use separate chunks of RAM for the two ports, the little hack to
make atyfb parse multiple vmode arguments (and consequently set up
and register multiple framebuffers) would indeed be trivial.

Do you have any idea if the config registers dumped to the console by
atyfb are all I need to look at?

	Michael


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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Geert Uytterhoeven]

On Tue, 3 Oct 2000, Michael Schmitz wrote:
> > > Fine, but how would I do that? And how do I tell atyfb to set up two
> > > framebuffers for the two separate screens`?
> >
> > By adding code to atyfb. Sorry for the short answer ;-)
>
> Har har. I almost guessed that. Once I figure out how to initialize the
> chip to use separate chunks of RAM for the two ports, the little hack to
> make atyfb parse multiple vmode arguments (and consequently set up
> and register multiple framebuffers) would indeed be trivial.
>
> Do you have any idea if the config registers dumped to the console by
> atyfb are all I need to look at?

They're not sufficient. They're relevant for clock and bus programming only.
A second CRTC is certainly not covered by them.

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: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Olaf Hering]

On Mon, Oct 02, Geert Uytterhoeven wrote:

> On Sun, 1 Oct 2000, Olaf Hering wrote:
> > while we are about to improve the atyfb, is it possible to fix the color
> > depth switching?
> > When I boot without a kernel arg I end up with 8 bit at console. I can't
> > increase the color depth afterwards with fbset, and mol crashes when it
> > tries to do that. When I specify atyfb:cmode:24 everythings works fine
> > and I can switch down to 8 and back to 24 and mol starts fine.
>
> Does it also crash when you increase the color depth with fbset?

It was not clear enough: I can not fbset when I have only 8 bit. But XF4
can increase the color depth, maybe it does that in a different way?

plum:~ # fbset

mode "1024x768-60"
    # D: 64.666 MHz, H: 48.115 kHz, V: 59.696 Hz
    geometry 1024 768 1024 4080 8
    timings 15464 144 40 29 3 136 6
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

plum:~ # fbset -depth 24
ioctl FBIOPUT_VSCREENINFO: Invalid argument


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriver with rage II/rage pro)

[Michel Dänzer]

Olaf Hering wrote:
>
> On Mon, Oct 02, Geert Uytterhoeven wrote:
>
> > On Sun, 1 Oct 2000, Olaf Hering wrote:
> > > while we are about to improve the atyfb, is it possible to fix the color
> > > depth switching?
> > > When I boot without a kernel arg I end up with 8 bit at console. I can't
> > > increase the color depth afterwards with fbset, and mol crashes when it
> > > tries to do that. When I specify atyfb:cmode:24 everythings works fine
> > > and I can switch down to 8 and back to 24 and mol starts fine.
> >
> > Does it also crash when you increase the color depth with fbset?
>
> It was not clear enough: I can not fbset when I have only 8 bit. But XF4
> can increase the color depth, maybe it does that in a different way?
>
> plum:~ # fbset
>
> mode "1024x768-60"
>     # D: 64.666 MHz, H: 48.115 kHz, V: 59.696 Hz
>     geometry 1024 768 1024 4080 8
>     timings 15464 144 40 29 3 136 6
>     accel true
>     rgba 8/0,8/0,8/0,0/0
> endmode
>
> plum:~ # fbset -depth 24
> ioctl FBIOPUT_VSCREENINFO: Invalid argument

What about -depth 32? Maybe X uses depth 24, 32 bpp.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriver with rage II/rage pro)

[Olaf Hering]

On Mon, Oct 02, Michel Dänzer wrote:

> > plum:~ # fbset -depth 24
> > ioctl FBIOPUT_VSCREENINFO: Invalid argument
>
> What about -depth 32? Maybe X uses depth 24, 32 bpp.

Same error.

X can use 8,15,24.  But 32 doesnt work:
(**) ATI(0): Depth 32, (--) framebuffer bpp 32
(EE) ATI(0): Weight given (000) is inconsistent with the depth (32)

Looks like that special chip needs a little extra setup in the kernel
code?


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriverwith rage II/rage pro)

[Michel Dänzer]

Olaf Hering wrote:
>
> On Mon, Oct 02, Michel Dänzer wrote:
>
> > > plum:~ # fbset -depth 24
> > > ioctl FBIOPUT_VSCREENINFO: Invalid argument
> >
> > What about -depth 32? Maybe X uses depth 24, 32 bpp.
>
> Same error.
>
> X can use 8,15,24.  But 32 doesnt work:
> (**) ATI(0): Depth 32, (--) framebuffer bpp 32
> (EE) ATI(0): Weight given (000) is inconsistent with the depth (32)

I was talking about fbset... there is no depth 32 yet in X until the alpha
channel is supported :)


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriverwith rage II/rage pro)

[Olaf Hering]

On Mon, Oct 02, Michel Dänzer wrote:

> Olaf Hering wrote:
> >
> > On Mon, Oct 02, Michel Dänzer wrote:
> >
> > > > plum:~ # fbset -depth 24
> > > > ioctl FBIOPUT_VSCREENINFO: Invalid argument
> > >
> > > What about -depth 32? Maybe X uses depth 24, 32 bpp.
> >
> > Same error.
> >
> > X can use 8,15,24.  But 32 doesnt work:
> > (**) ATI(0): Depth 32, (--) framebuffer bpp 32
> > (EE) ATI(0): Weight given (000) is inconsistent with the depth (32)
>
> I was talking about fbset... there is no depth 32 yet in X until the alpha
> channel is supported :)

Ok, first the console, then the alpha channel ;)

I got that in syslog when I try to switch the color depth:

Oct  2 23:02:45 plum kernel: not enough video RAM



Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriver with rage II/rage pro)

[Geert Uytterhoeven]

On Mon, 2 Oct 2000, Olaf Hering wrote:
> On Mon, Oct 02, Michel Dänzer wrote:
> > > plum:~ # fbset -depth 24
> > > ioctl FBIOPUT_VSCREENINFO: Invalid argument
> >
> > What about -depth 32? Maybe X uses depth 24, 32 bpp.
>
> Same error.

Depth 32 needs even more RAM :-)

> X can use 8,15,24.  But 32 doesnt work:
> (**) ATI(0): Depth 32, (--) framebuffer bpp 32
> (EE) ATI(0): Weight given (000) is inconsistent with the depth (32)
>
> Looks like that special chip needs a little extra setup in the kernel
> code?

Nitpicking about terminology, it's depth 24, bpp (bits per pixel) 32.

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: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriver with rage II/rage pro)

[Michael Schmitz]

> > What about -depth 32? Maybe X uses depth 24, 32 bpp.
>
> Same error.
>
> X can use 8,15,24.  But 32 doesnt work:
> (**) ATI(0): Depth 32, (--) framebuffer bpp 32
> (EE) ATI(0): Weight given (000) is inconsistent with the depth (32)
>
> Looks like that special chip needs a little extra setup in the kernel
> code?

Nope, X doesn't handle 32 bit depth (I've looked at the ati driver for
hours to no avail). The kernel driver has all necessary code to set up
the engine for 32 bit depth (rgb weight 8888).

	Michael


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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriverwith rage II/rage pro)

[Michel Dänzer]

Michael Schmitz wrote:
>
> > > What about -depth 32? Maybe X uses depth 24, 32 bpp.
> >
> > Same error.
> >
> > X can use 8,15,24.  But 32 doesnt work:
> > (**) ATI(0): Depth 32, (--) framebuffer bpp 32
> > (EE) ATI(0): Weight given (000) is inconsistent with the depth (32)
> >
> > Looks like that special chip needs a little extra setup in the kernel
> > code?
>
> Nope, X doesn't handle 32 bit depth (I've looked at the ati driver for
> hours to no avail). The kernel driver has all necessary code to set up
> the engine for 32 bit depth (rgb weight 8888).

I'll say it again: 32 bpp is depth 24, 32 fbbpp in X 4 terms. No depth 32 yet.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + atidriverwith rage II/rage pro)

[Michael Schmitz]

> > > Looks like that special chip needs a little extra setup in the kernel
> > > code?
> >
> > Nope, X doesn't handle 32 bit depth (I've looked at the ati driver for
> > hours to no avail). The kernel driver has all necessary code to set up
> > the engine for 32 bit depth (rgb weight 8888).
>
> I'll say it again: 32 bpp is depth 24, 32 fbbpp in X 4 terms. No depth 32 yet.

That's what I meant to say. Sorry if it was prone to misunderstanding, my
intention wasn't to bash X.

	Michael


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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Geert Uytterhoeven]

On Mon, 2 Oct 2000, Olaf Hering wrote:
> On Mon, Oct 02, Geert Uytterhoeven wrote:
> > On Sun, 1 Oct 2000, Olaf Hering wrote:
> > > while we are about to improve the atyfb, is it possible to fix the color
> > > depth switching?
> > > When I boot without a kernel arg I end up with 8 bit at console. I can't
> > > increase the color depth afterwards with fbset, and mol crashes when it
> > > tries to do that. When I specify atyfb:cmode:24 everythings works fine
> > > and I can switch down to 8 and back to 24 and mol starts fine.
> >
> > Does it also crash when you increase the color depth with fbset?
>
> It was not clear enough: I can not fbset when I have only 8 bit. But XF4
> can increase the color depth, maybe it does that in a different way?
>
> plum:~ # fbset
>
> mode "1024x768-60"
>     # D: 64.666 MHz, H: 48.115 kHz, V: 59.696 Hz
>     geometry 1024 768 1024 4080 8
                             ^^^^
>     timings 15464 144 40 29 3 136 6
>     accel true
>     rgba 8/0,8/0,8/0,0/0
> endmode
>
> plum:~ # fbset -depth 24
> ioctl FBIOPUT_VSCREENINFO: Invalid argument

That's normal, you also have to decrease the virtual size, which was
initialized to the maximum possible value w.r.t. RAM size.

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: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Olaf Hering]

On Tue, Oct 03, Geert Uytterhoeven wrote:

> > plum:~ # fbset
> >
> > mode "1024x768-60"
> >     # D: 64.666 MHz, H: 48.115 kHz, V: 59.696 Hz
> >     geometry 1024 768 1024 4080 8
>                              ^^^^
> >     timings 15464 144 40 29 3 136 6
> >     accel true
> >     rgba 8/0,8/0,8/0,0/0
> > endmode
> >
> > plum:~ # fbset -depth 24
> > ioctl FBIOPUT_VSCREENINFO: Invalid argument
>
> That's normal, you also have to decrease the virtual size, which was
> initialized to the maximum possible value w.r.t. RAM size.

It seems to be a problem with the color palette or somehow color depth
related.
First I just switched to 1024x768-60 and it didn't work, the next time I
added -depth 24 and it works fine. So mol can not increase the color
depth itself? I have depth 15 here right now in the molrc

plum:~ # fbset 1024x768-60 -a

-> crash

plum:~ # fbset 1024x768-60 -a -depth 24
plum:~ # exit
*** Mac-on-Linux full screen video console ***
Opening console video 1024*768, depth 32, 60.0 Hz  [offs:0, rb:4096]
Closing console video.
uOpening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
Exiting MOL
Closing console video.
plum:~ # fbset 1024x768-60 -a -depth 8
plum:~ # exit
*** Mac-on-Linux full screen video console ***
Opening console video 1024*768, depth 32, 60.0 Hz  [offs:0, rb:4096]
Closing console video.
Opening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
Closing console video.
Opening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
Closing console video.
Opening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
Exiting MOL
Closing console video.


So it looks like the atyfb driver doesnt init the color space stuff
correct.
How can we fix that?



Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Michael Schmitz]

> > > plum:~ # fbset -depth 24
> > > ioctl FBIOPUT_VSCREENINFO: Invalid argument
> >
> > That's normal, you also have to decrease the virtual size, which was
> > initialized to the maximum possible value w.r.t. RAM size.
>
> It seems to be a problem with the color palette or somehow color depth
> related.
> First I just switched to 1024x768-60 and it didn't work, the next time I
> added -depth 24 and it works fine. So mol can not increase the color

vmode also needs both arguments for me. fbset crashing when you omit the
depth argument is weird - does fbset not read the current depth from the
device before a mode set, Geert?

We sure could hack the kernel ioctl to take depth 0 as 'dont change' and
print a warning?

> depth itself? I have depth 15 here right now in the molrc
>
> plum:~ # fbset 1024x768-60 -a
>
> -> crash
>
> plum:~ # fbset 1024x768-60 -a -depth 24
> plum:~ # exit
> *** Mac-on-Linux full screen video console ***
> Opening console video 1024*768, depth 32, 60.0 Hz  [offs:0, rb:4096]
> Closing console video.
> uOpening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
> Exiting MOL
> Closing console video.
> plum:~ # fbset 1024x768-60 -a -depth 8
> plum:~ # exit
> *** Mac-on-Linux full screen video console ***
> Opening console video 1024*768, depth 32, 60.0 Hz  [offs:0, rb:4096]
> Closing console video.
> Opening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
> Closing console video.
> Opening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
> Closing console video.
> Opening console video 1024*768, depth 15, 60.0 Hz  [offs:0, rb:2048]
> Exiting MOL
> Closing console video.
>
>
> So it looks like the atyfb driver doesnt init the color space stuff
> correct.

What happened on each of the MOL runs? I don't see problems with MOL color
map setting at least for 32 bit depth.

	Michael


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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Geert Uytterhoeven]

On Tue, 3 Oct 2000, Michael Schmitz wrote:
> > > > plum:~ # fbset -depth 24
> > > > ioctl FBIOPUT_VSCREENINFO: Invalid argument
> > >
> > > That's normal, you also have to decrease the virtual size, which was
> > > initialized to the maximum possible value w.r.t. RAM size.
> >
> > It seems to be a problem with the color palette or somehow color depth
> > related.
> > First I just switched to 1024x768-60 and it didn't work, the next time I
> > added -depth 24 and it works fine. So mol can not increase the color
>
> vmode also needs both arguments for me. fbset crashing when you omit the
> depth argument is weird - does fbset not read the current depth from the
> device before a mode set, Geert?

Yes it does.

> We sure could hack the kernel ioctl to take depth 0 as 'dont change' and
> print a warning?

No, that would violate the `round up' policy.

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: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Olaf Hering]

On Mon, Oct 02, Geert Uytterhoeven wrote:

> On Sun, 1 Oct 2000, Olaf Hering wrote:
> > while we are about to improve the atyfb, is it possible to fix the color
> > depth switching?
> > When I boot without a kernel arg I end up with 8 bit at console. I can't
> > increase the color depth afterwards with fbset, and mol crashes when it
> > tries to do that. When I specify atyfb:cmode:24 everythings works fine
> > and I can switch down to 8 and back to 24 and mol starts fine.
>
> Does it also crash when you increase the color depth with fbset?

I only have access to the wallstreet right now, and I can not increase
the depth here.
But it seems to work fine on a beige G3:

pineapple:~ # fbset

mode "1024x768-90"
    # D: 99.830 MHz, H: 76.090 kHz, V: 90.048 Hz
    geometry 1024 768 1024 768 8
    timings 10017 192 0 41 21 96 15
    rgba 8/0,8/0,8/0,0/0
endmode

pineapple:~ # fbset -depth 16
pineapple:~ # fbset -depth 15
pineapple:~ # cat /proc/cmdline
root=/dev/fd0 load_ramdisk=1 ramdisk_size=64000
pineapple:~ # lspci -n
00:00.0 Class 0600: 1057:0002 (rev 40)
00:0e.0 Class 0200: 1011:0019 (rev 41)
00:10.0 Class ff00: 106b:0010 (rev 01)
00:12.0 Class 0300: 1002:4754 (rev 9a)
pineapple:~ #


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[William Blew]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1000 bytes --]

Just to give you another testing point, I tried your patch on my beige
G3/266 workstation (rev 2 with the 3D rage pro). My setup is the latest
(as of 1 hour ago) pmac-stable rsync (says its 2.2.17) launched via BootX,
from the MacOS 9.0.4

I started the console with atyfb, mode 17, color 32. The FBDev X server
(v3.3.6-11.2) started fine, with the latest utah-glx (pseudo DMA as real
DMA is still broken in utah-glx) also working well. Checking utah-glx is
useful as it accesses the MMIO mapped registers (particularly the 3D
engine's registers) as returned by /dev/fb0's fixed screen info IOCTL.

As the X server's mode is 1280x1024-61 (at 15 bpp) and the console was
running 1024x768-75 (at 32 bpp) this included a color depth mode switch.

Anyway, the conclusion: it didn't break my (utterly normal except for
utah-glx) setup.

FYI, my lspci -vv output is attached.

PS: I second the motion on the fixing of atyfb's depth switching.
--
William Blew, wblew@home.com
Gamer by Choice, Geek by Birth

[-- Attachment #2: the lspci -vv output --]
[-- Type: TEXT/PLAIN, Size: 1184 bytes --]

00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 40)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0 set, cache line size 08

00:10.0 Class ff00: Apple Computer Inc. Heathrow Mac I/O (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 set, cache line size 08
	Region 0: Memory at f3000000 (32-bit, non-prefetchable)

00:12.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) (prog-if 00 [VGA])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 min, 32 set, cache line size 08
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at 81000000 (32-bit, non-prefetchable)
	Region 1: I/O ports at 0c00 [disabled]
	Region 2: Memory at 80800000 (32-bit, non-prefetchable)

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[R Shapiro]

Michael Schmitz writes:
 > While I still think having a userland PCI resource fixup tool would be
 > nice (at least for debugging purpose) I also promised to come up with a
 > sanitized version of the atyfb resource fixup patch. Here it is, please
 > test it (especially Jon, and R. Shapiro) and tell me if it works.


I patched a kernel.org 2.2.17 kernel, it made no difference in the
behavior.  The fbdev driver works ok, the ati driver crashes linux.


--
rshapiro@bbn.com


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

Re: Patch: PCI resource fixup for atyfb (was: Re: xf 4.0.1 + ati driver with rage II/rage pro)

[Michael Schmitz]

>  > While I still think having a userland PCI resource fixup tool would be
>  > nice (at least for debugging purpose) I also promised to come up with a
>  > sanitized version of the atyfb resource fixup patch. Here it is, please
>  > test it (especially Jon, and R. Shapiro) and tell me if it works.
>
>
> I patched a kernel.org 2.2.17 kernel, it made no difference in the
> behavior.  The fbdev driver works ok, the ati driver crashes linux.

I'm not amused (though not exactly surprised: I said the PCI config looked
sane already on your box).

Just for the record: did you ever try the 2.2.17 source from BenH?

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michael Schmitz writes:
 > That's not fixable at the X level (well, technically it is but I can't
 > figure out how and the X people refuse to consider that method). You will
 > need to boot via OF and yaboot (or equivalent oldworld) directly, not via
 > BootX to avoid the PCI resource conflict.


I just spent an hour on this.  Sorry guys, but I can't get linux to
quik-boot off the ide drive and yaboot doesn't work on this platform.
It's either BootX or miBoot.




--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michael Schmitz]

>  > That's not fixable at the X level (well, technically it is but I can't
>
> I just spent an hour on this.  Sorry guys, but I can't get linux to
> quik-boot off the ide drive and yaboot doesn't work on this platform.
> It's either BootX or miBoot.

Ok already, I'm working on it.

	Michael


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

R Shapiro wrote:
>
> Michel Dänzer writes:
>  > Mr Shapiro, please test if this makes the ati driver work in your
>  > triple-head box.
>
> No luck.
>
> Booting with BootX, the ati driver still hoses linux when X starts.  I
> can send you (or post) the log.  Worse, using the new fbdev driver
> itself produces a confused display on the 2nd and 3rd monitor, with
> images appearing multiple times.

Oh no :( Can you please describe the corruptness more?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[R Shapiro]

Michel Dänzer writes:
 > Oh no :( Can you please describe the corruptness more?

I'm sure there's a technical term for it but I'm afraid I don't know
what it is.  The main monitor is ok, but on the other two, whatever
gets drawn (the mouse cursor, say, or a popup menu, appears where it
should, and then again a little left and down, and then again a little
more left and down, etc etc.

Does that make sense?  Fwiw the main monitor is Rage II, while the
other two are Rage Pro.

--
rshapiro@bbn.com


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

Re: xf 4.0.1 + ati driver with rage II/rage pro

[Michel Dänzer]

R Shapiro wrote:
>
> Michel Dänzer writes:
>  > Mr Shapiro, please test if this makes the ati driver work in your
>  > triple-head box.
>
> No luck.
>
> Booting with BootX, the ati driver still hoses linux when X starts.  I
> can send you (or post) the log.  Worse, using the new fbdev driver
> itself produces a confused display on the 2nd and 3rd monitor, with
> images appearing multiple times.

I've got something new to try:

http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2
http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.diff

Don't expect it to fix your problems, but one never knows... And if it still
doesn't work, please send me the logs privately.


And I'd be really interested to hear from the people with weird hardware if
this works for them.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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