From: Eugeniu Rosca <erosca@de.adit-jv.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Eugeniu Rosca <erosca@de.adit-jv.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Michael Rodin <mrodin@de.adit-jv.com>,
Koji Matsuoka <koji.matsuoka.xm@renesas.com>,
Eugen Friedrich <efriedrich@de.adit-jv.com>,
Eugeniu Rosca <roscaeugeniu@gmail.com>
Subject: Re: [RFC PATCH v2] media: renesas: vsp1: Add VSPD underrun detection & tracing
Date: Wed, 29 Jun 2022 11:09:12 +0200 [thread overview]
Message-ID: <20220629090912.GA27332@lxhi-065> (raw)
In-Reply-To: <YrtghyHkWZyj8hxL@pendragon.ideasonboard.com>
Dear Laurent, dear Geert,
On Di, Jun 28, 2022 at 11:11:51 +0300, Laurent Pinchart wrote:
> On Tue, Jun 28, 2022 at 10:08:28PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Jun 28, 2022 at 9:53 PM Laurent Pinchart wrote:
> > > On Tue, Jun 28, 2022 at 09:05:34PM +0200, Eugeniu Rosca wrote:
> > > > On So, Jun 26, 2022 at 09:46:42 +0300, Laurent Pinchart wrote:
> > > > > On Tue, May 03, 2022 at 03:20:10PM +0200, Eugeniu Rosca wrote:
> > > > > >
> > > > > > Troubleshooting the above without the right tools becomes a nightmare.
> > > > >
> > > > > Having spent lots of time working in userspace recently, I can't agree
> > > > > more.
> > > >
> > > > Thanks for the feedback and for endorsing the utility of this patch.
> > > >
> > > > > > +static int vspd_underrun[VSPD_MAX_NUM];
> > > > > > +module_param_array(vspd_underrun, int, NULL, 0444);
> > > > > > +MODULE_PARM_DESC(vspd_underrun, "VSPD underrun counter");
> > > > >
> > > > > Module parameters are not meant to convey information back to userspace.
> > > > > This should be done through either a debugfs file or a sysfs file. Given
> > > > > the debugging nature of this feature, I'd recommend the former.
> > > >
> > > > It is a bit unfortunate that we have to go the debugFS route, since I
> > > > recall at least one Customer in the past, who disabled the debugFS in
> > > > the end product, since it was the only available means to meet the
> > > > stringent automotive requirements (w.r.t. KNL binary size). Anybody
> > > > who has no choice but to disable debugFS will consequently not be able
> > > > to take advantage of this patch in the production/release software.
> > >
> > > debugfs isn't meant to be enabled in production, so if you need a
> > > solution for production environment, it's not an option indeed.
> > >
> > > > If there is no alternative, then for sure I can go this way.
> > > >
> > > > However, before submitting PATCH v3, would you consider SYSFS viable
> > > > too, if keeping the module param is totally unacceptable?
> > > >
> > > > I was hoping to keep the number of external dependencies to the bare
> > > > minimum, hence the initial choice of module param. Looking forward to
> > > > your final suggestion/preference.
> > >
> > > sysfs would be my next recommendation. I don't think a Linux system can
> > > meaningfully run without sysfs, so it shouldn't be an issue
> > > dependency-wise.
> >
> > Indeed, you can add a device attribute.
> > But as that is not a debug feature, the attribute must be documented,
> > and becomes ABI.
>
> Thanks for the comment, that's correct
Thanks for the precious and insightful comments.
I will try to get them resolved in PATCH v3, to the best of my ability.
BR, Eugeniu
next prev parent reply other threads:[~2022-06-29 9:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 13:20 [RFC PATCH v2] media: renesas: vsp1: Add VSPD underrun detection & tracing Eugeniu Rosca
2022-06-08 11:45 ` Eugeniu Rosca
2022-06-26 18:46 ` Laurent Pinchart
2022-06-28 19:05 ` Eugeniu Rosca
2022-06-28 19:50 ` Laurent Pinchart
2022-06-28 20:08 ` Geert Uytterhoeven
2022-06-28 20:11 ` Laurent Pinchart
2022-06-29 9:09 ` Eugeniu Rosca [this message]
2022-06-29 10:35 ` Kieran Bingham
2022-06-29 11:36 ` Laurent Pinchart
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=20220629090912.GA27332@lxhi-065 \
--to=erosca@de.adit-jv.com \
--cc=efriedrich@de.adit-jv.com \
--cc=geert@linux-m68k.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=koji.matsuoka.xm@renesas.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mrodin@de.adit-jv.com \
--cc=roscaeugeniu@gmail.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