From: CK Hu <ck.hu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Horng-Shyang Liao <hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Cc: Monica Wang <monica.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Jiaguang Zhang
<jiaguang.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Nicolas Boichat
<drinkcat-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
cawa cheng <cawa.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Bibby Hsieh <bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Damon Chu <damon.chu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Daoyuan Huang
<daoyuan.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Glory Hung <glory.hung-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Matthias Brugger
<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
Josh-YC Liu <josh-yc.liu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dennis-YC Hsieh
<dennis-yc.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Subject: Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver
Date: Mon, 27 Jun 2016 10:00:07 +0800 [thread overview]
Message-ID: <1466992807.9692.2.camel@mtksdaap41> (raw)
In-Reply-To: <1466768371.817.9.camel@mtksdaap41>
On Fri, 2016-06-24 at 19:39 +0800, Horng-Shyang Liao wrote:
> On Tue, 2016-06-21 at 15:46 +0800, Horng-Shyang Liao wrote:
> > On Tue, 2016-06-21 at 10:03 +0800, CK Hu wrote:
> > > On Mon, 2016-06-20 at 19:22 +0800, Horng-Shyang Liao wrote:
> > > > On Mon, 2016-06-20 at 18:41 +0800, CK Hu wrote:
> > > > > [Snip...]
> > > > >
> > > > > > +
> > > > > > +static int cmdq_eng_get_thread(u64 flag)
> > > > > > +{
> > > > > > + if (flag & BIT_ULL(CMDQ_ENG_DISP_DSI0))
> > > > > > + return CMDQ_THR_DISP_MAIN_IDX;
> > > > > > + else if (flag & BIT_ULL(CMDQ_ENG_DISP_DPI0))
> > > > > > + return CMDQ_THR_DISP_SUB_IDX;
> > > > > > + else
> > > > > > + return CMDQ_THR_DISP_MISC_IDX;
> > > > > > +}
> > > > >
> > > > > I think cmdq should not have knowledge of client. These statement show
> > > > > that cmdq know that DSI0-tasks is different with DPI0-tasks. I propose
> > > > > the 'session' to replace engine flag. For example, main display create
> > > > > one cmdq_session and external display create another cmdq_session. For
> > > > > client driver, every tasks created by main display is bound to main
> > > > > display session. For cmdq driver, it should dynamically bind a session
> > > > > to a HW thread, and then dispatch tasks of this session to this HW
> > > > > thread. After HW thread run out of tasks of this session, detach this
> > > > > session with this thread.
> > > > > For the problem of remove wfe cmd, I think a session can have a property
> > > > > of merge_wfe_cmd. For display session, session->merge_wfe_cmd = true.
> > > > > For other client, it's false.
> > > >
> > > > Hi CK,
> > > >
> > > > I think your suggestion is similar to CMDQ 'scenarios',
> > > > which was removed from CMDQ v2.
> > > >
> > > > Daniel suggests to use engine flags instead of scenarios.
> > > > Quote from https://patchwork.kernel.org/patch/8068311/ .
> > > > 'Instead of encoding policy (these arbitrary "scenarios"), perhaps the
> > > > cmdq driver should just provide these flag bits, and the display
> > > > subsystem can use them to build the "flag" parameter itself.
> > > >
> > > > After all, the exact configuration of mmsys components is somewhat
> > > > flexible.'
> > > >
> > > > Therefore, it would be better to discuss with Daniel before we change
> > > > it.
> > > >
> > > >
> > > > Hi Daniel,
> > > >
> > > > Do you think we should use scenarios or sessions instead of flags?
> > > >
> > > > Thanks,
> > > > HS
> > > >
> > >
> > > Hi, HS:
> > >
> > > 'session' is not similar to 'scenarios'.
> > >
> > > In 'scenarios' mechanism, client bind a task with scenarios and send to
> > > cmdq. Cmdq transfer scenarios to engine flag, and use engine flag to
> > > dispatch task to HW thread.
> > >
> > >
> > > In 'engine flag' mechanism, proposed by Daniel, client bind a task
> > > directly with engine flag. Cmdq directly use engine flag to dispatch
> > > task to HW thread without any translation.
> > >
> > > But neither 'scenarios' mechanism nor 'engine flag' mechanism get rid of
> > > engine flag, which make cmdq have knowledge of client.
> > >
> > > In 'session' mechanism, there is no engine flag any more. Client bind
> > > time-sequential tasks to the same session and tasks in different session
> > > can execute parallelly. One thing cmdq need to know is to dispatch tasks
> > > with the same session to the same HW thread, so cmdq does not have any
> > > knowledge of client.
> > >
> > > Daniel focus on reduce translating scenarios to engine flag. I think
> > > 'session' mechanism does not conflict with his opinion because we does
> > > not translate 'session' to engine flag. Therefore, I think 'session' is
> > > the best of these three mechanism.
> > >
> > > Regards,
> > > CK
> >
> > Hi CK,
> >
> > 'Session' looks like a group of options for CMDQ.
> > CMDQ driver can just follow the options to run its flow,
> > and doesn't need to know its client(s).
> >
> > We don't have many options now, but it has good flexibility to extend
> > for future requirements.
> >
> > I will add it in next version.
> >
> > Thanks,
> > HS
>
> Hi CK,
>
> I think session is very similar to mailbox channel.
> We can treat session's parameters as channel's arguments in device tree.
> Linking session to GCE thread is also just like linking channel to GCE
> thread.
> Because I will use mailbox framework in CMDQ v9, we can use mailbox
> channel instead of session.
> What do you think?
>
> Thanks,
> HS
>
Hi, HS:
I'm not familiar with mailbox, but this sounds good to me.
Regards,
CK
> > > > > Here is the sample code to create cmdq_rec with session.
> > > > >
> > > > > merge_wfe_cmd = true;
> > > > > cmdq_session_create(merge_wfe_cmd, &primary_display_session);
> > > > > cmdq_rec_create(dev, primary_display_session, &rec);
> > > > >
> > > > >
> > > > > Therefore, the below definition can be removed.
> > > > >
> > > > > > +
> > > > > > +enum cmdq_eng {
> > > > > > + CMDQ_ENG_DISP_AAL,
> > > > > > + CMDQ_ENG_DISP_COLOR0,
> > > > > > + CMDQ_ENG_DISP_COLOR1,
> > > > > > + CMDQ_ENG_DISP_DPI0,
> > > > > > + CMDQ_ENG_DISP_DSI0,
> > > > > > + CMDQ_ENG_DISP_DSI1,
> > > > > > + CMDQ_ENG_DISP_GAMMA,
> > > > > > + CMDQ_ENG_DISP_OD,
> > > > > > + CMDQ_ENG_DISP_OVL0,
> > > > > > + CMDQ_ENG_DISP_OVL1,
> > > > > > + CMDQ_ENG_DISP_PWM0,
> > > > > > + CMDQ_ENG_DISP_PWM1,
> > > > > > + CMDQ_ENG_DISP_RDMA0,
> > > > > > + CMDQ_ENG_DISP_RDMA1,
> > > > > > + CMDQ_ENG_DISP_RDMA2,
> > > > > > + CMDQ_ENG_DISP_UFOE,
> > > > > > + CMDQ_ENG_DISP_WDMA0,
> > > > > > + CMDQ_ENG_DISP_WDMA1,
> > > > > > + CMDQ_ENG_MAX,
> > > > > > +};
> > > > > > +
> > > > >
> > > > >
> > > > > Regards,
> > > > > CK
>
>
next prev parent reply other threads:[~2016-06-27 2:00 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 3:19 [PATCH v8 0/3] Mediatek MT8173 CMDQ support HS Liao
2016-05-30 3:19 ` [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver HS Liao
2016-05-30 6:49 ` CK Hu
2016-05-30 9:38 ` Horng-Shyang Liao
2016-05-30 15:31 ` Matthias Brugger
2016-05-31 8:36 ` Horng-Shyang Liao
2016-05-31 20:04 ` Matthias Brugger
2016-06-01 9:57 ` Horng-Shyang Liao
2016-06-02 8:46 ` Matthias Brugger
2016-06-03 6:12 ` Horng-Shyang Liao
2016-06-03 11:18 ` Matthias Brugger
2016-06-03 12:13 ` Horng-Shyang Liao
2016-06-03 13:11 ` Matthias Brugger
2016-06-07 16:59 ` Matthias Brugger
[not found] ` <5756FD73.3050607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-08 5:40 ` Horng-Shyang Liao
2016-06-08 10:45 ` Matthias Brugger
2016-06-08 12:25 ` Horng-Shyang Liao
2016-06-08 15:35 ` Matthias Brugger
[not found] ` <57583B45.2080504-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-14 7:44 ` Horng-Shyang Liao
2016-06-14 10:17 ` Matthias Brugger
2016-06-14 12:07 ` Horng-Shyang Liao
2016-06-17 8:28 ` Horng-Shyang Liao
2016-06-17 15:57 ` Matthias Brugger
[not found] ` <57641E01.3070205-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-21 5:52 ` Horng-Shyang Liao
2016-06-21 13:41 ` Matthias Brugger
[not found] ` <5769440D.5030505-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-22 5:43 ` Horng-Shyang Liao
2016-06-22 9:58 ` Matthias Brugger
2016-06-17 16:14 ` Matthias Brugger
[not found] ` <57516774.5080008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-03 13:11 ` Jassi Brar
[not found] ` <CABb+yY2aOncqM-fOiq_ZBink0Fth6Drd30ZMe3-bXNkodW2dVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-06 9:33 ` Horng-Shyang Liao
2016-06-06 13:17 ` Jassi Brar
2016-06-07 2:45 ` Horng-Shyang Liao
2016-06-07 17:04 ` Matthias Brugger
[not found] ` <5756FE9B.6020107-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-08 5:09 ` Horng-Shyang Liao
[not found] ` <1464578397-29743-3-git-send-email-hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2016-06-20 10:41 ` CK Hu
2016-06-20 11:22 ` Horng-Shyang Liao
2016-06-21 2:03 ` CK Hu
2016-06-21 7:46 ` Horng-Shyang Liao
2016-06-24 11:39 ` Horng-Shyang Liao
2016-06-27 2:00 ` CK Hu [this message]
2016-06-23 6:03 ` CK Hu
2016-06-23 7:54 ` Horng-Shyang Liao
2016-06-23 11:44 ` CK Hu
[not found] ` <1464578397-29743-1-git-send-email-hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2016-05-30 3:19 ` [PATCH v8 1/3] dt-bindings: soc: Add documentation for the MediaTek GCE unit HS Liao
2016-05-30 3:19 ` [PATCH v8 3/3] arm64: dts: mt8173: Add GCE node HS Liao
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=1466992807.9692.2.camel@mtksdaap41 \
--to=ck.hu-nus5lvnupcjwk0htik3j/w@public.gmane.org \
--cc=bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=cawa.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=damon.chu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=daoyuan.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=dennis-yc.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=drinkcat-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=glory.hung-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=jiaguang.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=josh-yc.liu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=monica.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=yt.shen-NuS5LvNUpcJWk0Htik3J/w@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).