[BUG] crystalhd git.linuxtv.org kernel driver: NULL pointer deref in bc_cproc_reset_stats() after crashing bino3d
Hello guys, I'm working on supporting BCM 970012/15 crystalhd decoder in userspace video/tv apps and can't find where to report bugs of http://git.linuxtv.org/jarod/crystalhd.git I think he just borrowed our git server. So I borrow this list to get more developers, testers and sw- quality guys in. Got a double free null pointer deref OOPS in chd_dec_free_iodata on crashing bino3d using crystalhd driver on debian wheezy Linux vdr1 3.6.10-PM #8 PREEMPT Sat Dec 15 00:54:11 CET 2012 i686 GNU/Linux crystalhd driver+lib, libavcodec crystalhd.c git HEAD but libavcodec53 reproducible and only occuring after Dec 27 12:12:17 vdr1 kernel: [33147.169731] crystalhd_hw_stats: Invalid Arguments log message. System not crashing, driver still usable. Note: I've disabled the legacy h264 software codec in libavcodec53 to force every app using h264_crystalhd for h.264 with my backport patch -Attached- from ffmpeg git HEAD of yesterday to libavcodec.so.53.61.100 , debian src ffmpeg 7:0.10.3-dmo1 0 using ./configure ... --disable-decoder='h264,h264_vdpau,h264_vda' to automate testing of (lib)crystalhd(.ko) with all apps requesting libavcodec h.264 ;-) Don't worry, I've left the "childlock" in the patch to not get this patch in any distro. y tom -Att: Kernel OOPS bt, etc Dec 27 12:11:57 vdr1 kernel: [33127.022053] crystalhd :02:00.0: Opening new user[0] handle Dec 27 12:12:00 vdr1 kernel: [33129.862089] start_capture: pause_th:12, resume_th:5 Dec 27 12:12:00 vdr1 kernel: [33130.273355] crystalhd :02:00.0: Closing user[0] handle via ioctl with mode 1417200 Dec 27 12:12:00 vdr1 kernel: [33130.589582] crystalhd :02:00.0: Opening new user[0] handle Dec 27 12:12:03 vdr1 kernel: [33133.464029] start_capture: pause_th:12, resume_th:5 Dec 27 12:12:17 vdr1 kernel: [33146.856414] crystalhd :02:00.0: Closing user[0] handle with mode 1417200 Dec 27 12:12:17 vdr1 kernel: [33147.169731] crystalhd_hw_stats: Invalid Arguments Dec 27 12:12:17 vdr1 kernel: [33147.169778] BUG: unable to handle kernel NULL pointer dereference at 0040 Dec 27 12:12:17 vdr1 kernel: [33147.170259] IP: [] do_raw_spin_trylock+0x8/0x50 Dec 27 12:12:17 vdr1 kernel: [33147.170621] *pdpt = 2b9cb001 *pde = Dec 27 12:12:17 vdr1 kernel: [33147.170622] Oops: [#1] PREEMPT Dec 27 12:12:17 vdr1 kernel: [33147.170622] Modules linked in: dvb_ttpci md5 crypto_hash cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative bnep rfcomm bluetooth crc16 binfmt_misc uinput fuse nfsd exportfs auth_rpcgss nfs_acl nfs lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_limit iptable_filter ip_tables af_packet ipv6 w83627ehf hwmon_vid hwmon uvcvideo isl6405 dvb_pll tda10086 saa7134_dvb tuner videobuf_dvb tda10021 saa7134 stv0297 snd_usb_audio cryptomgr aead arc4 crypto_blkcipher crypto_algapi snd_usbmidi_lib snd_hwdep rt73usb rt2x00usb rt2x00lib snd_pcm_oss budget_av snd_intel8x0 saa7146_vv budget_core ttpci_eeprom snd_ac97_codec saa7146 mac80211 ac97_bus snd_mixer_oss snd_seq_dummy snd_pcm snd_seq_oss cfg80211 dvb_core tveeprom videobuf2_vmalloc videobuf2_memops videobuf_dma_sg videobuf2_core snd_page_alloc snd_seq_midi joydev videobuf_core v4l2_common crc_itu_t crypto snd_ra wmidi videodev snd_seq_mid Dec 27 12:12:17 vdr1 kernel: i_event snd_seq rc_core shpchp snd_seq_device snd_timer snd serio_raw i2c_i801 pcspkr pci_hotplug rng_core crystalhd(O) 8250_pnp soundcore 8250 serial_core acpi_cpufreq mperf processor evdev ext3 mbcache jbd sg sr_mod sd_mod cdrom crc_t10dif hid_generic hid_sunplus usbhid hid ata_piix ahci libahci uhci_hcd ehci_hcd libata scsi_mod usbcore [last unloaded: dvb_ttpci] Dec 27 12:12:17 vdr1 kernel: [33147.170622] Pid: 23337, comm: bino Tainted: G O 3.6.10-PM #8/Alviso Dec 27 12:12:17 vdr1 kernel: [33147.170622] EIP: 0060:[] EFLAGS: 00210046 CPU: 0 Dec 27 12:12:17 vdr1 kernel: [33147.170622] EIP is at do_raw_spin_trylock+0x8/0x50 Dec 27 12:12:17 vdr1 kernel: [33147.170622] EAX: 0040 EBX: ECX: 0040 EDX: Dec 27 12:12:17 vdr1 kernel: [33147.170622] ESI: 0040 EDI: 00200292 EBP: f5379e5c ESP: f5379e58 Dec 27 12:12:17 vdr1 kernel: [33147.170622] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Dec 27 12:12:17 vdr1 kernel: [33147.170622] CR0: 8005003b CR2: 0040 CR3: 315c7000 CR4: 07f0 Dec 27 12:12:17 vdr1 kernel: [33147.170622] DR0: DR1: DR2: DR3: Dec 27 12:12:17 vdr1 kernel: [33147.170622] DR6: 0ff0 DR7: 0400 Dec 27 12:12:17 vdr1 kernel: [33147.170622] Process bino (pid: 23337, ti=f5378000 task=f59e2940 task.ti=f5378000) Dec 27 12:12:17 vdr1 kernel: [33147.170622] Stack: Dec 27 12:12:17 vdr1 kernel: [33147.170622] 0050 f5379e80 c136c9b5 0002 fa1f1bd6 f42e9400 Dec 27 12:12:17 vdr1 kernel: [33147.170622] f595dc88 f5379ed8 fa1f1bd6 0218 f5378000 00
[BUG] crystalhd git.linuxtv.org kernel driver: NULL pointer deref in crystalhd_dioq_fetch_wait() while playing SBS 3D h.264 in mplayer2
Hello guys, I'm working on supporting BCM 970012/15 crystalhd decoder in userspace video/tv apps and can't find where to report bugs of http://git.linuxtv.org/jarod/crystalhd.git I think he just borrowed our git server. So I borrow this list to get more developers, testers and sw- quality guys in. Got another null pointer deref OOPS in crystalhd_dioq_fetch_wait after chd_dec_free_iodata while playing 3D SBS with -vf stereo3d=sbsl:agmc using crystalhd driver on debian wheezy Linux vdr1 3.6.10-PM #8 PREEMPT Sat Dec 15 00:54:11 CET 2012 i686 GNU/Linux crystalhd driver+lib, libavcodec crystalhd.c git HEAD but libavcodec53 System not crashed but this issue needs rmmod -f and modprobe /-r again otherwise crash on access, see bt #2 below. And there's something strange: Why is pulseaudio loading libcrystalhd.so , see lsof output end of logs below. Note: I've disabled the legacy h264 software codec in libavcodec53 to force every app using h264_crystalhd for h.264 with my backport patch -Attached- from ffmpeg git HEAD of yesterday to libavcodec.so.53.61.100 , debian src ffmpeg 7:0.10.3-dmo1 0 using ./configure ... --disable-decoder='h264,h264_vdpau,h264_vda' to automate testing of (lib)crystalhd(.ko) with all apps requesting libavcodec h.264 ;-) Don't worry, I've left the "childlock" in the patch to not get this patch in any distro. y tom -Att: Backport patch for crystalhd.c using in libavcodec53 -Att: Kernel OOPS bt, etc Dec 29 03:45:48 vdr1 kernel: [21380.312142] crystalhd :02:00.0: list_index:0 rx[631] rxtot[65358] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0 Dec 29 03:45:48 vdr1 kernel: [21380.345357] crystalhd :02:00.0: MISSING 2 PICTURES Dec 29 03:45:57 vdr1 kernel: [21389.239365] crystalhd :02:00.0: list_index:1 rx[632] rxtot[65907] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0 Dec 29 03:45:57 vdr1 kernel: [21389.299893] crystalhd :02:00.0: list_index:0 rx[633] rxtot[65910] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0 Dec 29 03:45:58 vdr1 kernel: [21390.298013] crystalhd :02:00.0: list_index:1 rx[634] rxtot[65971] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0 Dec 29 03:45:59 vdr1 kernel: [21391.287414] crystalhd :02:00.0: list_index:0 rx[635] rxtot[66032] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0 Dec 29 03:46:03 vdr1 kernel: [21395.291567] crystalhd :02:00.0: list_index:0 rx[636] rxtot[66278] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0 Dec 29 03:46:04 vdr1 kernel: [21396.298724] crystalhd :02:00.0: list_index:0 rx[637] rxtot[66340] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0 Dec 29 03:46:06 vdr1 kernel: [21398.262450] crystalhd :02:00.0: list_index:1 rx[638] rxtot[66461] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0 Dec 29 03:46:09 vdr1 kernel: [21400.767268] crystalhd :02:00.0: list_index:1 rx[639] rxtot[66615] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0 Dec 29 03:46:11 vdr1 kernel: [21403.254963] crystalhd :02:00.0: list_index:0 rx[640] rxtot[66768] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0 Dec 29 03:46:13 vdr1 kernel: [21405.292398] crystalhd :02:00.0: list_index:1 rx[641] rxtot[66893] Y:10 UV:0 Int:800 YDnSz:0 UVDnSz:0 Dec 29 03:46:14 vdr1 kernel: [21406.288434] crystalhd :02:00.0: list_index:0 rx[642] rxtot[66954] Y:2 UV:0 Int:8 YDnSz:0 UVDnSz:0 Dec 29 03:46:15 vdr1 kernel: [21406.782372] BUG: unable to handle kernel NULL pointer dereference at 0018 Dec 29 03:46:15 vdr1 kernel: [21406.782876] IP: [] crystalhd_dioq_fetch_wait+0x19c/0x330 [crystalhd] Dec 29 03:46:15 vdr1 kernel: [21406.783173] *pdpt = 2f95e001 *pde = Dec 29 03:46:15 vdr1 kernel: [21406.783173] Oops: [#1] PREEMPT Dec 29 03:46:15 vdr1 kernel: [21406.783173] Modules linked in: md5 crypto_hash cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative bnep bluetooth crc16 binfmt_misc uinput fuse nfsd exportfs auth_rpcgss nfs_acl nfs lockd sunrpc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_limit iptable_filter ip_tables af_packet ipv6 w83627ehf hwmon_vid hwmon isl6405 uvcvideo dvb_pll tda10086 saa7134_dvb videobuf_dvb tuner tda10021 cryptomgr aead arc4 crypto_blkcipher crypto_algapi snd_usb_audio stv0297 snd_usbmidi_lib snd_intel8x0 snd_ac97_codec ac97_bus rt73usb rt2x00usb rt2x00lib snd_hwdep snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi snd_pcm_oss snd_mixer_oss joydev snd_pcm snd_rawmidi saa7134 hid_sunplus hid_generic snd_seq_midi_event videobuf2_vmalloc videobuf2_memops budget_av videobuf2_core cfg80211 usbhid hid snd_page_alloc snd_seq dvb_ttpci saa7146_vv budget_core crc_itu_t ttpci_eeprom crypto saa7146 dvb_core tveeprom videobu Dec 29 03:46:15 vdr1 kernel: f_dma_sg videobuf_core v4l2_common snd_seq_device snd_timer crystalhd(O) videodev snd rc_core shpchp i2c_i801 pci_hotplug serio_raw pcspkr rng_core soundcore 8250_pnp 8250 serial_core acpi_cpufreq mperf processor evdev ext3 mbcache jbd sg sr_mod sd_mod cdrom crc_t10dif ata_piix ahci libahci libata scsi_mod uhci_hcd ehci_hcd usbcore Dec 29 03:46:15 vdr1 kernel: [21406.7
Re: [PATCH/RFC 4/4] common: dma-mapping: Move dma_common_*() to
Em Fri, 28 Dec 2012 20:23:34 +0100
Geert Uytterhoeven escreveu:
> dma_common_mmap() and dma_common_get_sgtable() are defined in
> drivers/base/dma-mapping.c, and always compiled if CONFIG_HAS_DMA=y.
>
> However, their forward declarations and the inline functions defined on top
> of them (dma_mmap_attrs(), dma_mmap_coherent(), dma_mmap_writecombine(),
> dma_get_sgtable_attrs()), dma_get_sgtable()) are in
> , which is not included by all
> architectures supporting CONFIG_HAS_DMA=y. There exist no alternative
> implementations.
>
> Hence for e.g. m68k allmodconfig, I get:
>
> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
> drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit
> declaration of function ‘dma_mmap_coherent’
> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function
> ‘vb2_dc_get_base_sgt’:
> drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit
> declaration of function ‘dma_get_sgtable’
>
> To fix this
> - Move the forward declarations and inline definitions to
> , so all CONFIG_HAS_DMA=y architectures can use
> them,
> - Replace the hard "BUG_ON(!ops)" checks for dma_map_ops by soft checks,
> so architectures can fall back to the common code by returning NULL
> from their get_dma_ops(). Note that there are no "BUG_ON(!ops)" checks
> in other functions in ,
> - Make "struct dma_map_ops *ops" const while we're at it.
>
> Signed-off-by: Geert Uytterhoeven
>From my side:
Acked-by: Mauro Carvalho Chehab
> ---
> include/asm-generic/dma-mapping-common.h | 55
> --
> include/linux/dma-mapping.h | 54 +
> 2 files changed, 54 insertions(+), 55 deletions(-)
>
> diff --git a/include/asm-generic/dma-mapping-common.h
> b/include/asm-generic/dma-mapping-common.h
> index de8bf89..2e248d8 100644
> --- a/include/asm-generic/dma-mapping-common.h
> +++ b/include/asm-generic/dma-mapping-common.h
> @@ -176,59 +176,4 @@ dma_sync_sg_for_device(struct device *dev, struct
> scatterlist *sg,
> #define dma_map_sg(d, s, n, r) dma_map_sg_attrs(d, s, n, r, NULL)
> #define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, NULL)
>
> -extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> -void *cpu_addr, dma_addr_t dma_addr, size_t size);
> -
> -/**
> - * dma_mmap_attrs - map a coherent DMA allocation into user space
> - * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
> - * @vma: vm_area_struct describing requested user mapping
> - * @cpu_addr: kernel CPU-view address returned from dma_alloc_attrs
> - * @handle: device-view address returned from dma_alloc_attrs
> - * @size: size of memory originally requested in dma_alloc_attrs
> - * @attrs: attributes of mapping properties requested in dma_alloc_attrs
> - *
> - * Map a coherent DMA buffer previously allocated by dma_alloc_attrs
> - * into user space. The coherent DMA buffer must not be freed by the
> - * driver until the user space mapping has been released.
> - */
> -static inline int
> -dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma, void
> *cpu_addr,
> -dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs)
> -{
> - struct dma_map_ops *ops = get_dma_ops(dev);
> - BUG_ON(!ops);
> - if (ops->mmap)
> - return ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
> - return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
> -}
> -
> -#define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL)
> -
> -static inline int dma_mmap_writecombine(struct device *dev, struct
> vm_area_struct *vma,
> - void *cpu_addr, dma_addr_t dma_addr, size_t size)
> -{
> - DEFINE_DMA_ATTRS(attrs);
> - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
> - return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs);
> -}
> -
> -int
> -dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
> -void *cpu_addr, dma_addr_t dma_addr, size_t size);
> -
> -static inline int
> -dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt, void
> *cpu_addr,
> - dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs)
> -{
> - struct dma_map_ops *ops = get_dma_ops(dev);
> - BUG_ON(!ops);
> - if (ops->get_sgtable)
> - return ops->get_sgtable(dev, sgt, cpu_addr, dma_addr, size,
> - attrs);
> - return dma_common_get_sgtable(dev, sgt, cpu_addr, dma_addr, size);
> -}
> -
> -#define dma_get_sgtable(d, t, v, h, s) dma_get_sgtable_attrs(d, t, v, h, s,
> NULL)
> -
> #endif
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 94af418..4b47150 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -74,6 +74,60 @@ static inline int is_device_dma_capable(struct device *dev)
>
>
Re: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
Em Fri, 28 Dec 2012 14:52:24 -0500 Devin Heitmueller escreveu: > Hi there, > > So I noticed that one of the "V4L2 ambiguities" discussed at the Media > Workshop relates to expected behavior with TRY_FMT/S_FMT. > Specifically (from > http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab): > > === > 1.4. Unsupported formats in TRY_FMT/S_FMT > > What should a driver return in TRY_FMT/S_FMT if the requested format > is not supported (possible behaviors include returning the currently > selected format or a default format). > The spec says this: "Drivers should not return an error code unless > the input is ambiguous", but it does not explain what constitutes an > ambiguous input. In my opinion TRY/S_FMT should never return an error > other than EINVAL (if the buffer type is unsupported) or EBUSY (for > S_FMT if streaming is in progress). > Should we make a recommendation whether the currently selected format > or a default format should be returned? > One proposal is to just return a default format if the requested > pixelformat is unsupported. Returning the currently selected format > leads to inconsistent results. > Results: > TRY_FMT/S_FMT should never return an error when the requested format > is not supported. Drivers should always return a valid format, > preferably a format that is as widely supported by applications as > possible. > Both TRY_FMT and S_FMT should have the same behaviour. Drivers should > not return different formats when getting the same input parameters. > The format returned should be a driver default format if possible > (stateless behaviour) but can be stateful if needed. > The API spec should let clear that format retuns may be different when > different video inputs (or outputs) are selected. > === > > Note that this will cause ABI breakage with existing applications. If > an application expects an error condition to become aware that the > requested format was not supported, that application will silently > think the requested format was valid but in fact the driver is > returning data in some other format. > > Tvtime (one of the more popular apps for watching analog television) > is one such application that will broken. > > http://git.linuxtv.org/tvtime.git/blob/HEAD:/src/videoinput.c#l452 > > If YUVY isn't supported but UYVY is (for example, with the Hauppauge > HVR-950q), the application will think it's doing YUYV when in fact the > driver is returning UYVY. > > MythTV is a little better (it does ultimately store the format > returned by the driver), however even there it depends on an error > being returned in order to know to do userland format conversion. > > https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/NuppelVideoRecorder.cpp#L1367 > > Now it would be quite simple to change tvtime to use the expected > behavior, but if backward compatibility with the ABI is of paramount > importance, then we cannot proceed with this change as proposed. > Don't misunderstand me - if I were inventing the API today then the > proposed approach is what I would recommend - but since these parts of > the ABI are something like ten years old, we have to take into account > legacy applications. Thanks for pointing it! (c/c Hans, as he started those discussions) Well, if applications will break with this change, then we need to revisit the question, and decide otherwise, as it shouldn't break userspace. It should be noticed, however, that currently, some drivers won't return errors when S_FMT/TRY_FMT requests invalid parameters. So, IMHO, what should be done is: 1) to not break userspace; 2) userspace apps should be improved to handle those drivers that have a potential of breaking them; 3) clearly state at the API, and enforce via compliance tool, that all drivers will behave the same. > > Discussion is welcome. > > Devin Regards, Mauro -- 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: [GIT PULL FOR v3.9] separate Montage ts2020 from ds3000 and rs2000, support for new TeVii cards
Em Sat, 29 Dec 2012 01:06:29 +0300 "Igor M. Liplianin" escreveu: > On 27 декабрÑ_ 2012 19:33:38 Mauro Carvalho Chehab wrote: > > Hi Igor, > Hi Mauro, > > > > > Em Mon, 24 Dec 2012 11:23:56 +0300 > > > > "Igor M. Liplianin" escreveu: > > > The following changes since commit > > > 8b2aea7878f64814544d0527c659011949d52358: > > > [media] em28xx: prefer bulk mode on webcams (2012-12-23 17:24:30 -0200) > > > > > > are available in the git repository at: > > > git://git.linuxtv.org/liplianin/media_tree.git ts2020_v3.9 > > > > > > for you to fetch changes up to 2ff52e6f487c2ee841f3df9709d1b4e4416a1b15: > > > ts2020: separate from m88rs2000 (2012-12-24 01:26:12 +0300) > > > > > > > > > > > > Igor M. Liplianin (4): > > > Tevii S421 and S632 support > > > > > > > > > m88rs2000: SNR BER implemented > > > ds3000: lock led procedure added > > > ts2020: separate from m88rs2000 > > > > You forgot to add your SOB and patch descriptions on the above > > patches. > Actually, I made it two months ago, enough to forget. Yeah, there were too many things happening on the 4th quarter, with delayed patch push. Also, janitors requested us to not apply patches after -rc7. The better is to submit your work before -rc5, in order to give enough time for review. > So, I will add SOB, description and resend. Applied, thanks. Regards, Mauro -- 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: [ANNOUNCE] complete notes of the San Diego's workshop
Em Fri, 28 Dec 2012 12:04:33 -0800 VDR User escreveu: > On Fri, Dec 28, 2012 at 10:57 AM, Mauro Carvalho Chehab > wrote: > > This year was crazy... too much stuff on the 4Q. Only today I found some > > time to merge all notes we took from the San Diego's summit, convert them > > into html and publish. > > > > They're all available at: > > http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab > > > > If you find anything wrong there, please ping me. > > It's missing the long-awaited standardized signal infos. ;) That was not discussed there, sorry. I noticed that the patch that the RFC patch with the last proposal vanished (I likely dropped it from the queue, as nobody reviewed). So, I rebased it, at: http://patchwork.linuxtv.org/patch/16026/ Comments are welcome. Regards, Mauro -- 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 RFCv3] dvb: Add DVBv5 properties for quality parameters
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab
---
include/uapi/linux/dvb/frontend.h | 78 ++-
1 file changed, 77 insertions(+), 1 deletion(-)
v3: Just update http://patchwork.linuxtv.org/patch/9578/ to current tip
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c12d452..a998b9a 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,21 @@ struct dvb_frontend_event {
#define DTV_INTERLEAVING 60
#define DTV_LNA61
-#define DTV_MAX_COMMANDDTV_LNA
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 45 /* Enumerates supported QoS parameters
*/
+#define DTV_QUALITY_SNR46
+#define DTV_QUALITY_CNR47
+#define DTV_QUALITY_EsNo 48
+#define DTV_QUALITY_EbNo 49
+#define DTV_QUALITY_RELATIVE 50
+#define DTV_ERROR_BER 51
+#define DTV_ERROR_PER 52
+#define DTV_ERROR_PARAMS 53 /* Error count at TMCC or TPS carrier */
+#define DTV_FE_STRENGTH54
+#define DTV_FE_SIGNAL 55
+#define DTV_FE_UNC 56
+
+#define DTV_MAX_COMMANDDTV_FE_UNC
typedef enum fe_pilot {
PILOT_ON,
@@ -452,12 +466,74 @@ struct dtv_cmds_h {
__u32 reserved:30;/* Align */
};
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_DECIBEL: The scale is measured in dB, typically
+ * used on signal measures.
+ * @FE_SCALE_LINEAR: The scale is linear.
+ * typically used on error QoS parameters.
+ * @FE_SCALE_RELATIVE: The scale is relative.
+ */
+enum fecap_scale_params {
+ FE_SCALE_DECIBEL,
+ FE_SCALE_LINEAR,
+ FE_SCALE_RELATIVE
+};
+
+/**
+ * struct dtv_status - Used for reading a DTV status property
+ *
+ * @value: value of the measure. Should range from 0 to 0x;
+ * @scale: Filled with enum fecap_scale_params - the scale
+ * in usage for that parameter
+ * @min: minimum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0.
+ * @max: maximum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0x.
+ *
+ * At userspace, min/max values should be used to calculate the
+ * absolute value of that measure, if fecap_scale_params is not
+ * FE_SCALE_RELATIVE, using the following formula:
+ * measure = min + (value * (max - min) / 0x)
+ *
+ * For error count measures, typically, min = 0, and max = 0x,
+ * and the measure represent the number of errors detected.
+ *
+ * Up to 4 status groups can be provided. This is for the
+ * OFDM standards where the carriers can be grouped into
+ * independent layers, each with its own modulation. When
+ * such layers are used (for example, on ISDB-T), the status
+ * should be filled with:
+ * stat.status[0] = global statistics;
+ * stat.status[1] = layer A statistics;
+ * stat.status[2] = layer B statistics;
+ * stat.status[3] = layer C statistics.
+ * and stat.len should be filled with the latest filled status + 1.
+ * If the frontend doesn't provide a global statistics,
+ * stat.has_global should be 0.
+ * Delivery systems that don't use it, should just set stat.len and
+ * stat.has_global with 1, and fill just stat.status[0].
+ */
+struct dtv_status {
+ __u16 value;
+ __u16 scale;
+ __s16 min;
+ __s16 max;
+} __attribute__ ((packed));
+
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
+ __u8 len;
+ __u8 has_global;
+ struct dtv_status status[4];
+ } stat;
[PATCH RFCv3] [media] dvb: Add DVBv5 properties for quality parameters
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab
---
include/uapi/linux/dvb/frontend.h | 78 ++-
1 file changed, 77 insertions(+), 1 deletion(-)
v3: just a rebase of:
http://patchwork.linuxtv.org/patch/9578/
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c12d452..a998b9a 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,21 @@ struct dvb_frontend_event {
#define DTV_INTERLEAVING 60
#define DTV_LNA61
-#define DTV_MAX_COMMANDDTV_LNA
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 45 /* Enumerates supported QoS parameters
*/
+#define DTV_QUALITY_SNR46
+#define DTV_QUALITY_CNR47
+#define DTV_QUALITY_EsNo 48
+#define DTV_QUALITY_EbNo 49
+#define DTV_QUALITY_RELATIVE 50
+#define DTV_ERROR_BER 51
+#define DTV_ERROR_PER 52
+#define DTV_ERROR_PARAMS 53 /* Error count at TMCC or TPS carrier */
+#define DTV_FE_STRENGTH54
+#define DTV_FE_SIGNAL 55
+#define DTV_FE_UNC 56
+
+#define DTV_MAX_COMMANDDTV_FE_UNC
typedef enum fe_pilot {
PILOT_ON,
@@ -452,12 +466,74 @@ struct dtv_cmds_h {
__u32 reserved:30;/* Align */
};
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_DECIBEL: The scale is measured in dB, typically
+ * used on signal measures.
+ * @FE_SCALE_LINEAR: The scale is linear.
+ * typically used on error QoS parameters.
+ * @FE_SCALE_RELATIVE: The scale is relative.
+ */
+enum fecap_scale_params {
+ FE_SCALE_DECIBEL,
+ FE_SCALE_LINEAR,
+ FE_SCALE_RELATIVE
+};
+
+/**
+ * struct dtv_status - Used for reading a DTV status property
+ *
+ * @value: value of the measure. Should range from 0 to 0x;
+ * @scale: Filled with enum fecap_scale_params - the scale
+ * in usage for that parameter
+ * @min: minimum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0.
+ * @max: maximum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0x.
+ *
+ * At userspace, min/max values should be used to calculate the
+ * absolute value of that measure, if fecap_scale_params is not
+ * FE_SCALE_RELATIVE, using the following formula:
+ * measure = min + (value * (max - min) / 0x)
+ *
+ * For error count measures, typically, min = 0, and max = 0x,
+ * and the measure represent the number of errors detected.
+ *
+ * Up to 4 status groups can be provided. This is for the
+ * OFDM standards where the carriers can be grouped into
+ * independent layers, each with its own modulation. When
+ * such layers are used (for example, on ISDB-T), the status
+ * should be filled with:
+ * stat.status[0] = global statistics;
+ * stat.status[1] = layer A statistics;
+ * stat.status[2] = layer B statistics;
+ * stat.status[3] = layer C statistics.
+ * and stat.len should be filled with the latest filled status + 1.
+ * If the frontend doesn't provide a global statistics,
+ * stat.has_global should be 0.
+ * Delivery systems that don't use it, should just set stat.len and
+ * stat.has_global with 1, and fill just stat.status[0].
+ */
+struct dtv_status {
+ __u16 value;
+ __u16 scale;
+ __s16 min;
+ __s16 max;
+} __attribute__ ((packed));
+
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
+ __u8 len;
+ __u8 has_global;
+ struct dtv_status status[4];
+ } stat;
+
[RFC PATCH] [media] dvb: frontend API: Add a flag to indicate that get_frontend() can be called
get_frontend() can't be called too early, as the device may not have it
yet. Yet, get_frontend() on OFDM standards can happen before FE_HAS_LOCK,
as the TMCC carriers (ISDB-T) or the TPS carriers (DVB-T) require a very
low signal to noise relation to be detected. The other carriers use
different modulations, so they require a higher SNR.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/media/dvb/frontend.xml | 13 -
drivers/media/dvb-frontends/mb86a20s.c | 17 ++---
include/uapi/linux/dvb/frontend.h| 4
3 files changed, 26 insertions(+), 8 deletions(-)
v3: rebase it to apply with current tip and add an implementation example.
Obsoletes: http://patchwork.linuxtv.org/patch/13783/
diff --git a/Documentation/DocBook/media/dvb/frontend.xml
b/Documentation/DocBook/media/dvb/frontend.xml
index 426c252..5feff4e 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -216,6 +216,7 @@ typedef enum fe_status {
FE_HAS_LOCK = 0x10,
FE_TIMEDOUT = 0x20,
FE_REINIT = 0x40,
+ FE_HAS_PARAMETERS = 0x80,
} fe_status_t;
to indicate the current state and/or state changes of the frontend
hardware:
@@ -244,7 +245,17 @@ typedef enum fe_status {
FE_REINIT
The frontend was reinitialized, application is
recommended to reset DiSEqC, tone and parameters
-
+
+FE_HAS_PARAMETERS
+
+FE_GET_PROPERTY/FE_SET_PROPERTY or
+FE_GET_FRONTEND
can now be
+called to provide the detected network parameters.
+This should be risen for example when the DVB-T TPS/ISDB-T TMCC is locked.
+This status can be risen before FE_HAS_SYNC, as the SNR required for
+parameters detection is lower than the requirement for the other
+carriers on the OFDM delivery systems.
+
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index fade566..35153b6 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -333,19 +333,22 @@ static int mb86a20s_read_status(struct dvb_frontend *fe,
fe_status_t *status)
fe->ops.i2c_gate_ctrl(fe, 1);
if (val >= 2)
- *status |= FE_HAS_SIGNAL;
+ *status |= FE_HAS_SIGNAL; /* Tuner locked */
if (val >= 4)
- *status |= FE_HAS_CARRIER;
+ *status |= FE_HAS_CARRIER; /* Mode reliably detected */
- if (val >= 5)
- *status |= FE_HAS_VITERBI;
+ if (val >= 6)
+ *status |= FE_HAS_VITERBI; /* PLL locked and broadband
detected */
if (val >= 7)
- *status |= FE_HAS_SYNC;
+ *status |= FE_HAS_SYNC; /* Frame sync */
- if (val >= 8) /* Maybe 9? */
- *status |= FE_HAS_LOCK;
+ if (val >= 8)
+ *status |= FE_HAS_PARAMETERS; /* TMCC locked */
+
+ if (val >= 9)
+ *status |= FE_HAS_LOCK; /* TS output started */
dprintk("val = %d, status = 0x%02x\n", val, *status);
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c12d452..e4daeee 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -132,6 +132,9 @@ typedef enum fe_sec_mini_cmd {
* @FE_TIMEDOUT: no lock within the last ~2 seconds
* @FE_REINIT: frontend was reinitialized, application is recommended
* to reset DiSEqC, tone and parameters
+ * @FE_HAS_PARAMETERS: get_frontend() can now be called to provide the
+ * detected network parameters. This should be risen
+ * for example when the DVB-T TPS/ISDB-T TMCC is locked.
*/
typedef enum fe_status {
@@ -142,6 +145,7 @@ typedef enum fe_status {
FE_HAS_LOCK = 0x10,
FE_TIMEDOUT = 0x20,
FE_REINIT = 0x40,
+ FE_HAS_PARAMETERS = 0x80,
} fe_status_t;
typedef enum fe_spectral_inversion {
--
1.7.11.7
--
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
[GIT PULL FOR v3.9] the rest for TeVii s421, s632 DVB cards and Montage ds3000, rs2000 demods
The following changes since commit c19bec500168108bf28710fae304523679ffb40f: [media] vivi: Constify structures (2012-12-28 13:32:51 -0200) are available in the git repository at: git://git.linuxtv.org/liplianin/media_tree.git ts2020_1_v3.9 for you to fetch changes up to 3a36fae7540e031a811e6c28cd37c7db4baf142b: m88rs2000: make use ts2020 (2012-12-29 01:40:33 +0300) Igor M. Liplianin (4): Tevii S421 and S632 support, Kconfig part m88rs2000: SNR, BER implemented ds3000: lock led procedure added m88rs2000: make use ts2020 drivers/media/dvb-frontends/ds3000.c| 12 + drivers/media/dvb-frontends/ds3000.h| 2 + drivers/media/dvb-frontends/m88rs2000.c | 412 - drivers/media/dvb-frontends/m88rs2000.h | 6 --- drivers/media/dvb-frontends/ts2020.c| 381 +- drivers/media/dvb-frontends/ts2020.h| 1 + drivers/media/pci/cx23885/cx23885-dvb.c | 1 + drivers/media/pci/cx88/cx88-dvb.c | 1 + drivers/media/pci/dm1105/dm1105.c | 1 + drivers/media/usb/dvb-usb-v2/Kconfig| 1 + drivers/media/usb/dvb-usb-v2/lmedm04.c | 9 +++- drivers/media/usb/dvb-usb/Kconfig | 1 + drivers/media/usb/dvb-usb/dw2102.c | 56 13 files changed, 395 insertions(+), 489 deletions(-) -- 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: Re: [GIT PULL FOR v3.9] separate Montage ts2020 from ds3000 and rs2000, support for new TeVii cards
On 27 декабÑÑ 2012 19:33:38 Mauro Carvalho Chehab wrote: > Hi Igor, Hi Mauro, > > Em Mon, 24 Dec 2012 11:23:56 +0300 > > "Igor M. Liplianin" escreveu: > > The following changes since commit 8b2aea7878f64814544d0527c659011949d52358: > > [media] em28xx: prefer bulk mode on webcams (2012-12-23 17:24:30 -0200) > > > > are available in the git repository at: > > git://git.linuxtv.org/liplianin/media_tree.git ts2020_v3.9 > > > > for you to fetch changes up to 2ff52e6f487c2ee841f3df9709d1b4e4416a1b15: > > ts2020: separate from m88rs2000 (2012-12-24 01:26:12 +0300) > > > > > > > > Igor M. Liplianin (4): > > Tevii S421 and S632 support > > > > > > m88rs2000: SNR BER implemented > > ds3000: lock led procedure added > > ts2020: separate from m88rs2000 > > You forgot to add your SOB and patch descriptions on the above > patches. Actually, I made it two months ago, enough to forget. So, I will add SOB, description and resend. > > > Konstantin Dimitrov (3): > > ds3000: remove ts2020 tuner related code > > ts2020: add ts2020 tuner driver > > make the other drivers take use of the new ts2020 driver > > Those now looks correct. So, I'm applying them. > > Regards, > Mauro Regards, Igor -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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
cron job: media_tree daily build: ERRORS
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:Fri Dec 28 19:00:17 CET 2012 git hash:c19bec500168108bf28710fae304523679ffb40f gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: WARNINGS linux-3.8-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: WARNINGS linux-3.8-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification 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: [ANNOUNCE] complete notes of the San Diego's workshop
On Fri, Dec 28, 2012 at 10:57 AM, Mauro Carvalho Chehab wrote: > This year was crazy... too much stuff on the 4Q. Only today I found some > time to merge all notes we took from the San Diego's summit, convert them > into html and publish. > > They're all available at: > http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab > > If you find anything wrong there, please ping me. It's missing the long-awaited standardized signal infos. ;) -- 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
ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation
Hi there, So I noticed that one of the "V4L2 ambiguities" discussed at the Media Workshop relates to expected behavior with TRY_FMT/S_FMT. Specifically (from http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab): === 1.4. Unsupported formats in TRY_FMT/S_FMT What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviors include returning the currently selected format or a default format). The spec says this: "Drivers should not return an error code unless the input is ambiguous", but it does not explain what constitutes an ambiguous input. In my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Should we make a recommendation whether the currently selected format or a default format should be returned? One proposal is to just return a default format if the requested pixelformat is unsupported. Returning the currently selected format leads to inconsistent results. Results: TRY_FMT/S_FMT should never return an error when the requested format is not supported. Drivers should always return a valid format, preferably a format that is as widely supported by applications as possible. Both TRY_FMT and S_FMT should have the same behaviour. Drivers should not return different formats when getting the same input parameters. The format returned should be a driver default format if possible (stateless behaviour) but can be stateful if needed. The API spec should let clear that format retuns may be different when different video inputs (or outputs) are selected. === Note that this will cause ABI breakage with existing applications. If an application expects an error condition to become aware that the requested format was not supported, that application will silently think the requested format was valid but in fact the driver is returning data in some other format. Tvtime (one of the more popular apps for watching analog television) is one such application that will broken. http://git.linuxtv.org/tvtime.git/blob/HEAD:/src/videoinput.c#l452 If YUVY isn't supported but UYVY is (for example, with the Hauppauge HVR-950q), the application will think it's doing YUYV when in fact the driver is returning UYVY. MythTV is a little better (it does ultimately store the format returned by the driver), however even there it depends on an error being returned in order to know to do userland format conversion. https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/NuppelVideoRecorder.cpp#L1367 Now it would be quite simple to change tvtime to use the expected behavior, but if backward compatibility with the ABI is of paramount importance, then we cannot proceed with this change as proposed. Don't misunderstand me - if I were inventing the API today then the proposed approach is what I would recommend - but since these parts of the ABI are something like ten years old, we have to take into account legacy applications. Discussion is welcome. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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/RFC 0/4] Re: dma_mmap_coherent / ARCH_HAS_DMA_MMAP_COHERENT
On Sun, Dec 16, 2012 at 5:03 PM, Geert Uytterhoeven
wrote:
> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
> drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit
> declaration of function ‘dma_mmap_coherent’
> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function
> ‘vb2_dc_get_base_sgt’:
> drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit
> declaration of function ‘dma_get_sgtable’
> make[6]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1
> make[6]: Target `__build' not remade because of errors.
> make[5]: *** [drivers/media/v4l2-core] Error 2
>
> Both dma_mmap_coherent() and dma_get_sgtable() are defined in
> include/asm-generic/dma-mapping-common.h only, which is included by
> on alpha, arm, arm64, hexagon, ia64, microblaze, mips,
> openrisc, powerpc, s390, sh, sparc, tile, unicore32, x86.
> Should the remaining architectures include this, too?
> Should it be moved to ?
I came up with an RFC-solution for this in [PATCH/RFC 3/4]
("avr32/bfin/c6x/cris/frv/m68k/mn10300/parisc/xtensa: Add dummy get_dma_ops()")
and [PATCH/RFC 4/4] ("common: dma-mapping: Move dma_common_*() to
") of this series.
> Furthermore, there's ARCH_HAS_DMA_MMAP_COHERENT, which is defined
> by powerpc only:
> arch/powerpc/include/asm/dma-mapping.h:#define ARCH_HAS_DMA_MMAP_COHERENT
>
> and handled in some fishy way in sound/core/pcm_native.c:
>
> #ifndef ARCH_HAS_DMA_MMAP_COHERENT
> /* This should be defined / handled globally! */
> #ifdef CONFIG_ARM
> #define ARCH_HAS_DMA_MMAP_COHERENT
> #endif
> #endif
>
> /*
> * mmap the DMA buffer on RAM
> */
> int snd_pcm_lib_default_mmap(struct snd_pcm_substream *substream,
> struct vm_area_struct *area)
> {
> area->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> #ifdef ARCH_HAS_DMA_MMAP_COHERENT
> if (!substream->ops->page &&
> substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
> return dma_mmap_coherent(substream->dma_buffer.dev.dev,
> area,
> substream->runtime->dma_area,
> substream->runtime->dma_addr,
> area->vm_end - area->vm_start);
> #elif defined(CONFIG_MIPS) && defined(CONFIG_DMA_NONCOHERENT)
> if (substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV &&
> !plat_device_is_coherent(substream->dma_buffer.dev.dev))
> area->vm_page_prot = pgprot_noncached(area->vm_page_prot);
> #endif /* ARCH_HAS_DMA_MMAP_COHERENT */
> /* mmap with fault handler */
> area->vm_ops = &snd_pcm_vm_ops_data_fault;
> return 0;
> }
> EXPORT_SYMBOL_GPL(snd_pcm_lib_default_mmap);
>
> What's up here?
Probably an easy solution here is to kill ARCH_HAS_DMA_MMAP_COHERENT and
change the code to
#if defined(CONFIG_MIPS) && defined(CONFIG_DMA_NONCOHERENT)
if (substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV &&
!plat_device_is_coherent(substream->dma_buffer.dev.dev))
area->vm_page_prot = pgprot_noncached(area->vm_page_prot);
#else
if (!substream->ops->page &&
substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
return dma_mmap_coherent(substream->dma_buffer.dev.dev,
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
area->vm_end - area->vm_start);
#endif
but obviously I don't like the test for CONFIG_MIPS in generic code...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 1/4] m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA
In two places, we check !CONFIG_MMU_SUN3 while we should check
CONFIG_HAS_DMA instead.
While fixing this, the check in became redundant
( already handles this case), so just remove it.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/include/asm/dma-mapping.h |5 -
arch/m68k/kernel/Makefile |4 +---
2 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/m68k/include/asm/dma-mapping.h
b/arch/m68k/include/asm/dma-mapping.h
index 3e6b844..c68cdb4 100644
--- a/arch/m68k/include/asm/dma-mapping.h
+++ b/arch/m68k/include/asm/dma-mapping.h
@@ -5,7 +5,6 @@
struct scatterlist;
-#ifndef CONFIG_MMU_SUN3
static inline int dma_supported(struct device *dev, u64 mask)
{
return 1;
@@ -111,8 +110,4 @@ static inline int dma_mapping_error(struct device *dev,
dma_addr_t handle)
return 0;
}
-#else
-#include
-#endif
-
#endif /* _M68K_DMA_MAPPING_H */
diff --git a/arch/m68k/kernel/Makefile b/arch/m68k/kernel/Makefile
index 068ad49..655347d 100644
--- a/arch/m68k/kernel/Makefile
+++ b/arch/m68k/kernel/Makefile
@@ -20,7 +20,5 @@ obj-$(CONFIG_MMU_MOTOROLA) += ints.o vectors.o
obj-$(CONFIG_MMU_SUN3) += ints.o vectors.o
obj-$(CONFIG_PCI) += pcibios.o
-ifndef CONFIG_MMU_SUN3
-obj-y += dma.o
-endif
+obj-$(CONFIG_HAS_DMA) += dma.o
--
1.7.0.4
--
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/RFC 4/4] common: dma-mapping: Move dma_common_*() to
dma_common_mmap() and dma_common_get_sgtable() are defined in
drivers/base/dma-mapping.c, and always compiled if CONFIG_HAS_DMA=y.
However, their forward declarations and the inline functions defined on top
of them (dma_mmap_attrs(), dma_mmap_coherent(), dma_mmap_writecombine(),
dma_get_sgtable_attrs()), dma_get_sgtable()) are in
, which is not included by all
architectures supporting CONFIG_HAS_DMA=y. There exist no alternative
implementations.
Hence for e.g. m68k allmodconfig, I get:
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration
of function ‘dma_mmap_coherent’
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function
‘vb2_dc_get_base_sgt’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration
of function ‘dma_get_sgtable’
To fix this
- Move the forward declarations and inline definitions to
, so all CONFIG_HAS_DMA=y architectures can use
them,
- Replace the hard "BUG_ON(!ops)" checks for dma_map_ops by soft checks,
so architectures can fall back to the common code by returning NULL
from their get_dma_ops(). Note that there are no "BUG_ON(!ops)" checks
in other functions in ,
- Make "struct dma_map_ops *ops" const while we're at it.
Signed-off-by: Geert Uytterhoeven
---
include/asm-generic/dma-mapping-common.h | 55 --
include/linux/dma-mapping.h | 54 +
2 files changed, 54 insertions(+), 55 deletions(-)
diff --git a/include/asm-generic/dma-mapping-common.h
b/include/asm-generic/dma-mapping-common.h
index de8bf89..2e248d8 100644
--- a/include/asm-generic/dma-mapping-common.h
+++ b/include/asm-generic/dma-mapping-common.h
@@ -176,59 +176,4 @@ dma_sync_sg_for_device(struct device *dev, struct
scatterlist *sg,
#define dma_map_sg(d, s, n, r) dma_map_sg_attrs(d, s, n, r, NULL)
#define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, NULL)
-extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size);
-
-/**
- * dma_mmap_attrs - map a coherent DMA allocation into user space
- * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
- * @vma: vm_area_struct describing requested user mapping
- * @cpu_addr: kernel CPU-view address returned from dma_alloc_attrs
- * @handle: device-view address returned from dma_alloc_attrs
- * @size: size of memory originally requested in dma_alloc_attrs
- * @attrs: attributes of mapping properties requested in dma_alloc_attrs
- *
- * Map a coherent DMA buffer previously allocated by dma_alloc_attrs
- * into user space. The coherent DMA buffer must not be freed by the
- * driver until the user space mapping has been released.
- */
-static inline int
-dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma, void *cpu_addr,
- dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
- BUG_ON(!ops);
- if (ops->mmap)
- return ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
- return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
-}
-
-#define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL)
-
-static inline int dma_mmap_writecombine(struct device *dev, struct
vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size)
-{
- DEFINE_DMA_ATTRS(attrs);
- dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
- return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs);
-}
-
-int
-dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
- void *cpu_addr, dma_addr_t dma_addr, size_t size);
-
-static inline int
-dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt, void *cpu_addr,
- dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
- BUG_ON(!ops);
- if (ops->get_sgtable)
- return ops->get_sgtable(dev, sgt, cpu_addr, dma_addr, size,
- attrs);
- return dma_common_get_sgtable(dev, sgt, cpu_addr, dma_addr, size);
-}
-
-#define dma_get_sgtable(d, t, v, h, s) dma_get_sgtable_attrs(d, t, v, h, s,
NULL)
-
#endif
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 94af418..4b47150 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -74,6 +74,60 @@ static inline int is_device_dma_capable(struct device *dev)
#ifdef CONFIG_HAS_DMA
#include
+
+extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size);
+
+/**
+ * dma_mmap_attrs - map a coherent DMA allocation into user space
+ * @dev: valid struct device pointer, or NULL
[PATCH/RFC 3/4] avr32/bfin/c6x/cris/frv/m68k/mn10300/parisc/xtensa: Add dummy get_dma_ops()
Provide dummy versions of get_dma_ops(), as dma_mmap_attrs() and
dma_get_sgtable_attrs() (will) need these
Signed-off-by: Geert Uytterhoeven
---
arch/avr32/include/asm/dma-mapping.h|8
arch/blackfin/include/asm/dma-mapping.h |8
arch/c6x/include/asm/dma-mapping.h |8
arch/cris/include/asm/dma-mapping.h |8
arch/frv/include/asm/dma-mapping.h |8
arch/m68k/include/asm/dma-mapping.h |8
arch/mn10300/include/asm/dma-mapping.h |8
arch/parisc/include/asm/dma-mapping.h |8
arch/xtensa/include/asm/dma-mapping.h |8
9 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/arch/avr32/include/asm/dma-mapping.h
b/arch/avr32/include/asm/dma-mapping.h
index aaf5199..de55309 100644
--- a/arch/avr32/include/asm/dma-mapping.h
+++ b/arch/avr32/include/asm/dma-mapping.h
@@ -8,6 +8,14 @@
#include
#include
+/*
+ * Dummy to make dma_mmap_attrs()/dma_get_sgtable_attrs() happy
+ */
+static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ return NULL;
+}
+
extern void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
int direction);
diff --git a/arch/blackfin/include/asm/dma-mapping.h
b/arch/blackfin/include/asm/dma-mapping.h
index bbf4610..a2778b3 100644
--- a/arch/blackfin/include/asm/dma-mapping.h
+++ b/arch/blackfin/include/asm/dma-mapping.h
@@ -10,6 +10,14 @@
#include
struct scatterlist;
+/*
+ * Dummy to make dma_mmap_attrs()/dma_get_sgtable_attrs() happy
+ */
+static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ return NULL;
+}
+
void *dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp);
void dma_free_coherent(struct device *dev, size_t size, void *vaddr,
diff --git a/arch/c6x/include/asm/dma-mapping.h
b/arch/c6x/include/asm/dma-mapping.h
index 3c69406..5ae2f81 100644
--- a/arch/c6x/include/asm/dma-mapping.h
+++ b/arch/c6x/include/asm/dma-mapping.h
@@ -17,6 +17,14 @@
#define dma_supported(d, m)1
+/*
+ * Dummy to make dma_mmap_attrs()/dma_get_sgtable_attrs() happy
+ */
+static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ return NULL;
+}
+
static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
diff --git a/arch/cris/include/asm/dma-mapping.h
b/arch/cris/include/asm/dma-mapping.h
index 8588b2c..05a55aa 100644
--- a/arch/cris/include/asm/dma-mapping.h
+++ b/arch/cris/include/asm/dma-mapping.h
@@ -10,6 +10,14 @@
#include
#include
+/*
+ * Dummy to make dma_mmap_attrs()/dma_get_sgtable_attrs() happy
+ */
+static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ return NULL;
+}
+
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
diff --git a/arch/frv/include/asm/dma-mapping.h
b/arch/frv/include/asm/dma-mapping.h
index dfb8110..862e9b8 100644
--- a/arch/frv/include/asm/dma-mapping.h
+++ b/arch/frv/include/asm/dma-mapping.h
@@ -12,6 +12,14 @@
* following DMA API should work.
*/
+/*
+ * Dummy to make dma_mmap_attrs()/dma_get_sgtable_attrs() happy
+ */
+static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ return NULL;
+}
+
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
diff --git a/arch/m68k/include/asm/dma-mapping.h
b/arch/m68k/include/asm/dma-mapping.h
index c68cdb4..d8977f5 100644
--- a/arch/m68k/include/asm/dma-mapping.h
+++ b/arch/m68k/include/asm/dma-mapping.h
@@ -5,6 +5,14 @@
struct scatterlist;
+/*
+ * Dummy to make dma_mmap_attrs()/dma_get_sgtable_attrs() happy
+ */
+static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ return NULL;
+}
+
static inline int dma_supported(struct device *dev, u64 mask)
{
return 1;
diff --git a/arch/mn10300/include/asm/dma-mapping.h
b/arch/mn10300/include/asm/dma-mapping.h
index c1be439..b0cea53 100644
--- a/arch/mn10300/include/asm/dma-mapping.h
+++ b/arch/mn10300/include/asm/dma-mapping.h
@@ -22,6 +22,14 @@
* following DMA API should work.
*/
+/*
+ * Dummy to make dma_mmap_attrs()/dma_get_sgtable_attrs() happy
+ */
+static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ return NULL;
+}
+
extern void *dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, int flag);
diff --git a/arch/parisc/include/asm/dma-mapping.h
b/arch/parisc/include/asm/dma-mapping.h
index 467bbd5..cdd450f 100644
--- a/arch/parisc/include/asm/dma-mapping.h
+++ b/arch/parisc/include/asm/dma-mapping.h
@@ -46,6 +46,14 @@ extern struct hppa_dma_ops pcx_dma_ops;
extern struct hppa_dma_ops *hppa_dma_ops;
+
[PATCH 2/4] score: Remove unneeded
It just includes , which is already handled by for the !CONFIG_HAS_DMA case (score sets CONFIG_NO_DMA=y). Signed-off-by: Geert Uytterhoeven Cc: Chen Liqin Cc: Lennox Wu --- arch/score/include/asm/dma-mapping.h |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) delete mode 100644 arch/score/include/asm/dma-mapping.h diff --git a/arch/score/include/asm/dma-mapping.h b/arch/score/include/asm/dma-mapping.h deleted file mode 100644 index f9c0193..000 --- a/arch/score/include/asm/dma-mapping.h +++ /dev/null @@ -1,6 +0,0 @@ -#ifndef _ASM_SCORE_DMA_MAPPING_H -#define _ASM_SCORE_DMA_MAPPING_H - -#include - -#endif /* _ASM_SCORE_DMA_MAPPING_H */ -- 1.7.0.4 -- 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
[ANNOUNCE] complete notes of the San Diego's workshop
This year was crazy... too much stuff on the 4Q. Only today I found some time to merge all notes we took from the San Diego's summit, convert them into html and publish. They're all available at: http://www.linuxtv.org/news.php?entry=2012-12-28.mchehab If you find anything wrong there, please ping me. I intend to also release maybe today or tomorrow the notes from the Barcelona's workshop, and also store the presentations somewhere at our site. Regards, Mauro -- 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] [media] vivi: Constify structures
On Fri December 28 2012 14:12:56 Kirill Smelkov wrote:
> On Thu, Dec 27, 2012 at 12:55:11PM +0100, Hans Verkuil wrote:
> > On Wed December 26 2012 16:29:43 Kirill Smelkov wrote:
> > > Most of *_ops and other structures in vivi.c were already declared const
> > > but some have not. Constify and code/data will take less space:
> > >
> > > $ size drivers/media/platform/vivi.o
> > > textdata bss dec hex filename
> > > before: 12569 248 8 128253219
> > > drivers/media/platform/vivi.o
> > > after: 12308 20 8 123363030
> > > drivers/media/platform/vivi.o
> > >
> > > i.e. vivi.o is now ~500 bytes less.
> > >
> > > Signed-off-by: Kirill Smelkov
> > > ---
> > > drivers/media/platform/vivi.c | 26 +-
> > > 1 file changed, 13 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> > > index ec65089..bed04e1 100644
> > > --- a/drivers/media/platform/vivi.c
> > > +++ b/drivers/media/platform/vivi.c
> > > @@ -91,13 +91,13 @@ static const struct v4l2_fract
> > > --*/
> > >
> > > struct vivi_fmt {
> > > - char *name;
> > > + const char *name;
> >
> > Just use one space before '*' since it no longer lines up to anything.
>
> [...]
> > > @@ -191,7 +191,7 @@ struct vivi_buffer {
> > > /* common v4l buffer stuff -- must be first */
> > > struct vb2_buffer vb;
> > > struct list_headlist;
> > > - struct vivi_fmt*fmt;
> > > + struct vivi_fmt const *fmt;
> > > };
> > >
> > > struct vivi_dmaqueue {
> > > @@ -250,7 +250,7 @@ struct vivi_dev {
> > > intinput;
> > >
> > > /* video capture */
> > > - struct vivi_fmt*fmt;
> > > + struct vivi_fmt const *fmt;
> >
> > 'const' should be before 'struct' for consistency reasons.
>
> It's just a matter of style, and in this case I though putting const
> after would not distract from the fact that fmt is `struct vivi_fmt *`
> and also to align types beginning with non-const ones.
>
> But anyway, style is style and this is not a big deal, so here you are
> with corrected patch.
Acked-by: Hans Verkuil
Regards,
Hans
>
> Thanks,
> Kirill
>
> 8<
> From: Kirill Smelkov
> Date: Wed, 26 Dec 2012 19:23:26 +0400
> Subject: [PATCH,v2] [media] vivi: Constify structures
>
> Most of *_ops and other structures in vivi.c were already declared const
> but some have not. Constify and code/data will take less space:
>
> $ size drivers/media/platform/vivi.o
> textdata bss dec hex filename
> before: 12569 248 8 128253219
> drivers/media/platform/vivi.o
> after: 12308 20 8 123363030
> drivers/media/platform/vivi.o
>
> i.e. vivi.o is now ~500 bytes less.
>
> Signed-off-by: Kirill Smelkov
> ---
> drivers/media/platform/vivi.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> v2:
>
> - put 'const' always before anything, as noted by Hans Verkuil.
> - no changes otherwise.
>
>
> diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> index ec65089..8a33a71 100644
> --- a/drivers/media/platform/vivi.c
> +++ b/drivers/media/platform/vivi.c
> @@ -91,13 +91,13 @@ static const struct v4l2_fract
> --*/
>
> struct vivi_fmt {
> - char *name;
> + const char *name;
> u32 fourcc; /* v4l2 format id */
> u8depth;
> bool is_yuv;
> };
>
> -static struct vivi_fmt formats[] = {
> +static const struct vivi_fmt formats[] = {
> {
> .name = "4:2:2, packed, YUYV",
> .fourcc = V4L2_PIX_FMT_YUYV,
> @@ -164,9 +164,9 @@ static struct vivi_fmt formats[] = {
> },
> };
>
> -static struct vivi_fmt *__get_format(u32 pixelformat)
> +static const struct vivi_fmt *__get_format(u32 pixelformat)
> {
> - struct vivi_fmt *fmt;
> + const struct vivi_fmt *fmt;
> unsigned int k;
>
> for (k = 0; k < ARRAY_SIZE(formats); k++) {
> @@ -181,7 +181,7 @@ static struct vivi_fmt *__get_format(u32 pixelformat)
> return &formats[k];
> }
>
> -static struct vivi_fmt *get_format(struct v4l2_format *f)
> +static const struct vivi_fmt *get_format(struct v4l2_format *f)
> {
> return __get_format(f->fmt.pix.pixelformat);
> }
> @@ -191,7 +191,7 @@ struct vivi_buffer {
> /* common v4l buffer stuff -- must be first */
> struct vb2_buffer vb;
> struct list_headlist;
> - struct vivi_fmt*fmt;
> + const struct vivi_fmt *fmt;
> };
>
> struct vivi_dmaqueue {
> @@ -250,7 +250,7 @@ struct vivi_dev {
> intinput;
>
> /* video capture */
> - struct vivi_fmt*fmt;
> + con
Re: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
Em Fri, 28 Dec 2012 14:27:56 +0100 (CET) Jiri Kosina escreveu: > On Fri, 28 Dec 2012, Mauro Carvalho Chehab wrote: > > > Hi Jiri, > > > > There's another radio device that it is incorrectly detected as an HID > > driver. > > As I'll be applying the driver's patch via the media tree, do you mind if I > > also > > apply this hid patch there? > > Hi Mauro, > > please feel free to add > > Acked-by: Jiri Kosina > > and take the patch through your tree. Thank you, Jiri! Regards, Mauro -- 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
saa711x doesn't match in easycap devices (stk1160 bridged)
Hi everyone, Some stk1160 users (a lot acually) are reporting that stk1160 is broken. The reports come in the out of tree driver [1], but probably the issue is in mainline too. Now, it seems to me the problem is the saa711x decoder can't get matched, see a portion of dmesg. [89947.448813] usb 1-2.4: New device Syntek Semiconductor USB 2.0 Video Capture Controller @ 480 Mbps (05e1:0408, interface 0, class 0) [89947.448827] usb 1-2.4: video interface 0 found [89948.200366] saa7115 21-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. [89948.200555] stk1160: driver ver 0.9.3 successfully loaded [...] I'm working on this right now, but would like to know, given the ID seems to be NULL, what would be the right thing to do here. Perhaps, replacing the -ENODEV error by a just warning and keep going? Further debugging [2] shows the chip doesn't seem to have a proper chipid (as expected): [ 304.059917] stk1160_i2c_xfer: addr=4a [ 304.084238] OK [ 304.084483] stk1160_i2c_xfer: addr=4a [ 304.084498] subaddr=0 write=0 [ 304.108254] OK [ 304.108276] stk1160_i2c_xfer: addr=4a [ 304.108286] subaddr=0 [ 304.132367] read=10 [ 304.132378] OK [ 304.132394] stk1160_i2c_xfer: addr=4a [ 304.132403] subaddr=0 write=1 [ 304.156269] OK [ 304.156288] stk1160_i2c_xfer: addr=4a [ 304.156297] subaddr=0 [ 304.180490] read=10 [ 304.180500] OK [ 304.180514] stk1160_i2c_xfer: addr=4a [ 304.180523] subaddr=0 write=2 [ 304.204249] OK [ 304.204268] stk1160_i2c_xfer: addr=4a [ 304.204276] subaddr=0 [ 304.228365] read=10 [ 304.228374] OK [ 304.228388] stk1160_i2c_xfer: addr=4a [ 304.228397] subaddr=0 write=3 [ 304.252267] OK [ 304.252286] stk1160_i2c_xfer: addr=4a [ 304.252295] subaddr=0 [ 304.276363] read=10 [ 304.276372] OK [ 304.276386] stk1160_i2c_xfer: addr=4a [ 304.276395] subaddr=0 write=4 [ 304.300248] OK [ 304.300266] stk1160_i2c_xfer: addr=4a [ 304.300275] subaddr=0 [ 304.324363] read=10 [ 304.324373] OK [ 304.324386] stk1160_i2c_xfer: addr=4a [ 304.324394] subaddr=0 write=5 [ 304.348250] OK [ 304.348268] stk1160_i2c_xfer: addr=4a [ 304.348277] subaddr=0 [ 304.372364] read=10 [ 304.372374] OK [ 304.372387] stk1160_i2c_xfer: addr=4a [ 304.372396] subaddr=0 write=6 [ 304.396250] OK [ 304.396266] stk1160_i2c_xfer: addr=4a [ 304.396275] subaddr=0 [ 304.420363] read=10 [ 304.420372] OK [ 304.420386] stk1160_i2c_xfer: addr=4a [ 304.420395] subaddr=0 write=7 [ 304.444253] OK [ 304.444274] stk1160_i2c_xfer: addr=4a [ 304.444283] subaddr=0 [ 304.468364] read=10 [ 304.468374] OK [ 304.468389] stk1160_i2c_xfer: addr=4a [ 304.468398] subaddr=0 write=8 [ 304.492248] OK [ 304.492266] stk1160_i2c_xfer: addr=4a [ 304.492275] subaddr=0 [ 304.516360] read=10 [ 304.516370] OK [ 304.516384] stk1160_i2c_xfer: addr=4a [ 304.516392] subaddr=0 write=9 [ 304.540248] OK [ 304.540278] stk1160_i2c_xfer: addr=4a [ 304.540291] subaddr=0 [ 304.564638] read=10 [ 304.564653] OK [ 304.564675] stk1160_i2c_xfer: addr=4a [ 304.564687] subaddr=0 write=a [ 304.565874] OK [ 304.565895] stk1160_i2c_xfer: addr=4a [ 304.565904] subaddr=0 [ 304.588370] read=10 [ 304.588376] OK [ 304.588386] stk1160_i2c_xfer: addr=4a [ 304.588390] subaddr=0 write=b [ 304.61] OK [ 304.612241] stk1160_i2c_xfer: addr=4a [ 304.612249] subaddr=0 [ 304.636369] read=10 [ 304.636380] OK [ 304.636396] stk1160_i2c_xfer: addr=4a [ 304.636405] subaddr=0 write=c [ 304.660268] OK [ 304.660288] stk1160_i2c_xfer: addr=4a [ 304.660297] subaddr=0 [ 304.684364] read=10 [ 304.684374] OK [ 304.684388] stk1160_i2c_xfer: addr=4a [ 304.684396] subaddr=0 write=d [ 304.708249] OK [ 304.708267] stk1160_i2c_xfer: addr=4a [ 304.708276] subaddr=0 [ 304.732366] read=10 [ 304.732375] OK [ 304.732389] stk1160_i2c_xfer: addr=4a [ 304.732398] subaddr=0 write=e [ 304.756251] OK [ 304.756270] stk1160_i2c_xfer: addr=4a [ 304.756279] subaddr=0 [ 304.780365] read=10 -- Ezequiel [1] https://github.com/ezequielgarcia/stk1160-standalone/issues/14 [2] https://github.com/ezequielgarcia/stk1160-standalone/issues/14#issuecomment-11732376 -- 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 00/03 v2] driver for Masterkit MA901 usb radio
Hi Hans, On Fri, Dec 28, 2012 at 2:24 PM, Hans Verkuil wrote: > On Mon November 12 2012 07:56:06 Alexey Klimov wrote: >> Hi all, >> >> This is second version of small patch series for ma901 usb radio driver. >> Initial letter about this usb radio was sent on October 29 and can be >> found here: http://www.spinics.net/lists/linux-media/msg55779.html >> >> Changes: >> - removed f->type check and set in vidioc_g_frequency() >> - added maintainers entry patch > > For the whole patch series: > > Acked-by: Hans Verkuil > > PS: Sorry for the late reply. The 'Date:' line of these emails was November > 12, but > they were sent on November 27! So my email client sorted them way down in the > list, > out of sight. You might want to check the date in the future... Sorry!.. It looks like i sent them from odroid-x arm board that i use to play with and test usb radio devices that i have. This arm board doesn't have battery to save RTC time and gentoo in current configuration doesn't use NTP to update time from internet. BTW, thanks! -- Best regards, Klimov Alexey -- 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: Fw: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
On Fri, 28 Dec 2012, Mauro Carvalho Chehab wrote: > Hi Jiri, > > There's another radio device that it is incorrectly detected as an HID driver. > As I'll be applying the driver's patch via the media tree, do you mind if I > also > apply this hid patch there? Hi Mauro, please feel free to add Acked-by: Jiri Kosina and take the patch through your tree. Thanks, -- Jiri Kosina SUSE Labs -- 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,v2] [media] vivi: Constify structures
On Thu, Dec 27, 2012 at 12:55:11PM +0100, Hans Verkuil wrote:
> On Wed December 26 2012 16:29:43 Kirill Smelkov wrote:
> > Most of *_ops and other structures in vivi.c were already declared const
> > but some have not. Constify and code/data will take less space:
> >
> > $ size drivers/media/platform/vivi.o
> > textdata bss dec hex filename
> > before: 12569 248 8 128253219
> > drivers/media/platform/vivi.o
> > after: 12308 20 8 123363030
> > drivers/media/platform/vivi.o
> >
> > i.e. vivi.o is now ~500 bytes less.
> >
> > Signed-off-by: Kirill Smelkov
> > ---
> > drivers/media/platform/vivi.c | 26 +-
> > 1 file changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> > index ec65089..bed04e1 100644
> > --- a/drivers/media/platform/vivi.c
> > +++ b/drivers/media/platform/vivi.c
> > @@ -91,13 +91,13 @@ static const struct v4l2_fract
> > --*/
> >
> > struct vivi_fmt {
> > - char *name;
> > + const char *name;
>
> Just use one space before '*' since it no longer lines up to anything.
[...]
> > @@ -191,7 +191,7 @@ struct vivi_buffer {
> > /* common v4l buffer stuff -- must be first */
> > struct vb2_buffer vb;
> > struct list_headlist;
> > - struct vivi_fmt*fmt;
> > + struct vivi_fmt const *fmt;
> > };
> >
> > struct vivi_dmaqueue {
> > @@ -250,7 +250,7 @@ struct vivi_dev {
> > intinput;
> >
> > /* video capture */
> > - struct vivi_fmt*fmt;
> > + struct vivi_fmt const *fmt;
>
> 'const' should be before 'struct' for consistency reasons.
It's just a matter of style, and in this case I though putting const
after would not distract from the fact that fmt is `struct vivi_fmt *`
and also to align types beginning with non-const ones.
But anyway, style is style and this is not a big deal, so here you are
with corrected patch.
Thanks,
Kirill
8<
From: Kirill Smelkov
Date: Wed, 26 Dec 2012 19:23:26 +0400
Subject: [PATCH,v2] [media] vivi: Constify structures
Most of *_ops and other structures in vivi.c were already declared const
but some have not. Constify and code/data will take less space:
$ size drivers/media/platform/vivi.o
textdata bss dec hex filename
before: 12569 248 8 128253219 drivers/media/platform/vivi.o
after: 12308 20 8 123363030 drivers/media/platform/vivi.o
i.e. vivi.o is now ~500 bytes less.
Signed-off-by: Kirill Smelkov
---
drivers/media/platform/vivi.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
v2:
- put 'const' always before anything, as noted by Hans Verkuil.
- no changes otherwise.
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index ec65089..8a33a71 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -91,13 +91,13 @@ static const struct v4l2_fract
--*/
struct vivi_fmt {
- char *name;
+ const char *name;
u32 fourcc; /* v4l2 format id */
u8depth;
bool is_yuv;
};
-static struct vivi_fmt formats[] = {
+static const struct vivi_fmt formats[] = {
{
.name = "4:2:2, packed, YUYV",
.fourcc = V4L2_PIX_FMT_YUYV,
@@ -164,9 +164,9 @@ static struct vivi_fmt formats[] = {
},
};
-static struct vivi_fmt *__get_format(u32 pixelformat)
+static const struct vivi_fmt *__get_format(u32 pixelformat)
{
- struct vivi_fmt *fmt;
+ const struct vivi_fmt *fmt;
unsigned int k;
for (k = 0; k < ARRAY_SIZE(formats); k++) {
@@ -181,7 +181,7 @@ static struct vivi_fmt *__get_format(u32 pixelformat)
return &formats[k];
}
-static struct vivi_fmt *get_format(struct v4l2_format *f)
+static const struct vivi_fmt *get_format(struct v4l2_format *f)
{
return __get_format(f->fmt.pix.pixelformat);
}
@@ -191,7 +191,7 @@ struct vivi_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
struct list_headlist;
- struct vivi_fmt*fmt;
+ const struct vivi_fmt *fmt;
};
struct vivi_dmaqueue {
@@ -250,7 +250,7 @@ struct vivi_dev {
intinput;
/* video capture */
- struct vivi_fmt*fmt;
+ const struct vivi_fmt *fmt;
struct v4l2_fract timeperframe;
unsigned int width, height;
struct vb2_queue vb_vidq;
@@ -297,7 +297,7 @@ struct bar_std {
/* Maximum number of bars are 10 - otherwise, the input print code
should be modified */
-static struct bar_st
Fw: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
Hi Jiri,
There's another radio device that it is incorrectly detected as an HID driver.
As I'll be applying the driver's patch via the media tree, do you mind if I also
apply this hid patch there?
Thanks!
Mauro
Forwarded message:
Date: Mon, 12 Nov 2012 07:57:03 +0100
From: Alexey Klimov
To: linux-media@vger.kernel.org
Subject: [patch 02/03 v2] usb hid quirks for Masterkit MA901 usb radio
Don't let Masterkit MA901 USB radio be handled by usb hid drivers.
This device will be handled by radio-ma901.c driver.
Signed-off-by: Alexey Klimov
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5de3bb3..8e06569 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2025,6 +2025,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HYBRID) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HEATCONTROL) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_BEATPAD)
},
+ { HID_USB_DEVICE(USB_VENDOR_ID_MASTERKIT,
USB_DEVICE_ID_MASTERKIT_MA901RADIO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1024LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1208LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 1dcb76f..17aa4f6 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -533,6 +533,9 @@
#define USB_VENDOR_ID_MADCATZ 0x0738
#define USB_DEVICE_ID_MADCATZ_BEATPAD 0x4540
+#define USB_VENDOR_ID_MASTERKIT0x16c0
+#define USB_DEVICE_ID_MASTERKIT_MA901RADIO 0x05df
+
#define USB_VENDOR_ID_MCC 0x09db
#define USB_DEVICE_ID_MCC_PMD1024LS0x0076
#define USB_DEVICE_ID_MCC_PMD1208LS0x007a
--
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 update notification: 5 patches updated
Em Fri, 28 Dec 2012 10:40:36 +0530 Tushar Behera escreveu: > On 12/26/2012 06:03 PM, Patchwork wrote: > > Hello, > > > > The following patches (submitted by you) have been updated in patchwork: > > > > * [05/14,media] atmel-isi: Update error check for unsigned variables > > - http://patchwork.linuxtv.org/patch/15475/ > > was: New > > now: Under Review > > > > * [01/14,media] ivtv: Remove redundant check on unsigned variable > > - http://patchwork.linuxtv.org/patch/15479/ > > was: New > > now: Under Review > > > > * [04/14,media] tlg2300: Remove redundant check on unsigned variable > > - http://patchwork.linuxtv.org/patch/15476/ > > was: New > > now: Under Review > > > > * [02/14,media] meye: Remove redundant check on unsigned variable > > - http://patchwork.linuxtv.org/patch/15478/ > > was: New > > now: Under Review > > > > * [03/14,media] saa7134: Remove redundant check on unsigned variable > > - http://patchwork.linuxtv.org/patch/15477/ > > was: New > > now: Under Review > > > > This email is a notification only - you do not need to respond. > > > > The above 5 patches may please be marked as "Obsolete" as a similar > patches have already been merged to 3.8-rc1. Thanks for pointing it! That saves us time by not needing to review a patch that it was already superseded. Status updated. Regards, Mauro -- 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 2/2] [media] s5p-fimc: Use spinlock_t instead of 'struct spinlock'
Silences the following checkpatch warning:
WARNING: struct spinlock should be spinlock_t
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-fimc/mipi-csis.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 4c961b1..86c8775 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -187,7 +187,7 @@ struct csis_state {
const struct csis_pix_format *csis_fmt;
struct v4l2_mbus_framefmt format;
- struct spinlock slock;
+ spinlock_t slock;
struct csis_pktbuf pkt_buf;
struct s5pcsis_event events[S5PCSIS_NUM_EVENTS];
};
--
1.7.4.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
[PATCH 1/2] [media] s5p-jpeg: Use spinlock_t instead of 'struct spinlock'
Silences the following checkpatch warning:
WARNING: struct spinlock should be spinlock_t
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-jpeg/jpeg-core.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h
b/drivers/media/platform/s5p-jpeg/jpeg-core.h
index 022b9b9..8a4013e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -62,7 +62,7 @@
*/
struct s5p_jpeg {
struct mutexlock;
- struct spinlock slock;
+ spinlock_t slock;
struct v4l2_device v4l2_dev;
struct video_device *vfd_encoder;
--
1.7.4.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
[PATCH 3/3] [media] s5p-mfc: Use of_match_ptr and CONFIG_OF
This builds the code only if DT is enabled.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3930177..65ed603 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1405,6 +1405,7 @@ static struct platform_device_id mfc_driver_ids[] = {
};
MODULE_DEVICE_TABLE(platform, mfc_driver_ids);
+#ifdef CONFIG_OF
static const struct of_device_id exynos_mfc_match[] = {
{
.compatible = "samsung,mfc-v5",
@@ -1416,6 +1417,7 @@ static const struct of_device_id exynos_mfc_match[] = {
{},
};
MODULE_DEVICE_TABLE(of, exynos_mfc_match);
+#endif
static void *mfc_get_drv_data(struct platform_device *pdev)
{
@@ -1442,7 +1444,7 @@ static struct platform_driver s5p_mfc_driver = {
.name = S5P_MFC_NAME,
.owner = THIS_MODULE,
.pm = &s5p_mfc_pm_ops,
- .of_match_table = exynos_mfc_match,
+ .of_match_table = of_match_ptr(exynos_mfc_match),
},
};
--
1.7.4.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
[PATCH 2/3] [media] s5p-mfc: Remove redundant 'break'
The code returns before this statement. Hence not required.
Silences the following smatch message:
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c:525
s5p_mfc_set_dec_frame_buffer_v5() info: ignoring unreachable code.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index bb99d3d..b0f277e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -522,7 +522,6 @@ int s5p_mfc_set_dec_frame_buffer_v5(struct s5p_mfc_ctx *ctx)
mfc_err("Unknown codec for decoding (%x)\n",
ctx->codec_mode);
return -EINVAL;
- break;
}
frame_size = ctx->luma_size;
frame_size_ch = ctx->chroma_size;
--
1.7.4.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
[PATCH 1/3] [media] s5p-mfc: use mfc_err instead of printk
Use mfc_err for consistency. Also silences checkpatch warning.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index bf7d010..bb99d3d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -187,8 +187,7 @@ int s5p_mfc_alloc_codec_buffers_v5(struct s5p_mfc_ctx *ctx)
dev->alloc_ctx[MFC_BANK1_ALLOC_CTX], ctx->bank1_size);
if (IS_ERR(ctx->bank1_buf)) {
ctx->bank1_buf = NULL;
- printk(KERN_ERR
- "Buf alloc for decoding failed (port A)\n");
+ mfc_err("Buf alloc for decoding failed (port A)\n");
return -ENOMEM;
}
ctx->bank1_phys = s5p_mfc_mem_cookie(
--
1.7.4.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
Re: [patch 00/03 v2] driver for Masterkit MA901 usb radio
On Mon November 12 2012 07:56:06 Alexey Klimov wrote: > Hi all, > > This is second version of small patch series for ma901 usb radio driver. > Initial letter about this usb radio was sent on October 29 and can be > found here: http://www.spinics.net/lists/linux-media/msg55779.html > > Changes: > - removed f->type check and set in vidioc_g_frequency() > - added maintainers entry patch For the whole patch series: Acked-by: Hans Verkuil PS: Sorry for the late reply. The 'Date:' line of these emails was November 12, but they were sent on November 27! So my email client sorted them way down in the list, out of sight. You might want to check the date in the future... -- 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
