Hello Ville, On Wed, Aug 22, 2012 at 12:52 AM, Ville Syrj?l? < ville.syrjala at linux.intel.com> wrote:
> On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrj?l? < > > ville.syrjala at linux.intel.com> wrote: > > > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > Here are my earlier comments on Jean's patch: > > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > > > > If i am not wrong am doing exactly what you have said in you comments. > > > > This seems a bit wrong to me. The spec says that the ack for the > > segment address is "don't care", but for the segment pointer the ack is > > required (when segment != 0). > > The variable segFlags is "dont care for block 0 and 1 wheras". > > > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > > non E-DDC display, if we try to read segment != 0 from it. Of course > > we shouldn't do that unless the display lied to us about what extension > > blocks it provides. > > > > So I'm not sure if it would be better to trust that the display never > > lies about the extension blocks, or if we should just assume all E-DDC > > displays ack both segment addr and pointer. The no-ack feature seems > > to there for backwards compatibility, for cases where the host always > > sends the segment addr/pointer even when reading segment 0 (which your > > code doesn't do). > > > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > > into two flags (one for addr, other for data). > > > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > > and data pointer. > > I was referring to the addr and data phases of the segment pointer. > According to the spec the ack for the addr is always optional. But I > suppose no sane device would nak the addr, while acking the data. > > Thanks for your comment, actually there was a mistake in my code, i have posted the second set. Kindly have a look. > -- > Ville Syrj?l? > Intel OTC > Regards, Shirish S -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120823/dc546ce5/attachment-0001.html>
