From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C0132DF717; Fri, 12 Jun 2026 17:25:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781285124; cv=pass; b=g+R1ZrisUAKmIhBBqLel0rpkueQ28qSqsaOc8HFQCNKkFJfUBBLx/ORKaeFtg/gz70+U4UqQsykNswTLMLuCQpisyQnaOPHFw70qgfJjPhvzoARcwNsTe2kDA4GhCxTxtLchyRPhFhpZ1E1whh82R2OIwtww12hBxJ2ofTMcEnI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781285124; c=relaxed/simple; bh=4cURpMK3QQXpTF2gpONN7pJN8waoiDf3cy2VfuoNe8k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=j/9q3997iAyxp1OcK/EaULsbhQ4ZsIKNGx6OIfL2g/FKqmXs5sK6k47XEWx4TJUvQVCCEDYYyYqpZEu9WXqMRKIE2Q9Nc2GlZflGJwMe8UJmcrbbaP3CxjCIKOpivFFWEx8pioTlApbhNs99h6yBqMHZhPUYNJ7cpe51c/2oX/E= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=detlev.casanova@collabora.com header.b=URnLanFu; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=detlev.casanova@collabora.com header.b="URnLanFu" ARC-Seal: i=1; a=rsa-sha256; t=1781285107; cv=none; d=zohomail.com; s=zohoarc; b=Ie9SB7+6RIDCVKRsL7F8dgbNefcEZWZU3VgvWJqIcjQQWL4WIxbEAHqvkaBcai3EaTWp5N5mBVf2HSQaF4UfTbQp0fHwrFlEF4Q7OhQ/F6C5/TBw90tqh6LVpBmA7ZAuGj0Pw1k8oCIQWK5/+suedcNMELBYK7gv8f/OBH4ELCg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1781285107; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=YBrJ3CWYtlE5Lt5wfHrabjrVt1O9sxm+jNwBrYb+diw=; b=IRV5WzdNW/QSC0202dWqSYV9Ef229++uh6gQmv4IU17HoYLmM05/qYO7LnUXfbN0mEzHer0kI3U75Jxmm8/5XuYCOSWAcNCfAwA9N6IMuXSRZgnopXSzcgn7bld1TqqdPp+OqHX85iaX8HhRSYi2pGQhCr8tP83bEKU/P7VqxnM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=detlev.casanova@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1781285107; s=zohomail; d=collabora.com; i=detlev.casanova@collabora.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=YBrJ3CWYtlE5Lt5wfHrabjrVt1O9sxm+jNwBrYb+diw=; b=URnLanFuO8mcbhqA1deOArbyp+PclOyqIdETvtM8oYjM6ZB+ep/tjdIFIIZJlhZf 2yWLTl3N6AGKJ292v/KtPdfGbb1aORXrd7cbtTv75zjgw4XXk3R0iO/YvuVtO1zF75e w0YXrd/309XydfSAcekO2ZlRYUbPJNwJUFYGWXQY= Received: by mx.zohomail.com with SMTPS id 1781285104387254.58725887548405; Fri, 12 Jun 2026 10:25:04 -0700 (PDT) Message-ID: Date: Fri, 12 Jun 2026 13:25:02 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] media: hantro: add per-context fdinfo usage stats To: Nicolas Dufresne , Mauro Carvalho Chehab , Benjamin Gaignard , Philipp Zabel Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, kernel@collabora.com, Christopher Healy References: <20260612-v4l2-add-fdinfo-v1-0-723211abc861@collabora.com> <20260612-v4l2-add-fdinfo-v1-3-723211abc861@collabora.com> Content-Language: en-US From: Detlev Casanova In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External Hi Nicolas, On 6/12/26 11:18, Nicolas Dufresne wrote: > Hi, > > Le vendredi 12 juin 2026 à 10:26 -0400, Detlev Casanova a écrit : >> From: Christopher Healy >> >> Add per-file-descriptor hardware utilization tracking to the Hantro >> VPU stateless codec driver, exposed via /proc//fdinfo/. >> >> Record a ktime timestamp when each job is submitted to hardware in >> device_run(), and accumulate the elapsed nanoseconds when the job >> completes in hantro_job_finish(). Report the accumulated time along >> with the current clock frequency through the new V4L2 show_fdinfo >> callback. >> >> The output uses a media- key prefix with the following keys: >>   media-driver:           driver name >>   media-engine-:     accumulated busy time in nanoseconds >>   media-maxfreq-:    maximum engine frequency in Hz >>   media-curfreq-:    current engine frequency in Hz >> >> Where is "decoder" or "encoder" depending on the context. >> >> This enables userspace monitoring tools to compute per-process decoder >> and encoder utilization. The current and max frequency keys report the >> same value today since the driver lacks devfreq support, but will >> diverge once DVFS is added, allowing userspace to approximate true >> capacity utilization without any fdinfo code changes. A future series >> can add hardware cycle counter support (via media-cycles-) for >> exact utilization under DVFS, with no changes to the existing uAPI. >> >> Signed-off-by: Christopher Healy >> Signed-off-by: Detlev Casanova >> --- >>  drivers/media/platform/verisilicon/hantro.h     |  5 +++++ >>  drivers/media/platform/verisilicon/hantro_drv.c | 22 ++++++++++++++++++++++ >>  2 files changed, 27 insertions(+) >> >> diff --git a/drivers/media/platform/verisilicon/hantro.h b/drivers/media/platform/verisilicon/hantro.h >> index 0353de154a1e..10287e5cebac 100644 >> --- a/drivers/media/platform/verisilicon/hantro.h >> +++ b/drivers/media/platform/verisilicon/hantro.h >> @@ -16,6 +16,7 @@ >>  #include >>  #include >>  #include >> +#include >>  #include >> >>  #include >> @@ -268,6 +269,10 @@ struct hantro_ctx { >>   struct hantro_postproc_ctx postproc; >>   bool need_postproc; >> >> + /* Statistics for debugging and performance measurements. */ >> + ktime_t start_time; >> + u64 total_ns; >> + >>   /* Specific for particular codec modes. */ >>   union { >>   struct hantro_h264_dec_hw_ctx h264_dec; >> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c >> index 2e81877f640f..139c2e6a83aa 100644 >> --- a/drivers/media/platform/verisilicon/hantro_drv.c >> +++ b/drivers/media/platform/verisilicon/hantro_drv.c >> @@ -90,6 +90,8 @@ static void hantro_job_finish(struct hantro_dev *vpu, >>         struct hantro_ctx *ctx, >>         enum vb2_buffer_state result) >>  { >> + ctx->total_ns += ktime_to_ns(ktime_sub(ktime_get(), ctx->start_time)); >> + >>   pm_runtime_put_autosuspend(vpu->dev); >> >>   clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks); >> @@ -186,6 +188,8 @@ static void device_run(void *priv) >> >>   v4l2_m2m_buf_copy_metadata(src, dst); >> >> + ctx->start_time = ktime_get(); >> + >>   if (ctx->codec_ops->run(ctx)) >>   goto err_cancel_job; >> >> @@ -701,10 +705,28 @@ static int hantro_release(struct file *filp) >>   return 0; >>  } >> >> +static void hantro_show_fdinfo(struct seq_file *m, struct file *f) >> +{ >> + struct hantro_ctx *ctx = file_to_ctx(f); >> + struct hantro_dev *vpu = ctx->dev; >> + >> + seq_printf(m, "media-driver:\t%s\n", DRIVER_NAME); >> + seq_printf(m, "media-engine-%s:\t%llu ns\n", >> +    ctx->is_encoder ? "encoder" : "decoder", >> +    ctx->total_ns); >> + seq_printf(m, "media-maxfreq-%s:\t%lu Hz\n", >> +    ctx->is_encoder ? "encoder" : "decoder", >> +    clk_get_rate(vpu->clocks[0].clk)); >> + seq_printf(m, "media-curfreq-%s:\t%lu Hz\n", >> +    ctx->is_encoder ? "encoder" : "decoder", >> +    clk_get_rate(vpu->clocks[0].clk)); > Similar to what was done in DRM helpers, I would create a common structure, > maybe in a v4l2-stats library (or some better name). The driver would fill that > structure directly, or through helpers (such as software timer helper, cycle > count translation helper), and finally, this show_fd_info() would be a one > liners, just like DRM do. > > This will ensure full consistency in the trace, and avoid possible future > unresolvable compatibility issue due to past mistakes. If we ever let a bug > through (of course we won't :-D) all driver will have the same bug, and it will > be easier to not break userspace. Yes, that makes a lot of sense actually, And will also help with the ftrace HW info if we have stats and debug info centralized in v4l2 > Nicolas > >> +} >> + >>  static const struct v4l2_file_operations hantro_fops = { >>   .owner = THIS_MODULE, >>   .open = hantro_open, >>   .release = hantro_release, >> + .show_fdinfo = hantro_show_fdinfo, >>   .poll = v4l2_m2m_fop_poll, >>   .unlocked_ioctl = video_ioctl2, >>   .mmap = v4l2_m2m_fop_mmap,