All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Duggan <aduggan@synaptics.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	<linux-kernel@vger.kernel.org>, <linux-input@vger.kernel.org>
Subject: Re: [PATCH 0/8] PS
Date: Fri, 10 Mar 2017 12:31:01 -0800	[thread overview]
Message-ID: <ed26e9fd-4884-d71c-8afc-905c0d85f836@synaptics.com> (raw)
In-Reply-To: <20170310201240.GB35542@dtor-ws>

On 03/10/2017 12:12 PM, Dmitry Torokhov wrote:
> On Fri, Mar 10, 2017 at 10:56:33AM -0800, Andrew Duggan wrote:
>> On 03/10/2017 09:52 AM, Dmitry Torokhov wrote:
>>> On Fri, Mar 10, 2017 at 04:57:35PM +0100, Benjamin Tissoires wrote:
>>>> Hi Dmitry,
>>>>
>>>> On Mar 09 2017 or thereabouts, Dmitry Torokhov wrote:
>>>>> Hi,
>>>>>
>>>>> This is refresh of Benjamin's patches trying to bridge PS/2 and SMbus
>>>>> devices for better support of Synaptics RMI4 touchpads (and Elans later).
>>>> Thanks!
>>>>
>>>> I have some issues/comments and am still working on those. Here are some
>>>> general comments:
>>>>
>>>>> The main difference is that we do not have platform device, as it only
>>>>> adds another indirection level, and have psmouse create SMBus companion
>>>> The purpose of having the platform device was to not have dependency
>>>> between psmouse and I2C. Right now I think that patch 6/8 will fail to
>>>> compile if I2C=m and PSMOUSE=y (I may be wrong).
>>> This is taken care by the following guards in users if MOUSE_PS2_SMBUS:
>>>
>>> depends on I2C=y || I2C=MOUSE_PS2
>>>
>>> I am perfectly fine to tie psmouse to I2C *core*, we do not need to have
>>> adapters loaded for it to work (hopefully).
>>>
>>>>> directly. Because serio ports complete registration asynchronously, we do
>>>>> not deadlock on psmouse_mutex when even if we have a pass-through port.
>>>>> (Frankly we need to revisit this whole serio and psmouse thing, use of
>>>>> global serio_mutex and psmouse_mutex is hurting us; they were needed when
>>>>> driver core could not recursively iterate over device and driver lists).
>>>> Agree, this is a giant PITA.
>>>>
>>>>> We also do not allow overriding serio driver, instead we teach psmouse
>>>>> about "special" devices and let it continue own the serio port and make
>>>>> sure nobody else touches it.
>>>>>
>>>>> To work around issue with psmouse_reconnect() running sometimes too late,
>>>>> we add "fast reconnect" option to serio. Not too pretty, but gets the job
>>>>> done. We may need to revisit whole serio PM story later and stop "cheating"
>>>>> and pretending that device is resumed when it is not, but for that we need
>>>>> to teach PM core about devices that are OK not to wait for before resuming
>>>>> userspace. Anyway, much bigger topic for later.
>>>> I thought there was already the ability to say that a driver needs to be
>>>> run in a different thread for PM functions (IIRC i2c-hid uses
>>>> device_enable_async_suspend(&client->dev); and this "should" do the
>>>> trick).
>>> The issue is that currently asynchronous resume still has to complete
>>> before we start resuming userspace, as PS/2 is way too slow. So the
>>> current solution marks device as resumed right away, and mouse may
>>> become responsive 2 seconds later, but that is good as we do not idly
>>> sit and wait but have userspace start turning on the screen and do other
>>> useful stuff. Maybe user can already start typing their password into
>>> screen locker.
>>>
>>> We would need to give a way to drivers to indicate to PM core just how
>>> asynchronous our resume can be.
>>>
>>>>> This seems to be working on X1 Carbon and also not breaking my HP 1040 with
>>>>> forcepad (unfortunately it seems to be using some other SMBus controller
>>>>> for connecting Synaptics, as I see nothing at 0x2c when loading i2c-i801).
>>>> Well, on my T450, the SMBus connection is dead too. I can't seem to talk
>>>> to the device at all. This happens when the firmware believes it needs
>>>> to stay on PS/2 and gets completely deaf to I2C. I solved this by
>>>> calling psmouse_deactivate(), but this time, it looks like some other
>>>> function needs to be called.
>>>>
>>>> I'll keep investigating and report back.
>>> I've heard a rumors that HP 1020 uses a Microtech SMbus controller for
>>> its touchpad, it could be that 1040 is similar.
>>>
>>> When your SMBus connection is dead do you see anything on the bus? At
>>> that address? Or it is completely unresponsive?
>> Try the I2C address 0x20 for the HP forcepad. I have gotten previous
>> versions of Benjamin's SMBus patches working on a similar system. It
>> is a HP Elitebook Folio 940 and the forcepad was at address 0x20 and
>> it was on the i801 bus. The HP 1020 does have a microchip I2C
>> controller, but thats connected to a HID / I2C touchpad. The 1020
>> was a one off so the 1040 should be the more common SMBus
>> implementation.
>>
>> I also have not been able to get this patch series to successfully
>> switch over to SMBus mode. But, I have not had a chance to do
>> anything besides apply the patches and build. This is the output
>> from a Lenovo W541:
>>
>> [    9.674826] psmouse serio1: synaptics: queried max coordinates: x
>> [..5676], y [..4758]
>> [    9.705273] psmouse serio1: synaptics: queried min coordinates: x
>> [1266..], y [1096..]
>> [    9.705276] psmouse serio1: synaptics: Trying to set up SMBus access
>> [    9.707946] psmouse serio1: synaptics: SMbus companion is not ready yet
>> [    9.764848] psmouse serio1: synaptics: Touchpad model: 1, fw:
>> 8.1, id: 0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x10000, board
>> id: 3053, fw id: 2560
>> [    9.764853] psmouse serio1: synaptics: serio: Synaptics
>> pass-through port at isa0060/serio1/input0
>> [   10.418268] psmouse serio2: trackpoint: IBM TrackPoint firmware:
>> 0x0e, buttons: 3/3
>> ...
>> [   27.112954] psmouse serio1: synaptics: queried max coordinates: x
>> [..5676], y [..4758]
>> [   27.142555] psmouse serio1: synaptics: queried min coordinates: x
>> [1266..], y [1096..]
>> [   27.142559] psmouse serio1: synaptics: Trying to set up SMBus access
>> [   27.169776] psmouse serio1: synaptics: SMbus companion is not ready yet
>> [   27.226071] psmouse serio1: synaptics: Touchpad model: 1, fw:
>> 8.1, id: 0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x10000, board
>> id: 3053, fw id: 2560
>> [   27.226087] psmouse serio1: synaptics: serio: Synaptics
>> pass-through port at isa0060/serio1/input0
>> [   27.880282] psmouse serio3: trackpoint: IBM TrackPoint firmware:
>> 0x0e, buttons: 3/3
> Yay, that works:
>
> [  980.124573] psmouse serio3: synaptics: queried max coordinates: x [..5676], y [..4690]
> [  980.155902] psmouse serio3: synaptics: queried min coordinates: x [1266..], y [1162..]
> [  980.155915] psmouse serio3: synaptics: Trying to set up SMBus access
> [  980.229405] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2685-009, fw id: 1608298
> [  980.293225] input: Synaptics TM2685-009 as /devices/rmi4-00/input/input42
> [  980.305824] rmi4_smbus 9-0020: registered rmi smb driver at 0x20.
>
> Thanks Andrew!
>
Cool! FYI, forcepads don't have a F30 so currently there is nothing to 
report BTN_LEFT or BUTTONPAD which will probably confuse userspace about 
what type of device it is. I have a patch which I worked on a year ago 
for F21 which is the force function for these devices. It will report a 
click when the firmware determines that a certain amount of force has 
been applied. I can take a look at that patch again and submit it when I 
get a chance now that we are closer to getting these device working in 
RMI mode.

Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Duggan <aduggan@synaptics.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [PATCH 0/8] PS
Date: Fri, 10 Mar 2017 12:31:01 -0800	[thread overview]
Message-ID: <ed26e9fd-4884-d71c-8afc-905c0d85f836@synaptics.com> (raw)
In-Reply-To: <20170310201240.GB35542@dtor-ws>

On 03/10/2017 12:12 PM, Dmitry Torokhov wrote:
> On Fri, Mar 10, 2017 at 10:56:33AM -0800, Andrew Duggan wrote:
>> On 03/10/2017 09:52 AM, Dmitry Torokhov wrote:
>>> On Fri, Mar 10, 2017 at 04:57:35PM +0100, Benjamin Tissoires wrote:
>>>> Hi Dmitry,
>>>>
>>>> On Mar 09 2017 or thereabouts, Dmitry Torokhov wrote:
>>>>> Hi,
>>>>>
>>>>> This is refresh of Benjamin's patches trying to bridge PS/2 and SMbus
>>>>> devices for better support of Synaptics RMI4 touchpads (and Elans later).
>>>> Thanks!
>>>>
>>>> I have some issues/comments and am still working on those. Here are some
>>>> general comments:
>>>>
>>>>> The main difference is that we do not have platform device, as it only
>>>>> adds another indirection level, and have psmouse create SMBus companion
>>>> The purpose of having the platform device was to not have dependency
>>>> between psmouse and I2C. Right now I think that patch 6/8 will fail to
>>>> compile if I2C=m and PSMOUSE=y (I may be wrong).
>>> This is taken care by the following guards in users if MOUSE_PS2_SMBUS:
>>>
>>> depends on I2C=y || I2C=MOUSE_PS2
>>>
>>> I am perfectly fine to tie psmouse to I2C *core*, we do not need to have
>>> adapters loaded for it to work (hopefully).
>>>
>>>>> directly. Because serio ports complete registration asynchronously, we do
>>>>> not deadlock on psmouse_mutex when even if we have a pass-through port.
>>>>> (Frankly we need to revisit this whole serio and psmouse thing, use of
>>>>> global serio_mutex and psmouse_mutex is hurting us; they were needed when
>>>>> driver core could not recursively iterate over device and driver lists).
>>>> Agree, this is a giant PITA.
>>>>
>>>>> We also do not allow overriding serio driver, instead we teach psmouse
>>>>> about "special" devices and let it continue own the serio port and make
>>>>> sure nobody else touches it.
>>>>>
>>>>> To work around issue with psmouse_reconnect() running sometimes too late,
>>>>> we add "fast reconnect" option to serio. Not too pretty, but gets the job
>>>>> done. We may need to revisit whole serio PM story later and stop "cheating"
>>>>> and pretending that device is resumed when it is not, but for that we need
>>>>> to teach PM core about devices that are OK not to wait for before resuming
>>>>> userspace. Anyway, much bigger topic for later.
>>>> I thought there was already the ability to say that a driver needs to be
>>>> run in a different thread for PM functions (IIRC i2c-hid uses
>>>> device_enable_async_suspend(&client->dev); and this "should" do the
>>>> trick).
>>> The issue is that currently asynchronous resume still has to complete
>>> before we start resuming userspace, as PS/2 is way too slow. So the
>>> current solution marks device as resumed right away, and mouse may
>>> become responsive 2 seconds later, but that is good as we do not idly
>>> sit and wait but have userspace start turning on the screen and do other
>>> useful stuff. Maybe user can already start typing their password into
>>> screen locker.
>>>
>>> We would need to give a way to drivers to indicate to PM core just how
>>> asynchronous our resume can be.
>>>
>>>>> This seems to be working on X1 Carbon and also not breaking my HP 1040 with
>>>>> forcepad (unfortunately it seems to be using some other SMBus controller
>>>>> for connecting Synaptics, as I see nothing at 0x2c when loading i2c-i801).
>>>> Well, on my T450, the SMBus connection is dead too. I can't seem to talk
>>>> to the device at all. This happens when the firmware believes it needs
>>>> to stay on PS/2 and gets completely deaf to I2C. I solved this by
>>>> calling psmouse_deactivate(), but this time, it looks like some other
>>>> function needs to be called.
>>>>
>>>> I'll keep investigating and report back.
>>> I've heard a rumors that HP 1020 uses a Microtech SMbus controller for
>>> its touchpad, it could be that 1040 is similar.
>>>
>>> When your SMBus connection is dead do you see anything on the bus? At
>>> that address? Or it is completely unresponsive?
>> Try the I2C address 0x20 for the HP forcepad. I have gotten previous
>> versions of Benjamin's SMBus patches working on a similar system. It
>> is a HP Elitebook Folio 940 and the forcepad was at address 0x20 and
>> it was on the i801 bus. The HP 1020 does have a microchip I2C
>> controller, but thats connected to a HID / I2C touchpad. The 1020
>> was a one off so the 1040 should be the more common SMBus
>> implementation.
>>
>> I also have not been able to get this patch series to successfully
>> switch over to SMBus mode. But, I have not had a chance to do
>> anything besides apply the patches and build. This is the output
>> from a Lenovo W541:
>>
>> [    9.674826] psmouse serio1: synaptics: queried max coordinates: x
>> [..5676], y [..4758]
>> [    9.705273] psmouse serio1: synaptics: queried min coordinates: x
>> [1266..], y [1096..]
>> [    9.705276] psmouse serio1: synaptics: Trying to set up SMBus access
>> [    9.707946] psmouse serio1: synaptics: SMbus companion is not ready yet
>> [    9.764848] psmouse serio1: synaptics: Touchpad model: 1, fw:
>> 8.1, id: 0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x10000, board
>> id: 3053, fw id: 2560
>> [    9.764853] psmouse serio1: synaptics: serio: Synaptics
>> pass-through port at isa0060/serio1/input0
>> [   10.418268] psmouse serio2: trackpoint: IBM TrackPoint firmware:
>> 0x0e, buttons: 3/3
>> ...
>> [   27.112954] psmouse serio1: synaptics: queried max coordinates: x
>> [..5676], y [..4758]
>> [   27.142555] psmouse serio1: synaptics: queried min coordinates: x
>> [1266..], y [1096..]
>> [   27.142559] psmouse serio1: synaptics: Trying to set up SMBus access
>> [   27.169776] psmouse serio1: synaptics: SMbus companion is not ready yet
>> [   27.226071] psmouse serio1: synaptics: Touchpad model: 1, fw:
>> 8.1, id: 0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x10000, board
>> id: 3053, fw id: 2560
>> [   27.226087] psmouse serio1: synaptics: serio: Synaptics
>> pass-through port at isa0060/serio1/input0
>> [   27.880282] psmouse serio3: trackpoint: IBM TrackPoint firmware:
>> 0x0e, buttons: 3/3
> Yay, that works:
>
> [  980.124573] psmouse serio3: synaptics: queried max coordinates: x [..5676], y [..4690]
> [  980.155902] psmouse serio3: synaptics: queried min coordinates: x [1266..], y [1162..]
> [  980.155915] psmouse serio3: synaptics: Trying to set up SMBus access
> [  980.229405] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2685-009, fw id: 1608298
> [  980.293225] input: Synaptics TM2685-009 as /devices/rmi4-00/input/input42
> [  980.305824] rmi4_smbus 9-0020: registered rmi smb driver at 0x20.
>
> Thanks Andrew!
>
Cool! FYI, forcepads don't have a F30 so currently there is nothing to 
report BTN_LEFT or BUTTONPAD which will probably confuse userspace about 
what type of device it is. I have a patch which I worked on a year ago 
for F21 which is the force function for these devices. It will report a 
click when the firmware determines that a certain amount of force has 
been applied. I can take a look at that patch again and submit it when I 
get a chance now that we are closer to getting these device working in 
RMI mode.

Andrew


  reply	other threads:[~2017-03-10 20:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09 22:16 [PATCH 0/8] PS Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 1/8] i2c: export i2c_client_type structure Dmitry Torokhov
2017-03-09 23:12   ` Wolfram Sang
2017-03-09 23:46     ` Dmitry Torokhov
2017-03-09 23:51       ` Dmitry Torokhov
2017-03-13 13:50     ` Jean Delvare
2017-03-15 23:50       ` Dmitry Torokhov
2017-04-01 16:06   ` Wolfram Sang
2017-04-01 16:43     ` Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 2/8] Input: serio - add fast reconnect option Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 3/8] Input: psmouse - implement " Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 4/8] Input: psmouse - store pointer to current protocol Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 5/8] Input: psmouse - introduce notion of SMBus companions Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 6/8] Input: psmouse - add support for " Dmitry Torokhov
2017-03-11 15:13   ` kbuild test robot
2017-03-09 22:16 ` [PATCH 7/8] Input: synaptics - split device info into a separate structure Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 8/8] Input: synaptics - add support for Intertouch devices Dmitry Torokhov
2017-03-09 23:53 ` [PATCH 6/8] Input: psmouse - add support for SMBus companions Dmitry Torokhov
2017-03-10 17:55   ` Benjamin Tissoires
2017-03-10 18:16     ` Dmitry Torokhov
2017-03-10 15:57 ` [PATCH 0/8] PS Benjamin Tissoires
2017-03-10 17:52   ` Dmitry Torokhov
2017-03-10 18:04     ` Benjamin Tissoires
2017-03-10 18:10       ` Dmitry Torokhov
2017-03-10 20:25         ` Dmitry Torokhov
2017-03-10 18:56     ` Andrew Duggan
2017-03-10 18:56       ` Andrew Duggan
2017-03-10 20:12       ` Dmitry Torokhov
2017-03-10 20:31         ` Andrew Duggan [this message]
2017-03-10 20:31           ` Andrew Duggan

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=ed26e9fd-4884-d71c-8afc-905c0d85f836@synaptics.com \
    --to=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.