> > +/**
> > + * dpaa2_io_service_rearm() - Rearm the notification for the given DPIO
> > service.
> > + * @service: the given DPIO service.
> > + * @ctx: the notification context.
> > + *
> > + * Once a FQDAN/CDAN has been produced, the corresponding FQ/channel
> > is
> > + * considered "disarmed". Ie. the user can issue pull dequeue operations on
> > that
> > + * traffic source for as long as it likes. Eventually it may wish to "rearm"
> > + * that source to allow it to produce another FQDAN/CDAN, that's what this
> > + * function achieves.
> > + *
> > + * Return 0 for success.
> > + */
> > +int dpaa2_io_service_rearm(struct dpaa2_io *d,
> > + struct dpaa2_io_notification_ctx *ctx)
> > +{
> > + unsigned long irqflags;
> > + int err;
> > +
> > + d = service_select(d);
>
> Why not select the DPIO based on ctx->desired_cpu, like in the initial
> notification register?
Sounds like a reasonable idea, I am going to confirm with Roy.
Stuart
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
