Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Zev Weiss <zweiss@equinix.com>
To:     Jammy Huang <jammy_huang@aspeedtech.com>
CC:     "eajames@linux.ibm.com" <eajames@linux.ibm.com>,
        "mchehab@kernel.org" <mchehab@kernel.org>,
        "joel@jms.id.au" <joel@jms.id.au>,
        "andrew@aj.id.au" <andrew@aj.id.au>,
        "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
        "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "BMC-SW@aspeedtech.com" <BMC-SW@aspeedtech.com>
Subject: Re: [RESEND PATCH] media: aspeed: add debugfs
Thread-Topic: [RESEND PATCH] media: aspeed: add debugfs
Thread-Index: AQHXtPMpTKZrYpkgLEiZlACAPtW+vA==
Date:   Wed, 29 Sep 2021 05:30:49 +0000
Message-ID: <20210929053049.GQ17315@packtop>
References: <20210929011652.1709-1-jammy_huang@aspeedtech.com>
In-Reply-To: <20210929011652.1709-1-jammy_huang@aspeedtech.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?MPVWI80C3j46EXYFfOCI6M6FA31hwI0jSbe094Vz8q0mxisbSTbP+ktJeTY4?=
 =?us-ascii?Q?fIuoIIxGh8Q8I8qqo8Luo4zv+eilj+9oxweGp1c0OQKOybfknS16SZIAswbL?=
 =?us-ascii?Q?LpjQHMYi1TXUvVKjZDVJ0n+Z2VsvDn+yKsr7PhlA5jIxzQRMo5NRGTkwypAj?=
 =?us-ascii?Q?TrdPX4EAhT+JckJoG/a5TkjhQAyovJ3zcYoNBiPIQHq6aPru7pzvA0B7lr9I?=
 =?us-ascii?Q?hGoZFIR6CUvoyIKFU66cXLuTzn9ZV96IxsEUn4p54rN50KL4tHLEU5B1//2M?=
 =?us-ascii?Q?QkeccVleG6zqntGfuAn3RK1BQk9KJWcjlw4RhRGx9YSK1po7yVkqEa3kZRlA?=
 =?us-ascii?Q?LOwfXcyaFHMHSuPXdEBnj2XPN7ZZPNczxdD2oCEVJfNOeM97bzNLzo3Yvgtu?=
 =?us-ascii?Q?Zo1xxIGVFR9eCgSqixcsfbx6eLnW7gX3Amh8yRsc5culCSS+belq0geNz+0Y?=
 =?us-ascii?Q?AzrPfXqbpwUSCVt0ljFQwcHqxcprz7OabfABLJSffrqSIsQAJOXyLcgeEvgN?=
 =?us-ascii?Q?UCQDUtYJgYTEENJIIPtcgw1FhGYRgA87MJIHllNhmLdlxryvo9gDAFWUWf3u?=
 =?us-ascii?Q?Y5HgsQeI8MN2VY1/68VhOgphUCjVQBuRQO8jRHVNX2dQmlSWlNMY5KdCxwxy?=
 =?us-ascii?Q?Su5S7/ulehfUUyGT17jwnAMgUCTH9xUDiI65WzXm9IpWiv4+zQ6eL74r2c6b?=
 =?us-ascii?Q?9B0BNPJKvYHprX7H0AknwfqLBH/+Dt7UwrtlQAT27aqga75ubUOwrXWfnLQX?=
 =?us-ascii?Q?esmlkv2FBW5CMW1IbLPU7Cycvhnw1Y0/KDW1ysxvzoLmBhFhmoPugHmbK1jX?=
 =?us-ascii?Q?ewOO12LIZrYwRWOIYPmpdICdNngDkE9MsN5mpWBvVopeLRLw623z6z/GySyk?=
 =?us-ascii?Q?xnq4Er28Gxv/+JZjKHP38Yj6boJffKgtKZO+1xMLCcnyn1mLEKQcQEPAlexO?=
 =?us-ascii?Q?mas21HoEZRMPdBunYwcEb2TRnZsqvZupRWxFGo8mzEHwlB6MhW+Ie3mu3jy/?=
 =?us-ascii?Q?b6UBkOHeEQDziXGvi/K+0puCemVFTSQ4RVWjJ+H2YFSUsP0Y6+EzbRevTRFz?=
 =?us-ascii?Q?UDr+N5mAhrBHCngQap8FJpGAYVfvIYBZmxKmouYEIWzeh0WrgUugyzZQdIZD?=
 =?us-ascii?Q?ZJJwtlOU1cA4vfMkOLz4UidD1sJbhV/EGXmljIMkkAuKRr5R1nFn9nVssbMx?=
 =?us-ascii?Q?auzi/qIE0jB4jhgoR5UU5bag/nYQEHvDYuwXYD+jFl6IMcV99NsstwBPmibA?=
 =?us-ascii?Q?TKL2UhRWBzrAB08Xc9b8yq9YbuRLvZpH5HXf6BEguJxQm935jVlqQBA7DL6I?=
 =?us-ascii?Q?zEm8lxZ1zfGx18IsIYyPDaRr?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4599C88904522645A13BDDBA41879C2A@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: equinix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM8PR04MB8007.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b4634412-d407-4c17-893c-08d9830a4c25
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2021 05:30:49.9737
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72adb271-2fc7-4afe-a5ee-9de6a59f6bfb
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oCvuguvh8RK4XFSMGTrvAORxoLCmiVTgH01dmcoKZgbn8NSPY6Rp0qxHBUoFDrxCBrMwagPBQoUl15AZrL58EQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR04MB7797
X-Proofpoint-GUID: IU5X1DuFlTRdfhB65_q8FBmG2dWbOBXW
X-Proofpoint-ORIG-GUID: IU5X1DuFlTRdfhB65_q8FBmG2dWbOBXW
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475
 definitions=2021-09-29_01,2021-09-28_01,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=999
 spamscore=0 impostorscore=0 lowpriorityscore=0 adultscore=0 mlxscore=0
 priorityscore=1501 suspectscore=0 bulkscore=0 malwarescore=0 clxscore=1011
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001
 definitions=main-2109290033
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 28, 2021 at 06:16:53PM PDT, Jammy Huang wrote:
>To show video real-time information as below:
>
>    Signal|           Resolution|       FRC
>          |     Width     Height|
>      Lock|      1920       1080|         0
>
>    Frame#|       Frame Duration|       FPS
>          |    Now    Min    Max|
>       496|     26     25     30|        40
>
>Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
>---
> drivers/media/platform/aspeed-video.c | 100 ++++++++++++++++++++++++++
> 1 file changed, 100 insertions(+)
>
>diff --git a/drivers/media/platform/aspeed-video.c b/drivers/media/platfor=
m/aspeed-video.c
>index 8b3939b8052d..5b98dc7b7b15 100644
>--- a/drivers/media/platform/aspeed-video.c
>+++ b/drivers/media/platform/aspeed-video.c
>@@ -21,6 +21,8 @@
> #include <linux/videodev2.h>
> #include <linux/wait.h>
> #include <linux/workqueue.h>
>+#include <linux/debugfs.h>
>+#include <linux/ktime.h>
> #include <media/v4l2-ctrls.h>
> #include <media/v4l2-dev.h>
> #include <media/v4l2-device.h>
>@@ -203,6 +205,14 @@ struct aspeed_video_buffer {
> 	struct list_head link;
> };
>
>+struct aspeed_video_perf {
>+	ktime_t last_sample;
>+	u32 totaltime;
>+	u32 duration;
>+	u32 duration_min;
>+	u32 duration_max;
>+};
>+
> #define to_aspeed_video_buffer(x) \
> 	container_of((x), struct aspeed_video_buffer, vb)
>
>@@ -241,6 +251,8 @@ struct aspeed_video {
> 	unsigned int frame_left;
> 	unsigned int frame_right;
> 	unsigned int frame_top;
>+
>+	struct aspeed_video_perf perf;
> };
>
> #define to_aspeed_video(x) container_of((x), struct aspeed_video, v4l2_de=
v)
>@@ -444,6 +456,18 @@ static void aspeed_video_write(struct aspeed_video *v=
ideo, u32 reg, u32 val)
> 		readl(video->base + reg));
> }
>
>+static void update_perf(struct aspeed_video *v)
>+{
>+	v->perf.duration =3D
>+		ktime_to_ms(ktime_sub(ktime_get(),  v->perf.last_sample));
>+	v->perf.totaltime +=3D v->perf.duration;
>+
>+	if (!v->perf.duration_max || v->perf.duration > v->perf.duration_max)
>+		v->perf.duration_max =3D v->perf.duration;

How about

  v->perf.duration_max =3D max(v->perf.duration, v->perf.duration_max);

instead of manually testing & branching?

>+	if (!v->perf.duration_min || v->perf.duration < v->perf.duration_min)
>+		v->perf.duration_min =3D v->perf.duration;

And likewise with min(...) here.

As a minor style thing, I might suggest adding a variable declaration
like

  struct aspeed_video_perf *p =3D &v->perf;

and using that in the rest of the function to cut down on the
verbosity/repetition a bit.  Or actually, since it looks like there
aren't any other members of struct aspeed_video accessed in this
function, maybe just make struct aspeed_video_perf be the parameter
instead?

>+}
>+
> static int aspeed_video_start_frame(struct aspeed_video *video)
> {
> 	dma_addr_t addr;
>@@ -482,6 +506,8 @@ static int aspeed_video_start_frame(struct aspeed_vide=
o *video)
> 	aspeed_video_update(video, VE_INTERRUPT_CTRL, 0,
> 			    VE_INTERRUPT_COMP_COMPLETE);
>
>+	video->perf.last_sample =3D ktime_get();
>+
> 	aspeed_video_update(video, VE_SEQ_CTRL, 0,
> 			    VE_SEQ_CTRL_TRIG_CAPTURE | VE_SEQ_CTRL_TRIG_COMP);
>
>@@ -600,6 +626,8 @@ static irqreturn_t aspeed_video_irq(int irq, void *arg=
)
> 		u32 frame_size =3D aspeed_video_read(video,
> 						   VE_JPEG_COMP_SIZE_READ_BACK);
>
>+		update_perf(video);
>+
> 		spin_lock(&video->lock);
> 		clear_bit(VIDEO_FRAME_INPRG, &video->flags);
> 		buf =3D list_first_entry_or_null(&video->buffers,
>@@ -760,6 +788,7 @@ static void aspeed_video_get_resolution(struct aspeed_=
video *video)
> 	det->width =3D MIN_WIDTH;
> 	det->height =3D MIN_HEIGHT;
> 	video->v4l2_input_status =3D V4L2_IN_ST_NO_SIGNAL;
>+	memset(&video->perf, 0, sizeof(video->perf));
>
> 	do {
> 		if (tries) {
>@@ -1517,6 +1546,71 @@ static const struct vb2_ops aspeed_video_vb2_ops =
=3D {
> 	.buf_queue =3D  aspeed_video_buf_queue,
> };
>
>+#ifdef CONFIG_DEBUG_FS
>+static int aspeed_video_debugfs_show(struct seq_file *s, void *data)
>+{
>+	struct aspeed_video *v =3D s->private;
>+
>+	seq_printf(s, "%10s|%21s|%10s\n",
>+		   "Signal", "Resolution", "FRC");
>+	seq_printf(s, "%10s|%10s%11s|%10s\n",
>+		   "", "Width", "Height", "");
>+	seq_printf(s, "%10s|%10d%11d|%10d\n",
>+		   v->v4l2_input_status ? "Unlock" : "Lock",
>+		   v->pix_fmt.width, v->pix_fmt.height, v->frame_rate);
>+
>+	seq_puts(s, "\n");
>+
>+	seq_printf(s, "%10s|%21s|%10s\n",
>+		   "Frame#", "Frame Duration", "FPS");
>+	seq_printf(s, "%10s|%7s%7s%7s|%10s\n",
>+		   "", "Now", "Min", "Max", "");
>+	seq_printf(s, "%10d|%7d%7d%7d|%10d\n",
>+		   v->sequence, v->perf.duration, v->perf.duration_min,
>+		   v->perf.duration_max, 1000/(v->perf.totaltime/v->sequence));
>+

This looks like a convenient format for eyeballing with 'cat', but also
like it would be kind of awkward to parse if you wanted to do any sort
of automated analysis of the performance data it provides.  Would a
key:value type format like

  width: %d
  height: %d
  frame_rate: %d
  frame_number: %d
  # etc.

maybe provide a decent compromise?  (Easily parseable, almost as easily
readable.)

>+	return 0;
>+}
>+
>+int aspeed_video_proc_open(struct inode *inode, struct file *file)
>+{
>+	return single_open(file, aspeed_video_debugfs_show, inode->i_private);
>+}
>+
>+static const struct file_operations aspeed_video_debugfs_ops =3D {
>+	.owner   =3D THIS_MODULE,
>+	.open    =3D aspeed_video_proc_open,
>+	.read    =3D seq_read,
>+	.llseek  =3D seq_lseek,
>+	.release =3D single_release,
>+};
>+
>+static struct dentry *debugfs_entry;

I don't know how realistic the odds are of a system ever having multiple
aspeed-video devices, but structurally would this make more sense as
part of struct aspeed_video instead of being a single global?

>+
>+static void aspeed_video_debugfs_remove(struct aspeed_video *video)
>+{
>+	debugfs_remove_recursive(debugfs_entry);
>+	debugfs_entry =3D NULL;
>+}
>+
>+static int aspeed_video_debugfs_create(struct aspeed_video *video)
>+{
>+	debugfs_entry =3D debugfs_create_file(DEVICE_NAME, 0444, NULL,
>+						   video,
>+						   &aspeed_video_debugfs_ops);
>+	if (!debugfs_entry)
>+		aspeed_video_debugfs_remove(video);
>+
>+	return debugfs_entry =3D=3D NULL ? -EIO : 0;
>+}
>+#else
>+static void aspeed_video_debugfs_remove(struct aspeed_video *video) { }
>+static int aspeed_video_debugfs_create(struct aspeed_video *video)
>+{
>+	return 0;
>+}
>+#endif /* CONFIG_DEBUG_FS */
>+
> static int aspeed_video_setup_video(struct aspeed_video *video)
> {
> 	const u64 mask =3D ~(BIT(V4L2_JPEG_CHROMA_SUBSAMPLING_444) |
>@@ -1708,6 +1802,10 @@ static int aspeed_video_probe(struct platform_devic=
e *pdev)
> 		return rc;
> 	}
>
>+	rc =3D aspeed_video_debugfs_create(video);
>+	if (rc)
>+		dev_err(video->dev, "debugfs create failed\n");
>+
> 	return 0;
> }
>
>@@ -1719,6 +1817,8 @@ static int aspeed_video_remove(struct platform_devic=
e *pdev)
>
> 	aspeed_video_off(video);
>
>+	aspeed_video_debugfs_remove(video);
>+
> 	clk_unprepare(video->vclk);
> 	clk_unprepare(video->eclk);
>
>--=20
>2.25.1
>=