linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
To: Lucas Stach <l.stach@pengutronix.de>, linux-media@vger.kernel.org
Cc: linux-input@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Nick Dyer <nick@shmanahar.org>,
	Christopher Heiny <cheiny@synaptics.com>,
	Vandana BN <bnvandana@gmail.com>
Subject: Re: [PATCH 5/5] input/rmi4/rmi_smbus.c: don't increment rmiaddr in rmi_smb_read_block()
Date: Tue, 19 Nov 2019 13:19:28 +0100	[thread overview]
Message-ID: <3f21e94c-5ef5-f6f4-934d-2921fa93833f@xs4all.nl> (raw)
In-Reply-To: <409e5b53516fbf5daa752211d90f1fbba2f1c3b2.camel@pengutronix.de>

Hi Lucas,

On 11/19/19 12:48 PM, Lucas Stach wrote:
> Hi Hans,
> 
> On Di, 2019-11-19 at 11:51 +0100, Hans Verkuil wrote:
>> This increment of rmi_smbus causes garbage to be returned.
>> The first read of SMB_MAX_COUNT bytes is fine, but after that
>> it is nonsense. Trial-and-error showed that by dropping the
>> increment of rmiaddr everything is fine and the F54 function
>> properly works.
>>
>> Even going back to the original code when F54 was added, I
>> could not make it work without this patch. So I do not understand
>> how this ever worked.
> 
> My guess is that F54 has mostly been tested with touchscreens that are
> connected to a regular i2c bus, not smbus. i2c has a separate transport
> implementation in rmi4. Most of the other functions are probably
> reading much smaller block data than F54.

That's my suspicion as well. I tried to configure my kernel so that it
would be using i2c instead of smbus, but I couldn't make it work. I'll
have to try again next week.

I only have Rev E of the RMI4 spec, which does not appear to document
the mapping table entry that rmi_smb_get_command_code() uses.

Do you (or someone else) have access to a newer version? If so, can you check
how this is supposed to work for reading large blocks over smbus?

With the current code it will create a new mapping entry for every 32
byte read. I suspect that that is not how it is supposed to work, but
without a spec this is just trial-and-error.

Regards,

	Hans

> 
> Regards,
> Lucas
> 
>> My guess is that the same change is needed in rmi_smb_write_block,
>> but I wouldn't know how to test this.
>>
>> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>> ---
>>  drivers/input/rmi4/rmi_smbus.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
>> index 2407ea43de59..79ecea5edacc 100644
>> --- a/drivers/input/rmi4/rmi_smbus.c
>> +++ b/drivers/input/rmi4/rmi_smbus.c
>> @@ -215,7 +215,6 @@ static int rmi_smb_read_block(struct rmi_transport_dev *xport, u16 rmiaddr,
>>  		/* prepare to read next block of bytes */
>>  		cur_len -= SMB_MAX_COUNT;
>>  		databuff += SMB_MAX_COUNT;
>> -		rmiaddr += SMB_MAX_COUNT;
>>  	}
>>  
>>  	retval = 0;
> 


  reply	other threads:[~2019-11-19 12:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 10:51 [PATCH 0/5] input: rmi4/synaptics fixes Hans Verkuil
2019-11-19 10:51 ` [PATCH 1/5] input/mouse/synaptics: add LEN0091 support Hans Verkuil
2019-11-23  0:17   ` Dmitry Torokhov
2019-11-19 10:51 ` [PATCH 2/5] input/rmi4/rmi_f54: fix various V4L2 compliance problems Hans Verkuil
2019-11-19 11:42   ` Lucas Stach
2019-11-23  0:19     ` Dmitry Torokhov
2019-11-19 10:51 ` [PATCH 3/5] pixfmt-tch-td16/tu16.rst: document that this is little endian Hans Verkuil
2019-11-23 16:12   ` Hans Verkuil
2019-11-25 18:51     ` Dmitry Torokhov
2019-11-19 10:51 ` [PATCH 4/5] input/rmi4/rmi_driver: check if irq_find_mapping returns 0 Hans Verkuil
2019-11-19 11:38   ` Lucas Stach
2019-11-19 11:43     ` Hans Verkuil
2019-11-23 13:53       ` Hans Verkuil
2019-11-19 10:51 ` [PATCH 5/5] input/rmi4/rmi_smbus.c: don't increment rmiaddr in rmi_smb_read_block() Hans Verkuil
2019-11-19 11:48   ` Lucas Stach
2019-11-19 12:19     ` Hans Verkuil [this message]
2019-11-23 16:27   ` [PATCHv2 5/5] input/rmi4/rmi_smbus.c: don't increment rmiaddr Hans Verkuil
2019-12-02 18:09     ` Dmitry Torokhov

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=3f21e94c-5ef5-f6f4-934d-2921fa93833f@xs4all.nl \
    --to=hverkuil-cisco@xs4all.nl \
    --cc=bnvandana@gmail.com \
    --cc=cheiny@synaptics.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=nick@shmanahar.org \
    --cc=p.zabel@pengutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).