linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Ezequiel Garcia <ezequiel@collabora.com>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Rob Herring <robh+dt@kernel.org>,
	Tomasz Figa <tfiga@chromium.org>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	kernel@collabora.com,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Jonas Karlman <jonas@kwiboo.se>, Heiko Stuebner <heiko@sntech.de>,
	Sakari Ailus <sakari.ailus@iki.fi>,
	Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: [PATCH v6 5/6] media: rkvdec: Add the rkvdec driver
Date: Mon, 2 Mar 2020 15:30:39 +0100	[thread overview]
Message-ID: <20200302153039.0c4ff54f@collabora.com> (raw)
In-Reply-To: <20200302145746.3e94c1d1@coco.lan>

On Mon, 2 Mar 2020 14:57:46 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> > +#define M_N(ctxidx, idc0_m, idc0_n, idc1_m, idc1_n,		\
> > +	    idc2_m, idc2_n, intra_m, intra_n)			\
> > +	[0][(ctxidx)] = {idc0_m, idc0_n},			\
> > +	[1][(ctxidx)] = {idc1_m, idc1_n},			\
> > +	[2][(ctxidx)] = {idc2_m, idc2_n},			\
> > +	[3][(ctxidx)] = {intra_m, intra_n}  
> 
> Hmm... I can't even imagine what a macro named "M_N" would do.
> Please use a better name for it.

Well, the meaning of those fields is explained in the spec, and the
name itself has been chosen so it's short enough to not have lines
exceeding 80 chars while still keeping the number of lines used for the
cabac_table[] definition acceptable. But, I'm open to any other
suggestion.

> 
> -
> 
> With regards to the macro itself, at least for my eyes, it looked bad,
> from long-term maintenance PoV, to have a first argument (ctxidx) whose
> value is just a monotonic linearly-incremented counter.

It's not, we have holes in the middle, hence the explicit indexing. I
also tried to have something as close as possible to the spec, so
people can easily see where it comes from.

> 
> I mean, the way it is, it sounds risky, as one might miss a number
> and one entire line of the array would be filled with zeros.

That's exactly why I used explicit indexing: I want specific portions
of the table to be 0-filled :-).

> 
> > +
> > +/*
> > + * Constant CABAC table.
> > + * Built from the tables described in section '9.3.1.1 Initialisation process
> > + * for context variables' of the H264 spec.
> > + */
> > +static const s8 rkvdec_h264_cabac_table[4][464][2] = {
> > +	/* Table 9-12 – Values of variables m and n for ctxIdx from 0 to 10 */
> > +	M_N(0, 20, -15, 20, -15, 20, -15, 20, -15),  
> 
> So, (maybe except if the ctxidx value has some real meaning),
> perhaps you could, instead, switch the array order at the tables,
> and get rid of ctxidx parameter for good, so the above code would
> be like:

I can't switch the array order since the HW expects things to be
organized this way (that table is directly copied to a memory region
that's passed to the HW).

> 
> #define INIT_MN_PAIRS(idc0_m, idc0_n, idc1_m, idc1_n,	\
> 	       idc2_m, idc2_n, intra_m, intra_n)	\
> 	{						\
> 		[0] = {idc0_m, idc0_n},			\
> 		[1] = {idc1_m, idc1_n},			\
> 		[2] = {idc2_m, idc2_n},			\
> 		[3] = {intra_m, intra_n}		\
> 	},
> 
> static const s8 rkvdec_h264_cabac_table[464][4][2] = {
> 	/* Table 9-12 – Values of variables m and n for ctxIdx from 0 to 10 */
> 	INIT_MN_PAIRS(20, -15, 20, -15, 20, -15, 20, -15),
> 	...


  reply	other threads:[~2020-03-02 14:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 16:30 [PATCH v6 0/6] media: rockchip: Add the rkvdec driver Ezequiel Garcia
2020-02-20 16:30 ` [PATCH v6 1/6] media: uapi: h264: Add DPB entry field reference flags Ezequiel Garcia
2020-02-20 16:30 ` [PATCH v6 2/6] media: v4l2-core: Add helpers to build the H264 P/B0/B1 reflists Ezequiel Garcia
2020-03-02 13:24   ` Mauro Carvalho Chehab
2020-03-02 14:44     ` Boris Brezillon
2020-03-02 15:21       ` Mauro Carvalho Chehab
2020-03-05 19:42       ` Nicolas Dufresne
2020-03-05 20:15         ` Boris Brezillon
2020-03-05 21:37           ` Mauro Carvalho Chehab
2020-02-20 16:30 ` [PATCH v6 3/6] media: hantro: h264: Use the generic H264 reflist builder Ezequiel Garcia
2020-02-20 16:30 ` [PATCH v6 4/6] media: dt-bindings: rockchip: Document RK3399 Video Decoder bindings Ezequiel Garcia
2020-02-20 16:30 ` [PATCH v6 5/6] media: rkvdec: Add the rkvdec driver Ezequiel Garcia
2020-03-02 13:57   ` Mauro Carvalho Chehab
2020-03-02 14:30     ` Boris Brezillon [this message]
2020-03-02 14:53       ` Mauro Carvalho Chehab
2020-03-02 14:35     ` Boris Brezillon
2020-03-02 14:39       ` Mauro Carvalho Chehab
2020-02-20 16:30 ` [PATCH v6 6/6] arm64: dts: rockchip: rk3399: Define the rockchip Video Decoder node Ezequiel Garcia
2020-02-26 12:24   ` Johan Jonker
2020-02-26 13:21     ` Heiko Stuebner
2020-02-26 17:22       ` Ezequiel Garcia
2020-03-01  0:14         ` Heiko Stuebner

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=20200302153039.0c4ff54f@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@collabora.com \
    --cc=heiko@sntech.de \
    --cc=hverkuil@xs4all.nl \
    --cc=jonas@kwiboo.se \
    --cc=kernel@collabora.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@iki.fi \
    --cc=tfiga@chromium.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).