RE: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Peter,

> >>>> I'm not the one making the decision, and I don't even know if this
> >>>> is going through the i2c or the usb tree? If it's going through the
> >>>> i2c tree you need a tag from the usb people (Greg?) on patch 2/2,
> >>>> and if it's going through the usb tree, you need a tag from Wolfram
> >>>> on patch 1/2. As I said, I'm not involved with that part, I'm just
> >>>> reviewing these patches because I felt like it.
> >>>>
> >>>> The remaining issue that bothers me is the looping reads, and your
> >>>> email address reveals that you should be in a very good position to
> >>>> work out why they do not work, and fix it or let us know why they
> >>>> don't.
> >> I am working with different teams to debug this and I think it may
> >> take some time to know the root cause.
> > 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.
> 
> Thanks for digging into this! And if the HW team says it's not possible, then of
> course my objection falls flat. However, you only mention "read cycle", and
> based on your defines (I2C_MST_CNTL_CYCLE_TRIGGER) that seems to be
> terminology from the spec.
Comment "read cycle" and cycle in define I2C_MST_CNTL_CYCLE_TRIGGER is
not related. I should say "There has to be a STOP after every single read".

Thanks
Ajay

--nvpublic
> Yet, you apparently do writes without triggering a
> cycle. Do the HW team have anything to say about doing reads without
> triggering a "cycle"?
> 
> Cheers,
> Peter




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux