From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: unlisted-recipients:; (no To-header on input)
Cc: linuxarm@huawei.com, mauro.chehab@huawei.com,
Bhaskar Chowdhury <unixbhaskar@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
Deepak R Varma <drv@mailo.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Hans de Goede <hdegoede@redhat.com>,
Ingo Molnar <mingo@kernel.org>, Kaixu Xia <kaixuxia@tencent.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
Tsuchiya Yuto <kitakar@gmail.com>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-staging@lists.linux.dev
Subject: Re: [PATCH 0/3] atomisp: add support for enum frame rate and sizes
Date: Fri, 12 Nov 2021 12:03:35 +0000 [thread overview]
Message-ID: <20211112120335.74e437db@sal.lan> (raw)
In-Reply-To: <cover.1636651027.git.mchehab+huawei@kernel.org>
Em Thu, 11 Nov 2021 17:27:55 +0000
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
> Adding support for those two ioctls are trivial, and allow testing
> different resolutions with the driver.
>
> Together with some improvements I made at camorama, it is now
> possible to change the atomisp sensor's resolution at the GUI.
>
> Talking about camorama, I also added there an option to disable
> the Gtk cairo_scale() calls. On my tests here, placing ov2680 on
> its maximum resolution, I'm getting a framerate of 26 fps, which
> sounds reasonable, as the maximum would be 30fps, and I'm not
> using daylight.
>
> When letting cairo_scale() to run, the rate reduces to 8 fps, meaning
> that Gtk is not using GPU acceleration.
>
> Funny enough, when resolution is lower, atomisp is giving a very
> bad framerate (around 3fps, even with the scaler disabled).
>
> This is a very weird result, probably indicating some problems inside
> the driver. That requires further investigation.
Ok, when the sensor's resolution is not the highest one, what happens is
that the frame is retrieved via some timeout logic:
[10447.865064] ov2680 i2c-OVTI2680:00: ov2680_s_stream one
[10447.865491] atomisp-isp2 0000:00:03.0: timeout recovery handling done
[10450.029956] atomisp-isp2 0000:00:03.0: [WARNING]asd 0 pipe ATOMISP ISP PREVIEW output ISP timeout 1!
[10450.030099] atomisp-isp2 0000:00:03.0: pipe on asd0 timeout cnt: (0, 0, 1, 0) of 2, recover = 1
[10450.030137] atomisp-isp2 0000:00:03.0: pipe on asd1 timeout cnt: (0, 0, 0, 0) of 2, recover = 1
It sounds that it can't properly detect the end of frame when the
sensor is not on its highest resolution.
Basically atomisp_wdt_work() is triggered by a
IA_CSS_EVENT_TYPE_FW_ASSERT event. Identifying why this is happening
is not trivial, though.
Regards,
Mauro
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: linuxarm@huawei.com, mauro.chehab@huawei.com,
Bhaskar Chowdhury <unixbhaskar@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
Deepak R Varma <drv@mailo.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Hans de Goede <hdegoede@redhat.com>,
Ingo Molnar <mingo@kernel.org>, Kaixu Xia <kaixuxia@tencent.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
Tsuchiya Yuto <kitakar@gmail.com>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-staging@lists.linux.dev
Subject: Re: [PATCH 0/3] atomisp: add support for enum frame rate and sizes
Date: Fri, 12 Nov 2021 12:03:35 +0000 [thread overview]
Message-ID: <20211112120335.74e437db@sal.lan> (raw)
In-Reply-To: <cover.1636651027.git.mchehab+huawei@kernel.org>
Em Thu, 11 Nov 2021 17:27:55 +0000
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
> Adding support for those two ioctls are trivial, and allow testing
> different resolutions with the driver.
>
> Together with some improvements I made at camorama, it is now
> possible to change the atomisp sensor's resolution at the GUI.
>
> Talking about camorama, I also added there an option to disable
> the Gtk cairo_scale() calls. On my tests here, placing ov2680 on
> its maximum resolution, I'm getting a framerate of 26 fps, which
> sounds reasonable, as the maximum would be 30fps, and I'm not
> using daylight.
>
> When letting cairo_scale() to run, the rate reduces to 8 fps, meaning
> that Gtk is not using GPU acceleration.
>
> Funny enough, when resolution is lower, atomisp is giving a very
> bad framerate (around 3fps, even with the scaler disabled).
>
> This is a very weird result, probably indicating some problems inside
> the driver. That requires further investigation.
Ok, when the sensor's resolution is not the highest one, what happens is
that the frame is retrieved via some timeout logic:
[10447.865064] ov2680 i2c-OVTI2680:00: ov2680_s_stream one
[10447.865491] atomisp-isp2 0000:00:03.0: timeout recovery handling done
[10450.029956] atomisp-isp2 0000:00:03.0: [WARNING]asd 0 pipe ATOMISP ISP PREVIEW output ISP timeout 1!
[10450.030099] atomisp-isp2 0000:00:03.0: pipe on asd0 timeout cnt: (0, 0, 1, 0) of 2, recover = 1
[10450.030137] atomisp-isp2 0000:00:03.0: pipe on asd1 timeout cnt: (0, 0, 0, 0) of 2, recover = 1
It sounds that it can't properly detect the end of frame when the
sensor is not on its highest resolution.
Basically atomisp_wdt_work() is triggered by a
IA_CSS_EVENT_TYPE_FW_ASSERT event. Identifying why this is happening
is not trivial, though.
Regards,
Mauro
next prev parent reply other threads:[~2021-11-12 12:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 17:27 [PATCH 0/3] atomisp: add support for enum frame rate and sizes Mauro Carvalho Chehab
2021-11-11 17:27 ` Mauro Carvalho Chehab
2021-11-11 17:27 ` [PATCH 1/3] media: atomisp-ov2680: implement enum frame intervals Mauro Carvalho Chehab
2021-11-11 17:27 ` Mauro Carvalho Chehab
2021-11-11 17:27 ` [PATCH 2/3] media: atomisp-ov2680: adjust the maximum frame rate Mauro Carvalho Chehab
2021-11-11 17:27 ` Mauro Carvalho Chehab
2021-11-11 17:27 ` [PATCH 3/3] media: atomisp: implement enum framesize/frameinterval Mauro Carvalho Chehab
2021-11-11 17:27 ` Mauro Carvalho Chehab
2021-11-12 12:03 ` Mauro Carvalho Chehab [this message]
2021-11-12 12:03 ` [PATCH 0/3] atomisp: add support for enum frame rate and sizes Mauro Carvalho Chehab
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=20211112120335.74e437db@sal.lan \
--to=mchehab+huawei@kernel.org \
--cc=dan.carpenter@oracle.com \
--cc=drv@mailo.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=kaixuxia@tencent.com \
--cc=kitakar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linuxarm@huawei.com \
--cc=mauro.chehab@huawei.com \
--cc=mchehab@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=sakari.ailus@linux.intel.com \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=unixbhaskar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.