Re: pci_mapreg_map and BAR from `Bus space tutorial'

[Rocky Hotas <rockyhotas%firemail.cc@localhost>]

On giu 10  7:05, Mouse wrote:

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

Oh, got it. I checked some more documentation and tried the procedure
you mentioned. It works as expected: for example, my WiFi card ral0
requires a 2^16 bytes range, in its only active BAR. Great!

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

NP. But if you know some source of documentation about x86 or some other
architectures, it is useful as well.

> 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.
[...]
> You could always do something like
> 
> (in your driver's .c file)
[...] 
> (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.

Thank you so much! I am not sure now to have figured it out correctly,
but I can try. Does this have any relation with setting pci_conf_debug
to 1 in `src/sys/dev/pci/pciconf.c', which was suggested in another
reply?

Rocky