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
