pci config cycles on VRC-5477

pci config cycles on VRC-5477

[Gerald Champagne]

I'm studying the VRC-5477 code and I'm trying to understand how pci config
cycles can work reliably with the current code.  It looks like the pci
config code must execute with interrupts disabled, but I can't find code
that disables interrupts.  Can someone offer a few pointers?  Here's why
I ask...

All pci io, memory, and config accesses on the 5477 are performed through
two windows in the cpu address space.  Normally these two windows are configured
to perform pci memory and io accesses, and any driver can access pci io and
memory at any time.  In order to perform a pci config access, one of the two
windows must be remapped to perform pci config cycles.  The code in
read_config_dword() looks something like this:

- Call ddb_access_config_base() to reconfigure the window into pci memory space
   to access pci config space instead.

- Read from pci config space by reading from an offset into the window.

- Call ddb_close_config_base to restore the registers to the original values.

It looks like anything can interrupt this an try to perform a pci memory
access while the window is programmed to perfom config cycles.

Did I miss something, or is this a bug?

Thanks.

Gerald

Re: pci config cycles on VRC-5477

[Jun Sun]

Gerald Champagne wrote:

> 
> I'm studying the VRC-5477 code and I'm trying to understand how pci config
> cycles can work reliably with the current code.  It looks like the pci
> config code must execute with interrupts disabled, but I can't find code
> that disables interrupts.  Can someone offer a few pointers?  Here's why
> I ask...
> 
> All pci io, memory, and config accesses on the 5477 are performed through
> two windows in the cpu address space.  Normally these two windows are 
> configured
> to perform pci memory and io accesses, and any driver can access pci io and
> memory at any time.  In order to perform a pci config access, one of the 
> two
> windows must be remapped to perform pci config cycles.  The code in
> read_config_dword() looks something like this:
> 
> - Call ddb_access_config_base() to reconfigure the window into pci 
> memory space
>   to access pci config space instead.
> 
> - Read from pci config space by reading from an offset into the window.
> 
> - Call ddb_close_config_base to restore the registers to the original 
> values.
> 
> It looks like anything can interrupt this an try to perform a pci memory
> access while the window is programmed to perfom config cycles.
> 
> Did I miss something, or is this a bug?
> 


Your understanding is correct.  I think this is a bug.

Do you actually see the bug happening?  So far it has never hit me, but maybe 
due to the drivers that are loaded on my configuration.

Jun

Re: pci config cycles on VRC-5477

[Gerald Champagne]

> Your understanding is correct.  I think this is a bug.
> 
> Do you actually see the bug happening?  So far it has never hit me, but 
> maybe due to the drivers that are loaded on my configuration.
> 
> Jun

No, I don't actually see it.  It's not a big window, and pci config
cycles don't occur very often.  I found it while learning the device.

I checked the ddb5476 and ddb5074 dirctories, and it looks like they
have the same problem.

It's a shame that the devices have only two windows into pci space when
having three windows would be much simpler...

Thanks for the response.

Gerald

Re: pci config cycles on VRC-5477

[Geert Uytterhoeven]

On Mon, 11 Mar 2002, Jun Sun wrote:
> Gerald Champagne wrote:
> > I'm studying the VRC-5477 code and I'm trying to understand how pci config
> > cycles can work reliably with the current code.  It looks like the pci
> > config code must execute with interrupts disabled, but I can't find code
> > that disables interrupts.  Can someone offer a few pointers?  Here's why
> > I ask...
> > 
> > All pci io, memory, and config accesses on the 5477 are performed through
> > two windows in the cpu address space.  Normally these two windows are 
> > configured
> > to perform pci memory and io accesses, and any driver can access pci io and
> > memory at any time.  In order to perform a pci config access, one of the 
> > two
> > windows must be remapped to perform pci config cycles.  The code in
> > read_config_dword() looks something like this:
> > 
> > - Call ddb_access_config_base() to reconfigure the window into pci 
> > memory space
> >   to access pci config space instead.
> > 
> > - Read from pci config space by reading from an offset into the window.
> > 
> > - Call ddb_close_config_base to restore the registers to the original 
> > values.
> > 
> > It looks like anything can interrupt this an try to perform a pci memory
> > access while the window is programmed to perfom config cycles.
> > 
> > Did I miss something, or is this a bug?
> 
> Your understanding is correct.  I think this is a bug.
> 
> Do you actually see the bug happening?  So far it has never hit me, but maybe 
> due to the drivers that are loaded on my configuration.

(IIRC) When I wrote the Vrc-5074 support, I thought about this as well.
But then I noticed that this was already done by the upper PCI layer. Is this
still true?

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

Re: pci config cycles on VRC-5477

[Gerald Champagne]

>>>
>>>Did I miss something, or is this a bug?
>>>
>>Your understanding is correct.  I think this is a bug.
>>
>>Do you actually see the bug happening?  So far it has never hit me, but maybe 
>>due to the drivers that are loaded on my configuration.
>>
> 
> (IIRC) When I wrote the Vrc-5074 support, I thought about this as well.
> But then I noticed that this was already done by the upper PCI layer. Is this
> still true?
> 
> Gr{oetje,eeting}s,
> 
> 						Geert

You're right.  It's not a problem.  The code that disables interrupts right
here in drivers/pci/pci.c:

#define PCI_OP(rw,size,type) \
int pci_##rw##_config_##size (struct pci_dev *dev, int pos, type value) \
{                                                                       \
         int res;                                                        \
         unsigned long flags;                                            \
         if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;       \
         spin_lock_irqsave(&pci_lock, flags);                            \
         res = dev->bus->ops->rw##_##size(dev, pos, value);              \
         spin_unlock_irqrestore(&pci_lock, flags);                       \
         return res;                                                     \
}

I don't know why I missed that...

Thanks for the reply!

Gerald