[AMD Public Use] > -----Original Message----- > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > Sent: Wednesday, January 8, 2020 2:57 AM > To: Lin, Wayne <Wayne.Lin@xxxxxxx> > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>; dri- > devel@xxxxxxxxxxxxxxxxxxxxx; amd-gfx@xxxxxxxxxxxxxxxxxxxxx; Zuo, Jerry > <Jerry.Zuo@xxxxxxx>; Kazlauskas, Nicholas > <Nicholas.Kazlauskas@xxxxxxx> > Subject: Re: [PATCH] drm/dp_mst: correct the shifting in > DP_REMOTE_I2C_READ > > On Tue, Dec 31, 2019 at 03:30:47AM +0000, Lin, Wayne wrote: > > [AMD Official Use Only - Internal Distribution Only] > > > > > ________________________________________ > > > From: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> > > > Sent: Monday, December 30, 2019 19:15 > > > To: Lin, Wayne; dri-devel@xxxxxxxxxxxxxxxxxxxxx; > > > amd-gfx@xxxxxxxxxxxxxxxxxxxxx > > > Cc: Zuo, Jerry; Kazlauskas, Nicholas; Lin, Wayne > > > Subject: Re: [PATCH] drm/dp_mst: correct the shifting in > > > DP_REMOTE_I2C_READ > > > > > > On Mon, 30 Dec 2019, Wayne Lin <Wayne.Lin@xxxxxxx> wrote: > > > > [Why] > > > > According to DP spec, it should shift left 4 digits for > > > > NO_STOP_BIT in REMOTE_I2C_READ message. Not 5 digits. > > > > > > > > [How] > > > > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ > > > > case in drm_dp_encode_sideband_req(). > > > > > > Which commit introduced the issue? Fixes: tag. Does it need a stable > > > backport? Does this fix a user visible bug? > > > > > > BR, > > > Jani. > > > > > Thanks for your time and reminder. > > > > It seems like the issue has been there since very beginning.(commit: > ad7f8a1). > > It doesn't introduce user visible bug under my test cases, but this > > affects the I2C signal between I2C master and I2C slave. Not pretty > > sure if there is any eeprom will reset the written offset once received I2C > stop. If so, that might cause wrongly reading EDID. > > I will Cc to stable. Thanks. > > The segment address should be reset on STOP. So large EDIDs should fail. > IIRC we had a bug report of some sort about this which I tried to fix by > confgiuring .no_stop_bit correctly, but apparently I failed to double check > that the bit get stuffed onto the wire correctly. > > Ah yes, > https://bugs.freedesktop.org/show_bug.cgi?id=108081 > So you may have just fixed that one, although we seem to have closed it > already. Thanks for your time and the explanation. > > > > > Signed-off-by: Wayne Lin <Wayne.Lin@xxxxxxx> > > > > --- > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c > > > > index 1d1bfa49ca2b..0557e225ff67 100644 > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > > > > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct > drm_dp_sideband_msg_req_body *req, > > > > memcpy(&buf[idx], req->u.i2c_read.transactions[i].bytes, > req->u.i2c_read.transactions[i].num_bytes); > > > > idx += > > > > req->u.i2c_read.transactions[i].num_bytes; > > > > > > > > - buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit & > 0x1) << 5; > > > > + buf[idx] = > > > > + (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4; > > > > buf[idx] |= (req- > >u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); > > > > idx++; > > > > } > > > > > > -- > > > Jani Nikula, Intel Open Source Graphics Center > > -- > > Wayne Lin > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.freedesktop.org%2Fmailman%2Flistinfo%2Fdri- > devel&data=02%7C01%7C > > > Wayne.Lin%40amd.com%7C7a299e0e845242312acb08d793a36e63%7C3dd896 > 1fe4884 > > > e608e11a82d994e183d%7C0%7C0%7C637140202457938159&sdata=yK4I > 7fgenrR > > f%2FXrs5jKXv%2BmOZdjV7dl%2BiNUJcsxnXG0%3D&reserved=0 > > -- > Ville Syrjälä > Intel -- Best regards, Wayne Lin _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
