All of lore.kernel.org
 help / color / mirror / Atom feed
* [Devel] Re: Wake On LAN steps for QNX from S5
@ 2020-10-15 11:30 Devin Steffler
  0 siblings, 0 replies; 4+ messages in thread
From: Devin Steffler @ 2020-10-15 11:30 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 9058 bytes --]

Hi Will,

Just wanted to confirm that setting the WUC bits did the trick. I'm
guessing that there's no way to do that from ACPICA, correct?

Thanks,
Devin


On Wed, Oct 14, 2020 at 6:18 PM Devin Steffler <devinsteffler(a)gmail.com>
wrote:

> Hi Will,
>
> I think you hit the nail on the head. I just found out about the WUC
> register as well via various online searches.
>
> I am going to give that a shot and let you know.
>
> If it is due to WUC bits, then do you know if there is a way to toggle
> that programmatically with ACPICA in an agnostic way? Otherwise I have a
> feeling I'll need to write lots of code for different chipsets and it would
> not be very future proof. This applies for different vendors as well
> (although QNX is really just Intel, Realtek or ASIX).
>
> Many thanks for your email.
>
> Devin
>
>
> On Wed, Oct 14, 2020, 1:15 PM Will Miles <wmiles(a)sgl.com> wrote:
>
>> Hi Devin,
>>
>> I did some of the initial porting work to compile ACPICA for use in QNX
>> userspace.   I'm glad to hear you've had some success with it!
>>
>> I can't speak for current revisions; but at least as far as the BSP
>> supplied with QNX 6.6, QNX's e1000 driver explicitly disables
>> wake-on-LAN when loaded by writing to the wakeup control (WUC) register
>> on the device.   My recommendation would be to get a copy of the
>> datasheet for your device
>> (
>> http://www.intel.com/content/www/us/en/embedded/products/networking/ethernet-connection-i219-datasheet.html
>> ?) and then, as part of your shutdown routine, explicitly terminate the
>> QNX network drivers and then manually re-enable APM wakeup by directly
>> interacting with the ethernet device registers.
>>
>> Hope this is of some help,
>>
>> -Will
>>
>> On 10/14/2020 12:02 PM, devinsteffler(a)gmail.com wrote:
>> > Hello,
>> >
>> > I raised a case with QNX about this last week but I haven't heard back
>> from them yet. In the meantime, I'm wondering if the kind folks at ACPICA
>> might be able to help with this. I'm hoping that I'm not missing anything
>> obvious.
>> >
>> > I'm using an Intel based x86_64 PC with QNX on it (an Intel NUC
>> NUC7i5DNB to be precise). QNX does not have ACPI support built-in. As an
>> example, QNX does not have a way to read battery status or power down (soft
>> off, S5) an x86 based PC.
>> >
>> > So I'm making my own ACPI driver for QNX based off of the ACPICA code
>> base. I've done this previously with success for reading AC power/battery
>> information on laptops using things like _PSR from a ACPI0003 device as
>> well as _STA, _BIF, and _BST from PNP0C0A devices.
>> >
>> > Now I would like to try and get Wake On LAN working from a soft off
>> (S5) state.
>> >
>> > I'm able to enter S5 via the following code:
>> > -----------------------------------------------
>> >       AcpiEnterSleepStatePrep(5);
>> >
>> >       // disable interrupts, optional?
>> >       ThreadCtl( _NTO_TCTL_IO, 0 );
>> >       InterruptDisable();
>> >
>> >       AcpiEnterSleepState(5);
>> > -----------------------------------------------
>> >
>> > Unfortunately, when I enter S5 using that code, then Wake On LAN no
>> longer works when powered off. Although as you'll see below, Wake On LAN no
>> longer works if I go to S5 after having used the QNX e1000 driver. If I
>> don't use the e1000 driver then Wake On LAN works. Although, I need the QNX
>> e1000 driver to have networking when running.
>> >
>> > I've made the following observations:
>> > - When I boot my device with Linux and power it off using software,
>> then I'm able to Wake On LAN just fine.
>> >    - in this case, the NIC LEDs blink while powered off
>> > - If I boot into QNX and hold the power button for 10 seconds or so, it
>> powers off and Wake On LAN works (whether the QNX e1000 driver is loaded or
>> not).
>> >    - in this case, the NIC LEDs blink while powered off
>> > - If I boot into QNX and use software (the code above) to power down,
>> then Wake On LAN does not work.
>> >    - in this case, the NIC LEDs remain off while powered off
>> > - If I boot into QNX but do not start their networking stack (or their
>> e1000 driver) and use software (the code above) to power down, then Wake On
>> LAN does work.
>> >    - in this case, the NIC LEDs blink while powered off (they
>> momentarily stop blinking, but then blink again shortly afterwards)
>> >
>> > QNX has a pci-tool (similar to Linux's lspci tool). I can use it to see
>> the following:
>> >
>> ----------------------------------------------------------------------------------
>> > # pci-tool -vvvv -d0:31:6
>> >
>> > B000:D31:F06 @ idx 0
>> >          vid/did: 8086/156f
>> >                  Intel Corporation, <device id - unknown>
>> >          class/subclass/reg: 02/00/00
>> >                  Ethernet Network Controller
>> > <snip>
>> >          PMI Capability Details
>> >                  PMI supported states: D0 D3hot D3cold *
>> >                  PMI current state: D0
>> >                  PME's supported from states: D0 D3hot D3cold *
>> >                  PME's are disabled
>> >                  PMI data: [idx] val scale
>> >                          [00]  00  01  [01]  --  --  [02]  --  --
>> [03]  00  01
>> >                          [04]  00  01  [05]  --  --  [06]  --  --
>> [07]  00  01
>> >                          [08]  --  --  [09]  --  --  [10]  --  --
>> [11]  --  --
>> >                          [12]  --  --  [13]  --  --  [14]  --  --
>> [15]  --  --
>> >
>> ----------------------------------------------------------------------------------
>> >
>> > I can use this method in ACPI to get "PME's are enabled" output:
>> > \_SB.PCI0.GLAN._DSW
>> >
>> > i.e.
>> >
>> ----------------------------------------------------------------------------------
>> > # pci-tool -vvvv -d0:31:6
>> >
>> > B000:D31:F06 @ idx 0
>> > <snip>
>> >          PMI Capability Details
>> >                  PMI supported states: D0 D3hot D3cold *
>> >                  PMI current state: D0
>> >                  PME's supported from states: D0 D3hot D3cold *
>> >                  PME's are enabled
>> >                  PMI data: [idx] val scale
>> >                          [00]  00  01  [01]  --  --  [02]  --  --
>> [03]  00  01
>> >                          [04]  00  01  [05]  --  --  [06]  --  --
>> [07]  00  01
>> >                          [08]  --  --  [09]  --  --  [10]  --  --
>> [11]  --  --
>> >                          [12]  --  --  [13]  --  --  [14]  --  --
>> [15]  --  --
>> >
>> ----------------------------------------------------------------------------------
>> >
>> > Although that doesn't help.
>> >
>> > Do I need to get the PMI current state to be D3hot prior to entering S5
>> in order for Wake On LAN to work?
>> >
>> > However, I noticed that if I boot without the QNX e1000 driver, then
>> Wake On LAN works by just going to S5 alone, without _DSW. In this case:
>> >
>> ----------------------------------------------------------------------------------
>> > # pci-tool -vvvv -d0:31:6
>> >
>> > B000:D31:F06 @ idx 0
>> > <snip>
>> >          PMI Capability Details
>> >                  PMI supported states: D0 D3hot D3cold *
>> >                  PMI current state: D0
>> >                  PME's supported from states: D0 D3hot D3cold *
>> >                  PME's are disabled
>> >                  PMI data: [idx] val scale
>> >                          [00]  00  01  [01]  --  --  [02]  --  --
>> [03]  00  01
>> >                          [04]  00  01  [05]  --  --  [06]  --  --
>> [07]  00  01
>> >                          [08]  --  --  [09]  --  --  [10]  --  --
>> [11]  --  --
>> >                          [12]  --  --  [13]  --  --  [14]  --  --
>> [15]  --  --
>> >
>> ----------------------------------------------------------------------------------
>> >
>> > It's almost like the QNX e1000 driver is putting the NIC into some
>> state that EFI does not recover from when transitioning to S5. Maybe the
>> PHY is being turned off. If this is the case, then should calls to things
>> like _DSW, _PRW (and enabling GPE it returns), or even the LPI function 5
>> put the PHY back on? The NIC LEDs shut off at the same time as the power
>> LED when entering S5 and do not come back on.
>> >
>> > For LPI I'm referring to this:
>> >
>> https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
>> >
>> > Any help is appreciated.
>> >
>> > Thanks,
>> > Devin
>> > _______________________________________________
>> > Devel mailing list -- devel(a)acpica.org
>> > To unsubscribe send an email to devel-leave(a)acpica.org
>> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>> _______________________________________________
>> Devel mailing list -- devel(a)acpica.org
>> To unsubscribe send an email to devel-leave(a)acpica.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 11383 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Devel] Re: Wake On LAN steps for QNX from S5
@ 2020-10-15 13:19 Will Miles
  0 siblings, 0 replies; 4+ messages in thread
From: Will Miles @ 2020-10-15 13:19 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 12979 bytes --]

Hi Devin,

Glad to hear it worked for you!   I honestly don't know if there's an 
ACPI procedure for configuring the WUC state, but I doubt it -- I would 
expect that sort of feature to be managed by the operating system's 
hardware drivers.   I didn't spend too much time studying the x86 BIOS 
standards, though; my requirement was to implement a hardware enumerator 
for legacy PC devices such as serial ports for QNX 6.6, we didn't need 
to dig in to power management much.   I just happened to have a copy of 
the QNX 6.6 e1000 driver sources on hand and thought you'd be interested 
to know that WUC was explicitly disabled there.   If anything, I expect 
you'll find that the drivers have overridden the state set by the BIOS, 
and so the BIOS expects that this feature is already enabled.

If you really want to be certain, you could try decompiling the ACPI 
tables on your target board, identify the ethernet device, and walk 
through all the function bytecode looking for relevant register 
operations.  I did this once to patch up the power management procedures 
for an old laptop with switchable graphics to find out how to address 
the LCD panel switch; it had been tied to ACPI power management calls to 
power up and down the discrete graphics chip, and unfortunately that 
approach was not supported by the chip vendor's graphics drivers after 
2011.  It's a bit of a chore but it can be done.

Sorry I can't be of more help,

-Will

On 10/15/2020 7:30 AM, Devin Steffler wrote:
> Hi Will,
>
> Just wanted to confirm that setting the WUC bits did the trick. I'm 
> guessing that there's no way to do that from ACPICA, correct?
>
> Thanks,
> Devin
>
>
> On Wed, Oct 14, 2020 at 6:18 PM Devin Steffler 
> <devinsteffler(a)gmail.com <mailto:devinsteffler(a)gmail.com>> wrote:
>
>     Hi Will,
>
>     I think you hit the nail on the head. I just found out about the
>     WUC register as well via various online searches.
>
>     I am going to give that a shot and let you know.
>
>     If it is due to WUC bits, then do you know if there is a way to
>     toggle that programmatically with ACPICA in an agnostic way?
>     Otherwise I have a feeling I'll need to write lots of code for
>     different chipsets and it would not be very future proof. This
>     applies for different vendors as well (although QNX is really just
>     Intel, Realtek or ASIX).
>
>     Many thanks for your email.
>
>     Devin
>
>
>     On Wed, Oct 14, 2020, 1:15 PM Will Miles <wmiles(a)sgl.com
>     <mailto:wmiles(a)sgl.com>> wrote:
>
>         Hi Devin,
>
>         I did some of the initial porting work to compile ACPICA for
>         use in QNX
>         userspace.   I'm glad to hear you've had some success with it!
>
>         I can't speak for current revisions; but at least as far as
>         the BSP
>         supplied with QNX 6.6, QNX's e1000 driver explicitly disables
>         wake-on-LAN when loaded by writing to the wakeup control (WUC)
>         register
>         on the device.   My recommendation would be to get a copy of the
>         datasheet for your device
>         (http://www.intel.com/content/www/us/en/embedded/products/networking/ethernet-connection-i219-datasheet.html
>         <http://www.intel.com/content/www/us/en/embedded/products/networking/ethernet-connection-i219-datasheet.html>
>
>         ?) and then, as part of your shutdown routine, explicitly
>         terminate the
>         QNX network drivers and then manually re-enable APM wakeup by
>         directly
>         interacting with the ethernet device registers.
>
>         Hope this is of some help,
>
>         -Will
>
>         On 10/14/2020 12:02 PM, devinsteffler(a)gmail.com
>         <mailto:devinsteffler(a)gmail.com> wrote:
>         > Hello,
>         >
>         > I raised a case with QNX about this last week but I haven't
>         heard back from them yet. In the meantime, I'm wondering if
>         the kind folks at ACPICA might be able to help with this. I'm
>         hoping that I'm not missing anything obvious.
>         >
>         > I'm using an Intel based x86_64 PC with QNX on it (an Intel
>         NUC NUC7i5DNB to be precise). QNX does not have ACPI support
>         built-in. As an example, QNX does not have a way to read
>         battery status or power down (soft off, S5) an x86 based PC.
>         >
>         > So I'm making my own ACPI driver for QNX based off of the
>         ACPICA code base. I've done this previously with success for
>         reading AC power/battery information on laptops using things
>         like _PSR from a ACPI0003 device as well as _STA, _BIF, and
>         _BST from PNP0C0A devices.
>         >
>         > Now I would like to try and get Wake On LAN working from a
>         soft off (S5) state.
>         >
>         > I'm able to enter S5 via the following code:
>         > -----------------------------------------------
>         >       AcpiEnterSleepStatePrep(5);
>         >
>         >       // disable interrupts, optional?
>         >       ThreadCtl( _NTO_TCTL_IO, 0 );
>         >       InterruptDisable();
>         >
>         >       AcpiEnterSleepState(5);
>         > -----------------------------------------------
>         >
>         > Unfortunately, when I enter S5 using that code, then Wake On
>         LAN no longer works when powered off. Although as you'll see
>         below, Wake On LAN no longer works if I go to S5 after having
>         used the QNX e1000 driver. If I don't use the e1000 driver
>         then Wake On LAN works. Although, I need the QNX e1000 driver
>         to have networking when running.
>         >
>         > I've made the following observations:
>         > - When I boot my device with Linux and power it off using
>         software, then I'm able to Wake On LAN just fine.
>         >    - in this case, the NIC LEDs blink while powered off
>         > - If I boot into QNX and hold the power button for 10
>         seconds or so, it powers off and Wake On LAN works (whether
>         the QNX e1000 driver is loaded or not).
>         >    - in this case, the NIC LEDs blink while powered off
>         > - If I boot into QNX and use software (the code above) to
>         power down, then Wake On LAN does not work.
>         >    - in this case, the NIC LEDs remain off while powered off
>         > - If I boot into QNX but do not start their networking stack
>         (or their e1000 driver) and use software (the code above) to
>         power down, then Wake On LAN does work.
>         >    - in this case, the NIC LEDs blink while powered off
>         (they momentarily stop blinking, but then blink again shortly
>         afterwards)
>         >
>         > QNX has a pci-tool (similar to Linux's lspci tool). I can
>         use it to see the following:
>         >
>         ----------------------------------------------------------------------------------
>         > # pci-tool -vvvv -d0:31:6
>         >
>         > B000:D31:F06 @ idx 0
>         >          vid/did: 8086/156f
>         >                  Intel Corporation, <device id - unknown>
>         >          class/subclass/reg: 02/00/00
>         >                  Ethernet Network Controller
>         > <snip>
>         >          PMI Capability Details
>         >                  PMI supported states: D0 D3hot D3cold *
>         >                  PMI current state: D0
>         >                  PME's supported from states: D0 D3hot D3cold *
>         >                  PME's are disabled
>         >                  PMI data: [idx] val scale
>         >                          [00]  00  01  [01]  --  -- [02] 
>         --  --  [03]  00  01
>         >                          [04]  00  01  [05]  --  -- [06] 
>         --  --  [07]  00  01
>         >                          [08]  --  --  [09]  --  -- [10] 
>         --  --  [11]  --  --
>         >                          [12]  --  --  [13]  --  -- [14] 
>         --  --  [15]  --  --
>         >
>         ----------------------------------------------------------------------------------
>         >
>         > I can use this method in ACPI to get "PME's are enabled" output:
>         > \_SB.PCI0.GLAN._DSW
>         >
>         > i.e.
>         >
>         ----------------------------------------------------------------------------------
>         > # pci-tool -vvvv -d0:31:6
>         >
>         > B000:D31:F06 @ idx 0
>         > <snip>
>         >          PMI Capability Details
>         >                  PMI supported states: D0 D3hot D3cold *
>         >                  PMI current state: D0
>         >                  PME's supported from states: D0 D3hot D3cold *
>         >                  PME's are enabled
>         >                  PMI data: [idx] val scale
>         >                          [00]  00  01  [01]  --  -- [02] 
>         --  --  [03]  00  01
>         >                          [04]  00  01  [05]  --  -- [06] 
>         --  --  [07]  00  01
>         >                          [08]  --  --  [09]  --  -- [10] 
>         --  --  [11]  --  --
>         >                          [12]  --  --  [13]  --  -- [14] 
>         --  --  [15]  --  --
>         >
>         ----------------------------------------------------------------------------------
>         >
>         > Although that doesn't help.
>         >
>         > Do I need to get the PMI current state to be D3hot prior to
>         entering S5 in order for Wake On LAN to work?
>         >
>         > However, I noticed that if I boot without the QNX e1000
>         driver, then Wake On LAN works by just going to S5 alone,
>         without _DSW. In this case:
>         >
>         ----------------------------------------------------------------------------------
>         > # pci-tool -vvvv -d0:31:6
>         >
>         > B000:D31:F06 @ idx 0
>         > <snip>
>         >          PMI Capability Details
>         >                  PMI supported states: D0 D3hot D3cold *
>         >                  PMI current state: D0
>         >                  PME's supported from states: D0 D3hot D3cold *
>         >                  PME's are disabled
>         >                  PMI data: [idx] val scale
>         >                          [00]  00  01  [01]  --  -- [02] 
>         --  --  [03]  00  01
>         >                          [04]  00  01  [05]  --  -- [06] 
>         --  --  [07]  00  01
>         >                          [08]  --  --  [09]  --  -- [10] 
>         --  --  [11]  --  --
>         >                          [12]  --  --  [13]  --  -- [14] 
>         --  --  [15]  --  --
>         >
>         ----------------------------------------------------------------------------------
>         >
>         > It's almost like the QNX e1000 driver is putting the NIC
>         into some state that EFI does not recover from when
>         transitioning to S5. Maybe the PHY is being turned off. If
>         this is the case, then should calls to things like _DSW, _PRW
>         (and enabling GPE it returns), or even the LPI function 5 put
>         the PHY back on? The NIC LEDs shut off at the same time as the
>         power LED when entering S5 and do not come back on.
>         >
>         > For LPI I'm referring to this:
>         >
>         https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
>         <https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf>
>         >
>         > Any help is appreciated.
>         >
>         > Thanks,
>         > Devin
>         > _______________________________________________
>         > Devel mailing list -- devel(a)acpica.org <mailto:devel(a)acpica.org>
>         > To unsubscribe send an email to devel-leave(a)acpica.org
>         <mailto:devel-leave(a)acpica.org>
>         > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>         _______________________________________________
>         Devel mailing list -- devel(a)acpica.org <mailto:devel(a)acpica.org>
>         To unsubscribe send an email to devel-leave(a)acpica.org
>         <mailto:devel-leave(a)acpica.org>
>         %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 17354 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Devel] Re: Wake On LAN steps for QNX from S5
@ 2020-10-14 22:18 Devin Steffler
  0 siblings, 0 replies; 4+ messages in thread
From: Devin Steffler @ 2020-10-14 22:18 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 8586 bytes --]

Hi Will,

I think you hit the nail on the head. I just found out about the WUC
register as well via various online searches.

I am going to give that a shot and let you know.

If it is due to WUC bits, then do you know if there is a way to toggle that
programmatically with ACPICA in an agnostic way? Otherwise I have a feeling
I'll need to write lots of code for different chipsets and it would not be
very future proof. This applies for different vendors as well (although QNX
is really just Intel, Realtek or ASIX).

Many thanks for your email.

Devin


On Wed, Oct 14, 2020, 1:15 PM Will Miles <wmiles(a)sgl.com> wrote:

> Hi Devin,
>
> I did some of the initial porting work to compile ACPICA for use in QNX
> userspace.   I'm glad to hear you've had some success with it!
>
> I can't speak for current revisions; but at least as far as the BSP
> supplied with QNX 6.6, QNX's e1000 driver explicitly disables
> wake-on-LAN when loaded by writing to the wakeup control (WUC) register
> on the device.   My recommendation would be to get a copy of the
> datasheet for your device
> (
> http://www.intel.com/content/www/us/en/embedded/products/networking/ethernet-connection-i219-datasheet.html
> ?) and then, as part of your shutdown routine, explicitly terminate the
> QNX network drivers and then manually re-enable APM wakeup by directly
> interacting with the ethernet device registers.
>
> Hope this is of some help,
>
> -Will
>
> On 10/14/2020 12:02 PM, devinsteffler(a)gmail.com wrote:
> > Hello,
> >
> > I raised a case with QNX about this last week but I haven't heard back
> from them yet. In the meantime, I'm wondering if the kind folks at ACPICA
> might be able to help with this. I'm hoping that I'm not missing anything
> obvious.
> >
> > I'm using an Intel based x86_64 PC with QNX on it (an Intel NUC
> NUC7i5DNB to be precise). QNX does not have ACPI support built-in. As an
> example, QNX does not have a way to read battery status or power down (soft
> off, S5) an x86 based PC.
> >
> > So I'm making my own ACPI driver for QNX based off of the ACPICA code
> base. I've done this previously with success for reading AC power/battery
> information on laptops using things like _PSR from a ACPI0003 device as
> well as _STA, _BIF, and _BST from PNP0C0A devices.
> >
> > Now I would like to try and get Wake On LAN working from a soft off (S5)
> state.
> >
> > I'm able to enter S5 via the following code:
> > -----------------------------------------------
> >       AcpiEnterSleepStatePrep(5);
> >
> >       // disable interrupts, optional?
> >       ThreadCtl( _NTO_TCTL_IO, 0 );
> >       InterruptDisable();
> >
> >       AcpiEnterSleepState(5);
> > -----------------------------------------------
> >
> > Unfortunately, when I enter S5 using that code, then Wake On LAN no
> longer works when powered off. Although as you'll see below, Wake On LAN no
> longer works if I go to S5 after having used the QNX e1000 driver. If I
> don't use the e1000 driver then Wake On LAN works. Although, I need the QNX
> e1000 driver to have networking when running.
> >
> > I've made the following observations:
> > - When I boot my device with Linux and power it off using software, then
> I'm able to Wake On LAN just fine.
> >    - in this case, the NIC LEDs blink while powered off
> > - If I boot into QNX and hold the power button for 10 seconds or so, it
> powers off and Wake On LAN works (whether the QNX e1000 driver is loaded or
> not).
> >    - in this case, the NIC LEDs blink while powered off
> > - If I boot into QNX and use software (the code above) to power down,
> then Wake On LAN does not work.
> >    - in this case, the NIC LEDs remain off while powered off
> > - If I boot into QNX but do not start their networking stack (or their
> e1000 driver) and use software (the code above) to power down, then Wake On
> LAN does work.
> >    - in this case, the NIC LEDs blink while powered off (they
> momentarily stop blinking, but then blink again shortly afterwards)
> >
> > QNX has a pci-tool (similar to Linux's lspci tool). I can use it to see
> the following:
> >
> ----------------------------------------------------------------------------------
> > # pci-tool -vvvv -d0:31:6
> >
> > B000:D31:F06 @ idx 0
> >          vid/did: 8086/156f
> >                  Intel Corporation, <device id - unknown>
> >          class/subclass/reg: 02/00/00
> >                  Ethernet Network Controller
> > <snip>
> >          PMI Capability Details
> >                  PMI supported states: D0 D3hot D3cold *
> >                  PMI current state: D0
> >                  PME's supported from states: D0 D3hot D3cold *
> >                  PME's are disabled
> >                  PMI data: [idx] val scale
> >                          [00]  00  01  [01]  --  --  [02]  --  --  [03]
> 00  01
> >                          [04]  00  01  [05]  --  --  [06]  --  --  [07]
> 00  01
> >                          [08]  --  --  [09]  --  --  [10]  --  --  [11]
> --  --
> >                          [12]  --  --  [13]  --  --  [14]  --  --  [15]
> --  --
> >
> ----------------------------------------------------------------------------------
> >
> > I can use this method in ACPI to get "PME's are enabled" output:
> > \_SB.PCI0.GLAN._DSW
> >
> > i.e.
> >
> ----------------------------------------------------------------------------------
> > # pci-tool -vvvv -d0:31:6
> >
> > B000:D31:F06 @ idx 0
> > <snip>
> >          PMI Capability Details
> >                  PMI supported states: D0 D3hot D3cold *
> >                  PMI current state: D0
> >                  PME's supported from states: D0 D3hot D3cold *
> >                  PME's are enabled
> >                  PMI data: [idx] val scale
> >                          [00]  00  01  [01]  --  --  [02]  --  --  [03]
> 00  01
> >                          [04]  00  01  [05]  --  --  [06]  --  --  [07]
> 00  01
> >                          [08]  --  --  [09]  --  --  [10]  --  --  [11]
> --  --
> >                          [12]  --  --  [13]  --  --  [14]  --  --  [15]
> --  --
> >
> ----------------------------------------------------------------------------------
> >
> > Although that doesn't help.
> >
> > Do I need to get the PMI current state to be D3hot prior to entering S5
> in order for Wake On LAN to work?
> >
> > However, I noticed that if I boot without the QNX e1000 driver, then
> Wake On LAN works by just going to S5 alone, without _DSW. In this case:
> >
> ----------------------------------------------------------------------------------
> > # pci-tool -vvvv -d0:31:6
> >
> > B000:D31:F06 @ idx 0
> > <snip>
> >          PMI Capability Details
> >                  PMI supported states: D0 D3hot D3cold *
> >                  PMI current state: D0
> >                  PME's supported from states: D0 D3hot D3cold *
> >                  PME's are disabled
> >                  PMI data: [idx] val scale
> >                          [00]  00  01  [01]  --  --  [02]  --  --  [03]
> 00  01
> >                          [04]  00  01  [05]  --  --  [06]  --  --  [07]
> 00  01
> >                          [08]  --  --  [09]  --  --  [10]  --  --  [11]
> --  --
> >                          [12]  --  --  [13]  --  --  [14]  --  --  [15]
> --  --
> >
> ----------------------------------------------------------------------------------
> >
> > It's almost like the QNX e1000 driver is putting the NIC into some state
> that EFI does not recover from when transitioning to S5. Maybe the PHY is
> being turned off. If this is the case, then should calls to things like
> _DSW, _PRW (and enabling GPE it returns), or even the LPI function 5 put
> the PHY back on? The NIC LEDs shut off at the same time as the power LED
> when entering S5 and do not come back on.
> >
> > For LPI I'm referring to this:
> >
> https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
> >
> > Any help is appreciated.
> >
> > Thanks,
> > Devin
> > _______________________________________________
> > Devel mailing list -- devel(a)acpica.org
> > To unsubscribe send an email to devel-leave(a)acpica.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> _______________________________________________
> Devel mailing list -- devel(a)acpica.org
> To unsubscribe send an email to devel-leave(a)acpica.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 10733 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Devel] Re: Wake On LAN steps for QNX from S5
@ 2020-10-14 17:15 Will Miles
  0 siblings, 0 replies; 4+ messages in thread
From: Will Miles @ 2020-10-14 17:15 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 7319 bytes --]

Hi Devin,

I did some of the initial porting work to compile ACPICA for use in QNX 
userspace.   I'm glad to hear you've had some success with it!

I can't speak for current revisions; but at least as far as the BSP 
supplied with QNX 6.6, QNX's e1000 driver explicitly disables 
wake-on-LAN when loaded by writing to the wakeup control (WUC) register 
on the device.   My recommendation would be to get a copy of the 
datasheet for your device 
(http://www.intel.com/content/www/us/en/embedded/products/networking/ethernet-connection-i219-datasheet.html 
?) and then, as part of your shutdown routine, explicitly terminate the 
QNX network drivers and then manually re-enable APM wakeup by directly 
interacting with the ethernet device registers.

Hope this is of some help,

-Will

On 10/14/2020 12:02 PM, devinsteffler(a)gmail.com wrote:
> Hello,
>
> I raised a case with QNX about this last week but I haven't heard back from them yet. In the meantime, I'm wondering if the kind folks at ACPICA might be able to help with this. I'm hoping that I'm not missing anything obvious.
>
> I'm using an Intel based x86_64 PC with QNX on it (an Intel NUC NUC7i5DNB to be precise). QNX does not have ACPI support built-in. As an example, QNX does not have a way to read battery status or power down (soft off, S5) an x86 based PC.
>
> So I'm making my own ACPI driver for QNX based off of the ACPICA code base. I've done this previously with success for reading AC power/battery information on laptops using things like _PSR from a ACPI0003 device as well as _STA, _BIF, and _BST from PNP0C0A devices.
>
> Now I would like to try and get Wake On LAN working from a soft off (S5) state.
>
> I'm able to enter S5 via the following code:
> -----------------------------------------------
> 	AcpiEnterSleepStatePrep(5);
>
> 	// disable interrupts, optional?
> 	ThreadCtl( _NTO_TCTL_IO, 0 );
> 	InterruptDisable();
>
> 	AcpiEnterSleepState(5);
> -----------------------------------------------
>
> Unfortunately, when I enter S5 using that code, then Wake On LAN no longer works when powered off. Although as you'll see below, Wake On LAN no longer works if I go to S5 after having used the QNX e1000 driver. If I don't use the e1000 driver then Wake On LAN works. Although, I need the QNX e1000 driver to have networking when running.
>
> I've made the following observations:
> - When I boot my device with Linux and power it off using software, then I'm able to Wake On LAN just fine.
>    - in this case, the NIC LEDs blink while powered off
> - If I boot into QNX and hold the power button for 10 seconds or so, it powers off and Wake On LAN works (whether the QNX e1000 driver is loaded or not).
>    - in this case, the NIC LEDs blink while powered off
> - If I boot into QNX and use software (the code above) to power down, then Wake On LAN does not work.
>    - in this case, the NIC LEDs remain off while powered off
> - If I boot into QNX but do not start their networking stack (or their e1000 driver) and use software (the code above) to power down, then Wake On LAN does work.
>    - in this case, the NIC LEDs blink while powered off (they momentarily stop blinking, but then blink again shortly afterwards)
>
> QNX has a pci-tool (similar to Linux's lspci tool). I can use it to see the following:
> ----------------------------------------------------------------------------------
> # pci-tool -vvvv -d0:31:6
>
> B000:D31:F06 @ idx 0
>          vid/did: 8086/156f
>                  Intel Corporation, <device id - unknown>
>          class/subclass/reg: 02/00/00
>                  Ethernet Network Controller
> <snip>
>          PMI Capability Details
>                  PMI supported states: D0 D3hot D3cold *
>                  PMI current state: D0
>                  PME's supported from states: D0 D3hot D3cold *
>                  PME's are disabled
>                  PMI data: [idx] val scale
>                          [00]  00  01  [01]  --  --  [02]  --  --  [03]  00  01
>                          [04]  00  01  [05]  --  --  [06]  --  --  [07]  00  01
>                          [08]  --  --  [09]  --  --  [10]  --  --  [11]  --  --
>                          [12]  --  --  [13]  --  --  [14]  --  --  [15]  --  --
> ----------------------------------------------------------------------------------
>
> I can use this method in ACPI to get "PME's are enabled" output:
> \_SB.PCI0.GLAN._DSW
>
> i.e.
> ----------------------------------------------------------------------------------
> # pci-tool -vvvv -d0:31:6
>
> B000:D31:F06 @ idx 0
> <snip>
>          PMI Capability Details
>                  PMI supported states: D0 D3hot D3cold *
>                  PMI current state: D0
>                  PME's supported from states: D0 D3hot D3cold *
>                  PME's are enabled
>                  PMI data: [idx] val scale
>                          [00]  00  01  [01]  --  --  [02]  --  --  [03]  00  01
>                          [04]  00  01  [05]  --  --  [06]  --  --  [07]  00  01
>                          [08]  --  --  [09]  --  --  [10]  --  --  [11]  --  --
>                          [12]  --  --  [13]  --  --  [14]  --  --  [15]  --  --
> ----------------------------------------------------------------------------------
>
> Although that doesn't help.
>
> Do I need to get the PMI current state to be D3hot prior to entering S5 in order for Wake On LAN to work?
>
> However, I noticed that if I boot without the QNX e1000 driver, then Wake On LAN works by just going to S5 alone, without _DSW. In this case:
> ----------------------------------------------------------------------------------
> # pci-tool -vvvv -d0:31:6
>
> B000:D31:F06 @ idx 0
> <snip>
>          PMI Capability Details
>                  PMI supported states: D0 D3hot D3cold *
>                  PMI current state: D0
>                  PME's supported from states: D0 D3hot D3cold *
>                  PME's are disabled
>                  PMI data: [idx] val scale
>                          [00]  00  01  [01]  --  --  [02]  --  --  [03]  00  01
>                          [04]  00  01  [05]  --  --  [06]  --  --  [07]  00  01
>                          [08]  --  --  [09]  --  --  [10]  --  --  [11]  --  --
>                          [12]  --  --  [13]  --  --  [14]  --  --  [15]  --  --
> ----------------------------------------------------------------------------------
>
> It's almost like the QNX e1000 driver is putting the NIC into some state that EFI does not recover from when transitioning to S5. Maybe the PHY is being turned off. If this is the case, then should calls to things like _DSW, _PRW (and enabling GPE it returns), or even the LPI function 5 put the PHY back on? The NIC LEDs shut off at the same time as the power LED when entering S5 and do not come back on.
>
> For LPI I'm referring to this:
> https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
>
> Any help is appreciated.
>
> Thanks,
> Devin
> _______________________________________________
> Devel mailing list -- devel(a)acpica.org
> To unsubscribe send an email to devel-leave(a)acpica.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-10-15 13:19 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-15 11:30 [Devel] Re: Wake On LAN steps for QNX from S5 Devin Steffler
  -- strict thread matches above, loose matches on Subject: below --
2020-10-15 13:19 Will Miles
2020-10-14 22:18 Devin Steffler
2020-10-14 17:15 Will Miles

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.