Re: pci_mapreg_map and BAR from `Bus space tutorial'

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Guessing should not be relevant; how BARs work is part of the PCI
>> definition.
> What I was meaning is that it seems counterintuitive that a single 32
> bit register can at the same time specify a 32 bit physical memory
> address and a memory region extent.

Yes.  It is clever - but I wish the PCI designers had chosen a bit less
cleverness.

> In the example of the output of `pcictl' for my test device, this is
> exactly the case: only 1 non-zero BAR,

> Base address register at 0x10
>   type: 32-bit nonprefetchable memory
>   base: 0x10110000

> I am stuck in trying to interpret this value, and to use it both for
> an address and a range.

You can't.  If you have read-only access to the BAR - which is what
pcictl gives you - then all you can get is the base address.  You need
read/write access to get the range as well.  (In case you haven't yet
seen the trick: you read the value and save it, then you write all-1s
and read it back, to see which bits are read-only, then you write back
the value you saved.  Yes, this implies that the size of the range is
always a power of two.  As I said, clever, but I wish they'd kept their
cleverness a bit more in check.)

> Yes, this may change according to the architecture.  Here it's not
> x86.  If you remember some source, or documentation, I would check it
> out.

I don't.  I have never worked with a cobalt and I don't know whether
there is a de-facto standard for how MIPS interfaces to PCI.

> This makes me wonder if the tutorial is correct and why.

> The main fact here (at least, for a beginner) is that it's extremely
> difficult to make multiple attempts, check and verify, as you would
> with a normal C program (print something, do anything useful to let
> you know how it works).

Can't you print things?  I've done that often enough with kernel code.
If -current has broken "printf from the driver" debugging, I'd call
that a crippling regression.

> Here, for example, I wonder what (in detail) makes pci_mapreg_map
> fail, what kind of space actually needs the PCI test device: in other
> words, some more information about this mapping.

You could always do something like

(in your driver's .c file)

extern int mapreg_debug;

..._attach(...)
{
	...
	mapreg_debug = 1;
	... pci_mapreg_map(...) ...
	mapreg_debug = 0;
	...
}

(in the implementation of pci_mapreg_map)

int mapreg_debug = 0;
	...
	if (mapreg_debug) printf("...", ...);

It's a horrible thing to do for "permanent" (production) code, but I
see nothing at all wrong with it for experimental debugging.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B