Re: [PATCH] GPU: DRM: VC4/V3D Replace wait_for macros in to remove use of msleep

[Eric Anholt]

On Thu, Feb 20, 2020 at 1:44 AM James Hughes
<james.hughes@xxxxxxxxxxxxxxx> wrote:
>
> On Wed, 19 Feb 2020 at 22:51, Eric Anholt <eric@xxxxxxxxxx> wrote:
> >
> > On Mon, Feb 17, 2020 at 7:41 AM James Hughes
> > <james.hughes@xxxxxxxxxxxxxxx> wrote:
> > >
> > > The wait_for macro's for Broadcom VC4 and V3D drivers used msleep
> > > which is inappropriate due to its inaccuracy at low values (minimum
> > > wait time is about 30ms on the Raspberry Pi).
> > >
> > > This patch replaces the macro with the one from the Intel i915 version
> > > which uses usleep_range to provide more accurate waits.
> > >
> > > Signed-off-by: James Hughes <james.hughes@xxxxxxxxxxxxxxx>
> >
> > To apply this, we're going to want to split the patch up between v3d
> > (with a fixes tag to the introduction of the driver, since it's a
> > pretty critical fix) and vc4 (where it's used in KMS, and we're pretty
> > sure we want it but changing timing like this in KMS paths is risky so
> > we don't want to backport to stable).  And adjust the commit messages
> > to have consistent prefixes to the rest of the commits to those
> > drivers.
> >
> > I've been fighting with the drm maintainer tools today to try to apply
> > the patch, with no luck.   I'll keep trying, and if I succeed, I'll
> > push it.
>
> Hi Eric,
>
> unclear whether you want me to do the split or whether you are going
> to (your last paragraph). Also I'm a bit unclear on the exact
> requirements for the prefixes etc.

I debugged what was going on with my maintainer tools and got the
patches applied:

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=9daee6141cc9c75b09659b02b1cb9eeb2f5e16cc
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=7f2a09ecf2e8d86e22598dfb879db48e72c5a40e

Apologies for the wait!  I've fixed some mail filters I think so I
should notice pings like this in the future.  But also I hope Maxime
can feel enabled to merge patches to vc4/v3d in the future -- I
certainly don't want to be the limiting factor here, and it's under
drm-misc so any drm-misc maintainer can apply stuff.