Re: LongTrail PCI resource assignment

Re: LongTrail PCI resource assignment

[Michel D?nzer]

--- 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/

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > 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).

> > 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/

Re: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Fri, Mar 24, 2000, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> 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/

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> >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/

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Michael Schmitz wrote:
> > 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.

> > 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/

Re: LongTrail PCI resource assignment

[Michel Dänzer]

Michael Schmitz wrote:

> > 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/

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Sat, 25 Mar 2000, Michel Dänzer wrote:
> > 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/

Re: LongTrail PCI resource assignment

[Michel Dänzer]

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/

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > 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.

> > 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.

> > 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.

> > 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/

Re: LongTrail PCI resource assignment

[Michel Dänzer]

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.


> > > 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.


> > > 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
<eich@hilbert.ikp.physik.tu-darmstadt.de>

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/

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > 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
> <eich@hilbert.ikp.physik.tu-darmstadt.de>

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/

Re: LongTrail PCI resource assignment

[Michel Dänzer]

Michael Schmitz wrote:
>
> > > 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.


> > 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/

Re: LongTrail PCI resource assignment

[Martin Mares]

Hi!

>   - There are machine dependent things related to PCI resource assignment,
>     namely PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM in include/asm-ppc/pci.h. On the
>     LongTrail, PCI memory space is from 0xc0000000 until 0xf7000000, so I had
>     to change PCIBIOS_MIN_MEM to make sure allocation starts at 0xc0000000. I
>     think we need
>
> 	#define PCIBIOS_MIN_IO	ppc_md.pcibios_min_io
> 	#define PCIBIOS_MIN_MEM	ppc_md.pcibios_min_mem
>
>     and solve this in the machine specific setup code.
>
>     Martin, do you think it makes sense to have PCIBIOS_MAX_IO and
>     PCIBIOS_MAX_MEM to pass to allocate_resource() as the upper limits?

   Better define resources for the root bus itself and let resources of the
other devices to be allocated from these root resources.

   Also, for the PPC you probably don't need all the multipass resource magic
we do on the PC.

				Have a nice fortnight
--
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Whoa...I did a 'cp /vmlinuz /dev/audio' and I think I heard God..."

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

LongTrail PCI resource assignment

[Geert Uytterhoeven]

	Hi,

I added code to do automatic PCI resource assignment for unassigned resources
on my CHRP LongTrail. This is experimental, of course.

The code is heavily based on the ia32 code that checks for unassigned and
overlapping resources. In fact the only difference is that I also check for

    if (r->end == 0xffffffff) {     /* Unassigned */
	DBG("PCI: Resource %08lx-%08lx was unassigned\n", r->start, r->end);
	r->end -= r->start;
	r->start = 0;
	continue;
    }

in pcibios_allocate_resources() to catch the unassigned regions that show up in
high memory on my box (e.g. an unassigned 4 KB region shows up as occupying
0xfffff000-0xffffffff). It looks like OF did write 0xffffffff to the PCI
base address registers during the probe phase, but didn't bother to do anything
with the returned size mask.

Now the kernel assigns a valid memory resource for my S3 Trio64V+ and for the
secondary MMIO aperture of my ATI RAGE II+. It doesn't assign valid I/O
resources for the Winbond IDE yet, but I guess I just have to remove the test
for PCI_CLASS_STORAGE_IDE in pcibios_assign_resources() (on PC you must not
mess with the IDE interface, on PPC you probably have to).


Notes:

  - There are machine dependent things related to PCI resource assignment,
    namely PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM in include/asm-ppc/pci.h. On the
    LongTrail, PCI memory space is from 0xc0000000 until 0xf7000000, so I had
    to change PCIBIOS_MIN_MEM to make sure allocation starts at 0xc0000000. I
    think we need

	#define PCIBIOS_MIN_IO	ppc_md.pcibios_min_io
	#define PCIBIOS_MIN_MEM	ppc_md.pcibios_min_mem

    and solve this in the machine specific setup code.

    Martin, do you think it makes sense to have PCIBIOS_MAX_IO and
    PCIBIOS_MAX_MEM to pass to allocate_resource() as the upper limits?

  - Instead of testing for r->end == 0xffffffff, I think I can also lower
    iomem_resource.end (which is currently 0xffffffff), so the allocation of
    resources at the top of memory space fails and they will be reassigned.
    But then I can no longer allocate a resource for the ROM at
    0xfff80000-0xffffffff if I ever would want to do that.

  - Since the secondary MMIO aperture of Mach64 chips seems to overlap with the
    primary aperture on PowerMac, you may want to try this on PowerMac as well.
    Make sure to change the machine specific things (notable PCIBIOS_MIN_MEM)!

  - If you want to reassign all resources, you can just call

	pci_assign_unassigned_resources();
	pci_set_bus_ranges();

    (don't know what the second call really does, just copied it from the
    Alpha and it seems to work fine on my MIPS board at work as well) in
    pcibios_init() instead of the current calls to pcibios_*() functions there.
    You do not want to do this on a PowerMac or CHRP box, though, since it will
    make sure the OF device tree is no longer in sync with the PCI resource
    assignments. But it could be an alternative to Gabriel's bootloader on PReP
    boxes (under the motto: keep as much code shared in the kernel :-).

  - The code in pci_debug.c is just there for dumping all PCI buses, devices
    and resources. You activate it by doing `cat proc/pci' and looking in the
    kernel messages. The patch also enables all PCI debug code, since this is
    probably what you want when playing with PCI resource assignment :-)

Good luck!


===== arch/ppc/kernel/Makefile 1.14 vs edited =====
--- 1.14/arch/ppc/kernel/Makefile	Tue Mar  7 03:01:53 2000
+++ edited/arch/ppc/kernel/Makefile	Tue Mar 21 17:47:32 2000
@@ -38,7 +38,7 @@
 endif

 ifdef CONFIG_PCI
-O_OBJS += pci.o pci-dma.o
+O_OBJS += pci.o pci-dma.o pci_debug.o
 endif

 ifdef CONFIG_KGDB
===== arch/ppc/kernel/pci.c 1.13 vs edited =====
--- 1.13/arch/ppc/kernel/pci.c	Tue Mar  7 03:01:54 2000
+++ edited/arch/ppc/kernel/pci.c	Tue Mar 21 22:08:08 2000
@@ -22,6 +22,15 @@

 #include "pci.h"

+#define DEBUG
+
+#ifdef DEBUG
+#define DBG(x...) printk(x)
+#else
+#define DBG(x...)
+#endif
+
+
 static void __init pcibios_claim_resources(struct list_head *);

 unsigned long isa_io_base     = 0;
@@ -67,13 +76,271 @@
 	generic_pcibios_write_dword
 };

+
+
+#define PCI_PROBE_BIOS 1
+#define PCI_PROBE_CONF1 2
+#define PCI_PROBE_CONF2 4
+#define PCI_NO_SORT 0x100
+#define PCI_BIOS_SORT 0x200
+#define PCI_NO_CHECKS 0x400
+#define PCI_PEER_FIXUP 0x800
+#define PCI_ASSIGN_ROMS 0x1000
+#define PCI_BIOS_IRQ_SCAN 0x2000
+
+unsigned int pci_probe;
+
+
+void pcibios_update_resource(struct pci_dev *dev, struct resource *root,
+			     struct resource *res, int resource)
+{
+	u32 new, check;
+	int reg;
+
+	new = res->start | (res->flags & PCI_REGION_FLAG_MASK);
+	if (resource < 6) {
+		reg = PCI_BASE_ADDRESS_0 + 4*resource;
+	} else if (resource == PCI_ROM_RESOURCE) {
+		res->flags |= PCI_ROM_ADDRESS_ENABLE;
+		reg = dev->rom_base_reg;
+	} else {
+		/* Somebody might have asked allocation of a non-standard resource */
+		return;
+	}
+
+	pci_write_config_dword(dev, reg, new);
+	pci_read_config_dword(dev, reg, &check);
+	if ((new ^ check) & ((new & PCI_BASE_ADDRESS_SPACE_IO) ? PCI_BASE_ADDRESS_IO_MASK : PCI_BASE_ADDRESS_MEM_MASK)) {
+		printk(KERN_ERR "PCI: Error while updating region "
+		       "%s/%d (%08x != %08x)\n", dev->slot_name, resource,
+		       new, check);
+	}
+}
+
+void
+pcibios_align_resource(void *data, struct resource *res, unsigned long size)
+{
+	struct pci_dev *dev = data;
+
+	if (res->flags & IORESOURCE_IO) {
+		unsigned long start = res->start;
+
+		/* We need to avoid collisions with `mirrored' VGA ports
+		   and other strange ISA hardware, so we always want the
+		   addresses kilobyte aligned.  */
+		if (size > 0x100) {
+			printk(KERN_ERR "PCI: I/O Region %s/%d too large"
+			       " (%ld bytes)\n", dev->slot_name,
+			       dev->resource - res, size);
+		}
+
+		start = (start + 1024 - 1) & ~(1024 - 1);
+		res->start = start;
+	}
+}
+
+
+/*
+ *  Handle resources of PCI devices.  If the world were perfect, we could
+ *  just allocate all the resource regions and do nothing more.  It isn't.
+ *  On the other hand, we cannot just re-allocate all devices, as it would
+ *  require us to know lots of host bridge internals.  So we attempt to
+ *  keep as much of the original configuration as possible, but tweak it
+ *  when it's found to be wrong.
+ *
+ *  Known BIOS problems we have to work around:
+ *	- I/O or memory regions not configured
+ *	- regions configured, but not enabled in the command register
+ *	- bogus I/O addresses above 64K used
+ *	- expansion ROMs left enabled (this may sound harmless, but given
+ *	  the fact the PCI specs explicitly allow address decoders to be
+ *	  shared between expansion ROMs and other resource regions, it's
+ *	  at least dangerous)
+ *
+ *  Our solution:
+ *	(1) Allocate resources for all buses behind PCI-to-PCI bridges.
+ *	    This gives us fixed barriers on where we can allocate.
+ *	(2) Allocate resources for all enabled devices.  If there is
+ *	    a collision, just mark the resource as unallocated. Also
+ *	    disable expansion ROMs during this step.
+ *	(3) Try to allocate resources for disabled devices.  If the
+ *	    resources were assigned correctly, everything goes well,
+ *	    if they weren't, they won't disturb allocation of other
+ *	    resources.
+ *	(4) Assign new addresses to resources which were either
+ *	    not configured at all or misconfigured.  If explicitly
+ *	    requested by the user, configure expansion ROM address
+ *	    as well.
+ */
+
+static void __init pcibios_allocate_bus_resources(struct list_head *bus_list)
+{
+	struct list_head *ln;
+	struct pci_bus *bus;
+	struct pci_dev *dev;
+	int idx;
+	struct resource *r, *pr;
+
+	/* Depth-First Search on bus tree */
+	for (ln=bus_list->next; ln != bus_list; ln=ln->next) {
+		bus = pci_bus_b(ln);
+		if ((dev = bus->self)) {
+			for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
+				r = &dev->resource[idx];
+				if (!r->start)
+					continue;
+				pr = pci_find_parent_resource(dev, r);
+				if (!pr || request_resource(pr, r) < 0)
+					printk(KERN_ERR "PCI: Cannot allocate resource region %d of bridge %s\n", idx, dev->slot_name);
+			}
+		}
+		pcibios_allocate_bus_resources(&bus->children);
+	}
+}
+
+static void __init pcibios_allocate_resources(int pass)
+{
+	struct pci_dev *dev;
+	int idx, disabled;
+	u16 command;
+	struct resource *r, *pr;
+
+	pci_for_each_dev(dev) {
+		pci_read_config_word(dev, PCI_COMMAND, &command);
+		for(idx = 0; idx < 6; idx++) {
+			r = &dev->resource[idx];
+			if (r->parent)		/* Already allocated */
+				continue;
+			if (!r->start)		/* Address not assigned at all */
+				continue;
+			if (r->end == 0xffffffff) {	/* Unassigned */
+				DBG("PCI: Resource %08lx-%08lx was unassigned\n", r->start, r->end);
+				r->end -= r->start;
+				r->start = 0;
+				continue;
+			}
+
+			if (r->flags & IORESOURCE_IO)
+				disabled = !(command & PCI_COMMAND_IO);
+			else
+				disabled = !(command & PCI_COMMAND_MEMORY);
+			if (pass == disabled) {
+				DBG("PCI: Resource %08lx-%08lx (f=%lx, d=%d, p=%d)\n",
+				    r->start, r->end, r->flags, disabled, pass);
+				pr = pci_find_parent_resource(dev, r);
+				if (!pr || request_resource(pr, r) < 0) {
+					printk(KERN_ERR "PCI: Cannot allocate resource region %d of device %s\n", idx, dev->slot_name);
+					/* We'll assign a new address later */
+					r->start -= r->end;
+					r->start = 0;
+				}
+			}
+		}
+		if (!pass) {
+			r = &dev->resource[PCI_ROM_RESOURCE];
+			if (r->flags & PCI_ROM_ADDRESS_ENABLE) {
+				/* Turn the ROM off, leave the resource region, but keep it unregistered. */
+				u32 reg;
+				DBG("PCI: Switching off ROM of %s\n", dev->slot_name);
+				r->flags &= ~PCI_ROM_ADDRESS_ENABLE;
+				pci_read_config_dword(dev, dev->rom_base_reg, &reg);
+				pci_write_config_dword(dev, dev->rom_base_reg, reg & ~PCI_ROM_ADDRESS_ENABLE);
+			}
+		}
+	}
+}
+
+static void __init pcibios_assign_resources(void)
+{
+	struct pci_dev *dev;
+	int idx;
+	struct resource *r;
+
+	pci_for_each_dev(dev) {
+		int class = dev->class >> 8;
+
+		/* Don't touch classless devices and host bridges */
+		if (!class || class == PCI_CLASS_BRIDGE_HOST)
+			continue;
+
+		for(idx=0; idx<6; idx++) {
+			r = &dev->resource[idx];
+
+			/*
+			 *  Don't touch IDE controllers and I/O ports of video cards!
+			 */
+			if ((class == PCI_CLASS_STORAGE_IDE && idx < 4) ||
+			    (class == PCI_CLASS_DISPLAY_VGA && (r->flags & IORESOURCE_IO)))
+				continue;
+
+			/*
+			 *  We shall assign a new address to this resource, either because
+			 *  the BIOS forgot to do so or because we have decided the old
+			 *  address was unusable for some reason.
+			 */
+			if (!r->start && r->end)
+				pci_assign_resource(dev, idx);
+		}
+
+		if (pci_probe & PCI_ASSIGN_ROMS) {
+			r = &dev->resource[PCI_ROM_RESOURCE];
+			r->end -= r->start;
+			r->start = 0;
+			if (r->end)
+				pci_assign_resource(dev, PCI_ROM_RESOURCE);
+		}
+	}
+}
+
+
+int pcibios_enable_resources(struct pci_dev *dev)
+{
+	u16 cmd, old_cmd;
+	int idx;
+	struct resource *r;
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	old_cmd = cmd;
+	for(idx=0; idx<6; idx++) {
+		r = &dev->resource[idx];
+		if (!r->start && r->end) {
+			printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name);
+			return -EINVAL;
+		}
+		if (r->flags & IORESOURCE_IO)
+			cmd |= PCI_COMMAND_IO;
+		if (r->flags & IORESOURCE_MEM)
+			cmd |= PCI_COMMAND_MEMORY;
+	}
+	if (cmd != old_cmd) {
+		printk("PCI: Enabling device %s (%04x -> %04x)\n", dev->slot_name, old_cmd, cmd);
+		pci_write_config_word(dev, PCI_COMMAND, cmd);
+	}
+	return 0;
+}
+
+
+
 void __init pcibios_init(void)
 {
+#if 0
 	printk("PCI: Probing PCI hardware\n");
 	pci_scan_bus(0, &generic_pci_ops, NULL);
 	if (ppc_md.pcibios_fixup)
 		ppc_md.pcibios_fixup();
 	pcibios_claim_resources(&pci_root_buses);
+#else
+	printk("PCI: Probing PCI hardware (semiautomatic)\n");
+	pci_scan_bus(0, &generic_pci_ops, NULL);
+	if (ppc_md.pcibios_fixup)
+		ppc_md.pcibios_fixup();
+
+	pcibios_allocate_bus_resources(&pci_root_buses);
+	pcibios_allocate_resources(0);
+	pcibios_allocate_resources(1);
+	pcibios_assign_resources();
+#endif
+debug_scan_pci();
 }

 void __init
@@ -131,31 +398,12 @@
 	return str;
 }

-/* the next two are stolen from the alpha port... */
-void __init
-pcibios_update_resource(struct pci_dev *dev, struct resource *root,
-			struct resource *res, int resource)
-{
-        unsigned long where, size;
-        u32 reg;
-
-        where = PCI_BASE_ADDRESS_0 + (resource * 4);
-        size = res->end - res->start;
-        pci_read_config_dword(dev, where, &reg);
-        reg = (reg & size) | (((u32)(res->start - root->start)) & ~size);
-        pci_write_config_dword(dev, where, reg);
-}
-
+/* the next one is stolen from the alpha port... */
 void __init
 pcibios_update_irq(struct pci_dev *dev, int irq)
 {
 	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
 	/* XXX FIXME - update OF device tree node interrupt property */
-}
-
-void __init
-pcibios_align_resource(void *data, struct resource *res, unsigned long size)
-{
 }

 int pcibios_enable_device(struct pci_dev *dev)
===== drivers/pci/pci.c 1.16 vs edited =====
--- 1.16/drivers/pci/pci.c	Sat Mar 18 15:38:57 2000
+++ edited/drivers/pci/pci.c	Tue Mar 21 18:57:54 2000
@@ -22,7 +22,7 @@
 #include <asm/page.h>
 #include <asm/dma.h>	/* isa_dma_bridge_buggy */

-#undef DEBUG
+#define DEBUG

 #ifdef DEBUG
 #define DBG(x...) printk(x)
===== drivers/pci/setup-irq.c 1.1 vs edited =====
--- 1.1/drivers/pci/setup-irq.c	Thu Jan 13 04:40:58 2000
+++ edited/drivers/pci/setup-irq.c	Tue Mar 21 18:58:11 2000
@@ -18,7 +18,7 @@
 #include <linux/cache.h>


-#define DEBUG_CONFIG 0
+#define DEBUG_CONFIG 1
 #if DEBUG_CONFIG
 # define DBGC(args)     printk args
 #else
===== drivers/pci/setup-res.c 1.2 vs edited =====
--- 1.2/drivers/pci/setup-res.c	Thu Jan 13 23:46:31 2000
+++ edited/drivers/pci/setup-res.c	Tue Mar 21 18:58:16 2000
@@ -19,7 +19,7 @@
 #include <linux/cache.h>


-#define DEBUG_CONFIG 0
+#define DEBUG_CONFIG 1
 #if DEBUG_CONFIG
 # define DBGC(args)     printk args
 #else
===== drivers/pci/setup-bus.c 1.1 vs edited =====
--- 1.1/drivers/pci/setup-bus.c	Tue Jan 11 16:22:31 2000
+++ edited/drivers/pci/setup-bus.c	Tue Mar 21 18:58:08 2000
@@ -17,7 +17,7 @@
 #include <linux/cache.h>


-#define DEBUG_CONFIG 0
+#define DEBUG_CONFIG 1
 #if DEBUG_CONFIG
 # define DBGC(args)     printk args
 #else
===== drivers/pci/proc.c 1.5 vs edited =====
--- 1.5/drivers/pci/proc.c	Mon Feb 28 13:35:33 2000
+++ edited/drivers/pci/proc.c	Tue Mar 21 17:49:51 2000
@@ -385,6 +385,7 @@
 	int nprinted, len, begin = 0;
 	struct pci_dev *dev;

+debug_dump_pci();
 	len = sprintf(buf, "PCI devices found:\n");

 	*eof = 1;
===== drivers/pci/quirks.c 1.2 vs edited =====
--- 1.2/drivers/pci/quirks.c	Thu Mar  2 14:07:11 2000
+++ edited/drivers/pci/quirks.c	Tue Mar 21 18:58:03 2000
@@ -17,7 +17,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>

-#undef DEBUG
+#define DEBUG

 /* Deal with broken BIOS'es that neglect to enable passive release,
    which can cause problems in combination with the 82441FX/PPro MTRRs */
===== include/asm-ppc/pci.h 1.11 vs edited =====
--- 1.11/include/asm-ppc/pci.h	Sat Mar 18 23:16:43 2000
+++ edited/include/asm-ppc/pci.h	Tue Mar 21 18:57:04 2000
@@ -8,7 +8,7 @@
 #define pcibios_assign_all_busses()	0

 #define PCIBIOS_MIN_IO		0x1000
-#define PCIBIOS_MIN_MEM		0x10000000
+#define PCIBIOS_MIN_MEM		0xc0000000

 extern inline void pcibios_set_master(struct pci_dev *dev)
 {
--- /dev/null	Thu Aug  6 16:24:46 1998
+++ new/arch/ppc/kernel/pci_debug.c	Tue Mar 21 17:44:52 2000
@@ -0,0 +1,349 @@
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+
+static struct pci_dev *__pci_devices[100];
+static int num_pci_devices = 0;
+
+static struct pci_bus *__pci_buses[100];
+static int num_pci_buses = 0;
+
+static struct resource *__resources[1000];
+static int num_resources = 0;
+
+static void __add_pointer(const void *ptr, const void **table,
+			  int *num_entries, int max_entries)
+{
+    int i;
+
+    if (ptr == NULL)
+	return;
+
+    if (*num_entries == max_entries) {
+	printk("add_pointer: %p is full (%d entries)\n", table, *num_entries);
+	return;
+    }
+    for (i = 0; i < *num_entries; i++)
+	if ((unsigned long)table[i] == (unsigned long)ptr)
+	    return;
+    table[(*num_entries)++] = ptr;
+}
+
+static void __sort_table(const void **table, int num_entries)
+{
+    int i, j;
+
+    for (i = 0; i < num_entries-1; i++)
+	for (j = i+1; j < num_entries; j++)
+	    if ((unsigned long)table[j] < (unsigned long)table[i]) {
+		const void *t = table[i];
+		table[i] = table[j];
+		table[j] = t;
+	    }
+}
+
+static void add_pci_device(const struct pci_dev *dev)
+{
+    __add_pointer(dev, (const void **)__pci_devices, &num_pci_devices,
+		  sizeof(__pci_devices)/sizeof(void *));
+}
+
+static void add_pci_bus(const struct pci_bus *bus)
+{
+    __add_pointer(bus, (const void **)__pci_buses, &num_pci_buses,
+		  sizeof(__pci_buses)/sizeof(void *));
+}
+
+static void add_resource(const struct resource *res)
+{
+    __add_pointer(res, (const void **)__resources, &num_resources,
+		  sizeof(__resources)/sizeof(void *));
+}
+
+static void sort_pci_devices(void)
+{
+    __sort_table((const void **)__pci_devices, num_pci_devices);
+}
+
+static void sort_pci_buses(void)
+{
+    __sort_table((const void **)__pci_buses, num_pci_buses);
+}
+
+static void sort_resources(void)
+{
+    __sort_table((const void **)__resources, num_resources);
+}
+
+static void dump_resource_terse(int n, const struct resource *res)
+{
+    if (!res || !res->flags)
+	return;
+    printk("   %2d: %p [", n, res);
+    if (res->flags & IORESOURCE_IO)
+	printk(" I/O");
+    if (res->flags & IORESOURCE_MEM)
+	printk(" MEM");
+    if (res->flags & IORESOURCE_IRQ)
+	printk(" IRQ");
+    if (res->flags & IORESOURCE_DMA)
+	printk(" DMA");
+    if (res->flags & (IORESOURCE_IO|IORESOURCE_MEM))
+	printk(" %p-%p", (void *)res->start, (void *)res->end);
+    printk(" ]\n");
+}
+
+void dump_resource(const struct resource *res)
+{
+    printk("Resource %p %s\n", res, res->name);
+    if (!res->flags)
+	return;
+    printk("  range = %p-%p\n", (void *)res->start, (void *)res->end);
+    printk("  flags = 0x%08lx [", res->flags);
+    if (res->flags & IORESOURCE_IO)
+	printk(" IO");
+    if (res->flags & IORESOURCE_MEM)
+	printk(" MEM");
+    if (res->flags & IORESOURCE_IRQ)
+	printk(" IRQ");
+    if (res->flags & IORESOURCE_DMA)
+	printk(" DMA");
+
+    if (res->flags & IORESOURCE_PREFETCH)
+	printk(" PREFETCH");
+    if (res->flags & IORESOURCE_READONLY)
+	printk(" READONLY");
+    if (res->flags & IORESOURCE_CACHEABLE)
+	printk(" CACHEABLE");
+    if (res->flags & IORESOURCE_RANGELENGTH)
+	printk(" RANGELENGTH");
+    if (res->flags & IORESOURCE_SHADOWABLE)
+	printk(" SHADOWABLE");
+
+    if (res->flags & IORESOURCE_UNSET)
+	printk(" UNSET");
+    if (res->flags & IORESOURCE_AUTO)
+	printk(" AUTO");
+    if (res->flags & IORESOURCE_BUSY)
+	printk(" BUSY");
+
+    if (res->flags & IORESOURCE_IRQ) {
+	if (res->flags & IORESOURCE_IRQ_HIGHEDGE)
+	    printk(" IRQ_HIGHEDGE");
+	if (res->flags & IORESOURCE_IRQ_LOWEDGE)
+	    printk(" IRQ_LOWEDGE");
+	if (res->flags & IORESOURCE_IRQ_HIGHLEVEL)
+	    printk(" IRQ_HIGHLEVEL");
+	if (res->flags & IORESOURCE_IRQ_LOWLEVEL)
+	    printk(" IRQ_LOWLEVEL");
+    }
+
+    if (res->flags & IORESOURCE_DMA) {
+	switch (res->flags & IORESOURCE_DMA_TYPE_MASK) {
+	    case IORESOURCE_DMA_8BIT:
+		printk(" DMA_8BIT");
+		break;
+	    case IORESOURCE_DMA_8AND16BIT:
+		printk(" DMA_8AND16BIT");
+		break;
+	    case IORESOURCE_DMA_16BIT:
+		printk(" DMA_16BIT");
+		break;
+	}
+	if (res->flags & IORESOURCE_DMA_MASTER)
+	    printk(" DMA_MASTER");
+	if (res->flags & IORESOURCE_DMA_BYTE)
+	    printk(" DMA_BYTE");
+	if (res->flags & IORESOURCE_DMA_WORD)
+	    printk(" DMA_WORD");
+	switch (res->flags & IORESOURCE_DMA_SPEED_MASK) {
+	    case IORESOURCE_DMA_COMPATIBLE:
+		printk(" DMA_COMPATIBLE");
+		break;
+	    case IORESOURCE_DMA_TYPEA:
+		printk(" DMA_TYPEA");
+		break;
+	    case IORESOURCE_DMA_TYPEB:
+		printk(" DMA_TYPEB");
+		break;
+	    case IORESOURCE_DMA_TYPEF:
+		printk(" DMA_TYPEF");
+		break;
+	}
+    }
+
+    if (res->flags & IORESOURCE_MEM) {
+	if (res->flags & IORESOURCE_MEM_WRITEABLE)
+	    printk(" MEM_WRITEABLE");
+	if (res->flags & IORESOURCE_MEM_CACHEABLE)
+	    printk(" MEM_CACHEABLE");
+	if (res->flags & IORESOURCE_MEM_RANGELENGTH)
+	    printk(" MEM_RANGELENGTH");
+	switch (res->flags & IORESOURCE_MEM_TYPE_MASK) {
+	    case IORESOURCE_MEM_8BIT:
+		printk(" MEM_8BIT");
+		break;
+	    case IORESOURCE_MEM_16BIT:
+		printk(" MEM_16BIT");
+		break;
+	    case IORESOURCE_MEM_8AND16BIT:
+		printk(" MEM_8AND16BIT");
+		break;
+	}
+	if (res->flags & IORESOURCE_MEM_SHADOWABLE)
+	    printk(" MEM_SHADOWABLE");
+	if (res->flags & IORESOURCE_MEM_EXPANSIONROM)
+	    printk(" MEM_EXPANSIONROM");
+    }
+    printk(" ]\n");
+    printk("  parent = %p sibling = %p child = %p\n", res->parent,
+	   res->sibling, res->child);
+}
+
+void dump_pci_device(const struct pci_dev *dev)
+{
+    int i;
+
+    printk("PCI device %p %s %s\n", dev, dev->slot_name, dev->name);
+    printk("  global_list.prev = %p global_list.next = %p\n",
+	   dev->global_list.prev, dev->global_list.next);
+    printk("  bus_list.prev = %p bus_list.next = %p\n", dev->bus_list.prev,
+	   dev->bus_list.next);
+    printk("  bus = %p subordinate = %p\n", dev->bus, dev->subordinate);
+    printk("  sysdata = %p procent = %p devfn = 0x%08x\n", dev->sysdata,
+	   dev->procent, dev->devfn);
+    printk("  vendor/device = %04x:%04x subsystem = 0x%04x:%04x\n",
+	   dev->vendor, dev->device, dev->subsystem_vendor,
+	   dev->subsystem_device);
+    printk("  class = 0x%08x hdr_type = 0x%02x rom_base_reg = 0x%02x\n",
+	   dev->class, dev->hdr_type, dev->rom_base_reg);
+    printk("  driver = %p driver_data = %p\n", dev->driver, dev->driver_data);
+    printk("  dma_mask = %p\n", (void *)dev->dma_mask);
+    printk("  compatible[] = ");
+    for (i = 0; i < DEVICE_COUNT_COMPATIBLE; i++)
+	printk(" %04x:%04x", dev->vendor_compatible[i],
+	       dev->device_compatible[i]);
+    printk("\n");
+    printk("  irq = %d\n", dev->irq);
+    printk("  resource[] =\n");
+    for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
+	dump_resource_terse(i, &dev->resource[i]);
+    printk("  dma_resource[] =\n");
+    for (i = 0; i < DEVICE_COUNT_DMA; i++)
+	dump_resource_terse(i, &dev->dma_resource[i]);
+    printk("  irq_resource[] =\n");
+    for (i = 0; i < DEVICE_COUNT_IRQ; i++)
+	dump_resource_terse(i, &dev->irq_resource[i]);
+    printk("  active = %d ro = %d regs = 0x%04x\n", dev->active, dev->ro,
+	   dev->regs);
+    printk("  prepare = %p activate = %p deactivate = %p\n", dev->prepare,
+	   dev->activate, dev->deactivate);
+    printk("\n");
+}
+
+void dump_pci_bus(const struct pci_bus *bus)
+{
+    int i;
+
+    printk("PCI bus %p %s\n", bus, bus->name);
+    printk("  node.prev = %p node.next = %p\n", bus->node.prev,
+	   bus->node.next);
+    printk("  parent = %p\n", bus->parent);
+    printk("  children.prev = %p children.next = %p\n", bus->children.prev,
+	   bus->children.next);
+    printk("  devices.prev = %p devices.next = %p\n", bus->devices.prev,
+	   bus->devices.next);
+    printk("  self = %p\n", bus->self);
+    printk("  resource[] = [\n");
+    for (i = 0; i < 4; i++)
+	dump_resource_terse(i, bus->resource[i]);
+    printk("  ]\n");
+    printk("  ops = %p sysdata = %p procdir = %p\n", bus->ops, bus->sysdata,
+	   bus->procdir);
+    printk("  number = %d primary = %d secondary = %d subordinate = %d\n",
+	   bus->number, bus->primary, bus->secondary, bus->subordinate);
+    printk("  vendor/device = %04x:%04x\n", bus->vendor, bus->device);
+    printk("  serial = %d pnpver = %d productver = %d checksum = %d\n",
+	   bus->serial, bus->pnpver, bus->productver, bus->checksum);
+    printk("\n");
+}
+
+
+static void scan_pci_buses(void)
+{
+    struct pci_bus *bus;
+    int i;
+
+    for (bus = pci_bus_b(pci_root_buses.next);
+	 bus != pci_bus_b(&pci_root_buses);
+	 bus = pci_bus_b(bus->node.next)) {
+	add_pci_bus(bus);
+	for (i = 0; i < 4; i++)
+	    add_resource(bus->resource[i]);
+    }
+}
+
+static void scan_pci_devices(void)
+{
+    struct pci_dev *dev;
+    int i;
+
+    pci_for_each_dev(dev) {
+	add_pci_device(dev);
+	for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
+	    add_resource(&dev->resource[i]);
+	for (i = 0; i < DEVICE_COUNT_DMA; i++)
+	    add_resource(&dev->dma_resource[i]);
+	for (i = 0; i < DEVICE_COUNT_IRQ; i++)
+	    add_resource(&dev->irq_resource[i]);
+    }
+}
+
+void dump_pci_buses(void)
+{
+    int i;
+
+    printk(">>>>>>>>>>>>>>>>>>>> PCI Buses >>>>>>>>>>>>>>>>>>>>\n");
+    for (i = 0; i < num_pci_buses; i++)
+	dump_pci_bus(__pci_buses[i]);
+    printk("<<<<<<<<<<<<<<<<<<<< PCI Buses <<<<<<<<<<<<<<<<<<<<\n");
+}
+
+
+void dump_pci_devices(void)
+{
+    int i;
+
+    printk(">>>>>>>>>>>>>>>>>>>> PCI Devices >>>>>>>>>>>>>>>>>>>>\n");
+    for (i = 0; i < num_pci_devices; i++)
+	dump_pci_device(__pci_devices[i]);
+    printk("<<<<<<<<<<<<<<<<<<<< PCI Devices <<<<<<<<<<<<<<<<<<<<\n");
+}
+
+
+void dump_resources(void)
+{
+    int i;
+
+    printk(">>>>>>>>>>>>>>>>>>>> Resources >>>>>>>>>>>>>>>>>>>>\n");
+    for (i = 0; i < num_resources; i++)
+	dump_resource(__resources[i]);
+    printk("<<<<<<<<<<<<<<<<<<<< Resources <<<<<<<<<<<<<<<<<<<<\n");
+}
+
+void debug_scan_pci(void)
+{
+    scan_pci_buses();
+    scan_pci_devices();
+    sort_pci_buses();
+    sort_pci_devices();
+    sort_resources();
+}
+
+void debug_dump_pci(void)
+{
+    dump_pci_buses();
+    dump_pci_devices();
+    dump_resources();
+}
+

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: LongTrail PCI resource assignment

[Michel Lanners]

Hi Geert,

> I added code to do automatic PCI resource assignment for unassigned resources
> on my CHRP LongTrail. This is experimental, of course.

Cool!

> Notes:
>
>   - There are machine dependent things related to PCI resource assignment,
>     namely PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM in include/asm-ppc/pci.h. On the
>     LongTrail, PCI memory space is from 0xc0000000 until 0xf7000000, so I had
>     to change PCIBIOS_MIN_MEM to make sure allocation starts at 0xc0000000. I
>     think we need
>
> 	#define PCIBIOS_MIN_IO	ppc_md.pcibios_min_io
> 	#define PCIBIOS_MIN_MEM	ppc_md.pcibios_min_mem
>
>     and solve this in the machine specific setup code.

Hmmm.. bad solution. At least on a number of PowerMacs, there are multiple IO
windows, out of which IO resources need to be allocated (depends on the parent
bridge, in fact). So a single static definition doesn't do the job.

Can't we replace this with a seed to the resource tree, defined per host bridge
in arch-specific code? On PowerMacs, there's a function that scans for known
host bridges; that code could (either dynamically or based on hardcoded
knowledge) put the available IO window into some resource of the host bridge
pci_dev struct. The tree of IO resources could then be built from there.

>     Martin, do you think it makes sense to have PCIBIOS_MAX_IO and
>     PCIBIOS_MAX_MEM to pass to allocate_resource() as the upper limits?

I think so; allthough if you are clever at assigning resources, there's little chance you would ever hist the limit.... The reason to have the limit is that:

a. (on PMacs at least) IO windows are defined by the host bridges which map
a certain address range to IO accesses on the subordinate bus

b. mem windows are limited by the memory map of the arch.


Thanks

Michel
______________________________
.sig at home

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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Wed, 22 Mar 2000, Michel Lanners wrote:
> > Notes:
> >
> >   - There are machine dependent things related to PCI resource assignment,
> >     namely PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM in include/asm-ppc/pci.h. On the
> >     LongTrail, PCI memory space is from 0xc0000000 until 0xf7000000, so I had
> >     to change PCIBIOS_MIN_MEM to make sure allocation starts at 0xc0000000. I
> >     think we need
> >
> > 	#define PCIBIOS_MIN_IO	ppc_md.pcibios_min_io
> > 	#define PCIBIOS_MIN_MEM	ppc_md.pcibios_min_mem
> >
> >     and solve this in the machine specific setup code.
>
> Hmmm.. bad solution. At least on a number of PowerMacs, there are multiple IO
> windows, out of which IO resources need to be allocated (depends on the parent
> bridge, in fact). So a single static definition doesn't do the job.
>
> Can't we replace this with a seed to the resource tree, defined per host bridge
> in arch-specific code? On PowerMacs, there's a function that scans for known
> host bridges; that code could (either dynamically or based on hardcoded
> knowledge) put the available IO window into some resource of the host bridge
> pci_dev struct. The tree of IO resources could then be built from there.

The PCI resource allocation code allocates from the parent of the device. So I
think it must be possible to put bus-specific resource nodes in between the
general io{port,mem}_resource that covers the whole address space and the
device itself.

My PCI bus (struct pci_bus) shows up as:

    PCI bus c025f5a0
      node.prev = c01578b8 node.next = c01578b8
      parent = 00000000
      children.prev = c025f5ac children.next = c025f5ac
      devices.prev = c025c008 devices.next = c025dc08
      self = 00000000
      resource[] = [
	0: c01412f8 [ I/O 00000000-ffffffff ]
	1: c0141314 [ MEM 00000000-ffffffff ]
      ]
      ops = c014059c sysdata = 00000000 procdir = c05b2540
      number = 0 primary = 0 secondary = 0 subordinate = 0
      vendor/device = 0000:0000
      serial = 0 pnpver = 0 productver = 0 checksum = 0

    Resource c01412f8 PCI IO
      range = 00000000-ffffffff
      flags = 0x00000100 [ IO ]
      parent = 00000000 sibling = 00000000 child = c027dac0
    Resource c0141314 PCI mem
      range = 00000000-ffffffff
      flags = 0x00000200 [ MEM MEM_8BIT ]
      parent = 00000000 sibling = 00000000 child = c025c48c

so the parents of all resources for devices are `PCI IO' and `PCI mem', the
whole address space. If the PCI bus would have resources that contain only the
effective areas for that bus, we can live with the standard

#define PCIBIOS_MIN_IO          0x1000		(10 bit XT ISA I/O space)
#define PCIBIOS_MIN_MEM         0x10000000	(why 256 MB and not 16 MB
						 ISA memory space??)

as on ia32.

So the resources for my PCI bus should be

    I/O 00000000-00ffffff
    MEM c0000000-f6ffffff

If you have two PCI busses, you want to have separate busresources for I/O,
like

    I/O 00000000-00ffffff

for bus 0 and

    I/O 01000000-01ffffff

for bus 1.

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: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Wed, Mar 22, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:

>> Hmmm.. bad solution. At least on a number of PowerMacs, there are multiple
>IO
>> windows, out of which IO resources need to be allocated (depends on the
>parent
>> bridge, in fact). So a single static definition doesn't do the job.
>>
>> Can't we replace this with a seed to the resource tree, defined per host
>bridge
>> in arch-specific code? On PowerMacs, there's a function that scans for
known
>> host bridges; that code could (either dynamically or based on hardcoded
>> knowledge) put the available IO window into some resource of the host
bridge
>> pci_dev struct. The tree of IO resources could then be built from there.
>
>The PCI resource allocation code allocates from the parent of the
device. So I
>think it must be possible to put bus-specific resource nodes in between the
>general io{port,mem}_resource that covers the whole address space and the
>device itself.

Well, ideally, we need the resource allocation/re-allocation mecanism to
rely on the parent resource node, regardless of it beeing a real PCI bus
or something else. This way, we can handle the Uni-N case by insterting
sort of per-bus nodes: (I only report IO ranges below since mem ranges
seems to be less of a problem)

 Uni-N : IO 0xf0000000 - 0xf5ffffff  (fake range covering all 3 sub-busses)
   |
   |-- Uni-N-sub1 : IO 0xf0000000 - 0xf000ffff
   |      |
   |      --- ATI AGP
   |
   |-- Uni-N-sub2 : IO 0xf2000000 - 0xf200ffff
   |      |
   |      --- (external PCI, can be a DEC PCI<->PCI bridge)
   |
   |-- Uni-N-sub3 : IO 0xf4000000 - 0xf400ffff
          |
          --- GMAC
          |
          --- Internal FireWire

Note that I don't think we need IOs at all on the GMAC/InternalFW bus.

The pmac specific PCI code would then create the 3 Uni-N-subX nodes. The
probing code needs to be hacked so that devices are put under the proper
sub nodes. Then, the reallocation/fixup code will re-assign IO ranges
based only on the device parent node exposed range.


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

Re: LongTrail PCI resource assignment

[Michel Lanners]

Hi Ben,

On  22 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
> Well, ideally, we need the resource allocation/re-allocation mecanism to
> rely on the parent resource node, regardless of it beeing a real PCI bus
> or something else. This way, we can handle the Uni-N case by insterting
> sort of per-bus nodes: (I only report IO ranges below since mem ranges
> seems to be less of a problem)
>
>  Uni-N : IO 0xf0000000 - 0xf5ffffff  (fake range covering all 3 sub-busses)
>    |
>    |-- Uni-N-sub1 : IO 0xf0000000 - 0xf000ffff
>    |      |
>    |      --- ATI AGP
>    |
>    |-- Uni-N-sub2 : IO 0xf2000000 - 0xf200ffff
>    |      |
>    |      --- (external PCI, can be a DEC PCI<->PCI bridge)
>    |
>    |-- Uni-N-sub3 : IO 0xf4000000 - 0xf400ffff
>           |
>           --- GMAC
>           |
>           --- Internal FireWire

How about omitting the base Uni-N, and have each of the three
sub-entities be seen as a separate host bridge, being parent to a
separate pci bus with a separate bus number?

OK, that would mean renumbering stuff (might be quite hard, if you
think about a P2P bridge in a PCI slot...), but it might make config
acesses simpler, as you can register config access functions per bus..

> The pmac specific PCI code would then create the 3 Uni-N-subX nodes. The
> probing code needs to be hacked so that devices are put under the proper
> sub nodes. Then, the reallocation/fixup code will re-assign IO ranges
> based only on the device parent node exposed range.

Would it be possible to insert those sub-nodes at all? Would those be
PCI devices in the global chain of devs, or would you just allocate
resources and insert those in the tree of resources?


Michel

PS Interesting to see Apple still sticks to the original memory map
(from 1st generation PCI Macs)...

------------------------------------------------------------------------
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: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Thu, Mar 23, 2000, Michel Lanners <mlan@cpu.lu> wrote:

>How about omitting the base Uni-N, and have each of the three
>sub-entities be seen as a separate host bridge, being parent to a
>separate pci bus with a separate bus number?
>
>OK, that would mean renumbering stuff (might be quite hard, if you
>think about a P2P bridge in a PCI slot...), but it might make config
>acesses simpler, as you can register config access functions per bus..

Well, that's what I originally wanted to do. But it causes a number of
problems and I felt it could be simpler to actually use the resource trick:

 - Renumbering, reconfiguring PCI<->PCI bridges (and all G4s have one), etc..
 - Re-sync'ing the OF tree or else, the functions for matching PCI
devices with
   OF entries will break, causing some problems here or there
 - What about devices that issue config access to other devices ? I don't
know if
   such device actually exist, but I beleive it's theorically possible. If for
   any reason they rely on a devfn/bus_number send to them by the driver, they
   will break.

Well, my main problem is with PCI<->PCI bridges and re-numbering since I
don't have the PCI bridge spec (looks like it's paying). I do have the
PCI 2.1 and 2.2 specs but they don't include the PCI<->PCI bridge section.

>Would it be possible to insert those sub-nodes at all? Would those be
>PCI devices in the global chain of devs, or would you just allocate
>resources and insert those in the tree of resources?

Well, I was thinking about only adding them to the tree of resources. If
there a problem with that ? (I'm not too familiar with the new resource
management).


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

Re: LongTrail PCI resource assignment

[Michel Lanners]

Hi all,

On  23 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>How about omitting the base Uni-N, and have each of the three
>>sub-entities be seen as a separate host bridge, being parent to a
>>separate pci bus with a separate bus number?

> Well, that's what I originally wanted to do. But it causes a number of
> problems and I felt it could be simpler to actually use the resource trick:
>
>  - Renumbering, reconfiguring PCI<->PCI bridges (and all G4s have one), etc..

You can probably avoid that by leaving the 'real' PCI bus (the one with
the slots) as bus 0 with all its subordinates, and have the other two
buses renumbered after those. Unfortunately (don't know whether it
really matters) those bus numbers might change depending on what you
put into the slots...

>  - Re-sync'ing the OF tree or else, the functions for matching PCI
> devices with
>    OF entries will break, causing some problems here or there

That's obviously an issue. I think we should decide once and for all
whether the OF tree is supposed to be up-to-date once the system is
running. If so, then all fixups (also changing base address) need to be
re-sync'ed into the OF tree, which is not done now... Or we just leave
the OF tree alone and work only with the PCI_dev list.

>  - What about devices that issue config access to other devices ? I don't
> know if
>    such device actually exist, but I beleive it's theorically possible. If for
>    any reason they rely on a devfn/bus_number send to them by the driver, they
>    will break.

I doubt that would be done... except maybe a DMA engine modifying it's
own config. But then again, that code is supposed to be set up by the
driver, who knows the right bus number from struct pci_dev.

> Well, my main problem is with PCI<->PCI bridges and re-numbering since I
> don't have the PCI bridge spec (looks like it's paying). I do have the
> PCI 2.1 and 2.2 specs but they don't include the PCI<->PCI bridge section.

Yes, easiest would be to leave P2P bridges alone.

>>Would it be possible to insert those sub-nodes at all? Would those be
>>PCI devices in the global chain of devs, or would you just allocate
>>resources and insert those in the tree of resources?
>
> Well, I was thinking about only adding them to the tree of resources. If
> there a problem with that ? (I'm not too familiar with the new resource
> management).

Neither am I... it might not be the most 'clean' way, but should work
nevertheless. You'll just have three resources with no corresponding
PCI dev...


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: LongTrail PCI resource assignment

[Timothy A. Seufert]

At 8:22 PM +0100 3/23/00, Michel Lanners wrote:

>That's obviously an issue. I think we should decide once and for all
>whether the OF tree is supposed to be up-to-date once the system is
>running. If so, then all fixups (also changing base address) need to be
>re-sync'ed into the OF tree, which is not done now... Or we just leave
>the OF tree alone and work only with the PCI_dev list.

It's not up to me, because I don't understand the code well enough to
contribute directly, but I'll offer these points in favor of not
updating OF:


1. Duplication of information across multiple data structures is
evil.  It should be avoided at all costs.

If there was a really, really good reason to keep OF up to date
(like, say, if we could break back into the OF console like you can
on Sparcs), then it would be OK.  Otherwise it is most likely
unnecessary bloat, and leads to potential confusion (and bugs).  Is
there any such reason on ppc?


2. Most arch types obviously don't have an OF tree at all.
Presumably they just do everything with the pci_dev list.  Therefore,
ppc should too -- it's a bad idea to be different in an unnecessary
way.

   Tim Seufert

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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Timothy A. Seufert wrote:
> At 8:22 PM +0100 3/23/00, Michel Lanners wrote:
>
> >That's obviously an issue. I think we should decide once and for all
> >whether the OF tree is supposed to be up-to-date once the system is
> >running. If so, then all fixups (also changing base address) need to be
> >re-sync'ed into the OF tree, which is not done now... Or we just leave
> >the OF tree alone and work only with the PCI_dev list.
>
> It's not up to me, because I don't understand the code well enough to
> contribute directly, but I'll offer these points in favor of not
> updating OF:
>
>
> 1. Duplication of information across multiple data structures is
> evil.  It should be avoided at all costs.
>
> If there was a really, really good reason to keep OF up to date
> (like, say, if we could break back into the OF console like you can
> on Sparcs), then it would be OK.  Otherwise it is most likely
> unnecessary bloat, and leads to potential confusion (and bugs).  Is
> there any such reason on ppc?

Offb is one thing that comes to my mind. But this can easily be solved by
scanning for OF displays before PCI fixup and updating the values returned from
the scanning in pcibios_update_resource() if corresponding resources are
modified.

> 2. Most arch types obviously don't have an OF tree at all.
> Presumably they just do everything with the pci_dev list.  Therefore,
> ppc should too -- it's a bad idea to be different in an unnecessary
> way.

I favor using PCI probing for everything as well, since it means more
integration with existing drivers and less PPC-specific code.

Another advantage of no longer using the information from the OF tree is that
we can just call pci_assign_unassigned_resources() and get everything
reassigned, without worrying about inconsistencies with the OF device tree.

BTW, if you do want to keep the OF device tree consistent,
pcibios_update_resource() is the place to do this.

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: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Fri, Mar 24, 2000, Geert Uytterhoeven <geert@linux-m68k.org> wrote:


>Another advantage of no longer using the information from the OF tree is that
>we can just call pci_assign_unassigned_resources() and get everything
>reassigned, without worrying about inconsistencies with the OF device tree.
>
>BTW, if you do want to keep the OF device tree consistent,
>pcibios_update_resource() is the place to do this.

If this is called _after_ we have done the bus re-numbering, updating the
OF tree will be difficult since we need the old bus number to match the
PCI device with it's OF entry.


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> >Another advantage of no longer using the information from the OF tree is that
> >we can just call pci_assign_unassigned_resources() and get everything
> >reassigned, without worrying about inconsistencies with the OF device tree.
> >
> >BTW, if you do want to keep the OF device tree consistent,
> >pcibios_update_resource() is the place to do this.
>
> If this is called _after_ we have done the bus re-numbering, updating the
> OF tree will be difficult since we need the old bus number to match the
> PCI device with it's OF entry.

On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?

Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
case), I get:

 atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
 atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
 atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
 atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
 atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0

I'd like to correct the first one to only include the big endian aperture,
and the third one to use the little endian aperture (0x817ff000). Can this
be done in atyfb_init?

	Michael


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Michael Schmitz wrote:
> > >Another advantage of no longer using the information from the OF tree is that
> > >we can just call pci_assign_unassigned_resources() and get everything
> > >reassigned, without worrying about inconsistencies with the OF device tree.
> > >
> > >BTW, if you do want to keep the OF device tree consistent,
> > >pcibios_update_resource() is the place to do this.
> >
> > If this is called _after_ we have done the bus re-numbering, updating the
> > OF tree will be difficult since we need the old bus number to match the
> > PCI device with it's OF entry.
>
> On a somewhat related issue (the PCI mapping funnies for the Lombard and
> possibly other Rage Pro devices): what are the penalties if I 'correct'
> the PCI mapping for the Rage Pro within atyfb_of_init?

atyfb_of_init() no longer exists. Atyfb uses PCI probing only now.

> Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
> case), I get:
>
>  atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
>  atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
>  atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
>  atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
>  atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
>
> I'd like to correct the first one to only include the big endian aperture,

Why? Atyfb has no troubles finding the big endian aperture on its own.

> and the third one to use the little endian aperture (0x817ff000). Can this
> be done in atyfb_init?

Third one? ATI Mach64 chips have 2 PCI windows only, AFAIK.

I think chunk 0 maps to PCI BAR 0 and chunk 2 maps to PCI BAR 1. Don't know
what chunk 1 and 3 are.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > On a somewhat related issue (the PCI mapping funnies for the Lombard and
> > possibly other Rage Pro devices): what are the penalties if I 'correct'
> > the PCI mapping for the Rage Pro within atyfb_of_init?
>
> atyfb_of_init() no longer exists. Atyfb uses PCI probing only now.

Define 'now' please.

> > Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
> > case), I get:
> >
> >  atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
> >  atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
> >  atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
> >  atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
> >  atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
> >
> > I'd like to correct the first one to only include the big endian aperture,
>
> Why? Atyfb has no troubles finding the big endian aperture on its own.

Stupid X doesn't query atyfb on this and stomps on the PCI resources.
atyfb finds the BE aperture because someone hardcoded that it's at
base + 0x800000 :-)

> > and the third one to use the little endian aperture (0x817ff000). Can this
> > be done in atyfb_init?
>
> Third one? ATI Mach64 chips have 2 PCI windows only, AFAIK.

1 is the I/O region, 0 is vram, 2 is MMIO. 1 conflicts with some other
device (though lspci reports it as disabled anyway), 0 and 1 overlap. X
outsmarts us and disables 0 for the benefit of 2.
lspci also reports three regions, in the same order, with the same
addresses (I sent you a lspci log when hunting down the 2.3.48 atyfb bug).

> I think chunk 0 maps to PCI BAR 0 and chunk 2 maps to PCI BAR 1. Don't know
> what chunk 1 and 3 are.

Here's how I read them, don't know how this translates to BAR 0 or 1:

--- drivers/video/atyfb.c.org	Thu Mar 23 22:32:01 2000
+++ drivers/video/atyfb.c	Thu Mar 23 22:28:42 2000
@@ -3191,7 +3191,7 @@
     u8 bus, devfn;
     u16 cmd;
     struct fb_info_aty *info;
-    int i;
+    int i, naddr;

     if (device_is_compatible(dp, "ATY,264LTPro")) {
 	/* XXX kludge for now */
@@ -3219,6 +3219,13 @@
 	    return;
     }

+    printk("atyfb_of_init: got %d OF adresses for ATY:\n", dp->n_addrs);
+    for (i = 0; i < dp->n_addrs; i++)
+	printk(" %08x-%08x", dp->addrs[i].address,
+	       dp->addrs[i].address+dp->addrs[i].size-1);
+    if (dp->n_addrs)
+	printk("\n");
+
     info = kmalloc(sizeof(struct fb_info_aty), GFP_ATOMIC);
     if (!info) {
 	printk("atyfb_of_init: can't alloc fb_info_aty\n");
@@ -3241,6 +3248,38 @@

     /* enable memory-space accesses using config-space command register */
     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;
+	    size = ~(size) + 1;
+
+	    if (size == 0)
+	    	break;
+
+	    printk("atyfb: chunk %d ofbase 0x%lx breg %d io %d pbase 0x%lx size 0x%lx \n",
+		i, base, breg, io, pbase, size);
+
+	}
+
+	naddr = i;
+	printk("atyfb: found %d PCI addresses total. \n", i);
+
+	/* insert fixup code here ?? */
+
 	pcibios_read_config_word(bus, devfn, PCI_COMMAND, &cmd);
 	if (cmd != 0xffff) {
 	    cmd |= PCI_COMMAND_MEMORY;

As I said, I adapted code from elsewhere in atyfb.c. I'm just getting my
feet wet WRT PCI.

	Michael

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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Michael Schmitz wrote:
> > > On a somewhat related issue (the PCI mapping funnies for the Lombard and
> > > possibly other Rage Pro devices): what are the penalties if I 'correct'
> > > the PCI mapping for the Rage Pro within atyfb_of_init?
> >
> > atyfb_of_init() no longer exists. Atyfb uses PCI probing only now.
>
> Define 'now' please.

2.4.0 :-)

> > > I'd like to correct the first one to only include the big endian aperture,
> >
> > Why? Atyfb has no troubles finding the big endian aperture on its own.
>
> Stupid X doesn't query atyfb on this and stomps on the PCI resources.
> atyfb finds the BE aperture because someone hardcoded that it's at
> base + 0x800000 :-)

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

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).

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: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Michael Schmitz wrote:
> > >Another advantage of no longer using the information from the OF tree is that
> > >we can just call pci_assign_unassigned_resources() and get everything
> > >reassigned, without worrying about inconsistencies with the OF device tree.
> > >
> > >BTW, if you do want to keep the OF device tree consistent,
> > >pcibios_update_resource() is the place to do this.
> >
> > If this is called _after_ we have done the bus re-numbering, updating the
> > OF tree will be difficult since we need the old bus number to match the
> > PCI device with it's OF entry.
>
> On a somewhat related issue (the PCI mapping funnies for the Lombard and
> possibly other Rage Pro devices): what are the penalties if I 'correct'
> the PCI mapping for the Rage Pro within atyfb_of_init?

To be a bit more constructive: what about adapting my patches and use them on
the Lombard as well? Then the conflicting secondary aperture will be assigned a
new region, while the valid regions will stay what they are.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > On a somewhat related issue (the PCI mapping funnies for the Lombard and
> > possibly other Rage Pro devices): what are the penalties if I 'correct'
> > the PCI mapping for the Rage Pro within atyfb_of_init?
>
> To be a bit more constructive: what about adapting my patches and use them on
> the Lombard as well? Then the conflicting secondary aperture will be assigned a
> new region, while the valid regions will stay what they are.

Fine with me. I forgot to mention that I'm currently working on the 2.2.15
atyfb source, do your patches apply to that as well? (Frankly, I tried to
follow your argument about the PCI / OF resource handling but couldn't
make out where it would fit in with the problem I try to solve.)

	Michael


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Michael Schmitz wrote:
> > > On a somewhat related issue (the PCI mapping funnies for the Lombard and
> > > possibly other Rage Pro devices): what are the penalties if I 'correct'
> > > the PCI mapping for the Rage Pro within atyfb_of_init?
> >
> > To be a bit more constructive: what about adapting my patches and use them on
> > the Lombard as well? Then the conflicting secondary aperture will be assigned a
> > new region, while the valid regions will stay what they are.
>
> Fine with me. I forgot to mention that I'm currently working on the 2.2.15
> atyfb source, do your patches apply to that as well? (Frankly, I tried to
> follow your argument about the PCI / OF resource handling but couldn't
> make out where it would fit in with the problem I try to solve.)

For 2.2.15, I suggest doing it in atyfb manually. But it will be quite
difficult to find a suitable free hole in PCI memory space without the resource
management subsystem.

PCI resource assignment was added in late 2.3.x, together with hot-pluggable
PCI support.

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: LongTrail PCI resource assignment

[Michael Schmitz]

> > Fine with me. I forgot to mention that I'm currently working on the 2.2.15
> > atyfb source, do your patches apply to that as well? (Frankly, I tried to
> > follow your argument about the PCI / OF resource handling but couldn't
> > make out where it would fit in with the problem I try to solve.)
>
> For 2.2.15, I suggest doing it in atyfb manually. But it will be quite
> difficult to find a suitable free hole in PCI memory space without the resource
> management subsystem.

I just want to reduce the vram and mmio apertures to the minimum sizes and
make them non overlapping.

	Michael


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

Re: LongTrail PCI resource assignment

[Gabriel Paubert]

On Fri, 24 Mar 2000, Michael Schmitz wrote:

> On a somewhat related issue (the PCI mapping funnies for the Lombard and
> possibly other Rage Pro devices): what are the penalties if I 'correct'
> the PCI mapping for the Rage Pro within atyfb_of_init?
>
> Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
> case), I get:
>
>  atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
>  atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
>  atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
>  atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
>  atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
>
> I'd like to correct the first one to only include the big endian aperture,
> and the third one to use the little endian aperture (0x817ff000). Can this
> be done in atyfb_init?

Don't touch the resources which correspond to assigned PCI bus addresses
because they correspond to the address ranges to which chip decoders
respond. Lying in this area makes dynamic allocation and hotplugging
impossible by giving the resource allocator the impression that some area
is free. Rather attach asubtree to the already existing device resources.

That's for example how it looks like for the VME bridge I'm using
(I hope to build a diff soon, but it's very easy to do), the third
bridge area actually consists of 8 subareas which together occupy 64 Mb
(ther other subareas I've defined are mostly cosmetic):

e0000000-f2ffffff : Tundra Semiconductor Corp. CA91C042 [Universe]
  e0000000-f2ffffff : VMEbus A32 BLT        D32 [e0000000-f2ffffff]
f3000000-f3ffffff : Tundra Semiconductor Corp. CA91C042 [Universe]
  f3000000-f3ffffff : VMEbus CR/CSR         D32 [00000000-00ffffff]
f4000000-f7ffffff : Tundra Semiconductor Corp. CA91C042 [Universe]
  f4000000-f4feffff : VMEbus A24 DATA       D16 [00000000-00feffff]
  f4ff0000-f4ffffff : VMEbus A16            D16 [00000000-0000ffff]
  f5000000-f5feffff : VMEbus A24 DATA       D32 [00000000-00feffff]
  f5ff0000-f5ffffff : VMEbus A16            D32 [00000000-0000ffff]
  f6000000-f6feffff : VMEbus A24 DATA  PRIV D16 [00000000-00feffff]
  f6ff0000-f6ffffff : VMEbus A16       PRIV D16 [00000000-0000ffff]
  f7000000-f7feffff : VMEbus A24 DATA  PRIV D32 [00000000-00feffff]
  f7ff0000-f7ffffff : VMEbus A16       PRIV D32 [00000000-0000ffff]
fc6b0000-fc6bffff : S3 Inc. 86c764/765 [Trio32/64/64V+]
fc6c0000-fc6fffff : Digital Equipment Corporation DECchip 21140 [FasterNet]
fc700000-fc701fff : Tundra Semiconductor Corp. CA91C042 [Universe]
  fc700000-fc701fff : Dynamically reprogrammed VME slave image
fc7aee80-fc7aeeff : Digital Equipment Corporation DECchip 21140 [FasterNet]
fc7aef00-fc7aefff : Symbios Logic Inc. (formerly NCR) 53c825
fc7af000-fc7affff : Symbios Logic Inc. (formerly NCR) 53c825
fc7b0000-fc7bffff : Tundra Semiconductor Corp. CA91C042 [Universe]
fc7c0000-fc7fffff : Motorola Raven
fc800000-fcffffff : S3 Inc. 86c764/765 [Trio32/64/64V+]

	Gabriel.


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
> > case), I get:
> >
> >  atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
> >  atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
> >  atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
> >  atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
> >  atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
> >
> > I'd like to correct the first one to only include the big endian aperture,
> > and the third one to use the little endian aperture (0x817ff000). Can this
> > be done in atyfb_init?
>
> Don't touch the resources which correspond to assigned PCI bus addresses
> because they correspond to the address ranges to which chip decoders
> respond. Lying in this area makes dynamic allocation and hotplugging
> impossible by giving the resource allocator the impression that some area
> is free. Rather attach asubtree to the already existing device resources.

So it's perfectly legal for resources within the same device to overlap?
WTF does X not tolerate this and disables the overlapping one?

(Side note: X also reports the mem resources in reverse order, or maybe
sorted by end address, and disables the larger of the two apertures
because it saw the smaller one first, even though the smaller one is
completely embedded in the larger).

I'm not sure adding subtrees will help - I guess X might go ahead and
disable the main resources anyway. Will the subtree resources remain
accessible in that case?

	Michael


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

Re: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Fri, Mar 24, 2000, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> wrote:

>> Don't touch the resources which correspond to assigned PCI bus addresses
>> because they correspond to the address ranges to which chip decoders
>> respond. Lying in this area makes dynamic allocation and hotplugging
>> impossible by giving the resource allocator the impression that some area
>> is free. Rather attach asubtree to the already existing device resources.
>
>So it's perfectly legal for resources within the same device to overlap?
>WTF does X not tolerate this and disables the overlapping one?
>
>(Side note: X also reports the mem resources in reverse order, or maybe
>sorted by end address, and disables the larger of the two apertures
>because it saw the smaller one first, even though the smaller one is
>completely embedded in the larger).
>
>I'm not sure adding subtrees will help - I guess X might go ahead and
>disable the main resources anyway. Will the subtree resources remain
>accessible in that case?

Two things:

 - It's not legal to have overlapping BARs (well, maybe it is if they are
doing hard decoding), but it's out of spec. At least, that's my
understanding of the spec. ATI does this, so we need a workaround.

 - X will always try to fix any PCI conflict it finds, with or without
fbdev drivers. That's what I understands after discussing with some X
coders. To handle various OSes and all sort of legacy crap, X has to play
weird tricks with PCI and no-one in the XFree group wants to change this.
They don't want to make this remapping optional neither for support
reasons, so we have to make sure there's no conflict detected by X so it
doesn't try to mess with assignements.

However, Egbert is working on improving the X PCI interface so that we
know in the kernel what's going on the PCI bus and can keep kernel
resources in sync. I beleive we can use this not-yet-existing mecanism to
"hide" some of those stuffs to X if really necessary.

Ben.


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

Re: LongTrail PCI resource assignment

[Gabriel Paubert]

On Fri, 24 Mar 2000, Michael Schmitz wrote:

> > Don't touch the resources which correspond to assigned PCI bus addresses
> > because they correspond to the address ranges to which chip decoders
> > respond. Lying in this area makes dynamic allocation and hotplugging
> > impossible by giving the resource allocator the impression that some area
> > is free. Rather attach asubtree to the already existing device resources.
>
> So it's perfectly legal for resources within the same device to overlap?
> WTF does X not tolerate this and disables the overlapping one?

It may be legal if the internal decoders are prioritized and the priority
is the right one (which it should if the firmware has set it up this way).
I don't consider it good practice though, especially when it saves only
minute amounts of address space. X should tolerate this in any case
however, it should admit that it is not always smarter than the firmware.

> I'm not sure adding subtrees will help - I guess X might go ahead and
> disable the main resources anyway. Will the subtree resources remain
> accessible in that case?

Yes, but then I have given up on trying to understand X :-( Oh and the
case I had was somewhat different, since base registers never overlap,
only that a single base registers defined several independant areas.
What I was suggesting is that if you need it you should add a subtree to
the vram area with for example (that's completely made-up for my S3 and
I did not even look at the reference, so the offsets night be wrong):

f8000000-fbffffff: S3 Inc. 86c764/765 [Trio32/64/64V+]
  f8000000-f8ffffff: Little endian VRAM aperture
  f9000000-f9ffffff: Big endian VRAM aperture

and perhaps even another line with MMIO registers if applicable. Only the
first line would appear in lspci, but you could get all the info from cat
/proc/iomem.

	Gabriel.


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > So it's perfectly legal for resources within the same device to overlap?
> > WTF does X not tolerate this and disables the overlapping one?
>
> It may be legal if the internal decoders are prioritized and the priority
> is the right one (which it should if the firmware has set it up this way).

They are prioritized the right way: if you memset the whole aperture to 0
the chip freaks out instead of just painting the whole screen black. Been
there, done that.

> I don't consider it good practice though, especially when it saves only
> minute amounts of address space. X should tolerate this in any case
> however, it should admit that it is not always smarter than the firmware.

Well, arguing with X is pointless. So far I've always got the short end of
the stick :-)

> > I'm not sure adding subtrees will help - I guess X might go ahead and
> > disable the main resources anyway. Will the subtree resources remain
> > accessible in that case?
>
> Yes, but then I have given up on trying to understand X :-( Oh and the

I mean: if someone disables the original resource, what happens to the
new resources?

	Michael


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

Re: LongTrail PCI resource assignment

[Gabriel Paubert]

On Fri, 24 Mar 2000, Michael Schmitz wrote:

> They are prioritized the right way: if you memset the whole aperture to 0
> the chip freaks out instead of just painting the whole screen black. Been
> there, done that.

Ok, anyway memsetting the whole aperture may not be the smartest thing to
do since the aperture may be larger than the installed VRAM.

> Well, arguing with X is pointless. So far I've always got the short end of
> the stick :-)

Hmmm, then find some free space and put the MMIO registers in this area.

> I mean: if someone disables the original resource, what happens to the
> new resources?

I don't understand the question.

	Gabriel.


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > They are prioritized the right way: if you memset the whole aperture to 0
> > the chip freaks out instead of just painting the whole screen black. Been
> > there, done that.
>
> Ok, anyway memsetting the whole aperture may not be the smartest thing to
> do since the aperture may be larger than the installed VRAM.

I was hoping for OF to report the right thing.

> > Well, arguing with X is pointless. So far I've always got the short end of
> > the stick :-)
>
> Hmmm, then find some free space and put the MMIO registers in this area.

Assuming VRAM is from 0x81800000 to 0x81ffffff (the big endian aperture),
a perfect place to put MMIO would be 0x817ff000. The same registers appear
there, and that's the very place atyfb exports for MMIO mmap. It's just
the combination of silly PCI mapping in OF and X boneheadedness that gets
us here.

> > I mean: if someone disables the original resource, what happens to the
> > new resources?
>
> I don't understand the question.

Assume the 0x81000000->0x81ffffff mapping is left untouched and I just add
a new one for 0x81800000>0x81ffffff, and another one for 0x817ff000->
0x817fffff. X goes along and disables 0x81800000->0x81ffffff, does the
0x81800000>0x81ffffff stil work? X disables 0x81fff000->0x81ffffff, does
0x817ff000->0x817fffff still work?

But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.

	Michael


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

Re: LongTrail PCI resource assignment

[Gabriel Paubert]

On Fri, 24 Mar 2000, Michael Schmitz wrote:

> > > They are prioritized the right way: if you memset the whole aperture to 0
> > > the chip freaks out instead of just painting the whole screen black. Been
> > > there, done that.
> >
> > Ok, anyway memsetting the whole aperture may not be the smartest thing to
> > do since the aperture may be larger than the installed VRAM.
>
> I was hoping for OF to report the right thing.

Nope, if it is the assigned addresses properties. It has to be the range
of addresses potentially decoded by this device to make sure that
allocation of other devices does not cause conflicts. I remember seeing
something about allocating subareas in OF but I don't know where to find
it right now.

> Assuming VRAM is from 0x81800000 to 0x81ffffff (the big endian aperture),
> a perfect place to put MMIO would be 0x817ff000. The same registers appear
> there, and that's the very place atyfb exports for MMIO mmap. It's just
> the combination of silly PCI mapping in OF and X boneheadedness that gets
> us here.

I disagree, mapping in OF or in the resource tree is not that silly. At
one point you have to describe all address ranges potentially decoded
by a device to perform correct allocation, even if they corresopnd to
alias addresses of the same VRAM for example.

> Assume the 0x81000000->0x81ffffff mapping is left untouched and I just add
> a new one for 0x81800000>0x81ffffff, and another one for 0x817ff000->
> 0x817fffff. X goes along and disables 0x81800000->0x81ffffff, does the
> 0x81800000>0x81ffffff stil work? X disables 0x81fff000->0x81ffffff, does
> 0x817ff000->0x817fffff still work?

It depends on how it disables it. By writing 0 to the BAR ?

Anyway the resource tree in 2.3 won't let you add the 0x81800000 mapping
unless you put it as a child of the 0x81000000, which it actually is AFAIU
the intent of the resource tree code.

> But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
> 0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.

Then X needs to be fixed, perhaps the generic X PCI code needs special
hooks for individual drivers to check whether the configuration is
acceptable or not. OTOH I don't understand why something there (OF ?)
insists in overlapping the registers with the VRAM, the PCI code in the
kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
space is completely useless.

	Gabriel.

>
> 	Michael
>
>


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > I was hoping for OF to report the right thing.
>
> Nope, if it is the assigned addresses properties. It has to be the range
> of addresses potentially decoded by this device to make sure that
> allocation of other devices does not cause conflicts. I remember seeing

OK, strictly speaking the OF mapping is right, we just never need the
full address range.

> > Assume the 0x81000000->0x81ffffff mapping is left untouched and I just add
> > a new one for 0x81800000>0x81ffffff, and another one for 0x817ff000->
> > 0x817fffff. X goes along and disables 0x81800000->0x81ffffff, does the
> > 0x81800000>0x81ffffff stil work? X disables 0x81fff000->0x81ffffff, does
> > 0x817ff000->0x817fffff still work?
>
> It depends on how it disables it. By writing 0 to the BAR ?

By writing to the register at offset 4 - I'm not familiar with PCI speak
but this seems to be the same register that pcibios_write_config* writes
to in the atyfb code. 0 to disable, different bit patterns to enable mem
or io access.

> Anyway the resource tree in 2.3 won't let you add the 0x81800000 mapping
> unless you put it as a child of the 0x81000000, which it actually is AFAIU
> the intent of the resource tree code.

I'll look at the 2.3 code some more.

> > But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
> > 0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.
>
> Then X needs to be fixed, perhaps the generic X PCI code needs special
> hooks for individual drivers to check whether the configuration is
> acceptable or not. OTOH I don't understand why something there (OF ?)
> insists in overlapping the registers with the VRAM, the PCI code in the
> kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
> space is completely useless.

It should but last time I tried it complained about resource conflicts.
I've sent BenH a log of this on request.

	Michael


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Michael Schmitz wrote:
> > Then X needs to be fixed, perhaps the generic X PCI code needs special
> > hooks for individual drivers to check whether the configuration is
> > acceptable or not. OTOH I don't understand why something there (OF ?)
> > insists in overlapping the registers with the VRAM, the PCI code in the
> > kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
> > space is completely useless.
>
> It should but last time I tried it complained about resource conflicts.
> I've sent BenH a log of this on request.

The kernel code `should' do that, but currently it doesn't. All it does is try
to allocate the PCI resources, as they are set up by the `bootloader' (OF,
MacOS, whatever). If they conflict, you just get a warning.

The code I posted for the LongTrail does assign missing/conflicting resources.
Please adapt it for PowerMac.

And for 2.2.x: sorry, but I don't care what you do there. In theory you should
do the same thing, but then you have to `invent' all code yourself, while in
2.3.x most is already there.

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: LongTrail PCI resource assignment

[Michael Schmitz]

> > > insists in overlapping the registers with the VRAM, the PCI code in the
> > > kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
> > > space is completely useless.
> >
> > It should but last time I tried it complained about resource conflicts.
> > I've sent BenH a log of this on request.
>
> The kernel code `should' do that, but currently it doesn't. All it does is try
> to allocate the PCI resources, as they are set up by the `bootloader' (OF,
> MacOS, whatever). If they conflict, you just get a warning.
>
> The code I posted for the LongTrail does assign missing/conflicting resources.
> Please adapt it for PowerMac.

Ok, I'll start working on this. If that gets me far enough with XFree to
show it's working, fine. I'll really need 2.2 though (USB mouse support
was broken for me in 2.3).

> And for 2.2.x: sorry, but I don't care what you do there. In theory you should
> do the same thing, but then you have to `invent' all code yourself, while in
> 2.3.x most is already there.

If the resource reassignment helps I can probably hack something like that
for 2.2.x. I wasn't asking you for a PCI resource assignment backport to
2.2 :-)
I've collected a fair share of advice on this topic, so I should get some
results now.

	Michael


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> The code I posted for the LongTrail does assign missing/conflicting resources.
> Please adapt it for PowerMac.

Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
aperture, and allows XFree86 4.0 to run on my Lombard.

	Michael

--- arch/ppc/kernel/pci.c.org	Sun Mar 26 14:08:53 2000
+++ arch/ppc/kernel/pci.c	Sun Mar 26 14:09:16 2000
@@ -231,7 +231,7 @@
 				if (!pr || request_resource(pr, r) < 0) {
 					printk(KERN_ERR "PCI: Cannot allocate resource region %d of device %s\n", idx, dev->slot_name);
 					/* We'll assign a new address later */
-					r->start -= r->end;
+					r->end -= r->start;
 					r->start = 0;
 				}
 			}


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

Re: LongTrail PCI resource assignment

[Michel Dänzer]

Michael Schmitz wrote:

> Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
> one solves my PCI address conflict for the Mach64 by reallocating the MMIO
> aperture, and allows XFree86 4.0 to run on my Lombard.

Great news! So how does it compare to 3.3.x for you?


Michel


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
> > one solves my PCI address conflict for the Mach64 by reallocating the MMIO
> > aperture, and allows XFree86 4.0 to run on my Lombard.
>
> Great news! So how does it compare to 3.3.x for you?

It feels a lot slower (15/16 bpp as fast as 32 before), 16 bpp have messed
up color (green too bright, maybe 565 is wrong after all), 32 bpp fails to
start (no screen found, weight 000 inconsistent with depth 32).

I need to figure out what the pixel format for 16 and 32 bpp really is.
Currently the X server refuses to start up if the RGB weights don't add up
to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
it's really slower than 32 bpp before. Plus the X server refuses to
cooperate with xscreensaver and consistently kicks me out after 10
minutes.

Even with not loading the more arcane extensions the X server weighs in at
21 MB (I recall 17 or so before), that might explain the slowdown a bit.
Need to work on the accelerated Mach64 driver perhaps.

	Michael


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Mon, 27 Mar 2000, Michael Schmitz wrote:
> > > Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
> > > one solves my PCI address conflict for the Mach64 by reallocating the MMIO
> > > aperture, and allows XFree86 4.0 to run on my Lombard.
> >
> > Great news! So how does it compare to 3.3.x for you?
>
> It feels a lot slower (15/16 bpp as fast as 32 before), 16 bpp have messed
> up color (green too bright, maybe 565 is wrong after all), 32 bpp fails to
> start (no screen found, weight 000 inconsistent with depth 32).

16 bpp (depth 15) is 555 on the Mach64. Feel free to add support for 565 (depth
16).

> I need to figure out what the pixel format for 16 and 32 bpp really is.
> Currently the X server refuses to start up if the RGB weights don't add up
> to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
> it's really slower than 32 bpp before. Plus the X server refuses to
> cooperate with xscreensaver and consistently kicks me out after 10
> minutes.

32 bpp (depth 24) is 888.

> Even with not loading the more arcane extensions the X server weighs in at
> 21 MB (I recall 17 or so before), that might explain the slowdown a bit.

Does it use shadowfb? And extra copy of the screen image would explain some of
the memory requirements.

BTW, you don't want to know about the resource consumption of Xsun on the
Ultra-10 at work.

> Need to work on the accelerated Mach64 driver perhaps.

YES! ;-)

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: LongTrail PCI resource assignment

[Geert Uytterhoeven]

FYI, I played some more with PCI resources on the MIPS (to be applied to my
LongTrail in the near future :-)

You can specify from which region resources are allocated by doing this

  - create a `pci mem' resource with start and end corresponding to the PCI
    memory space region that is provided by your host bridge
  - call request_resource(&iomem_resource, &my_pci_mem_resource);
  - change bus->resource[1] = &my_pci_mem_resource in your machine specific
    pcibios_fixup_bus()

After this, all resources will be allocated from the `parent' PCI mem resource,
which is my_pci_mem_resource now (by default (drivers/pci/pci.c),
bus->resource[1] points to iomem_resource).

Result for the MIPS, where _all_ resources must be assigned by calling
pci_assign_unassigned_resources() afterwards:

    root # cat /proc/iomem
 *  00000000-03ffffff : RAM
 *  04000000-043fffff : Flash ROM
 *  06000000-060fffff : Nile4 ISA I/O
 *  06100000-07ffffff : Nile4 PCI I/O
 *  08000000-08ffffff : Nile4 ISA mem
 *  09000000-0fffffff : Nile4 PCI mem
      09000000-0900007f : Digital Equipment Corporation DECchip 21140 [Fa
      09001000-09001fff : Acer Laboratories Inc. [ALi] M5237 USB
      09040000-0907ffff : Digital Equipment Corporation DECchip 21140 [Fa
 *  1fa00000-1fbfffff : Nile4 ctrl
 *  1fc00000-1fffffff : Boot ROM
    root #

All resources marked with `*' were manually requested before calling
pci_scan_bus(), but only `Nile4 PCI mem' matters here.

The example considers PCI memory space only. PCI I/O space is left as an
exercise for the reader :-)

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: LongTrail PCI resource assignment

[Michael Schmitz]

> The example considers PCI memory space only. PCI I/O space is left as an
> exercise for the reader :-)

I played a bit with PCI resource remapping in 2.2.15pre9 and I've got a
few questions, one of them dealing with PCI I/O space:

- OF reports two base addresses for the Mach64, one of which is the I/O
region (according to the PCI BAR values) at 0xc00. OF reports its address
as 0x80881000 or some such. Does this mean the I/O registers are
accessible at 0x80881000, or did OF probing get some bogus values there?

- I can successfully remap the MMIO range of the chip to some area outside
the VRAM range. XFree86 no longer barfs on the mem resource conflict
(though it still reports the I/O resource conflict with the DVD decoder),
reports the new mapping of the MMIO range, and starts up nicely. lspci -vv,
however, still reports the old range. Where's that one stored
(assuming /proc/pci somewhere), and wouldn't it make more sense to have
the PCI bus rescanned on reading /proc/pci entries?

- I picked a range to remap MMIO to more or less at random. How can I find
out what ranges are believed to be unassigned from OF data?

Too lazy to read all of the source,

	Michael


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

Re: LongTrail PCI resource assignment

[Michel Lanners]

On  30 Mar, this message from Michael Schmitz echoed through cyberspace:
> I played a bit with PCI resource remapping in 2.2.15pre9 and I've got a
> few questions, one of them dealing with PCI I/O space:
>
> - OF reports two base addresses for the Mach64, one of which is the I/O
> region (according to the PCI BAR values) at 0xc00. OF reports its address
                                              ^^^^^
Where does that address come from? I'm missing something here..

> as 0x80881000 or some such. Does this mean the I/O registers are
> accessible at 0x80881000, or did OF probing get some bogus values there?

When talking PCI IO space on PowerMacs, always keep in mind that the
host bridge adds an offset to PCI IO space, i.e. IO port 0xc00 on the
bus will have processor physical address 0xf2000c00 or something like
that. The offset might be reprogrammable, but I'd suggest _not_
changing it, as it is also the base address for config space accesses on
that bus...

> - I can successfully remap the MMIO range of the chip to some area outside
> the VRAM range. XFree86 no longer barfs on the mem resource conflict
> (though it still reports the I/O resource conflict with the DVD decoder),
> reports the new mapping of the MMIO range, and starts up nicely. lspci -vv,
> however, still reports the old range. Where's that one stored
> (assuming /proc/pci somewhere), and wouldn't it make more sense to have
> the PCI bus rescanned on reading /proc/pci entries?

If you remap the MMIO range, you need to do two things:

1. change the BAR setting, so that the device will respond to the new
address

2. change the values stored in struct pci_dev, so that the kernel at
large (that includes other drivers, and the interface used by lspci)
knows about it.

> - I picked a range to remap MMIO to more or less at random. How can I find
> out what ranges are believed to be unassigned from OF data?

There's no other way than to look up all assigned regions. However,
don't rely (only) on what OF tells you in the devide tree, as some
assigments may have been changed by PCI fixup code, and OF may have
forgotten some assigments.

Good luck!

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: LongTrail PCI resource assignment

[Michael Schmitz]

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

> > - OF reports two base addresses for the Mach64, one of which is the I/O
> > region (according to the PCI BAR values) at 0xc00. OF reports its address
>                                               ^^^^^
> Where does that address come from? I'm missing something here..

Straight from the BAR for region 1, with the resource type bits masked
off. BTW lspci also reports this.

> > as 0x80881000 or some such. Does this mean the I/O registers are
> > accessible at 0x80881000, or did OF probing get some bogus values there?
>
> When talking PCI IO space on PowerMacs, always keep in mind that the
> host bridge adds an offset to PCI IO space, i.e. IO port 0xc00 on the
> bus will have processor physical address 0xf2000c00 or something like
> that. The offset might be reprogrammable, but I'd suggest _not_
> changing it, as it is also the base address for config space accesses on
> that bus...

0xfe000000 is what pmac_pci.c uses for my machine (processor physical as
well as virtual). I'm not trying to change that, I just didn't understand
the address reported by OF for that region. I still don't understand it.

> > - I can successfully remap the MMIO range of the chip to some area outside
> > the VRAM range. XFree86 no longer barfs on the mem resource conflict
> > (though it still reports the I/O resource conflict with the DVD decoder),
> > reports the new mapping of the MMIO range, and starts up nicely. lspci -vv,
> > however, still reports the old range. Where's that one stored
> > (assuming /proc/pci somewhere), and wouldn't it make more sense to have
> > the PCI bus rescanned on reading /proc/pci entries?
>
> If you remap the MMIO range, you need to do two things:
>
> 1. change the BAR setting, so that the device will respond to the new
> address

That's been done :-)

> 2. change the values stored in struct pci_dev, so that the kernel at
> large (that includes other drivers, and the interface used by lspci)
> knows about it.

That's what I missed. I changed the value in the OF tree but forgot the
PCI side.

> > - I picked a range to remap MMIO to more or less at random. How can I find
> > out what ranges are believed to be unassigned from OF data?
>
> There's no other way than to look up all assigned regions. However,
> don't rely (only) on what OF tells you in the devide tree, as some
> assigments may have been changed by PCI fixup code, and OF may have
> forgotten some assigments.

As seen for the MMIO region :-) No thanks, I'l just use the address that
appears to be unused (right beyond the framebuffer). If someone wants to
generalize this hack, be careful. On a side note: I've not changed
ati_regbase after remapping the MMIO region, it still points to the old
location at the end of the LE aperture, and does apparently still work due
to the video RAM aperture remaining unchanged.

Patch appended (use at your own risk, works for me but I don't fully
understand why, etc.).

	Michael

[-- Attachment #2: 2.2.15 atyfb PCI remap patch --]
[-- Type: TEXT/PLAIN, Size: 5892 bytes --]

--- drivers/video/atyfb.c.org	Mon Apr  3 20:20:24 2000
+++ drivers/video/atyfb.c	Mon Apr  3 20:26:11 2000
@@ -3176,7 +3176,7 @@
     u8 bus, devfn;
     u16 cmd;
     struct fb_info_aty *info;
-    int i;
+    int i, i_frame, i_regs, naddr;
 
     if (device_is_compatible(dp, "ATY,264LTPro")) {
 	/* XXX kludge for now */
@@ -3204,6 +3204,13 @@
 	    return;
     }
 
+    printk("atyfb: of_init got %d OF adresses for ATY:\n", dp->n_addrs);
+    for (i = 0; i < dp->n_addrs; i++)
+	printk(" %08x-%08x", dp->addrs[i].address,
+	       dp->addrs[i].address+dp->addrs[i].size-1);
+    if (dp->n_addrs)
+	printk("\n");
+
     info = kmalloc(sizeof(struct fb_info_aty), GFP_ATOMIC);
     if (!info) {
 	printk("atyfb_of_init: can't alloc fb_info_aty\n");
@@ -3215,6 +3222,8 @@
     info->ati_regbase = (unsigned long)ioremap(info->ati_regbase_phys,
 						   0x1000);
 
+    printk("atyfb: regbase phys 0x%lx virt 0x%lx\n", info->ati_regbase_phys, info->ati_regbase);
+
     if(! info->ati_regbase) {
 	    printk("atyfb_init: ioremap() returned NULL\n");
 	    kfree(info);
@@ -3226,6 +3235,50 @@
 
     /* enable memory-space accesses using config-space command register */
     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;
+	    size = ~(size) + 1;
+	    
+	    if (size == 0) 
+	    	break;
+
+	    printk("atyfb: chunk %d ofbase 0x%lx breg %d io %d pbase 0x%lx size 0x%lx \n",
+		i, base, breg, io, pbase, size);
+
+	    if (!base) {
+		printk("atyfb: chunk %d assigning ofbase 0x%lx \n", i, pbase);
+		dp->addrs[i].address = pbase;
+		dp->addrs[i].size = size;
+	    }
+	    if (pbase == addr) {
+		printk("atyfb: chunk %d assigned as VRAM aperture! \n", i);
+		i_frame = i;
+	    }
+	    if (size == 0x1000) {
+		printk("atyfb: chunk %d assigned as MMIO aperture! \n", i);
+		i_regs = i;
+	    }
+
+	}
+
+	naddr = i;
+	printk("atyfb: found %d PCI addresses total. \n", i);
+
 	pcibios_read_config_word(bus, devfn, PCI_COMMAND, &cmd);
 	if (cmd != 0xffff) {
 	    cmd |= PCI_COMMAND_MEMORY;
@@ -3242,12 +3295,80 @@
     info->frame_buffer_phys = addr;
     info->frame_buffer = (unsigned long)ioremap(addr, 0x800000);
 
+    printk("atyfb: framebuffer phys 0x%lx virt 0x%lx\n", info->frame_buffer_phys, info->frame_buffer);
+
     if(! info->frame_buffer) {
 	    printk("atyfb_init: ioremap() returned NULL\n");
 	    kfree(info);
 	    return;
     }
 
+    /* 
+     * Fix MMIO mapping if MMIO and VRAM overlap 
+     * 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;
+	    size = ~(size) + 1;
+	    
+	    printk("atyfb: chunk %d ofbase 0x%lx breg %d io %d pbase 0x%lx size 0x%lx needs reassigning! \n",
+		i_regs, base, breg, io, pbase, size);
+
+	    /* move MMIO past frame buffer for now. Need to walk PCI resources to find safe place */
+	    new = (dp->addrs[i_frame].address+dp->addrs[i_frame].size) | (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;
+	    size = ~(size) + 1;
+	    
+	    printk("atyfb: chunk %d ofbase 0x%lx breg %d io %d reassigned to pbase 0x%lx size 0x%lx ! \n",
+		i_regs, base, breg, io, pbase, size);
+
+	    /* update OF device tree */
+	    dp->addrs[i_regs].address = dp->addrs[i_frame].address+dp->addrs[i_frame].size;
+    }
+
     if (!aty_init(info, dp->full_name)) {
 	kfree(info);
 	return;
@@ -3267,7 +3388,6 @@
 #endif /* CONFIG_FB_COMPAT_XPMAC */
 }
 #endif /* CONFIG_FB_OF */
-
 
 __initfunc(void atyfb_setup(char *options, int *ints))
 {

Re: LongTrail PCI resource assignment

[Michel Lanners]

Hi there,

On   3 Apr, this message from Michael Schmitz echoed through cyberspace:
>> > - OF reports two base addresses for the Mach64, one of which is the I/O
>> > region (according to the PCI BAR values) at 0xc00. OF reports its address
>>                                               ^^^^^
>> Where does that address come from? I'm missing something here..
>
> Straight from the BAR for region 1, with the resource type bits masked
> off. BTW lspci also reports this.

Ahhh... ok. In that case, it's a possible value.

>> > as 0x80881000 or some such. Does this mean the I/O registers are
>> > accessible at 0x80881000, or did OF probing get some bogus values there?

When looking at what OF assigned, always check the BAR value in OF's
properties; they are not necessarily all in the same order all the
time. Here's for example what I have on my machine for my Matrox:

[mlan@piglet /proc/device-tree/bandit/MTRX,Millennium@F]$ hexdump reg
0000000 0000 7800 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0200 7810 0000 0000 0000 0000
0000020 0000 0000 0000 4000 4200 7814 0000 0000
0000030 0000 0000 0000 0000 0080 0000
000003c
[mlan@piglet /proc/device-tree/bandit/MTRX,Millennium@F]$ hexdump assigned-addresses
0000000 c200 7814 0000 0000 8100 0000 0000 0000
0000010 0080 0000 8200 7810 0000 0000 8080 0000
0000020 0000 0000 0000 4000
0000028

The reg property has 3 entries, where the second and third represent
BARs at 0x10 and 0x14; however, assigned-addresses has these in reverse
order...

If you look at your properties, here is their meaning:

 <flags> <bus-hi> <bus-lo> <processor> <size>

All elements are 32 bits; the BAR value is in the last byte of <flags>.
You'll see that in reg, <processor> is not set; that's because reg
represents the address requests of the device before attribution.

<bus-hi> and <bus-lo> form a 64-bit PCI bus address; on 32-bit systems,
<bus-hi> is zero. assigned-addresses is what OF gave your device.

> 0xfe000000 is what pmac_pci.c uses for my machine (processor physical as
> well as virtual). I'm not trying to change that, I just didn't understand
> the address reported by OF for that region. I still don't understand it.

Can you verify your OF properties, to check whether OF _really_ assigned
a region for the IO ports at 0xc00? I doubt it...

>> If you remap the MMIO range, you need to do two things:
>>
>> 2. change the values stored in struct pci_dev, so that the kernel at
>> large (that includes other drivers, and the interface used by lspci)
>> knows about it.
>
> That's what I missed. I changed the value in the OF tree but forgot the
> PCI side.

Changing the OF device tree is nice, but probably too much hassle.
The struct pci_dev, on the other hand, is vital.

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: LongTrail PCI resource assignment

[Kostas Gewrgiou]

On Mon, 27 Mar 2000, Michael Schmitz wrote:

>
> > > Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
> > > one solves my PCI address conflict for the Mach64 by reallocating the MMIO
> > > aperture, and allows XFree86 4.0 to run on my Lombard.
> >
> > Great news! So how does it compare to 3.3.x for you?
>
> It feels a lot slower (15/16 bpp as fast as 32 before), 16 bpp have messed
> up color (green too bright, maybe 565 is wrong after all), 32 bpp fails to
> start (no screen found, weight 000 inconsistent with depth 32).
>
> I need to figure out what the pixel format for 16 and 32 bpp really is.
> Currently the X server refuses to start up if the RGB weights don't add up
> to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
> it's really slower than 32 bpp before. Plus the X server refuses to
> cooperate with xscreensaver and consistently kicks me out after 10
> minutes.
>

Without acceleration its logical to be *alot* slower than the old server
the shadowfb helps a little there (its used by default unless you disabled
it in the config)

16bpp isn't supported by atyfb, you should use 15bpp instead (the xserver
needs to be fixed to report that 16bpp isn't supported)

32bpp should have worked fine, the (no screen found, weight 000 inconsistent
with depth 32) message probably means that you tried a startx -- -depth 32
instead of the correct -fbbpp 32

> Even with not loading the more arcane extensions the X server weighs in at
> 21 MB (I recall 17 or so before), that might explain the slowdown a bit.
> Need to work on the accelerated Mach64 driver perhaps.

  My xserver weights about 74mb (it hits 100+mb with dual head) but keep in
mind that this includes the  mmaped fb/mmio areas which in my case is 64mb
so the server is using about 10mb of memory which isn't too much.
 The shadowfb module might be the cause of the memory increase in your case
i don't think that all the extra 4mb are from there though, but as i said
the slowdown is because you use a non accelerated server non because of
memory.

  Kostas


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> Without acceleration its logical to be *alot* slower than the old server
> the shadowfb helps a little there (its used by default unless you disabled
> it in the config)

So the old server was accelerating already?

> 16bpp isn't supported by atyfb, you should use 15bpp instead (the xserver
> needs to be fixed to report that 16bpp isn't supported)

I guessed as much, and Geert said 565 weight needs to be implemented
already.

> 32bpp should have worked fine, the (no screen found, weight 000 inconsistent
> with depth 32) message probably means that you tried a startx -- -depth 32
> instead of the correct -fbbpp 32

I did no such thing. I just used the DefaultDisplayDepth option in the
config file. How do I specify fbbpp in the config?

> > Even with not loading the more arcane extensions the X server weighs in at
> > 21 MB (I recall 17 or so before), that might explain the slowdown a bit.
> > Need to work on the accelerated Mach64 driver perhaps.
>
>   My xserver weights about 74mb (it hits 100+mb with dual head) but keep in
> mind that this includes the  mmaped fb/mmio areas which in my case is 64mb
> so the server is using about 10mb of memory which isn't too much.

With only 64 MB RAM (yes I was cheap but the Powerbook was expensive
enough already) it's a bit heavy on the system.

	Michael


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Mon, 27 Mar 2000, Michael Schmitz wrote:
> > Without acceleration its logical to be *alot* slower than the old server
> > the shadowfb helps a little there (its used by default unless you disabled
> > it in the config)
>
> So the old server was accelerating already?

Yes, I had ported Ryuichi Oikawa's Mach64 acceleration for Xpmac to
XF68_FBDev. It was not that much accelerated as on ia32, but the difference
with the unaccelerated server was definitely noticable. Try `option no_accel'
in XF86Config and compare. I expect unaccelerated 4.0 to be faster than
unaccelerated 3.3.x.

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: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Mon, 27 Mar 2000, Kostas Gewrgiou wrote:
> 16bpp isn't supported by atyfb, you should use 15bpp instead (the xserver
> needs to be fixed to report that 16bpp isn't supported)
>
> 32bpp should have worked fine, the (no screen found, weight 000 inconsistent
> with depth 32) message probably means that you tried a startx -- -depth 32
> instead of the correct -fbbpp 32

s/bpp/depth/

There's a difference between bpp (`bit per pixel': 8, 16, 24 or 32 are
supported by atyfb) and depth (8, 15 and 24 are supported by atyfb).

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: LongTrail PCI resource assignment

[Michael Schmitz]

> s/bpp/depth/
>
> There's a difference between bpp (`bit per pixel': 8, 16, 24 or 32 are
> supported by atyfb) and depth (8, 15 and 24 are supported by atyfb).

Imagine my confusion. What bpp will X use for depth 24 by default? Would
32 help any?

	Michael


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

Re: LongTrail PCI resource assignment

[Michel Dänzer]

Michael Schmitz wrote:

> > There's a difference between bpp (`bit per pixel': 8, 16, 24 or 32 are
> > supported by atyfb) and depth (8, 15 and 24 are supported by atyfb).
>
> Imagine my confusion.

'depth' is the number of bits used to determine the color of a pixel.

'framebuffer bpp' is the number of bits a pixel takes up in memory.


> What bpp will X use for depth 24 by default?

24.

Or then maybe it depends on the driver? Check yourself in the server output or
the log.


> Would 32 help any?

Maybe, because pixels correspond to words directly.


Michel


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

Re: LongTrail PCI resource assignment

[Michel Dänzer]

Michael Schmitz wrote:

> Currently the X server refuses to start up if the RGB weights don't add up
> to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
> it's really slower than 32 bpp before.

There's now a distinction between 'depth' and 'framebuffer bpp'. There is no
depth 32.

You can set framebuffer bpp with the -fbbpp command line option (there
certainly is an XF86Config option as well, but I don't remember it). You have
to add a Display Subsection like this:

    SubSection "Display"
        Depth       24
        fbbpp       32
        Modes       "1152x864" "1024x768" "640x480"
        Virtual     1152 864
    EndSubSection


> Plus the X server refuses to cooperate with xscreensaver and consistently
> kicks me out after 10 minutes.

Hm. Can you build a static server and try to track it down in gdb?


Michel


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Mon, 27 Mar 2000, Michael Schmitz wrote:
> > The code I posted for the LongTrail does assign missing/conflicting resources.
> > Please adapt it for PowerMac.
>
> Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
> one solves my PCI address conflict for the Mach64 by reallocating the MMIO

So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
assigned to the secondary aperture? Can you please send me the output of
`lspci -vv'? Thx!

> aperture, and allows XFree86 4.0 to run on my Lombard.

Guess I have to try 4.0 as well...

> --- arch/ppc/kernel/pci.c.org	Sun Mar 26 14:08:53 2000
> +++ arch/ppc/kernel/pci.c	Sun Mar 26 14:09:16 2000
> @@ -231,7 +231,7 @@
>  				if (!pr || request_resource(pr, r) < 0) {
>  					printk(KERN_ERR "PCI: Cannot allocate resource region %d of device %s\n", idx, dev->slot_name);
>  					/* We'll assign a new address later */
> -					r->start -= r->end;
> +					r->end -= r->start;
>  					r->start = 0;
>  				}
>  			}

I copied this buglet from arch/i386/kernel/pci-i386.c.

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: LongTrail PCI resource assignment

[Michael Schmitz]

> > Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
> > one solves my PCI address conflict for the Mach64 by reallocating the MMIO
>
> So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
> assigned to the secondary aperture? Can you please send me the output of
> `lspci -vv'? Thx!

00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
4c49 (rev dc)
	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 24
	Region 0: Memory at 81000000 (32-bit, non-prefetchable)
	Region 1: I/O ports at <unassigned>
	Region 2: Memory at 00010000 (32-bit, non-prefetchable)
	Capabilities: [5c] Power Management version 1
		Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-


> > aperture, and allows XFree86 4.0 to run on my Lombard.
>
> Guess I have to try 4.0 as well...

Does this mean you didn't compile it already? :-)

> > -					r->start -= r->end;
> > +					r->end -= r->start;
> >  					r->start = 0;
> >  				}
> >  			}
>
> I copied this buglet from arch/i386/kernel/pci-i386.c.

I noticed after reading linux-m68k - how did that thread move there?

	Michael


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Mon, 27 Mar 2000, Michael Schmitz wrote:
> > > Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
> > > one solves my PCI address conflict for the Mach64 by reallocating the MMIO
> >
> > So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
> > assigned to the secondary aperture? Can you please send me the output of
> > `lspci -vv'? Thx!
>
> 00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
> 4c49 (rev dc)
> 	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 24
> 	Region 0: Memory at 81000000 (32-bit, non-prefetchable)
> 	Region 1: I/O ports at <unassigned>
> 	Region 2: Memory at 00010000 (32-bit, non-prefetchable)
                            ^^^^^^^^
Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
valid address for PCI memory for your box. To me, it looks like PCIBIOS_MIN_MEM
must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
sure.

> > > aperture, and allows XFree86 4.0 to run on my Lombard.
> >
> > Guess I have to try 4.0 as well...
>
> Does this mean you didn't compile it already? :-)

Indeed. For now, I intend to go with Jack's RPMs...

> I noticed after reading linux-m68k - how did that thread move there?

That's my fault: I really should make the aliases for the Linux/m68k list and
for my personal email less similar. Or perhaps I should switch to a
GUI-based mail client, where I can just click click click click on adresses :-)
Nah, that would lower my productivity.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > 00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
> > 4c49 (rev dc)
> > 	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 24
> > 	Region 0: Memory at 81000000 (32-bit, non-prefetchable)
> > 	Region 1: I/O ports at <unassigned>
> > 	Region 2: Memory at 00010000 (32-bit, non-prefetchable)
>                             ^^^^^^^^
> Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
> valid address for PCI memory for your box. To me, it looks like PCIBIOS_MIN_MEM
> must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
> sure.

Well, all I know is that it works.

And this is my PCIBIOS_MIN_MEM:

include/asm/pci.h:#define PCIBIOS_MIN_MEM		0x10000000

Seems it got ignored and the resource allocator picked the next free spot.

	Michael


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Mon, 27 Mar 2000, Michael Schmitz wrote:
> > > 00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
> > > 4c49 (rev dc)
> > > 	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 24
> > > 	Region 0: Memory at 81000000 (32-bit, non-prefetchable)
> > > 	Region 1: I/O ports at <unassigned>
> > > 	Region 2: Memory at 00010000 (32-bit, non-prefetchable)
> >                             ^^^^^^^^
> > Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
> > valid address for PCI memory for your box. To me, it looks like PCIBIOS_MIN_MEM
> > must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
> > sure.
>
> Well, all I know is that it works.

Ever tried writing to it? :-) For your own safety, please don't! But you can
try reading the CHIP_ID register.

> And this is my PCIBIOS_MIN_MEM:
>
> include/asm/pci.h:#define PCIBIOS_MIN_MEM		0x10000000
>
> Seems it got ignored and the resource allocator picked the next free spot.

Weird, mine got assigned to 0xc0000000, which is what I expect.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


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

Re: LongTrail PCI resource assignment

[Michael Schmitz]

> > Well, all I know is that it works.
>
> Ever tried writing to it? :-) For your own safety, please don't! But you can
> try reading the CHIP_ID register.

I should still have code around to do that, in the atyfb driver. Anyway,
this is what I found in arch/ppc/kernel/pci.c:

int pci_assign_resource(struct pci_dev *dev, int i)
{
	struct resource *r = &dev->resource[i];
	struct resource *pr = pci_find_parent_resource(dev, r);
	unsigned long size = r->end + 1;
	u32 new, check;

	if (!pr) {
	 	printk(KERN_ERR "PCI: Cannot find parent resource for device %s\n", dev->slot_name);
	 	return -EINVAL;
	}
	if (r->flags & IORESOURCE_IO) {
	        if (allocate_resource(pr, r, size, 0x100, ~0, size, NULL, NULL)) {
	         	printk(KERN_ERR "PCI: Allocation of I/O region %s/%d (%ld bytes) failed\n", de
	         	return -EBUSY;
	        }
	} else {
	 	if (allocate_resource(pr, r, size, 0x10000, ~0, size, NULL, NULL)) {
	 	 	printk(KERN_ERR "PCI: Allocation of memory region %s/%d (%ld bytes) failed\n",
	 	 	return -EBUSY;
	 	}
	}

See the 0x10000 above? Exactly what I get.

pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
where the correct PCIBIOS_MIN_* limits are applied. That function calls
pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
dated for your patch to apply?

> > And this is my PCIBIOS_MIN_MEM:
> >
> > include/asm/pci.h:#define PCIBIOS_MIN_MEM		0x10000000
> >
> > Seems it got ignored and the resource allocator picked the next free spot.
>
> Weird, mine got assigned to 0xc0000000, which is what I expect.

Seems pci_assign_resource is no longer in the arch/ppc/kernel section in
your source. Or your linker picks up the other one.

	Michael


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

Re: LongTrail PCI resource assignment

[Michel Lanners]

On  27 Mar, this message from Michael Schmitz echoed through cyberspace:
> Anyway,
> this is what I found in arch/ppc/kernel/pci.c:
>
> int pci_assign_resource(struct pci_dev *dev, int i)
> {
[snip]
> 	}
>
> pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
> where the correct PCIBIOS_MIN_* limits are applied. That function calls
> pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
> dated for your patch to apply?

Yeah; you might consider moving to 2.3.99.... pci_assign_resource() is
gone from arch/ppc/kernel/pci.c.

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: LongTrail PCI resource assignment

[Michael Schmitz]

> > pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
> > where the correct PCIBIOS_MIN_* limits are applied. That function calls
> > pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
> > dated for your patch to apply?
>
> Yeah; you might consider moving to 2.3.99.... pci_assign_resource() is
> gone from arch/ppc/kernel/pci.c.

Wasn't 2.3.99 the one with broken IDE interface as someone reported here?
I can do without that sort of fun, thank you :-) I'll move back to 2.2.15
now.

	Michael


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

Re: LongTrail PCI resource assignment

[Michel Lanners]

On  27 Mar, this message from Michael Schmitz echoed through cyberspace:
>> > pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
>> > where the correct PCIBIOS_MIN_* limits are applied. That function calls
>> > pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
>> > dated for your patch to apply?
>>
>> Yeah; you might consider moving to 2.3.99.... pci_assign_resource() is
>> gone from arch/ppc/kernel/pci.c.
>
> Wasn't 2.3.99 the one with broken IDE interface as someone reported here?
> I can do without that sort of fun, thank you :-) I'll move back to 2.2.15
> now.

IDE is working fine in my 2.3.99... but it's a Promise, not PowerMac
integrated IDE.

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: LongTrail PCI resource assignment

[Michel Lanners]

On  27 Mar, this message from Geert Uytterhoeven echoed through cyberspace:
> On Mon, 27 Mar 2000, Michael Schmitz wrote:
>> > > Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
>> > > one solves my PCI address conflict for the Mach64 by reallocating the MMIO
>> >
>> > So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
>> > assigned to the secondary aperture? Can you please send me the output of
>> > `lspci -vv'? Thx!
>>
>> 00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
>> 4c49 (rev dc)
>> 	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 24
>> 	Region 0: Memory at 81000000 (32-bit, non-prefetchable)
>> 	Region 1: I/O ports at <unassigned>
>> 	Region 2: Memory at 00010000 (32-bit, non-prefetchable)
>                             ^^^^^^^^
> Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
> valid address for PCI memory for your box.

IIRC, physical RAM is mapped starting at 0x0.... with host bridges
being transparent for mem accesses that would mean your memory region is
in the midst of RAM... funny, no?

> To me, it looks like PCIBIOS_MIN_MEM
> must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
> sure.

On my machine, yes, OF starts mapping mem resources at 0x80000000; but I
can't remember reading explicitly what the memory map is on PowerMacs.

Ben?

Cheers

Michel

PS I just checked in OF's device tree; each host bridge has an assigned
range for memory resources; for bus 0, its: 0x80000000 - 0x8fffffff.

Which means we should probably implement 'corrected' mem resources per
bus like I did with IO resources.

-------------------------------------------------------------------------
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: LongTrail PCI resource assignment

[Michel Dänzer]

Gabriel Paubert wrote:

> > But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
> > 0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.
>
> Then X needs to be fixed, perhaps the generic X PCI code needs special
> hooks for individual drivers to check whether the configuration is
> acceptable or not.

Sounds a bit drastic to correct a small, isolated problem like this.


> OTOH I don't understand why something there (OF ?) insists in overlapping
> the registers with the VRAM, the PCI code in the kernel (2.3) should give
> the registers a separate area, saving 4kB of MMIO space is completely
> useless.

Right. If it is fixed more reasonably and easily in the kernel, why should it
be worked around in X?


Michel


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

Re: LongTrail PCI resource assignment

[Geert Uytterhoeven]

On Fri, 24 Mar 2000, Michael Schmitz wrote:
> > > So it's perfectly legal for resources within the same device to overlap?
> > > WTF does X not tolerate this and disables the overlapping one?
> >
> > It may be legal if the internal decoders are prioritized and the priority
> > is the right one (which it should if the firmware has set it up this way).
>
> They are prioritized the right way: if you memset the whole aperture to 0
> the chip freaks out instead of just painting the whole screen black. Been
> there, done that.

Aha, now I know why I had to remove the last 4K. You had overlapping regions!
Which means my patch was not really necessary, since it worked around the real
problem instead of fixing it.

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: LongTrail PCI resource assignment

[Michael Schmitz]

> > They are prioritized the right way: if you memset the whole aperture to 0
> > the chip freaks out instead of just painting the whole screen black. Been
> > there, done that.
>
> Aha, now I know why I had to remove the last 4K. You had overlapping regions!
> Which means my patch was not really necessary, since it worked around the real
> problem instead of fixing it.

Indeed :-) At least that's how I see it. At that time I had no idea that
the overlap would get to be a real problem ...

	Michael

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

Re: LongTrail PCI resource assignment

[Michel Lanners]

On  24 Mar, this message from Michael Schmitz echoed through cyberspace:
>
>> >Another advantage of no longer using the information from the OF tree is that
>> >we can just call pci_assign_unassigned_resources() and get everything
>> >reassigned, without worrying about inconsistencies with the OF device tree.
>> >
>> >BTW, if you do want to keep the OF device tree consistent,
>> >pcibios_update_resource() is the place to do this.
>>
>> If this is called _after_ we have done the bus re-numbering, updating the
>> OF tree will be difficult since we need the old bus number to match the
>> PCI device with it's OF entry.
>
> On a somewhat related issue (the PCI mapping funnies for the Lombard and
> possibly other Rage Pro devices): what are the penalties if I 'correct'
> the PCI mapping for the Rage Pro within atyfb_of_init?

A good advice: don't do it ;-). If OF does something wrong with the ATI
device, then fix it in arch-specific PCI fixup code, so that all other
code using that device can be left untouched.

Put the special code in the special places, so that the general code
only needs to care for the general case ;-)

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: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Fri, Mar 24, 2000, Timothy A. Seufert <tas@mindspring.com> wrote:


>1. Duplication of information across multiple data structures is
>evil.  It should be avoided at all costs.
>
>If there was a really, really good reason to keep OF up to date
>(like, say, if we could break back into the OF console like you can
>on Sparcs), then it would be OK.  Otherwise it is most likely
>unnecessary bloat, and leads to potential confusion (and bugs).  Is
>there any such reason on ppc?

The OF tree is still used by devices inside the mac-io chip. But in this
case, the PCI bus number is not used. There are a few places where we
need to find the OF entry for a PCI device in order to read some
properties left by MacOS/OF. This is done at startup to read the
interrupt tree (but this can be done before the fixup). I don't have
other specific cases in mind, but there is at least one thing for which
we need a valid OF tree: to be able to get an OF path from a device in
order to configure the OF bootloader.
This is not used currently since we still need some more kernel support
that I didn't implement yet, but this will definitely be needed if we
want a  way to configure yaboot and OF automatically from Linux without
having to type the full OF path to the boot device.

>2. Most arch types obviously don't have an OF tree at all.
>Presumably they just do everything with the pci_dev list.  Therefore,
>ppc should too -- it's a bad idea to be different in an unnecessary
>way.

Well, If it was only for me, I would have craped PCI probing in favor of
a device-tree only operations ;) But that's not the point. I agree that
to be consistent with other archs and to have portable drivers, we must
rely on PCI probing alone whenever possible.
There are cases where we don't have choice:

 - We need some infos from the device tree to identify machine models

 - The interrupt-tree is interleaved in the device tree, so we need it to
   configure the PIC.

 - We need the device tree to probe ASIC cells inside the various
incarnations of
   Apple ASICs. This is currently the way we probe for devices like the PMU,
   Cuda, AWACS, MESH, OpenPIC, etc... Those drivers also use the tree in
order to get some
   infos like the presence of an ADB bus, etc...

 - We retreive the eth. HW address from the tree


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

Re: LongTrail PCI resource assignment

[Michel Lanners]

On  24 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>1. Duplication of information across multiple data structures is
>>evil.  It should be avoided at all costs.
>>
>>If there was a really, really good reason to keep OF up to date
>>(like, say, if we could break back into the OF console like you can
>>on Sparcs), then it would be OK.  Otherwise it is most likely
>>unnecessary bloat, and leads to potential confusion (and bugs).  Is
>>there any such reason on ppc?
>
> The OF tree is still used by devices inside the mac-io chip. But in this
> case, the PCI bus number is not used. There are a few places where we
> need to find the OF entry for a PCI device in order to read some
> properties left by MacOS/OF. This is done at startup to read the
> interrupt tree (but this can be done before the fixup). I don't have
> other specific cases in mind, but there is at least one thing for which
> we need a valid OF tree: to be able to get an OF path from a device in
> order to configure the OF bootloader.

How about integrating the OF tree's data into struct pci_dev's void *sysdata?
That would provide the missing link between OF tree and pci_dev list,
that otherwise forces you to keep both in sync. I'd think about
something like 'all data must taken from PCI dev, except whenn only
available in OF', so that you can safely leave bogus stuff in the OF
device tree.

>>2. Most arch types obviously don't have an OF tree at all.
>>Presumably they just do everything with the pci_dev list.  Therefore,
>>ppc should too -- it's a bad idea to be different in an unnecessary
>>way.
>
> There are cases where we don't have choice:
>
>  - We need some infos from the device tree to identify machine models
>
>  - The interrupt-tree is interleaved in the device tree, so we need it to
>    configure the PIC.
>
>  - We need the device tree to probe ASIC cells inside the various
> incarnations of
>    Apple ASICs. This is currently the way we probe for devices like the PMU,
>    Cuda, AWACS, MESH, OpenPIC, etc... Those drivers also use the tree in
> order to get some
>    infos like the presence of an ADB bus, etc...
>
>  - We retreive the eth. HW address from the tree

All of the above would be left intact in the OF device refenced by
dev->sysdata.

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: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Fri, Mar 24, 2000, Timothy A. Seufert <tas@mindspring.com> wrote:

>If there was a really, really good reason to keep OF up to date
>(like, say, if we could break back into the OF console like you can
>on Sparcs), then it would be OK.  Otherwise it is most likely
>unnecessary bloat, and leads to potential confusion (and bugs).  Is
>there any such reason on ppc?

After thinking a bit more about this, I beleive we could simply add a
property to the nodes of cards for which we change the bus number,
indicating the new linux pci dev infos. The way, we keep the "reg"
property intact (it may be useful for rebuilding OF path).


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

Re: LongTrail PCI resource assignment

[Michel Lanners]

On  24 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
>
> On Fri, Mar 24, 2000, Timothy A. Seufert <tas@mindspring.com> wrote:
>
>>If there was a really, really good reason to keep OF up to date
>>(like, say, if we could break back into the OF console like you can
>>on Sparcs), then it would be OK.  Otherwise it is most likely
>>unnecessary bloat, and leads to potential confusion (and bugs).  Is
>>there any such reason on ppc?
>
> After thinking a bit more about this, I beleive we could simply add a
> property to the nodes of cards for which we change the bus number,
> indicating the new linux pci dev infos. The way, we keep the "reg"
> property intact (it may be useful for rebuilding OF path).

Good idea. Fits what I said before about special code ;-)

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: LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Wed, Mar 22, 2000, Michel Lanners <mlan@mcp.cpu.lu> wrote:


>Can't we replace this with a seed to the resource tree, defined per host
>bridge
>in arch-specific code? On PowerMacs, there's a function that scans for known
>host bridges; that code could (either dynamically or based on hardcoded
>knowledge) put the available IO window into some resource of the host bridge
>pci_dev struct. The tree of IO resources could then be built from there.

Note that in the Uni-N case, all 3 sub-busses have the same bus number
(0). There's apparenty no dev_fn conflicts between the devices on the
various nodes (but each sub node does _not_ have a specific range of
dev_fn, they are somewhat mixed).

For config accesses, we can still rely on my current hack which does a
reverse lookup of the PCI device in the OF device-tree, walks up the tree
to find on which Uni-N entry it is attached, and use the proper config
access registers (all not-found devices are routed to the external PCI,
just in case).

Ben.


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