[PATCH v2] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
Lin, Wayne
Wayne.Lin at amd.com
Mon Jan 6 09:51:10 UTC 2020
[AMD Public Use]
> -----Original Message-----
> From: Lyude Paul <lyude at redhat.com>
> Sent: Saturday, January 4, 2020 6:02 AM
> To: Lin, Wayne <Wayne.Lin at amd.com>; dri-devel at lists.freedesktop.org;
> amd-gfx at lists.freedesktop.org
> Cc: Kazlauskas, Nicholas <Nicholas.Kazlauskas at amd.com>; Wentland, Harry
> <Harry.Wentland at amd.com>; Zuo, Jerry <Jerry.Zuo at amd.com>;
> stable at vger.kernel.org
> Subject: Re: [PATCH v2] drm/dp_mst: correct the shifting in
> DP_REMOTE_I2C_READ
>
> Oh! Just a friendly tip, I fixed this before pushing your patch:
>
> ➜ drm-maint git:(drm-misc-fixes) dim push
> dim: 0b1d54cedbb4 ("drm/dp_mst: correct the shifting in
> DP_REMOTE_I2C_READ"): Fixes: SHA1 needs at least 12 digits:
> dim: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper (v0.6))
> dim: ERROR: issues in commits detected, aborting
>
> For the future, we have a set of DRM maintainer tools (they're quite useful
> for people who aren't maintainers though!) that you can use to make sure
> your patch is formatted correctly ahead of time:
>
> https://drm.pages.freedesktop.org/maintainer-tools/dim.html>
>
> Particularly useful commands:
> * dim sparse # Checks for trivial code issues, like set but unused variables
> * dim checkpatch # Checks for code style issues
> * dim fixes $COMMIT_ID # Adds an appropriately formatted Fixes: tag
> * dim cite $COMMIT_ID # Adds an appropriately formatted Reference: tag
>
Really appreciate for your time!
I will have a look on this. Thanks a lot.
> On Fri, 2020-01-03 at 13:50 +0800, Wayne Lin wrote:
> > [Why]
> > According to DP spec, it should shift left 4 digits for NO_STOP_BIT in
> > REMOTE_I2C_READ message. Not 5 digits.
> >
> > In current code, NO_STOP_BIT is always set to zero which means I2C
> > master is always generating a I2C stop at the end of each I2C write
> > transaction while handling REMOTE_I2C_READ sideband message. This
> > issue might have the generated I2C signal not meeting the requirement.
> > Take random read in I2C for instance, I2C master should generate a
> > repeat start to start to read data after writing the read address.
> > This issue will cause the I2C master to generate a stop-start rather
> > than a re-start which is not expected in I2C random read.
> >
> > [How]
> > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case
> > in drm_dp_encode_sideband_req().
> >
> > Changes since
> >
> v1:(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >
> patchwork.kernel.org%2Fpatch%2F11312667%2F&data=02%7C01%7Cw
> ayne.li
> >
> n%40amd.com%7Ce4299c1721bd4bcb486708d790989148%7C3dd8961fe4884e
> 608e11a
> >
> 82d994e183d%7C0%7C0%7C637136857271065549&sdata=eoxiRojffBepY
> YoQbjp
> > j8b6R%2BkwaOQWBoU%2Fu8lY5gIQ%3D&reserved=0)
> > * Add more descriptions in commit and cc to stable
> >
> > Fixes: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper
> > (v0.6))
> > Reviewed-by: Harry Wentland <harry.wentland at amd.com>
> > Signed-off-by: Wayne Lin <Wayne.Lin at amd.com>
> > Cc: stable at vger.kernel.org
> > ---
> > 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 1cf5f8b8bbb8..9d24c98bece1 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++;
> > }
> --
> Cheers,
> Lyude Paul
--
Best Regards,
Wayne Lin
More information about the amd-gfx
mailing list