From: Mikko Perttunen <cyndis-/1wQRMveznE@public.gmane.org> To: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 04/10] gpu: host1x: Lock classes during job submission Date: Tue, 5 Dec 2017 15:21:49 +0200 [thread overview] Message-ID: <2b4d9283-dabe-9e1f-f8cb-6ddbc16e3f0f@kapsi.fi> (raw) In-Reply-To: <dc39398b-ea49-6e97-28ba-652f8b49db44-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> On 07.11.2017 23:23, Dmitry Osipenko wrote: > On 07.11.2017 15:28, Mikko Perttunen wrote: >> 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. >> > > Okay. > >>> >>>> + 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? > > See INDMODID / REGF_MODULEID fields of HOST1X_CHANNEL_INDOFF2_0 / > HOST1X_SYNC_REGF_ADDR_0 registers, bit numbers of HOST1X_SYNC_INTSTATUS_0 / > HOST1X_SYNC_INTC0MASK_0 / HOST1X_SYNC_MOD_TEARDOWN_0. These values look like they would work on T20, but at least on T124 the module numbering for modules we want to lock goes above the number of MLOCKs so the indexing scheme would not work there.. Mikko > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
WARNING: multiple messages have this Message-ID (diff)
From: Mikko Perttunen <cyndis@kapsi.fi> To: Dmitry Osipenko <digetx@gmail.com>, Mikko Perttunen <mperttunen@nvidia.com>, thierry.reding@gmail.com, jonathanh@nvidia.com Cc: dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 04/10] gpu: host1x: Lock classes during job submission Date: Tue, 5 Dec 2017 15:21:49 +0200 [thread overview] Message-ID: <2b4d9283-dabe-9e1f-f8cb-6ddbc16e3f0f@kapsi.fi> (raw) In-Reply-To: <dc39398b-ea49-6e97-28ba-652f8b49db44@gmail.com> On 07.11.2017 23:23, Dmitry Osipenko wrote: > On 07.11.2017 15:28, Mikko Perttunen wrote: >> 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. >> > > Okay. > >>> >>>> + 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? > > See INDMODID / REGF_MODULEID fields of HOST1X_CHANNEL_INDOFF2_0 / > HOST1X_SYNC_REGF_ADDR_0 registers, bit numbers of HOST1X_SYNC_INTSTATUS_0 / > HOST1X_SYNC_INTC0MASK_0 / HOST1X_SYNC_MOD_TEARDOWN_0. These values look like they would work on T20, but at least on T124 the module numbering for modules we want to lock goes above the number of MLOCKs so the indexing scheme would not work there.. Mikko > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
next prev parent reply other threads:[~2017-12-05 13:21 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-05 11:01 [PATCH 00/10] Dynamic Host1x channel allocation Mikko Perttunen 2017-11-05 11:01 ` [PATCH 02/10] gpu: host1x: Print MLOCK state in debug dumps on T186 Mikko Perttunen 2017-11-05 11:01 ` [PATCH 03/10] gpu: host1x: Add lock around channel allocation Mikko Perttunen 2017-11-05 11:01 ` [PATCH 04/10] gpu: host1x: Lock classes during job submission Mikko Perttunen 2017-11-05 11:01 ` Mikko Perttunen [not found] ` <20171105110118.15142-5-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-11-05 16:46 ` Dmitry Osipenko 2017-11-05 16:46 ` Dmitry Osipenko 2017-11-07 12:28 ` Mikko Perttunen [not found] ` <ef08d3d8-94a7-8804-c339-5310719333f3-/1wQRMveznE@public.gmane.org> 2017-11-07 21:23 ` Dmitry Osipenko 2017-11-07 21:23 ` Dmitry Osipenko [not found] ` <dc39398b-ea49-6e97-28ba-652f8b49db44-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-12-05 13:21 ` Mikko Perttunen [this message] 2017-12-05 13:21 ` Mikko Perttunen [not found] ` <2b4d9283-dabe-9e1f-f8cb-6ddbc16e3f0f-/1wQRMveznE@public.gmane.org> 2017-12-05 13:43 ` Dmitry Osipenko 2017-12-05 13:43 ` Dmitry Osipenko 2017-11-05 11:01 ` [PATCH 05/10] gpu: host1x: Add job done callback Mikko Perttunen [not found] ` <20171105110118.15142-1-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-11-05 11:01 ` [PATCH 01/10] gpu: host1x: Parameterize channel aperture size Mikko Perttunen 2017-11-05 11:01 ` Mikko Perttunen 2017-11-05 11:01 ` [PATCH 06/10] drm/tegra: Deliver job completion callback to client Mikko Perttunen 2017-11-05 11:01 ` Mikko Perttunen [not found] ` <20171105110118.15142-7-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-11-16 16:33 ` Dmitry Osipenko 2017-11-16 16:33 ` Dmitry Osipenko 2017-11-16 16:40 ` Dmitry Osipenko [not found] ` <1afa1ba9-3103-3672-2e15-fb8c7de2520b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-11-29 9:09 ` Mikko Perttunen 2017-11-29 9:09 ` Mikko Perttunen 2017-11-05 11:01 ` [PATCH 07/10] drm/tegra: Make syncpoints be per-context Mikko Perttunen 2017-11-05 11:01 ` Mikko Perttunen 2017-11-07 15:34 ` [PATCH 00/10] Dynamic Host1x channel allocation Dmitry Osipenko 2017-11-07 15:34 ` Dmitry Osipenko 2017-11-05 11:01 ` [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model Mikko Perttunen [not found] ` <20171105110118.15142-9-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-11-05 17:43 ` Dmitry Osipenko 2017-11-05 17:43 ` Dmitry Osipenko 2017-11-07 12:29 ` Mikko Perttunen [not found] ` <38fcf947-0d5d-e2c7-f49f-9efce5eeb1a3-/1wQRMveznE@public.gmane.org> 2017-11-13 11:49 ` Dmitry Osipenko 2017-11-13 11:49 ` Dmitry Osipenko 2017-11-05 11:01 ` [PATCH 09/10] drm/tegra: Boot VIC in runtime resume Mikko Perttunen 2017-11-05 11:01 ` [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel Mikko Perttunen 2017-11-05 11:01 ` Mikko Perttunen [not found] ` <20171105110118.15142-11-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-11-05 17:14 ` Dmitry Osipenko 2017-11-05 17:14 ` Dmitry Osipenko [not found] ` <9c5676eb-ba6f-c187-29e4-7b331bd3962f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-11-07 13:11 ` Mikko Perttunen 2017-11-07 13:11 ` Mikko Perttunen 2017-11-07 15:29 ` Dmitry Osipenko [not found] ` <1b35ec93-167b-3436-0ff2-5e2e0886aea7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-11-10 21:15 ` Dmitry Osipenko 2017-11-10 21:15 ` Dmitry Osipenko [not found] ` <dcb8c4ef-9eb9-556f-cc96-651a50636afa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-11-12 11:23 ` Dmitry Osipenko 2017-11-12 11:23 ` Dmitry Osipenko 2017-11-29 9:10 ` Mikko Perttunen 2017-11-29 12:18 ` Dmitry Osipenko [not found] ` <07e28b40-dd2b-774f-2d07-3b5d6cf08c46-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-11-29 12:25 ` Mikko Perttunen 2017-11-29 12:25 ` Mikko Perttunen [not found] ` <a4adb6ac-b72e-3f9b-fc6c-2a56bc6537ce-/1wQRMveznE@public.gmane.org> 2017-11-29 12:37 ` Dmitry Osipenko 2017-11-29 12:37 ` Dmitry Osipenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2b4d9283-dabe-9e1f-f8cb-6ddbc16e3f0f@kapsi.fi \ --to=cyndis-/1wqrmvezne@public.gmane.org \ --cc=digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.