Messages in this thread | | | Subject | Re: [PATCH 04/10] gpu: host1x: Lock classes during job submission | From | Mikko Perttunen <> | Date | Tue, 7 Nov 2017 14:28:37 +0200 |
| |
On 05.11.2017 18:46, Dmitry Osipenko wrote: > On 05.11.2017 14:01, Mikko Perttunen wrote: >> ... >> >> +static int mlock_id_for_class(unsigned int class) >> +{ >> +#if HOST1X_HW >= 6 >> + switch (class) >> + { >> + case HOST1X_CLASS_HOST1X: >> + return 0; >> + case HOST1X_CLASS_VIC: >> + return 17; > > What is the meaning of returned ID values that you have defined here? Why VIC > should have different ID on T186?
On T186, MLOCKs are not "generic" - the HW knows that each MLOCK corresponds to a specific class. Therefore we must map that correctly.
> >> + default: >> + return -EINVAL; >> + } >> +#else >> + switch (class) >> + { >> + case HOST1X_CLASS_HOST1X: >> + return 0; >> + case HOST1X_CLASS_GR2D: >> + return 1; >> + case HOST1X_CLASS_GR2D_SB: >> + return 2; > > Note that we are allowing to switch 2d classes in the same jobs context and > currently jobs class is somewhat hardcoded to GR2D. > > Even though that GR2D and GR2D_SB use different register banks, is it okay to > trigger execution of different classes simultaneously? Would syncpoint > differentiate classes on OP_DONE event?
Good point, we might need to use the same lock for these two.
> > I suppose that MLOCK (the module lock) implies the whole module locking, > wouldn't it make sense to just use the module ID's defined in the TRM?
Can you point out where these are defined?
Mikko
| |