Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-27 Thread Benjamin Tissoires 
On Jun 24 2016 or thereabouts, Dmitry Torokhov wrote:
> On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> > On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > > +
> > > > +static struct i2c_driver rmi_smb_driver = {
> > > > +   .driver = {
> > > > +   .owner  = THIS_MODULE,
> > > > +   .name   = "rmi4_smbus",
> > > > +   .pm = _smb_pm,
> > > > +   .resume = rmi_smb_resume,
> > > 
> > > Why rmi_smb_resume is not part of rmi_smb_pm?
> > > 
> > 
> > This is because rmi_smbus device both have a PS/2 interface and a SMBus
> > one. I'll have to check again now that I have a slightly different way
> > of binding smbus devices in my tree, but the issue was:
> > - having resume part of pm means it will get caught by PM directly
> > - the PS/2 node gets also resumed by PM
> > - calling PS/2 commands during resume switches the devices back into
> >   PS/2 and stops the SMBus communication.
> > 
> > So it's easier to wait only for the PS/2 PM resume call which will call
> > the SMBus resume function when the device is in a proper state.
> > 
> > I'll send out the updated patch with your comments next week hopefully.
> 
> Hmm, I think you will have to walk me through resume process. How do we
> tie in PS/2 and I2C on these devices abd have PS/2 code call into this
> driver?
> 

Sure.

For starters, here is my latest WIP (I need to rework on the series for
commit messages and probably squash some patches):
https://github.com/bentiss/linux/commits/synaptics-rmi4-smbus-v4.7-rc4%2B

Then, let me explain the problems we have with those touchpads and the
resume process.

The touchpads are both connected to PS/2 and SMBus as you know. However,
there is no SMBus enumeration entry anywhere in the system. Luckily,
the PS/2 chip is aware of the other bus, and can be polled to
request whether or not we are confronted to a RMI4 over SMBus device
(see 
https://github.com/bentiss/linux/commit/a3e67de764656201522962028bc783fc4b921de3
 )

Of course, to make those touchpads robust with reboots and allow legacy
drivers (PS/2) to use them, the firmware tend to switch back to PS/2 as
soon as you issue a PS/2 reset command or if you send some other PS/2
commands. The problem we have is that if you send some various PS/2
commands to the touchpad, it disconnects from the SMBus entirely (it
took me one year to understand why the device was not showing up on
I2C).

The last interesting fact for those touchpad is that you need to enable
SMBus communication by issuing a SMB_PROTOCOL_VERSION_ADDRESS command.
If you do not issue this after a PS/2 reset, the device is muted over
SMBus.

So, to be sure we can query the touchpad from PS/2 and to control the
PS/2 commands and the resume, I have in the series above a separate PS/2
driver for this touchpad. The regular psmouse driver probes the PS/2
chip, but aborts seeing the SMBus capability. Then rmi_ps2 takes over
and binds to the PS/2 chip to fill in the platform data required by
rmi_smbus 
(https://github.com/bentiss/linux/commit/3ceb7c80ecee17a86b8ae8476211c7498cc823d2)

If we simply unbind the PS/2 node and let it dangling, the serio driver
issues a reconnect after resume on both the PS/2 chip of the touchpad,
and the PS/2 pass-through node of the trackstick.

But if the PS/2 chip of the touchpad is left dangling, the resume
process will first call a reconnect on the pass-through, then on
the touchpad through the enumeration of the serio bus, which will reset
the touchpad and messed up the pass-through node and the rmi-smbus
driver.
So keeping around a reference to the PS/2 node allows to set this node
as a parent of the pass-through trackstick node and guarantees that the
touchpad will be resumed before the trackstick.

One final thing. I tried not having rmi_ps2 calling the .resume callback
of rmi_smbus and keeping rmi_smbus as a PM. But the issue is that the
serio driver sends the reset command in a workqueue as it can takes some
time:

- serio gets resume called -> prepare the worker for the
  resume/reconnect process
- rmi_smbus gets resumed -> OK
- the worker kicks in, reset the PS/2 lines, and shuts down the
  rmi_smbus device


I also tried one thing where I did not bind the PS/2 touchpad at all
(and having some kind of platform driver to bind rmi_smbus). And of
course, grub initializes the touchpad, so it disconnects on I2C and you
can't bind it on SMBus, ever :)


I think that's all I know on these touchpads and this is all the mess I can
present. If you have a better option, I'm all ears as this is not clean,
but I can't figure out a better way.

Cheers,
Benjamin

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-27 Thread Benjamin Tissoires 
On Jun 24 2016 or thereabouts, Dmitry Torokhov wrote:
> On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> > On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > > +
> > > > +static struct i2c_driver rmi_smb_driver = {
> > > > +   .driver = {
> > > > +   .owner  = THIS_MODULE,
> > > > +   .name   = "rmi4_smbus",
> > > > +   .pm = _smb_pm,
> > > > +   .resume = rmi_smb_resume,
> > > 
> > > Why rmi_smb_resume is not part of rmi_smb_pm?
> > > 
> > 
> > This is because rmi_smbus device both have a PS/2 interface and a SMBus
> > one. I'll have to check again now that I have a slightly different way
> > of binding smbus devices in my tree, but the issue was:
> > - having resume part of pm means it will get caught by PM directly
> > - the PS/2 node gets also resumed by PM
> > - calling PS/2 commands during resume switches the devices back into
> >   PS/2 and stops the SMBus communication.
> > 
> > So it's easier to wait only for the PS/2 PM resume call which will call
> > the SMBus resume function when the device is in a proper state.
> > 
> > I'll send out the updated patch with your comments next week hopefully.
> 
> Hmm, I think you will have to walk me through resume process. How do we
> tie in PS/2 and I2C on these devices abd have PS/2 code call into this
> driver?
> 

Sure.

For starters, here is my latest WIP (I need to rework on the series for
commit messages and probably squash some patches):
https://github.com/bentiss/linux/commits/synaptics-rmi4-smbus-v4.7-rc4%2B

Then, let me explain the problems we have with those touchpads and the
resume process.

The touchpads are both connected to PS/2 and SMBus as you know. However,
there is no SMBus enumeration entry anywhere in the system. Luckily,
the PS/2 chip is aware of the other bus, and can be polled to
request whether or not we are confronted to a RMI4 over SMBus device
(see 
https://github.com/bentiss/linux/commit/a3e67de764656201522962028bc783fc4b921de3
 )

Of course, to make those touchpads robust with reboots and allow legacy
drivers (PS/2) to use them, the firmware tend to switch back to PS/2 as
soon as you issue a PS/2 reset command or if you send some other PS/2
commands. The problem we have is that if you send some various PS/2
commands to the touchpad, it disconnects from the SMBus entirely (it
took me one year to understand why the device was not showing up on
I2C).

The last interesting fact for those touchpad is that you need to enable
SMBus communication by issuing a SMB_PROTOCOL_VERSION_ADDRESS command.
If you do not issue this after a PS/2 reset, the device is muted over
SMBus.

So, to be sure we can query the touchpad from PS/2 and to control the
PS/2 commands and the resume, I have in the series above a separate PS/2
driver for this touchpad. The regular psmouse driver probes the PS/2
chip, but aborts seeing the SMBus capability. Then rmi_ps2 takes over
and binds to the PS/2 chip to fill in the platform data required by
rmi_smbus 
(https://github.com/bentiss/linux/commit/3ceb7c80ecee17a86b8ae8476211c7498cc823d2)

If we simply unbind the PS/2 node and let it dangling, the serio driver
issues a reconnect after resume on both the PS/2 chip of the touchpad,
and the PS/2 pass-through node of the trackstick.

But if the PS/2 chip of the touchpad is left dangling, the resume
process will first call a reconnect on the pass-through, then on
the touchpad through the enumeration of the serio bus, which will reset
the touchpad and messed up the pass-through node and the rmi-smbus
driver.
So keeping around a reference to the PS/2 node allows to set this node
as a parent of the pass-through trackstick node and guarantees that the
touchpad will be resumed before the trackstick.

One final thing. I tried not having rmi_ps2 calling the .resume callback
of rmi_smbus and keeping rmi_smbus as a PM. But the issue is that the
serio driver sends the reset command in a workqueue as it can takes some
time:

- serio gets resume called -> prepare the worker for the
  resume/reconnect process
- rmi_smbus gets resumed -> OK
- the worker kicks in, reset the PS/2 lines, and shuts down the
  rmi_smbus device


I also tried one thing where I did not bind the PS/2 touchpad at all
(and having some kind of platform driver to bind rmi_smbus). And of
course, grub initializes the touchpad, so it disconnects on I2C and you
can't bind it on SMBus, ever :)


I think that's all I know on these touchpads and this is all the mess I can
present. If you have a better option, I'm all ears as this is not clean,
but I can't figure out a better way.

Cheers,
Benjamin

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-24 Thread Dmitry Torokhov 
On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > +
> > > +static struct i2c_driver rmi_smb_driver = {
> > > + .driver = {
> > > + .owner  = THIS_MODULE,
> > > + .name   = "rmi4_smbus",
> > > + .pm = _smb_pm,
> > > + .resume = rmi_smb_resume,
> > 
> > Why rmi_smb_resume is not part of rmi_smb_pm?
> > 
> 
> This is because rmi_smbus device both have a PS/2 interface and a SMBus
> one. I'll have to check again now that I have a slightly different way
> of binding smbus devices in my tree, but the issue was:
> - having resume part of pm means it will get caught by PM directly
> - the PS/2 node gets also resumed by PM
> - calling PS/2 commands during resume switches the devices back into
>   PS/2 and stops the SMBus communication.
> 
> So it's easier to wait only for the PS/2 PM resume call which will call
> the SMBus resume function when the device is in a proper state.
> 
> I'll send out the updated patch with your comments next week hopefully.

Hmm, I think you will have to walk me through resume process. How do we
tie in PS/2 and I2C on these devices abd have PS/2 code call into this
driver?

Thanks.

-- 
Dmitry

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-24 Thread Dmitry Torokhov 
On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > +
> > > +static struct i2c_driver rmi_smb_driver = {
> > > + .driver = {
> > > + .owner  = THIS_MODULE,
> > > + .name   = "rmi4_smbus",
> > > + .pm = _smb_pm,
> > > + .resume = rmi_smb_resume,
> > 
> > Why rmi_smb_resume is not part of rmi_smb_pm?
> > 
> 
> This is because rmi_smbus device both have a PS/2 interface and a SMBus
> one. I'll have to check again now that I have a slightly different way
> of binding smbus devices in my tree, but the issue was:
> - having resume part of pm means it will get caught by PM directly
> - the PS/2 node gets also resumed by PM
> - calling PS/2 commands during resume switches the devices back into
>   PS/2 and stops the SMBus communication.
> 
> So it's easier to wait only for the PS/2 PM resume call which will call
> the SMBus resume function when the device is in a proper state.
> 
> I'll send out the updated patch with your comments next week hopefully.

Hmm, I think you will have to walk me through resume process. How do we
tie in PS/2 and I2C on these devices abd have PS/2 code call into this
driver?

Thanks.

-- 
Dmitry

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-24 Thread Benjamin Tissoires 
On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> Hi Benjamin,
> 
> On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > +
> > +struct mapping_table_entry {
> > +   u16 rmiaddr;
> 
> Should be __le16 rmiaddr, otherwise:
> 
>   CHECK   drivers/input/rmi4/rmi_smbus.c
> drivers/input/rmi4/rmi_smbus.c:116:33: warning: incorrect type in assignment 
> (different base types)
> drivers/input/rmi4/rmi_smbus.c:116:33:expected unsigned short [unsigned] 
> [usertype] rmiaddr
> drivers/input/rmi4/rmi_smbus.c:116:33:got restricted __le16 [usertype] 
> 
> 
> > +
> > +static struct i2c_driver rmi_smb_driver;
> > +
> 
> I do not think this forward declaration is needed.
> 
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int rmi_smb_suspend(struct device *dev)
> 
> __maybe_unused instead of #ifdef.
> 
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to suspend device: %d\n", ret);
> > +
> > +   return ret;
> > +}
> > +#endif
> > +
> > +#ifdef CONFIG_PM
> > +static int rmi_smb_runtime_suspend(struct device *dev)
> 
> Same here?
> 
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to suspend device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +
> > +static int rmi_smb_runtime_resume(struct device *dev)
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to resume device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops rmi_smb_pm = {
> > +   SET_SYSTEM_SLEEP_PM_OPS(rmi_smb_suspend, NULL)
> > +   SET_RUNTIME_PM_OPS(rmi_smb_runtime_suspend, rmi_smb_runtime_resume,
> > +  NULL)
> > +};
> > +
> > +static int rmi_smb_resume(struct device *dev)
> > +{
> > +   struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   struct rmi_device *rmi_dev = rmi_smb->xport.rmi_dev;
> > +   int ret;
> > +
> > +   rmi_smb_reset(_smb->xport, 0);
> > +
> > +   rmi_reset(rmi_dev);
> > +
> > +   ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to resume device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct i2c_device_id rmi_id[] = {
> > +   { "rmi4_smbus", 0 },
> > +   { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, rmi_id);
> > +
> > +static struct i2c_driver rmi_smb_driver = {
> > +   .driver = {
> > +   .owner  = THIS_MODULE,
> > +   .name   = "rmi4_smbus",
> > +   .pm = _smb_pm,
> > +   .resume = rmi_smb_resume,
> 
> Why rmi_smb_resume is not part of rmi_smb_pm?
> 

This is because rmi_smbus device both have a PS/2 interface and a SMBus
one. I'll have to check again now that I have a slightly different way
of binding smbus devices in my tree, but the issue was:
- having resume part of pm means it will get caught by PM directly
- the PS/2 node gets also resumed by PM
- calling PS/2 commands during resume switches the devices back into
  PS/2 and stops the SMBus communication.

So it's easier to wait only for the PS/2 PM resume call which will call
the SMBus resume function when the device is in a proper state.

I'll send out the updated patch with your comments next week hopefully.

Cheers,
Benjamin

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-24 Thread Benjamin Tissoires 
On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> Hi Benjamin,
> 
> On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > +
> > +struct mapping_table_entry {
> > +   u16 rmiaddr;
> 
> Should be __le16 rmiaddr, otherwise:
> 
>   CHECK   drivers/input/rmi4/rmi_smbus.c
> drivers/input/rmi4/rmi_smbus.c:116:33: warning: incorrect type in assignment 
> (different base types)
> drivers/input/rmi4/rmi_smbus.c:116:33:expected unsigned short [unsigned] 
> [usertype] rmiaddr
> drivers/input/rmi4/rmi_smbus.c:116:33:got restricted __le16 [usertype] 
> 
> 
> > +
> > +static struct i2c_driver rmi_smb_driver;
> > +
> 
> I do not think this forward declaration is needed.
> 
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int rmi_smb_suspend(struct device *dev)
> 
> __maybe_unused instead of #ifdef.
> 
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to suspend device: %d\n", ret);
> > +
> > +   return ret;
> > +}
> > +#endif
> > +
> > +#ifdef CONFIG_PM
> > +static int rmi_smb_runtime_suspend(struct device *dev)
> 
> Same here?
> 
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to suspend device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +
> > +static int rmi_smb_runtime_resume(struct device *dev)
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   int ret;
> > +
> > +   ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to resume device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops rmi_smb_pm = {
> > +   SET_SYSTEM_SLEEP_PM_OPS(rmi_smb_suspend, NULL)
> > +   SET_RUNTIME_PM_OPS(rmi_smb_runtime_suspend, rmi_smb_runtime_resume,
> > +  NULL)
> > +};
> > +
> > +static int rmi_smb_resume(struct device *dev)
> > +{
> > +   struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> > +   struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> > +   struct rmi_device *rmi_dev = rmi_smb->xport.rmi_dev;
> > +   int ret;
> > +
> > +   rmi_smb_reset(_smb->xport, 0);
> > +
> > +   rmi_reset(rmi_dev);
> > +
> > +   ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> > +   if (ret)
> > +   dev_warn(dev, "Failed to resume device: %d\n", ret);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct i2c_device_id rmi_id[] = {
> > +   { "rmi4_smbus", 0 },
> > +   { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, rmi_id);
> > +
> > +static struct i2c_driver rmi_smb_driver = {
> > +   .driver = {
> > +   .owner  = THIS_MODULE,
> > +   .name   = "rmi4_smbus",
> > +   .pm = _smb_pm,
> > +   .resume = rmi_smb_resume,
> 
> Why rmi_smb_resume is not part of rmi_smb_pm?
> 

This is because rmi_smbus device both have a PS/2 interface and a SMBus
one. I'll have to check again now that I have a slightly different way
of binding smbus devices in my tree, but the issue was:
- having resume part of pm means it will get caught by PM directly
- the PS/2 node gets also resumed by PM
- calling PS/2 commands during resume switches the devices back into
  PS/2 and stops the SMBus communication.

So it's easier to wait only for the PS/2 PM resume call which will call
the SMBus resume function when the device is in a proper state.

I'll send out the updated patch with your comments next week hopefully.

Cheers,
Benjamin

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-23 Thread Dmitry Torokhov 
Hi Benjamin,

On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> +
> +struct mapping_table_entry {
> + u16 rmiaddr;

Should be __le16 rmiaddr, otherwise:

  CHECK   drivers/input/rmi4/rmi_smbus.c
drivers/input/rmi4/rmi_smbus.c:116:33: warning: incorrect type in assignment 
(different base types)
drivers/input/rmi4/rmi_smbus.c:116:33:expected unsigned short [unsigned] 
[usertype] rmiaddr
drivers/input/rmi4/rmi_smbus.c:116:33:got restricted __le16 [usertype] 


> +
> +static struct i2c_driver rmi_smb_driver;
> +

I do not think this forward declaration is needed.

> +
> +#ifdef CONFIG_PM_SLEEP
> +static int rmi_smb_suspend(struct device *dev)

__maybe_unused instead of #ifdef.

> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to suspend device: %d\n", ret);
> +
> + return ret;
> +}
> +#endif
> +
> +#ifdef CONFIG_PM
> +static int rmi_smb_runtime_suspend(struct device *dev)

Same here?

> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to suspend device: %d\n", ret);
> +
> + return 0;
> +}
> +
> +static int rmi_smb_runtime_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to resume device: %d\n", ret);
> +
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops rmi_smb_pm = {
> + SET_SYSTEM_SLEEP_PM_OPS(rmi_smb_suspend, NULL)
> + SET_RUNTIME_PM_OPS(rmi_smb_runtime_suspend, rmi_smb_runtime_resume,
> +NULL)
> +};
> +
> +static int rmi_smb_resume(struct device *dev)
> +{
> + struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + struct rmi_device *rmi_dev = rmi_smb->xport.rmi_dev;
> + int ret;
> +
> + rmi_smb_reset(_smb->xport, 0);
> +
> + rmi_reset(rmi_dev);
> +
> + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to resume device: %d\n", ret);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id rmi_id[] = {
> + { "rmi4_smbus", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, rmi_id);
> +
> +static struct i2c_driver rmi_smb_driver = {
> + .driver = {
> + .owner  = THIS_MODULE,
> + .name   = "rmi4_smbus",
> + .pm = _smb_pm,
> + .resume = rmi_smb_resume,

Why rmi_smb_resume is not part of rmi_smb_pm?

Thanks.

-- 
Dmitry

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-23 Thread Dmitry Torokhov 
Hi Benjamin,

On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> +
> +struct mapping_table_entry {
> + u16 rmiaddr;

Should be __le16 rmiaddr, otherwise:

  CHECK   drivers/input/rmi4/rmi_smbus.c
drivers/input/rmi4/rmi_smbus.c:116:33: warning: incorrect type in assignment 
(different base types)
drivers/input/rmi4/rmi_smbus.c:116:33:expected unsigned short [unsigned] 
[usertype] rmiaddr
drivers/input/rmi4/rmi_smbus.c:116:33:got restricted __le16 [usertype] 


> +
> +static struct i2c_driver rmi_smb_driver;
> +

I do not think this forward declaration is needed.

> +
> +#ifdef CONFIG_PM_SLEEP
> +static int rmi_smb_suspend(struct device *dev)

__maybe_unused instead of #ifdef.

> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to suspend device: %d\n", ret);
> +
> + return ret;
> +}
> +#endif
> +
> +#ifdef CONFIG_PM
> +static int rmi_smb_runtime_suspend(struct device *dev)

Same here?

> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_suspend(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to suspend device: %d\n", ret);
> +
> + return 0;
> +}
> +
> +static int rmi_smb_runtime_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + int ret;
> +
> + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to resume device: %d\n", ret);
> +
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops rmi_smb_pm = {
> + SET_SYSTEM_SLEEP_PM_OPS(rmi_smb_suspend, NULL)
> + SET_RUNTIME_PM_OPS(rmi_smb_runtime_suspend, rmi_smb_runtime_resume,
> +NULL)
> +};
> +
> +static int rmi_smb_resume(struct device *dev)
> +{
> + struct i2c_client *client = container_of(dev, struct i2c_client, dev);
> + struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
> + struct rmi_device *rmi_dev = rmi_smb->xport.rmi_dev;
> + int ret;
> +
> + rmi_smb_reset(_smb->xport, 0);
> +
> + rmi_reset(rmi_dev);
> +
> + ret = rmi_driver_resume(rmi_smb->xport.rmi_dev);
> + if (ret)
> + dev_warn(dev, "Failed to resume device: %d\n", ret);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id rmi_id[] = {
> + { "rmi4_smbus", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, rmi_id);
> +
> +static struct i2c_driver rmi_smb_driver = {
> + .driver = {
> + .owner  = THIS_MODULE,
> + .name   = "rmi4_smbus",
> + .pm = _smb_pm,
> + .resume = rmi_smb_resume,

Why rmi_smb_resume is not part of rmi_smb_pm?

Thanks.

-- 
Dmitry

[PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-09 Thread Benjamin Tissoires 
Code obtained from 
https://raw.githubusercontent.com/mightybigcar/synaptics-rmi4/jf/drivers/input/rmi4/rmi_smbus.c
and updated to match upstream. And fixed to make it work.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Andrew Duggan 
---
new in v5

no changes in v6

changes in v7:
- fixed typos as per Andrew's requests
- changed module author from Allie to Andrew as per Andrew's request
- add suspend/resume callbacks to match upstream rmi4 behavior

no changes in v8

 drivers/input/rmi4/Kconfig |  12 ++
 drivers/input/rmi4/Makefile|   1 +
 drivers/input/rmi4/rmi_bus.h   |  12 ++
 drivers/input/rmi4/rmi_smbus.c | 470 +
 4 files changed, 495 insertions(+)
 create mode 100644 drivers/input/rmi4/rmi_smbus.c

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index f73df24..86a180b 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -27,6 +27,18 @@ config RMI4_SPI
 
  If unsure, say N.
 
+config RMI4_SMB
+   tristate "RMI4 SMB Support"
+   depends on RMI4_CORE && I2C
+   help
+ Say Y here if you want to support RMI4 devices connected to an SMB
+ bus.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called rmi_smbus.
+
 config RMI4_2D_SENSOR
bool
depends on RMI4_CORE
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 95c00a7..3c8ebf2 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -11,3 +11,4 @@ rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
 obj-$(CONFIG_RMI4_SPI) += rmi_spi.o
+obj-$(CONFIG_RMI4_SMB) += rmi_smbus.o
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index 8995798..b7625a9 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -105,6 +105,18 @@ rmi_get_platform_data(struct rmi_device *d)
 bool rmi_is_physical_device(struct device *dev);
 
 /**
+ * rmi_reset - reset a RMI4 device
+ * @d: Pointer to an RMI device
+ *
+ * Calls for a reset of each function implemented by a specific device.
+ * Returns 0 on success or a negative error code.
+ */
+static inline int rmi_reset(struct rmi_device *d)
+{
+   return d->driver->reset_handler(d);
+}
+
+/**
  * rmi_read - read a single byte
  * @d: Pointer to an RMI device
  * @addr: The address to read from
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
new file mode 100644
index 000..d60b0e9
--- /dev/null
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -0,0 +1,470 @@
+/*
+ * Copyright (c) 2015 - 2016 Red Hat, Inc
+ * Copyright (c) 2011, 2012 Synaptics Incorporated
+ * Copyright (c) 2011 Unixphere
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rmi_driver.h"
+
+#define SMB_PROTOCOL_VERSION_ADDRESS   0xfd
+#define SMB_MAX_COUNT  32
+#define RMI_SMB2_MAP_SIZE  8 /* 8 entry of 4 bytes each */
+#define RMI_SMB2_MAP_FLAGS_WE  0x01
+
+struct mapping_table_entry {
+   u16 rmiaddr;
+   u8 readcount;
+   u8 flags;
+};
+
+struct rmi_smb_xport {
+   struct rmi_transport_dev xport;
+   struct i2c_client *client;
+
+   struct mutex page_mutex;
+   int page;
+   u8 table_index;
+   struct mutex mappingtable_mutex;
+   struct mapping_table_entry mapping_table[RMI_SMB2_MAP_SIZE];
+};
+
+static int rmi_smb_get_version(struct rmi_smb_xport *rmi_smb)
+{
+   struct i2c_client *client = rmi_smb->client;
+   int retval;
+
+   /* Check if for SMBus new version device by reading version byte. */
+   retval = i2c_smbus_read_byte_data(client, SMB_PROTOCOL_VERSION_ADDRESS);
+   if (retval < 0) {
+   dev_err(>dev, "failed to get SMBus version number!\n");
+   return retval;
+   }
+   return retval + 1;
+}
+
+/* SMB block write - wrapper over ic2_smb_write_block */
+static int smb_block_write(struct rmi_transport_dev *xport,
+ u8 commandcode, const void *buf, size_t len)
+{
+   struct rmi_smb_xport *rmi_smb =
+   container_of(xport, struct rmi_smb_xport, xport);
+   struct i2c_client *client = rmi_smb->client;
+   int retval;
+
+   retval = i2c_smbus_write_block_data(client, commandcode, len, buf);
+
+   rmi_dbg(RMI_DEBUG_XPORT, >dev,
+   "wrote %zd bytes at %#04x: %d (%*ph)\n",
+   len, commandcode, retval, (int)len, buf);
+
+   return retval;
+}
+
+/*
+ * The function to get command code for smbus operations and keeps
+ * records to the driver mapping table
+

[PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-09 Thread Benjamin Tissoires 
Code obtained from 
https://raw.githubusercontent.com/mightybigcar/synaptics-rmi4/jf/drivers/input/rmi4/rmi_smbus.c
and updated to match upstream. And fixed to make it work.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Andrew Duggan 
---
new in v5

no changes in v6

changes in v7:
- fixed typos as per Andrew's requests
- changed module author from Allie to Andrew as per Andrew's request
- add suspend/resume callbacks to match upstream rmi4 behavior

no changes in v8

 drivers/input/rmi4/Kconfig |  12 ++
 drivers/input/rmi4/Makefile|   1 +
 drivers/input/rmi4/rmi_bus.h   |  12 ++
 drivers/input/rmi4/rmi_smbus.c | 470 +
 4 files changed, 495 insertions(+)
 create mode 100644 drivers/input/rmi4/rmi_smbus.c

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index f73df24..86a180b 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -27,6 +27,18 @@ config RMI4_SPI
 
  If unsure, say N.
 
+config RMI4_SMB
+   tristate "RMI4 SMB Support"
+   depends on RMI4_CORE && I2C
+   help
+ Say Y here if you want to support RMI4 devices connected to an SMB
+ bus.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called rmi_smbus.
+
 config RMI4_2D_SENSOR
bool
depends on RMI4_CORE
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 95c00a7..3c8ebf2 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -11,3 +11,4 @@ rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
 obj-$(CONFIG_RMI4_SPI) += rmi_spi.o
+obj-$(CONFIG_RMI4_SMB) += rmi_smbus.o
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index 8995798..b7625a9 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -105,6 +105,18 @@ rmi_get_platform_data(struct rmi_device *d)
 bool rmi_is_physical_device(struct device *dev);
 
 /**
+ * rmi_reset - reset a RMI4 device
+ * @d: Pointer to an RMI device
+ *
+ * Calls for a reset of each function implemented by a specific device.
+ * Returns 0 on success or a negative error code.
+ */
+static inline int rmi_reset(struct rmi_device *d)
+{
+   return d->driver->reset_handler(d);
+}
+
+/**
  * rmi_read - read a single byte
  * @d: Pointer to an RMI device
  * @addr: The address to read from
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
new file mode 100644
index 000..d60b0e9
--- /dev/null
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -0,0 +1,470 @@
+/*
+ * Copyright (c) 2015 - 2016 Red Hat, Inc
+ * Copyright (c) 2011, 2012 Synaptics Incorporated
+ * Copyright (c) 2011 Unixphere
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rmi_driver.h"
+
+#define SMB_PROTOCOL_VERSION_ADDRESS   0xfd
+#define SMB_MAX_COUNT  32
+#define RMI_SMB2_MAP_SIZE  8 /* 8 entry of 4 bytes each */
+#define RMI_SMB2_MAP_FLAGS_WE  0x01
+
+struct mapping_table_entry {
+   u16 rmiaddr;
+   u8 readcount;
+   u8 flags;
+};
+
+struct rmi_smb_xport {
+   struct rmi_transport_dev xport;
+   struct i2c_client *client;
+
+   struct mutex page_mutex;
+   int page;
+   u8 table_index;
+   struct mutex mappingtable_mutex;
+   struct mapping_table_entry mapping_table[RMI_SMB2_MAP_SIZE];
+};
+
+static int rmi_smb_get_version(struct rmi_smb_xport *rmi_smb)
+{
+   struct i2c_client *client = rmi_smb->client;
+   int retval;
+
+   /* Check if for SMBus new version device by reading version byte. */
+   retval = i2c_smbus_read_byte_data(client, SMB_PROTOCOL_VERSION_ADDRESS);
+   if (retval < 0) {
+   dev_err(>dev, "failed to get SMBus version number!\n");
+   return retval;
+   }
+   return retval + 1;
+}
+
+/* SMB block write - wrapper over ic2_smb_write_block */
+static int smb_block_write(struct rmi_transport_dev *xport,
+ u8 commandcode, const void *buf, size_t len)
+{
+   struct rmi_smb_xport *rmi_smb =
+   container_of(xport, struct rmi_smb_xport, xport);
+   struct i2c_client *client = rmi_smb->client;
+   int retval;
+
+   retval = i2c_smbus_write_block_data(client, commandcode, len, buf);
+
+   rmi_dbg(RMI_DEBUG_XPORT, >dev,
+   "wrote %zd bytes at %#04x: %d (%*ph)\n",
+   len, commandcode, retval, (int)len, buf);
+
+   return retval;
+}
+
+/*
+ * The function to get command code for smbus operations and keeps
+ * records to the driver mapping table
+ */
+static int rmi_smb_get_command_code(struct