Re: [ECOS] PCI Address Mapping

[Hugo Tyson <hmt at redhat dot com>]

"Robert Cragie" <rcc@jennic.com> writes:
> > One important point to make, however, is that device drivers should
> > not use malloc(). If you look at the i82559 you will see that it has a
> > memory region reserved for it in the .ldi file and uses that for
> > allocating buffers.
> 
> As the earlier correspondent noticed, all of __pci_window is used by the
> i82559 driver, and the allocator for this window is wholly contained inside

It only uses an allocator to make it easy to create pointers to memory of
arbitrary size and vary the number of buffers and so on.  The allocator
does { pointer q = p; p+= size; return q; } and little else besides error
checking.  Free is not supported.  It really just encapsulates the fact
that we don't know the base address of the window until runtime; little
else.

If you change the number of buffers you can confidently know that it'll
only use half of that amount.  Actually, if you only have one i82559
device, it'll only use half of that Mb anyway.  The only interest the
allocator has in the "top" of that heap is for error checking.  The
allocation is not dynamic in any real sense at all; it always results in
the same set of pointers.

> the driver. What is the preferred method of adding another section? Can this

Make the driver use less.  You can then statically know that the upper 1/2
Mbyte is available for your additional device, and it can do whatever it
likes in that space.  It can collect the symbols for its base address and
so on in the same way as the 82559 does - but starting 1/2 Mb up from
there.

Just do it statically, is what I'm getting at.  We keep having this
discussion where people want a heap or malloc for managing the PCI window
but I can see no need to do it at runtime at all.  A table that lays out
how the window can be used by the various different possible devices is all
that's needed.

Yes, a human would need to maintain that table as part of maintaining the
particular platform, as and when new devices that share the window are
added.

Where this fails: OK, if you can plug in any 2 of 3 devices, and each needs
0.5 Mb laid out in its own sweet way, all taken from 1Mb, so you have to
free a device's memory when its card is unplugged, *then* you need a real
heap, and very differently written device drivers.

But mostly I think the situation is more like this: there can be zero, one
or two i82559s present.  There might also be a NEWTHING and maybe
ANOTHERTHING.  So just decide to give 0-512k to the i82559s, 512k-768k to
NEWTHING and 768k-1024k to ANOTHERTHING.  If they're not plugged in, no big
deal - there's nothing to be gained by doing those allocations at runtime
so that all the used RAM is abutted in the bottom of the window.

Of course, of you add a further possible device to that platform, then that
set of numbers needs revision, by a human.  Ideally an extension to CDL
would let us handle all of this at build time though.


Important: Please DO NOT take this as Red Hat eCos team policy; it's a
topic for discussion, and this message discusses a different way of
thinking about it from what most people seem to assume is the only way -
that's why I sent it.

	- Huge