From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757625AbdECT6m (ORCPT ); Wed, 3 May 2017 15:58:42 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:36152 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754984AbdECT6c (ORCPT ); Wed, 3 May 2017 15:58:32 -0400 Date: Wed, 3 May 2017 21:58:29 +0200 From: Pavel Machek To: Russell King - ARM Linux Cc: Ivaylo Dimitrov , Mauro Carvalho Chehab , abcloriens@gmail.com, linux-media@vger.kernel.org, khilman@kernel.org, tony@atomide.com, aaro.koskinen@iki.fi, kernel list , sre@kernel.org, Sakari Ailus , Sakari Ailus , pali.rohar@gmail.com, linux-omap@vger.kernel.org, patrikbachan@gmail.com, linux-arm-kernel , serge@hallyn.com Subject: Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2) Message-ID: <20170503195829.GA17315@amd> References: <20170419105118.72b8e284@vento.lan> <20170424093059.GA20427@amd> <20170424103802.00d3b554@vento.lan> <20170424212914.GA20780@amd> <20170424224724.5bb52382@vento.lan> <20170426105300.GA857@amd> <20170426081330.6ca10e42@vento.lan> <20170426132337.GA6482@amd> <20170503190556.GT23750@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20170503190556.GT23750@n2100.armlinux.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed 2017-05-03 20:05:56, Russell King - ARM Linux wrote: > On Wed, Apr 26, 2017 at 06:43:54PM +0300, Ivaylo Dimitrov wrote: > > >+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_fo= rmat *fmt) > > >+{ > > >+ long long avg_lum =3D 0; > > >+ int x, y; > > >+=09 > > >+ buf +=3D fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 + > > >+ fmt->fmt.pix.width / 4; > > >+ > > >+ for (y =3D 0; y < fmt->fmt.pix.height / 2; y++) { > > >+ for (x =3D 0; x < fmt->fmt.pix.width / 2; x++) > >=20 > > That would take some time :). AIUI, we have NEON support in ARM kernels > > (CONFIG_KERNEL_MODE_NEON), I wonder if it makes sense (me) to convert t= he > > above loop to NEON-optimized when it comes to it? Are there any drawbac= ks in > > using NEON code in kernel? >=20 > Using neon without the VFP state saved and restored corrupts userspace's > FP state. So, you have to save the entire VFP state to use neon in kernel > mode. There are helper functions for this: kernel_neon_begin() and > kernel_neon_end(). =2E.. > Given that, do we really want to be walking over multi-megabytes of image > data in the kernel with preemption disabled - it sounds like a recipe for > a very sluggish system. I think this should (and can only sensibly be > done) in userspace. The patch was for libv4l2. (And I explained why we don't need to overoptimize this.) Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --huq684BweRXVnRxX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlkKNmUACgkQMOfwapXb+vKfewCeIArUjeHqoSyWWlhdaFa+Ej20 5VkAoLPgQMUkBaWNVRrjkNPJP1r+K32H =BmM6 -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: pavel@ucw.cz (Pavel Machek) Date: Wed, 3 May 2017 21:58:29 +0200 Subject: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2) In-Reply-To: <20170503190556.GT23750@n2100.armlinux.org.uk> References: <20170419105118.72b8e284@vento.lan> <20170424093059.GA20427@amd> <20170424103802.00d3b554@vento.lan> <20170424212914.GA20780@amd> <20170424224724.5bb52382@vento.lan> <20170426105300.GA857@amd> <20170426081330.6ca10e42@vento.lan> <20170426132337.GA6482@amd> <20170503190556.GT23750@n2100.armlinux.org.uk> Message-ID: <20170503195829.GA17315@amd> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed 2017-05-03 20:05:56, Russell King - ARM Linux wrote: > On Wed, Apr 26, 2017 at 06:43:54PM +0300, Ivaylo Dimitrov wrote: > > >+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format *fmt) > > >+{ > > >+ long long avg_lum = 0; > > >+ int x, y; > > >+ > > >+ buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 + > > >+ fmt->fmt.pix.width / 4; > > >+ > > >+ for (y = 0; y < fmt->fmt.pix.height / 2; y++) { > > >+ for (x = 0; x < fmt->fmt.pix.width / 2; x++) > > > > That would take some time :). AIUI, we have NEON support in ARM kernels > > (CONFIG_KERNEL_MODE_NEON), I wonder if it makes sense (me) to convert the > > above loop to NEON-optimized when it comes to it? Are there any drawbacks in > > using NEON code in kernel? > > Using neon without the VFP state saved and restored corrupts userspace's > FP state. So, you have to save the entire VFP state to use neon in kernel > mode. There are helper functions for this: kernel_neon_begin() and > kernel_neon_end(). ... > Given that, do we really want to be walking over multi-megabytes of image > data in the kernel with preemption disabled - it sounds like a recipe for > a very sluggish system. I think this should (and can only sensibly be > done) in userspace. The patch was for libv4l2. (And I explained why we don't need to overoptimize this.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: