From: houlong wei <houlong.wei@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: "Jassi Brar" <jassisinghbrar@gmail.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Daniel Kurtz" <djkurtz@chromium.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
srv_heupstream <srv_heupstream@mediatek.com>,
"Sascha Hauer" <kernel@pengutronix.de>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Nicolas Boichat" <drinkcat@chromium.org>,
"CK Hu (胡俊光)" <ck.hu@mediatek.com>,
"Bibby Hsieh (謝濟遠)" <Bibby.Hsieh@mediatek.com>,
"YT Shen (沈岳霆)" <Yt.Shen@mediatek.com>,
"Daoyuan Huang (黃道原)" <Daoyuan.Huang@mediatek.com>,
"Jiaguang Zhang (张加广)" <Jiaguang.Zhang@mediatek.com>,
"Dennis-YC Hsieh (謝宇哲)" <Dennis-YC.Hsieh@mediatek.com>,
"Monica Wang (王孟婷)" <monica.wang@mediatek.com>,
"Hs Liao (廖宏祥)" <Hs.Liao@mediatek.com>,
"Ginny Chen (陳治傑)" <ginny.chen@mediatek.com>,
"Enzhu Wang (王恩柱)" <enzhu.wang@mediatek.com>,
houlong.wei@mediatek.com
Subject: Re: [PATCH v25 2/2] soc: mediatek: Add Mediatek CMDQ helper
Date: Mon, 8 Oct 2018 10:29:06 +0800 [thread overview]
Message-ID: <1538965746.4271.20.camel@mhfsdcap03> (raw)
In-Reply-To: <7040427b-f580-ec33-8afa-35dcf5735abb@gmail.com>
On Sat, 2018-09-29 at 20:50 +0800, Matthias Brugger wrote:
>
> On 29/09/2018 11:21, Houlong Wei wrote:
> [...]
>
> > +static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> > + u32 arg_a, u32 arg_b)
> > +{
> > + u64 *cmd_ptr;
> > +
> > + if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> > + pkt->cmd_buf_size += CMDQ_INST_SIZE;
>
> Can you plesae provide some example code of a driver that will use this API, I
> still don't understand why you need to update the cmd_buf_size here.
In our previous design, when appending a new command to buffer and the
buffer gets overflow, we will re-allocate a larger buffer to use.
CK.Hu had concern about the performance of buffer re-allocation. Please
refer:
http://lists.infradead.org/pipermail/linux-mediatek/2018-June/013797.html
One of his suggestions is that the consumer dynamically allocates buffer
with a initial size. Because the consumer doesn't know how to calculate
the buffer size. So we increase cmdq_buf_size here, that will help the
consumer get the buffer size in developing phase. In release driver
code, consumer passes a constant value to function call
cmdq_pkt_create(client, cmdq_buffer_size), cmdq_buffer_size is the
specified command queue buffer size.
>
> > + WARN_ON(1);
>
> can we add some debug information:
> WARN_ON(1, "%s: buffer size too small for the amount of commands", __func__);
>
> Would it make sense to use WARN_ONCE()?
>
Yes, I will add debug information and use WARN_ONCE().
> > + return -ENOMEM;
> > + }
> > + cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> > + (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> > + pkt->cmd_buf_size += CMDQ_INST_SIZE;
> > +
> > + return 0;
> > +}
>
> Thanks,
> Matthias
prev parent reply other threads:[~2018-10-08 2:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-29 9:21 MediaTek MT8173 CMDQ support Houlong Wei
2018-09-29 9:21 ` [PATCH v25 1/2] arm64: dts: mt8173: Add GCE node Houlong Wei
2018-09-29 9:21 ` [PATCH v25 2/2] soc: mediatek: Add Mediatek CMDQ helper Houlong Wei
2018-09-29 12:50 ` Matthias Brugger
2018-10-08 2:29 ` houlong wei [this message]
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=1538965746.4271.20.camel@mhfsdcap03 \
--to=houlong.wei@mediatek.com \
--cc=Bibby.Hsieh@mediatek.com \
--cc=Daoyuan.Huang@mediatek.com \
--cc=Dennis-YC.Hsieh@mediatek.com \
--cc=Hs.Liao@mediatek.com \
--cc=Jiaguang.Zhang@mediatek.com \
--cc=Yt.Shen@mediatek.com \
--cc=ck.hu@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=djkurtz@chromium.org \
--cc=drinkcat@chromium.org \
--cc=enzhu.wang@mediatek.com \
--cc=ginny.chen@mediatek.com \
--cc=jassisinghbrar@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=monica.wang@mediatek.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=srv_heupstream@mediatek.com \
/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).