On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote:
>>
>> On Thursday, September 01, 2005 12:32 PM Andrew Morton wrote:
>> > So what is the alternative to Shaohua's fix? Restore all the msi
>> > registers on resume?
>>
>> Yes, the PCIe port bus driver, for example, did that.
>>
> So you're saying that each individual driver which uses MSI is
responsible
> for the restore?
Yes.
> Is it not possible to do this in some single centralized place?
Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64 bytes
of PCI header. One solution is to extend these APIs to cover up to 256
bytes. What do you think?
Thanks,
Tom
On Thu, Sep 01, 2005 at 01:59:32PM -0700, Nguyen, Tom L wrote:
> On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote:
> >>
> >> On Thursday, September 01, 2005 12:32 PM Andrew Morton wrote:
> >> > So what is the alternative to Shaohua's fix? Restore all the msi
> >> > registers on resume?
> >>
> >> Yes, the PCIe port bus driver, for example, did that.
> >>
>
> > So you're saying that each individual driver which uses MSI is
> responsible
> > for the restore?
> Yes.
>
> > Is it not possible to do this in some single centralized place?
> Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64 bytes
> of PCI header. One solution is to extend these APIs to cover up to 256
> bytes. What do you think?
Will that solve this issue? I need to dig up my PCI spec to see if that
will still work properly on older pci devices...
thanks,
greg k-h
On Thu, Sep 01, 2005 at 01:59:32PM -0700, Nguyen, Tom L wrote:
> On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote:
> > Is it not possible to do this in some single centralized place?
> Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64 bytes
> of PCI header. One solution is to extend these APIs to cover up to 256
> bytes. What do you think?
>
No, we can't have these generic functions blindly save/restore
device specific parts of the config space (offset 64+). I know
of several chipset devices which have read-clear or write-clear
bits where reading/writing would have bad side effects. If at
all the pci core does this, it needs to explicitly walk the
capability list and save/restore the well known capability
registers only.
Rajesh
Rajesh Shah <[email protected]> wrote:
>
> On Thu, Sep 01, 2005 at 01:59:32PM -0700, Nguyen, Tom L wrote:
> > On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote:
> > > Is it not possible to do this in some single centralized place?
> > Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64 bytes
> > of PCI header. One solution is to extend these APIs to cover up to 256
> > bytes. What do you think?
> >
> No, we can't have these generic functions blindly save/restore
> device specific parts of the config space (offset 64+). I know
> of several chipset devices which have read-clear or write-clear
> bits where reading/writing would have bad side effects. If at
> all the pci core does this, it needs to explicitly walk the
> capability list and save/restore the well known capability
> registers only.
>
OK, thanks. I'll drop Shaohua's
reconfigure-msi-registers-after-resume.patch while this gets sorted out.