Master Chief Posted December 8, 2009 Share Posted December 8, 2009 I just got mine working. I got so interested in why USB2.0 hubs wouldn't work that I went out to buy one Now I can wake up using both my aluminium keyboard and a mouse connected to powered USB2.0 hub. The red part might be key here. GigaByte USB hubs are underpowered? It's a DSDT patch, my ehci devices now look like this: Store (0xC9C2,\_SB.PCI0.EHC1.PMSS) ... Store (0xC9C2,\_SB.PCI0.EHC2.PMSS) Here we go. Bits 6-8 are the onces I was referring to with being underpowered. BTW: I would have used PWRC instead of PMCR since that's what it is. Edit: You don't need register 0x80 when you re-write it a little: OperationRegion (PWRC, PCI_Config, 0x52, 0x02) Field (PWRC, ByteAcc, NoLock, Preserve) { , 6, AUXC, 3, // Auxiliary Current. , 7 } And then call Store (0x07, AUXC). Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 The red part might be key here. GigaByte USB hubs are underpowered? Now try that with the vanilla DSDT No, the key is that for some reason Gigabyte writes 0x0002 to register 52h when booting up and that is why OS X thinks that Ehci has no power. When board goes to sleep for first time and wakes up then it gets that value 0xC9C2 which it should have had originally. Yet again a Gigabyte bios bug I guess, same thing happens on Windows but it just doesn't seem to care about that value. Link to comment Share on other sites More sharing options...
Master Chief Posted December 8, 2009 Share Posted December 8, 2009 No, the key is that for some reason Gigabyte writes 0x0002 to register 52h when booting up and that is why OS X thinks that Ehci has no power. When board goes to sleep for first time and wakes up then it gets that value 0xC9C2 which it should have had originally. Yet again a Gigabyte bios bug I guess, same thing happens on Windows but it just doesn't seem to care about that value. That's exactly what I said: They are underpowered. To me it doesn't matter what the cause is, since it doesn't work without a patch. They are underpowered without the patch. That's key here. p.s. Now do a search and find what I said about USB power since that was why I was so busy with all these ioreg outputs the changed registers after sleep. Remember? Let me quote that: Edit: Here's something to think about: Blackosx's ICH10 (EHCI controller #1: Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) And this is what I have with my ICH9: Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) And that on both EHCI controllers! Which would mean, if the data can be trusted, that you first have to do a sleep-wake cycle, and then wake from keyboard works, or that the lspci output can't be trusted. But good to see it nailed! Finally. Great work! Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 That's exactly what I said: They are underpowered. To me it doesn't matter what the cause is, since it doesn't work without a patch. They are underpowered without the patch. That's key here. p.s. Now do a search and find what I said about USB power since that was why I was so busy with all these ioreg outputs the changed registers after sleep. Remember? Let me quote that: But good to see it nailed! Finally. Great work! That is exactly what I noticed when comparing lspci outputs before and after sleep. It just doesn't help even if the power value gets corrected after first sleep. Link to comment Share on other sites More sharing options...
Master Chief Posted December 8, 2009 Share Posted December 8, 2009 That is exactly what I noticed when comparing lspci outputs before and after sleep. It just doesn't help even if the power value gets corrected after first sleep. I'm not sure I understand you; You still can't wake from alu Apple keyboard – before sleep – with this patch? Only from the externally powered hub (with the patch)? p.s. I'm sure that we are missing some kind of init() foo at boot time. Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 I'm not sure I understand you; You still can't wake from the keyboard – before sleep – with this patch? Only from the externally powered hub (with the patch)? p.s. I'm sure that we are missing some kind of init() foo at boot time. No, with the patch everything works fine. But patch has to be done on bootup, it doesn't help to write that register later. Link to comment Share on other sites More sharing options...
Master Chief Posted December 8, 2009 Share Posted December 8, 2009 No, with the patch everything works fine. But patch has to be done on bootup, it doesn't help to write that register later. But of course – the USB drivers need to know about it at load time (driver state differ). I would also like to advise you to use Method (_INI) under Scope (_SB) { right above Device (PCI0) – which runs unconditionally, before anythings else – to make sure that it works, even when (load / init) delays hit you. Link to comment Share on other sites More sharing options...
kdawg Posted December 8, 2009 Share Posted December 8, 2009 BTW: I would have used PWRC instead of PMCR since that's what it is. Edit: You don't need register 0x80 when you re-write it a little: OperationRegion (PWRC, PCI_Config, 0x52, 0x02) Field (PWRC, ByteAcc, NoLock, Preserve) { , 6, AUXC, 3, // Auxiliary Current. , 7 } And then call Store (0x07, AUXC). Did you mean PWCR? Link to comment Share on other sites More sharing options...
FKA Posted December 8, 2009 Share Posted December 8, 2009 No, with the patch everything works fine. But patch has to be done on bootup, it doesn't help to write that register later. Nice one mm67! Link to comment Share on other sites More sharing options...
Master Chief Posted December 8, 2009 Share Posted December 8, 2009 Did you mean PWCR? I checked the datasheet to find: "Power Management Capabilities Register" so PMCR would be the right one to use, for both the OperationRegion and Field, but I am going to group things up as I want less code. Here's part I: Method (_INI, 0, NotSerialized) // USB hub power initialization. { Store (0x07, ^EHC1.AUXC) // \_SB.PCI0.UHCI.AUXC Store (0x07, ^EHC2.AUXC) // \_SB.PCI0.EHCI.AUXC } Put that in your Device (PCI0) because that's what mm67 meant to do by using ^_INI. And this is step one, resulting in 10 optimizations and 55 bytes less AML code. More to come... Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 I checked the datasheet to find: "Power Management Capabilities Register" so PMCR would be the right one to use, for both the OperationRegion and Field, but I am going to group things up as I want less code. Here's part I: Method (_INI, 0, NotSerialized) // USB hub power initialization. { Store (0x07, ^EHC1.AUXC) // \_SB.PCI0.UHCI.AUXC Store (0x07, ^EHC2.AUXC) // \_SB.PCI0.EHCI.AUXC } Put that in your Device (PCI0) because that's what mm67 meant to do by using ^_INI. And this is step one, resulting in 10 optimizations and 55 bytes less AML code. More to come... Ok, did some more testing and those bits 8:6 don't matter, it's the bits 15:11 that do the business, writing 0x19 there is the key to working Ehci Link to comment Share on other sites More sharing options...
kdawg Posted December 8, 2009 Share Posted December 8, 2009 I can even connect a mouse to keyboards hub and use that for wake up. /edit If you try this on something else than ICH10 check that your ICH has the same register on EHCI as ICH10 does 52h–53h PWR_CAP Power Management Capabilities I have a ICH10 (GA-EP45-UD3P). Thanks for the tip. Link to comment Share on other sites More sharing options...
Master Chief Posted December 8, 2009 Share Posted December 8, 2009 Ok, did some more testing and those bits 8:6 don't matter, it's the bits 15:11 that do the business, writing 0x19 there is the key to working Ehci But isn't that controlled by bit 8 in register 0x54? Is that bit set on your board? What happens when you set it? Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 But isn't that controlled by bit 8 in register 0x54? Is that bit set on your board? What happens when you set it? Nope, ICH10 datasheet has this note under description: Normally, this register is read-only to report capabilities to the power management software. To report different power management capabilities, depending on the system in which the ICH10 is used, bits 15:11 and 8:6 in this register are writable when the WRT_RDONLY bit (D29:F7, D26:F7:80h, bit 0) is set. The value written to this register does not affect the hardware other than changing the value returned during a read. So this register really isn't needed for anything, it's just that because Gigabyte writes a stupid value there OS X is fooled into thinking that EHCI device has no PME capabilities. Link to comment Share on other sites More sharing options...
Master Chief Posted December 8, 2009 Share Posted December 8, 2009 Nope, ICH10 datasheet has this note under description:Normally, this register is read-only to report capabilities to the power management software. To report different power management capabilities, depending on the system in which the ICH10 is used, bits 15:11 and 8:6 in this register are writable when the WRT_RDONLY bit (D29:F7, D26:F7:80h, bit 0) is set. The value written to this register does not affect the hardware other than changing the value returned during a read. That's is exactly the same note I have for register 0x52, for my ICH9. And something is initializing this register. Or should I say should as it doesn't appear to work on GB boards So this register really isn't needed for anything, it's just that because Gigabyte writes a stupid value there OS X is fooled into thinking that EHCI device has no PME capabilities. You think? So tell me; Why did Apple include this snippet: OperationRegion (U7CS, PCI_Config, 0x54, 0x02) Field (U7CS, WordAcc, NoLock, Preserve) { , 15, PMES, 1 } Why did they, when they don't need it? Again: Is bit 8 set, and if not, what happens when you set it? I mean the note: "This bit (8 and 15) must be explicitly cleared by the operating system each time it is initially loaded." can't be there too for nothing! What if bit 8 and/or 15 are not cleared at boot time? Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 That's is exactly the same note I have for register 0x52, for my ICH9. And something is initializing this register. Or should I say should as it doesn't appear to work on GB boards You think? So tell me; Why did Apple include this snippet: OperationRegion (U7CS, PCI_Config, 0x54, 0x02) Field (U7CS, WordAcc, NoLock, Preserve) { , 15, PMES, 1 } Why did they, when they don't need it? Again: Is bit 8 set, and if not, what happens when you set it? I mean the note: "This bit (8 and 15) must be explicitly cleared by the operating system each time it is initially loaded." can't be there too for nothing! What if bit 8 and/or 15 are not cleared at boot time? Bit 8 of register 54 is set if I boot without my patch and I don't know why Apple added that register to their DSDT. What I do know is that my MSI board has no such stuff in DSDT and value of register 52 is always C9C2 so I assume that bios is putting that value there. /edit With my patch bit 8 of register 54 is not set. Without patch value is 0x0100 and with patch 0x0000 Link to comment Share on other sites More sharing options...
keeza Posted December 8, 2009 Share Posted December 8, 2009 Bit 8 of register 54 is set if I boot without my patch and I don't know why Apple added that register to their DSDT. What I do know is that my MSI board has no such stuff in DSDT and value of register 52 is always C9C2 so I assume that bios is putting that value there. /edit With my patch bit 8 of register 54 is not set. Without patch value is 0x0100 and with patch 0x0000 I'll try this patch when I get back from a short break to see if it'll work with my white apple keyboard connected to my hub on my cinema display. Nice work mm67!!! p.s. care to share your latest and greatest? Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 I'll try this patch when I get back from a short break to see if it'll work with my white apple keyboard connected to my hub on my cinema display. Nice work mm67!!! p.s. care to share your latest and greatest? This is what I am using at the moment: dsdt.dsl.zip Was already under 900 lines without these EHCI mods 1 Link to comment Share on other sites More sharing options...
blackosx Posted December 8, 2009 Share Posted December 8, 2009 Great work with your fix mm67 and I enjoyed your open discussion with MasterChief about it as it gives an insight in to the whole development process. Thanks This is what I am using at the moment: Was already under 900 lines without these EHCI mods And your DSDT is amazing, as for me, it throws a whole new angle on this subject. It's as if you have started with a blank DSDT and only added what you've needed? Thanks for sharing. Link to comment Share on other sites More sharing options...
FKA Posted December 8, 2009 Share Posted December 8, 2009 This is what I am using at the moment:dsdt.dsl.zip Was already under 900 lines without these EHCI mods I'd love to know why I can't get speedstep working with these mods. Here's mm67's dsdt patched up for my p35 board - speedstep NOT working! D. DSDT08_12_09.dsl.zip Link to comment Share on other sites More sharing options...
blackosx Posted December 8, 2009 Share Posted December 8, 2009 I'd love to know why I can't get speedstep working with these mods. Here's mm67's dsdt patched up for my p35 board - speedstep NOT working! It worked for me, so I have done what I did for mine, with your data. Have a look at the attached and see if that works for you? (You might need other bits for your setup, but this is using just what I know).. SuggestionForFormerly_DSDT.dsl.zip Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 It worked for me, so I have done what I did for mine, with your data. Have a look at the attached and see if that works for you? (You might need other bits for your setup, but this is using just what I know).. Do you now have method PTS setup like mine, if you do then could you try some shutdowns without OHR.kext. Link to comment Share on other sites More sharing options...
blackosx Posted December 8, 2009 Share Posted December 8, 2009 Do you now have method PTS setup like mine, if you do then could you try some shutdowns without OHR.kext. I am testing with your DSDT with only my data in Scope (_PR). Here it is... dsdt.dsl.zip As for Shutdowns, I can report 5 out of 5 so far Link to comment Share on other sites More sharing options...
mm67 Posted December 8, 2009 Share Posted December 8, 2009 I am testing with your DSDT with only my data in Scope (_PR). Here it is...dsdt.dsl.zip As for Shutdowns, I can report 5 out of 5 so far That's good, I have now been using shutdown without OHR for almost two weeks, haven't seen it fail even once. Link to comment Share on other sites More sharing options...
kdawg Posted December 9, 2009 Share Posted December 9, 2009 That's good, I have now been using shutdown without OHR for almost two weeks, haven't seen it fail even once. I know this is a lot to ask but would you happen to have your original unedited DSDT for comparison? Link to comment Share on other sites More sharing options...
Recommended Posts