At 10:44 AM 7/12/2005 -0400, John Baldwin wrote: >Now, when ACPI is enabled, the >pnpmss driver doesn't probe the device IIRC? Both the mss_probe and pnpmss_probe routine are called in the ACPI case and in the ACPI disabled case. Let me help by providing proof from some edited short form commented dmesg excerpts from upstream postings using unmodified-except-for-debug-writes mss.c: In the case ACPI is enabled, you get: ... atpic: Programming IRQ9 as level/low mss_probe: bus acpi0 is probing device pcm0 -- non-pnp probe does not find device pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 mss_probe: bus acpi0 is probing device pcm0 -- non-pnp probe does not find device pnpmss_probe: bus acpi0 is probing device pcm0 lid 10cd041h, vid ffffffffh pnpmss_probe result 6 ACPI timer: 0/6 0/4 0/5 0/6 0/6 0/4 0/6 0/6 0/6 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 mss_probe: bus acpi0 is probing device pcm0 mss_probe: isa_get_logicalid() returned 0! -- non pnp probe FINDS the device, wrongly. Using the ISA_PNP_PROBE does the right thing here. mss_probe: no address given, try 0x530 mss_detect - chip revision 0x0a mss_detect() - Detected CS4236 pcm0: <CS4236> port 0x530-0x537 on acpi0 device_attach: pcm0 attach returned 6 mss_probe: bus acpi0 is probing device pcm1 pnpmss_probe: bus acpi0 is probing device pcm1 lid 30ad041h, vid ffffffffh pnpmss_probe result 6 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 <snip>... isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm3 pnpmss_probe: bus isa0 is probing device pcm3 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm3: <CS4236B> at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 CS4236B X25 reg: ebh ...<snip and so on> In the case ACPI is not enabled, you get: ..isa_probe_children: probing PnP devices mss_probe: bus isa0 is probing device pcm0 pnpmss_probe: bus isa0 is probing device pcm0 lid 630eh, vid 3568630eh pnpmss_probe result 0 pcm0: <CS4236B> at port 0x220-0x22f,0x388-0x38b,0x534-0x537 irq 5 drq 0,1 on isa0 CS4236B X25 reg: ebh .. Note that in the non-ACPI case, the non-pnp probe routine, mss_probe, when called by isa0 does the right thing and fails to accept the pnp device. The pnp probe routine correctly probes the device in this case. The question I can't get out of my head is this: When I change the mss.c code to use the routine the manual says non-PNP devices are supposed to use: ISA_PNP_PROBE -- all bootup operations are correct in both the ACPI and non ACPI case. Why doesn't that count as 'fixed, update mss.c and lets move on?'. Clearly the present code uses another function that doesn't work in the ACPI case. Shouldn't the investigation focus on what ISA_PNP_PROBE knows that the other call doesn't? ISA_PNP_PROBE in mss_probe works and matches the docs, the isa_get_whatziz doesn't work and is not accepted as correct practice in the docs. Maybe the doc writer has the answer. At any rate I don't get why this further investigation when an apparently 'canonical' practice works. That, or the architecture manual needs changing to mention this other way to avoid wrongful probing by non-PNP isa drivers when called by ACPI or isa0. If you still want me to try a test I'm game, let me know. It would encourage me to do so with the insight provided by some comments on the above though. HarryReceived on Tue Jul 12 2005 - 17:19:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC