From: Aaron Lu <aaron.lu@intel.com>
To: "Zheng, Lv" <lv.zheng@intel.com>,
Bastien Nocera <hadess@hadess.net>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "dev@mgautier.fr" <dev@mgautier.fr>
Subject: Re: Ghost Lid switch on Baytrail tablet
Date: Tue, 21 Jul 2015 13:55:37 +0800 [thread overview]
Message-ID: <55ADDED9.8060901@intel.com> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E8802738695@SHSMSX101.ccr.corp.intel.com>
On 07/21/2015 09:30 AM, Zheng, Lv wrote:
> Hi,
>
> If the issue is already identified and confirmed:
> For example, you've confirmed the QR_EC(0x14) can only arrive when the keyboard accessory is plugged in.
> Then please ignore my previous reply.
> I don't have idea about handling a LID that always returns "closed" when the keyboard accessory is not plugged in.
Perhaps the LID status should be ignored when the device is in tablet
mode?
In the meantime, I took a look at two tablets here: ASUS T100 and Onda
V975W, both are baytrail-T tablet while the T100 has a keyboard dock.
For T100, its _LID return the value of GPO2.LIDZ, which has an initial
value of 1: "Name(LIDZ, One)" and on LID events, LIDZ will be assigned
proper value; and for Onda V975W, it doesn't define the LID acpi device.
So these two devices don't have this problem.
-Aaron
>
> Thanks
> -Lv
>
>> From: Zheng, Lv
>> Sent: Tuesday, July 21, 2015 8:23 AM
>>
>> Hi,
>>
>> The _LID returns LIDS:
>> Device (LID)
>> {
>> Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID
>> Name (LIDS, Zero)
>> Method (_LID, 0, NotSerialized) // _LID: Lid Status
>> {
>> Return (LIDS) /* \_SB_.LID_.LIDS */
>> }
>> }
>> All LIDS related code can be found:
>> Line 132: LIDS, 8,
>> Line 5400: PARM |= (LIDS << 0x10)
>> Line 5566: PARM = (LIDS << 0x08)
>> Line 11792: ^^LID.LIDS = Zero
>> * Line 11802: ^^LID.LIDS = One
>> Line 11906: Name (LIDS, Zero)
>> Line 11909: Return (LIDS) /* \_SB_.LID_.LIDS */
>> The value is only set by Q14 (marked by * above):
>> Method (Q14, 0, NotSerialized)
>> {
>> P8XH (One, 0xBB)
>> P8XH (Zero, 0x14)
>> ^^LID.LIDS = One
>> Notify (LID, 0x80) // Status Change
>> P8XH (One, 0xBB)
>> P8XH (Zero, 0xA4)
>> }
>> If QR_EC(0x14) cannot arrive to the OSPMs as early as possible, then the default LIDS=0 value may cause problem.
>> We need EC debug log to track if QR_EC(0x14) can arrive earlier.
>>
>> You can uncomment the following line from drivers/acpi/ec.c and rebuild the kernel:
>> /* #define DEBUG */
>>
>> Send the dmesg output (before suspending) to us.
>>
>> Thanks and best regards
>> -Lv
>>
>>> -----Original Message-----
>>> From: Bastien Nocera [mailto:hadess@hadess.net]
>>> Sent: Sunday, July 19, 2015 8:43 AM
>>> To: Rafael J. Wysocki; Len Brown; linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org
>>> Cc: dev@mgautier.fr
>>> Subject: Ghost Lid switch on Baytrail tablet
>>>
>>> Hey,
>>>
>>> This tablet:
>>> http://www.amazon.com/WinBook-10-1-Inch-Windows-full-size-Display/dp/B00N9ZG5U2/
>>> doesn't have a physical lid switch unless you plug the keyboard accessory to it.
>>>
>>> But it thinks that there is a lid, and that it's closed, making logind
>>> suspend the machine after about 30 seconds.
>>>
>>> I'm currently testing this on a 4.0 kernel, as there have been
>>> regressions on Baytrail with 4.1 and 4.2rcs.
>>>
>>> The DSDT for that tablet:
>>> https://people.gnome.org/~hadess/Winbook%20TW100%20DSDT.dsl
>>>
>>> Any ideas how to handle this sort of device?
>>>
>>> Cheers
> N�����r��y���b�X��ǧv�^�){.n�+����{�i�b�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�i
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Aaron Lu <aaron.lu@intel.com>
To: "Zheng, Lv" <lv.zheng@intel.com>,
Bastien Nocera <hadess@hadess.net>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "dev@mgautier.fr" <dev@mgautier.fr>
Subject: Re: Ghost Lid switch on Baytrail tablet
Date: Tue, 21 Jul 2015 13:55:37 +0800 [thread overview]
Message-ID: <55ADDED9.8060901@intel.com> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E8802738695@SHSMSX101.ccr.corp.intel.com>
On 07/21/2015 09:30 AM, Zheng, Lv wrote:
> Hi,
>
> If the issue is already identified and confirmed:
> For example, you've confirmed the QR_EC(0x14) can only arrive when the keyboard accessory is plugged in.
> Then please ignore my previous reply.
> I don't have idea about handling a LID that always returns "closed" when the keyboard accessory is not plugged in.
Perhaps the LID status should be ignored when the device is in tablet
mode?
In the meantime, I took a look at two tablets here: ASUS T100 and Onda
V975W, both are baytrail-T tablet while the T100 has a keyboard dock.
For T100, its _LID return the value of GPO2.LIDZ, which has an initial
value of 1: "Name(LIDZ, One)" and on LID events, LIDZ will be assigned
proper value; and for Onda V975W, it doesn't define the LID acpi device.
So these two devices don't have this problem.
-Aaron
>
> Thanks
> -Lv
>
>> From: Zheng, Lv
>> Sent: Tuesday, July 21, 2015 8:23 AM
>>
>> Hi,
>>
>> The _LID returns LIDS:
>> Device (LID)
>> {
>> Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID
>> Name (LIDS, Zero)
>> Method (_LID, 0, NotSerialized) // _LID: Lid Status
>> {
>> Return (LIDS) /* \_SB_.LID_.LIDS */
>> }
>> }
>> All LIDS related code can be found:
>> Line 132: LIDS, 8,
>> Line 5400: PARM |= (LIDS << 0x10)
>> Line 5566: PARM = (LIDS << 0x08)
>> Line 11792: ^^LID.LIDS = Zero
>> * Line 11802: ^^LID.LIDS = One
>> Line 11906: Name (LIDS, Zero)
>> Line 11909: Return (LIDS) /* \_SB_.LID_.LIDS */
>> The value is only set by Q14 (marked by * above):
>> Method (Q14, 0, NotSerialized)
>> {
>> P8XH (One, 0xBB)
>> P8XH (Zero, 0x14)
>> ^^LID.LIDS = One
>> Notify (LID, 0x80) // Status Change
>> P8XH (One, 0xBB)
>> P8XH (Zero, 0xA4)
>> }
>> If QR_EC(0x14) cannot arrive to the OSPMs as early as possible, then the default LIDS=0 value may cause problem.
>> We need EC debug log to track if QR_EC(0x14) can arrive earlier.
>>
>> You can uncomment the following line from drivers/acpi/ec.c and rebuild the kernel:
>> /* #define DEBUG */
>>
>> Send the dmesg output (before suspending) to us.
>>
>> Thanks and best regards
>> -Lv
>>
>>> -----Original Message-----
>>> From: Bastien Nocera [mailto:hadess@hadess.net]
>>> Sent: Sunday, July 19, 2015 8:43 AM
>>> To: Rafael J. Wysocki; Len Brown; linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org
>>> Cc: dev@mgautier.fr
>>> Subject: Ghost Lid switch on Baytrail tablet
>>>
>>> Hey,
>>>
>>> This tablet:
>>> http://www.amazon.com/WinBook-10-1-Inch-Windows-full-size-Display/dp/B00N9ZG5U2/
>>> doesn't have a physical lid switch unless you plug the keyboard accessory to it.
>>>
>>> But it thinks that there is a lid, and that it's closed, making logind
>>> suspend the machine after about 30 seconds.
>>>
>>> I'm currently testing this on a 4.0 kernel, as there have been
>>> regressions on Baytrail with 4.1 and 4.2rcs.
>>>
>>> The DSDT for that tablet:
>>> https://people.gnome.org/~hadess/Winbook%20TW100%20DSDT.dsl
>>>
>>> Any ideas how to handle this sort of device?
>>>
>>> Cheers
> N�����r��y���b�X��ǧv�^�){.n�+����{�i�b�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�i
>
next prev parent reply other threads:[~2015-07-21 5:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-19 0:42 Ghost Lid switch on Baytrail tablet Bastien Nocera
2015-07-21 0:22 ` Zheng, Lv
2015-07-21 0:22 ` Zheng, Lv
2015-07-21 1:30 ` Zheng, Lv
2015-07-21 1:30 ` Zheng, Lv
2015-07-21 5:55 ` Aaron Lu [this message]
2015-07-21 5:55 ` Aaron Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55ADDED9.8060901@intel.com \
--to=aaron.lu@intel.com \
--cc=dev@mgautier.fr \
--cc=hadess@hadess.net \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.