Message ID | 1329761467-14417-1-git-send-email-festevam@gmail.com (mailing list archive) |
---|---|
State | Rejected, archived |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1RzXho-0001DC-Cp for patchwork@linuxtv.org; Mon, 20 Feb 2012 19:11:20 +0100 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtp for <patchwork@linuxtv.org> id 1RzXhn-0004Re-HI; Mon, 20 Feb 2012 19:11:20 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751952Ab2BTSLR (ORCPT <rfc822;patchwork@linuxtv.org>); Mon, 20 Feb 2012 13:11:17 -0500 Received: from mail-yw0-f46.google.com ([209.85.213.46]:58877 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751705Ab2BTSLQ (ORCPT <rfc822;linux-media@vger.kernel.org>); Mon, 20 Feb 2012 13:11:16 -0500 Received: by yhoo21 with SMTP id o21so2685292yho.19 for <linux-media@vger.kernel.org>; Mon, 20 Feb 2012 10:11:16 -0800 (PST) Received-SPF: pass (google.com: domain of festevam@gmail.com designates 10.236.190.134 as permitted sender) client-ip=10.236.190.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of festevam@gmail.com designates 10.236.190.134 as permitted sender) smtp.mail=festevam@gmail.com; dkim=pass header.i=festevam@gmail.com Received: from mr.google.com ([10.236.190.134]) by 10.236.190.134 with SMTP id e6mr29722599yhn.98.1329761476236 (num_hops = 1); Mon, 20 Feb 2012 10:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer; bh=/KQEgMzPsxRS+uQi5H/AfzRe8ijn9bpcSlvNdwAFQio=; b=DVUjazOy5tyejMr/4S3wWlcct1wyFV5XR0Vu5JdykKMPMmQeHimRWQQN70TcwDBUxM MlNg03h2YCrSyRkXwTWO16pjV1GAmH0IQFC4CTeA5Ec+lYHPV+fgMPFfDr681KwN1iJg 9/0m07czPRvoT5NsZphGhhIDmi63uVtAd1YME= Received: by 10.236.190.134 with SMTP id e6mr22930916yhn.98.1329761476174; Mon, 20 Feb 2012 10:11:16 -0800 (PST) Received: from localhost.localdomain ([189.5.21.38]) by mx.google.com with ESMTPS id n72sm47852294yhh.21.2012.02.20.10.11.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 10:11:15 -0800 (PST) From: Fabio Estevam <festevam@gmail.com> To: linux-media@vger.kernel.org Cc: g.liakhovetski@gmx.de, mchehab@infradead.org, kernel@pengutronix.de, Fabio Estevam <festevam@gmail.com>, Fabio Estevam <fabio.estevam@freescale.com> Subject: [PATCH] video: mx3_camera: Allocate camera object via kzalloc Date: Mon, 20 Feb 2012 16:11:07 -0200 Message-Id: <1329761467-14417-1-git-send-email-festevam@gmail.com> X-Mailer: git-send-email 1.7.1 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.20.180316 X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' FORGED_FROM_GMAIL 0.1, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS ' |
Commit Message
Fabio Estevam
Feb. 20, 2012, 6:11 p.m. UTC
Align mx3_camera driver with the other soc camera driver implementations
by allocating the camera object via kzalloc.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/media/video/mx3_camera.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Comments
On Mon, 20 Feb 2012, Fabio Estevam wrote: > Align mx3_camera driver with the other soc camera driver implementations > by allocating the camera object via kzalloc. Sorry, any specific reason, why you think this "aligning" is so important? I personally don't see any. Thanks Guennadi > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> > --- > drivers/media/video/mx3_camera.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c > index 7452277..cccd574 100644 > --- a/drivers/media/video/mx3_camera.c > +++ b/drivers/media/video/mx3_camera.c > @@ -1159,7 +1159,7 @@ static int __devinit mx3_camera_probe(struct platform_device *pdev) > goto egetres; > } > > - mx3_cam = vzalloc(sizeof(*mx3_cam)); > + mx3_cam = kzalloc(sizeof(*mx3_cam), GFP_KERNEL); > if (!mx3_cam) { > dev_err(&pdev->dev, "Could not allocate mx3 camera object\n"); > err = -ENOMEM; > -- > 1.7.1 > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 20, 2012 at 4:17 PM, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > On Mon, 20 Feb 2012, Fabio Estevam wrote: > >> Align mx3_camera driver with the other soc camera driver implementations >> by allocating the camera object via kzalloc. > > Sorry, any specific reason, why you think this "aligning" is so important? Not really. Just compared it with all other soc camera drivers I found and mx3_camera was the only one that uses "vzalloc" Any specific reason that requires mx3_camera to use "vzalloc" instead of "kzalloc"? Tested with kzalloc and it worked fine on my mx31pdk. Regards, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 20-02-2012 16:23, Fabio Estevam escreveu: > On Mon, Feb 20, 2012 at 4:17 PM, Guennadi Liakhovetski > <g.liakhovetski@gmx.de> wrote: >> On Mon, 20 Feb 2012, Fabio Estevam wrote: >> >>> Align mx3_camera driver with the other soc camera driver implementations >>> by allocating the camera object via kzalloc. >> >> Sorry, any specific reason, why you think this "aligning" is so important? > > Not really. > > Just compared it with all other soc camera drivers I found and > mx3_camera was the only one that uses "vzalloc" > > Any specific reason that requires mx3_camera to use "vzalloc" instead > of "kzalloc"? kzalloc() is more restrictive than vzalloc(). With v*alloc, it will allocate a virtual memory area, with can be discontinuous, while kzalloc will get a continuous area. The DMA logic need to be prepared for virtual memory, if v*alloc() is used (e. g. using videobuf2-vmalloc). As it is currently including media/videobuf2-dma-contig.h, I this patch makes sense on my eyes. > > Tested with kzalloc and it worked fine on my mx31pdk. If the driver is working with vzalloc, then maybe it is due to some arch-specific implementation for v*alloc. It shouldn't be working like that. Regards, Mauro > > Regards, > > Fabio Estevam > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 19 Mar 2012, Mauro Carvalho Chehab wrote: > Em 20-02-2012 16:23, Fabio Estevam escreveu: > > On Mon, Feb 20, 2012 at 4:17 PM, Guennadi Liakhovetski > > <g.liakhovetski@gmx.de> wrote: > >> On Mon, 20 Feb 2012, Fabio Estevam wrote: > >> > >>> Align mx3_camera driver with the other soc camera driver implementations > >>> by allocating the camera object via kzalloc. > >> > >> Sorry, any specific reason, why you think this "aligning" is so important? > > > > Not really. > > > > Just compared it with all other soc camera drivers I found and > > mx3_camera was the only one that uses "vzalloc" > > > > Any specific reason that requires mx3_camera to use "vzalloc" instead > > of "kzalloc"? > > kzalloc() is more restrictive than vzalloc(). With v*alloc, it will allocate > a virtual memory area, with can be discontinuous, while kzalloc will get > a continuous area. > > The DMA logic need to be prepared for virtual memory, if v*alloc() is used > (e. g. using videobuf2-vmalloc). > > As it is currently including media/videobuf2-dma-contig.h, I this patch > makes sense on my eyes. Don't think so. vzalloc() is used in mx3_camera to allocate driver private data objects and are never used for DMA, so, it doesn't have any restrictions on contiguity, coherency, alignment etc. One could argue, that since the struct is anyway smaller than 1 page, it anyway will be allocated in a physically contiguous memory area (will it?) and so, maybe, kmalloc() is less heavy weight than vmalloc() and might save a couple of CPU cycles, but I don't think it's anything important, that we should be optimising for. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Guennadi, On 3/20/12, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > Don't think so. vzalloc() is used in mx3_camera to allocate driver private > data objects and are never used for DMA, so, it doesn't have any > restrictions on contiguity, coherency, alignment etc. Is this valid only for mx3_camera driver? All other soc camera drivers use kzalloc. What makes mx3_camera different in this respect? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 20 Mar 2012, Fabio Estevam wrote: > Hi Guennadi, > > On 3/20/12, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > > > Don't think so. vzalloc() is used in mx3_camera to allocate driver private > > data objects and are never used for DMA, so, it doesn't have any > > restrictions on contiguity, coherency, alignment etc. > > Is this valid only for mx3_camera driver? No > All other soc camera drivers use kzalloc. > > What makes mx3_camera different in this respect? Nothing Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3/20/12, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: >> Is this valid only for mx3_camera driver? > > No > >> All other soc camera drivers use kzalloc. >> >> What makes mx3_camera different in this respect? > > Nothing Ok, so isn't my patch correct then? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 20-03-2012 04:57, Guennadi Liakhovetski escreveu: > On Mon, 19 Mar 2012, Mauro Carvalho Chehab wrote: > >> Em 20-02-2012 16:23, Fabio Estevam escreveu: >>> On Mon, Feb 20, 2012 at 4:17 PM, Guennadi Liakhovetski >>> <g.liakhovetski@gmx.de> wrote: >>>> On Mon, 20 Feb 2012, Fabio Estevam wrote: >>>> >>>>> Align mx3_camera driver with the other soc camera driver implementations >>>>> by allocating the camera object via kzalloc. >>>> >>>> Sorry, any specific reason, why you think this "aligning" is so important? >>> >>> Not really. >>> >>> Just compared it with all other soc camera drivers I found and >>> mx3_camera was the only one that uses "vzalloc" >>> >>> Any specific reason that requires mx3_camera to use "vzalloc" instead >>> of "kzalloc"? >> >> kzalloc() is more restrictive than vzalloc(). With v*alloc, it will allocate >> a virtual memory area, with can be discontinuous, while kzalloc will get >> a continuous area. >> >> The DMA logic need to be prepared for virtual memory, if v*alloc() is used >> (e. g. using videobuf2-vmalloc). >> >> As it is currently including media/videobuf2-dma-contig.h, I this patch >> makes sense on my eyes. > > Don't think so. vzalloc() is used in mx3_camera to allocate driver private > data objects and are never used for DMA, so, it doesn't have any > restrictions on contiguity, coherency, alignment etc. OK. In this case, using v*alloc()/vfree() won't be that different than k*alloc()/k*free(). > One could argue, that since the struct is anyway smaller than 1 page, it > anyway will be allocated in a physically contiguous memory area (will it?) > and so, maybe, kmalloc() is less heavy weight than vmalloc() and might > save a couple of CPU cycles, but I don't think it's anything important, > that we should be optimising for. Yes. There's another aspect to consider there: the vmalloc space is limited (there's a boot time parameter to regulate its size)[1]. I dunno why, nor what are the consequences of using a bigger value, but I think a big vmalloc size creates a big table to map between virtual/physical memory space. Yet, a single page is far below the vmaloc default max size, except if the system has very severe memory constraints. [1] On x86, I think that the default is 256MB. Several video adapters eat a lot of space there. I use a bigger value here, otherwise my 3-head system won't initialize all screens. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 20 Mar 2012, Fabio Estevam wrote: > On 3/20/12, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > > >> Is this valid only for mx3_camera driver? > > > > No > > > >> All other soc camera drivers use kzalloc. > >> > >> What makes mx3_camera different in this respect? > > > > Nothing > > Ok, so isn't my patch correct then? No. It doesn't improve anything. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, I acquire this usb stick 07ca:a835 and it's still does not work properly. Now, with the af9035 patch from http://openpli.git.sourceforge.net/git/gitweb.cgi?p=openpli/openembedded;a=blob_plain;f=recipes/linux/linux-etxx00/dvb-usb-af9035.patch;hb=HEAD the tv interface is recognize but have trouble with kaffeine, tvtime and gnome-dvb-daemon. Here's a trace from gnome : "af9033: I2C read failed reg:0047". From kaffeine : "kaffeine(3817) DvbDevice::frontendEvent: tuning failed". From tvtime, nothing card doesn't appear : probably missing conf, it's ok. This message try to follow Andrej Podzimekand Gianluca Gennari's messages on 02/07/2012. Does someone got ideas about what to do to correct this ? kernel : 3.2.11 with patch noticed. No externe v4l at all during construct. Compile fine : Mar 18 16:09:43 localhost kernel: [ 305.726981] dvb-usb: found a 'Avermedia AverTV Volar HD & HD PRO (A835)' in cold state, will try to load a firmware Mar 18 16:09:43 localhost kernel: [ 305.742050] dvb-usb: downloading firmware from file 'dvb-usb-af9035-01.fw' Mar 18 16:09:43 localhost kernel: [ 306.039886] dvb-usb: found a 'Avermedia AverTV Volar HD & HD PRO (A835)' in warm state. Mar 18 16:09:43 localhost kernel: [ 306.040032] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Mar 18 16:09:43 localhost kernel: [ 306.040406] DVB: registering new adapter (Avermedia AverTV Volar HD & HD PRO (A835)) Mar 18 16:09:43 localhost kernel: [ 306.078104] af9033: firmware version: LINK:11.15.10.0 OFDM:5.48.10.0 Mar 18 16:09:43 localhost kernel: [ 306.080355] DVB: registering adapter 0 frontend 0 (Afatech AF9033 DVB-T)... Mar 18 16:09:43 localhost kernel: [ 306.129981] tda18218: NXP TDA18218HN successfully identified. Mar 18 16:09:43 localhost kernel: [ 306.131483] dvb-usb: Avermedia AverTV Volar HD & HD PRO (A835) successfully initialized and connected. Mar 18 16:09:43 localhost kernel: [ 306.140531] usbcore: registered new interface driver dvb_usb_af9035 Best regards. See ya. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c index 7452277..cccd574 100644 --- a/drivers/media/video/mx3_camera.c +++ b/drivers/media/video/mx3_camera.c @@ -1159,7 +1159,7 @@ static int __devinit mx3_camera_probe(struct platform_device *pdev) goto egetres; } - mx3_cam = vzalloc(sizeof(*mx3_cam)); + mx3_cam = kzalloc(sizeof(*mx3_cam), GFP_KERNEL); if (!mx3_cam) { dev_err(&pdev->dev, "Could not allocate mx3 camera object\n"); err = -ENOMEM;