[PATCH v3 2/2] drm/lima: driver for ARM Mali4xx GPUs

[Rob Herring]

On Sat, Mar 2, 2019 at 12:23 PM Rob Clark <robdclark at gmail.com> wrote:
>
> On Fri, Mar 1, 2019 at 9:32 PM Qiang Yu <yuq825 at gmail.com> wrote:
> >
> > On Thu, Feb 28, 2019 at 5:41 AM Rob Herring <robh at kernel.org> wrote:
> > >
> > > On Wed, Feb 27, 2019 at 7:42 AM Qiang Yu <yuq825 at gmail.com> wrote:
> > > > diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c> > > new file mode 100644
> > > > index 000000000000..e93bce16ee10
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/lima/lima_drv.c
> > > > @@ -0,0 +1,353 @@
> > > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > > +/* Copyright 2017-2018 Qiang Yu <yuq825 at gmail.com> */
> > > > +
> > > > +#include <linux/module.h>
> > > > +#include <linux/of_platform.h>
> > > > +#include <linux/log2.h>
> > > > +#include <drm/drm_prime.h>
> > > > +#include <drm/lima_drm.h>
> > > > +
> > > > +#include "lima_drv.h"
> > > > +#include "lima_gem.h"
> > > > +#include "lima_gem_prime.h"
> > > > +#include "lima_vm.h"
> > > > +
> > > > +int lima_sched_timeout_ms = 0;
> > > > +int lima_sched_max_tasks = 32;
> > > > +
> > > > +MODULE_PARM_DESC(sched_timeout_ms, "task run timeout in ms (0 = no timeout (default))");
> > > > +module_param_named(sched_timeout_ms, lima_sched_timeout_ms, int, 0444);
> > > > +
> > > > +MODULE_PARM_DESC(sched_max_tasks, "max queued task num in a context (default 32)");
> > > > +module_param_named(sched_max_tasks, lima_sched_max_tasks, int, 0444);
> > > > +
> > > > +static int lima_ioctl_info(struct drm_device *dev, void *data, struct drm_file *file)
> > > > +{
> > >
> > > For panfrost, we generalized this to "get param" like other drivers.
> > > Looks like you can only add 7 more items.
> > >
> > > What about GPU revisions?
> >
> > Currently I don't know there's any programming difference between GPUs
> > with different revision. Would be appreciate if anyone can tell me before
> > some hard reverse engineering effort.

What does the vendor kernel driver have? I haven't checked utgard, but
there's no shortage of quirks in the midgard/bifrost driver. I'd
imagine utgard to be similar.

> Probably a safe bet there are some revisions that need userspace
> workarounds.. and given that kernel to userspace uabi is something we
> end up having to live with for a long time, better to expose more
> information to userspace just in case.

Right.

More importantly than the 1 example I gave, design the ABI to be
extendable beyond 7 more u32 values. It is quite easy to support 2^32
params.

Rob