Re: [PATCH v2 1/4] b2c2: Add option to skip the first 6 pid filters
On 05/30/2015 09:10 PM, Jemma Denson wrote: The flexcop bridge chip has two banks of hardware pid filters - an initial 6, and on some chip revisions an additional bank of 32. A bug is present on the initial 6 - when changing transponders one of two PAT packets from the old transponder would be included in the initial packets from the new transponder. This usually transpired with userspace programs complaining about services missing, because they are seeing a PAT that they would not be expecting. Running in full TS mode does not exhibit this problem, neither does using just the additional 32. This patch adds in an option to not use the inital 6 and solely use just the additional 32, and enables this option for the SkystarS2 card. Other cards can be added as required if they also have this bug. Why not to use strategy where 32 pid filter is used as a priority and that buggy 6 pid filter is used only when 32 pid filter is not available (or it is already 100% in use)? regards Antti -- http://palosaari.fi/ -- 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] Improve Y16 color setup
Currently the colors for the Y16 and Y16_BE pixelformats are in the range
0x-0xff00. So pure white (0x) is never created.
Improve this by using the same byte for both LSB and MSB so the full range
is achieved.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index b1147f2..e28f32b 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -896,16 +896,12 @@ static void gen_twopix(struct tpg_data *tpg,
b_v = tpg-colors[color][2]; /* B or precalculated V */
switch (tpg-fourcc) {
- case V4L2_PIX_FMT_GREY:
- buf[0][offset] = r_y;
- break;
case V4L2_PIX_FMT_Y16:
- buf[0][offset] = 0;
- buf[0][offset+1] = r_y;
- break;
case V4L2_PIX_FMT_Y16_BE:
+ buf[0][offset+1] = r_y;
+ /* fall through */
+ case V4L2_PIX_FMT_GREY:
buf[0][offset] = r_y;
- buf[0][offset+1] = 0;
break;
case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
--
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] DocBook: document DVB net API
The DVB network API was not documented. There are just some
placeholders there.
Replace it by a proper documentation.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/Documentation/DocBook/media/Makefile
b/Documentation/DocBook/media/Makefile
index dbc9a56e8260..ae9d5a0404aa 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -91,7 +91,7 @@ STRUCTS = \
$(shell perl -ne 'print $$1 if (/^struct\s+([^\s]+)\s+/)'
$(srctree)/include/uapi/linux/dvb/ca.h) \
$(shell perl -ne 'print $$1 if (/^struct\s+([^\s]+)\s+/)'
$(srctree)/include/uapi/linux/dvb/dmx.h) \
$(shell perl -ne 'print $$1 if (!/dtv\_cmds\_h/
/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/frontend.h) \
- $(shell perl -ne 'print $$1 if (/^struct\s+([A-Z][^\s]+)\s+/)'
$(srctree)/include/uapi/linux/dvb/net.h) \
+ $(shell perl -ne 'print $$1 if (/^struct\s+([^\s]+)\s+/ !/_old/)'
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print $$1 if (/^struct\s+([^\s]+)\s+/)'
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/'
$(srctree)/include/uapi/linux/media.h) \
$(shell perl -ne 'print $$1 if /^struct\s+([^\s]+)\s+/'
$(srctree)/include/uapi/linux/v4l2-subdev.h) \
diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml
b/Documentation/DocBook/media/dvb/dvbapi.xml
index dc8cb558f9fd..858fd7d17104 100644
--- a/Documentation/DocBook/media/dvb/dvbapi.xml
+++ b/Documentation/DocBook/media/dvb/dvbapi.xml
@@ -108,7 +108,7 @@ Added ISDB-T test originally written by Patrick Boettcher
chapter id=dvb_ca
sub-ca;
/chapter
- chapter id=dvb_net
+ chapter id=net
sub-net;
/chapter
chapter id=legacy_dvb_apis
diff --git a/Documentation/DocBook/media/dvb/net.xml
b/Documentation/DocBook/media/dvb/net.xml
index d4ef21764959..aeac41ca7eae 100644
--- a/Documentation/DocBook/media/dvb/net.xml
+++ b/Documentation/DocBook/media/dvb/net.xml
@@ -1,156 +1,238 @@
titleDVB Network API/title
-paraThe DVB net device enables feeding of MPE (multi protocol encapsulation)
packets
-received via DVB into the Linux network protocol stack, e.g. for internet via
satellite
-applications. It can be accessed through emphasis
role=bold/dev/dvb/adapter0/net0/emphasis. Data types and
-and ioctl definitions can be accessed by including emphasis
role=boldlinux/dvb/net.h/emphasis in your
-application.
-/para
-section id=dvb_net_types
-titleDVB Net Data Types/title
+paraThe DVB net device controls the mapping of data packages that are
+part of a transport stream to be mapped into a virtual network interface,
+visible through the standard Linux network protocol stack./para
+paraCurrently, two encapsulations are supported:/para
+itemizedlist
+listitemparaulink
url=http://en.wikipedia.org/wiki/Multiprotocol_Encapsulation;
+ Multi Protocol Encapsulation (MPE)/ulink/para/listitem
+listitemparaulink
url=http://en.wikipedia.org/wiki/Unidirectional_Lightweight_Encapsulation;
+ Ultra Lightweight Encapsulation (ULE)/ulink/para/listitem
+/itemizedlist
-section id=dvb-net-if
-titlestruct dvb_net_if/title
-programlisting
-struct dvb_net_if {
- __u16 pid;
- __u16 if_num;
- __u8 feedtype;
-#define DVB_NET_FEEDTYPE_MPE 0 /#x22C6; multi protocol encapsulation #x22C6;/
-#define DVB_NET_FEEDTYPE_ULE 1 /#x22C6; ultra lightweight encapsulation
#x22C6;/
-};
-/programlisting
-/section
+paraIn order to create the Linux virtual network interfaces, an application
+needs to tell to the Kernel what are the PIDs and the encapsulation types
+that are present on the transport stream. This is done through
+emphasis role=bold/dev/dvb/adapter?/net?/emphasis device node.
+The data will be available via virtual constantdvb?_?/constant
+network interfaces, and will be controled/routed via the standard
+ip tools (like ip, route, netstat, ifconfig, etc)./para
+para Data types and and ioctl definitions are defined via
+emphasis role=boldlinux/dvb/net.h/emphasis header./para
-/section
section id=net_fcalls
titleDVB net Function Calls/title
-paraTo be written#x2026;
-/para
-
-section id=NET_ADD_IF
-role=subsectiontitleNET_ADD_IF/title
-paraDESCRIPTION
-/para
-informaltabletgroup cols=1tbodyrowentry
- align=char
-paraThis ioctl is undocumented. Documentation is welcome./para
-/entry
- /row/tbody/tgroup/informaltable
-paraSYNOPSIS
-/para
-informaltabletgroup cols=1tbodyrowentry
- align=char
-paraint ioctl(fd, int request = NET_ADD_IF,
- struct dvb_net_if *if);/para
-/entry
- /row/tbody/tgroup/informaltable
-paraPARAMETERS
-/para
-informaltabletgroup cols=2tbodyrowentry
- align=char
-paraint fd/para
-/entryentry
- align=char
-paraFile descriptor returned by a previous call to open()./para
-/entry
- /rowrowentry
- align=char
-paraint request/para
-/entryentry
- align=char
-paraEquals NET_ADD_IF for this command./para
Re: [RFC] Export alignment requirements for buffers
On 06/01/2015 12:44 PM, Sakari Ailus wrote: Hi Hans, Thanks for the RFC. On Mon, Jun 01, 2015 at 11:44:51AM +0200, Hans Verkuil wrote: One of the things that is really irritating is the fact that drivers that use contig-dma sometimes want to support USERPTR, allowing applications to pass pointers to the driver that point to physically contiguous memory that was somehow obtained, and that userspace has no way of knowing whether the driver has this requirement or not. A related issue is that, depending on the DMA engine, the user pointer might have some alignment requirements (page aligned, or at minimum 16 bytes aligned) that userspace has no way of knowing. The same alignment issue is present also for dma-buf. I propose to take one reserved field from struct v4l2_create_buffers and from struct v4l2_requestbuffers and change it to this: __u32 flags; #define V4L2_REQBUFS_FL_ALIGNMENT_MSK0x3f How about V4L2_REQBUFS_FL_ALIGN_MASK instead? It's shorter, and that msk part looks odd to me. Hmm, how to do this. Currently it masks out 6 bits which form the power-of-two that determines the alignment. How about this: #define V4L2_REQBUFS_FL_ALIGN_EXP(flags) ((flags) 0x3f) #define V4L2_REQBUFS_FL_ALIGN_MASK(flags) ((1ULL (flags 0x3f)) - 1) That gives you both mask and the exponent. Better names are welcome :-) ALIGN_PWR? PWR2? ALIGN_AT_BIT? #define V4L2_REQBUFS_FL_PHYS_CONTIG (1 31) Where the alignment is a power of 2 (and if 0 the alignment is unknown). The max is 2^63, which should be enough for the foreseeable future :-) If the physically contiguous flag is set, then the buffer must be physically contiguous. Both only apply to userptr buffers. I guess saying this in documentation only is enough. I don't follow you. Perhaps there is some confusion here? The flags field is set by the driver, not by userspace. So PHYS_CONTIG applies to any type of buffer if the driver uses dma-contig. And the alignment is valid for all drivers as well. The approach looks good to me. dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless overridden by the driver) page aligned. dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the driver DMA implementation. Note: malloc will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. Ack. Many dma-sg drivers actually can handle physically contiguous memory since they're behind an IOMMU; the drivers can then set the flag if needed. All dma-sg drivers can handle phys contig memory since that's just one DMA descriptor. The flag is meant to say that the buffer *has* to be phys contig, not that it might be. So dma-sg drivers will not set it, since they don't have that requirement. Regards, Hans -- 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] stk1160: add DMABUF support
Implement DMABUF exporting and importing.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/usb/stk1160/stk1160-v4l.c
b/drivers/media/usb/stk1160/stk1160-v4l.c
index 749ad56..4d313ed 100644
--- a/drivers/media/usb/stk1160/stk1160-v4l.c
+++ b/drivers/media/usb/stk1160/stk1160-v4l.c
@@ -500,6 +500,7 @@ static const struct v4l2_ioctl_ops stk1160_ioctl_ops = {
.vidioc_dqbuf = vb2_ioctl_dqbuf,
.vidioc_streamon = vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
+ .vidioc_expbuf= vb2_ioctl_expbuf,
.vidioc_log_status = v4l2_ctrl_log_status,
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
@@ -645,7 +646,7 @@ int stk1160_vb2_setup(struct stk1160 *dev)
q = dev-vb_vidq;
q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- q-io_modes = VB2_READ | VB2_MMAP | VB2_USERPTR;
+ q-io_modes = VB2_READ | VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct stk1160_buffer);
q-ops = stk1160_video_qops;
--
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] treewide: Fix typo compatability - compatibility
On 27.05.15 14:05, Laurent Pinchart wrote: Even though 'compatability' has a dedicated entry in the Wiktionary, it's listed as 'Mispelling of compatibility'. Fix it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- arch/metag/include/asm/elf.h | 2 +- arch/powerpc/kvm/book3s.c| 2 +- Acked-by: Alexander Graf ag...@suse.de for the PPC KVM bit. Alex -- 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: videobuf2-dc: set properly dma_max_segment_size
If device has no DMA max_seg_size set, we assume that there is no limit
and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
let DMA-mapping API always create contiguous mappings in DMA address
space. This is essential for all devices, which use dma-contig
videobuf2 memory allocator.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 644dec73d220..9d7c1814b0f3 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -862,6 +862,23 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
void *vb2_dma_contig_init_ctx(struct device *dev)
{
struct vb2_dc_conf *conf;
+ int err;
+
+ /*
+* if device has no max_seg_size set, we assume that there is no limit
+* and force it to DMA_BIT_MASK(32) to always use contiguous mappings
+* in DMA address space
+*/
+ if (!dev-dma_parms) {
+ dev-dma_parms = kzalloc(sizeof(*dev-dma_parms), GFP_KERNEL);
+ if (!dev-dma_parms)
+ return ERR_PTR(-ENOMEM);
+ }
+ if (dma_get_max_seg_size(dev) DMA_BIT_MASK(32)) {
+ err = dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+ if (err)
+ return ERR_PTR(err);
+ }
conf = kzalloc(sizeof *conf, GFP_KERNEL);
if (!conf)
--
1.9.2
--
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 2/9] mm: Provide new get_vaddr_frames() helper
On 06/01/2015 02:40 PM, Jan Kara wrote: On Thu 28-05-15 16:24:02, Andrew Morton wrote: On Wed, 13 May 2015 15:08:08 +0200 Jan Kara j...@suse.cz wrote: Provide new function get_vaddr_frames(). This function maps virtual addresses from given start and fills given array with page frame numbers of the corresponding pages. If given start belongs to a normal vma, the function grabs reference to each of the pages to pin them in memory. If start belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller must make sure pfns aren't reused for anything else while he is using them. This function is created for various drivers to simplify handling of their buffers. Acked-by: Mel Gorman mgor...@suse.de Acked-by: Vlastimil Babka vba...@suse.cz Signed-off-by: Jan Kara j...@suse.cz --- include/linux/mm.h | 44 +++ mm/gup.c | 226 + That's a lump of new code which many kernels won't be needing. Can we put all this in a new .c file and select it within drivers/media Kconfig? Yeah, makes sense. I'll write a patch. Hans, is it OK with you if I just create a patch on top of the series you have in your tree? No problem. Regards, Hans -- 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: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
Hi, On Friday 29 May 2015 08:34 PM, Felipe Balbi wrote: Hi, On Fri, May 29, 2015 at 05:04:38PM +0530, Kishon Vijay Abraham I wrote: Hi Felipe, On Wednesday 27 May 2015 12:09 AM, Felipe Balbi wrote: On Tue, May 26, 2015 at 11:37:17AM -0700, Arun Ramamurthy wrote: Hi On 15-05-26 07:19 AM, Felipe Balbi wrote: HI, On Mon, May 25, 2015 at 02:19:58PM -0700, Arun Ramamurthy wrote: On 15-05-14 05:52 PM, Felipe Balbi wrote: Hi, On Wed, Apr 22, 2015 at 04:04:10PM -0700, Arun Ramamurthy wrote: Most of the phy providers use select to enable GENERIC_PHY. Since select is only recommended when the config is not visible, GENERIC_PHY is changed an invisible option. To maintain consistency, all phy providers are changed to select GENERIC_PHY and all non-phy drivers use depends on when the phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic dependency, so it is left as select. Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com --- drivers/ata/Kconfig | 1 - drivers/media/platform/exynos4-is/Kconfig | 2 +- drivers/phy/Kconfig | 4 ++-- drivers/usb/host/Kconfig | 4 ++-- drivers/video/fbdev/exynos/Kconfig| 2 +- 5 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 5f60155..6d2e881 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -301,7 +301,6 @@ config SATA_MV tristate Marvell SATA support depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \ ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST - select GENERIC_PHY help This option enables support for the Marvell Serial ATA family. Currently supports 88SX[56]0[48][01] PCI(-X) chips, diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index b7b2e47..b6f3eaa 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC config VIDEO_S5P_MIPI_CSIS tristate S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver depends on REGULATOR - select GENERIC_PHY + depends on GENERIC_PHY help This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2 receiver (MIPI-CSIS) devices. diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 2962de2..edecdb1 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -5,7 +5,7 @@ menu PHY Subsystem config GENERIC_PHY - bool PHY Core + bool help Generic PHY support. @@ -72,7 +72,7 @@ config PHY_MIPHY365X config PHY_RCAR_GEN2 tristate Renesas R-Car generation 2 USB PHY driver depends on ARCH_SHMOBILE - depends on GENERIC_PHY + select GENERIC_PHY so some you changed from depends to select... help Support for USB PHY found on Renesas R-Car generation 2 SoCs. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5ad60e4..e2197e2 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR config USB_EHCI_HCD_STI tristate Support for ST STiHxxx on-chip EHCI USB controller depends on ARCH_STI OF - select GENERIC_PHY + depends on GENERIC_PHY while others you changed from select to depends. NAK. Felipe, I dont understand your concern, could you please explain it more detail? The logic behind the changes is that in cases where there was an explicit dependency, I changed it to depends on and in other cases I changed it to selects. Thanks Since GENERIC_PHY is visible from Kconfig, it would be much nicer to avoid select altogether. Felipe, after discussion with the maintainers, I have made GENERIC_PHY an invisible option as part of this change. Thanks Then, if the option is invisible, how can you depend on it ? It can never be selected by poking around in Kconfig. IMO, it's counterintuitive that you need to enable a PHY driver before you can see your EHCI/OHCI/whatever controller listed in Kconfig. If the controller requires PHY for it to be functional, it is okay to make the controller depend on PHY IMHO. We want to try and minimize the usage of 'select' wherever possible or else 'select' is the most intuitive way. The other option is just to leave the 'depends on' and let the user select PHY. How can you 'depend' on something that the user can't select by navigating through Kconfig ? hmm... Actually it's selected when the user selects the PHY driver. Maybe we should directly depend on the PHY driver instead of Generic PHY? Thanks Kishon -- 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/2] si2168: Implement own I2C adapter locking
On 05/31/2015 07:56 PM, Adam Baker wrote: On 29/05/15 22:05, Antti Palosaari wrote: We need own I2C locking because of tuner I2C adapter/repeater. Firmware command is executed using I2C send + reply message. Default I2C adapter locking protects only single I2C operation, not whole send + reply sequence as needed. Due to that, it was possible tuner I2C message interrupts firmware command sequence. Reported-by: Adam Baker li...@baker-net.org.uk Signed-off-by: Antti Palosaari cr...@iki.fi --- Reviewed-by: Adam Baker li...@baker-net.org.uk Having looked over this I can't see any remaining deadlocks or failures to provide adequate locking. Without a detailed device datasheet (the public datasheet is only the short version) it is impossible to say 1) If accessing the I2C gate in between a read and write cycle would actually cause a problem, if it doesn't then a simpler solution would be possible but it seems reasonable to assume that it does. Hey, you could very very easily make test and see what happens. Just add dummy I2C gate open / close request to si2168_cmd_execute_unlocked() and see what happens. I suspect it will fail as I cannot see how firmware could even report status of multiple operations happening same time. Firmware status is always first byte of read operation, there is no flag to say which operation status is for. OK, currently I2C gate status is not checked at all, but still. i2c_master_send(download firmware packet); i2c_master_send(open I2C gate); i2c_master_recv(read status); -- which operation status it will be? Many fw operations are pretty fast and reply is always firmware ready. But there is some operations that will take up to 70ms. 2) How effective the retry mechanism is. The current behaviour that retries the read cycle without retrying the preceding write means that it isn't possible to pass the read and write messages as multiple messages to i2c_transfer and let that handle the locking for us. Passing multiple messages to i2c_transfer() is different that multiple i2c_master_send() / i2c_master_recv(). Look what means repeated start condition from some I2C documentation to understand the difference. Do you know how likely it is for this issue to be triggered without the signal stats patch applied? My suspicion is that it could only happen if user space deliberately tried changing parameters on the tuner and frontend at the same time from different threads and hence the fix isn't worth pushing to stable. Those callbacks are driven be DVB core which serializes all operations. So it could not happen (without that statistics polling kernel thread). regards Antti -- http://palosaari.fi/ -- 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 1/4] b2c2: Add option to skip the first 6 pid filters
Hi all, On Mon, 01 Jun 2015 09:08:03 +0100 Jemma Denson jden...@gmail.com wrote: Yes, that might work, I hadn't though of just swapping them around - thanks. It would however assume that the 0x PAT feed is requested early on enough that it always sits within the bank of 32 and nothing else is too bothered by the odd out of order packet. The only concern I have got is if there is any other oddness in the first 6 - this card is the only flexcop based card with dvb-s2 and there is a lack of stream with high bitrate transponders (approx. 45Mbps), which we think might due to the hardware pid filter. The card apparently works fine under the windows driver so it's a case of trying to work out what that might be doing differently. It's quite speculative at the moment but I'm hoping this patch might help with that and I'm waiting for some feedback on that - I'm stuck with 28.2E which doesn't hold anything interesting. At the moment it doesn't really matter too much having only 32 filters rather than the full 38 - it does switch to full-TS once it runs out of hardware filters, and the only issue with full-TS is that the flexcop can't pass a TS with more than 45Mbps (but they aren't working at the moment anyway) I agree, if the 6 PID-filters are not working they should be used. The worth is receiving PSI of a transponder/channel which is in fact from the one previously tuned. I think it is better to leave it as you suggested. -- Patrick. -- 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: Issues with Geniatech MyGica T230
On Thu, May 28, 2015 at 04:41:17PM +0200, Valentin Vidic wrote: I recently bought this card after seeing on the LinuxTV wiki that it's supported since kernel v3.19, but now I can't get it working properly with Debian. The modules load without errors but scanning for channels or watching TV does not work reliably: some channels work but others just hang the player or return a lot of frame out of order erorrs. In order to rule out hardware problems I tested the card using OpenELEC (RPi and x86_64) and Windows Media Player and it works there without a glich. So I assumed this is a software problem somewhere I tried several different kernel versions without success: 3.16.7-ckt9-3~deb8u1 + media_build drivers 4.0.2-1 3.19.0 3.19.8 Any suggestions what could be wrong or what more to try? -- Valentin -- 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 2/9] mm: Provide new get_vaddr_frames() helper
On Thu 28-05-15 16:24:02, Andrew Morton wrote: On Wed, 13 May 2015 15:08:08 +0200 Jan Kara j...@suse.cz wrote: Provide new function get_vaddr_frames(). This function maps virtual addresses from given start and fills given array with page frame numbers of the corresponding pages. If given start belongs to a normal vma, the function grabs reference to each of the pages to pin them in memory. If start belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller must make sure pfns aren't reused for anything else while he is using them. This function is created for various drivers to simplify handling of their buffers. Acked-by: Mel Gorman mgor...@suse.de Acked-by: Vlastimil Babka vba...@suse.cz Signed-off-by: Jan Kara j...@suse.cz --- include/linux/mm.h | 44 +++ mm/gup.c | 226 + That's a lump of new code which many kernels won't be needing. Can we put all this in a new .c file and select it within drivers/media Kconfig? Yeah, makes sense. I'll write a patch. Hans, is it OK with you if I just create a patch on top of the series you have in your tree? Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- 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 2/2] [media] DocBook: fix FE_SET_PROPERTY ioctl arguments
On 06/01/2015 11:12 AM, Mauro Carvalho Chehab wrote: FE_SET_PROPERTY/FE_GET_PROPERTY actually expects a struct dtv_properties argument. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media/dvb/fe-get-property.xml b/Documentation/DocBook/media/dvb/fe-get-property.xml index 7d0bd78f5a24..53a170ed3bd1 100644 --- a/Documentation/DocBook/media/dvb/fe-get-property.xml +++ b/Documentation/DocBook/media/dvb/fe-get-property.xml @@ -17,7 +17,7 @@ funcdefint functionioctl/function/funcdef paramdefint parameterfd/parameter/paramdef paramdefint parameterrequest/parameter/paramdef - paramdefstruct dtv_property *parameterargp/parameter/paramdef + paramdefstruct dtv_properties *parameterargp/parameter/paramdef Oops, my fault. It's already merged, but for the record: Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans /funcprototype /funcsynopsis /refsynopsisdiv -- 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 0/3] DocBook media: xmllint/typo fixes
Em Sun, 31 May 2015 14:59:09 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: From: Hans Verkuil hans.verk...@cisco.com Hi Mauro, Here are three patches that fix typos and xmllint errors. The first patch fixes typos, the second a large number of xmllint errors and the last fixes a final xmllint error, but it does that by copying most of the v4l2 open/close text and you should check whether I didn't remove anything that is relevant for DVB. Note that I use the following 'gitdocs.sh' script to build the documentation: Patches applied. I had to add two extra patches in order to fix a few issues (one at the open() conversion and another one that it is likely a cut-and-past mistake that I introduced). #!/bin/sh make DOCBOOKS=media_api.xml htmldocs 21 | grep -v element.*: validity error : ID .* already defined xmllint --noent --postvalid $PWD/Documentation/DocBook/media_api.xml /tmp/x.xml 2/dev/null xmllint --noent --postvalid --noout /tmp/x.xml xmlto html-nochunks -m ./Documentation/DocBook/stylesheet.xsl -o Documentation/DocBook/media Documentation/DocBook/media_api.xml /dev/null 21 Updated my scripts to use this more pedantic variation. -- 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: [RFC] Export alignment requirements for buffers
Hi Hans, Thanks for the RFC. On Mon, Jun 01, 2015 at 11:44:51AM +0200, Hans Verkuil wrote: One of the things that is really irritating is the fact that drivers that use contig-dma sometimes want to support USERPTR, allowing applications to pass pointers to the driver that point to physically contiguous memory that was somehow obtained, and that userspace has no way of knowing whether the driver has this requirement or not. A related issue is that, depending on the DMA engine, the user pointer might have some alignment requirements (page aligned, or at minimum 16 bytes aligned) that userspace has no way of knowing. The same alignment issue is present also for dma-buf. I propose to take one reserved field from struct v4l2_create_buffers and from struct v4l2_requestbuffers and change it to this: __u32 flags; #define V4L2_REQBUFS_FL_ALIGNMENT_MSK 0x3f How about V4L2_REQBUFS_FL_ALIGN_MASK instead? It's shorter, and that msk part looks odd to me. #define V4L2_REQBUFS_FL_PHYS_CONTIG (1 31) Where the alignment is a power of 2 (and if 0 the alignment is unknown). The max is 2^63, which should be enough for the foreseeable future :-) If the physically contiguous flag is set, then the buffer must be physically contiguous. Both only apply to userptr buffers. I guess saying this in documentation only is enough. The approach looks good to me. dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless overridden by the driver) page aligned. dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the driver DMA implementation. Note: malloc will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. Ack. Many dma-sg drivers actually can handle physically contiguous memory since they're behind an IOMMU; the drivers can then set the flag if needed. -- 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 v2 1/4] b2c2: Add option to skip the first 6 pid filters
Hi Antti, On 01/06/15 07:14, Antti Palosaari wrote: On 05/30/2015 09:10 PM, Jemma Denson wrote: The flexcop bridge chip has two banks of hardware pid filters - an initial 6, and on some chip revisions an additional bank of 32. A bug is present on the initial 6 - when changing transponders one of two PAT packets from the old transponder would be included in the initial packets from the new transponder. This usually transpired with userspace programs complaining about services missing, because they are seeing a PAT that they would not be expecting. Running in full TS mode does not exhibit this problem, neither does using just the additional 32. This patch adds in an option to not use the inital 6 and solely use just the additional 32, and enables this option for the SkystarS2 card. Other cards can be added as required if they also have this bug. Why not to use strategy where 32 pid filter is used as a priority and that buggy 6 pid filter is used only when 32 pid filter is not available (or it is already 100% in use)? Yes, that might work, I hadn't though of just swapping them around - thanks. It would however assume that the 0x PAT feed is requested early on enough that it always sits within the bank of 32 and nothing else is too bothered by the odd out of order packet. The only concern I have got is if there is any other oddness in the first 6 - this card is the only flexcop based card with dvb-s2 and there is a lack of stream with high bitrate transponders (approx. 45Mbps), which we think might due to the hardware pid filter. The card apparently works fine under the windows driver so it's a case of trying to work out what that might be doing differently. It's quite speculative at the moment but I'm hoping this patch might help with that and I'm waiting for some feedback on that - I'm stuck with 28.2E which doesn't hold anything interesting. At the moment it doesn't really matter too much having only 32 filters rather than the full 38 - it does switch to full-TS once it runs out of hardware filters, and the only issue with full-TS is that the flexcop can't pass a TS with more than 45Mbps (but they aren't working at the moment anyway) Jemma. -- 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 v4.2] Final set of compile/sparse fixes
This set fixes the final compilation and sparse warnings (except for a few remaining sparse warnings for which I have no obvious solution). It also improves timestamp handling in the davinci drivers. Regards, Hans The following changes since commit c1c3c85ddf60a6d97c122d57d385b4929fcec4b3: [media] DocBook: fix FE_SET_PROPERTY ioctl arguments (2015-06-01 06:10:15 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.2n for you to fetch changes up to 4dc825912fb78205a3ec5c6d43f9d517569d6adc: media: s5p-mfc: fix sparse warnings (2015-06-01 11:19:45 +0200) Lad, Prabhakar (4): media: davinci_vpfe: clear the output_specs media: davinci_vpfe: set minimum required buffers to three media: davinci_vpfe: use monotonic timestamp media: davinci: vpbe: use v4l2_get_timestamp() Marek Szyprowski (1): media: s5p-mfc: fix sparse warnings drivers/media/platform/davinci/vpbe_display.c| 9 ++--- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 4 ++-- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 4 ++-- drivers/staging/media/davinci_vpfe/dm365_resizer.c | 1 + drivers/staging/media/davinci_vpfe/vpfe_mc_capture.h | 2 -- drivers/staging/media/davinci_vpfe/vpfe_video.c | 18 +- 6 files changed, 12 insertions(+), 26 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: Build regressions/improvements in v4.1-rc6
On Mon, Jun 1, 2015 at 12:09 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
JFYI, when comparing v4.1-rc6[1] to v4.1-rc5[3], the summaries are:
- build errors: +8/-52
+ /home/kisskb/slave/src/drivers/media/i2c/ov2659.c: error: 'struct
v4l2_subdev_fh' has no member named 'pad': = 1264:38
+ /home/kisskb/slave/src/drivers/media/i2c/ov2659.c: error: implicit
declaration of function 'v4l2_subdev_get_try_format'
[-Werror=implicit-function-declaration]: = 1054:3
i386-randconfig
+ error: aes.c: undefined reference to `.enable_kernel_altivec': =
.text+0x48e894), .text+0x48e6e0), .text+0x48e960)
+ error: aes_cbc.c: undefined reference to `.enable_kernel_altivec':
= .text+0x48ea98), .text+0x48ebf4)
powerpc-randconfig
[1] http://kisskb.ellerman.id.au/kisskb/head/8943/ (254 out of 257 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/8914/ (254 out of 257 configs)
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
[GIT PULL 4.2] si2157 RSSI
The following changes since commit d511eb7d642aaf513fefeb05514dc6177c53c350: [media] uvcvideo: Remove unneeded device disconnected flag (2015-05-30 12:12:58 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git silabs_pull for you to fetch changes up to c7da453bbea128534bbe82cbec2c4c2bc5f24c3c: si2157: implement signal strength stats (2015-06-01 11:24:00 +0300) Antti Palosaari (2): si2168: Implement own I2C adapter locking si2157: implement signal strength stats drivers/media/dvb-frontends/si2168.c | 135 +++ drivers/media/dvb-frontends/si2168_priv.h | 1 - drivers/media/tuners/si2157.c | 40 +++- drivers/media/tuners/si2157_priv.h| 1 + 4 files changed, 119 insertions(+), 58 deletions(-) -- http://palosaari.fi/ -- 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
[RFC] Export alignment requirements for buffers
One of the things that is really irritating is the fact that drivers that use contig-dma sometimes want to support USERPTR, allowing applications to pass pointers to the driver that point to physically contiguous memory that was somehow obtained, and that userspace has no way of knowing whether the driver has this requirement or not. A related issue is that, depending on the DMA engine, the user pointer might have some alignment requirements (page aligned, or at minimum 16 bytes aligned) that userspace has no way of knowing. The same alignment issue is present also for dma-buf. I propose to take one reserved field from struct v4l2_create_buffers and from struct v4l2_requestbuffers and change it to this: __u32 flags; #define V4L2_REQBUFS_FL_ALIGNMENT_MSK 0x3f #define V4L2_REQBUFS_FL_PHYS_CONTIG (1 31) Where the alignment is a power of 2 (and if 0 the alignment is unknown). The max is 2^63, which should be enough for the foreseeable future :-) If the physically contiguous flag is set, then the buffer must be physically contiguous. These flags can be set for every vb2 dma implementation: dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless overridden by the driver) page aligned. dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the driver DMA implementation. Note: malloc will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. The flags field can be extended with things like OPAQUE if the buffers cannot be mmapped (since they are in protected memory). Comments? Alternative solutions? Regards, Hans -- 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] vivid: move video loopback control to the capture device
This has been on my TODO list for some time now: the control that enables the
video
loopback was part of the controls of the video output device instead of the
video
capture device. In practice this was quite annoying since you expect it at the
capture
side since that's where you want to make the decision whether to use the TPG or
looped
video.
This patch moves the control from the output to the capture side.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/Documentation/video4linux/vivid.txt
b/Documentation/video4linux/vivid.txt
index cd4b5a1..51f57e3 100644
--- a/Documentation/video4linux/vivid.txt
+++ b/Documentation/video4linux/vivid.txt
@@ -888,7 +888,7 @@ Section 10.1: Video and Sliced VBI looping
The way to enable video/VBI looping is currently fairly crude. A 'Loop Video'
control is available in the Vivid control class of the video
-output and VBI output devices. When checked the video looping will be enabled.
+capture and VBI capture devices. When checked the video looping will be
enabled.
Once enabled any video S-Video or HDMI input will show a static test pattern
until the video output has started. At that time the video output will be
looped to the video input provided that:
diff --git a/drivers/media/platform/vivid/vivid-core.h
b/drivers/media/platform/vivid/vivid-core.h
index aa1b523..a6ffd51 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -139,7 +139,7 @@ struct vivid_dev {
struct v4l2_ctrl_handlerctrl_hdl_user_aud;
struct v4l2_ctrl_handlerctrl_hdl_streaming;
struct v4l2_ctrl_handlerctrl_hdl_sdtv_cap;
- struct v4l2_ctrl_handlerctrl_hdl_loop_out;
+ struct v4l2_ctrl_handlerctrl_hdl_loop_cap;
struct video_device vid_cap_dev;
struct v4l2_ctrl_handlerctrl_hdl_vid_cap;
struct video_device vid_out_dev;
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c
b/drivers/media/platform/vivid/vivid-ctrls.c
index 2b90700..81ee872 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -766,6 +766,37 @@ static const struct v4l2_ctrl_config
vivid_ctrl_limited_rgb_range = {
};
+/* Video Loop Control */
+
+static int vivid_loop_cap_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct vivid_dev *dev = container_of(ctrl-handler, struct vivid_dev,
ctrl_hdl_loop_cap);
+
+ switch (ctrl-id) {
+ case VIVID_CID_LOOP_VIDEO:
+ dev-loop_video = ctrl-val;
+ vivid_update_quality(dev);
+ vivid_send_source_change(dev, SVID);
+ vivid_send_source_change(dev, HDMI);
+ break;
+ }
+ return 0;
+}
+
+static const struct v4l2_ctrl_ops vivid_loop_cap_ctrl_ops = {
+ .s_ctrl = vivid_loop_cap_s_ctrl,
+};
+
+static const struct v4l2_ctrl_config vivid_ctrl_loop_video = {
+ .ops = vivid_loop_cap_ctrl_ops,
+ .id = VIVID_CID_LOOP_VIDEO,
+ .name = Loop Video,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .max = 1,
+ .step = 1,
+};
+
+
/* VBI Capture Control */
static int vivid_vbi_cap_s_ctrl(struct v4l2_ctrl *ctrl)
@@ -1199,38 +1230,6 @@ static const struct v4l2_ctrl_config
vivid_ctrl_radio_tx_rds_blockio = {
};
-
-/* Video Loop Control */
-
-static int vivid_loop_out_s_ctrl(struct v4l2_ctrl *ctrl)
-{
- struct vivid_dev *dev = container_of(ctrl-handler, struct vivid_dev,
ctrl_hdl_loop_out);
-
- switch (ctrl-id) {
- case VIVID_CID_LOOP_VIDEO:
- dev-loop_video = ctrl-val;
- vivid_update_quality(dev);
- vivid_send_source_change(dev, SVID);
- vivid_send_source_change(dev, HDMI);
- break;
- }
- return 0;
-}
-
-static const struct v4l2_ctrl_ops vivid_loop_out_ctrl_ops = {
- .s_ctrl = vivid_loop_out_s_ctrl,
-};
-
-static const struct v4l2_ctrl_config vivid_ctrl_loop_video = {
- .ops = vivid_loop_out_ctrl_ops,
- .id = VIVID_CID_LOOP_VIDEO,
- .name = Loop Video,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .max = 1,
- .step = 1,
-};
-
-
static const struct v4l2_ctrl_config vivid_ctrl_class = {
.ops = vivid_user_gen_ctrl_ops,
.flags = V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY,
@@ -1248,7 +1247,7 @@ int vivid_create_controls(struct vivid_dev *dev, bool
show_ccs_cap,
struct v4l2_ctrl_handler *hdl_user_aud = dev-ctrl_hdl_user_aud;
struct v4l2_ctrl_handler *hdl_streaming = dev-ctrl_hdl_streaming;
struct v4l2_ctrl_handler *hdl_sdtv_cap = dev-ctrl_hdl_sdtv_cap;
- struct v4l2_ctrl_handler *hdl_loop_out = dev-ctrl_hdl_loop_out;
+ struct v4l2_ctrl_handler *hdl_loop_cap = dev-ctrl_hdl_loop_cap;
struct v4l2_ctrl_handler *hdl_vid_cap = dev-ctrl_hdl_vid_cap;
struct v4l2_ctrl_handler *hdl_vid_out = dev-ctrl_hdl_vid_out;
struct
Re: [PATCH 1/2] [media] DocBook: some fixes for DVB FE open()
On 06/01/2015 11:12 AM, Mauro Carvalho Chehab wrote: The changeset dc9ef7d11207 change the open() ioctl documentation to match the V4L2 open(). However, some cut-and-pasted stuff doesn't match what actually happens at the DVB core. So, fix the documentation entry to be more accurate with the DVB frontend open() specifics. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com I thought this might be necessary :-) Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks! Hans diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index c7fa3d8bff5c..9d8e95cd9694 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml @@ -61,7 +61,7 @@ specification is available at refentry id=frontend_f_open refmeta -refentrytitleopen()/refentrytitle +refentrytitleDVB frontend open()/refentrytitle manvol; /refmeta @@ -94,20 +94,19 @@ specification is available at varlistentry termparameterflags/parameter/term listitem - paraOpen flags. Access mode must be -constantO_RDWR/constant. This is just a technicality, input devices -still support only reading and output devices only writing./para - paraWhen the constantO_NONBLOCK/constant flag is -given, the read() function will return the EAGAIN; when no data is available, -otherwise these functions block until data becomes -available. Other flags have no effect./para + paraOpen flags. Access can either be + constantO_RDWR/constant or constantO_RDONLY/constant./para + paraMultiple opens are allowed with constantO_RDONLY/constant. In this mode, only query and read ioctls are allowed./para + paraOnly one open is allowed in constantO_RDWR/constant. In this mode, all ioctls are allowed./para + paraWhen the constantO_NONBLOCK/constant flag is given, the system calls may return EAGAIN; when no data is available or when the device driver is temporarily busy./para + paraOther flags have no effect./para /listitem /varlistentry /variablelist /refsect1 refsect1 titleDescription/title -paraThis system call opens a named frontend device (/dev/dvb/adapter0/frontend0) +paraThis system call opens a named frontend device (constant/dev/dvb/adapter?/frontend?/constant) for subsequent use. Usually the first thing to do after a successful open is to find out the frontend type with link linkend=FE_GET_INFOFE_GET_INFO/link./para paraThe device can be opened in read-only mode, which only allows monitoring of @@ -145,8 +144,7 @@ device./para varlistentry termerrorcodeEBUSY/errorcode/term listitem - paraThe driver does not support multiple opens and the -device is already in use./para + paraThe the device driver is already in use./para /listitem /varlistentry varlistentry @@ -177,13 +175,19 @@ files open./para system has been reached./para /listitem /varlistentry + varlistentry + termerrorcodeENODEV/errorcode/term + listitem + paraThe device got removed./para + /listitem + /varlistentry /variablelist /refsect1 /refentry refentry id=frontend_f_close refmeta -refentrytitleclose()/refentrytitle +refentrytitleDVB frontend close()/refentrytitle manvol; /refmeta -- 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
[PATCHv2 0/2] si2157 rssi and si2168 I2C adapter locking
v2: * si2168 declare functions as static * i2157 set FE_SCALE_NOT_AVAILABLE if stats polling stopped due to IO error Antti Palosaari (2): si2168: Implement own I2C adapter locking si2157: implement signal strength stats drivers/media/dvb-frontends/si2168.c | 135 +- drivers/media/dvb-frontends/si2168_priv.h | 1 - drivers/media/tuners/si2157.c | 40 - drivers/media/tuners/si2157_priv.h| 1 + 4 files changed, 119 insertions(+), 58 deletions(-) -- http://palosaari.fi/ -- 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
[PATCHv2 2/2] si2157: implement signal strength stats
Implement DVBv5 signal strength stats. Returns dBm.
Signed-off-by: Antti Palosaari cr...@iki.fi
Tested-by: Adam Baker li...@baker-net.org.uk
---
drivers/media/tuners/si2157.c | 40 +-
drivers/media/tuners/si2157_priv.h | 1 +
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index cdaf687..a6245ef 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -79,6 +79,7 @@ static int si2157_init(struct dvb_frontend *fe)
{
struct i2c_client *client = fe-tuner_priv;
struct si2157_dev *dev = i2c_get_clientdata(client);
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret, len, remaining;
struct si2157_cmd cmd;
const struct firmware *fw;
@@ -201,9 +202,14 @@ skip_fw_download:
dev-fw_loaded = true;
warm:
+ /* init statistics in order signal app which are supported */
+ c-strength.len = 1;
+ c-strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ /* start statistics polling */
+ schedule_delayed_work(dev-stat_work, msecs_to_jiffies(1000));
+
dev-active = true;
return 0;
-
err_release_firmware:
release_firmware(fw);
err:
@@ -222,6 +228,9 @@ static int si2157_sleep(struct dvb_frontend *fe)
dev-active = false;
+ /* stop statistics polling */
+ cancel_delayed_work_sync(dev-stat_work);
+
/* standby */
memcpy(cmd.args, \x16\x00, 2);
cmd.wlen = 2;
@@ -360,6 +369,34 @@ static const struct dvb_tuner_ops si2157_ops = {
.get_if_frequency = si2157_get_if_frequency,
};
+static void si2157_stat_work(struct work_struct *work)
+{
+ struct si2157_dev *dev = container_of(work, struct si2157_dev,
stat_work.work);
+ struct dvb_frontend *fe = dev-fe;
+ struct i2c_client *client = fe-tuner_priv;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ struct si2157_cmd cmd;
+ int ret;
+
+ dev_dbg(client-dev, \n);
+
+ memcpy(cmd.args, \x42\x00, 2);
+ cmd.wlen = 2;
+ cmd.rlen = 12;
+ ret = si2157_cmd_execute(client, cmd);
+ if (ret)
+ goto err;
+
+ c-strength.stat[0].scale = FE_SCALE_DECIBEL;
+ c-strength.stat[0].svalue = (s8) cmd.args[3] * 1000;
+
+ schedule_delayed_work(dev-stat_work, msecs_to_jiffies(2000));
+ return;
+err:
+ c-strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ dev_dbg(client-dev, failed=%d\n, ret);
+}
+
static int si2157_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -384,6 +421,7 @@ static int si2157_probe(struct i2c_client *client,
dev-chiptype = (u8)id-driver_data;
dev-if_frequency = 500; /* default value of property 0x0706 */
mutex_init(dev-i2c_mutex);
+ INIT_DELAYED_WORK(dev-stat_work, si2157_stat_work);
/* check if the tuner is there */
cmd.wlen = 0;
diff --git a/drivers/media/tuners/si2157_priv.h
b/drivers/media/tuners/si2157_priv.h
index 71a5f8c..ecc463d 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -30,6 +30,7 @@ struct si2157_dev {
u8 chiptype;
u8 if_port;
u32 if_frequency;
+ struct delayed_work stat_work;
};
#define SI2157_CHIPTYPE_SI2157 0
--
http://palosaari.fi/
--
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
[PATCHv2 1/2] si2168: Implement own I2C adapter locking
We need own I2C locking because of tuner I2C adapter/repeater.
Firmware command is executed using I2C send + reply message. Default
I2C adapter locking protects only single I2C operation, not whole
send + reply sequence as needed. Due to that, it was possible tuner
I2C message interrupts firmware command sequence.
Reported-by: Adam Baker li...@baker-net.org.uk
Signed-off-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Adam Baker li...@baker-net.org.uk
---
drivers/media/dvb-frontends/si2168.c | 135 +-
drivers/media/dvb-frontends/si2168_priv.h | 1 -
2 files changed, 79 insertions(+), 57 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index b68ab34..d6a4cb0 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -18,23 +18,53 @@
static const struct dvb_frontend_ops si2168_ops;
+/* Own I2C adapter locking is needed because of I2C gate logic. */
+static int si2168_i2c_master_send_unlocked(const struct i2c_client *client,
+ const char *buf, int count)
+{
+ int ret;
+ struct i2c_msg msg = {
+ .addr = client-addr,
+ .flags = 0,
+ .len = count,
+ .buf = (char *)buf,
+ };
+
+ ret = __i2c_transfer(client-adapter, msg, 1);
+ return (ret == 1) ? count : ret;
+}
+
+static int si2168_i2c_master_recv_unlocked(const struct i2c_client *client,
+ char *buf, int count)
+{
+ int ret;
+ struct i2c_msg msg = {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = count,
+ .buf = buf,
+ };
+
+ ret = __i2c_transfer(client-adapter, msg, 1);
+ return (ret == 1) ? count : ret;
+}
+
/* execute firmware command */
-static int si2168_cmd_execute(struct i2c_client *client, struct si2168_cmd
*cmd)
+static int si2168_cmd_execute_unlocked(struct i2c_client *client,
+ struct si2168_cmd *cmd)
{
- struct si2168_dev *dev = i2c_get_clientdata(client);
int ret;
unsigned long timeout;
- mutex_lock(dev-i2c_mutex);
-
if (cmd-wlen) {
/* write cmd and args for firmware */
- ret = i2c_master_send(client, cmd-args, cmd-wlen);
+ ret = si2168_i2c_master_send_unlocked(client, cmd-args,
+ cmd-wlen);
if (ret 0) {
- goto err_mutex_unlock;
+ goto err;
} else if (ret != cmd-wlen) {
ret = -EREMOTEIO;
- goto err_mutex_unlock;
+ goto err;
}
}
@@ -43,12 +73,13 @@ static int si2168_cmd_execute(struct i2c_client *client,
struct si2168_cmd *cmd)
#define TIMEOUT 70
timeout = jiffies + msecs_to_jiffies(TIMEOUT);
while (!time_after(jiffies, timeout)) {
- ret = i2c_master_recv(client, cmd-args, cmd-rlen);
+ ret = si2168_i2c_master_recv_unlocked(client, cmd-args,
+ cmd-rlen);
if (ret 0) {
- goto err_mutex_unlock;
+ goto err;
} else if (ret != cmd-rlen) {
ret = -EREMOTEIO;
- goto err_mutex_unlock;
+ goto err;
}
/* firmware ready? */
@@ -63,24 +94,32 @@ static int si2168_cmd_execute(struct i2c_client *client,
struct si2168_cmd *cmd)
/* error bit set? */
if ((cmd-args[0] 6) 0x01) {
ret = -EREMOTEIO;
- goto err_mutex_unlock;
+ goto err;
}
if (!((cmd-args[0] 7) 0x01)) {
ret = -ETIMEDOUT;
- goto err_mutex_unlock;
+ goto err;
}
}
- mutex_unlock(dev-i2c_mutex);
return 0;
-
-err_mutex_unlock:
- mutex_unlock(dev-i2c_mutex);
+err:
dev_dbg(client-dev, failed=%d\n, ret);
return ret;
}
+static int si2168_cmd_execute(struct i2c_client *client, struct si2168_cmd
*cmd)
+{
+ int ret;
+
+ i2c_lock_adapter(client-adapter);
+ ret = si2168_cmd_execute_unlocked(client, cmd);
+ i2c_unlock_adapter(client-adapter);
+
+ return ret;
+}
+
static int si2168_read_status(struct dvb_frontend *fe, fe_status_t *status)
{
struct i2c_client *client = fe-demodulator_priv;
@@ -569,60 +608,46 @@ static int si2168_get_tune_settings(struct dvb_frontend
*fe,
/*
* I2C gate logic
- *
[PATCH 1/2] [media] DocBook: some fixes for DVB FE open()
The changeset dc9ef7d11207 change the open() ioctl documentation to match the V4L2 open(). However, some cut-and-pasted stuff doesn't match what actually happens at the DVB core. So, fix the documentation entry to be more accurate with the DVB frontend open() specifics. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index c7fa3d8bff5c..9d8e95cd9694 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml @@ -61,7 +61,7 @@ specification is available at refentry id=frontend_f_open refmeta -refentrytitleopen()/refentrytitle +refentrytitleDVB frontend open()/refentrytitle manvol; /refmeta @@ -94,20 +94,19 @@ specification is available at varlistentry termparameterflags/parameter/term listitem - paraOpen flags. Access mode must be -constantO_RDWR/constant. This is just a technicality, input devices -still support only reading and output devices only writing./para - paraWhen the constantO_NONBLOCK/constant flag is -given, the read() function will return the EAGAIN; when no data is available, -otherwise these functions block until data becomes -available. Other flags have no effect./para + paraOpen flags. Access can either be + constantO_RDWR/constant or constantO_RDONLY/constant./para + paraMultiple opens are allowed with constantO_RDONLY/constant. In this mode, only query and read ioctls are allowed./para + paraOnly one open is allowed in constantO_RDWR/constant. In this mode, all ioctls are allowed./para + paraWhen the constantO_NONBLOCK/constant flag is given, the system calls may return EAGAIN; when no data is available or when the device driver is temporarily busy./para + paraOther flags have no effect./para /listitem /varlistentry /variablelist /refsect1 refsect1 titleDescription/title -paraThis system call opens a named frontend device (/dev/dvb/adapter0/frontend0) +paraThis system call opens a named frontend device (constant/dev/dvb/adapter?/frontend?/constant) for subsequent use. Usually the first thing to do after a successful open is to find out the frontend type with link linkend=FE_GET_INFOFE_GET_INFO/link./para paraThe device can be opened in read-only mode, which only allows monitoring of @@ -145,8 +144,7 @@ device./para varlistentry termerrorcodeEBUSY/errorcode/term listitem - paraThe driver does not support multiple opens and the -device is already in use./para + paraThe the device driver is already in use./para /listitem /varlistentry varlistentry @@ -177,13 +175,19 @@ files open./para system has been reached./para /listitem /varlistentry + varlistentry + termerrorcodeENODEV/errorcode/term + listitem + paraThe device got removed./para + /listitem + /varlistentry /variablelist /refsect1 /refentry refentry id=frontend_f_close refmeta -refentrytitleclose()/refentrytitle +refentrytitleDVB frontend close()/refentrytitle manvol; /refmeta -- 2.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/2] [media] DocBook: fix FE_SET_PROPERTY ioctl arguments
FE_SET_PROPERTY/FE_GET_PROPERTY actually expects a struct dtv_properties argument. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media/dvb/fe-get-property.xml b/Documentation/DocBook/media/dvb/fe-get-property.xml index 7d0bd78f5a24..53a170ed3bd1 100644 --- a/Documentation/DocBook/media/dvb/fe-get-property.xml +++ b/Documentation/DocBook/media/dvb/fe-get-property.xml @@ -17,7 +17,7 @@ funcdefint functionioctl/function/funcdef paramdefint parameterfd/parameter/paramdef paramdefint parameterrequest/parameter/paramdef - paramdefstruct dtv_property *parameterargp/parameter/paramdef + paramdefstruct dtv_properties *parameterargp/parameter/paramdef /funcprototype /funcsynopsis /refsynopsisdiv -- 2.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: [RFC] Export alignment requirements for buffers
Hi Hans, On Mon, Jun 01, 2015 at 01:02:26PM +0200, Hans Verkuil wrote: On 06/01/2015 12:44 PM, Sakari Ailus wrote: Hi Hans, Thanks for the RFC. On Mon, Jun 01, 2015 at 11:44:51AM +0200, Hans Verkuil wrote: One of the things that is really irritating is the fact that drivers that use contig-dma sometimes want to support USERPTR, allowing applications to pass pointers to the driver that point to physically contiguous memory that was somehow obtained, and that userspace has no way of knowing whether the driver has this requirement or not. A related issue is that, depending on the DMA engine, the user pointer might have some alignment requirements (page aligned, or at minimum 16 bytes aligned) that userspace has no way of knowing. The same alignment issue is present also for dma-buf. I propose to take one reserved field from struct v4l2_create_buffers and from struct v4l2_requestbuffers and change it to this: __u32 flags; #define V4L2_REQBUFS_FL_ALIGNMENT_MSK 0x3f How about V4L2_REQBUFS_FL_ALIGN_MASK instead? It's shorter, and that msk part looks odd to me. Hmm, how to do this. Currently it masks out 6 bits which form the power-of-two that determines the alignment. How about this: #define V4L2_REQBUFS_FL_ALIGN_EXP(flags) ((flags) 0x3f) #define V4L2_REQBUFS_FL_ALIGN_MASK(flags) ((1ULL (flags 0x3f)) - 1) That gives you both mask and the exponent. Better names are welcome :-) ALIGN_PWR? PWR2? ALIGN_AT_BIT? I think ALIGN_EXP and ALIGN_MASK are good. #define V4L2_REQBUFS_FL_PHYS_CONTIG(1 31) Where the alignment is a power of 2 (and if 0 the alignment is unknown). The max is 2^63, which should be enough for the foreseeable future :-) If the physically contiguous flag is set, then the buffer must be physically contiguous. Both only apply to userptr buffers. I guess saying this in documentation only is enough. I don't follow you. Perhaps there is some confusion here? The flags field is set by the driver, not by userspace. So PHYS_CONTIG applies to any type of buffer if the driver uses dma-contig. And the alignment is valid for all drivers as well. What I meant was that this is mostly relevant for userptr buffers, mmap buffers are allocated by the driver as well as dma-buf buffers are, so the user has no (or little?) use for this information on those buffer types. The approach looks good to me. dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless overridden by the driver) page aligned. dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the driver DMA implementation. Note: malloc will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. Ack. Many dma-sg drivers actually can handle physically contiguous memory since they're behind an IOMMU; the drivers can then set the flag if needed. All dma-sg drivers can handle phys contig memory since that's just one DMA descriptor. The flag is meant to say that the buffer *has* to be phys contig, not that it might be. So dma-sg drivers will not set it, since they don't have that requirement. I meant to say drivers using dma-contig, not dma-sg. -- 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: [RFC] Export alignment requirements for buffers
Hi Hans, On Monday 01 June 2015 11:44:51 Hans Verkuil wrote: One of the things that is really irritating is the fact that drivers that use contig-dma sometimes want to support USERPTR, allowing applications to pass pointers to the driver that point to physically contiguous memory that was somehow obtained, and that userspace has no way of knowing whether the driver has this requirement or not. A related issue is that, depending on the DMA engine, the user pointer might have some alignment requirements (page aligned, or at minimum 16 bytes aligned) that userspace has no way of knowing. The same alignment issue is present also for dma-buf. Doesn't the first issue also apply to DMABUF ? As you already know, I'm not a big fan of USERPTR when used for sharing buffers between devices. DMABUF is a much better choice there. USERPTR can still be helpful for other use cases though. One of them that comes to my mind is to capturing directly buffers allocated by a software codec (or another similar userspace library) that doesn't support externally allocated memory (although the core issue there would be the library design). Anyway, the problem of conveying memory constraints is identical in the DMABUF case, so a solution is needed. I propose to take one reserved field from struct v4l2_create_buffers and from struct v4l2_requestbuffers and change it to this: __u32 flags; #define V4L2_REQBUFS_FL_ALIGNMENT_MSK 0x3f #define V4L2_REQBUFS_FL_PHYS_CONTIG (1 31) Where the alignment is a power of 2 (and if 0 the alignment is unknown). The max is 2^63, which should be enough for the foreseeable future :-) If the physically contiguous flag is set, then the buffer must be physically contiguous. These flags can be set for every vb2 dma implementation: dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless overridden by the driver) page aligned. dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the driver DMA implementation. Note: malloc will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. The flags field can be extended with things like OPAQUE if the buffers cannot be mmapped (since they are in protected memory). Comments? Alternative solutions? The question of conveying memory constraints has been raised several times in the past, without any solutions being merged. The work has been revived recently, see http://lists.freedesktop.org/archives/dri-devel/2015-February/076862.html for instance. Even if the API proposed here is specific to V4L2, and even if the patch set I linked to addresses a different problem, I believe it would be wise to widen the audience to make sure the solutions we come up with are at least aligned between subsystems. I've thus CC'ed Sumit to this e-mail as a start. -- Regards, Laurent Pinchart -- 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 2/2] sound/usb: Update ALSA driver to use media controller API
On 05/27/2015 09:24 AM, Takashi Iwai wrote:
At Fri, 8 May 2015 13:31:31 -0600,
Shuah Khan wrote:
Change ALSA driver to use media controller API to share tuner
with DVB and V4L2 drivers that control AU0828 media device.
Media device is created based on a newly added field value
in the struct snd_usb_audio_quirk. Using this approach, the
media controller API usage can be added for a specific device.
In this patch, media controller API is enabled for AU0828 hw.
snd_usb_create_quirk() will check this new field, if set will
create a media device using media_device_get_dr() interface.
media_device_get_dr() will allocate a new media device device
resource or return an existing one if it exists. During probe,
media usb driver could have created the media device. It will
then register the media device if it isn't already registered.
Media device unregister is done from usb_audio_disconnect().
New fields to add support for media entity and links are
added to struct snd_usb_substream. A new media entity for
ALSA and a link from tuner entity to the newly registered
ALSA entity are created from snd_usb_init_substream() and
removed from free_substream(). The state is kept to indicate
if tuner is linked. This is to account for case when tuner
entity doesn't exist. Media pipeline gets started to mark
the tuner busy from snd_usb_substream_capture_trigger in
response to SNDRV_PCM_TRIGGER_START and pipeline is stopped
in response to SNDRV_PCM_TRIGGER_STOP. snd_usb_pcm_close()
stops pipeline to cover the case when SNDRV_PCM_TRIGGER_STOP
isn't issued. Pipeline start and stop are done only when
tuner_linked is set.
Tested with and without CONFIG_MEDIA_CONTROLLER enabled.
Tested tuner entity doesn't exist case as au0828 v4l2
driver is the one that will create the tuner when it gets
updated to use media controller API.
I guess it gets broken when CONFIG_MEDIA_SUPPORT=m while
CONFIG_SND*=y. So, it should be compiled in only when the media
support is built-in or both sound and media are module, i.e.
#ifdef CONFIG_MEDIA_CONTROLLER
#if defined(CONFIG_MEDIA_SUPPORT) || \
(defined(CONFIG_MEDIA_SUPPORT_MODULE) defined(MODULE))
#define I_CAN_USE_MEDIA_CONTROLLER
#endif
#endif
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
sound/usb/card.c | 5 +
sound/usb/card.h | 12 ++
sound/usb/pcm.c | 23 ++-
sound/usb/quirks-table.h | 1 +
sound/usb/quirks.c | 58
+++-
sound/usb/quirks.h | 6 +
sound/usb/stream.c | 40 +
sound/usb/usbaudio.h | 1 +
8 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 1fab977..587fc24 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -621,6 +621,11 @@ static void usb_audio_disconnect(struct usb_interface
*intf)
}
}
+/* Nice to check quirk quirk-media_device
+ * need some special handlings. Doesn't look like
+ * we have access to quirk here */
+media_device_delete(intf);
This should be called once, so better in if (!was_shutdown) block, I
guess.
Moved it under if (!was_shutdown) block.
Apart from that, yes, a good way to call an optional destructor for
quirks would be better.
Maybe something to look into as an enhancement for quirk handling.
chip-num_interfaces--;
if (chip-num_interfaces = 0) {
usb_chip[chip-index] = NULL;
diff --git a/sound/usb/card.h b/sound/usb/card.h
index ef580b4..477bdcd 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -1,6 +1,11 @@
#ifndef __USBAUDIO_CARD_H
#define __USBAUDIO_CARD_H
+#ifdef CONFIG_MEDIA_CONTROLLER
+#include media/media-device.h
+#include media/media-entity.h
+#endif
+
#define MAX_NR_RATES1024
#define MAX_PACKS 6 /* per URB */
#define MAX_PACKS_HS(MAX_PACKS * 8) /* in high speed mode */
@@ -155,6 +160,13 @@ struct snd_usb_substream {
} dsd_dop;
bool trigger_tstamp_pending_update; /* trigger timestamp being updated
from initial estimate */
+#ifdef CONFIG_MEDIA_CONTROLLER
+struct media_device *media_dev;
+struct media_entity media_entity;
+struct media_pad media_pads;
+struct media_pipeline media_pipe;
+bool tuner_linked;
+#endif
Maybe a slightly better idea is to allocate these in a new record and
stores the pointer in stream-media_ctl or whatever new field.
Then, a check like
if (subs-tuner_linked)
can be replaced with
if (subs-media_ctl)
The whole media-specific stuff can be gathered in a single file,
e.g. sound/usb/media.c, and there you can define the struct.
};
struct snd_usb_stream {
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index b4ef410..c2a40a9 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -1225,6 +1225,10 @@ static int
Re: [RFC] Export alignment requirements for buffers
On 06/01/2015 11:44 AM, Hans Verkuil wrote: One of the things that is really irritating is the fact that drivers that use contig-dma sometimes want to support USERPTR, allowing applications to pass pointers to the driver that point to physically contiguous memory that was somehow obtained, and that userspace has no way of knowing whether the driver has this requirement or not. A related issue is that, depending on the DMA engine, the user pointer might have some alignment requirements (page aligned, or at minimum 16 bytes aligned) that userspace has no way of knowing. The same alignment issue is present also for dma-buf. I propose to take one reserved field from struct v4l2_create_buffers and from struct v4l2_requestbuffers and change it to this: __u32 flags; #define V4L2_REQBUFS_FL_ALIGNMENT_MSK 0x3f #define V4L2_REQBUFS_FL_PHYS_CONTIG (1 31) Where the alignment is a power of 2 (and if 0 the alignment is unknown). The max is 2^63, which should be enough for the foreseeable future :-) If the physically contiguous flag is set, then the buffer must be physically contiguous. These flags can be set for every vb2 dma implementation: dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless overridden by the driver) page aligned. dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the driver DMA implementation. Note: malloc will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS. The flags field can be extended with things like OPAQUE if the buffers cannot be mmapped (since they are in protected memory). Comments? Alternative solutions? I realized that we need this information for each plane. v4l2_requestbuffers does not have enough room for that so for now I will do a test implementation using v4l2_create_buffers only. Perhaps later requestbuffers can just expose the 'worst case' alignment requirements which would be fine in most (and currently AFAIK all) cases. Regards, Hans -- 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: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
On Mon, Jun 01, 2015 at 06:22:41PM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 29 May 2015 08:34 PM, Felipe Balbi wrote: Hi, On Fri, May 29, 2015 at 05:04:38PM +0530, Kishon Vijay Abraham I wrote: Hi Felipe, On Wednesday 27 May 2015 12:09 AM, Felipe Balbi wrote: On Tue, May 26, 2015 at 11:37:17AM -0700, Arun Ramamurthy wrote: Hi On 15-05-26 07:19 AM, Felipe Balbi wrote: HI, On Mon, May 25, 2015 at 02:19:58PM -0700, Arun Ramamurthy wrote: On 15-05-14 05:52 PM, Felipe Balbi wrote: Hi, On Wed, Apr 22, 2015 at 04:04:10PM -0700, Arun Ramamurthy wrote: Most of the phy providers use select to enable GENERIC_PHY. Since select is only recommended when the config is not visible, GENERIC_PHY is changed an invisible option. To maintain consistency, all phy providers are changed to select GENERIC_PHY and all non-phy drivers use depends on when the phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic dependency, so it is left as select. Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com --- drivers/ata/Kconfig | 1 - drivers/media/platform/exynos4-is/Kconfig | 2 +- drivers/phy/Kconfig | 4 ++-- drivers/usb/host/Kconfig | 4 ++-- drivers/video/fbdev/exynos/Kconfig| 2 +- 5 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 5f60155..6d2e881 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -301,7 +301,6 @@ config SATA_MV tristate Marvell SATA support depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \ ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST - select GENERIC_PHY help This option enables support for the Marvell Serial ATA family. Currently supports 88SX[56]0[48][01] PCI(-X) chips, diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index b7b2e47..b6f3eaa 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC config VIDEO_S5P_MIPI_CSIS tristate S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver depends on REGULATOR - select GENERIC_PHY + depends on GENERIC_PHY help This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2 receiver (MIPI-CSIS) devices. diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 2962de2..edecdb1 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -5,7 +5,7 @@ menu PHY Subsystem config GENERIC_PHY - bool PHY Core + bool help Generic PHY support. @@ -72,7 +72,7 @@ config PHY_MIPHY365X config PHY_RCAR_GEN2 tristate Renesas R-Car generation 2 USB PHY driver depends on ARCH_SHMOBILE - depends on GENERIC_PHY + select GENERIC_PHY so some you changed from depends to select... help Support for USB PHY found on Renesas R-Car generation 2 SoCs. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5ad60e4..e2197e2 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR config USB_EHCI_HCD_STI tristate Support for ST STiHxxx on-chip EHCI USB controller depends on ARCH_STI OF - select GENERIC_PHY + depends on GENERIC_PHY while others you changed from select to depends. NAK. Felipe, I dont understand your concern, could you please explain it more detail? The logic behind the changes is that in cases where there was an explicit dependency, I changed it to depends on and in other cases I changed it to selects. Thanks Since GENERIC_PHY is visible from Kconfig, it would be much nicer to avoid select altogether. Felipe, after discussion with the maintainers, I have made GENERIC_PHY an invisible option as part of this change. Thanks Then, if the option is invisible, how can you depend on it ? It can never be selected by poking around in Kconfig. IMO, it's counterintuitive that you need to enable a PHY driver before you can see your EHCI/OHCI/whatever controller listed in Kconfig. If the controller requires PHY for it to be functional, it is okay to make the controller depend on PHY IMHO. We want to try and minimize the usage of 'select' wherever possible or else 'select' is the most intuitive way. The other option is just to leave the 'depends on' and let the user select PHY. How can you 'depend' on something that the user can't select by navigating through Kconfig ? hmm... Actually it's selected when the user selects the PHY driver. that's my point, don't you think it's a little counter-intuitive ? Maybe we should directly depend on the PHY driver instead of Generic PHY? maybe... But then what do you do when you have different boards using different PHYs ? --
[PATCH] [media] radio-si470x-i2c: Pass the IRQF_ONESHOT flag
Since commit 1c6c69525b40 (genirq: Reject bogus threaded irq requests)
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 2a497c8..49fe845 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -421,7 +421,8 @@ static int si470x_i2c_probe(struct i2c_client *client,
init_waitqueue_head(radio-read_queue);
retval = request_threaded_irq(client-irq, NULL, si470x_i2c_interrupt,
- IRQF_TRIGGER_FALLING, DRIVER_NAME, radio);
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT, DRIVER_NAME,
+ radio);
if (retval) {
dev_err(client-dev, Failed to register interrupt\n);
goto err_rds;
--
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
Re: [PATCH v3] [media] dvb-frontend: Replace timeval with ktime_t
On Sunday 31 May 2015 12:47:06 Tina Ruchandani wrote: struct timeval uses a 32-bit seconds representation which will overflow in the year 2038 and beyond. This patch replaces the usage of struct timeval with ktime_t which is a 64-bit timestamp and is year 2038 safe. This patch is part of a larger attempt to remove all instances of 32-bit timekeeping variables (timeval, timespec, time_t) which are not year 2038 safe, from the kernel. Signed-off-by: Tina Ruchandani ruchandani.t...@gmail.com Suggested-by: Arnd Bergmann ar...@arndb.de Reviewed-by: Arnd Bergmann a...@arndb.de -- 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 v9 1/8] Documentation: leds: Add description of v4l2-flash sub-device
Hi Jacek, On Mon, May 25, 2015 at 05:13:56PM +0200, Jacek Anaszewski wrote: +On remove the v4l2_flash_release function has to be called, which takes one +argument - struct v4l2_flash pointer returned previously by v4l2_flash_init. You might want to add this function can be safely called with NULL or error pointer argument. Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- 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 v9 3/8] leds: max77693: add support for V4L2 Flash sub-device
Hi Jacek, On Mon, May 25, 2015 at 05:13:58PM +0200, Jacek Anaszewski wrote: Add support for V4L2 Flash sub-device to the max77693 LED Flash class driver. The support allows for V4L2 Flash sub-device to take the control of the LED Flash class device. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Sakari Ailus sakari.ai...@iki.fi For this and the rest in the set: Acked-by: Sakari Ailus sakari.ai...@linux.intel.com Many thanks to you for your efforts on this! It's great to see it in this state after all the review rounds. :-) -- 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 v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek, On Mon, May 25, 2015 at 05:13:57PM +0200, Jacek Anaszewski wrote: This patch adds helper functions for registering/unregistering LED Flash class devices as V4L2 sub-devices. The functions should be called from the LED subsystem device driver. In case the support for V4L2 Flash sub-devices is disabled in the kernel config the functions' empty versions will be used. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com Thanks for adding indicator support! Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- 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 v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
Hi Sylwester, On Mon, May 25, 2015 at 02:00:33PM +0200, Sylwester Nawrocki wrote: Hi, On 23/05/15 14:03, Sakari Ailus wrote: On Thu, May 21, 2015 at 03:28:40PM +0200, Sylwester Nawrocki wrote: flash-leds = flash_xx image_sensor_x, ...; One more matter to consider: xenon flash devices. How about samsung,camera-flashes (and ti,camera-flashes)? After pondering this awhile, I'm ok with removing the vendor prefix as well. Let me know what you think. I thought about it a bit more and I have some doubts about semantics as above. I'm fine with 'camera-flashes' as far as name is concerned. Perhaps we should put only phandles to leds or xenon flash devices in the 'camera-flashes' property. I think it would be more future proof in case there is more nodes needed to describe the camera flash (or a camera module) than the above two. And phandles to corresponding image sensor device nodes would be put in a separate property. camera-flashes = flash_xx, ... camera-flash-masters = image_sensor_x, ... Then pairs at same index would describe a single flash, 0 would indicate a null entry if needed. Similarly we could create properties for other sub-devices of a camera module, like lenses, etc. This arrangement would be advantageous compared to a single property when adding modules (or lenses) to the equation, and probably more future proof than samsung,camera-flashes / ti,camera-flashes I believe. I'm also ok with keeping it as-is though. -- 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] Improve Y16 color setup
Hello Hans On Mon, Jun 1, 2015 at 9:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: Currently the colors for the Y16 and Y16_BE pixelformats are in the range 0x-0xff00. So pure white (0x) is never created. Improve this by using the same byte for both LSB and MSB so the full range is achieved. If someone uses vivid as reference (I sometimes do), this could lead to incorrect implementations. If the user don't implement the endianess right he will never notice. I have carried out an endianness bug for some months, until gstreamer was showing funny ;) images. If the problem is that you want to reach saturation, I would rather setting the lsb to 0xff all the time. (i.e. going from 0x00ff to 0x). If we want saturation and zero, we could set the lsb to val?0xff:0; Regards! -- 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 v1.1 1/5] v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it
Hi Sakari,
Thank you for the patch. Please see below for one small comment.
On Monday 01 June 2015 01:24:39 Sakari Ailus wrote:
V4L2 async sub-devices are currently matched (OF case) based on the struct
device_node pointer in struct device. LED devices may have more than one
LED, and in that case the OF node to match is not directly the device's
node, but a LED's node.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
since v1:
- Move conditional setting of struct v4l2_subdev.of_node from
v4l2_device_register_subdev() to v4l2_async_register_subdev.
- Remove the check for NULL struct v4l2_subdev.of_node from match_of() as
it's no longer needed.
- Unconditionally state in the struct v4l2_subdev.of_node field comment that
the field contains (a pointer to) the sub-device's of_node.
drivers/media/v4l2-core/v4l2-async.c | 34 +
include/media/v4l2-subdev.h | 2 ++
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c index 85a6a34..b0badac 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
[snip]
@@ -266,6 +273,9 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
{
struct v4l2_async_notifier *notifier;
+ if (!sd-of_node sd-dev)
+ sd-of_node = sd-dev-of_node;
+
I think we don't need to take a reference to of_node here, as we assume
there's a reference to dev through the whole life of the subdev, and dev
should have a reference to of_node, but could you double-check ?
If that's indeed not a problem,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
(and maybe a small comment in the source code would be useful)
mutex_lock(list_lock);
INIT_LIST_HEAD(sd-async_list);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73..8a17c24 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -603,6 +603,8 @@ struct v4l2_subdev {
struct video_device *devnode;
/* pointer to the physical device, if any */
struct device *dev;
+ /* A device_node of the subdev, usually the same as dev-of_node. */
+ struct device_node *of_node;
/* Links this subdev to a global subdev_list or @notifier-done list. */
struct list_head async_list;
/* Pointer to respective struct v4l2_async_subdev. */
--
Regards,
Laurent Pinchart
--
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
[RFC] V4L2 codecs in user space
Hello All, I would like to ask for some comments about a plan to use user space video codecs through the V4L interface. I am thinking of a situation similar to the one described on the linuxtv.org wiki at http://www.linuxtv.org/wiki/index.php/V4L2_Userspace_Library The basic premise is to use a FUSE-like driver to connect the standard V4L2 api to a user space daemon that will work as an mem-to-mem driver for decoding/encoding, compression/decompression and the like. This allows for codecs that are either partially or wholly implemented in user space to be exposed through the standard kernel interface. Before I dive in to implementing this I was hoping to get some comments regarding the following: 1. I haven't been able to find any implementation of the design described in the wiki page. Would anyone know if I have missed it? Does this exist somewhere, even in part? It seems like that might be a good place to start if possible. 2. I think that this could be implemented as either an extension to FUSE (like CUSE) or as a V4L2 device driver (that forwards requests through the FUSE API). I think that the V4L2 device driver would be sufficient, but would the fact that there is no specific hardware tied to it be an issue? Should it instead be presented as a more generic device? 3. And of course anything else that comes to mind. Thank you, Damian -- 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: WARNINGS
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: Tue Jun 2 04:00:20 CEST 2015 git branch: test git hash: c1c3c85ddf60a6d97c122d57d385b4929fcec4b3 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS 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.32.27-i686: OK linux-2.6.33.7-i686: 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: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: 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: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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 02/35] DocBook: add a note about the ALSA API
On Thu, 28 May 2015 18:49:05 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: + paraIt should also be noticed that a media device may also have audio + components, like mixers, PCM capture, PCM playback, etc, with + are controlled via ALSA API./para How about s/noticed/noted/ and s/with/which/ ? jon -- 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 15/35] DocBook: Improve the description of the properties API
A few minor corrections here. jon On Thu, 28 May 2015 18:49:18 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Make the text clearer about what the properties API does. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 28ea62067af6..c10ed0636d02 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -1,8 +1,35 @@ -section id=FE_GET_SET_PROPERTY -titleconstantFE_GET_PROPERTY/FE_SET_PROPERTY/constant/title -paraThis section describes the DVB version 5 extension of the DVB-API, also -called S2API, as this API were added to provide support for DVB-S2. It was -designed to be able to replace the old frontend API. Yet, the DISEQC and +section id=frontend-properties +titleDVB Frontend properties/title +paraTuning into a Digital TV physical channel and starting decoding it +requires to change a set of parameters, in order to control the requires *changing* as set... +tuner, the demodulator, the Linear Low-noise Amplifier (LNA) and to set the +antena subsystem via Satellite Equipment Control (SEC), on satellital antenna +systems. The actual parameters are specific to each particular digital +TV standards, and may change as the digital TV specs evolutes./para standard (no s). s/evolutes/evolves/ +paraIn the past, the strategy used were to have an union with the parameters s/were to have an/was to have a/ +needed to tune for DVB-S, DVB-C, DVB-T and ATSC delivery systems grouped +there. The problem is that, as the second generation standards appeared, +those structs were not big enough to contain the additional parameters. +Also, the union didn't have any space left to be expanded without breaking +userspace. So, the decision was to deprecate the legacy union/struct based +approach, in favor of a properties set approach./para +paraBy using a properties set, it is now possible to extend and support any +digital TV without needing to redesign the API/para +paraExample: with the properties based approach, in order to set the tuner +to a DVB-C channel at 651 kHz, modulated with 256-QAM, FEC 3/4 and symbol +rate of 5.217 Mbauds, those properties should be sent to +link linkend=FE_GET_PROPERTYconstantFE_SET_PROPERTY/constant/link ioctl:/para +itemizedlist + listitemDTV_FREQUENCY = 65100/listitem + listitemDTV_MODULATION = QAM_256/listitem + listitemDTV_INVERSION = INVERSION_AUTO/listitem + listitemDTV_SYMBOL_RATE = 5217000/listitem + listitemDTV_INNER_FEC = FEC_3_4/listitem + listitemDTV_TUNE/listitem +/itemizedlist +paraNOTE: This section describes the DVB version 5 extension of the DVB-API, +also called S2API, as this API were added to provide support for DVB-S2. It +was designed to be able to replace the old frontend API. Yet, the DISEQC and the capability ioctls weren't implemented yet via the new way./para paraThe typical usage for the constantFE_GET_PROPERTY/FE_SET_PROPERTY/constant API is to replace the ioctl's were the link linkend=dvb-frontend-parameters jon -- 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/35] Improve DVB frontend API documentation
On Thu, 28 May 2015 18:49:03 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: This is the first series of patches that will improve the DVB documentation. I've done a *quick* pass over these and sent a few comments, but they are all on the trivial-detail side of things. Looks good in general. Would you like me to carry these in the docs tree, or will you sent them up yourself? Feel free to add my ack if you want in the latter case. jon -- 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 04/35] DocBook: fix emphasis at the DVB documentation
On Thu, 28 May 2015 18:49:07 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Currently, it is using 'role=tt', but this is not defined at the DocBook 4.5 spec. The net result is that no emphasis happens. So, replace them to bold emphasis. Nit: I suspect the intent of the emphasis here was to get the code in a monospace font, which bold is unlikely to do. Isn't there a role=code or something useful like that to use? I'd have to go look. jon -- 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 32/35] DocBook: Provide a high-level description for DVB frontend
On Thu, 28 May 2015 18:49:35 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: +Please notice that several statistics require the demodulator to be fully +locked (e. g. with FE_HAS_LOCK bit set). See s/notice/note/ jon -- 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
