[PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems

[Bjorn Helgaas]

On Thu, Feb 14, 2013 at 10:06 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:

>> > +       case PCI_PREF_LIMIT_UPPER32:
>> > +               bridge->preflimitupper = value;
>> > +               break;
>>
>> You're relying on a subsequent PCI_COMMAND write to set PCI_COMMAND_IO
>> and/or PCI_COMMAND_MEMORY, and you program the bridge windows at that
>> time.
>
> Correct.
>
>>  It might be a good idea if the PCI core did clear those bits
>> while updating the windows, but I'm not sure we do.  In any case,
>> delaying the update is a difference from a standard P2P bridge that
>> could cause issues later.
>
> When would you want the window assignment to occur? Directly when the
> registers containing the base/limit are being written to? There are
> multiple registers for base/limit, so I'll have to figure out a way to
> validate when the base/limit informations are valid.

For a standard bridge, the window change occurs immediately upon
writing the base/limit, so that would be the best time.

Here's the scenario I have in mind: We have a bridge X leading to
several devices A and B.  Drivers are bound to A and B, and they are
operating.  A hotplug event requires us to expand or shrink one of X's
windows, but the new window is still sufficient to operate A and B.
The question is how we do the window update.  If we turn off
PCI_COMMAND_MEMORY for the update, then we have to coordinate with the
drivers for A and B.  But I think it is possible to do some updates
safely even with the window decoding enabled, without any effect on A
and B, and these are the ones that would cause trouble with your
current scheme.

I don't think the PCI core does any updates like this today, but it's
something we might like to do in the future.

Bjorn