1905 replies to this topic

[mm67]

Is it the hub that lets you wake via the keyboard of some DSDT patch?

It's a DSDT patch, my ehci devices now look like this:

Device (EHC1)            {                Name (_ADR, 0x001D0007)                Name (_PRW, Package (0x02){0x0D,0x03})                OperationRegion (PMCR, PCI_Config, 0x52, 0x2F)                Field (PMCR, ByteAcc, NoLock, Preserve)                {                    PMSS,   16,	                Offset (0x2E),                    WRTA,   1                }           }            Device (EHC2)            {                Name (_ADR, 0x001A0007)                Name (_PRW, Package (0x02){0x0D,0x03})                OperationRegion (PMCR, PCI_Config, 0x52, 0x2F)                Field (PMCR, ByteAcc, NoLock, Preserve)                {                    PMSS,   16,	                Offset (0x2E),                    WRTA,   1                }            }

and this is what I added under device LPC

Method (^_INI, 0, NotSerialized)				{					Store (0x01,\_SB.PCI0.EHC1.WRTA)					Store (0xC9C2,\_SB.PCI0.EHC1.PMSS)					Store (0x00,\_SB.PCI0.EHC1.WRTA)								Store (0x01,\_SB.PCI0.EHC2.WRTA)					Store (0xC9C2,\_SB.PCI0.EHC2.PMSS)					Store (0x00,\_SB.PCI0.EHC2.WRTA)				}

Funny thing is that the register that I modified doesn't really do anything, it is only used to show OS capabilities of Ehci device.

WOW! so your aluminum KB is working just by plugging it on a USB hub? mind showing a pic of that 'special' hub hehe? i have two 4-port hub here (Belkin and a chinese brand) and both of them don't work..

i have no problem waking from a wired mouse though may it be connected to a hub or directly to my machine.

No, I meant that now USB2.0 hub connected devices work for wake up, including Apple keyboard

[kdawg]

No, I meant that now USB2.0 hub connected devices work for wake up, including Apple keyboard

So can you wake your computer if you connect the keyboard directly instead of via the hub?

[mm67]

So can you wake your computer if you connect the keyboard directly instead of via the hub?

Both work, I can connect my keyboard to a usb hub or directly to motherboard and wake up using it.

[kdawg]

Both work, I can connect my keyboard to a usb hub or directly to motherboard and wake up using it.

Nice! Maybe I'll bring home my aluminum keyboard and see if I can get it working.

[mm67]

Nice! Maybe I'll bring home my aluminum keyboard and see if I can get it working.

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

[sk1nhead]

I can even connect a mouse to keyboards hub and use that for wake up

IT WORKS!!! finally wake from sleep using my slim aluminum keyboard

Thanks a lot mm67..

[Master Chief]

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).

[mm67]

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.

[Master Chief]

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!

[mm67]

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.

[Master Chief]

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.

[mm67]

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.

[Master Chief]

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.

[kdawg]

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?

[FKA]

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!

[Master Chief]

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...

[mm67]

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

[kdawg]

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.

[Master Chief]

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?

[mm67]

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.