linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Alexandre Courbot <acourbot@chromium.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Tiffany Lin <tiffany.lin@mediatek.com>,
	Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Tomasz Figa <tfiga@chromium.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"moderated list:ARM/Mediatek SoC support
	<linux-mediatek@lists.infradead.org>,
	Randy Dunlap"  <rdunlap@infradead.org>
Subject: Re: [PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled
Date: Mon, 12 Oct 2020 09:28:54 +0200	[thread overview]
Message-ID: <20201012092854.3c43b9bd@coco.lan> (raw)
In-Reply-To: <CAPBb6MXjEZB1N0vgTMGk28_qPpAqX87XFfkwor-9Yge0_uejsg@mail.gmail.com>

Em Mon, 12 Oct 2020 13:58:51 +0900
Alexandre Courbot <acourbot@chromium.org> escreveu:

> Hi Mauro,
> 
> On Fri, Oct 9, 2020 at 3:34 PM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > Em Fri, 9 Oct 2020 13:30:06 +0900
> > Alexandre Courbot <acourbot@chromium.org> escreveu:
> >  
> > > On Fri, Oct 9, 2020 at 1:13 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:  
> >  
> > > > >>> If VIDEO_MEDIATEK_VPU=y and MTK_SCP=m, then VIDEO_MEDIATEK_VCODEC can be configured
> > > > >>> to y, and then it won't be able to find the scp_ functions.
> > > > >>>
> > > > >>> To be honest, I'm not sure how to solve this.  
> > > > >>
> > > > >> Found it. Add this:
> > > > >>
> > > > >>         depends on MTK_SCP || !MTK_SCP
> > > > >>         depends on VIDEO_MEDIATEK_VPU || !VIDEO_MEDIATEK_VPU
> > > > >>
> > > > >> Ugly as hell, but it appears to be the correct incantation for this.  
> >
> > While the above does the job, I'm wondering if the better wouldn't
> > be to have this spit into 3 config dependencies. E. g. something like:
> >
> > config VIDEO_MEDIATEK_CODEC
> >         depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU
> >
> > config VIDEO_MEDIATEK_VPU
> >         depends on VIDEO_DEV && VIDEO_V4L2
> >         depends on ARCH_MEDIATEK || COMPILE_TEST
> >         tristate "support for Mediatek Video Processor Unit without SCP"
> >         help
> >             ...
> >
> > config VIDEO_MEDIATEK_VPU_SCP
> >         depends on VIDEO_DEV && VIDEO_V4L2
> >         depends on ARCH_MEDIATEK || COMPILE_TEST
> >         tristate "support for Mediatek Video Processor Unit with SCP"
> >         help
> >             ...  
> 
> Doing so would introduce two extra choices to enable the driver, so
> I'm a bit concerned this may be a bit confusing?

The Kconfig name for "SCP" is already confusing:

	config MTK_SCP
		tristate "Mediatek SCP support"

Only looking at the helper messages one would understand what SCP
actually means ;-)

	help
	  Say y here to support Mediatek's System Companion Processor (SCP) via
	  the remote processor framework.

IMO, the way to make it less confusing would be to change the Kconfig
message (probably both here and at remoteproc) to make it easier for
people to understand.

For example, I would use something similar to this for MTK_SCP prompt:

	tristate "Use remoteproc with Mediatek companion processor (SCP)"

There would be other ways of producing the same result using multiple
config entries and just one that would be prompted, but, IMHO, with
multiple entries, it t is clearer for the user to understand what
what kind of support was selected. 

This also allows one to look at the produced .config in order to 
check if SCP was enabled for Mediatek VPU or not.

> Also I have experimented with this, and it appears that
> VIDEO_MEDIATEK_CODEC won't be automatically enabled if one of the new
> options is selected. So this means that after setting e.g.
> VIDEO_MEDIATEK_VPU_SCP, one still needs to manually enable
> VIDEO_MEDIATEK_CODEC otherwise the driver won't be compiled at all.

Actually, the codec config option would need a default line too,
e. g. either:

	config VIDEO_MEDIATEK_CODEC
	         depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU
		 default y

or:

	config VIDEO_MEDIATEK_CODEC
	         depends on VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU
		 default VIDEO_MEDIATEK_VPU_SCP || VIDEO_MEDIATEK_VPU

Both should produce exactly the same result. I usually prefer the
first, as it is easier to read.

> 
> >
> > And split the board-specific data for each variant on separate files,
> > doing something like this at the Makefile:
> >
> >         obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
> >                                        mtk-vcodec-enc.o \
> >                                        mtk-vcodec-common.o
> >
> >         ifneq ($(VIDEO_MEDIATEK_VPU_SCP),)
> >         obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-fw-scp.o
> >         endif
> >
> >         ifneq ($(VIDEO_MEDIATEK_VPU),)
> >         obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-fw-vpu.o
> >         endif
> >
> > This will avoid the ugly ifdefs in the middle of mtk_vcodec_fw.c,
> > and the ugly "depends on FOO || !FOO" usage.
> >
> > It should also be simpler to add future variants of it in the
> > future, if needed.  
> 
> Indeed, the split makes sense regardless of the selection mechanism
> adopted. I will try to do it in the next revision.

Agreed.

Thanks,
Mauro

      reply	other threads:[~2020-10-12  7:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-04 12:22 [PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled Alexandre Courbot
2020-10-05  3:32 ` Alexandre Courbot
2020-10-05  8:48 ` Sakari Ailus
2020-10-05 11:29   ` Alexandre Courbot
2020-10-08 13:07 ` Hans Verkuil
2020-10-08 13:12   ` Hans Verkuil
2020-10-08 14:02     ` Alexandre Courbot
2020-10-08 16:13       ` Hans Verkuil
2020-10-09  4:30         ` Alexandre Courbot
     [not found]           ` <20201009083350.6c2e5a6a@coco.lan>
2020-10-12  4:58             ` Alexandre Courbot
2020-10-12  7:28               ` Mauro Carvalho Chehab [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=20201012092854.3c43b9bd@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=acourbot@chromium.org \
    --cc=andrew-ct.chen@mediatek.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tfiga@chromium.org \
    --cc=tiffany.lin@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).