Re: LongTrail PCI resource assignment

--- Geert Uytterhoeven <geert@linux-m68k.org> wrote:

Bug in X: the big endian frame buffer is at base + 0x800000.

It doesn't know about the meaning behind the regions.

Besides, why does X need this? If it uses fbdev, all it should notice is
that the reported fix.smem_start lies within the 16 MB for this PCI device,
so it should not touch that PCI directly, only through the fbdev API
(ioctl+mmap).

You should discuss that on the X-devel list, in particular with Egbert Eich
(and Jeff Garzik, and ... :).


Michel


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

quoted

Bug in X: the big endian frame buffer is at base + 0x800000.

It doesn't know about the meaning behind the regions.

And X uses the base address and offset returned by fb_mmap anyway. The
whole probing of PCI resources is completely pointless for the framebuffer
driver. That's what the kernel framebuffer code is for IMHO (and I think
Geert will agree on that).

quoted

Besides, why does X need this? If it uses fbdev, all it should notice is
that the reported fix.smem_start lies within the 16 MB for this PCI device,
so it should not touch that PCI directly, only through the fbdev API
(ioctl+mmap).

You should discuss that on the X-devel list, in particular with Egbert Eich
(and Jeff Garzik, and ... :).

I'd like to reach a point where I understand what's happening in the
XFree PCI code before getting into that sort of discussion. And the X
source is way too convoluted for me to achieve that right now.

I'll stick to pre-4.0 XFree rather.

	Michael


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

On Fri, Mar 24, 2000, Michael Schmitz
[off-list ref] wrote:

I'd like to reach a point where I understand what's happening in the
XFree PCI code before getting into that sort of discussion. And the X
source is way too convoluted for me to achieve that right now.

I'll stick to pre-4.0 XFree rather.

I spent some time discussion with Egbert. The result is basically that in
order to support all archs, bogus BIOS, legacy cards, softbooting, etc...
XF must take over the PCI the way it does it. There are lots of reasons
for that, I could try to summarize them if you really want the gory
details, I beleive Egbert is bored of repeating himself all the time ;)

I suggested making that optional (and relying, for example, only on fbdev
or disabling the re-assignement when the appropriate option is set in
XF86Config), but Egbert thinks that would be a support nightmare with
users playing with the config options.

He agrees that things are not perfect, especially since the way we handle
PIO and iobase is bogus (see other discussions about this). Also, the
current remapping scheme can make the kernel (and fbdev) quite confused
with new hot-swap PCI, Cardbus, etc... He plans to rework the PCI
interface of XFree so that better cooperation with the kernel can be
implemented. On another hand, I think _we_ should find a definitive
solution for the PIO problem before he can begin adapting XFree. There
are lots of changes to be done to legacy drivers (VGA) to make them grok
a notion of iobase (since iobase can be different per-device, it can't be
handled inside inb/outb and friends).

Note that XF will always have to disable IO response on VGA cards when
more than one card is present in the machine since that's the only way to
prevent 2 VGA cards from trying to hard-decode legacy VGA addresses at
the same time. We need to find a way to make the kernel (and the fbdev)
aware of what's going on.

No time do give more details now, tell me if you need more precisions on
one of these specific points.

Ben.


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

quoted

I'd like to reach a point where I understand what's happening in the
XFree PCI code before getting into that sort of discussion. And the X
source is way too convoluted for me to achieve that right now.

I'll stick to pre-4.0 XFree rather.

I spent some time discussion with Egbert. The result is basically that in
order to support all archs, bogus BIOS, legacy cards, softbooting, etc...
XF must take over the PCI the way it does it. There are lots of reasons
for that, I could try to summarize them if you really want the gory
details, I beleive Egbert is bored of repeating himself all the time ;)

Nah, I take this to mean we better fix our PCI resource conflicts in the
kernel if at all possible. But as I see everybody juggle with PCI resource
and hot swap options only available in 2.3 the XFree people should plaster
a big fat warning 'will not work with 2.2 kernels on some PPC hardware' on
their release notes.
'Resource conflict' isn't even strictly true, the PIO resource on the Rage
Pro is disabled (so we'd probably better use the MMIO range), and MMIO is
a subrange of the full aperture. It's not violating anything as far as I
can see.

I suggested making that optional (and relying, for example, only on fbdev
or disabling the re-assignement when the appropriate option is set in
XF86Config), but Egbert thinks that would be a support nightmare with
users playing with the config options.

I sometimes wonder - the FBDev X server used to be a painless thing: the
kernel frame buffer driver would handle the gory details and X would use a
simplified, maybe slow but stable interface. X used to deal with that
fine. Suddenly the kernel isn't to be trusted to correctly set up things
anymore, and we're back to square one in terms of X stability. How did
that happen?

He agrees that things are not perfect, especially since the way we handle
PIO and iobase is bogus (see other discussions about this). Also, the
current remapping scheme can make the kernel (and fbdev) quite confused
with new hot-swap PCI, Cardbus, etc... He plans to rework the PCI
interface of XFree so that better cooperation with the kernel can be

I'd be glad if the X PCI code would recognize the same facts as reported
via the kernel /proc/bus/pci interface, and 1) leave disabled regions
alone and not bitch about them, 2) tolerate one region being fully
contained inside another if it's on the same card. But it sure is easier
to work around X.

implemented. On another hand, I think _we_ should find a definitive
solution for the PIO problem before he can begin adapting XFree. There
are lots of changes to be done to legacy drivers (VGA) to make them grok
a notion of iobase (since iobase can be different per-device, it can't be
handled inside inb/outb and friends).

Can't the PIO registers be accessed via the MMIO aperture? Either way,
with non accelerated framebuffer drivers there's no need to ever use VGA
registers. And there's no fbdev driver for stupid VGA cards (yuck). It's a
non issue from my point of view.

Note that XF will always have to disable IO response on VGA cards when
more than one card is present in the machine since that's the only way to
prevent 2 VGA cards from trying to hard-decode legacy VGA addresses at
the same time. We need to find a way to make the kernel (and the fbdev)
aware of what's going on.

X is free to disable whatever it likes on cards that aren't handled by
framebuffer drivers. It should not disable anything otherwise and leave it
to the kernel framebuffer drivers to sort things out. More communication
between X and kernel is fine, but why not leave things as they were for
framebuffer drivers? This is all that the framebuffer concept was about,
why throw it out?
You probably have had all these discussions with the X team already and
there's nothing of substance I could add, presumably. It does sound like
the old framebuffer driver concept is dead for good so we need to find
other ways.

No time do give more details now, tell me if you need more precisions on
one of these specific points.

I'd just need specifics on how to fudge the ATI PCI resources from kernel
space. I'll take cues from the 2.3 resource handling code and hope to not
blow up my system too badly.

	Michael


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

On Fri, 24 Mar 2000, Michael Schmitz wrote:

quoted

I spent some time discussion with Egbert. The result is basically that in
order to support all archs, bogus BIOS, legacy cards, softbooting, etc...
XF must take over the PCI the way it does it. There are lots of reasons
for that, I could try to summarize them if you really want the gory
details, I beleive Egbert is bored of repeating himself all the time ;)

Nah, I take this to mean we better fix our PCI resource conflicts in the
kernel if at all possible. But as I see everybody juggle with PCI resource

Yes, they should be fixed in the kernel's pcibios_* routines.

quoted

I suggested making that optional (and relying, for example, only on fbdev
or disabling the re-assignement when the appropriate option is set in
XF86Config), but Egbert thinks that would be a support nightmare with
users playing with the config options.

I sometimes wonder - the FBDev X server used to be a painless thing: the
kernel frame buffer driver would handle the gory details and X would use a
simplified, maybe slow but stable interface. X used to deal with that
fine. Suddenly the kernel isn't to be trusted to correctly set up things
anymore, and we're back to square one in terms of X stability. How did
that happen?

Because they insist on playing with PCI theirselves. And partly because of
multi-head (what if you have 2 cards, and you have a fbdev for only one of
them?). But the solution is quite simple: XFree86 should not touch PCI devices
that have a fbdev attached, and it can easily find out using fix.smem_start.

Can't the PIO registers be accessed via the MMIO aperture? Either way,
with non accelerated framebuffer drivers there's no need to ever use VGA
registers. And there's no fbdev driver for stupid VGA cards (yuck). It's a
non issue from my point of view.

Yes we have: vga16fb.

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/

Michael Schmitz wrote:

quoted

I spent some time discussion with Egbert. The result is basically that in
order to support all archs, bogus BIOS, legacy cards, softbooting, etc...
XF must take over the PCI the way it does it. There are lots of reasons
for that, I could try to summarize them if you really want the gory
details, I beleive Egbert is bored of repeating himself all the time ;)

Nah, I take this to mean we better fix our PCI resource conflicts in the
kernel if at all possible. But as I see everybody juggle with PCI resource
and hot swap options only available in 2.3 the XFree people should plaster
a big fat warning 'will not work with 2.2 kernels on some PPC hardware' on
their release notes.

You are thinking Linux centric IMHO. XFree86 runs on a variety of OSs. AFAIK
the X PCI code we're talking about is OS independent.

I sometimes wonder - the FBDev X server used to be a painless thing: the
kernel frame buffer driver would handle the gory details and X would use a
simplified, maybe slow but stable interface. X used to deal with that
fine. Suddenly the kernel isn't to be trusted to correctly set up things
anymore, and we're back to square one in terms of X stability. How did
that happen?

The _big_ difference is that _the FBDev_ server was responsible for fbdev only
(I imagine it didn't have to care about PCI stuff at all), while there is only
one server for all drivers now, and it has to deal with several drivers
working on the same machine.

I'd be glad if the X PCI code would recognize the same facts as reported
via the kernel /proc/bus/pci interface, and 1) leave disabled regions
alone and not bitch about them, 2) tolerate one region being fully
contained inside another if it's on the same card. But it sure is easier
to work around X.

It sure is easy to complain about something and not try to enhance it.

X is free to disable whatever it likes on cards that aren't handled by
framebuffer drivers. It should not disable anything otherwise and leave it
to the kernel framebuffer drivers to sort things out. More communication
between X and kernel is fine, but why not leave things as they were for
framebuffer drivers? This is all that the framebuffer concept was about,
why throw it out?

Because X can currently only determine what is controlled by an fbdev via
heuristics regarding the memory regions themselves. (With 32 bit busses on 64
bit machines it may even be impossible). Jeff Garzik has proposed a solution
for this with a new ioctl.


Michel


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

On Sat, 25 Mar 2000, Michel Dänzer wrote:

quoted

X is free to disable whatever it likes on cards that aren't handled by
framebuffer drivers. It should not disable anything otherwise and leave it
to the kernel framebuffer drivers to sort things out. More communication
between X and kernel is fine, but why not leave things as they were for
framebuffer drivers? This is all that the framebuffer concept was about,
why throw it out?

Because X can currently only determine what is controlled by an fbdev via
heuristics regarding the memory regions themselves. (With 32 bit busses on 64
bit machines it may even be impossible). Jeff Garzik has proposed a solution
for this with a new ioctl.

fix.smem_start is unsigned long, which is 64-bit on all 64-bit platforms.

Please tell me where you're hiding that 32-bit box with 64-bit PCI addressing
inside :-)

Anyway, it's perfectly possible to do it correctly _now_ on 32-bit boxes with
32-bit PCI addressing and on all 64-bit boxes, so I see no reason for breaking
the game for those.

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/

quoted

Nah, I take this to mean we better fix our PCI resource conflicts in the
kernel if at all possible. But as I see everybody juggle with PCI resource
and hot swap options only available in 2.3 the XFree people should plaster
a big fat warning 'will not work with 2.2 kernels on some PPC hardware' on
their release notes.

You are thinking Linux centric IMHO. XFree86 runs on a variety of OSs. AFAIK
the X PCI code we're talking about is OS independent.

It is OS independent. And I concede my point of view is Linux centric
(which may be excused as I haven't seen XFree on anything beside Linux
yet). The problem is with the PCI setup by OF or MacOS, and can probably
be fixed in the kernel, that's what I'll try next.

Anyway, as things are now, XFree 4.0 not working on Lombard Powerbooks
seems a safe bet, and XFree 4.0 not working on other Powermac models with
the same Mach64 chipset seems likely.

quoted

fine. Suddenly the kernel isn't to be trusted to correctly set up things
anymore, and we're back to square one in terms of X stability. How did
that happen?

The _big_ difference is that _the FBDev_ server was responsible for fbdev only
(I imagine it didn't have to care about PCI stuff at all), while there is only
one server for all drivers now, and it has to deal with several drivers
working on the same machine.

I've seen a device option "UseFBDev" in XF86Config. I take that to mean
XFree knows a particular device (even with it's BusID specified) is going
to be handled by a framebuffer driver. Assuming the framebuffer driver
makes sure no PCI access conflicts with _other_ hardware happen, I see no
problem with XFree managing all the other drivers but considering the
framebuffer driven devices off limits in terms of PCI fixup.

quoted

I'd be glad if the X PCI code would recognize the same facts as reported
via the kernel /proc/bus/pci interface, and 1) leave disabled regions
alone and not bitch about them, 2) tolerate one region being fully
contained inside another if it's on the same card. But it sure is easier
to work around X.

It sure is easy to complain about something and not try to enhance it.

I've been banging my head over the X PCI code more hours already than I
would like. Not counting debugging where exactly X crashes the
kernel. I just don't get it. Color me clueless on X server workings, or
PCI in general. Enhancing the X PCI code sure is beyond me. Thanks for
listening anyways.

quoted

between X and kernel is fine, but why not leave things as they were for
framebuffer drivers? This is all that the framebuffer concept was about,
why throw it out?

Because X can currently only determine what is controlled by an fbdev via
heuristics regarding the memory regions themselves. (With 32 bit busses on 64
bit machines it may even be impossible). Jeff Garzik has proposed a solution
for this with a new ioctl.

I though X could take a hint from the Device section in the config file?

Section "Device"
    Identifier  "ATY Mach64"
    Driver      "fbdev"
    Option	"no accel"
    Option	"UseFBDev"
    BusID	"PCI:0:17:0"

... seems to say enough. That's not an autoprobed config though;
autoprobing won't be possible to guess a device will use a framebuffer
driver anyway, or will it?

	Michael


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

Geert Uytterhoeven wrote:

fix.smem_start is unsigned long, which is 64-bit on all 64-bit platforms.

Please tell me where you're hiding that 32-bit box with 64-bit PCI
addressing inside :-)

Anyway, it's perfectly possible to do it correctly _now_ on 32-bit boxes
with 32-bit PCI addressing and on all 64-bit boxes, so I see no reason for
breaking the game for those.

I shouldn't have opened my mouth about something I don't really know about,
I'll just cite Jeff from a linux-fbdev post:

The server obtains a list of hardware from scanning the PCI bus.  It
needs to know which devices are attached to framebuffer devices, and
which are not, in order to know whether to use a bit-banging interface
or an fbdev interface.

Currently the only way to do this is a hueristic which takes
fix.smem_start and determines in which PCI BAR the address falls.  This
is insufficient for 64-bit machines, and also generally ugly :)

In another post he was talking about the problem being 32 bit PCI busses on 64
bit machines.


Michel


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

Michael Schmitz wrote:

Anyway, as things are now, XFree 4.0 not working on Lombard Powerbooks
seems a safe bet, and XFree 4.0 not working on other Powermac models with
the same Mach64 chipset seems likely.

Due to buggy OF and/or Linux kernels.

quoted

quoted

fine. Suddenly the kernel isn't to be trusted to correctly set up things
anymore, and we're back to square one in terms of X stability. How did
that happen?

The _big_ difference is that _the FBDev_ server was responsible for fbdev > > only (I imagine it didn't have to care about PCI stuff at all), while
there is only one server for all drivers now, and it has to deal with
several drivers working on the same machine.

I've seen a device option "UseFBDev" in XF86Config. I take that to mean
XFree knows a particular device (even with it's BusID specified) is going
to be handled by a framebuffer driver.

No. The option is in the Device Section and thus driver-dependant. It just
tells the driver to use fbdev for mode setting/switching etc. instead of
banging the hardware directly. The option can be there but not the fbdev, the
driver should then just fall back to banging.

And only a few drivers (glint, r128, nv, mga, ???) currently support that
option.

Assuming the framebuffer driver makes sure no PCI access conflicts with
_other_ hardware happen, I see no problem with XFree managing all the other
drivers but considering the framebuffer driven devices off limits in terms
of PCI fixup.

Yes, once X has a safe way of telling what is controlled by an fbdev that
should be no problem.

quoted

quoted

I'd be glad if the X PCI code would recognize the same facts as reported
via the kernel /proc/bus/pci interface, and 1) leave disabled regions
alone and not bitch about them, 2) tolerate one region being fully
contained inside another if it's on the same card. But it sure is easier
to work around X.

It sure is easy to complain about something and not try to enhance it.

I've been banging my head over the X PCI code more hours already than I
would like. Not counting debugging where exactly X crashes the
kernel. I just don't get it. Color me clueless on X server workings, or
PCI in general. Enhancing the X PCI code sure is beyond me. Thanks for
listening anyways.

If you can't fix/work around it yourself, you could post your ideas to
devel@XFree86.Org (state clearly that you're not on the list as the reply-to
is set to it) and in particular to Egbert Eich
[off-list ref]

Nothing will ever happen if you're complaining about X on linuxppc-dev.


Michel


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

quoted

I've seen a device option "UseFBDev" in XF86Config. I take that to mean
XFree knows a particular device (even with it's BusID specified) is going
to be handled by a framebuffer driver.

No. The option is in the Device Section and thus driver-dependant. It just
tells the driver to use fbdev for mode setting/switching etc. instead of
banging the hardware directly. The option can be there but not the fbdev, the
driver should then just fall back to banging.

OK, that explains this option. I've looked for a XConfig man page in the
source without success, and I have a few more

If you can't fix/work around it yourself, you could post your ideas to
devel@XFree86.Org (state clearly that you're not on the list as the reply-to
is set to it) and in particular to Egbert Eich
[off-list ref]

The PCI stuff is sorted by Geert's PCI patch. I'll post a fix for 2.2.15
shortly. The remaining trouble is with 16 and 32 bpp support which may be
a problem with atyfb as well. If it's a X problem the xfree people will
hear about it.

Nothing will ever happen if you're complaining about X on linuxppc-dev.

Well, as you will have noticed, various people here helped pushing me in
the right direction (fixing the PCI conflicts in the kernel). I doubt the
xfree list would have been the place to ask PPC kernel questions.

	Michael


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

Michael Schmitz wrote:

quoted

quoted

I've seen a device option "UseFBDev" in XF86Config. I take that to mean
XFree knows a particular device (even with it's BusID specified) is
going to be handled by a framebuffer driver.

No. The option is in the Device Section and thus driver-dependant. It just
tells the driver to use fbdev for mode setting/switching etc. instead of
banging the hardware directly. The option can be there but not the fbdev, > > the driver should then just fall back to banging.

OK, that explains this option. I've looked for a XConfig man page in the
source without success, and I have a few more

Documentation is somewhat lacking yet in 4.0 ... I'm glad to answer whatever I
can.

quoted

Nothing will ever happen if you're complaining about X on linuxppc-dev.

Well, as you will have noticed, various people here helped pushing me in
the right direction (fixing the PCI conflicts in the kernel). I doubt the
xfree list would have been the place to ask PPC kernel questions.

Of course not. But you were talking about shortcomings in X, which probably
wouldn't get fixed if they were reported only here.


Michel


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