All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: unlisted-recipients:; (no To-header on input)
Cc: linuxarm@huawei.com, mauro.chehab@huawei.com,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	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: [PATCH 0/3] atomisp: add support for enum frame rate and sizes
Date: Thu, 11 Nov 2021 17:27:55 +0000	[thread overview]
Message-ID: <cover.1636651027.git.mchehab+huawei@kernel.org> (raw)

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.

Mauro Carvalho Chehab (3):
  media: atomisp-ov2680: implement enum frame intervals
  media: atomisp-ov2680: adjust the maximum frame rate
  media: atomisp: implement enum framesize/frameinterval

 .../media/atomisp/i2c/atomisp-ov2680.c        | 21 ++++++++
 drivers/staging/media/atomisp/i2c/ov2680.h    | 14 ++---
 .../staging/media/atomisp/pci/atomisp_ioctl.c | 53 +++++++++++++++++++
 3 files changed, 81 insertions(+), 7 deletions(-)

-- 
2.33.1



WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: linuxarm@huawei.com, mauro.chehab@huawei.com,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	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: [PATCH 0/3] atomisp: add support for enum frame rate and sizes
Date: Thu, 11 Nov 2021 17:27:55 +0000	[thread overview]
Message-ID: <cover.1636651027.git.mchehab+huawei@kernel.org> (raw)

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.

Mauro Carvalho Chehab (3):
  media: atomisp-ov2680: implement enum frame intervals
  media: atomisp-ov2680: adjust the maximum frame rate
  media: atomisp: implement enum framesize/frameinterval

 .../media/atomisp/i2c/atomisp-ov2680.c        | 21 ++++++++
 drivers/staging/media/atomisp/i2c/ov2680.h    | 14 ++---
 .../staging/media/atomisp/pci/atomisp_ioctl.c | 53 +++++++++++++++++++
 3 files changed, 81 insertions(+), 7 deletions(-)

-- 
2.33.1



             reply	other threads:[~2021-11-11 17:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 17:27 Mauro Carvalho Chehab [this message]
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 ` [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 ` [PATCH 0/3] atomisp: add support for enum frame rate and sizes Mauro Carvalho Chehab
2021-11-12 12:03   ` 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=cover.1636651027.git.mchehab+huawei@kernel.org \
    --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.