On 9/24/19 11:57 AM, Wolfram Sang wrote:
In my opinion, it's probably better to continue to support master_xfer in
our driver (with obvious limitations), in order to allow i2ctransfer (or any
apps that use I2C RDWR) to continue to work.
What do you think?
Yes, don't break it for users.
> In my opinion, it's probably better to continue to support master_xfer in
> our driver (with obvious limitations), in order to allow i2ctransfer (or any
> apps that use I2C RDWR) to continue to work.
>
> What do you think?
Yes, don't break it for users. We should have paid more attention to
Hi Wolfram,
On 9/4/19 2:37 PM, Wolfram Sang wrote:
I think you are right that the controller does not seem to support
additional I2C features in addition to SMBUS.
However, my concern of switching to the smbus_xfer API is:
1) Some customers might have used I2C_RDWR based API from i2cdev.
> I think you are right that the controller does not seem to support
> additional I2C features in addition to SMBUS.
>
> However, my concern of switching to the smbus_xfer API is:
>
> 1) Some customers might have used I2C_RDWR based API from i2cdev. Changing
> from master_xfer to smbus_xfer may
On 8/31/19 2:49 AM, Wolfram Sang wrote:
Hi Ray,
With all the limitations in place, I wonder if it might be easier to
implement an smbus_xfer callback instead? What is left that makes this
controller more than SMBus and real I2C?
Right. But what is the implication of using smbus_xfer
Hi Ray,
> > With all the limitations in place, I wonder if it might be easier to
> > implement an smbus_xfer callback instead? What is left that makes this
> > controller more than SMBus and real I2C?
> >
>
> Right. But what is the implication of using smbus_xfer instead of
> master_xfer in our
On 8/30/19 5:56 AM, Wolfram Sang wrote:
Hi everyone,
+/*
+ * If 'process_call' is true, then this is a multi-msg transfer that requires
+ * a repeated start between the messages.
+ * More specifically, it must be a write (reg) followed by a read (data).
+ * The i2c quirks are set to enforce
Hi everyone,
> +/*
> + * If 'process_call' is true, then this is a multi-msg transfer that requires
> + * a repeated start between the messages.
> + * More specifically, it must be a write (reg) followed by a read (data).
> + * The i2c quirks are set to enforce this rule.
> + */
With all the
> Given that my name is also on the Signed-off-by since I helped to rewrite
> part of the patch, I'm not going to add my Reviewed-by tag here.
>
> Please help to review.
Outstanding iproc patches are next in my queue.
signature.asc
Description: PGP signature
Hi Wolfram,
On 8/6/19 9:09 PM, Rayagonda Kokatanur wrote:
From: Lori Hikichi
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of
From: Lori Hikichi
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of msgs
in a transfer is limited to two, and must be a write
11 matches
Mail list logo
