Your company import from China, we help in logistics field.
Dear Sirs: Glad to write you! Does your company have imported goods from China?If so, please send your packing list to me.I can give you a quotation for reference. Hope our years of experience in the logistics field and good service can give you help. Happy new year. --- Alfred Shenzhen Dongda Freight agency CO., LTD --- Tel:86-755-61961370 Mob:86-18929393836 Fax:86-755-29196661 Email:alfred_wei...@sina.comsal...@ddhy168.com SKYPE:ddhy168 QQ:1559489526 Web:www.ddhy168.com Address: 516 Baishiwei Logistics Park Fuwei Community Fuyong Street Bao'an District, Shenzhen,518103 ChinaN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w*jg�报�茛j/�赇z罐���2���ㄨ��&�)摺�a囤���G���h��j:+v���w��佶
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Dec 28 04:00:15 CET 2015 git branch: test git hash: 768acf46e1320d6c41ed1b7c4952bab41c1cde79 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-51-ga53cea2 smatch version: v0.5.0-3228-g5cf65ab host hardware: x86_64 host os:4.3.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-rc1-i686: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/23] Unrestricted media entity ID range support
Hello Laurent, On 12/27/2015 02:11 PM, Laurent Pinchart wrote: > Hi Mauro, > > On Wednesday 23 December 2015 10:32:42 Mauro Carvalho Chehab wrote: >> Em Wed, 16 Dec 2015 16:03:01 +0200 Sakari Ailus escreveu: >>> On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote: This is the third version of the unrestricted media entity ID range support set. I've taken Mauro's comments into account and fixed a number of bugs as well (omap3isp memory leak and omap4iss stream start). >>> >>> Javier: Mauro told me you might have OMAP4 hardware. Would you be able to >>> test the OMAP4 ISS with these patches? >>> >>> Thanks. >> >> Sakari, >> >> Testing with OMAP4 is not possible. The driver is broken: it doesn't >> support DT, and the required pdata definition is missing. > > What do you mean by missing ? struct iss_platform_data is defined in > include/media/omap4iss.h. > That's true but at the very least the omap4iss hwmod is broken in mainline as you mentioned in the linux-media thread that Mauro shared below. I think what Mauro meant is that there isn't an omap4 board supported in mainline that makes use of the iss platform data structures. So testing the driver in a popular omap4 board such as the pandaboard isn't possible without adding plumbing board code. And even in that case, the driver fails to probe due a missing iss_fck clock as Mauro mentioned in his boot log below as well. I know is not a requirement for a driver to have mainline users but without DT bindings, using this driver will not be possible sooner rather than later once the mach-omap2 pdata-quirks.c workaround is removed from mainline since the omap4 board files were deleted almost 3 years ago (3.11 according to git). >> Both Javier and I tried to fix it in the last couple days, in order to test >> it with a PandaBoard. We came with the enclosed patch, but it is still >> incomplete. Based on what's written on this e-mail: >> https://www.mail-archive.com/linux-media@vger.kernel.org/msg89247.html >> >> It seems that this is an already known issue. >> >> So, I'm considering this driver as BROKEN. Not much sense on doing any >> tests on it, while this doesn't get fixed. >> >> Regards, >> Mauro >> >> PS.: With the enclosed patch, I got this error: >> [0.267639] platform omap4iss: failed to claim resource 2 >> >> But, even if I comment out the platform code that returns this error, >> there are still other missing things: >> [7.131622] omap4iss omap4iss: Unable to get iss_fck clock info >> [7.137878] omap4iss omap4iss: Unable to get clocks >> >> --- >> >> ARM: add a pdata quirks for OMAP4 panda camera >> >> This is a hack to make it to believe that the pandaboard >> has a camera. >> >> >> diff --git a/arch/arm/mach-omap2/pdata-quirks.c >> b/arch/arm/mach-omap2/pdata-quirks.c index 1dfe34654c43..998bb6936dc0 >> 100644 >> --- a/arch/arm/mach-omap2/pdata-quirks.c >> +++ b/arch/arm/mach-omap2/pdata-quirks.c >> @@ -36,6 +36,8 @@ >> #include "soc.h" >> #include "hsmmc.h" >> >> +#include "../../../drivers/staging/media/omap4iss/iss.h" >> + >> struct pdata_init { >> const char *compatible; >> void (*fn)(void); >> @@ -408,6 +410,124 @@ static void __init t410_abort_init(void) >> } >> #endif >> >> +#ifdef CONFIG_ARCH_OMAP4 >> + >> +static struct resource panda_iss_resource[] = { >> +{ >> +.start = 0x5200, >> +.end = 0x5200 + 0x100, >> +.name = "top", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52001000, >> +.end = 0x52001000 + 0x170, >> +.name = "csi2_a_regs1", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52001170, >> +.end = 0x52001170 + 0x020, >> +.name = "camerarx_core1", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52001400, >> +.end = 0x52001400 + 0x170, >> +.name = "csi2_b_regs1", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52001570, >> +.end = 0x52001570 + 0x020, >> +.name = "camerarx_core2", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52002000, >> +.end = 0x52002000 + 0x200, >> +.name = "bte", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x5201, >> +.end = 0x5201 + 0x0a0, >> +.name = "isp_sys1", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52010400, >> +.end = 0x52010400 + 0x400, >> +.name = "isp_resizer", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52010800, >> +.end = 0x52010800 + 0x800, >> +.name = "isp_ipipe", >> +.flags = IORESOURCE_MEM, >> +}, { >> +.start = 0x52011000, >> +.end = 0x52011000 + 0x200, >> +
Re: [PATCH 2/2] [media] media-device: split media initialization and registration
Hi Mauro, On Tue, Dec 15, 2015 at 09:13:42AM -0200, Mauro Carvalho Chehab wrote: > Em Thu, 10 Sep 2015 20:14:04 +0300 > Sakari Ailus escreveu: > > > Hi Javier, > > > > Thanks for the set! A few comments below. > > > > Javier Martinez Canillas wrote: > > > The media device node is registered and so made visible to user-space > > > before entities are registered and links created which means that the > > > media graph obtained by user-space could be only partially enumerated > > > if that happens too early before all the graph has been created. > > > > > > To avoid this race condition, split the media init and registration > > > in separate functions and only register the media device node when > > > all the pending subdevices have been registered, either explicitly > > > by the driver or asynchronously using v4l2_async_register_subdev(). > > > > > > Also, add a media_entity_cleanup() function that will destroy the > > > graph_mutex that is initialized in media_entity_init(). > > > > > > Suggested-by: Sakari Ailus > > > Signed-off-by: Javier Martinez Canillas > > > > > > --- > > > > > > drivers/media/common/siano/smsdvb-main.c | 1 + > > > drivers/media/media-device.c | 38 > > > +++ > > > drivers/media/platform/exynos4-is/media-dev.c | 12 ++--- > > > drivers/media/platform/omap3isp/isp.c | 11 +--- > > > drivers/media/platform/s3c-camif/camif-core.c | 13 ++--- > > > drivers/media/platform/vsp1/vsp1_drv.c| 19 ++ > > > drivers/media/platform/xilinx/xilinx-vipp.c | 11 +--- > > > drivers/media/usb/au0828/au0828-core.c| 26 +- > > > drivers/media/usb/cx231xx/cx231xx-cards.c | 22 +++- > > > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 11 +--- > > > drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 13 ++--- > > > drivers/media/usb/siano/smsusb.c | 14 -- > > > drivers/media/usb/uvc/uvc_driver.c| 9 +-- > > > include/media/media-device.h | 2 ++ > > > 14 files changed, 156 insertions(+), 46 deletions(-) > > > > > > diff --git a/drivers/media/common/siano/smsdvb-main.c > > > b/drivers/media/common/siano/smsdvb-main.c > > > index ab345490a43a..8a1ea2192439 100644 > > > --- a/drivers/media/common/siano/smsdvb-main.c > > > +++ b/drivers/media/common/siano/smsdvb-main.c > > > @@ -617,6 +617,7 @@ static void smsdvb_media_device_unregister(struct > > > smsdvb_client_t *client) > > > if (!coredev->media_dev) > > > return; > > > media_device_unregister(coredev->media_dev); > > > + media_device_cleanup(coredev->media_dev); > > > kfree(coredev->media_dev); > > > coredev->media_dev = NULL; > > > #endif > > > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c > > > index 745defb34b33..a8beb0b445a6 100644 > > > --- a/drivers/media/media-device.c > > > +++ b/drivers/media/media-device.c > > > @@ -526,7 +526,7 @@ static void media_device_release(struct media_devnode > > > *mdev) > > > } > > > > > > /** > > > - * media_device_register - register a media device > > > + * media_device_init() - initialize a media device > > > * @mdev:The media device > > > * > > > * The caller is responsible for initializing the media device before > > > @@ -534,12 +534,11 @@ static void media_device_release(struct > > > media_devnode *mdev) > > > * > > > * - dev must point to the parent device > > > * - model must be filled with the device model name > > > + * > > > + * returns zero on success or a negative error code. > > > */ > > > -int __must_check __media_device_register(struct media_device *mdev, > > > - struct module *owner) > > > +int __must_check media_device_init(struct media_device *mdev) > > > > I think I suggested making media_device_init() return void as the only > > remaining source of errors would be driver bugs. > > > > I'd simply replace the WARN_ON() below with BUG(). > > That sounds like bad idea to me, and it is against the current > Kernel policy of using BUG() only when there's no other way, e. g. on > event so severe that the Kernel has no other thing to do except to > stop running. > > For sure, this is not the case here. Also, all drivers have already > a logic that checks if the device init happened. So, they should already > be doing the right thing. My point is that it's simply counter-productive to require the caller to perform error handling in cases such as the only possible source of the error being a NULL argument passed to the callee. To give you some examples, device_register(), device_add() nor mutex_lock() perform such checks. Some functions in V4L2 do, but I understand that's sometimes for historical reasons where NULL arguments were allowed. Or that there are other possible sources for errors in non-trivial functions and the rest of the checks are done on the side. If you don't like BUG_
Re: [PATCH 2/2] [media] media: move MEDIA_LNK_FL_INTERFACE_LINK logic to link creation
Hi Mauro, (Resending, there was an error in handling the cc field.) On Fri, Dec 11, 2015 at 06:17:53PM -0200, Mauro Carvalho Chehab wrote: > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c > index 181ca0de6e52..7895e17aeee9 100644 > --- a/drivers/media/media-entity.c > +++ b/drivers/media/media-entity.c > @@ -526,7 +526,7 @@ media_create_pad_link(struct media_entity *source, u16 > source_pad, > > link->source = &source->pads[source_pad]; > link->sink = &sink->pads[sink_pad]; > - link->flags = flags; > + link->flags = flags && ~MEDIA_LNK_FL_INTERFACE_LINK; s/&&/&/ > > /* Initialize graph object embedded at the new link */ > media_gobj_create(source->graph_obj.mdev, MEDIA_GRAPH_LINK, > @@ -756,7 +756,7 @@ struct media_link *media_create_intf_link(struct > media_entity *entity, > > link->intf = intf; > link->entity = entity; > - link->flags = flags; > + link->flags = flags | MEDIA_LNK_FL_INTERFACE_LINK; > > /* Initialize graph object embedded at the new link */ > media_gobj_create(intf->graph_obj.mdev, MEDIA_GRAPH_LINK, -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] v4l: subdev: Register the entity before calling subdev's registered op
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system] Hi Sakari, [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v4.4-rc6 next-20151223] url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-subdev-Register-the-entity-before-calling-subdev-s-registered-op/20151228-074927 base: git://linuxtv.org/media_tree.git master config: x86_64-randconfig-x016-201552 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/media/v4l2-core/v4l2-device.c: In function 'v4l2_device_register_subdev': >> drivers/media/v4l2-core/v4l2-device.c:210:33: error: 'entity' undeclared >> (first use in this function) media_device_unregister_entity(entity); ^ drivers/media/v4l2-core/v4l2-device.c:210:33: note: each undeclared identifier is reported only once for each function it appears in vim +/entity +210 drivers/media/v4l2-core/v4l2-device.c 204 list_add_tail(&sd->list, &v4l2_dev->subdevs); 205 spin_unlock(&v4l2_dev->lock); 206 207 return 0; 208 209 error_unregister: > 210 media_device_unregister_entity(entity); 211 error_module: 212 if (!sd->owner_v4l2_dev) 213 module_put(sd->owner); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[PATCH 1/1] v4l: subdev: Register the entity before calling subdev's registered op
Registering a V4L2 sub-device includes, among other things, registering the related media entity and calling the sub-device's registered op. Since patch "media: convert links from array to list", creating a link between two pads requires registering the entity first. If the registered() op involves link creation, the link list head will not be initialised before it is used. Resolve this by first registering the entity, then calling its registered() op. Signed-off-by: Sakari Ailus --- Hi Mauro, You seem to be missing this patch from your media-controller-rc4 branch. Not having it breaks at least the smiapp driver. I was pretty sure to have sent it but I can't find it on linux-media. Oh well. Speaking of the entity function warnings --- I'd omit them until we've agreed that this is what we should really have (I don't think so). I can submit a patch to remove them if you like. --8< [ 108.919189] omap3isp 480bc000.isp: Entity type for entity jt8ew9 binner 1-0010 was not initialized! [ 108.929046] Unable to handle kernel NULL pointer dereference at virtual address [ 108.937652] pgd = ed0b8000 [ 108.940521] [] *pgd=aefc3831, *pte=, *ppte= [ 108.947204] Internal error: Oops: 817 [#1] ARM [ 108.951904] Modules linked in: smiapp(+) smiapp_pll omap3_isp videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media [ 108.966735] CPU: 0 PID: 1163 Comm: modprobe Not tainted 4.4.0-rc2-00328-g40e950d #507 [ 108.975006] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 108.981597] task: eeb91340 ti: eec6e000 task.ti: eec6e000 [ 108.987335] PC is at media_add_link+0x34/0x44 [media] [ 108.992645] LR is at 0x0 [ 108.995330] pc : []lr : [<>]psr: a013 [ 108.995330] sp : eec6fc78 ip : fp : [ 109.007415] r10: r9 : 0003 r8 : 1c40 [ 109.012939] r7 : r6 : 001c r5 : ee9a7248 r4 : ee9a70c4 [ 109.019805] r3 : r2 : 1c10 r1 : ee8000c0 r0 : 1c00 [ 109.026672] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 109.034210] Control: 10c5387d Table: ad0b8019 DAC: 0051 [ 109.040252] Process modprobe (pid: 1163, stack limit = 0xeec6e208) [ 109.046752] Stack: (0xeec6fc78 to 0xeec7) [ 109.051361] fc60: ee9a7098 bf0021b4 [ 109.059997] fc80: ee9a7010 eec6fcbc eea1fc00 ee9a7248 eec6fcc0 ee9a7098 [ 109.068634] fca0: 0136 bf09c520 0003 ee9a7140 eeb91340 ee9a7098 ee9a7248 ee9a73f8 [ 109.077270] fcc0: ee9a7010 ee9a7098 eefd0010 ed08f620 bf024d8c 035a 1dc13000 [ 109.085906] fce0: bf014488 eefd0084 ee9a7098 ed08f620 bf024d8c bf01d384 [ 109.094543] fd00: ee9a7140 eefd0090 ed08f620 bf024d48 ee9a7098 eefd0084 ee9a7140 bf01d444 [ 109.103179] fd20: 6650 eea1fc00 ee9a7010 66c0 0003 bf09c3f8 1dc13000 [ 109.111785] fd40: 0002 c02bab44 ef7e2994 eea1fc00 bf09c13c bf09eba4 eea1fc04 [ 109.120422] fd60: eea1fc20 eec6ff0c c028b7dc eea1fc20 bf09ebc0 c0dce564 [ 109.129058] fd80: 0002 c02112dc bf09ebc0 eea1fc20 0002 [ 109.137695] fda0: eea1fc20 eea1fc54 bf09ebc0 c05908e0 c02115c8 bf09ebc0 eec6fdc8 [ 109.146331] fdc0: c0211560 c020f8ac ee92c6a4 eea78410 bf09ebc0 bf09ebc0 ee9ec240 c05d1e74 [ 109.154968] fde0: c05908e0 c0210110 bf09d8ec eec6fd90 bf09ebc0 bf0a3000 c0211cc4 [ 109.163604] fe00: bf09eba4 bf0a3000 c028bd94 6780 bf0a3000 c0009784 [ 109.172241] fe20: efdd6ca0 efdd6cc0 0001 c009709c eeb91340 efdd6ca0 [ 109.180877] fe40: c0063428 eeb91340 0001 c00c4f1c eedb13c0 [ 109.189514] fe60: 0018 c005fdc8 024000c0 ee8000c0 6013 bf09f340 eec6ff48 eedb13c0 [ 109.198150] fe80: 0001 0018 eec6ff0c c008ac94 bf09f340 [ 109.206756] fea0: efd99ff4 bf09f340 eec6ff48 bf09f34c 0001 c008c634 8000 7fff [ 109.215393] fec0: c008a8f4 f163a300 f163a448 07d0 0186 0001cfc0 f16b9e80 [ 109.224029] fee0: bf09f344 eec6ff1c [ 109.232666] ff00: 1c02 c019cf24 2013 c050e0b8 0055 0001 0001 b6dfdea8 [ 109.241302] ff20: 6ea8 0001cfc0 f16b9ea8 eec6e000 0051 0001cf48 c008cb04 [ 109.249938] ff40: 6013 c005dcf4 f1633000 00086ea8 f16b96b0 f1697f05 f1699958 7560 [ 109.258575] ff60: 8670 bf09ef90 0025 0031 0032 0017 001b [ 109.267211] ff80: 0010 0001b070 0001b070 0080 c000fa44 [ 109.275848] ffa0: c000f8a0 0001b070 b6d77000 00086ea8 0001cfc0 [ 109.284484] ffc0: 0001b070 0080 0001cfe0 0001cf48 [ 109.293121] ffe0: 0001cfc0 bea866fc 0
[PATCH] [media] bttv: Returning only value constants in two functions
From: Markus Elfring Date: Sun, 27 Dec 2015 22:02:21 +0100 Return constant integer values without storing them in the local variable "err" or "rc". Signed-off-by: Markus Elfring --- drivers/media/pci/bt8xx/bttv-driver.c | 25 ++--- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 9400e99..cd7d6ef 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -1726,22 +1726,15 @@ static int bttv_s_std(struct file *file, void *priv, v4l2_std_id id) struct bttv_fh *fh = priv; struct bttv *btv = fh->btv; unsigned int i; - int err = 0; for (i = 0; i < BTTV_TVNORMS; i++) if (id & bttv_tvnorms[i].v4l2_id) break; - if (i == BTTV_TVNORMS) { - err = -EINVAL; - goto err; - } - + if (i == BTTV_TVNORMS) + return -EINVAL; btv->std = id; set_tvnorm(btv, i); - -err: - - return err; + return 0; } static int bttv_g_std(struct file *file, void *priv, v4l2_std_id *id) @@ -1770,12 +1763,9 @@ static int bttv_enum_input(struct file *file, void *priv, { struct bttv_fh *fh = priv; struct bttv *btv = fh->btv; - int rc = 0; - if (i->index >= bttv_tvcards[btv->c.type].video_inputs) { - rc = -EINVAL; - goto err; - } + if (i->index >= bttv_tvcards[btv->c.type].video_inputs) + return -EINVAL; i->type = V4L2_INPUT_TYPE_CAMERA; i->audioset = 0; @@ -1799,10 +1789,7 @@ static int bttv_enum_input(struct file *file, void *priv, } i->std = BTTV_NORMS; - -err: - - return rc; + return 0; } static int bttv_g_input(struct file *file, void *priv, unsigned int *i) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: dvb_ringbuffer: Add memory barriers
Implement memory barriers according to Documentation/circular-buffers.txt: - use smp_store_release() to update ringbuffer read/write pointers - use smp_load_acquire() to load write pointer on reader side - use ACCESS_ONCE() to load read pointer on writer side This fixes data stream corruptions observed e.g. on an ARM Cortex-A9 quad core system with different types (PCI, USB) of DVB tuners. Signed-off-by: Soeren Moch Cc: sta...@vger.kernel.org # 3.14+ --- Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14, a 3.14+ stable tag was added. Is it desired to apply a similar patch to older stable kernels? --- drivers/media/dvb-core/dvb_ringbuffer.c | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c b/drivers/media/dvb-core/dvb_ringbuffer.c index 1100e98..58b5968 100644 --- a/drivers/media/dvb-core/dvb_ringbuffer.c +++ b/drivers/media/dvb-core/dvb_ringbuffer.c @@ -55,7 +55,7 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void *data, size_t len) int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf) { - return (rbuf->pread==rbuf->pwrite); + return (rbuf->pread == smp_load_acquire(&rbuf->pwrite)); } @@ -64,7 +64,7 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf) { ssize_t free; - free = rbuf->pread - rbuf->pwrite; + free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite; if (free <= 0) free += rbuf->size; return free-1; @@ -76,7 +76,7 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf) { ssize_t avail; - avail = rbuf->pwrite - rbuf->pread; + avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread; if (avail < 0) avail += rbuf->size; return avail; @@ -86,14 +86,15 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf) void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf) { - rbuf->pread = rbuf->pwrite; + smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite)); rbuf->error = 0; } EXPORT_SYMBOL(dvb_ringbuffer_flush); void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf) { - rbuf->pread = rbuf->pwrite = 0; + smp_store_release(&rbuf->pread, 0); + smp_store_release(&rbuf->pwrite, 0); rbuf->error = 0; } @@ -119,12 +120,12 @@ ssize_t dvb_ringbuffer_read_user(struct dvb_ringbuffer *rbuf, u8 __user *buf, si return -EFAULT; buf += split; todo -= split; - rbuf->pread = 0; + smp_store_release(&rbuf->pread, 0); } if (copy_to_user(buf, rbuf->data+rbuf->pread, todo)) return -EFAULT; - rbuf->pread = (rbuf->pread + todo) % rbuf->size; + smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size); return len; } @@ -139,11 +140,11 @@ void dvb_ringbuffer_read(struct dvb_ringbuffer *rbuf, u8 *buf, size_t len) memcpy(buf, rbuf->data+rbuf->pread, split); buf += split; todo -= split; - rbuf->pread = 0; + smp_store_release(&rbuf->pread, 0); } memcpy(buf, rbuf->data+rbuf->pread, todo); - rbuf->pread = (rbuf->pread + todo) % rbuf->size; + smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size); } @@ -158,10 +159,10 @@ ssize_t dvb_ringbuffer_write(struct dvb_ringbuffer *rbuf, const u8 *buf, size_t memcpy(rbuf->data+rbuf->pwrite, buf, split); buf += split; todo -= split; - rbuf->pwrite = 0; + smp_store_release(&rbuf->pwrite, 0); } memcpy(rbuf->data+rbuf->pwrite, buf, todo); - rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size; + smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size); return len; } @@ -181,12 +182,12 @@ ssize_t dvb_ringbuffer_write_user(struct dvb_ringbuffer *rbuf, return len - todo; buf += split; todo -= split; - rbuf->pwrite = 0; + smp_store_release(&rbuf->pwrite, 0); } status = copy_from_user(rbuf->data+rbuf->pwrite, buf, todo); if (status) return len - todo; - rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size; + smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size); return len; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v4l-utils PATCH] man: Fix typos in dvbv5-scan dvbv5-zap pages
Signed-off-by: Chris Mayo --- utils/dvb/dvbv5-scan.1.in | 2 +- utils/dvb/dvbv5-zap.1.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/utils/dvb/dvbv5-scan.1.in b/utils/dvb/dvbv5-scan.1.in index 8958ceb..e6fe3ee 100644 --- a/utils/dvb/dvbv5-scan.1.in +++ b/utils/dvb/dvbv5-scan.1.in @@ -172,7 +172,7 @@ New transponder/channel found: #39: 50700 .fi .PP The scan process will then scan the other 38 discovered new transponders, -and generate a dvb_channel.com with several entries with will have not only +and generate a dvb_channel.conf with several entries with will have not only the physical channel/transponder info, but also the Service ID, and the corresponding audio/video/other program IDs (PID), like: .PP diff --git a/utils/dvb/dvbv5-zap.1.in b/utils/dvb/dvbv5-zap.1.in index 9bf2687..2445593 100644 --- a/utils/dvb/dvbv5-zap.1.in +++ b/utils/dvb/dvbv5-zap.1.in @@ -167,7 +167,7 @@ DVR interface '/dev/dvb/adapter0/dvr0' can now be opened The channel can be watched by playing the contents of the DVR interface, with some player that recognizes the MPEG\-TS format. .PP -For example, this audio-only channel can be playew with mplayer: +For example, this audio-only channel can be played with mplayer: .PP .nf $ \fBmplayer \-cache 800 /dev/dvb/adapter0/dvr0\fR -- 2.4.10 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] si2165: Refactoring for si2165_writereg_mask8()
From: Markus Elfring Date: Sun, 27 Dec 2015 18:23:57 +0100 This issue was detected by using the Coccinelle software. 1. Let us return directly if a call of the si2165_readreg8() function failed. 2. Reduce the scope for the local variables "ret" and "tmp" to one branch of an if statement. 3. Delete the jump label "err" then. 4. Return the value from a call of the si2165_writereg8() function without using an extra assignment for the variable "ret" at the end. Signed-off-by: Markus Elfring --- drivers/media/dvb-frontends/si2165.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/media/dvb-frontends/si2165.c b/drivers/media/dvb-frontends/si2165.c index 2b93241..e8518ae 100644 --- a/drivers/media/dvb-frontends/si2165.c +++ b/drivers/media/dvb-frontends/si2165.c @@ -225,22 +225,18 @@ static int si2165_writereg32(struct si2165_state *state, const u16 reg, u32 val) static int si2165_writereg_mask8(struct si2165_state *state, const u16 reg, u8 val, u8 mask) { - int ret; - u8 tmp; - if (mask != 0xff) { - ret = si2165_readreg8(state, reg, &tmp); + u8 tmp; + int ret = si2165_readreg8(state, reg, &tmp); + if (ret < 0) - goto err; + return ret; val &= mask; tmp &= ~mask; val |= tmp; } - - ret = si2165_writereg8(state, reg, val); -err: - return ret; + return si2165_writereg8(state, reg, val); } #define REG16(reg, val) { (reg), (val) & 0xff }, { (reg)+1, (val)>>8 & 0xff } -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/23] Unrestricted media entity ID range support
Hi Mauro, On Wednesday 23 December 2015 10:32:42 Mauro Carvalho Chehab wrote: > Em Wed, 16 Dec 2015 16:03:01 +0200 Sakari Ailus escreveu: > > On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote: > > > This is the third version of the unrestricted media entity ID range > > > support set. I've taken Mauro's comments into account and fixed a number > > > of bugs as well (omap3isp memory leak and omap4iss stream start). > > > > Javier: Mauro told me you might have OMAP4 hardware. Would you be able to > > test the OMAP4 ISS with these patches? > > > > Thanks. > > Sakari, > > Testing with OMAP4 is not possible. The driver is broken: it doesn't > support DT, and the required pdata definition is missing. What do you mean by missing ? struct iss_platform_data is defined in include/media/omap4iss.h. > Both Javier and I tried to fix it in the last couple days, in order to test > it with a PandaBoard. We came with the enclosed patch, but it is still > incomplete. Based on what's written on this e-mail: >https://www.mail-archive.com/linux-media@vger.kernel.org/msg89247.html > > It seems that this is an already known issue. > > So, I'm considering this driver as BROKEN. Not much sense on doing any > tests on it, while this doesn't get fixed. > > Regards, > Mauro > > PS.: With the enclosed patch, I got this error: > [0.267639] platform omap4iss: failed to claim resource 2 > > But, even if I comment out the platform code that returns this error, > there are still other missing things: > [7.131622] omap4iss omap4iss: Unable to get iss_fck clock info > [7.137878] omap4iss omap4iss: Unable to get clocks > > --- > > ARM: add a pdata quirks for OMAP4 panda camera > > This is a hack to make it to believe that the pandaboard > has a camera. > > > diff --git a/arch/arm/mach-omap2/pdata-quirks.c > b/arch/arm/mach-omap2/pdata-quirks.c index 1dfe34654c43..998bb6936dc0 > 100644 > --- a/arch/arm/mach-omap2/pdata-quirks.c > +++ b/arch/arm/mach-omap2/pdata-quirks.c > @@ -36,6 +36,8 @@ > #include "soc.h" > #include "hsmmc.h" > > +#include "../../../drivers/staging/media/omap4iss/iss.h" > + > struct pdata_init { > const char *compatible; > void (*fn)(void); > @@ -408,6 +410,124 @@ static void __init t410_abort_init(void) > } > #endif > > +#ifdef CONFIG_ARCH_OMAP4 > + > +static struct resource panda_iss_resource[] = { > + { > + .start = 0x5200, > + .end = 0x5200 + 0x100, > + .name = "top", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52001000, > + .end = 0x52001000 + 0x170, > + .name = "csi2_a_regs1", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52001170, > + .end = 0x52001170 + 0x020, > + .name = "camerarx_core1", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52001400, > + .end = 0x52001400 + 0x170, > + .name = "csi2_b_regs1", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52001570, > + .end = 0x52001570 + 0x020, > + .name = "camerarx_core2", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52002000, > + .end = 0x52002000 + 0x200, > + .name = "bte", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x5201, > + .end = 0x5201 + 0x0a0, > + .name = "isp_sys1", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52010400, > + .end = 0x52010400 + 0x400, > + .name = "isp_resizer", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52010800, > + .end = 0x52010800 + 0x800, > + .name = "isp_ipipe", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52011000, > + .end = 0x52011000 + 0x200, > + .name = "isp_isif", > + .flags = IORESOURCE_MEM, > + }, { > + .start = 0x52011200, > + .end = 0x52011200 + 0x080, > + .name = "isp_ipipeif", > + .flags = IORESOURCE_MEM, > + } > +}; > + > +static struct i2c_board_info panda_camera_i2c_device = { > + I2C_BOARD_INFO("smia", 0x10), > +}; > + > +static struct iss_subdev_i2c_board_info panda_camera_subdevs[] = { > + { > + .board_info = &panda_camera_i2c_device, > + .i2c_adapter_id = 3, > + }, > +}; > + > +static struct iss_v4l2_subdevs_group iss_subdevs[] = { > + { > + .subdevs = panda_camera_subdevs, > + .interface = ISS_INTERFACE_CSI2A_PHY1, > + .bus = { > + .csi2 = { > + .lanecfg = { > + .clk = { > + .pol = 0,
Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
>> https://cwe.mitre.org/data/definitions/252.html > > The value is not unchecked. Would you like to express any stronger relationship between the function call example and the occurrence of an if statement by the discussed SmPL script? > I made a specific rule because the specific problem is quite common. Can it become also interesting to generalise this search pattern? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PCIe sg dma device used as dma-contig
Hello, The following question is not totally in the scope of v4l2, but more about your advise concering dma alternatives for non-expreciened v4l2 device writer. We intend to use the fpga for concurrent 3xHD and 3xSD. We have some dillema regadring the fpga to choose from: ALTERA fpga which use contiguous dma memory, or Xilinx fpga which is using scatter-gather architecture. With xilinx, it seems that the sg architecture can also be used as contiguous according to the following: "... While these descriptors are not required to be contiguous, they should be contained within an 8 megabyte region which corresponds to the width of the AXI_PCIe_SG port" it seems according to the above description that sg-list can be used as single contiguous descriptor (with dma-cotig), though the 8MBytes seems like a problematic constrain. This constrain make it difficult to be used with dma-contig solution in v4l2. Our current direction is try to imeplement it as simple as possible. Therefore we prefer the dma contiguous solution (I think that together with CMA and a strong cpu like 64-bit i7 it can handle contigious memory for 3xHD and 3xSD allocation). Any feedback is appreciated, Ran -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[media] af9013: Checking for register accesses?
Hello, I have looked at the implementations of functions like the following once more. https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/media/dvb-frontends/af9013.c?id=80c75a0f1d81922bf322c0634d1e1a15825a89e6#n124 * af9013_rd_regs * af9013_wr_regs Both functions will always return zero so far. Should they eventually forward an error code from other function calls? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
On Sun, 27 Dec 2015, SF Markus Elfring wrote: > > The error return value of platform_get_irq seems to often get dropped. > > How do you think about any more fine-tuning here? > > Commit message: > * … of the platform_get_irq() function seems to get dropped too often. > > * Why do you concentrate on a single function name? > Do you plan to extend this source code analysis approach? > > > > +@script:python r_report depends on report@ > > +j0 << r.j0; > > +j1 << r.j1; > > +@@ > > + > > +msg = "Propagate return value of platform_get_irq around line %s." % > > (j1[0].line) > > Are there more unchecked return values which are interesting > for further considerations? > https://cwe.mitre.org/data/definitions/252.html The value is not unchecked. I made a specific rule because the specific problem is quite common. julia
Probably a new board ID for em28xx: [1b80:e349]
Hi, I have a small usb-device with s-vhs, composite-video and stereo-audio cabels attached. The shell just says "MAGIX" and "Made in China". It has also a black button to push. I plugged it in to get some video grabbed but no /dev/videoX was created. "lsusb" output: Bus 003 Device 012: ID 1b80:e349 Afatech journalctl -f output: kernel: usb 3-1.1: new high-speed USB device number 12 using ehci-pci kernel: usb 3-1.1: New USB device found, idVendor=1b80, idProduct=e349 kernel: usb 3-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 kernel: usb 3-1.1: Product: USB 2861 Device mtp-probe[7688]: checking bus 3, device 12: "/sys/devices/pci:00/:00:1a.0/usb3/3-1/3-1.1" mtp-probe[7688]: bus: 3, device: 12 was not an MTP device Kernel is 4.1.13-5-default on openSuse 42.1 I opened that thing and found these chips: SAA7113H EM2860 EMP202 I did modprobe em28xx modprobe saa7115 but still got no video-device. (I use an application called "cheese" which works perfect with my other usb videograbbing device.) Is there anything else I can do? CU Peter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
On 12/27/2015 9:13 AM, Julia Lawall wrote: Well, looking again, the patch should be good. I just thought its goal was to fix the code as well... I could do that for the irq < 0 case, but I think that in that case, kbuild will only run the patch version, and the <= cases will not be reported on. I don't have a general fix for the <= 0. Is it even correct to have < in some cases and <= in others? That's a good question... In my prior fixes of this case I preferred to consider IRQ0 valid and so used 'irq < 0'. I myself don't share the "IRQ0 is invalid" sentiment... julia MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
> The error return value of platform_get_irq seems to often get dropped. How do you think about any more fine-tuning here? Commit message: * … of the platform_get_irq() function seems to get dropped too often. * Why do you concentrate on a single function name? Do you plan to extend this source code analysis approach? > +@script:python r_report depends on report@ > +j0 << r.j0; > +j1 << r.j1; > +@@ > + > +msg = "Propagate return value of platform_get_irq around line %s." % > (j1[0].line) Are there more unchecked return values which are interesting for further considerations? https://cwe.mitre.org/data/definitions/252.html Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html