Re: [RFC, PATCH] sysdev suspend/resume order?

[Nathan Bryant <nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>]

Nathan Bryant wrote:
> Pallipadi, Venkatesh wrote:
> 
>>  
>> Problem:
>> Most of the sysdev_register calls in various devices
>> are being done using device_initcalls. This method of initialization 
>> has a side-effect, as we loose the ordering requirements for various 
>> resume calls. Order in which _resume() functions gets called during a 
>> resume, just depends on the order device_initcalls were called on 
>> these devices.
>>
>> Shaohua's mail below describes one issue that is a result of this 
>> problem, where in pci link device get initialized before PIC. There 
>> can be more issues like this.
> 
> 
> Actually, the PCI links are initialized from a subsys_initcall, which is 
> not to be confused with a device_initcall, and anyway the PCI links 
> don't have their own suspend/resume callbacks unless you're using a 
> specific patch that I posted.

Ok, I take that back. Looks like my patch was merged to mainline. Well I 
suppose I can help restructure that. As I mentioned a week or two ago in 
a separate thread, I think it may be a good idea to control these 
init-order issues by combining these IRQrouting-related sys_device 
drivers into a single logical driver, then you handle the ordering 
issues within the driver. I'd like to get some feedback on that idea. If 
Shaohua can tell me precisely what order he wants to see, that would help.

> 
> Maybe the problem you guys are thinking of has to do with PIC/APIC and 
> PIT resume order?
> 
>>
>> One solution to this problem:
>> Call the sysdev_registers during the actual device initialization. 
>> Say, i8259 sysdev_register should be called when i8259 device is 
>> getting registered and not with a device_initcall 'sometime' later.
>>
>> With this, we will be able to save the original device initialization 
>> order (bootup order), and call the resume methods in the same order.
>>
>> Attached are the couple of sample patches that does this in particular 
>> files.
>>
>> Questions:
>> Is this solution proper?
> 
> 
> I think that's dubious. Haven't looked at your patch yet, but... if you 
> call sysdev_register from with an ACPI subsys_initcall you will run into 
> some sort of data structure corruption and your kernel will fail to boot.
> 
> Also, some of the devices you refer to are initialized from 
> subsys_initcall's anyway, and I assume that the order of those is also 
> somewhat undefined.
> 
>> Is there any better solution to this problem? Say introducing some 
>> sort of levels in device_initcall.
>> If the above soultion is proper, is it practical/feasible to audit all 
>> usages of sysdev_register() and try to move it to the device 
>> initialization function?
>>
>> Thanks,
>> Venki
>>
>>
>>> -----Original Message-----
>>> From: Pallipadi, Venkatesh Sent: Friday, August 13, 2004 11:58 AM
>>> To: Li, Shaohua; 'Patrick Mochel'
>>> Cc: 'acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org'; Brown, Len
>>> Subject: RE: sysdev suspend/resume order?
>>>
>>>
>>>
>>> I think, there should be a relation between the order
>>> in which actual device initialization happens during the boot time 
>>> and the order in which device initcalls are called (at boot time).
>>>
>>> In this example, actual PIC initialization happens before pci_link 
>>> device initialization. So, device initcall should have a similar 
>>> ordering. That will take care of this after S3 ordering in a natural 
>>> manner.
>>>
>>> Thanks,
>>> Venki
>>>
>>>> -----Original Message-----
>>>> From: Li, Shaohua Sent: Friday, August 13, 2004 12:37 AM
>>>> To: Patrick Mochel
>>>> Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Brown, Len; Pallipadi, Venkatesh
>>>> Subject: sysdev suspend/resume order?
>>>>
>>>> Patrick,
>>>> My sound card dies after S3 sometimes. Basically, if it dies depends 
>>>> on the order of sysdev's resume. If IRQ router resume before PIC (I 
>>>> use a tricky method to change order. It's changing the initcall 
>>>> level of the sysfs initialization for the device), the sound card 
>>>> die. Otherwise, it works. Is it possible that we add some levels for 
>>>> sysdev? I'd like some sysdevs resume before other sysdevs. Does this 
>>>> make sense?
>>>> Thanks,
>>>> Shaohua
>>>>
>>>
> 
> 



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285