Hi Wolfram,
> > > > We got confirmation from HW team about 4 byte read limitation.
> > > > There has to be a STOP after every single read cycle. One read
> > > > cycle supports maximum of
> > > > 4 byte burst. I will update the patches with a comment on this.
> > >
> > > Could it be that this is more an SMBus controller than an I2C controller?
> > > I haven't looked at the specs but maybe populating smbus_xfer
> > > instead of master_xfer is an option here?
> > I think its more of i2c controller and we do mention " .max_read_len =
> > 4" in " struct i2c_adapter_quirks". Do you still see something missing here?
>
> Well, if there has to be STOP after a read, then you can't do a transfer
> containing "write-read-write", or?
Yes, that's correct.
> So, I wondered if this controller is of the
> type which can mainly do "write-then-read" transfers only (check
> I2C_AQ_COMB* quirk flags).
Yes it is mainly used "write-then-read" and also "write" only.
Read can be maximum of 4 bytes only and write has no size limitation.
I will add the flag I2C_AQ_COMB_WRITE_THEN_READ in the adapter quirk.
static const struct i2c_adapter_quirks gpu_i2c_quirks = {
.max_read_len = 4,
.flags = I2C_AQ_COMB_WRITE_THEN_READ,
};
> And for some of those controller types, it might
> be even easier to drop generic I2C transfers and only handle the SMBUS calls.
>
> I didn't check this driver closely yet, so I can't tell if/what it needs from
> the
> above. I wanted to give this input already, though.
Thanks for early feedback.
Please help review v12 at [1] and provide your input.
Thanks
Ajay
[1]
https://marc.info/?l=linux-usb&m=153668792309635&w=2
https://marc.info/?l=linux-usb&m=153668793009637&w=2
--nvpublic
>
> Regards,
>
> Wolfram
