Re: [RFC/PATCH v6 0/4] Multi Format Codec 5.1 driver for S5PC110 SoC
On Monday, January 17, 2011 08:35:21 Kamil Debski wrote: > Hi Hans, > > > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > > Hi Kamil, > > > > I still need to review this carefully since this is the first codec > > driver. > > I had hoped to do this during the weekend, but I didn't manage it. I > > hope I > > can get to it on Friday. > > This would be great. > > > One thing I noticed: you aren't using the control framework in this > > driver. > > Please switch to that. From now on I will NACK any new driver that is > > not > > using that framework. I'm in the process of converting all existing > > drivers > > to it, and I don't want to have to fix new drivers as well :-) > > > > Documentation is in Documentation/video4linux/v4l2-controls.txt. > > > > I am aware of that. I think my reply to one of your previous comments might > have got lost in your inbox. > > I have doubts about the point of using the control framework in my case. > I agree with you that for the majority of drivers it will be very useful. > In case of MFC or mem2mem FIMC - those two drivers use per file handle > contexts and that's the thing that stops me from using your framework. > > If I understand the control framework correctly, there is no support for > such use case. When S_CTRL is run on an MFC driver then the value passed > to the driver is stored in s5p_mfc_ctx structure instead of writing this to > hardware directly. This value is then used, when it is necessary to setup > hardware. For example before running codec initialization for that context. > > In case of the control framework, the I could implement my .s_ctrl > callback which sets the appropriate field in s5p_mfc_ctx structure. > The thing I don't like about this is the redundancy of storing the control > value. In the one instance scenario it is stored in the driver in > s5p_mfc_ctx > and in the control fw. In multiple instance scenario the values in > s5p_mfc_ctx > and in the control fw will be different. I know that there are volatile > controls in the framework, but in this case all controls would have to be > volatile. > > Correct me if I am wrong, but I don't see that the control framework is for > mem2mem drivers that can have multiple contexts. Again, I agree with you > that it is generally a good idea, but not for every driver. I am open to > discuss this use case with you - maybe some functionality could be added > to the control framework? Normally the struct v4l2_ctrl_handler is put in either the top-level device structure (a global handler) or it is per-device node. But there is nothing preventing you from doing this per-filehandle. However, a small change will be needed to the v4l framework since right now it assumes that struct video_device has a pointer to the corresponding control handler. This should be moved down to struct v4l2_fh. So struct v4l2_fh should get a pointer to a v4l2_ctrl_handler. If not set, then it will use any value set in video_device. And v4l2-ioctl.c should use the struct v4l2_fh control handler pointer if available. These changes are very minor and then you can use per-filehandle controls. The reason why I want drivers to use this is that it is next to impossible to write full-featured and correct control handling code without it. I've been implementing control API tests to v4l2-compliance and it is depressing to see how few drivers actually do the right thing. Regards, Hans > > Best wishes, > -- > Kamil Debski > Linux Platform Group > Samsung Poland R&D Center > > > > > On Friday, January 07, 2011 17:25:30 Kamil Debski wrote: > > > Hello, > > > > > > This is the sixth version of the MFC 5.1 driver, decoding part. The > > suggestions > > > and comments from the group members have been very helpful. > > > > > > I would be grateful for your comments. Original cover letter ant > > detailed change > > > log has been attached below. > > > > > > Best regards, > > > Kamil Debski > > > > -- > 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 > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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/PATCH v6 0/4] Multi Format Codec 5.1 driver for S5PC110 SoC
Hi Hans, > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Hi Kamil, > > I still need to review this carefully since this is the first codec > driver. > I had hoped to do this during the weekend, but I didn't manage it. I > hope I > can get to it on Friday. This would be great. > One thing I noticed: you aren't using the control framework in this > driver. > Please switch to that. From now on I will NACK any new driver that is > not > using that framework. I'm in the process of converting all existing > drivers > to it, and I don't want to have to fix new drivers as well :-) > > Documentation is in Documentation/video4linux/v4l2-controls.txt. > I am aware of that. I think my reply to one of your previous comments might have got lost in your inbox. I have doubts about the point of using the control framework in my case. I agree with you that for the majority of drivers it will be very useful. In case of MFC or mem2mem FIMC - those two drivers use per file handle contexts and that's the thing that stops me from using your framework. If I understand the control framework correctly, there is no support for such use case. When S_CTRL is run on an MFC driver then the value passed to the driver is stored in s5p_mfc_ctx structure instead of writing this to hardware directly. This value is then used, when it is necessary to setup hardware. For example before running codec initialization for that context. In case of the control framework, the I could implement my .s_ctrl callback which sets the appropriate field in s5p_mfc_ctx structure. The thing I don't like about this is the redundancy of storing the control value. In the one instance scenario it is stored in the driver in s5p_mfc_ctx and in the control fw. In multiple instance scenario the values in s5p_mfc_ctx and in the control fw will be different. I know that there are volatile controls in the framework, but in this case all controls would have to be volatile. Correct me if I am wrong, but I don't see that the control framework is for mem2mem drivers that can have multiple contexts. Again, I agree with you that it is generally a good idea, but not for every driver. I am open to discuss this use case with you - maybe some functionality could be added to the control framework? Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland R&D Center > > On Friday, January 07, 2011 17:25:30 Kamil Debski wrote: > > Hello, > > > > This is the sixth version of the MFC 5.1 driver, decoding part. The > suggestions > > and comments from the group members have been very helpful. > > > > I would be grateful for your comments. Original cover letter ant > detailed change > > log has been attached below. > > > > Best regards, > > Kamil Debski -- 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/PATCH v6 0/4] Multi Format Codec 5.1 driver for S5PC110 SoC
Hi Kamil, I still need to review this carefully since this is the first codec driver. I had hoped to do this during the weekend, but I didn't manage it. I hope I can get to it on Friday. One thing I noticed: you aren't using the control framework in this driver. Please switch to that. From now on I will NACK any new driver that is not using that framework. I'm in the process of converting all existing drivers to it, and I don't want to have to fix new drivers as well :-) Documentation is in Documentation/video4linux/v4l2-controls.txt. Regards, Hans On Friday, January 07, 2011 17:25:30 Kamil Debski wrote: > Hello, > > This is the sixth version of the MFC 5.1 driver, decoding part. The > suggestions > and comments from the group members have been very helpful. > > I would be grateful for your comments. Original cover letter ant detailed > change > log has been attached below. > > Best regards, > Kamil Debski > > * Changelog: > > == > Changes since v5 > == > > 1) Changes suggested by Hans Verkuil: > - small change in videodev2.h - corrected control offsets > - made the code more readable by simplifying if statements and using temporary > pointers > - mfc_mutex is now included in s5p_mfc_dev structure > - after discussion with Peter Oh modification of fourcc defintions > (replaced DX52 and DX53 with DX50) > > 2) Changes suggested by JongHun Han: > - comsmetic changed of defines in regs-mfc5.h > - in buffers that have no width adn height, such as the buffer for compressed > stream, those values are set to 0 instead of 1 > - remove redundant pointer to MFC registers > - change name of the union in s5p_mfc_buf from paddr to cookie > - removed global variable (struct s5p_mfc_dev *dev) and moved to use > video_drvdata > > 3) Other changes: > - added check for values returned after parsing header - in rare > circumstances MFC > hw returned 0x0 as image size and this could cause problems > > == > Changes since v4 > == > > 1) Changes suggested by Kukjin Kim from: > - removed comment arch/arm/mach-s5pv210/include/mach/map.h > - changed device name to s5p-mfc (removed "5", MFC version number) > also removed the version number from the name of MFC device file > - added GPL license to arch/arm/plat-s5p/dev-mfc.c > - removed unused include file from dev-mfc.c and unnecessary comments > > 2) Cache handling improvement: > - changed cache handling to use dma_map_single and dma_unmap_single > > == > Changes since v3 > == > > 1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski) > - s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions > have been merged > - queue initialization has been adapted to the new API > - use of the allocator memops has been changed, now there are single > memops for all the allocator contexts > > 2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions > - parts of the s5p_mfc_try_run function have been moved to separate > functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames, > s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst > s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers) > - s5p_mfc_handle_frame_int has been split to the following functions: > s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new > and s5p_mfc_handle_frame to handle different cases > > 3) Remove remaining magic numbers and tidy up comments > > == > Changes since v2 > == > > 1) Update to newest videobuf2 API > This is the major change from v2. The videobuf2 API will hopefully have no > more > major API changes. Buffer initialization has been moved from buf_prepare > callback to buf_init to simplify the process. Locking mechanism has been > modified to the requirements of new videobuf2 version. > 2) Code cleanup > Removed more magic contants and replaced them with appropriate defines. > Changed > code to use unlocked_ioctl instead of ioctl in v4l2 file ops. > 3) Allocators > All internal buffer allocations are done using the selected vb2 allocator, > instead of using CMA functions directly. > > == > Changes since v1 > == > > 1) Cleanup accoridng to Peter Oh suggestions on the mailing list (Thanks). > > * Original cover letter: > > == > Introduction > == > > The purpose of this RFC is to discuss the driver for a hw video codec > embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to > handle video decoding of in a range of formats. > > So far no hardware codec was supported in V4L2 and this would be the > first one. I guess there are more similar device that would benefit from > a V4L2 unified interface. I suggest a separate control class for codec > devices - V4L2_CTRL_CLASS_CODEC. > > Internally the driver uses videobuf2 framework and CMA memory allocator. > I am aware that those have not yet been merge
Re: How to set global alpha to V4L2_BUF_TYPE_CAPTURE ?
On Monday, January 17, 2011 04:44:54 Jonghun Han wrote: > > Hello, > > How to set global alpha to V4L2_BUF_TYPE_CAPTURE ? > > Samsung SoC S5PC210 has Camera interface and Video post processor named FIMC > which can set the alpha value to V4L2_BUF_TYPE_CAPTURE. > For example during color space conversion from YUV422 to ARGB, > FIMC can set the alpha value to V4L2_BUF_TYPE_CAPTURE. > > I tried to find an available command to set it but I couldn't found it. That's right, there isn't. > But there is fmt.win.global_alpha for Video Overlay Interface. > So in my opinion VIDIOC_S_FMT is also suitable for V4L2_BUF_TYPE_CAPTURE*. > How about using fmt.pix.priv in struct v4l2_format > and fmt.pix_mp.reserved[0] in struct v4l2_format ? Not a good idea. This is really ideal for a control. We already have a somewhat similar control in the form of V4L2_CID_BG_COLOR. It's perfectly reasonable to add a V4L2_CID_ALPHA_COLOR (or something similar) where you set this up. The little available space in the format structs is too precious to use for something trivial like this :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
I don't see the need to do DQBUF on the source buffer that has the
I-frame with changed resolution. I think that one could notify the
application by setting size=0 on the CAPTURE buffer. So the OUTPUT
buffer would not be dequeued. It would be dequeued after it has
been decoded. Do you think anything is wrong with this approach?
I really think that copying the source buffer contents is unnecessary.
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center
> -Original Message-
> From: Jaeryul Oh [mailto:jaeryul...@samsung.com]
> Sent: 14 January 2011 19:21
> To: 'Jonghun Han'; 'Kamil Debski'; linux-media@vger.kernel.org; linux-
> samsung-...@vger.kernel.org
> Cc: 'Marek Szyprowski'; pa...@osciak.com; kyungmin.p...@samsung.com;
> kgene@samsung.com
> Subject: RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
>
> I added my comments.
> I guess that Kamil's way could be possible to run seq. of dynamic
> resolution
> change.
>
> > -Original Message-
> > From: Jonghun Han [mailto:jonghun@samsung.com]
> > Sent: Friday, January 14, 2011 6:45 PM
> > To: 'Kamil Debski'; linux-media@vger.kernel.org; linux-samsung-
> > s...@vger.kernel.org
> > Cc: 'Marek Szyprowski'; pa...@osciak.com; kyungmin.p...@samsung.com;
> > jaeryul...@samsung.com; kgene@samsung.com
> > Subject: RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
> >
> >
> > Hi,
> >
> > I was confused the source and destination.
> > I agree with you mostly.
> >
> > In my opinion, the way how to notify the resolution change is return
> value
> > of the DQBUF.
> > But if we use DQBUF, there are some problem as below.
> >
> > DQBUF means that the buffer has been operated already and application
> will
> > have the buffer's right.
> >
> > Although application new QBUF destination buffers after changing
> > destination(CAPTURE),
> > driver cannot re-decode the I-frame which has the resolution change
> > information
> > because the I-frame has been dequeued already.
> > If application re-QBUF the buffer, the buffer sequence will be out of
> > order
> > as below.
> > Original: I -> B -> B .
> > Out of order: missed -> B -> B -> I .
> >
> > How do you think about the following sequence.
> >
> > 1. getting the resolution change from the MFC H/W
> >
> > 2. copy the buffer to driver's internal memory.
> >
> > 3. send the result with DQBUF
> >
> > 4. changing destination buffers by application
> >
> > 5. QBUF for new destination buffers
> >
> > 6. in the first vb2_try_schedule
> > re-decode the driver's internal buffer instead of the B frame.
> >
> > 7. in the next vb2_try_schedule
> > decode the B frame in order.
> >
> > I also welcome your comments.
>
> In the blocking sequence, blocking will be done in DQBUF.
> 1. QBUF done for I1 frame with hdr(first buf, res. chd)
>: Copy I1 frame in the driver
> 2. DQBUF done for I1 frame
> 3. QBUF P2,P3,P4 frame, but it should NOT be DEQUED which means
> Qbufed p2,p3,p4 is not executed
>: P4(third buf) -> P3(second buf) -> P2 frame(first buf)
> 4. While waiting for DEQUE about P2, copied I1 frame is executed for
> INIT_CODEC
> 5. Copied I1 frame is runned FRAME_START after dst buffer is
> reallocated
> (5~9 in your seq.)
> 6. Queued P2 frame is executed, then DQBUF will be OK
>
> >
> > Best regards,
> >
> > > -Original Message-
> > > From: Kamil Debski [mailto:k.deb...@samsung.com]
> > > Sent: Friday, January 14, 2011 4:24 PM
> > > To: 'Jonghun Han'; linux-media@vger.kernel.org; linux-samsung-
> > > s...@vger.kernel.org
> > > Cc: Marek Szyprowski; pa...@osciak.com; kyungmin.p...@samsung.com;
> > > jaeryul...@samsung.com; kgene@samsung.com
> > > Subject: RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
> > >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Jonghun Han [mailto:jonghun@samsung.com]
> > > >
> > > > Hi,
> > > >
> > > > Kamil Debski wrote:
> > > >
> > > >
> > > >
> > > > > +/* Reqeust buffers */
> > > > > +static int vidioc_reqbufs(struct file *file, void *priv,
> > > > > + struct v4l2_requestbuffers
> > > > *reqbufs)
> > > > > +{
> > > > > + struct s5p_mfc_dev *dev = video_drvdata(file);
> > > > > + struct s5p_mfc_ctx *ctx = priv;
> > > > > + int ret = 0;
> > > > > + unsigned long flags;
> > > > > +
> > > > > + mfc_debug_enter();
> > > > > + mfc_debug("Memory type: %d\n", reqbufs->memory);
> > > > > + if (reqbufs->memory != V4L2_MEMORY_MMAP) {
> > > > > + mfc_err("Only V4L2_MEMORY_MAP is supported.\n");
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > > > + /* Can only request buffers after an instance has
> been
> > > > opened.*/
> > > > > + if (ctx->state == MFCINST_DEC_GOT_INST) {
> > > > > + /* Decoding */
> > > > > + if (ctx->output_state != QUEUE_FREE
How to set global alpha to V4L2_BUF_TYPE_CAPTURE ?
Hello, How to set global alpha to V4L2_BUF_TYPE_CAPTURE ? Samsung SoC S5PC210 has Camera interface and Video post processor named FIMC which can set the alpha value to V4L2_BUF_TYPE_CAPTURE. For example during color space conversion from YUV422 to ARGB, FIMC can set the alpha value to V4L2_BUF_TYPE_CAPTURE. I tried to find an available command to set it but I couldn't found it. But there is fmt.win.global_alpha for Video Overlay Interface. So in my opinion VIDIOC_S_FMT is also suitable for V4L2_BUF_TYPE_CAPTURE*. How about using fmt.pix.priv in struct v4l2_format and fmt.pix_mp.reserved[0] in struct v4l2_format ? I welcome your opinion. Best 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: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote: > Mauro, > > Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes > for 2.6.38. > > The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set > defaults for I2C client address 0x71. I know I was the one who > recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv > rely on it for the moment - Mea culpa. > > The lirc_zilog changes are tested to work with both Tx and Rx with an > HVR-1600. I don't want to continue much further on lirc_zilog changes, > unitl a few things happen: > > 1. I have developed, and have had tested, a patch for the pvrusb2 driver > to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported > device. Mauro, I have developed a patch for pvrusb2 and Mike Isely provided his Ack. I have added it to my "z8" branch and this pull request. > 2. Jarrod finishes his changes related to the Z8 chip for hdpvr and they > are pulled into media_tree.git branch. > > 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if > adding some new fields for struct IR_i2c_init_data is acceptable. > Specifically, I'd like to add a transceiver_lock mutex, a transceiver > reset callback, and a data pointer for that reset callback. > (Only lirc_zilog would use the reset callback and data pointer.) > > 4. I find spare time ever again. Here's the updated changeset information: The following changes since commit 0a97a683049d83deaf636d18316358065417d87b: [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git z8 Andy Walls (12): lirc_zilog: Reword debug message in ir_probe() lirc_zilog: Remove disable_tx module parameter lirc_zilog: Split struct IR into structs IR, IR_tx, and IR_rx lirc_zilog: Don't make private copies of i2c clients lirc_zilog: Extensive rework of ir_probe()/ir_remove() lirc_zilog: Update IR Rx polling kthread start/stop and some printks lirc_zilog: Remove unneeded tests for existence of the IR Tx function lirc_zilog: Remove useless struct i2c_driver.command function lirc_zilog: Add Andy Walls to copyright notice and authors list lirc_zilog: Update TODO.lirc_zilog ir-kbd-i2c: Add back defaults setting for Zilog Z8's at addr 0x71 pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c drivers/media/video/ir-kbd-i2c.c |6 + drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h |2 + drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 62 ++- drivers/staging/lirc/TODO.lirc_zilog | 36 +- drivers/staging/lirc/lirc_zilog.c | 650 +++- 5 files changed, 434 insertions(+), 322 deletions(-) Regards, Andy -- 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 PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
On Sun, 16 Jan 2011, Andy Walls wrote: > On Sun, 2011-01-16 at 20:27 -0600, Mike Isely wrote: [,,,] > > Right now, yes. In the near future, I need to use to to pass 3 > non-const items though: > > 1. A "struct mutex *transceiver_lock" so that the bridge driver can pass > a mutex to multiple modules accessing the Z8. That would be a per > device instance mutex, instantiated and initialized by the bridge > driver. The use case where this would be needed is a setup where > ir-kbd-i2c handles Z8 IR Rx and lirc_zilog handles only Z8 IR Tx of the > same chip. > > 2. A bridge driver provided "void (*reset_ir_chip)(struct i2c_adapter > *adap)", or maybe "void (*reset_ir_chip)(void *priv)", callback to > reset the transceiver chip when it gets hung. The original lirc_pvr150 > module had some hard coded reset function names and calls in it, but > they were removed with the rename to lirc_zilog and move into the > kernel. I'd like to get that ability back. > > 3. A bridge driver provided private data structure for the "void *priv" > argument of the aforementioned reset callback. This would also be a per > device object instantiated and initialized by the bridge driver. > I follow. Makes sense. Something to consider, perhaps for the future: Seems like what you have here amounts to some configuration data which will always be read-only, and other data which maps to the "context" in which the driver is being used (e.g. mutex instance, callback private context pointer, etc). That configuration data, if packed up into its own struct, could then be squirreled away at compile-time by the bridge driver and provided as part of a single table lookup. This only makes sense if there are a lot of configuration bits - but here I count 6 different items. > > > I believe I follow this and it looks good. The concept looks very > > simple and it's nice that the changes are really only in a single spot. > > Just thinking ahead about making the setup table-driven and not > > requiring data segment storage. > > With the patch right now it could be constant, I think. You would have > to use some generic name, like "pvrusb2 IR", instead of > hdw->hdw_desc->description though. > > For my future plans, if you don't provide a reset callback and don't > wish to provide a mutex, then yes you can keep it constant. > > I suspect not providing a reset callback may be OK. > > Not providing a mutex is also OK but it imposes a limitation: only one > IR module should be allowed to use the Z8 chip. That means > only lirc_zilog for IR Tx/Rx with Rx through LIRC, or > only ir-kbd-i2c for IR Rx through the the Linux input subsystem. For the future, I have no problem providing a reset callback. And given what you've said, I see no reason to do anything here which would constrain what you're trying to accomplish. But if down the road you do set up a separate configuration struct which this context struct might point to, then I'd like to update the pvrusb2 driver to take advantage of it. But this is no big deal for now. > > > -Mike > > > > > > Acked-By: Mike Isely > > Thanks. I'll pull this into my Z8 branch then. You're welcome. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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 PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
On Sun, 2011-01-16 at 20:27 -0600, Mike Isely wrote:
> Andy:
>
> Is the IR_i2c_init_data struct instance required to remain around for
> the life of the driver's registration and is that why you stuffed it
> into the pvr2_hdw struct?
Yes.
The loading of ir-kbd-i2c or lirc_zilog can happen some undetermined
amount of time after or before the pvrusb2 driver registers the I2C
devices. The data needs to persist on a per device basis; it cannot
come from the stack.
> Second: If the first question is yes, then is
> that struct considered to be read-only once it is set up and passed
> through to the i2c device registration function?
Yes. It will only be read once by lirc_zilog or ir-kbd-i2c in their
probe methods. Although both of those modules can be unloaded and
reloaded, so there is the possibility of being read again any number of
times.
> In other words, could
> that structure be a const static initialized at compile time, perhaps
> as part of a table definition?
Right now, yes. In the near future, I need to use to to pass 3
non-const items though:
1. A "struct mutex *transceiver_lock" so that the bridge driver can pass
a mutex to multiple modules accessing the Z8. That would be a per
device instance mutex, instantiated and initialized by the bridge
driver. The use case where this would be needed is a setup where
ir-kbd-i2c handles Z8 IR Rx and lirc_zilog handles only Z8 IR Tx of the
same chip.
2. A bridge driver provided "void (*reset_ir_chip)(struct i2c_adapter
*adap)", or maybe "void (*reset_ir_chip)(void *priv)", callback to
reset the transceiver chip when it gets hung. The original lirc_pvr150
module had some hard coded reset function names and calls in it, but
they were removed with the rename to lirc_zilog and move into the
kernel. I'd like to get that ability back.
3. A bridge driver provided private data structure for the "void *priv"
argument of the aforementioned reset callback. This would also be a per
device object instantiated and initialized by the bridge driver.
> I believe I follow this and it looks good. The concept looks very
> simple and it's nice that the changes are really only in a single spot.
> Just thinking ahead about making the setup table-driven and not
> requiring data segment storage.
With the patch right now it could be constant, I think. You would have
to use some generic name, like "pvrusb2 IR", instead of
hdw->hdw_desc->description though.
For my future plans, if you don't provide a reset callback and don't
wish to provide a mutex, then yes you can keep it constant.
I suspect not providing a reset callback may be OK.
Not providing a mutex is also OK but it imposes a limitation: only one
IR module should be allowed to use the Z8 chip. That means
only lirc_zilog for IR Tx/Rx with Rx through LIRC, or
only ir-kbd-i2c for IR Rx through the the Linux input subsystem.
> -Mike
>
>
> Acked-By: Mike Isely
Thanks. I'll pull this into my Z8 branch then.
Regards,
Andy
> On Sun, 16 Jan 2011, Andy Walls wrote:
>
> >
> > When registering an IR Rx device with the I2C subsystem, provide more
> > detailed
> > information about the IR device and default remote configuration for the IR
> > driver modules.
> >
> > Also explicitly register any IR Tx device with the I2C subsystem.
> >
> > Signed-off-by: Andy Walls
> > Cc: Mike Isely
> >
> > --
> > Mike,
> >
> > As discussed on IRC, this patch will enable lirc_zilog to bind to Zilog
> > Z8 IR units on devices supported by pvrusb2.
> >
> > Please review and comment. This patch could have been written a number
> > of ways. The way I chose was very direct: hard-coding information in a
> > single function.
> >
> > A git branch with this change, and the updated lirc_zilog, is here:
> >
> > git://linuxtv.org/awalls/media_tree.git z8-pvrusb2
> >
> >
> > http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8-pvrusb2
> >
> > Regards,
> > Andy
> >
> > diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > index ac94a8b..305e6aa 100644
> > --- a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > @@ -40,6 +40,7 @@
> > #include "pvrusb2-io.h"
> > #include
> > #include
> > +#include
> > #include "pvrusb2-devattr.h"
> >
> > /* Legal values for PVR2_CID_HSM */
> > @@ -202,6 +203,7 @@ struct pvr2_hdw {
> >
> > /* IR related */
> > unsigned int ir_scheme_active; /* IR scheme as seen from the outside */
> > + struct IR_i2c_init_data ir_init_data; /* params passed to IR modules */
> >
> > /* Frequency table */
> > unsigned int freqTable[FREQTABLE_SIZE];
> > diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> > b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> > index 7cbe18c..ccc8849 100644
> > --- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> > +++ b/drivers/media/video/pvrusb2
Re: [RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
Andy:
Is the IR_i2c_init_data struct instance required to remain around for
the life of the driver's registration and is that why you stuffed it
into the pvr2_hdw struct? Second: If the first question is yes, then is
that struct considered to be read-only once it is set up and passed
through to the i2c device registration function? In other words, could
that structure be a const static initialized at compile time, perhaps
as part of a table definition?
I believe I follow this and it looks good. The concept looks very
simple and it's nice that the changes are really only in a single spot.
Just thinking ahead about making the setup table-driven and not
requiring data segment storage.
-Mike
Acked-By: Mike Isely
On Sun, 16 Jan 2011, Andy Walls wrote:
>
> When registering an IR Rx device with the I2C subsystem, provide more detailed
> information about the IR device and default remote configuration for the IR
> driver modules.
>
> Also explicitly register any IR Tx device with the I2C subsystem.
>
> Signed-off-by: Andy Walls
> Cc: Mike Isely
>
> --
> Mike,
>
> As discussed on IRC, this patch will enable lirc_zilog to bind to Zilog
> Z8 IR units on devices supported by pvrusb2.
>
> Please review and comment. This patch could have been written a number
> of ways. The way I chose was very direct: hard-coding information in a
> single function.
>
> A git branch with this change, and the updated lirc_zilog, is here:
>
> git://linuxtv.org/awalls/media_tree.git z8-pvrusb2
>
>
> http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8-pvrusb2
>
> Regards,
> Andy
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> index ac94a8b..305e6aa 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> @@ -40,6 +40,7 @@
> #include "pvrusb2-io.h"
> #include
> #include
> +#include
> #include "pvrusb2-devattr.h"
>
> /* Legal values for PVR2_CID_HSM */
> @@ -202,6 +203,7 @@ struct pvr2_hdw {
>
> /* IR related */
> unsigned int ir_scheme_active; /* IR scheme as seen from the outside */
> + struct IR_i2c_init_data ir_init_data; /* params passed to IR modules */
>
> /* Frequency table */
> unsigned int freqTable[FREQTABLE_SIZE];
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> index 7cbe18c..ccc8849 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> @@ -19,6 +19,7 @@
> */
>
> #include
> +#include
> #include "pvrusb2-i2c-core.h"
> #include "pvrusb2-hdw-internal.h"
> #include "pvrusb2-debug.h"
> @@ -48,13 +49,6 @@ module_param_named(disable_autoload_ir_video,
> pvr2_disable_ir_video,
> MODULE_PARM_DESC(disable_autoload_ir_video,
>"1=do not try to autoload ir_video IR receiver");
>
> -/* Mapping of IR schemes to known I2C addresses - if any */
> -static const unsigned char ir_video_addresses[] = {
> - [PVR2_IR_SCHEME_ZILOG] = 0x71,
> - [PVR2_IR_SCHEME_29XXX] = 0x18,
> - [PVR2_IR_SCHEME_24XXX] = 0x18,
> -};
> -
> static int pvr2_i2c_write(struct pvr2_hdw *hdw, /* Context */
> u8 i2c_addr, /* I2C address we're talking to */
> u8 *data, /* Data to write */
> @@ -574,26 +568,56 @@ static void do_i2c_scan(struct pvr2_hdw *hdw)
> static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
> {
> struct i2c_board_info info;
> - unsigned char addr = 0;
> + struct IR_i2c_init_data *init_data = &hdw->ir_init_data;
> if (pvr2_disable_ir_video) {
> pvr2_trace(PVR2_TRACE_INFO,
> "Automatic binding of ir_video has been disabled.");
> return;
> }
> - if (hdw->ir_scheme_active < ARRAY_SIZE(ir_video_addresses)) {
> - addr = ir_video_addresses[hdw->ir_scheme_active];
> - }
> - if (!addr) {
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + switch (hdw->ir_scheme_active) {
> + case PVR2_IR_SCHEME_24XXX: /* FX2-controlled IR */
> + case PVR2_IR_SCHEME_29XXX: /* Original 29xxx device */
> + init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
> + init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP;
> + init_data->type = RC_TYPE_RC5;
> + init_data->name = hdw->hdw_desc->description;
> + init_data->polling_interval = 100; /* ms From ir-kbd-i2c */
> + /* IR Receiver */
> + info.addr = 0x18;
> + info.platform_data = init_data;
> + strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
> + pvr2_trace(PVR2_TRACE_INFO, "Binding %s to i2c address 0x%02x.",
> +info.typ
[RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
When registering an IR Rx device with the I2C subsystem, provide more detailed
information about the IR device and default remote configuration for the IR
driver modules.
Also explicitly register any IR Tx device with the I2C subsystem.
Signed-off-by: Andy Walls
Cc: Mike Isely
--
Mike,
As discussed on IRC, this patch will enable lirc_zilog to bind to Zilog
Z8 IR units on devices supported by pvrusb2.
Please review and comment. This patch could have been written a number
of ways. The way I chose was very direct: hard-coding information in a
single function.
A git branch with this change, and the updated lirc_zilog, is here:
git://linuxtv.org/awalls/media_tree.git z8-pvrusb2
http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8-pvrusb2
Regards,
Andy
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
index ac94a8b..305e6aa 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
@@ -40,6 +40,7 @@
#include "pvrusb2-io.h"
#include
#include
+#include
#include "pvrusb2-devattr.h"
/* Legal values for PVR2_CID_HSM */
@@ -202,6 +203,7 @@ struct pvr2_hdw {
/* IR related */
unsigned int ir_scheme_active; /* IR scheme as seen from the outside */
+ struct IR_i2c_init_data ir_init_data; /* params passed to IR modules */
/* Frequency table */
unsigned int freqTable[FREQTABLE_SIZE];
diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
index 7cbe18c..ccc8849 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
@@ -19,6 +19,7 @@
*/
#include
+#include
#include "pvrusb2-i2c-core.h"
#include "pvrusb2-hdw-internal.h"
#include "pvrusb2-debug.h"
@@ -48,13 +49,6 @@ module_param_named(disable_autoload_ir_video,
pvr2_disable_ir_video,
MODULE_PARM_DESC(disable_autoload_ir_video,
"1=do not try to autoload ir_video IR receiver");
-/* Mapping of IR schemes to known I2C addresses - if any */
-static const unsigned char ir_video_addresses[] = {
- [PVR2_IR_SCHEME_ZILOG] = 0x71,
- [PVR2_IR_SCHEME_29XXX] = 0x18,
- [PVR2_IR_SCHEME_24XXX] = 0x18,
-};
-
static int pvr2_i2c_write(struct pvr2_hdw *hdw, /* Context */
u8 i2c_addr, /* I2C address we're talking to */
u8 *data, /* Data to write */
@@ -574,26 +568,56 @@ static void do_i2c_scan(struct pvr2_hdw *hdw)
static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
{
struct i2c_board_info info;
- unsigned char addr = 0;
+ struct IR_i2c_init_data *init_data = &hdw->ir_init_data;
if (pvr2_disable_ir_video) {
pvr2_trace(PVR2_TRACE_INFO,
"Automatic binding of ir_video has been disabled.");
return;
}
- if (hdw->ir_scheme_active < ARRAY_SIZE(ir_video_addresses)) {
- addr = ir_video_addresses[hdw->ir_scheme_active];
- }
- if (!addr) {
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ switch (hdw->ir_scheme_active) {
+ case PVR2_IR_SCHEME_24XXX: /* FX2-controlled IR */
+ case PVR2_IR_SCHEME_29XXX: /* Original 29xxx device */
+ init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
+ init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP;
+ init_data->type = RC_TYPE_RC5;
+ init_data->name = hdw->hdw_desc->description;
+ init_data->polling_interval = 100; /* ms From ir-kbd-i2c */
+ /* IR Receiver */
+ info.addr = 0x18;
+ info.platform_data = init_data;
+ strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
+ pvr2_trace(PVR2_TRACE_INFO, "Binding %s to i2c address 0x%02x.",
+ info.type, info.addr);
+ i2c_new_device(&hdw->i2c_adap, &info);
+ break;
+ case PVR2_IR_SCHEME_ZILOG: /* HVR-1950 style */
+ case PVR2_IR_SCHEME_24XXX_MCE: /* 24xxx MCE device */
+ init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
+ init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
+ init_data->type = RC_TYPE_RC5;
+ init_data->name = hdw->hdw_desc->description;
+ init_data->polling_interval = 260; /* ms From lirc_zilog */
+ /* IR Receiver */
+ info.addr = 0x71;
+ info.platform_data = init_data;
+ strlcpy(info.type, "ir_rx_z8f0811_haup", I2C_NAME_SIZE);
+ pvr2_trace(PVR2_TRACE_INFO, "Binding %s to i2c address 0x%02x.",
+ info.type, info.addr);
+
too few arguments to function 'i2c_new_probed_device'
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-09/msg12477.html hg v4l today (01/16/2011). Doesn't do it when using linux-2.6.34 x64, but when trying to compile under linux-2.6.37 on a 32bit: /usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l/bttv-i2c.c: In function 'init_bttv_i2c_ir': /usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l/bttv-i2c.c:437: error: too few arguments to function 'i2c_new_probed_device' make[3]: *** [/usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l/bttv-i2c.o] Error 1 make[2]: *** [_module_/usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.37' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l' make: *** [all] Error 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
[PATCH] [media] Remove compatibility layer from multi-planar API documentation
This feature will probably be moved to libv4l2. Signed-off-by: Pawel Osciak --- Documentation/DocBook/v4l/planar-apis.xml | 35 +--- Documentation/DocBook/v4l/vidioc-querycap.xml | 22 +++ 2 files changed, 18 insertions(+), 39 deletions(-) diff --git a/Documentation/DocBook/v4l/planar-apis.xml b/Documentation/DocBook/v4l/planar-apis.xml index 8be7552..e6b5c18 100644 --- a/Documentation/DocBook/v4l/planar-apis.xml +++ b/Documentation/DocBook/v4l/planar-apis.xml @@ -2,10 +2,10 @@ Single- and multi-planar APIs Some devices require data for each input or output video frame - to be placed in discontiguous memory buffers. In such cases one + to be placed in discontiguous memory buffers. In such cases, one video frame has to be addressed using more than one memory address, i.e. one - pointer per "plane". A plane is a sub-buffer of current frame. For examples - of such formats see . + pointer per "plane". A plane is a sub-buffer of the current frame. For + examples of such formats see . Initially, V4L2 API did not support multi-planar buffers and a set of extensions has been introduced to handle them. Those extensions constitute @@ -14,8 +14,8 @@ Some of the V4L2 API calls and structures are interpreted differently, depending on whether single- or multi-planar API is being used. An application can choose whether to use one or the other by passing a corresponding buffer - type to its ioctl calls. Multi-planar versions of buffer types are suffixed with - an `_MPLANE' string. For a list of available multi-planar buffer types + type to its ioctl calls. Multi-planar versions of buffer types are suffixed + with an `_MPLANE' string. For a list of available multi-planar buffer types see &v4l2-buf-type;. @@ -24,28 +24,9 @@ Multi-planar API introduces new multi-planar formats. Those formats use a separate set of FourCC codes. It is important to distinguish between the multi-planar API and a multi-planar format. Multi-planar API calls can -handle all single-planar formats as well, while the single-planar API cannot -handle multi-planar formats. Applications do not have to switch between APIs -when handling both single- and multi-planar devices and should use the -multi-planar API version for both single- and multi-planar formats. -Drivers that do not support multi-planar API can still be handled with it, -utilizing a compatibility layer built into standard V4L2 ioctl handling. - - - - -Single and multi-planar API compatibility layer -In most casesThe compatibility layer does not cover -drivers that do not use video_ioctl2() call., applications -can use the multi-planar API with older drivers that support -only its single-planar version and vice versa. Appropriate conversion is -done seamlessly for both applications and drivers in the V4L2 core. The -general rule of thumb is: as long as an application uses formats that -a driver supports, it can use either API (although use of multi-planar -formats is only possible with the multi-planar API). The list of formats -supported by a driver can be obtained using the &VIDIOC-ENUM-FMT; call. -It is possible, but discouraged, for a driver or an application to support -and use both versions of the API. +handle all single-planar formats as well (as long as they are passed in +multi-planar API structures), while the single-planar API cannot +handle multi-planar formats. diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml index 9369976..f29f1b8 100644 --- a/Documentation/DocBook/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/v4l/vidioc-querycap.xml @@ -142,30 +142,28 @@ this array to zero. V4L2_CAP_VIDEO_CAPTURE 0x0001 - The device supports single-planar formats through the Video Capture interface. An application can use either -the single or the multi-planar API. + The device supports the single-planar API through the Video Capture interface. V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x1000 - The device supports multi-planar formats through the Video Capture interface. An application has to use the -multi-planar API. + The device supports the + multi-planar API through the + Video Capture interface. V4L2_CAP_VIDEO_OUTPUT 0x0002 - The device supports single-planar formats through the Video Output interface. An application can use either -the single or the multi-planar API. + The device supports the single-planar API through the Video Output interface. V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x2000 - The device supports multi-planar formats through the Video Output int
Re: [GIT PATCHES FOR 2.6.38] v4l2-ctrls: fix missing read-only check causing kernel oops
On Sunday, January 16, 2011 18:55:22 Hans Verkuil wrote: > On Sunday, January 16, 2011 16:36:34 Hans Verkuil wrote: > > Hi Mauro, > > > > This fixes a nasty little bug that I just found with v4l2-compliance. > > > > I'm writing lots of compliance tests for control handling at the moment and > > the results are rather, erm, disheartening to use a polite word :-( > > Added this fix as well: > > v4l2-ctrls: queryctrl shouldn't attempt to replace > V4L2_CID_PRIVATE_BASE IDs And these three to fix DocBook issues: DocBook/v4l: fix validation error in dev-rds.xml DocBook/v4l: fix validation errors DocBook/v4l: update V4L2 revision and update copyright years. Those validation errors aren't seen when you build the documentation normally (make DOCBOOKS=media.xml htmldocs) since the DocBook makefile uses the xmlto --skip-validation option :-( But for the daily build I always do a: xmlto html-nochunks -m /Documentation/DocBook/stylesheet.xsl \ -o Documentation/DocBook/media Documentation/DocBook/media.xml which creates a one-page media.html in Documentation/DocBook/media. That's the version I upload every day since I like this nochunks version much better than having to click through a zillion links. And since I don't use the skip-validation option I see these errors. Regards, Hans > > Regards, > > Hans > > > > > Regards, > > > > Hans > > > > The following changes since commit a9ac9ac36d6b199074f9545b25154fa4771ed3f4: > > Hans Verkuil (1): > > [media] v4l2-ctrls: v4l2_ctrl_handler_setup must set is_new to 1 > > > > are available in the git repository at: > > > > ssh://linuxtv.org/git/hverkuil/media_tree.git ctrl-fix > > > > Hans Verkuil (1): > > v4l2-ctrls: fix missing 'read-only' check > > > > drivers/media/video/v4l2-ctrls.c |3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > > > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue
Fixing the very annoying tunning issue. When switching from DVB-S2 to DVB-S,
it often took minutes to have a lock.
This issue is known to Igor M. Liplianin and was also reported ie. in the
following posts:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24573
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/25275
The patch is changing the frontend from stv0900 to stv090x.
The card now works much more reliable. There is no problem with switching
from DVB-S2 to DVB-S, tunning works flawless.
Signed-off-by: Mariusz Bialonczyk
Tested-by: Warpme
---
drivers/media/video/cx88/Kconfig |2 +-
drivers/media/video/cx88/cx88-dvb.c| 56
2 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/media/video/cx88/Kconfig b/drivers/media/video/cx88/Kconfig
index 5c42abd..57316bb 100644
--- a/drivers/media/video/cx88/Kconfig
+++ b/drivers/media/video/cx88/Kconfig
@@ -60,7 +60,7 @@ config VIDEO_CX88_DVB
select DVB_STV0299 if !DVB_FE_CUSTOMISE
select DVB_STV0288 if !DVB_FE_CUSTOMISE
select DVB_STB6000 if !DVB_FE_CUSTOMISE
- select DVB_STV0900 if !DVB_FE_CUSTOMISE
+ select DVB_STV090x if !DVB_FE_CUSTOMISE
select DVB_STB6100 if !DVB_FE_CUSTOMISE
select MEDIA_TUNER_SIMPLE if !MEDIA_TUNER_CUSTOMISE
---help---
diff --git a/drivers/media/video/cx88/cx88-dvb.c
b/drivers/media/video/cx88/cx88-dvb.c
index 90717ee..3f25872 100644
--- a/drivers/media/video/cx88/cx88-dvb.c
+++ b/drivers/media/video/cx88/cx88-dvb.c
@@ -53,9 +53,9 @@
#include "stv0288.h"
#include "stb6000.h"
#include "cx24116.h"
-#include "stv0900.h"
+#include "stv090x.h"
#include "stb6100.h"
-#include "stb6100_proc.h"
+#include "stb6100_cfg.h"
#include "mb86a16.h"
MODULE_DESCRIPTION("driver for cx2388x based DVB cards");
@@ -611,15 +611,6 @@ static int cx24116_set_ts_param(struct dvb_frontend *fe,
return 0;
}
-static int stv0900_set_ts_param(struct dvb_frontend *fe,
- int is_punctured)
-{
- struct cx8802_dev *dev = fe->dvb->priv;
- dev->ts_gen_cntrl = 0;
-
- return 0;
-}
-
static int cx24116_reset_device(struct dvb_frontend *fe)
{
struct cx8802_dev *dev = fe->dvb->priv;
@@ -648,16 +639,21 @@ static const struct cx24116_config tevii_s460_config = {
.reset_device = cx24116_reset_device,
};
-static const struct stv0900_config prof_7301_stv0900_config = {
- .demod_address = 0x6a,
-/* demod_mode = 0,*/
- .xtal = 2700,
- .clkmode = 3,/* 0-CLKI, 2-XTALI, else AUTO */
- .diseqc_mode = 2,/* 2/3 PWM */
- .tun1_maddress = 0,/* 0x60 */
- .tun1_adc = 0,/* 2 Vpp */
- .path1_mode = 3,
- .set_ts_params = stv0900_set_ts_param,
+static struct stv090x_config prof_7301_stv090x_config = {
+.device = STV0903,
+.demod_mode = STV090x_SINGLE,
+.clk_mode = STV090x_CLK_EXT,
+.xtal = 2700,
+.address= 0x6A,
+.ts1_mode = STV090x_TSMODE_PARALLEL_PUNCTURED,
+.repeater_level = STV090x_RPTLEVEL_64,
+.adc1_range = STV090x_ADC_2Vpp,
+.diseqc_envelope_mode = false,
+
+.tuner_get_frequency= stb6100_get_frequency,
+.tuner_set_frequency= stb6100_set_frequency,
+.tuner_set_bandwidth= stb6100_set_bandwidth,
+.tuner_get_bandwidth= stb6100_get_bandwidth,
};
static const struct stb6100_config prof_7301_stb6100_config = {
@@ -1402,23 +1398,19 @@ static int dvb_register(struct cx8802_dev *dev)
}
break;
case CX88_BOARD_PROF_7301:{
- struct dvb_tuner_ops *tuner_ops = NULL;
+ dev->ts_gen_cntrl = 0x00;
- fe0->dvb.frontend = dvb_attach(stv0900_attach,
- &prof_7301_stv0900_config,
- &core->i2c_adap, 0);
+ fe0->dvb.frontend = dvb_attach(stv090x_attach,
+ &prof_7301_stv090x_config,
+ &core->i2c_adap,
+ STV090x_DEMODULATOR_0);
if (fe0->dvb.frontend != NULL) {
- if (!dvb_attach(stb6100_attach, fe0->dvb.frontend,
+ if (!dvb_attach(stb6100_attach,
+ fe0->dvb.frontend,
&prof_7301_stb6100_config,
&core->i2c_adap))
goto frontend_detach;
- tuner_ops = &fe0->dvb.frontend->ops.tuner_ops;
- tuner_ops->set_frequency = stb6100_set_freq;
- tuner_ops->get_frequency = stb6100_get_freq;
- tuner_
Re: [RFC PATCH] ir-kbd-i2c, lirc_zilog: Allow bridge drivers to pass an IR trasnceiver mutex to I2C IR modules
On Sun, 2011-01-16 at 16:27 -0200, Mauro Carvalho Chehab wrote: > Jarod/Andy, > > For now, I'm marking all those ir-kbd-i2c/lirc_zilog patches as "RFC" at > patchwork, > as I'm not sure if they're ok, and because there are a few revisions of them > and > I'm afraid to apply some wrong version. And that's just fine. :) That particular RFC was to get mostly Jean's opinion on adding fields to struct IR_i2c_init_data and struct IR_i2c and code to ir-kbd-i2c. > Please, after finishing and testing, send me a patch series or, preferably, a > git pull with those stuff. I just sent a [GIT PATCHES for 2.6.38], which is my pull request. It fixes one minor regression in ir-kbd-i2c.c. The rest of the patches are limited to lirc_zilog and do not modify any bridge drivers. The lirc_zilog changes were tested by me using my HVR-1600. Jarrod will have to ask you to pull any hdpvr fixes, when he feels they are ready. Note my pull request does *not* include the patches in the subject [RFC PATCH], so no worries about pulling those in. :) I'll submit a pull for those when they are correct and ready. Regards, Andy -- 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 v3] [media] Add multi-planar API documentation
Add DocBook documentation for the new multi-planar API extensions to the Video for Linux 2 API DocBook. Signed-off-by: Pawel Osciak --- Removed references to single-multi planar API conversion layer. Documentation/DocBook/media-entities.tmpl |4 + Documentation/DocBook/v4l/common.xml |2 + Documentation/DocBook/v4l/compat.xml | 11 + Documentation/DocBook/v4l/dev-capture.xml | 13 +- Documentation/DocBook/v4l/dev-output.xml | 13 +- Documentation/DocBook/v4l/func-mmap.xml | 10 +- Documentation/DocBook/v4l/func-munmap.xml |3 +- Documentation/DocBook/v4l/io.xml | 247 + Documentation/DocBook/v4l/pixfmt.xml | 116 +++- Documentation/DocBook/v4l/planar-apis.xml | 62 ++ Documentation/DocBook/v4l/v4l2.xml| 21 ++- Documentation/DocBook/v4l/vidioc-enum-fmt.xml |2 + Documentation/DocBook/v4l/vidioc-g-fmt.xml| 15 ++- Documentation/DocBook/v4l/vidioc-qbuf.xml | 24 ++- Documentation/DocBook/v4l/vidioc-querybuf.xml | 14 +- Documentation/DocBook/v4l/vidioc-querycap.xml | 18 ++- 16 files changed, 507 insertions(+), 68 deletions(-) create mode 100644 Documentation/DocBook/v4l/planar-apis.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index be34dcb..74923d7 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -129,6 +129,7 @@ v4l2_audioout"> v4l2_bt_timings"> v4l2_buffer"> +v4l2_plane"> v4l2_capability"> v4l2_captureparm"> v4l2_clip"> @@ -167,6 +168,8 @@ v4l2_output"> v4l2_outputparm"> v4l2_pix_format"> +v4l2_pix_format_mplane"> +v4l2_plane_pix_format"> v4l2_queryctrl"> v4l2_querymenu"> v4l2_rect"> @@ -202,6 +205,7 @@ + diff --git a/Documentation/DocBook/v4l/common.xml b/Documentation/DocBook/v4l/common.xml index cea23e1..dbab79c 100644 --- a/Documentation/DocBook/v4l/common.xml +++ b/Documentation/DocBook/v4l/common.xml @@ -846,6 +846,8 @@ conversion routine or library for integration into applications. + &sub-planar-apis; + Image Cropping, Insertion and Scaling diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index c9ce61d..223c24c 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -2353,6 +2353,17 @@ that used it. It was originally scheduled for removal in 2.6.35. + + V4L2 in Linux 2.6.38 + + + Multi-planar API added. Does not affect the compatibility of + current drivers and applications. See + multi-planar API + for details. + + + Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/v4l/dev-capture.xml b/Documentation/DocBook/v4l/dev-capture.xml index 32807e4..2237c66 100644 --- a/Documentation/DocBook/v4l/dev-capture.xml +++ b/Documentation/DocBook/v4l/dev-capture.xml @@ -18,7 +18,8 @@ files are used for video output devices. Querying Capabilities Devices supporting the video capture interface set the -V4L2_CAP_VIDEO_CAPTURE flag in the +V4L2_CAP_VIDEO_CAPTURE or +V4L2_CAP_VIDEO_CAPTURE_MPLANE flag in the capabilities field of &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions they may also support the video overlay @@ -64,9 +65,11 @@ linkend="crop" />. To query the current image format applications set the type field of a &v4l2-format; to -V4L2_BUF_TYPE_VIDEO_CAPTURE and call the +V4L2_BUF_TYPE_VIDEO_CAPTURE or +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and call the &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill -the &v4l2-pix-format; pix member of the +the &v4l2-pix-format; pix or the +&v4l2-pix-format-mplane; pix_mp member of the fmt union. To request different parameters applications set the @@ -84,8 +87,8 @@ adjust the parameters and finally return the actual parameters as without disabling I/O or possibly time consuming hardware preparations. -The contents of &v4l2-pix-format; are discussed in . See also the specification of the +The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; +are discussed in . See also the specification of the VIDIOC_G_FMT, VIDIOC_S_FMT and VIDIOC_TRY_FMT ioctls for details. Video capture devices must implement both the diff --git a/Documentation/DocBook/v4l/dev-output.xml b/Documentation/DocBook/v4l/dev-output.xml index 63c3c20..919e22c 100644 --- a/Documentation/DocBook/v4l/dev-output.xml +++ b/Documentation/DocBook/v4l/dev-output.xml @@ -17,7 +17,8 @@ files are used for video capture devices. Querying Capabilities Devices supporting the video output interface set the -V4L2_CAP_VIDEO_OUTPUT flag in the +V4L2_CAP_VIDEO_OUTPUT or +V4L2_CAP_VIDEO_OUTPUT_MPLANE flag in the capabilities field of &v4l2-capabil
[PATCH for 2.6.38] [media] Fix double free of video_device in mem2mem_testdev
video_device is already being freed in video_device.release callback on release. Signed-off-by: Pawel Osciak Reported-by: Roland Kletzing --- drivers/media/video/mem2mem_testdev.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mem2mem_testdev.c b/drivers/media/video/mem2mem_testdev.c index 6ab2d4f..e1f96ea 100644 --- a/drivers/media/video/mem2mem_testdev.c +++ b/drivers/media/video/mem2mem_testdev.c @@ -996,7 +996,6 @@ static int m2mtest_remove(struct platform_device *pdev) v4l2_m2m_release(dev->m2m_dev); del_timer_sync(&dev->timer); video_unregister_device(dev->vfd); - video_device_release(dev->vfd); v4l2_device_unregister(&dev->v4l2_dev); kfree(dev); -- 1.7.3.5 -- 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 PATCHES for 2.6.38] Zilog Z8 IR unit fixes
Mauro, Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes for 2.6.38. The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set defaults for I2C client address 0x71. I know I was the one who recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv rely on it for the moment - Mea culpa. The lirc_zilog changes are tested to work with both Tx and Rx with an HVR-1600. I don't want to continue much further on lirc_zilog changes, unitl a few things happen: 1. I have developed, and have had tested, a patch for the pvrusb2 driver to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported device. 2. Jarrod finishes his changes related to the Z8 chip for hdpvr and they are pulled into media_tree.git branch. 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if adding some new fields for struct IR_i2c_init_data is acceptable. Specifically, I'd like to add a transceiver_lock mutex, a transceiver reset callback, and a data pointer for that reset callback. (Only lirc_zilog would use the reset callback and data pointer.) 4. I find spare time ever again. Anyway, here's the patchset reference... The following changes since commit 0a97a683049d83deaf636d18316358065417d87b: [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git z8 Andy Walls (11): lirc_zilog: Reword debug message in ir_probe() lirc_zilog: Remove disable_tx module parameter lirc_zilog: Split struct IR into structs IR, IR_tx, and IR_rx lirc_zilog: Don't make private copies of i2c clients lirc_zilog: Extensive rework of ir_probe()/ir_remove() lirc_zilog: Update IR Rx polling kthread start/stop and some printks lirc_zilog: Remove unneeded tests for existence of the IR Tx function lirc_zilog: Remove useless struct i2c_driver.command function lirc_zilog: Add Andy Walls to copyright notice and authors list lirc_zilog: Update TODO.lirc_zilog ir-kbd-i2c: Add back defaults setting for Zilog Z8's at addr 0x71 drivers/media/video/ir-kbd-i2c.c |6 + drivers/staging/lirc/TODO.lirc_zilog | 36 ++- drivers/staging/lirc/lirc_zilog.c| 650 ++ 3 files changed, 389 insertions(+), 303 deletions(-) Regards, Andy -- 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: Patches an media build tree
Em 15-01-2011 11:46, Helmut Auer escreveu: > Hello List > > How long does it usually take til patches are integrated into the media build > tree ( after posting these here ) ? > I'm just wondering because I miss some patches posted here. It takes as much it needs for the driver maintainer to look into it, and for me to have time to handle them. The pending patches are always at: https://patchwork.kernel.org/project/linux-media/list/ Please note that, by default, Patchwork filters the patches to display only the ones marked as New or Under Review. If you want to see all patches, you need to change the state filter to show all patches: https://patchwork.kernel.org/project/linux-media/list/?state=* If the patch you're waiting are marked as Under Review, you should ping the driver maintainer, as I'm waiting for his review. If it is new, that means that I didn't have time yet to dig into it. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jan 16 19:00:22 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 A linux-media.tar.bz2 archive with the latest media git sources that can be used with the media_build tree is available here: http://www.xs4all.nl/~hverkuil/logs/Sunday-linux-media.tar.bz2 Rename to linux-media.tar.bz2, put it in the media_build/linux directory, go to the directory and type 'make untar'. The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ir-kbd-i2c, lirc_zilog: Allow bridge drivers to pass an IR trasnceiver mutex to I2C IR modules
Jarod/Andy,
For now, I'm marking all those ir-kbd-i2c/lirc_zilog patches as "RFC" at
patchwork,
as I'm not sure if they're ok, and because there are a few revisions of them and
I'm afraid to apply some wrong version.
Please, after finishing and testing, send me a patch series or, preferably, a
git pull with those stuff.
Thanks!
Mauro
Em 16-01-2011 01:49, Andy Walls escreveu:
> The following patch allows bridge drivers, with an I2C IR Tx/Rx
> transceiver, to pass a mutex for serializing access to a single I2C IR
> chip between separate IR Tx and Rx modules.
>
> The change modifies struct IR_i2c_init_data and struct IR_i2c to add
>
> struct mutex *transceiver_lock
>
> that ir-kbd-i2c and lirc_zilog will use, if provided by the bridge
> driver. The changes to ir-kbd-i2c.[ch] and lirc_zilog.c provide the
> functional change in the patch.
>
> This patch also modifies cx18, ivtv, and hdpvr (sans Jarrod's recent
> patches) to provide a transceiver_lock mutex to ir-kbd-i2c and
> lirc_zilog.
>
> I skimmed all the other modules that use IR_i2c_init_data. They all
> appear to zero-fill the init_data properly before handing the data over
> to ir-kbd-i2c.c.
>
> I did find that pvrusb2 IR Rx for address 0x71 was broken, due to my
> recommendation to remove automatic config for address 0x71 from
> ir-kbd-i2c.c. I'll fix that in another patch, if someone with a pvrusb2
> device doesn't beat me to it.
>
> So without further ado...
>
>
> diff --git a/drivers/media/video/cx18/cx18-driver.c
> b/drivers/media/video/cx18/cx18-driver.c
> index 676e5be..da1ef93 100644
> --- a/drivers/media/video/cx18/cx18-driver.c
> +++ b/drivers/media/video/cx18/cx18-driver.c
> @@ -701,6 +701,7 @@ static int __devinit cx18_init_struct1(struct cx18 *cx)
>
> mutex_init(&cx->serialize_lock);
> mutex_init(&cx->gpio_lock);
> + mutex_init(&cx->ir_transceiver_lock);
> mutex_init(&cx->epu2apu_mb_lock);
> mutex_init(&cx->epu2cpu_mb_lock);
>
> diff --git a/drivers/media/video/cx18/cx18-driver.h
> b/drivers/media/video/cx18/cx18-driver.h
> index f6f3e50..82dc747 100644
> --- a/drivers/media/video/cx18/cx18-driver.h
> +++ b/drivers/media/video/cx18/cx18-driver.h
> @@ -626,6 +626,7 @@ struct cx18 {
> struct cx18_i2c_algo_callback_data i2c_algo_cb_data[2];
>
> struct IR_i2c_init_data ir_i2c_init_data;
> + struct mutex ir_transceiver_lock;
>
> /* gpio */
> u32 gpio_dir;
> diff --git a/drivers/media/video/cx18/cx18-i2c.c
> b/drivers/media/video/cx18/cx18-i2c.c
> index c330fb9..7782de1 100644
> --- a/drivers/media/video/cx18/cx18-i2c.c
> +++ b/drivers/media/video/cx18/cx18-i2c.c
> @@ -96,10 +96,12 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct
> i2c_adapter *adap, u32 hw,
> /* Our default information for ir-kbd-i2c.c to use */
> switch (hw) {
> case CX18_HW_Z8F0811_IR_RX_HAUP:
> + case CX18_HW_Z8F0811_IR_TX_HAUP:
> init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
> init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
> init_data->type = RC_TYPE_RC5;
> init_data->name = cx->card_name;
> + init_data->transceiver_lock = &cx->ir_transceiver_lock;
> info.platform_data = init_data;
> break;
> }
> diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
> b/drivers/media/video/hdpvr/hdpvr-core.c
> index f7d1ee5..df4a02a 100644
> --- a/drivers/media/video/hdpvr/hdpvr-core.c
> +++ b/drivers/media/video/hdpvr/hdpvr-core.c
> @@ -304,6 +304,7 @@ static int hdpvr_probe(struct usb_interface *interface,
>
> mutex_init(&dev->io_mutex);
> mutex_init(&dev->i2c_mutex);
> + mutex_init(&dev->ir_transceiver_mutex);
> mutex_init(&dev->usbc_mutex);
> dev->usbc_buf = kmalloc(64, GFP_KERNEL);
> if (!dev->usbc_buf) {
> diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
> b/drivers/media/video/hdpvr/hdpvr-i2c.c
> index 24966aa..b1e68b8 100644
> --- a/drivers/media/video/hdpvr/hdpvr-i2c.c
> +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
> @@ -48,13 +48,15 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device *dev,
> struct i2c_adapter *adap,
> memset(&info, 0, sizeof(struct i2c_board_info));
> strlcpy(info.type, type, I2C_NAME_SIZE);
>
> - /* Our default information for ir-kbd-i2c.c to use */
> + /* Our default information for ir-kbd-i2c.c and lirc_zilog.c to use */
> switch (addr) {
> case Z8F0811_IR_RX_I2C_ADDR:
> + case Z8F0811_IR_TX_I2C_ADDR:
> init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
> init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
> init_data->type = RC_TYPE_RC5;
> init_data->name = "HD PVR";
> + init_data->transceiver_lock = &dev->ir_transceiver_mutex;
> info.platform_data = init_data;
> break;
> }
> diff --git a/drivers/media/video/hdpvr/hdpvr.h
> b/drivers/media/video/hdpvr/hdpvr
Re: [GIT PATCHES FOR 2.6.38] v4l2-ctrls: fix missing read-only check causing kernel oops
On Sunday, January 16, 2011 16:36:34 Hans Verkuil wrote: > Hi Mauro, > > This fixes a nasty little bug that I just found with v4l2-compliance. > > I'm writing lots of compliance tests for control handling at the moment and > the results are rather, erm, disheartening to use a polite word :-( Added this fix as well: v4l2-ctrls: queryctrl shouldn't attempt to replace V4L2_CID_PRIVATE_BASE IDs Regards, Hans > > Regards, > > Hans > > The following changes since commit a9ac9ac36d6b199074f9545b25154fa4771ed3f4: > Hans Verkuil (1): > [media] v4l2-ctrls: v4l2_ctrl_handler_setup must set is_new to 1 > > are available in the git repository at: > > ssh://linuxtv.org/git/hverkuil/media_tree.git ctrl-fix > > Hans Verkuil (1): > v4l2-ctrls: fix missing 'read-only' check > > drivers/media/video/v4l2-ctrls.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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 v2] Altera FPGA based CI driver module.
Em 02-01-2011 10:01, Igor M. Liplianin escreveu: > An Altera FPGA CI module for NetUP Dual DVB-T/C RF CI card. > > Signed-off-by: Igor M. Liplianin Igor, There's something wrong with this patch. I got lots of error after applying it: drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_read_attribute_mem': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:304: multiple definition of `netup_ci_read_attribute_mem' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:241: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_op_cam': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:269: multiple definition of `netup_ci_op_cam' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:171: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_shutdown': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:364: multiple definition of `netup_ci_slot_shutdown' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:293: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_ts_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:370: multiple definition of `netup_ci_slot_ts_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:320: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_write_cam_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:322: multiple definition of `netup_ci_write_cam_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:259: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_read_cam_ctl': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:315: multiple definition of `netup_ci_read_cam_ctl' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:252: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_write_attribute_mem': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:310: multiple definition of `netup_ci_write_attribute_mem' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:247: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_poll_ci_slot_status': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:448: multiple definition of `netup_poll_ci_slot_status' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:403: first defined here drivers/media/video/cx23885/altera-ci.o: In function `netup_ci_slot_reset': /home/v4l/v4l/patchwork/drivers/media/video/cx23885/altera-ci.c:327: multiple definition of `netup_ci_slot_reset' drivers/media/video/cx23885/cx23885.o:/home/v4l/v4l/patchwork/drivers/media/video/cx23885/cimax2.c:264: first defined here Please fix it and submit a new version. The better is to replace all those new symbols to start with altera_ci. While here, please, on the first patch, move the Altera FPGA driver to staging, to give people some time do discuss about it. PS.: there are a few CodingStyle errors on this patch. Please always review your patches with ./scripts/checkpatch.pl. Thanks! Mauro > --- > drivers/media/video/cx23885/Kconfig |9 + > drivers/media/video/cx23885/Makefile|1 + > drivers/media/video/cx23885/altera-ci.c | 837 > +++ > drivers/media/video/cx23885/altera-ci.h | 102 > 4 files changed, 949 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/video/cx23885/altera-ci.c > create mode 100644 drivers/media/video/cx23885/altera-ci.h > > diff --git a/drivers/media/video/cx23885/Kconfig > b/drivers/media/video/cx23885/Kconfig > index 6b4a516..5e5faad 100644 > --- a/drivers/media/video/cx23885/Kconfig > +++ b/drivers/media/video/cx23885/Kconfig > @@ -33,3 +33,12 @@ config VIDEO_CX23885 > To compile this driver as a module, choose M here: the > module will be called cx23885 > > +config MEDIA_ALTERA_CI > + tristate "Altera FPGA based CI module" > + depends on VIDEO_CX23885 && DVB_CORE > + select STAPL_ALTERA > + ---help--- > + An Altera FPGA CI module for NetUP Dual DVB-T/C RF CI card. > + > + To compile this driver as a module, choose M here: the > + module will be called altera-ci > diff --git a/drivers/media/video/cx23885/Makefile > b/drivers/media/video/cx23885/Makefile > index e2ee95f..23293c7 100644 > --- a/drivers/media/video/cx23885/Makefile > +++ b/drivers/media/video/cx23885/Makefile > @@ -5,6 +5,7 @@ cx23885-objs := cx23885-cards.o cx23885-video.o > cx23885-vbi.o \ > cx23885-f300.o > > ob
[GIT PATCHES FOR 2.6.38] v4l2-ctrls: fix missing read-only check causing kernel oops
Hi Mauro, This fixes a nasty little bug that I just found with v4l2-compliance. I'm writing lots of compliance tests for control handling at the moment and the results are rather, erm, disheartening to use a polite word :-( Regards, Hans The following changes since commit a9ac9ac36d6b199074f9545b25154fa4771ed3f4: Hans Verkuil (1): [media] v4l2-ctrls: v4l2_ctrl_handler_setup must set is_new to 1 are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git ctrl-fix Hans Verkuil (1): v4l2-ctrls: fix missing 'read-only' check drivers/media/video/v4l2-ctrls.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
BUG: unable to handle kernel NULL pointer dereference when using radio_usb_si470x
Hello, I've recently faced kernel boo-boo using driver radio_usb_si470x with SI chipset device, according to info in module I think I should post it here. Here's crash report in syslog: Jan 16 00:53:14 aclex kernel: usb 1-2.3: new full speed USB device using ehci_hcd and address 9 Jan 16 00:53:14 aclex kernel: radio-si470x 1-2.3:1.2: DeviceID=0x1242 ChipID=0x060f Jan 16 00:53:14 aclex kernel: radio-si470x 1-2.3:1.2: software version 1, hardware version 4 Jan 16 00:53:14 aclex kernel: radio-si470x 1-2.3:1.2: This driver is known to work with software version 7, Jan 16 00:53:14 aclex kernel: radio-si470x 1-2.3:1.2: but the device has software version 1. Jan 16 00:53:14 aclex kernel: radio-si470x 1-2.3:1.2: If you have some trouble using this driver, Jan 16 00:53:14 aclex kernel: radio-si470x 1-2.3:1.2: please report to V4L ML at linux-media@vger.kernel.org Jan 16 00:53:22 aclex kernel: BUG: unable to handle kernel NULL pointer dereference at 0010 Jan 16 00:53:22 aclex kernel: IP: [] si470x_vidioc_querycap+0x58/0x90 [radio_usb_si470x] Jan 16 00:53:22 aclex kernel: PGD 256f7f067 PUD 252a96067 PMD 0 Jan 16 00:53:22 aclex kernel: Oops: [#1] PREEMPT SMP Jan 16 00:53:22 aclex kernel: last sysfs file: /sys/devices/platform/coretemp.0/temp1_label Jan 16 00:53:22 aclex kernel: CPU 7 Jan 16 00:53:22 aclex kernel: Modules linked in: radio_usb_si470x zl10353 xc5000 option tuner cx25840 cx23885 usb_wwan cx2341x videobuf_dma_sg videobuf_dvb tpm_tis dvb_core tpm tpm_bios usbserial videobuf_core btcx_risc tveeprom acpi_cpufreq mperf tun Jan 16 00:53:22 aclex kernel: Jan 16 00:53:22 aclex kernel: Pid: 3222, comm: gst-launch-0.10 Not tainted 2.6.36.1 #2 S5000XVN/S5000XVN Jan 16 00:53:22 aclex kernel: RIP: 0010:[] [] si470x_vidioc_querycap+0x58/0x90 [radio_usb_si470x] Jan 16 00:53:22 aclex kernel: RSP: 0018:880210829c58 EFLAGS: 00010296 Jan 16 00:53:22 aclex kernel: RAX: 880252b5 RBX: 880210829db8 RCX: Jan 16 00:53:22 aclex kernel: RDX: RSI: a0038097 RDI: 880210829de8 Jan 16 00:53:22 aclex kernel: RBP: 880210829c68 R08: 880252b50004 R09: 880210829db8 Jan 16 00:53:22 aclex kernel: R10: R11: R12: 880258ad9ec0 Jan 16 00:53:22 aclex kernel: R13: 80685600 R14: 880259319780 R15: a0037a40 Jan 16 00:53:22 aclex kernel: FS: 7fbcef316700() GS:880001bc() knlGS: Jan 16 00:53:22 aclex kernel: CS: 0010 DS: ES: CR0: 80050033 Jan 16 00:53:22 aclex kernel: CR2: 0010 CR3: 000255a24000 CR4: 06e0 Jan 16 00:53:22 aclex kernel: DR0: DR1: DR2: Jan 16 00:53:22 aclex kernel: DR3: DR6: 0ff0 DR7: 0400 Jan 16 00:53:22 aclex kernel: Process gst-launch-0.10 (pid: 3222, threadinfo 880210828000, task 88025894c710) Jan 16 00:53:22 aclex kernel: Stack: Jan 16 00:53:22 aclex kernel: 880252b86c00 880210829db8 880210829d78 8146a54d Jan 16 00:53:22 aclex kernel: <0> 880210829ca8 810ebe23 88024596bd98 880210829d28 Jan 16 00:53:22 aclex kernel: <0> 880259319780 880252b7aa30 ea0008487860 ea00 Jan 16 00:53:22 aclex kernel: Call Trace: Jan 16 00:53:22 aclex kernel: [] __video_do_ioctl+0x46d/0x4bd0 Jan 16 00:53:22 aclex kernel: [] ? cdev_get+0x63/0xa0 Jan 16 00:53:22 aclex kernel: [] ? unlock_page+0x25/0x30 Jan 16 00:53:22 aclex kernel: [] ? __do_fault+0x409/0x540 Jan 16 00:53:22 aclex kernel: [] ? chrdev_open+0x0/0x200 Jan 16 00:53:22 aclex kernel: [] video_ioctl2+0x141/0x590 Jan 16 00:53:22 aclex kernel: [] v4l2_ioctl+0x9e/0xc0 Jan 16 00:53:22 aclex kernel: [] do_vfs_ioctl+0x9f/0x550 Jan 16 00:53:22 aclex kernel: [] ? alloc_fd+0xf2/0x140 Jan 16 00:53:22 aclex kernel: [] sys_ioctl+0x81/0xa0 Jan 16 00:53:22 aclex kernel: [] system_call_fastpath+0x16/0x1b Jan 16 00:53:22 aclex kernel: Code: 20 e1 48 8d 7b 10 ba 20 00 00 00 48 c7 c6 78 80 03 a0 e8 9c d6 20 e1 49 8b 84 24 80 00 00 00 48 8d 7b 30 48 8b 50 40 4c 8d 40 04 <48> 8b 4a 10 be 20 00 00 00 48 c7 c2 ff 7e 03 a0 31 c0 e8 41 fd Jan 16 00:53:22 aclex kernel: RIP [] si470x_vidioc_querycap+0x58/0x90 [radio_usb_si470x] Jan 16 00:53:22 aclex kernel: RSP Jan 16 00:53:22 aclex kernel: CR2: 0010 Jan 16 00:53:23 aclex kernel: ---[ end trace 6e0f9403fadb7548 ]--- Jan 16 00:53:50 aclex kernel: usb 1-2.3: USB disconnect, address 9 The device is Silicon Labs USBFMRADIO-RD and chipset seems to be Si4701. How I reproduced it (was 100% reproducible for me): 1. Connect the device, start playing from its ALSA card and send several ioctl commands to control it. (I used gstreamer for it). 2. Connect USB-flash to the next USB port and mention that the radio device stopped receiving the signal (audio stream is still goes but with silence). 3. Send some more ioctl commands. You
Re: [PATCH 01/18] Altera FPGA firmware download module.
Em 07-01-2011 17:31, Ben Gamari escreveu: > Hi Mauro, > > On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab > wrote: >> Em 31-12-2010 09:30, Laurent Pinchart escreveu: >>> Hi Mauro, >>> >>> [snip] >>> >>> I understand this. However, a complete JTAG state machine in the kernel, >>> plus >>> an Altera firmware parser, seems to be a lot of code that could live in >>> userspace. >> >> Moving it to userspace would mean a kernel driver that would depend on an >> userspace daemon^Wfirmware loader to work. I would NAK such designs. >> >> The way it is is fine from my POV. > > Any furthur comment on this? As I noted, I strongly disagree and would > point out that there is no shortage of precedent for the use of > userspace callbacks for loading of firmware, especially when the process > is as tricky as this. > > I also work with Altera FPGAs and have a strong interest in making this > work yet from my perspective it seems pretty clear that the best way > forward both for both maintainability and useability is to keep > this code in user-space. There is absolutely no reason why this code > _must_ be in the kernel and punting it out to userspace only requires > a udev rule. > > Placing this functionality in userspace results in a massive duplication > of code, as there are already a number of functional user-space JTAG > implementations. On all V4L/DVB drivers I'm ware of, firmwares are loaded via request_firmware, when userspace tries to use the device, or when the driver is loaded (eventually, it might have some v4l/dvb legacy drivers with some weird implementation, but this is a bad practice). There's currently no V4L/DVB load firmware daemon or V4L/DVB udev rules for loading firmware that I'm ware of, and I don't like the idea of adding an extra complexity for userspace to use this device. So, I'll be adding this driver as proposed. Yet, as some points are risen, I'll be moving those drivers to staging for 2.6.38. This will give you some time for propose patches and to better discuss this question. > >>> If I understand it correctly the driver assumes the firmware is in an >>> Altera >>> proprietary format. If we really want JTAG code in the kernel we should at >>> least split the file parser and the TAP access code. >>> >> >> Agreed, but I don't think this would be a good reason to block the code merge >> for .38. >> > Sure, but there should be agreement that a kernel-mode JTAG state > machine really is the best way forward (i.e. necessary for effective > firmware upload) before we commit to carry this code around forever. > > - Ben > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.38] gspca for_2.6.38
Em 13-01-2011 14:30, Jean-Francois Moine escreveu: > On Thu, 13 Jan 2011 12:38:04 +0100 > Antonio Ospite wrote: > >>> Jean-François Moine (9): >> [...] >>> gspca - ov534: Use the new video control mechanism >> >> In this commit, is there a reason why you didn't rename also >> sd_setagc() into setagc() like for the other functions? >> >> I am going to test the changes and report back if there's anything >> more, I like the cleanup tho. > > Hi Antonio, > > With the new video control mechanism, the '.set_control' function is > called only when capture is active. Otherwise, the '.set' function is > called in any case, and here, it activates/inactivates the auto white > balance control... Oh, I forgot to disable the awb when the agc is > disabled! > > Thank you for reporting any problem. BTW, the webcam 06f8:3002 which > had been removed some time ago is being tested. I will add it to this > subdriver as soon as it works correctly. I'm applying the remaining 8 patches from this series, as they seem to be ok. Please send me a new pull request when you fix the issues with the ov534 new video control mechanism. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] Add plugin support to libv4l
Hi, Thanks for the new patch, it looks much better. Unfortunately I found what I can only describe as a bug in the plugin rfc (which as you probasbly know I wrote). The problem is 2 fold: 1) The existence of v4l2_fd_open (and its active use by multiple applications) means that we cannot let he plugin open the fd, since it may already be opened by the app. So the plugin function dev_open should be replaced by a dev_init taking an already open fd. Note we could probably change the API and remove v4l2_fd_open, but ... The reason for actually passing the open call with a file path (ie "/dev/video0") to the plugin was to allow creating a fully fake device (which would be created by a plugin when an open tries to open "fakevideo0" for example). However I now realize that doing fake (or userspace originating) device is best left to a loopback v4l2 kernel driver, because: 2) The fd needs to be a real file descriptor, which also really links to the v4l2 buffer for the device, as the application may use poll or select on the fd. Note that 2 also means when working with subdevices that the application actually needs to open the subdevice which will be the exit node for the format which the apps want (raw bayer for example has a different exit node then YUV data). This is part of the unsolved enumeration problem which we discussed in Helsinki last year. So summarizing, I believe that: 1) dev_open should be replaced by a dev_init which gets passed in an already open fd for the main / exit /dev/video node for the device 2) dev_close should be replaced by dev_cleanup, which frees allocated resources but does not close the fd (for consistency) This means this patch will need to be reworked a bit more, sorry about this. ### Looking at / thinking about the mmap / munmap code for plugins, I'm wondering if we should allow plugins to intercept mmap at all (given the above where we have given up on fully fake devices). Intercepting mmap is only useful for creating fakebuffers, which in turn is only necessary for format conversion which libv4l2 already handles. So I think it would be best to remove mmap interception, if we ever get a use case scenario where plugins need to modify frame data, they can create and manage their own mapping of the buffers and modify the data inline (after a dqbuf), or we can add a separate plugin mechanism to libv4lconvert for registering new format conversion plugins. Given that the main use case is for plugins which control settings inside the "webcam bridge" part of soc's related to 3a I don't think that dropping mmap interception will cause any problems and it will significantly simplify the code, removing some nasty corner cases. Which are hard to get right (and the current code does not get right). ### More detailed comments inline. Note quite a few remarks have to do with mmap / munmap. If we decide to drop this, they can be ignored :) On 01/14/2011 06:18 PM, Yordan Kamenov wrote: A libv4l2 plugin will sit in between libv4l2 itself and the actual /dev/video device node a fd refers to. It will be called each time libv4l2 wants to do an operation (read/write/ioctl/mmap/munmap) on the actual /dev/video node in question. Signed-off-by: Yordan Kamenov --- lib/include/libv4l2-plugin.h | 43 +++ lib/include/libv4l2.h |4 +- lib/include/libv4lconvert.h|5 +- lib/libv4l1/libv4l1.c |2 +- lib/libv4l2/Makefile |4 +- lib/libv4l2/libv4l2-priv.h | 24 ++ lib/libv4l2/libv4l2.c | 128 +++--- lib/libv4l2/v4l2-plugin.c | 344 lib/libv4l2/v4l2convert.c | 23 ++- lib/libv4lconvert/control/libv4lcontrol-priv.h |3 + lib/libv4lconvert/control/libv4lcontrol.c | 26 +- lib/libv4lconvert/control/libv4lcontrol.h |5 +- lib/libv4lconvert/libv4lconvert-priv.h |1 + lib/libv4lconvert/libv4lconvert.c | 25 +- 14 files changed, 573 insertions(+), 64 deletions(-) create mode 100644 lib/include/libv4l2-plugin.h create mode 100644 lib/libv4l2/v4l2-plugin.c diff --git a/lib/include/libv4l2-plugin.h b/lib/include/libv4l2-plugin.h new file mode 100644 index 000..3971735 --- /dev/null +++ b/lib/include/libv4l2-plugin.h @@ -0,0 +1,43 @@ +/* +* Copyright (C) 2010 Nokia Corporation + +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU Lesser General Public License as published by +* the Free Software Foundation; either version 2.1 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* Lesser General Public License for mor
[PATCH] media: radio-aimslab.c needs #include
Commit e3c92215198cb6aa00ad38db2780faa6b72e0a3f ("[media] radio-aimslab.c: Fix
gcc 4.5+ bug") removed the include, but introduced new callers of msleep():
| drivers/media/radio/radio-aimslab.c: In function ‘rt_decvol’:
| drivers/media/radio/radio-aimslab.c:76: error: implicit declaration of
function ‘msleep’
Signed-off-by: Geert Uytterhoeven
---
drivers/media/radio/radio-aimslab.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/radio/radio-aimslab.c
b/drivers/media/radio/radio-aimslab.c
index 6cc5d13..4ce10db 100644
--- a/drivers/media/radio/radio-aimslab.c
+++ b/drivers/media/radio/radio-aimslab.c
@@ -31,6 +31,7 @@
#include /* Modules */
#include /* Initdata */
#include /* request_region */
+#include/* msleep */
#include/* kernel radio structs */
#include /* for KERNEL_VERSION MACRO */
#include /* outb, outb_p */
--
1.7.0.4
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
Re: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Em 13-01-2011 10:58, Mauro Carvalho Chehab escreveu: > Em 13-01-2011 06:46, Andrzej Pietrasiewicz escreveu: >> Hello Mauro, >> >> On Wednesday, January 12, 2011 9:24 PM Mauro Carvalho Chehab wrote: >>> >>> Em 12-01-2011 08:25, Marek Szyprowski escreveu: Hello Mauro, I've rebased our fimc and saa patches onto >>> http://linuxtv.org/git/mchehab/experimental.git vb2_test branch. The last 2 patches are for SAA7134 driver and are only to show that >>> videobuf2-dma-sg works correctly. >>> >>> On my first test with saa7134, it hanged. It seems that the code >>> reached a dead lock. >>> >>> On my test environment, I'm using a remote machine, without monitor. My >>> test is using >>> qv4l2 via a remote X server. Using a remote X server is an interesting >>> test, as it will >>> likely loose some frames, increasing the probability of races and dead >>> locks. >>> >> >> We did a similar test using a remote machine and qv4l2 with X forwarding. >> Both userptr and mmap worked. Read does not work because it is not >> implemented, but there was no freeze anyway, just green screen in qv4l2. >> However, we set "Capture Image Formats" to "YUV - 4:2:2 packed, YUV", "TV >> Standard" to "PAL". I enclose a (lengthy) log for reference - it is a log of >> a short session when modules where loaded, qv4l2 started, userptr mode run >> for a while and then mmap mode run for a while. >> >> We did it on a 32-bit system. We are going to repeat the test on a 64-bit >> system, it just takes some time to set it up. Perhaps this is the >> difference. > > Yeah, I tested where with PAL/M and 64-bits, but I don't think that the hangs > have something due to 64 bits. It is probably because of the high delay > introduced > by using the 100 Mbps Ethernet connection to display the stream. This > introduces > a high delay (the max frame rate drops from 30 fps to about 6 fps on my > setup). > So, qv4l2 will loose frames. This increases the possibility of a race between > qbuf/dqbuf. There are still some issued with saa7134, but I don't want to delay the upstream submission for vb2 due to those issues, as they may be caused by the saa7134 port to vb2. So, I'll be adding on my tree, and I'll be sending it upstream. Yet, I suggest that you finish the saa7134 backport, to allow more people to test it, as we have tons of users with saa7134 and they can help to double check if is there any bad locking inside vb2. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] request for 2.6.38-rc1
Em 14-01-2011 12:51, Patrick Boettcher escreveu:
> Hi Mauro,
>
> if it is not too late, here is a pull request for some new devices from
> DiBcom. It would be nice to have it in 2.6.38-rc1.
>
> Pull from
>
> git://linuxtv.org/pb/media_tree.git staging/for_2.6.38-rc1.dibcom
>
> for
>
> DiB: Codingstype updates
Not sure if this is by purpose, but you're changing all
msleep(10) into msleep(20). This sounds very weird for a
CodingStyle fix:
- msleep(10);
+ msleep(20);
> DiB0700: add support for several board-layouts
Hmm...
+ if (request_firmware(&state->frontend_firmware, "dib9090.fw",
&adap->dev->udev->dev)) {
Where's dib9090.fw firmware is available? The better is to submit a patch to
linux-firmware
with the firmware binary, with some license that allows end-users to use it
with your device
and distros/distro partners to re-distribute it. While here, please add also
the other
dibcom firmwares.
Vendors are free to use their own legal text for it. There are several examples
for it
at:
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob_plain;f=WHENCE;hb=HEAD
Btw, there are two alignment errors (one at dib7000p, for some cases, aligned
with 4 chars),
and another at dib8000, where all statements after an if are aligned with 3
tabs plus one space.
I'm fixing those issues, c/c you at the fix patches.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to help with RTL2832U based TV?
Antti Palosaari wrote Thu, 03 Dec 2009 13:48:01 -0800 > On 12/03/2009 10:09 PM, Peter Rasmussen wrote: > > as mentioned in the welcome email of this list, but it isn't > apparent to > me what the status in Linux of using a device based on this chip is? > > I have got today device having this chip (thanks to verkkokauppa.com for > sponsoring) and I am going to implement the driver. I am in hope I can > share some code from the old RTL2831U chip driver. I haven't looked > driver code yet nor taken any sniffs. I will do that during next week. OK, what is the status of this now? It seems from the status page that it is not finished. > Anyhow, there is Realtek released driver spreading over the net for that > chip, you can use it. I tried to find this but without luck. Do you know where it can be found? Anyway, I got the dongle to work via the following receipt: http://www.linuxin.dk/node/15583 (in Danish, but I think Google can translate it). I would appreciate that this be in the kernel tree proper. Best regards Keld -- 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] firedtv: fix remote control with newer Xorg evdev
After a recent update of xf86-input-evdev and xorg-server, I noticed
that X11 applications did not receive keypresses from the FireDTV
infrared remote control anymore. Instead, the Xorg log featured lots of
"FireDTV remote control: dropping event due to full queue!"
exclamations. The Linux console did not have an issue with the
FireDTV's RC though.
The fix is to insert EV_SYN events after the key-down/-up events.
Signed-off-by: Stefan Richter
---
drivers/media/dvb/firewire/firedtv-rc.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Index: b/drivers/media/dvb/firewire/firedtv-rc.c
===
--- a/drivers/media/dvb/firewire/firedtv-rc.c
+++ b/drivers/media/dvb/firewire/firedtv-rc.c
@@ -172,7 +172,8 @@ void fdtv_unregister_rc(struct firedtv *
void fdtv_handle_rc(struct firedtv *fdtv, unsigned int code)
{
- u16 *keycode = fdtv->remote_ctrl_dev->keycode;
+ struct input_dev *idev = fdtv->remote_ctrl_dev;
+ u16 *keycode = idev->keycode;
if (code >= 0x0300 && code <= 0x031f)
code = keycode[code - 0x0300];
@@ -188,6 +189,7 @@ void fdtv_handle_rc(struct firedtv *fdtv
return;
}
- input_report_key(fdtv->remote_ctrl_dev, code, 1);
- input_report_key(fdtv->remote_ctrl_dev, code, 0);
+ input_report_key(idev, code, 1);
+ input_report_key(idev, code, 0);
+ input_sync(idev);
}
--
Stefan Richter
-=-==-== ---= =
http://arcgraph.de/sr/
--
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
