Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
Hi, On Fri, Dec 07, 2012 at 03:12:48PM +0100, Philipp Zabel wrote: Hi, Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen: On 2012-11-26 18:10, Steffen Trumtrar wrote: Hi, On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote: +optional properties: + - hsync-active: hsync pulse is active low/high/ignored + - vsync-active: vsync pulse is active low/high/ignored + - de-active: data-enable pulse is active low/high/ignored + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/ + non-inverted (active on rising edge)/ +ignored (ignore property) I think hsync-active and vsync-active are clear, and commonly used, and they are used for both drm and fb mode conversions in later patches. de-active is not used in drm and fb mode conversions, but I think it's also clear. pixelclk-inverted is not used in the mode conversions. It's also a bit unclear to me. What does it mean that pix clock is active on rising edge? The pixel data is driven on rising edge? How about the sync signals and DE, when are they driven? Does your HW have any settings related to those? Those are properties commonly found in display specs. That is why they are here. If the GPU does not support the property it can be omitted. So what does the pixelclk-inverted mean? Normally the SoC drives pixel data on rising edge, and the panel samples it at falling edge? And vice-versa for inverted? Or the other way around? When is hsync/vsync set? On rising or falling edge of pclk? My point here is that the pixelclk-inverted is not crystal clear thing, like the hsync/vsync/de-active values are. And while thinking about this, I realized that the meaning of pixelclk-inverted depends on what component is it applied to. Presuming normal pixclk means pixel data on rising edge, the meaning of that depends on do we consider the SoC or the panel. The panel needs to sample the data on the other edge from the one the SoC uses to drive the data. Does the videomode describe the panel, or does it describe the settings programmed to the SoC? How about calling this property pixelclk-active, active high meaning driving pixel data on rising edges and sampling on falling edges (the pixel clock is high between driving and sampling the data), and active low meaning driving on falling edges and sampling on rising edges? It is the same from the SoC perspective and from the panel perspective, and it mirrors the usage of the other *-active properties. I think, this would not be a bad idea. I would include Philipps description in the display-timing.txt, as it makes the meaning pretty clear; at least to me. What do the others think about this? Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [PATCHv15 3/7] video: add of helper for display timings/videomode
On 2012-12-07 16:12, Philipp Zabel wrote: Hi, Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen: So what does the pixelclk-inverted mean? Normally the SoC drives pixel data on rising edge, and the panel samples it at falling edge? And vice-versa for inverted? Or the other way around? When is hsync/vsync set? On rising or falling edge of pclk? My point here is that the pixelclk-inverted is not crystal clear thing, like the hsync/vsync/de-active values are. And while thinking about this, I realized that the meaning of pixelclk-inverted depends on what component is it applied to. Presuming normal pixclk means pixel data on rising edge, the meaning of that depends on do we consider the SoC or the panel. The panel needs to sample the data on the other edge from the one the SoC uses to drive the data. Does the videomode describe the panel, or does it describe the settings programmed to the SoC? How about calling this property pixelclk-active, active high meaning driving pixel data on rising edges and sampling on falling edges (the pixel clock is high between driving and sampling the data), and active low meaning driving on falling edges and sampling on rising edges? It is the same from the SoC perspective and from the panel perspective, and it mirrors the usage of the other *-active properties. This sounds good to me. It's not quite correct, as neither pixelclock or pixel data are not really active when the clock is high/low, but it still makes sense and is clear (at least with a short description). Tomi signature.asc Description: OpenPGP digital signature
[PATCH] [media] fix tua6034 pll bandwich configuration [3rd and last attempt]
i have already send this patch twice and the mailing list but get no
response. (Three weeks delay between the mails).
Why mail mails are ignored?
The tua6034 pll is corrupted by commit [media] dvb-pll: use DVBv5
parameters on set_params()
http://git.linuxtv.org/media_tree.git/commit/80d8d4985f280dca3c395286d13b49f910a029e7
[SNIP]
/* Infineon TUA6034
* used in LG TDTP E102P
*/
-static void tua6034_bw(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
{
- if (BANDWIDTH_7_MHZ != params-u.ofdm.bandwidth)
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 700)
buf[3] |= 0x08;
}
[/SNIP]
so here is a patch to fix this typo to get the Skymaster DTMU100
(HANFTEK UMT010 OEM BOX)
working again.
Arne
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=51011
diff -Naur linux-3.7-rc7-org/drivers/media/dvb-frontends/dvb-pll.c
linux-3.7-rc7/drivers/media/dvb-frontends/dvb-pll.c
--- linux-3.7-rc7-org/drivers/media/dvb-frontends/dvb-pll.c 2012-11-26
02:59:19.0 +0100
+++ linux-3.7-rc7/drivers/media/dvb-frontends/dvb-pll.c 2012-11-27
09:45:16.736775252 +0100
@@ -247,7 +247,7 @@
static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
{
u32 bw = fe-dtv_property_cache.bandwidth_hz;
- if (bw == 700)
+ if (bw != 700)
buf[3] |= 0x08;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: First draft of guidelines for submitting patches to linux-media
Hi all, As discussed in Barcelona I would write a text describing requirements for new drivers and what to expect when submitting patches to linux-media. This is a first rough draft and nothing is fixed yet. I have a few open questions: 1) Where to put it? One thing I would propose that we improve is to move the dvb and video4linux directories in Documentation/ to Documentation/media to correctly reflect the drivers/media structure. If we do that, then we can put this document in Documentation/media/SubmittingMediaPatches. Alternatively, this is something we can document in our wiki. 2) Are there DVB requirements as well for new drivers? We discussed a list of V4L2 requirements in Barcelona, but I wonder if there is a similar list that can be made for DVB drivers. Input on that will be welcome. 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. 4) In Barcelona we discussed 'tags' for patches to help organize them. I've made a proposal for those in this document. Feedback is very welcome. 5) As discussed in Barcelona there will be git tree maintainers for specific platforms, but we didn't really go into detail who would be responsible for which platform. If you want to maintain a particular platform, then please let me know. 6) The patchwork section is very short at the moment. It should be extended when patchwork gets support to recognize the various tags. 7) Anything else that should be discussed here? Again, remember that this is a rough draft only, so be gentle with me :-) Regards, Hans --- cut here --- General Information === For general information on how to submit patches see: http://linuxtv.org/wiki/index.php/Developer_Section In particular the section 'Submitting Your Work'. This document goes into more detail regarding media specific requirements when submitting patches and what the patch flow looks like in this subsystem. Submitting New Media Drivers When submitting new media drivers for inclusion in drivers/staging/media all that is required is that the driver compiles with the latest kernel and that an entry is added to the MAINTAINERS file. For inclusion as a non-staging driver the requirements are more strict: General requirements: - It must pass checkpatch.pl, but see the note regarding interpreting the output from checkpatch below. - An entry for the driver is added to the MAINTAINERS file. V4L2 specific requirements: - Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for sub-device drivers. - Use the control framework for control handling. - Use struct v4l2_fh if the driver supports events (implied by the use of controls) or priority handling. - Use videobuf2 for buffer handling. Mike Krufky will look into extending vb2 to support DVB buffers. Note: using vb2 for VBI devices has not been tested yet, but it should work. Please contact the mailinglist in case of problems with that. - Must pass the v4l2-compliance tests. DVB specific requirements: TBD How to deal with checkpatch.pl? === First of all, the requirement to comply to the kernel coding style is there for a reason. Sometimes people feel that it is a pointless exercise: after all, code is code, right? Why would just changing some spacing improve it? But the coding style is not there to help you (at least, not directly), it is there to help those who have to review and/or maintain your code as it takes a lot of time to review code or try to figure out how someone else's code works. By at least ensuring that the coding style is consistent with other code we can concentrate on what humans to best: pattern matching. Ever read a book or article that did not use the correct spelling, grammar and/or punctuation rules? Did you notice how your brain 'stumbles' whenever it encounters such mistakes? It makes the text harder to understand and slower to read. The same happens with code that does not comply to the conventions of the project and it is the reason why most large projects, both open source and proprietary, have a coding style. However, when interpreting the checkpatch output it is good to remember that it is just an automated tool and there are cases where what checkpatch recommends does not actually results in the best readable code. This is particularly true for the line length warnings. A warning that a line is 82 characters long can probably be ignored, since breaking up such a line will usually make the code harder to understand. A warning that a line is 101 characters long definitely needs attention, since that's an indication that the line is really too long. The guideline here is to check such warnings, but use common sense whether or not to fix them. Please do run checkpatch before posting any code to the mailinglist. Code that
[PATCH RFC 0/2] V4L: Add auto focus area control and selection
This set of patches is created by Sylwester Nawrocki, with small changes by me. This set of patches extends the camera class with control V4L2_CID_AUTO_FOCUS_AREA for determining the area of the frame that camera uses for auto-focus. The control takes care of three cases: - V4L2_AUTO_FOCUS_AREA_ALL, normal auto-focus, whole frame is used for auto-focus, - V4L2_AUTO_FOCUS_AREA_RECTANGLE, user provides rectangle or spot as an area of interest, - V4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION, object/face detection engine of the camera should be used for auto-focus. In case of the rectangle or the spot its coordinates shall be passed to the driver using selection API (VIDIOC_SUBDEV_S_SELECTION) with V4L2_SEL_TGT_AUTO_FOCUS as a target name. In case of spot width and height of the rectangle shall be set to 0. We (me and Sylwester) are not sure if this is the best solution. I would like to propose another solution which seems to me more natural, but probably it would require extending controls API. The solution is neither formalized, neither implemented at the moment. The solution takes an advantage of the fact VIDIOC_(G/S/TRY)_EXT_CTRLS ioctls can be called with multiple controls per call. There could be added four pseudo-controls, lets call them for short: LEFT, TOP, WIDTH, HEIGHT. Those controls could be passed together with V4L2_AUTO_FOCUS_AREA_RECTANGLE control in one ioctl as a kind of control parameters. For example setting auto-focus spot would require calling VIDIOC_S_EXT_CTRLS with the following controls: - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_RECTANGLE - LEFT = ... - RIGHT = ... Setting AF rectangle: - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_RECTANGLE - LEFT = ... - TOP = ... - WIDTH = ... - HEIGHT = ... Setting AF object detection: - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION I have presented all three cases to show the advantages of this solution: - atomicity - control and its parameters are passed in one call, - flexibility - we are not limited by a fixed number of parameters, - no-redundancy(?) - we can pass only required parameters (no need to pass null width and height in case of spot selection), - extensibility - it is possible to extend parameters in the future, for example add parameters to V4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION, - backward compatibility, - re-usability - this schema could be used in other controls, pseudo-controls could be re-used in other controls as well. I hope this e-mail will trigger some discussion about the proposed solution. Regards Andrzej Hajda -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 2/2] V4L: Add V4L2_CID_AUTO_FOCUS_AREA control
From: Sylwester Nawrocki s.nawro...@samsung.com Add control for automatic focus area selection. This control determines the area of the frame that the camera uses for automatic focus. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Andrzej Hajda a.ha...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/compat.xml |9 +++-- Documentation/DocBook/media/v4l/controls.xml | 47 +- Documentation/DocBook/media/v4l/v4l2.xml |7 drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++ include/uapi/linux/v4l2-controls.h |6 5 files changed, 76 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 4fdf6b5..e8b53da 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2452,8 +2452,9 @@ that used it. It was originally scheduled for removal in 2.6.35. constantV4L2_CID_3A_LOCK/constant, constantV4L2_CID_AUTO_FOCUS_START/constant, constantV4L2_CID_AUTO_FOCUS_STOP/constant, - constantV4L2_CID_AUTO_FOCUS_STATUS/constant and - constantV4L2_CID_AUTO_FOCUS_RANGE/constant. + constantV4L2_CID_AUTO_FOCUS_STATUS/constant, + constantV4L2_CID_AUTO_FOCUS_RANGE/constant and + constantV4L2_CID_AUTO_FOCUS_AREA/constant. /para /listitem /orderedlist @@ -2586,6 +2587,10 @@ ioctls./para paraVendor and device specific media bus pixel formats. xref linkend=v4l2-mbus-vendor-spec-fmts /./para /listitem +listitem + paralink linkend=v4l2-auto-focus-areaconstant + V4L2_CID_AUTO_FOCUS_AREA/constant/link control./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1..9d4af8a 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3347,6 +3347,51 @@ use its minimum possible distance for auto focus./entry /row rowentry/entry/row + row id=v4l2-auto-focus-area + entry spanname=id + constantV4L2_CID_AUTO_FOCUS_AREA/constantnbsp;/entry + entryenumnbsp;v4l2_auto_focus_area/entry + /row + rowentry spanname=descrDetermines the area of the frame that +the camera uses for automatic focus. The corresponding coordinates of the +focusing spot or rectangle can be specified and queried using the selection API. +To change the auto focus region of interest applications first select required +mode of this control and then set the rectangle or spot coordinates by means +of the VIDIOC-SUBDEV-S-SELECTION; or VIDIOC-S-SELECTION; ioctl. In order to +trigger again a one shot auto focus with same coordinates applications should +use the constantV4L2_CID_AUTO_FOCUS_START /constant control. Or alternatively +invoke a VIDIOC-SUBDEV-S-SELECTION; or a VIDIOC-S-SELECTION; ioctl again. +In the latter case the new pixel coordinates are applied to hardware only when +the focus area control was set to +constantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constant./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_AUTO_FOCUS_AREA_ALL/constantnbsp;/entry + entryNormal auto focus, the focusing area extends over the +entire frame./entry + /row + row + entryconstantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constantnbsp;/entry + entryThe auto focus region of interest is determined by the +constantV4L2_SEL_TGT_AUTO_FOCUS/constant selection rectangle./entry + /row + row + entryconstantV4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION/constantnbsp;/entry + entryThe auto focus region of interest is determined +by an object (e.g. face) detection engine./entry + /row + /tbody + /entrytbl + /row + rowentry spanname=descr + This is an link linkend=experimentalexperimental/link +control and may change in the future./entry + /row + rowentry/entry/row + row entry spanname=idconstantV4L2_CID_ZOOM_ABSOLUTE/constantnbsp;/entry entryinteger/entry @@ -3986,7 +4031,7 @@ interface and may change in the future./para table pgwide=1 frame=none id=flash-control-id titleFlash Control IDs/title - + tgroup cols=4 colspec colname=c1 colwidth=1* / colspec colname=c2 colwidth=6* / diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 10ccde9..1477540 100644 ---
[PATCHv2] saa7134: Add pm_qos_request to fix video corruption
The SAA7134 appears to have trouble buffering more than one line of video
when doing DMA. Rather than try to fix the driver to cope (as has been done
by Andy Walls for the cx18 driver), put in a pm_qos_request to limit deep
sleep exit latencies.
The visible effect of not having this is that seemingly random lines are
only partly transferred - if you feed in a static image, you see a portion
of the image flicker into place.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
v2 changes: Reduced the latency further, based on a functional block level
datasheet. Comment updated to match.
As noted in the comment, I can't check this in detail.
My SandyBridge systems convert any value less than about 80 usec into 0
usec, as that's the hardware latency from the lightest deep sleep state, and
I'm not aware of any hardware that would let me set the latency directly.
If someone has register-level documentation for the SAA7134, checking our
FIFO configuration and matching the DMA latency to it would be useful.
drivers/media/pci/saa7134/saa7134-video.c | 13 +
drivers/media/pci/saa7134/saa7134.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index 4a77124..3f4a2a6 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2248,6 +2248,17 @@ static int saa7134_streamon(struct file *file, void
*priv,
if (!res_get(dev, fh, res))
return -EBUSY;
+ /* The SAA7134 has a 1K FIFO; the datasheet suggests that when
+* configured conservatively, there's 22 usec of buffering for video.
+ * We therefore request a DMA latency of 20 usec, giving us 2 usec of
+ * margin in case the FIFO is configured differently to the datasheet.
+ * Unfortunately, I lack register-level documentation to check the
+ * Linux FIFO setup and confirm the perfect value.
+*/
+ pm_qos_add_request(fh-qos_request,
+ PM_QOS_CPU_DMA_LATENCY,
+ 20);
+
return videobuf_streamon(saa7134_queue(fh));
}
@@ -2259,6 +2270,8 @@ static int saa7134_streamoff(struct file *file, void
*priv,
struct saa7134_dev *dev = fh-dev;
int res = saa7134_resource(fh);
+ pm_qos_remove_request(fh-qos_request);
+
err = videobuf_streamoff(saa7134_queue(fh));
if (err 0)
return err;
diff --git a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
index c24b651..d09393b 100644
--- a/drivers/media/pci/saa7134/saa7134.h
+++ b/drivers/media/pci/saa7134/saa7134.h
@@ -29,6 +29,7 @@
#include linux/notifier.h
#include linux/delay.h
#include linux/mutex.h
+#include linux/pm_qos_params.h
#include asm/io.h
@@ -469,6 +470,7 @@ struct saa7134_fh {
enum v4l2_buf_type type;
unsigned int resources;
enum v4l2_priority prio;
+ struct pm_qos_request_list qos_request;
/* video overlay */
struct v4l2_window win;
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] fix tua6034 pll bandwich configuration [3rd and last attempt]
On Mon, 10 Dec 2012, Arne Fitzenreiter wrote:
i have already send this patch twice and the mailing list but get no response.
(Three weeks delay between the mails).
Why mail mails are ignored?
I have no idea, but I'd like to have this taken through media tree rather
than trivial.
Adding Mauro to CC.
The tua6034 pll is corrupted by commit [media] dvb-pll: use DVBv5 parameters
on set_params()
http://git.linuxtv.org/media_tree.git/commit/80d8d4985f280dca3c395286d13b49f910a029e7
[SNIP]
/* Infineon TUA6034
* used in LG TDTP E102P
*/
-static void tua6034_bw(struct dvb_frontend *fe, u8 *buf,
- const struct dvb_frontend_parameters *params)
+static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
{
- if (BANDWIDTH_7_MHZ != params-u.ofdm.bandwidth)
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 700)
buf[3] |= 0x08;
}
[/SNIP]
so here is a patch to fix this typo to get the Skymaster DTMU100 (HANFTEK
UMT010 OEM BOX)
working again.
Arne
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=51011
diff -Naur linux-3.7-rc7-org/drivers/media/dvb-frontends/dvb-pll.c
linux-3.7-rc7/drivers/media/dvb-frontends/dvb-pll.c
--- linux-3.7-rc7-org/drivers/media/dvb-frontends/dvb-pll.c 2012-11-26
02:59:19.0 +0100
+++ linux-3.7-rc7/drivers/media/dvb-frontends/dvb-pll.c 2012-11-27
09:45:16.736775252 +0100
@@ -247,7 +247,7 @@
static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
{
u32 bw = fe-dtv_property_cache.bandwidth_hz;
- if (bw == 700)
+ if (bw != 700)
buf[3] |= 0x08;
}
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
Am 09.12.2012 18:53, schrieb Matthew Gyurgyik: On 12/09/2012 12:06 PM, Frank Schäfer wrote: Forget this sh... (never do multiple things at the same time ;) ) Reg 0x50 is set to according to rc_type specified in the selected remote control map. So if the correct map is selected, everything should be fine (as long as it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet). RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so the stick seems to use no NEC protocol. Matthew, insert a line ir_config = 0x01; before 380em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, ir_config, 1); in em28xx-input.c and see if something shows up in the dmesg output. Regards, Frank That seems to be a bit more successful! Here is the dmesg output: [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2, key 0x61d6 I pressed all the buttons on the remote (40 buttons). Did you cut the dmesg output ? Or do you really get these messages for key 0x61d6 only ? It seems like things are working different with reg 0x50 = 0x01. Taking a look into the datasheet might help, but I don't have it. ;) Regards, Frank Thanks, Matthew -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer fschaefer@googlemail.com wrote: Am 09.12.2012 18:53, schrieb Matthew Gyurgyik: On 12/09/2012 12:06 PM, Frank Schäfer wrote: Forget this sh... (never do multiple things at the same time ;) ) Reg 0x50 is set to according to rc_type specified in the selected remote control map. So if the correct map is selected, everything should be fine (as long as it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet). RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so the stick seems to use no NEC protocol. Matthew, insert a line ir_config = 0x01; before 380em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, ir_config, 1); in em28xx-input.c and see if something shows up in the dmesg output. Regards, Frank That seems to be a bit more successful! Here is the dmesg output: [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2, key 0x61d6 I pressed all the buttons on the remote (40 buttons). Did you cut the dmesg output ? Or do you really get these messages for key 0x61d6 only ? It seems like things are working different with reg 0x50 = 0x01. Taking a look into the datasheet might help, but I don't have it. ;) Setting that bit turns off NEC parity checking. I don't think we've ever had a need for it before, which is why it isn't exposed as configurable functionality in the driver. No clear answer on how this should be fixed, if that's what is really required. I guess in theory we could introduce some new board config option, but that would likely interfere with the ability to reconfigure the RC protocol at runtime. An alternative would be a new property of the RC profile, but that would pollute the definition of the struct presumably to work around some bug in a crappy remote control. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: First draft of guidelines for submitting patches to linux-media
Am 10.12.2012 14:07, schrieb Hans Verkuil: snip 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. ... Reviewed-by/Acked-by Within the media subsystem there are three levels of maintainership: Mauro Carvalho Chehab is the maintainer of the whole subsystem and the DVB/V4L/IR/Media Controller core code in particular, then there are a number of submaintainers for specific areas of the subsystem: - Kamil Debski: codec (aka memory-to-memory) drivers - Hans de Goede: non-UVC USB webcam drivers - Mike Krufky: frontends/tuners/demodulators In addition he'll be the reviewer for DVB core patches. - Guennadi Liakhovetski: soc-camera drivers - Laurent Pinchart: sensor subdev drivers. In addition he'll be the reviewer for Media Controller core patches. - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video receivers and transmitters). In addition he'll be the reviewer for V4L2 core patches. Finally there are maintainers for specific drivers. This is documented in the MAINTAINERS file. When modifying existing code you need to get the Reviewed-by/Acked-by of the maintainer of that code. So CC that maintainer when posting patches. If said maintainer is unavailable then the submaintainer or even Mauro can accept it as well, but that should be the exception, not the rule. Once patches are accepted they will flow through the git tree of the submaintainer to the git tree of the maintainer (Mauro) who will do a final review. There are a few exceptions: code for certain platforms goes through git trees specific to that platform. The submaintainer will still review it and add a acked-by or reviewed-by line, but it will not go through the submaintainer's git tree. The platform maintainers are: TDB In case patches touch on areas that are the responsibility of multiple submaintainers, then they will decide among one another who will merge the patches. I've read this when the submaintainers take their place early next year, everything will be fine several times now. But can anyone please explain me what's going to change ? AFAICS, the above exactly describes the _current_ situation. We already have sub-maintainers, sub-trees etc, right !? And the people listed above are already doing the same job at the moment. Looking at patchwork, it seems we are behind at least 1 complete kernel release cycle. And the reason seems to be, that (at least some) maintainers don't have the resources to review them in time (no reproaches !). But to me this seems to be no structural problem. If a maintainer (permanently) doesn't have the time to review patches, he should leave maintainership to someone else. So the actual problem seems to be, that we don't have enough maintainers/reviewers, right ? snip Patchwork = Patchwork is an automated system that takes care of all posted patches. It can be found here: http://patchwork.linuxtv.org/project/linux-media/list/ If your patch does not appear in patchwork after [TBD], then check if you used the right patch tags and if your patch is formatted correctly (no HTML, no mangled lines). Whenever you patch changes state you'll get an email informing you about that. What if people send a V2 of a patch (series). Should they mark V1 as superseeded themselves ? And what about maintainers not using patchwork ? Are they nevertheless supposed to take care of the status of their patches ? Regards, Frank -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 2012-12-10 10:39, Frank Schäfer wrote: Am 09.12.2012 18:53, schrieb Matthew Gyurgyik: On 12/09/2012 12:06 PM, Frank Schäfer wrote: Forget this sh... (never do multiple things at the same time ;) ) Reg 0x50 is set to according to rc_type specified in the selected remote control map. So if the correct map is selected, everything should be fine (as long as it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet). RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so the stick seems to use no NEC protocol. Matthew, insert a line ir_config = 0x01; before 380em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, ir_config, 1); in em28xx-input.c and see if something shows up in the dmesg output. Regards, Frank That seems to be a bit more successful! Here is the dmesg output: [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2, key 0x61d6 I pressed all the buttons on the remote (40 buttons). Did you cut the dmesg output ? Or do you really get these messages for key 0x61d6 only ? Correct, I got these messages for key 0x61d6 regardless of the physical key pressed. It seems like things are working different with reg 0x50 = 0x01. Taking a look into the datasheet might help, but I don't have it. ;) Regards, Frank Thanks, Matthew -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
Am 10.12.2012 16:46, schrieb Devin Heitmueller: On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer fschaefer@googlemail.com wrote: Am 09.12.2012 18:53, schrieb Matthew Gyurgyik: On 12/09/2012 12:06 PM, Frank Schäfer wrote: Forget this sh... (never do multiple things at the same time ;) ) Reg 0x50 is set to according to rc_type specified in the selected remote control map. So if the correct map is selected, everything should be fine (as long as it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet). RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so the stick seems to use no NEC protocol. Matthew, insert a line ir_config = 0x01; before 380em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, ir_config, 1); in em28xx-input.c and see if something shows up in the dmesg output. Regards, Frank That seems to be a bit more successful! Here is the dmesg output: [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6 em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2, key 0x61d6 I pressed all the buttons on the remote (40 buttons). Did you cut the dmesg output ? Or do you really get these messages for key 0x61d6 only ? It seems like things are working different with reg 0x50 = 0x01. Taking a look into the datasheet might help, but I don't have it. ;) Setting that bit turns off NEC parity checking. I don't think we've ever had a need for it before, which is why it isn't exposed as configurable functionality in the driver. No clear answer on how this should be fixed, if that's what is really required. I guess in theory we could introduce some new board config option, but that would likely interfere with the ability to reconfigure the RC protocol at runtime. An alternative would be a new property of the RC profile, but that would pollute the definition of the struct presumably to work around some bug in a crappy remote control. Adding a new property to the RC profile certainly seems to be the cleanest solution. Do all protocols have paritiy checking ? Otherwise we could add a new type RC_TYPE_NEC_NO_PARITY. OTOH, introducing a new bitfield in struct rc_map might be usefull for other flags, too, in the future... Regards, Frank Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer Adding a new property to the RC profile certainly seems to be the cleanest solution. Do all protocols have paritiy checking ? Otherwise we could add a new type RC_TYPE_NEC_NO_PARITY. OTOH, introducing a new bitfield in struct rc_map might be usefull for other flags, too, in the future... It's probably also worth mentioning that in that mode the device reports four bytes, not two. I guess perhaps if parity is ignored it reports the data in some other format? You will probably have to do some experimentation there. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: First draft of guidelines for submitting patches to linux-media
On Mon December 10 2012 16:56:16 Frank Schäfer wrote: Am 10.12.2012 14:07, schrieb Hans Verkuil: snip 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. ... Reviewed-by/Acked-by Within the media subsystem there are three levels of maintainership: Mauro Carvalho Chehab is the maintainer of the whole subsystem and the DVB/V4L/IR/Media Controller core code in particular, then there are a number of submaintainers for specific areas of the subsystem: - Kamil Debski: codec (aka memory-to-memory) drivers - Hans de Goede: non-UVC USB webcam drivers - Mike Krufky: frontends/tuners/demodulators In addition he'll be the reviewer for DVB core patches. - Guennadi Liakhovetski: soc-camera drivers - Laurent Pinchart: sensor subdev drivers. In addition he'll be the reviewer for Media Controller core patches. - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video receivers and transmitters). In addition he'll be the reviewer for V4L2 core patches. Finally there are maintainers for specific drivers. This is documented in the MAINTAINERS file. When modifying existing code you need to get the Reviewed-by/Acked-by of the maintainer of that code. So CC that maintainer when posting patches. If said maintainer is unavailable then the submaintainer or even Mauro can accept it as well, but that should be the exception, not the rule. Once patches are accepted they will flow through the git tree of the submaintainer to the git tree of the maintainer (Mauro) who will do a final review. There are a few exceptions: code for certain platforms goes through git trees specific to that platform. The submaintainer will still review it and add a acked-by or reviewed-by line, but it will not go through the submaintainer's git tree. The platform maintainers are: TDB In case patches touch on areas that are the responsibility of multiple submaintainers, then they will decide among one another who will merge the patches. I've read this when the submaintainers take their place early next year, everything will be fine several times now. I doubt everything will be fine, but I sure hope it will be better at least. In other words, don't expect miracles :-) But can anyone please explain me what's going to change ? AFAICS, the above exactly describes the _current_ situation. We already have sub-maintainers, sub-trees etc, right !? And the people listed above are already doing the same job at the moment. Looking at patchwork, it seems we are behind at least 1 complete kernel release cycle. And the reason seems to be, that (at least some) maintainers don't have the resources to review them in time (no reproaches !). But to me this seems to be no structural problem. If a maintainer (permanently) doesn't have the time to review patches, he should leave maintainership to someone else. So the actual problem seems to be, that we don't have enough maintainers/reviewers, right ? The main problem is that all the work is done by Mauro. Sure, people help out with reviews but a lot of the final administrative and merge effort is done by one person only. In particular the patch flow is something he can't keep up with anymore. So by assigning official submaintainers who get access to patchwork and can process patches quickly we hope that his job will become a lot easier. So the core two changes are 1) giving clear responsibilities to submaintainers and 2) giving submaintainers access to patchwork to keep track of the patches. So patch submitters no longer have to wait until Mauro gets around to cleaning out patchwork. Instead the submaintainers can do that themselves and collect accepted patches in their git tree and post regular pull requests for Mauro. It should simplify things substantially for Mauro, we hope. I think we have enough people doing reviews etc. (although more are always welcome), it's the patchflow itself that is the problem. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
integrated webcam on Dell Latitude E6530 (Microdia)
Hello the list, I am not sure I post this in the appropriate list, but it looks like... I apologize if I'm wrong. I am running Debian sid on a Linux 3.6.6 kernel on my Dell Latitude E6530. Its builtin camera appears to be Microdia, this is what lsusb says. Briefly: idVendor 0x0c45 Microdia idProduct 0x648b bcdDevice 28.07 iManufacturer 2 CNFB183I41201ML2 iProduct1 Laptop_Integrated_Webcam_E4HD When I grep /var/log/kern.log for any line related to this stuff, nothing shows. In my kernel the support for V4L USB devices is built-in, and inside this I built USB Video Class (UVC) as a module, and the GSPCA based webcams are also as modules. Maybe you know which type of hardware is my Camera, and then help me...? FYI, Carlo Hamalainenen recenlty reported (http://carlo-hamalainen.net/blog/2012/11/12/debian-on-dell-latitude-e6530/) that the same camera was working just fine with a 3.2.33 but not on his 3.6.6 kernel. Thanks! JB (I'm using this integrated Opera newsreader for the first time, can't figure out which address it will use as a sender address, but in case something weird happens, my address is domelevo at gmail.) -- Using Opera's mail client: http://www.opera.com/mail/ -- 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 RFC 06/11] az6007: make remote controller optional
Em 09-12-2012 22:45, Antti Palosaari escreveu:
Do not compile remote controller when RC-core is disabled by Kconfig.
Cc: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Antti Palosaari cr...@iki.fi
Seems OK for me.
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/usb/dvb-usb-v2/az6007.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/az6007.c
b/drivers/media/usb/dvb-usb-v2/az6007.c
index d75dbf2..3b33f1e 100644
--- a/drivers/media/usb/dvb-usb-v2/az6007.c
+++ b/drivers/media/usb/dvb-usb-v2/az6007.c
@@ -189,6 +189,7 @@ static int az6007_streaming_ctrl(struct dvb_frontend *fe,
int onoff)
return az6007_write(d, 0xbc, onoff, 0, NULL, 0);
}
+#if defined(CONFIG_RC_CORE) || defined(CONFIG_RC_CORE_MODULE)
/* remote control stuff (does not work with my box) */
static int az6007_rc_query(struct dvb_usb_device *d)
{
@@ -215,6 +216,20 @@ static int az6007_rc_query(struct dvb_usb_device *d)
return 0;
}
+static int az6007_get_rc_config(struct dvb_usb_device *d, struct dvb_usb_rc
*rc)
+{
+ pr_debug(Getting az6007 Remote Control properties\n);
+
+ rc-allowed_protos = RC_BIT_NEC;
+ rc-query = az6007_rc_query;
+ rc-interval = 400;
+
+ return 0;
+}
+#else
+ #define az6007_get_rc_config NULL
+#endif
+
static int az6007_ci_read_attribute_mem(struct dvb_ca_en50221 *ca,
int slot,
int address)
@@ -822,17 +837,6 @@ static void az6007_usb_disconnect(struct usb_interface
*intf)
dvb_usbv2_disconnect(intf);
}
-static int az6007_get_rc_config(struct dvb_usb_device *d, struct dvb_usb_rc
*rc)
-{
- pr_debug(Getting az6007 Remote Control properties\n);
-
- rc-allowed_protos = RC_BIT_NEC;
- rc-query = az6007_rc_query;
- rc-interval = 400;
-
- return 0;
-}
-
static int az6007_download_firmware(struct dvb_usb_device *d,
const struct firmware *fw)
{
--
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: First draft of guidelines for submitting patches to linux-media
Em Mon, 10 Dec 2012 17:27:29 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Mon December 10 2012 16:56:16 Frank Schäfer wrote: Am 10.12.2012 14:07, schrieb Hans Verkuil: snip 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. ... Reviewed-by/Acked-by Within the media subsystem there are three levels of maintainership: Mauro Carvalho Chehab is the maintainer of the whole subsystem and the DVB/V4L/IR/Media Controller core code in particular, then there are a number of submaintainers for specific areas of the subsystem: - Kamil Debski: codec (aka memory-to-memory) drivers - Hans de Goede: non-UVC USB webcam drivers - Mike Krufky: frontends/tuners/demodulators In addition he'll be the reviewer for DVB core patches. - Guennadi Liakhovetski: soc-camera drivers - Laurent Pinchart: sensor subdev drivers. In addition he'll be the reviewer for Media Controller core patches. - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video receivers and transmitters). In addition he'll be the reviewer for V4L2 core patches. Finally there are maintainers for specific drivers. This is documented in the MAINTAINERS file. When modifying existing code you need to get the Reviewed-by/Acked-by of the maintainer of that code. So CC that maintainer when posting patches. If said maintainer is unavailable then the submaintainer or even Mauro can accept it as well, but that should be the exception, not the rule. Once patches are accepted they will flow through the git tree of the submaintainer to the git tree of the maintainer (Mauro) who will do a final review. There are a few exceptions: code for certain platforms goes through git trees specific to that platform. The submaintainer will still review it and add a acked-by or reviewed-by line, but it will not go through the submaintainer's git tree. The platform maintainers are: TDB In case patches touch on areas that are the responsibility of multiple submaintainers, then they will decide among one another who will merge the patches. I've read this when the submaintainers take their place early next year, everything will be fine several times now. I doubt everything will be fine, but I sure hope it will be better at least. In other words, don't expect miracles :-) But can anyone please explain me what's going to change ? AFAICS, the above exactly describes the _current_ situation. We already have sub-maintainers, sub-trees etc, right !? And the people listed above are already doing the same job at the moment. Looking at patchwork, it seems we are behind at least 1 complete kernel release cycle. No, this is not true; git pull requests are typically handled faster, as the material there is submitted either by a driver maintainer or by a sub-maintainer. The delay there for -git is currently 2 weeks, as we closed our merge window at the beginning of -rc7 (expecting that there won't be a -rc8). The very large of individual patches have a longer delays, due to the lack of driver maintainers reviews. And the reason seems to be, that (at least some) maintainers don't have the resources to review them in time (no reproaches !). But to me this seems to be no structural problem. If a maintainer (permanently) doesn't have the time to review patches, he should leave maintainership to someone else. Agreed. So the actual problem seems to be, that we don't have enough maintainers/reviewers, right ? The main problem is that all the work is done by Mauro. Sure, people help out with reviews but a lot of the final administrative and merge effort is done by one person only. In particular the patch flow is something he can't keep up with anymore. So by assigning official submaintainers who get access to patchwork and can process patches quickly we hope that his job will become a lot easier. So the core two changes are 1) giving clear responsibilities to submaintainers and 2) giving submaintainers access to patchwork to keep track of the patches. So patch submitters no longer have to wait until Mauro gets around to cleaning out patchwork. Instead the submaintainers can do that themselves and collect accepted patches in their git tree and post regular pull requests for Mauro. It should simplify things substantially for Mauro, we hope. I think we have enough people doing reviews etc. (although more are always welcome), it's the patchflow itself that is the problem. Yeah, the issue is that both reviewed, non-reviewed and rejected/commented patches go into the very same queue, forcing me to revisit each patch again, even the rejected/commented ones, and the previous versions
Re: RFC: First draft of guidelines for submitting patches to linux-media
On 12/10/2012 07:38 PM, Mauro Carvalho Chehab wrote: Yeah, the issue is that both reviewed, non-reviewed and rejected/commented patches go into the very same queue, forcing me to revisit each patch again, even the rejected/commented ones, and the previous versions of newer patches. By giving rights and responsibilities to the sub-maintainers to manage their stuff directly at patchwork, those patches that tend to stay at patchwork for a long time will likely disappear, and the queue will be cleaner. Is there any change module maintainer responsibility of patch could do what ever he likes to given patch in patchwork? I have looked it already many times but I can drop only my own patches. If someone sends patch to my driver X and I pick it up my GIT tree I would like to mark it superseded for patchwork (which is not possible currently). regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/10/2012 06:13 PM, Devin Heitmueller wrote: On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer Adding a new property to the RC profile certainly seems to be the cleanest solution. Do all protocols have paritiy checking ? Otherwise we could add a new type RC_TYPE_NEC_NO_PARITY. OTOH, introducing a new bitfield in struct rc_map might be usefull for other flags, too, in the future... It's probably also worth mentioning that in that mode the device reports four bytes, not two. I guess perhaps if parity is ignored it reports the data in some other format? You will probably have to do some experimentation there. Uh, current em28xx NEC implementation is locked to traditional 16 bit NEC, where is hw checksum used. Implementation should be changed to more general to support 24 and 32 bit NEC too. There is multiple drivers doing already that, for example AF9015. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kworld PCI Analog TV Card Lite PVR-7134SE
Can anybody help setting up this card? I posted details in an earlier message but got no response. This list is my last hope to get this thing working. Regards, Saad -- 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: First draft of guidelines for submitting patches to linux-media
Em Mon, 10 Dec 2012 14:07:09 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi all, As discussed in Barcelona I would write a text describing requirements for new drivers and what to expect when submitting patches to linux-media. This is a first rough draft and nothing is fixed yet. I have a few open questions: 1) Where to put it? Maybe at media-build.git. I'm thinking on putting there, under devel_contrib, the main scripts I use here to handle patches. /me needs some time to sanitize them and add there. One thing I would propose that we improve is to move the dvb and video4linux directories in Documentation/ to Documentation/media to correctly reflect the drivers/media structure. If we do that, then we can put this document in Documentation/media/SubmittingMediaPatches. Hmm... I don't see any other subsystems having their own document for that. We may need to discuss it upstream before doing that, and be prepared to answer why we thing sub-systems would need their own rules there. In any case, I think that the better is to store it at media-build.git tree, and later open such discussions upstream, if we think it is valuable enough. Alternatively, this is something we can document in our wiki. 2) Are there DVB requirements as well for new drivers? We discussed a list of V4L2 requirements in Barcelona, but I wonder if there is a similar list that can be made for DVB drivers. Input on that will be welcome. See below. 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. 4) In Barcelona we discussed 'tags' for patches to help organize them. I've made a proposal for those in this document. Feedback is very welcome. 5) As discussed in Barcelona there will be git tree maintainers for specific platforms, but we didn't really go into detail who would be responsible for which platform. If you want to maintain a particular platform, then please let me know. 6) The patchwork section is very short at the moment. It should be extended when patchwork gets support to recognize the various tags. 7) Anything else that should be discussed here? Again, remember that this is a rough draft only, so be gentle with me :-) Regards, Hans --- cut here --- General Information === For general information on how to submit patches see: http://linuxtv.org/wiki/index.php/Developer_Section In particular the section 'Submitting Your Work'. This document goes into more detail regarding media specific requirements when submitting patches and what the patch flow looks like in this subsystem. I think we should add a paragraph here saying that rules may have exceptions, when there's a clear reason why a certain submission should need a different criteria. Also, IMHO, we should add a notice that this list is not exhaustive, and may be changed, keeping it for at least one or two Kernel cycles, while it doesn't get proofed/matured, as I'm sure we'll forget things. Submitting New Media Drivers When submitting new media drivers for inclusion in drivers/staging/media all that is required is that the driver compiles with the latest kernel and that an entry is added to the MAINTAINERS file Please add: and what is missing there for it to be promoted to be a main driver is documented at the TODO file. It should be noticed, however, that it is expected that the driver will be fixed to fulfill the requirements for upstream addition. If a driver at staging lacks relevant patches fixing it for more than a kernel cycle, it can be dropped without further notice. For inclusion as a non-staging driver the requirements are more strict: General requirements: - It must pass checkpatch.pl, but see the note regarding interpreting the output from checkpatch below. - An entry for the driver is added to the MAINTAINERS file. Please add: - Properly use the kernel internal APIs; - Should re-invent the wheel, by adding new defines, math logic, etc that already exists in the Kernel; - Errors should be reported as negative numbers, using the Kernel error codes; - typedefs should't be used; V4L2 specific requirements: - Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for sub-device drivers. Please add: - each I2C chip should be mapped as a separate sub-device driver; - Use the control framework for control handling. - Use struct v4l2_fh if the driver supports events (implied by the use of controls) or priority handling. - Use videobuf2 for buffer handling. Mike Krufky will look into extending vb2 to support DVB buffers. Note: using vb2 for VBI devices has not been tested yet, but it should work. Please contact the mailinglist in case of problems with that. - Must pass the v4l2-compliance
Re: RFC: First draft of guidelines for submitting patches to linux-media
Em Mon, 10 Dec 2012 19:45:40 +0200 Antti Palosaari cr...@iki.fi escreveu: On 12/10/2012 07:38 PM, Mauro Carvalho Chehab wrote: Yeah, the issue is that both reviewed, non-reviewed and rejected/commented patches go into the very same queue, forcing me to revisit each patch again, even the rejected/commented ones, and the previous versions of newer patches. By giving rights and responsibilities to the sub-maintainers to manage their stuff directly at patchwork, those patches that tend to stay at patchwork for a long time will likely disappear, and the queue will be cleaner. Is there any change module maintainer responsibility of patch could do what ever he likes to given patch in patchwork? I have looked it already many times but I can drop only my own patches. If someone sends patch to my driver X and I pick it up my GIT tree I would like to mark it superseded for patchwork (which is not possible currently). Patchwork's ACL is very limited. It has 3 types there: - People (every email it detects); - User (the ones that created a password); - Project maintainers; A people can't do anything special, except be promoted to users, by setting a password for him. An user can only set his emails, enable/disable opt-out/opt-in, set his primary project and the number of patches per page. The Project maintainers can do everything in the project. It would be great to have a feature there allowing the user to change the status of their own patches, and to let the project maintainers to delegate a patch to an user[1]. [1] well, I think it can delegate it right now, but only a project maintainer can change the patch status, so, delegation doesn't work if the delegated user is not a project owner. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 08/11] it913x: remove unused define and increase module version
On Mon, 2012-12-10 at 02:45 +0200, Antti Palosaari wrote:
Cc: Malcolm Priestley tvbox...@gmail.com
Signed-off-by: Antti Palosaari cr...@iki.fi
---
Acked-by: Malcolm Priestley tvbox...@gmail.com
drivers/media/usb/dvb-usb-v2/it913x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/it913x.c
b/drivers/media/usb/dvb-usb-v2/it913x.c
index 5dc352b..3d20e38 100644
--- a/drivers/media/usb/dvb-usb-v2/it913x.c
+++ b/drivers/media/usb/dvb-usb-v2/it913x.c
@@ -309,7 +309,6 @@ static struct i2c_algorithm it913x_i2c_algo = {
/* Callbacks for DVB USB */
#if defined(CONFIG_RC_CORE) || defined(CONFIG_RC_CORE_MODULE)
-#define IT913X_POLL 250
static int it913x_rc_query(struct dvb_usb_device *d)
{
u8 ibuf[4];
@@ -801,7 +800,7 @@ module_usb_driver(it913x_driver);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.32);
+MODULE_VERSION(1.33);
MODULE_LICENSE(GPL);
MODULE_FIRMWARE(FW_IT9135_V1);
MODULE_FIRMWARE(FW_IT9135_V2);
--
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: First draft of guidelines for submitting patches to linux-media
Am 10.12.2012 18:38, schrieb Mauro Carvalho Chehab: Em Mon, 10 Dec 2012 17:27:29 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Mon December 10 2012 16:56:16 Frank Schäfer wrote: Am 10.12.2012 14:07, schrieb Hans Verkuil: snip 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. ... Reviewed-by/Acked-by Within the media subsystem there are three levels of maintainership: Mauro Carvalho Chehab is the maintainer of the whole subsystem and the DVB/V4L/IR/Media Controller core code in particular, then there are a number of submaintainers for specific areas of the subsystem: - Kamil Debski: codec (aka memory-to-memory) drivers - Hans de Goede: non-UVC USB webcam drivers - Mike Krufky: frontends/tuners/demodulators In addition he'll be the reviewer for DVB core patches. - Guennadi Liakhovetski: soc-camera drivers - Laurent Pinchart: sensor subdev drivers. In addition he'll be the reviewer for Media Controller core patches. - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video receivers and transmitters). In addition he'll be the reviewer for V4L2 core patches. Finally there are maintainers for specific drivers. This is documented in the MAINTAINERS file. When modifying existing code you need to get the Reviewed-by/Acked-by of the maintainer of that code. So CC that maintainer when posting patches. If said maintainer is unavailable then the submaintainer or even Mauro can accept it as well, but that should be the exception, not the rule. Once patches are accepted they will flow through the git tree of the submaintainer to the git tree of the maintainer (Mauro) who will do a final review. There are a few exceptions: code for certain platforms goes through git trees specific to that platform. The submaintainer will still review it and add a acked-by or reviewed-by line, but it will not go through the submaintainer's git tree. The platform maintainers are: TDB In case patches touch on areas that are the responsibility of multiple submaintainers, then they will decide among one another who will merge the patches. I've read this when the submaintainers take their place early next year, everything will be fine several times now. I doubt everything will be fine, but I sure hope it will be better at least. In other words, don't expect miracles :-) But can anyone please explain me what's going to change ? AFAICS, the above exactly describes the _current_ situation. We already have sub-maintainers, sub-trees etc, right !? And the people listed above are already doing the same job at the moment. Looking at patchwork, it seems we are behind at least 1 complete kernel release cycle. No, this is not true; git pull requests are typically handled faster, as the material there is submitted either by a driver maintainer or by a sub-maintainer. The delay there for -git is currently 2 weeks, as we closed our merge window at the beginning of -rc7 (expecting that there won't be a -rc8). But it's not git pull request vs. patches sent to the list directly, it's reviewed vs. not reviewed, right ? The very large of individual patches have a longer delays, due to the lack of driver maintainers reviews. That's what I said, the problem is that we lack maintainers/reviewers. And people beeing subsystem maintainers AND driver maintainers have to find a balance between processing pull requests and reviewing patches. I'm not sure if I have understood yet how this balance should look like... Can you elaborate a bit on this ? At the moment it's ~12 weeks / ~2 weeks. What's the target value ? ;) And the reason seems to be, that (at least some) maintainers don't have the resources to review them in time (no reproaches !). But to me this seems to be no structural problem. If a maintainer (permanently) doesn't have the time to review patches, he should leave maintainership to someone else. Agreed. So the actual problem seems to be, that we don't have enough maintainers/reviewers, right ? The main problem is that all the work is done by Mauro. Sure, people help out with reviews but a lot of the final administrative and merge effort is done by one person only. In particular the patch flow is something he can't keep up with anymore. So by assigning official submaintainers who get access to patchwork and can process patches quickly we hope that his job will become a lot easier. So the core two changes are 1) giving clear responsibilities to submaintainers and 2) giving submaintainers access to patchwork to keep track of the patches. So patch submitters no longer have to wait until Mauro gets around to cleaning out patchwork. Instead the submaintainers can do that themselves and collect accepted patches in their git tree and post regular pull requests for Mauro. It
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
Am 10.12.2012 18:57, schrieb Antti Palosaari: On 12/10/2012 06:13 PM, Devin Heitmueller wrote: On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer Adding a new property to the RC profile certainly seems to be the cleanest solution. Do all protocols have paritiy checking ? Otherwise we could add a new type RC_TYPE_NEC_NO_PARITY. OTOH, introducing a new bitfield in struct rc_map might be usefull for other flags, too, in the future... It's probably also worth mentioning that in that mode the device reports four bytes, not two. I guess perhaps if parity is ignored it reports the data in some other format? You will probably have to do some experimentation there. Uh, current em28xx NEC implementation is locked to traditional 16 bit NEC, where is hw checksum used. Implementation should be changed to more general to support 24 and 32 bit NEC too. There is multiple drivers doing already that, for example AF9015. Hmm... are there and documents (, links, books, ...) where I can learn more about all those RC protocols ? Regards Frank -- 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
EM2800 and audio via USB ?
Hi, does anyone know if the EM2800 is capable of delivering audio via USB ? AFAIK, it doesn't have AC97 included. I recently got some real legacy hardware: a Terratec Cinergy 200 USB (EM2800 + SAA7113 +TDA9887). This device has an audio line-in input (also SVIDEO + Composite), but no extra AC97 IC. I wonder how this is supposed to work (I actually can't get it working ;) ) Thanks, Frank -- 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: First draft of guidelines for submitting patches to linux-media
Em Mon, 10 Dec 2012 20:17:23 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 10.12.2012 18:38, schrieb Mauro Carvalho Chehab: Em Mon, 10 Dec 2012 17:27:29 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Mon December 10 2012 16:56:16 Frank Schäfer wrote: Am 10.12.2012 14:07, schrieb Hans Verkuil: snip 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. ... Reviewed-by/Acked-by Within the media subsystem there are three levels of maintainership: Mauro Carvalho Chehab is the maintainer of the whole subsystem and the DVB/V4L/IR/Media Controller core code in particular, then there are a number of submaintainers for specific areas of the subsystem: - Kamil Debski: codec (aka memory-to-memory) drivers - Hans de Goede: non-UVC USB webcam drivers - Mike Krufky: frontends/tuners/demodulators In addition he'll be the reviewer for DVB core patches. - Guennadi Liakhovetski: soc-camera drivers - Laurent Pinchart: sensor subdev drivers. In addition he'll be the reviewer for Media Controller core patches. - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video receivers and transmitters). In addition he'll be the reviewer for V4L2 core patches. Finally there are maintainers for specific drivers. This is documented in the MAINTAINERS file. When modifying existing code you need to get the Reviewed-by/Acked-by of the maintainer of that code. So CC that maintainer when posting patches. If said maintainer is unavailable then the submaintainer or even Mauro can accept it as well, but that should be the exception, not the rule. Once patches are accepted they will flow through the git tree of the submaintainer to the git tree of the maintainer (Mauro) who will do a final review. There are a few exceptions: code for certain platforms goes through git trees specific to that platform. The submaintainer will still review it and add a acked-by or reviewed-by line, but it will not go through the submaintainer's git tree. The platform maintainers are: TDB In case patches touch on areas that are the responsibility of multiple submaintainers, then they will decide among one another who will merge the patches. I've read this when the submaintainers take their place early next year, everything will be fine several times now. I doubt everything will be fine, but I sure hope it will be better at least. In other words, don't expect miracles :-) But can anyone please explain me what's going to change ? AFAICS, the above exactly describes the _current_ situation. We already have sub-maintainers, sub-trees etc, right !? And the people listed above are already doing the same job at the moment. Looking at patchwork, it seems we are behind at least 1 complete kernel release cycle. No, this is not true; git pull requests are typically handled faster, as the material there is submitted either by a driver maintainer or by a sub-maintainer. The delay there for -git is currently 2 weeks, as we closed our merge window at the beginning of -rc7 (expecting that there won't be a -rc8). But it's not git pull request vs. patches sent to the list directly, it's reviewed vs. not reviewed, right ? A patch reviewed by a sub-maintainer/driver maintainers typically goes to me via a git pull request. The very large of individual patches have a longer delays, due to the lack of driver maintainers reviews. That's what I said, the problem is that we lack maintainers/reviewers. We (used to) lack to have sub-maintainers formally (except for gspca and soc_camera). Even driver's maintainership is currently shady, as most drivers lack a MAINTAINERS entry. That is in the process of being fixed. And people beeing subsystem maintainers AND driver maintainers have to find a balance between processing pull requests and reviewing patches. I'm not sure if I have understood yet how this balance should look like... Can you elaborate a bit on this ? At the moment it's ~12 weeks / ~2 weeks. What's the target value ? ;) Please wait for it to be implemented before complaining it ;) The sub-maintainers new schema will start to work likely by Feb/Mar 2013. Also, the reviewing process is not equal to all patches: trivial patches can be merged quicker; core API changes should take a longer time, as it is expected to have more review before merging them. And the reason seems to be, that (at least some) maintainers don't have the resources to review them in time (no reproaches !). But to me this seems to be no structural problem. If a maintainer (permanently) doesn't have the time to review patches, he should leave maintainership to someone else. Agreed. So the actual problem seems
[PATCH RFC 12/13] v4l2-of: Corrected v4l2_of_parse_link() function declaration
v4l2_of_parse_link() return value type is int, not void.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/v4l2-of.h |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 9b036e6..686d04b 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -49,10 +49,13 @@ int v4l2_of_parse_data_lanes(const struct device_node *node,
struct device_node *v4l2_of_get_next_link(const struct device_node *parent,
struct device_node *previous);
struct device_node *v4l2_of_get_remote(const struct device_node *node);
-#else
-static inline void v4l2_of_parse_link(const struct device_node *node,
+
+#else /* CONFIG_OF */
+
+static inline int v4l2_of_parse_link(const struct device_node *node,
struct v4l2_of_link *link)
{
+ return -ENOSYS;
}
static inline int v4l2_of_parse_data_lanes(const struct device_node *node,
--
1.7.9.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
[PATCH RFC 07/13] of: Add empty of_get_next_child() function definition
Add an empty of_get_next_child() function definition so users can
be build when CONFIG_OF is disabled and are not required to exclude
OF specific parts explicitly with #ifdefs.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/of.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index 7df42cc..fb92acc 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -335,6 +335,13 @@ static inline bool of_have_populated_dt(void)
#define for_each_available_child_of_node(parent, child) \
while (0)
+static inline struct device_node *of_get_next_child(
+ const struct device_node *node,
+ struct device_node *prev)
+{
+ return NULL;
+}
+
static inline struct device_node *of_get_child_by_name(
const struct device_node *node,
const char *name)
--
1.7.9.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
[PATCH RFC 08/13] media: add V4L2 DT binding documentation
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Documentation/devicetree/bindings/media/v4l2.txt | 162 ++
1 file changed, 162 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
diff --git a/Documentation/devicetree/bindings/media/v4l2.txt
b/Documentation/devicetree/bindings/media/v4l2.txt
new file mode 100644
index 000..b8b3f41
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/v4l2.txt
@@ -0,0 +1,162 @@
+Video4Linux Version 2 (V4L2)
+
+General concept
+---
+
+Video pipelines consist of external devices, e.g. camera sensors, controlled
+over an I2C, SPI or UART bus, and SoC internal IP blocks, including video DMA
+engines and video data processors.
+
+SoC internal blocks are described by DT nodes, placed similarly to other SoC
+blocks. External devices are represented as child nodes of their respective bus
+controller nodes, e.g. I2C.
+
+Data interfaces on all video devices are described by port child DT nodes.
+Configuration of a port depends on other devices participating in the data
+transfer and is described by link DT nodes, specified as children of the
+port nodes:
+
+/foo {
+ port@0 {
+ link@0 { ... };
+ link@1 { ... };
+ };
+ port@1 { ... };
+};
+
+If a port can be configured to work with more than one other device on the same
+bus, a link child DT node must be provided for each of them. If more than one
+port is present on a device or more than one link is connected to a port, a
+common scheme, using #address-cells, #size-cells and reg properties is
+used.
+
+Optional link properties:
+- remote: phandle to the other endpoint link DT node.
+- slave-mode: a boolean property, run the link in slave mode. Default is master
+ mode.
+- data-shift: on parallel data busses, if data-width is used to specify the
+ number of data lines, data-shift can be used to specify which data lines are
+ used, e.g. data-width=10; data-shift=2; means, that lines 9:2 are used.
+- hsync-active: 1 or 0 for active-high or -low HSYNC signal polarity
+ respectively.
+- vsync-active: ditto for VSYNC. Note, that if HSYNC and VSYNC polarities are
+ not specified, embedded synchronisation may be required, where supported.
+- data-active: similar to HSYNC and VSYNC specifies data line polarity.
+- field-even-active: field signal level during the even field data
transmission.
+- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock pin.
+- data-lanes: array of serial, e.g. MIPI CSI-2, data hardware lane numbers in
+ the ascending order, beginning with logical lane 0.
+- clock-lanes: hardware lane number, used for the clock lane.
+- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
+ clock mode.
+
+Example:
+
+ ceu0: ceu@0xfe91 {
+ compatible = renesas,sh-mobile-ceu;
+ reg = 0xfe91 0xa0;
+ interrupts = 0x880;
+
+ mclk: master_clock {
+ compatible = renesas,ceu-clock;
+ #clock-cells = 1;
+ clock-frequency = 5000; /* max clock frequency
*/
+ clock-output-names = mclk;
+ };
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ceu0_1: link@1 {
+ reg = 1; /* local link # */
+ remote = ov772x_1_1; /* remote phandle */
+ bus-width = 8;/* used data lines */
+ data-shift = 0; /* lines 7:0 are used */
+
+ /* If [hv]sync-active are missing, embedded
bt.605 sync is used */
+ hsync-active = 1; /* active high */
+ vsync-active = 1; /* active high */
+ data-active = 1; /* active high */
+ pclk-sample = 1; /* rising */
+ };
+
+ ceu0_0: link@0 {
+ reg = 0;
+ remote = csi2_2;
+ immutable;
+ };
+ };
+ };
+
+ i2c0: i2c@0xfff2 {
+ ...
+ ov772x_1: camera@0x21 {
+ compatible = omnivision,ov772x;
+ reg = 0x21;
+ vddio-supply = regulator1;
+ vddcore-supply = regulator2;
+
+ clock-frequency = 2000;
+ clocks = mclk 0;
+ clock-names = xclk;
+
+
[PATCH RFC 10/13] v4l2-of: Support variable length of data-lanes property
Based on code from Guennadi Liakhovetski g.liakhovet...@gmx.de.
Add data_lanes property which relects the number of active data lanes,
that is length of the data-lanes array. Previously we assumed the
data-lanes array had fixed length which doesn't match the binding
semantics.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/v4l2-core/v4l2-of.c | 15 +++
include/media/v4l2-of.h |1 +
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index f45d64b..4e6658c 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -33,6 +33,7 @@ void v4l2_of_parse_link(const struct device_node *node,
unsigned int v;
u32 data_lanes[ARRAY_SIZE(link-mipi_csi_2.data_lanes)];
bool data_lanes_present;
+ struct property *prop;
memset(link, 0, sizeof(*link));
@@ -83,10 +84,16 @@ void v4l2_of_parse_link(const struct device_node *node,
if (!of_property_read_u32(node, clock-lanes, v))
link-mipi_csi_2.clock_lane = v;
- if (!of_property_read_u32_array(node, data-lanes, data_lanes,
- ARRAY_SIZE(data_lanes))) {
- int i;
- for (i = 0; i ARRAY_SIZE(data_lanes); i++)
+ prop = of_find_property(node, data-lanes, NULL);
+ if (prop) {
+ int i = 0;
+ const __be32 *lane = NULL;
+ do {
+ lane = of_prop_next_u32(prop, lane, data_lanes[i]);
+ } while (lane i++ ARRAY_SIZE(data_lanes));
+
+ link-mipi_csi_2.num_data_lanes = i;
+ while (i--)
link-mipi_csi_2.data_lanes[i] = data_lanes[i];
data_lanes_present = true;
} else {
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 6fafedb..ccb1ebe 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -33,6 +33,7 @@ struct v4l2_of_link {
struct {
unsigned char data_lanes[4];
unsigned char clock_lane;
+ unsigned short num_data_lanes;
} mipi_csi_2;
};
};
--
1.7.9.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
[PATCH RFC 11/13] v4l2-of: Add v4l2_of_parse_data_lanes() function
Put the data-lanes property parsing code and make a separate function
out of it, so it can be used in drivers that don't need all features
packed in v4l2_of_parse_link().
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/v4l2-core/v4l2-of.c | 48 -
include/media/v4l2-of.h | 28 --
2 files changed, 52 insertions(+), 24 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 4e6658c..032ee67 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -15,6 +15,35 @@
#include media/v4l2-of.h
+
+/**
+ * v4l2_of_parse_data_lanes() - parse data-lanes property
+ * @node: a node containing data-lanes property [in]
+ * @mipi_csi2: data lanes configuration [out]
+ *
+ * Return: 0 on success or negative error value otherwise.
+ */
+int v4l2_of_parse_data_lanes(const struct device_node *node,
+ struct v4l2_of_mipi_csi2 *mipi_csi2)
+{
+ struct property *prop = of_find_property(node, data-lanes, NULL);
+ u32 data_lanes[ARRAY_SIZE(mipi_csi2-data_lanes)];
+ const __be32 *lane = NULL;
+ int i = 0;
+
+ if (!prop)
+ return -EINVAL;
+
+ do {
+ lane = of_prop_next_u32(prop, lane, data_lanes[i]);
+ } while (lane i++ ARRAY_SIZE(data_lanes));
+
+ mipi_csi2-num_data_lanes = i;
+ while (i--)
+ mipi_csi2-data_lanes[i] = data_lanes[i];
+ return 0;
+}
+
/*
* All properties are optional. If none are found, we don't set any flags. This
* means, the port has a static configuration and no properties have to be
@@ -29,11 +58,9 @@ void v4l2_of_parse_link(const struct device_node *node,
struct v4l2_of_link *link)
{
const struct device_node *port_node = of_get_parent(node);
+ bool data_lanes_present = false;
int size;
unsigned int v;
- u32 data_lanes[ARRAY_SIZE(link-mipi_csi_2.data_lanes)];
- bool data_lanes_present;
- struct property *prop;
memset(link, 0, sizeof(*link));
@@ -84,21 +111,8 @@ void v4l2_of_parse_link(const struct device_node *node,
if (!of_property_read_u32(node, clock-lanes, v))
link-mipi_csi_2.clock_lane = v;
- prop = of_find_property(node, data-lanes, NULL);
- if (prop) {
- int i = 0;
- const __be32 *lane = NULL;
- do {
- lane = of_prop_next_u32(prop, lane, data_lanes[i]);
- } while (lane i++ ARRAY_SIZE(data_lanes));
-
- link-mipi_csi_2.num_data_lanes = i;
- while (i--)
- link-mipi_csi_2.data_lanes[i] = data_lanes[i];
+ if (!v4l2_of_parse_data_lanes(node, link-mipi_csi_2))
data_lanes_present = true;
- } else {
- data_lanes_present = false;
- }
if (of_get_property(node, clock-noncontinuous, size))
link-mbus_flags |= V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK;
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index ccb1ebe..9b036e6 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -13,11 +13,18 @@
#include linux/list.h
#include linux/types.h
+#include linux/errno.h
#include media/v4l2-mediabus.h
struct device_node;
+struct v4l2_of_mipi_csi2 {
+ unsigned char data_lanes[4];
+ unsigned char clock_lane;
+ unsigned short num_data_lanes;
+};
+
struct v4l2_of_link {
unsigned int port;
unsigned int addr;
@@ -30,17 +37,15 @@ struct v4l2_of_link {
unsigned char bus_width;
unsigned char data_shift;
} parallel;
- struct {
- unsigned char data_lanes[4];
- unsigned char clock_lane;
- unsigned short num_data_lanes;
- } mipi_csi_2;
+ struct v4l2_of_mipi_csi2 mipi_csi_2;
};
};
#ifdef CONFIG_OF
void v4l2_of_parse_link(const struct device_node *node,
struct v4l2_of_link *link);
+int v4l2_of_parse_data_lanes(const struct device_node *node,
+ struct v4l2_of_mipi_csi2 *mipi_csi2);
struct device_node *v4l2_of_get_next_link(const struct device_node *parent,
struct device_node *previous);
struct device_node *v4l2_of_get_remote(const struct device_node *node);
@@ -49,15 +54,24 @@ static inline void v4l2_of_parse_link(const struct
device_node *node,
struct v4l2_of_link *link)
{
}
+
+static inline int v4l2_of_parse_data_lanes(const struct device_node *node,
+ struct v4l2_of_mipi_csi2 *mipi_csi2)
+{
+ return -ENOSYS;
+}
+
static inline struct
[PATCH RFC 13/13] v4l2-of: Replace remote property with remote-endpoint
As agreed (I hope I'm not wrong) on the LMML use remote-endpoint
property instead of remote. Also add kerneldoc description for
the function.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/v4l2-core/v4l2-of.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 032ee67..10a06e4 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -186,13 +186,19 @@ struct device_node *v4l2_of_get_next_link(const struct
device_node *parent,
}
EXPORT_SYMBOL(v4l2_of_get_next_link);
-/* Return a refcounted DT node, owning the link, referenced by remote */
+/**
+ * v4l2_of_get_remote() - get device node corresponding to remote enpoint
+ * @node: local endpoint node
+ *
+ * Return: Remote device node associated with remote endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
struct device_node *v4l2_of_get_remote(const struct device_node *node)
{
struct device_node *remote, *tmp;
- /* Get remote link DT node */
- remote = of_parse_phandle(node, remote, 0);
+ /* Get remote endpoint DT node */
+ remote = of_parse_phandle(node, remote-endpoint, 0);
if (!remote)
return NULL;
--
1.7.9.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
[PATCH RFC 09/13] media: add a V4L2 OF parser
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Add a V4L2 OF parser, implementing bindings, documented in
Documentation/devicetree/bindings/media/v4l2.txt.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/v4l2-core/Makefile |3 +
drivers/media/v4l2-core/v4l2-of.c | 190 +
include/media/v4l2-of.h | 62
3 files changed, 255 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-of.c
create mode 100644 include/media/v4l2-of.h
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index c2d61d4..00f64d6 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -9,6 +9,9 @@ videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
v4l2-fh.o \
ifeq ($(CONFIG_COMPAT),y)
videodev-objs += v4l2-compat-ioctl32.o
endif
+ifeq ($(CONFIG_OF),y)
+ videodev-objs += v4l2-of.o
+endif
obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o
obj-$(CONFIG_VIDEO_V4L2) += v4l2-common.o
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
new file mode 100644
index 000..f45d64b
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -0,0 +1,190 @@
+/*
+ * V4L2 OF binding parsing library
+ *
+ * Copyright (C) 2012 Renesas Electronics Corp.
+ * Author: Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/types.h
+
+#include media/v4l2-of.h
+
+/*
+ * All properties are optional. If none are found, we don't set any flags. This
+ * means, the port has a static configuration and no properties have to be
+ * specified explicitly.
+ * If any properties are found, that identify the bus as parallel, and
+ * slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if we recognise
the
+ * bus as serial CSI-2 and clock-noncontinuous isn't set, we set the
+ * V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag.
+ * The caller should hold a reference to node.
+ */
+void v4l2_of_parse_link(const struct device_node *node,
+ struct v4l2_of_link *link)
+{
+ const struct device_node *port_node = of_get_parent(node);
+ int size;
+ unsigned int v;
+ u32 data_lanes[ARRAY_SIZE(link-mipi_csi_2.data_lanes)];
+ bool data_lanes_present;
+
+ memset(link, 0, sizeof(*link));
+
+ link-local_node = node;
+
+ /* Doesn't matter, whether the below two calls succeed */
+ of_property_read_u32(port_node, reg, link-port);
+ of_property_read_u32(node, reg, link-addr);
+
+ if (!of_property_read_u32(node, bus-width, v))
+ link-parallel.bus_width = v;
+
+ if (!of_property_read_u32(node, data-shift, v))
+ link-parallel.data_shift = v;
+
+ if (!of_property_read_u32(node, hsync-active, v))
+ link-mbus_flags |= v ? V4L2_MBUS_HSYNC_ACTIVE_HIGH :
+ V4L2_MBUS_HSYNC_ACTIVE_LOW;
+
+ if (!of_property_read_u32(node, vsync-active, v))
+ link-mbus_flags |= v ? V4L2_MBUS_VSYNC_ACTIVE_HIGH :
+ V4L2_MBUS_VSYNC_ACTIVE_LOW;
+
+ if (!of_property_read_u32(node, data-active, v))
+ link-mbus_flags |= v ? V4L2_MBUS_DATA_ACTIVE_HIGH :
+ V4L2_MBUS_DATA_ACTIVE_LOW;
+
+ if (!of_property_read_u32(node, pclk-sample, v))
+ link-mbus_flags |= v ? V4L2_MBUS_PCLK_SAMPLE_RISING :
+ V4L2_MBUS_PCLK_SAMPLE_FALLING;
+
+ if (!of_property_read_u32(node, field-even-active, v))
+ link-mbus_flags |= v ? V4L2_MBUS_FIELD_EVEN_HIGH :
+ V4L2_MBUS_FIELD_EVEN_LOW;
+
+ if (of_get_property(node, slave-mode, size))
+ link-mbus_flags |= V4L2_MBUS_SLAVE;
+
+ /* If any parallel-bus properties have been found, skip serial ones */
+ if (link-parallel.bus_width || link-parallel.data_shift ||
+ link-mbus_flags) {
+ /* Default parallel bus-master */
+ if (!(link-mbus_flags V4L2_MBUS_SLAVE))
+ link-mbus_flags |= V4L2_MBUS_MASTER;
+ return;
+ }
+
+ if (!of_property_read_u32(node, clock-lanes, v))
+ link-mipi_csi_2.clock_lane = v;
+
+ if (!of_property_read_u32_array(node, data-lanes, data_lanes,
+ ARRAY_SIZE(data_lanes))) {
+ int i;
+ for (i = 0; i ARRAY_SIZE(data_lanes); i++)
+ link-mipi_csi_2.data_lanes[i] = data_lanes[i];
+ data_lanes_present = true;
+ } else {
+ data_lanes_present = false;
+ }
+
+ if (of_get_property(node, clock-noncontinuous, size))
+
[PATCH RFC 06/13] of: Add empty of_find_device_by_node() function definition
This allows users to be compiled without excluding this function
call with preprocessor directives when CONFIG_OF_DEVICE is disabled.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/of_platform.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index b47d204..d8f587f 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -96,6 +96,13 @@ extern int of_platform_populate(struct device_node *root,
struct device *parent);
#endif /* CONFIG_OF_ADDRESS */
+#else /* CONFIG_OF_DEVICE */
+static inline struct platform_device *of_find_device_by_node(
+ struct device_node *np)
+{
+ return NULL;
+}
+
#endif /* CONFIG_OF_DEVICE */
#if !defined(CONFIG_OF_ADDRESS)
--
1.7.9.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
[PATCH RFC 04/13] OF: make a function pointer argument const
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
The struct device_node * argument of of_parse_phandle_*() can be const.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/of/base.c |4 ++--
include/linux/of.h |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index af3b22a..c180205 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -894,7 +894,7 @@ EXPORT_SYMBOL_GPL(of_property_count_strings);
* of_node_put() on it when done.
*/
struct device_node *
-of_parse_phandle(struct device_node *np, const char *phandle_name, int index)
+of_parse_phandle(const struct device_node *np, const char *phandle_name, int
index)
{
const __be32 *phandle;
int size;
@@ -939,7 +939,7 @@ EXPORT_SYMBOL(of_parse_phandle);
* To get a device_node of the `node2' node you may call this:
* of_parse_phandle_with_args(node3, list, #list-cells, 1, args);
*/
-int of_parse_phandle_with_args(struct device_node *np, const char *list_name,
+int of_parse_phandle_with_args(const struct device_node *np, const char
*list_name,
const char *cells_name, int index,
struct of_phandle_args *out_args)
{
diff --git a/include/linux/of.h b/include/linux/of.h
index 38d4b1a..2fb0dbe 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -256,10 +256,10 @@ extern int of_n_size_cells(struct device_node *np);
extern const struct of_device_id *of_match_node(
const struct of_device_id *matches, const struct device_node *node);
extern int of_modalias_node(struct device_node *node, char *modalias, int len);
-extern struct device_node *of_parse_phandle(struct device_node *np,
+extern struct device_node *of_parse_phandle(const struct device_node *np,
const char *phandle_name,
int index);
-extern int of_parse_phandle_with_args(struct device_node *np,
+extern int of_parse_phandle_with_args(const struct device_node *np,
const char *list_name, const char *cells_name, int index,
struct of_phandle_args *out_args);
@@ -412,7 +412,7 @@ static inline int of_property_match_string(struct
device_node *np,
return -ENOSYS;
}
-static inline struct device_node *of_parse_phandle(struct device_node *np,
+static inline struct device_node *of_parse_phandle(const struct device_node
*np,
const char *phandle_name,
int index)
{
--
1.7.9.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
[PATCH RFC 01/13] i2c: add dummy inline functions for when CONFIG_OF_I2C(_MODULE) isn't defined
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
If CONFIG_OF_I2C and CONFIG_OF_I2C_MODULE are undefined no declaration of
of_find_i2c_device_by_node and of_find_i2c_adapter_by_node will be
available. Add dummy inline functions to avoid compilation breakage.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/of_i2c.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index 1cb775f..cfb545c 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -29,6 +29,18 @@ static inline void of_i2c_register_devices(struct
i2c_adapter *adap)
{
return;
}
+
+static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node
*node)
+{
+ return NULL;
+}
+
+/* must call put_device() when done with returned i2c_adapter device */
+static inline struct i2c_adapter *of_find_i2c_adapter_by_node(
+ struct device_node *node)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_I2C */
#endif /* __LINUX_OF_I2C_H */
--
1.7.9.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
[PATCH RFC 03/13] OF: define of_*_cmp() macros also if CONFIG_OF isn't set
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
of_*_cmp() macros do not depend on any OF functions and can be defined also
if CONFIG_OF isn't set. Also include linux/string.h, required by those
macros.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/of.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 9ba8cf1..38d4b1a 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -85,6 +85,14 @@ static inline struct device_node *of_node_get(struct
device_node *node)
static inline void of_node_put(struct device_node *node) { }
#endif /* !CONFIG_OF_DYNAMIC */
+/* Default string compare functions, Allow arch asm/prom.h to override */
+#if !defined(of_compat_cmp)
+#include linux/string.h
+#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
+#define of_prop_cmp(s1, s2)strcmp((s1), (s2))
+#define of_node_cmp(s1, s2)strcasecmp((s1), (s2))
+#endif
+
#ifdef CONFIG_OF
/* Pointer for first entry in chain of all nodes. */
@@ -143,13 +151,6 @@ static inline unsigned long of_read_ulong(const __be32
*cell, int size)
#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
#endif
-/* Default string compare functions, Allow arch asm/prom.h to override */
-#if !defined(of_compat_cmp)
-#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
-#define of_prop_cmp(s1, s2)strcmp((s1), (s2))
-#define of_node_cmp(s1, s2)strcasecmp((s1), (s2))
-#endif
-
/* flag descriptions */
#define OF_DYNAMIC 1 /* node and properties were allocated via kmalloc */
#define OF_DETACHED2 /* node has been detached from the device tree */
--
1.7.9.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
[PATCH RFC 05/13] of: Add empty for_each_available_child_of_node() macro definition
Add this empty macro definition so users can be compiled without excluding this macro call with preprocessor directives when CONFIG_OF is disabled. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- include/linux/of.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/of.h b/include/linux/of.h index 2fb0dbe..7df42cc 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -332,6 +332,9 @@ static inline bool of_have_populated_dt(void) #define for_each_child_of_node(parent, child) \ while (0) +#define for_each_available_child_of_node(parent, child) \ + while (0) + static inline struct device_node *of_get_child_by_name( const struct device_node *node, const char *name) -- 1.7.9.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
[PATCH RFC 02/13] of: add a dummy inline function for when CONFIG_OF is not defined
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
If CONFIG_OF isn't defined, no declaration of of_get_parent will be found
and compilation can fail. This patch adds a dummy inline function
definition to fix the problem.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/of.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index b4e50d5..9ba8cf1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -427,6 +427,11 @@ static inline int of_parse_phandle_with_args(struct
device_node *np,
return -ENOSYS;
}
+static inline struct device_node *of_get_parent(const struct device_node *np)
+{
+ return NULL;
+}
+
static inline int of_alias_get_id(struct device_node *np, const char *stem)
{
return -ENOSYS;
--
1.7.9.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
[PATCH RFC 00/12] Device tree support for Exynos4 SoC camera drivers
This patch series adds support for Samsung Exynos4 SoC camera subsystem drivers. It depends on the video input interfaces bindings and the V4L2 OF parsing helpers. Full tree containing these patches can be browsed at: http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/v3.7-rc8-pq-camera-dt Sylwester Nawrocki (12): s5p-csis: Add device tree support s5p-fimc: Add device tree support for FIMC devices s5p-fimc: Add device tree support for FIMC-LITE s5p-fimc: Instantiate media device from device tree s5p-fimc: Add device tree based sensors registration s5p-fimc: Use pinctrl API for camera ports configuration ARM: EXYNOS4: Add OF_DEV_AUXDATA for FIMC, FIMC-LITE and CSIS ARM: dts: Add camera node exynos4.dtsi ARM: dts: Add ISP power domain node for Exynos4x12 ARM: dts: Add FIMC and MIPI CSIS device nodes for Exynos4x12 ARM: dts: Add camera pinctrl nodes for Exynos4x12 SoCs ARM: dts: Add camera device nodes nodes for PQ board .../devicetree/bindings/media/soc/samsung-fimc.txt | 183 .../bindings/media/soc/samsung-mipi-csis.txt | 82 arch/arm/boot/dts/exynos4.dtsi | 64 +++ arch/arm/boot/dts/exynos4412-slp_pq.dts| 130 ++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 33 +- arch/arm/boot/dts/exynos4x12.dtsi | 41 ++ arch/arm/mach-exynos/mach-exynos4-dt.c | 16 + drivers/media/platform/s5p-fimc/fimc-capture.c |2 +- drivers/media/platform/s5p-fimc/fimc-core.c| 84 ++-- drivers/media/platform/s5p-fimc/fimc-lite.c| 65 ++- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 462 ++-- drivers/media/platform/s5p-fimc/fimc-mdevice.h | 10 + drivers/media/platform/s5p-fimc/mipi-csis.c| 155 +-- drivers/media/platform/s5p-fimc/mipi-csis.h|1 + 14 files changed, 1109 insertions(+), 219 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/soc/samsung-fimc.txt create mode 100644 Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt -- 1.7.9.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
[PATCH RFC 01/12] s5p-csis: Add device tree support
s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC
(camera host interface DMA engine and image processor). This patch
adds support for instantiating the MIPI-CSIS devices from DT and
parsing all SoC and board specific properties from device tree.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/media/soc/samsung-mipi-csis.txt | 82 +++
drivers/media/platform/s5p-fimc/mipi-csis.c| 155 +++-
drivers/media/platform/s5p-fimc/mipi-csis.h|1 +
3 files changed, 202 insertions(+), 36 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
new file mode 100644
index 000..f57cbdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
@@ -0,0 +1,82 @@
+Samsung S5P/EXYNOS SoC MIPI-CSI2 receiver (MIPI CSIS)
+-
+
+Required properties:
+
+- compatible : samsung,s5pv210-csis for S5PV210 SoCs,
+ samsung,exynos4210-csis for Exynos4210 and later SoCs;
+- reg: physical base address and size of the device memory mapped
+ registers;
+- interrupts : should contain MIPI CSIS interrupt; the format of the
+ interrupt specifier depends on the interrupt controller;
+- max-data-lanes : maximum number of data lanes supported (SoC specific);
+- vddio-supply: MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V);
+- vddcore-supply : MIPI CSIS Core voltage supply (e.g. 1.1V).
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+ value when this property is not specified is 166 MHz;
+- samsung,csis,wclk : CSI-2 wrapper clock selection. If this property is
present
+ external clock from CMU will be used, if not bus clock will
+ be selected.
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, as outlined in the common media bindings specification. See
+Documentation/devicetree/bindings/media/v4l2.txt for details. The following are
+properties specific to those nodes. (TODO: update the file path)
+
+port node
+-
+
+- reg: (required) must be 2 for camera C input (CSIS0) or 3 for
+ camera D input (CSIS1);
+
+endpoint node
+-
+
+- data-lanes : (required) an array specifying active physical MIPI-CSI2
+ data input lanes and their mapping to logical lanes; the
+ array's content is unused, only its length is meaningful;
+
+- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle
time;
+
+- samsung,camclk-out: (optional) specifies clock output for remote sensor,
+ 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+
+Example:
+
+ reg0: regulator@0 {
+ };
+
+ reg1: regulator@1 {
+ };
+
+/* SoC properties */
+
+ aliases {
+ csis0 = csis_0;
+ };
+
+ csis_0: csis@1188 {
+ compatible = samsung,exynos4210-csis;
+ reg = 0x1188 0x1000;
+ interrupts = 0 78 0;
+ max-data-lanes = 4;
+ };
+
+/* Board properties */
+
+ csis_0: csis@1188 {
+ clock-frequency = 16600;
+ vddio-supply = reg0;
+ vddcore-supply = reg1;
+ port {
+ reg = 2; /* 2 - CSIS0, 3 - CSIS1 */
+ csis0_ep: endpoint {
+ remote-endpoint = ...;
+ data-lanes = 1, 2;
+ samsung,csis-hs-settle = 12;
+ };
+ };
+ };
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 8a06f14..5049aaf 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -19,12 +19,14 @@
#include linux/kernel.h
#include linux/memory.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/regulator/consumer.h
#include linux/slab.h
#include linux/spinlock.h
#include linux/videodev2.h
+#include media/v4l2-of.h
#include media/v4l2-subdev.h
#include linux/platform_data/mipi-csis.h
#include mipi-csis.h
@@ -113,6 +115,7 @@ static char *csi_clock_name[] = {
[CSIS_CLK_GATE] = csis,
};
#define NUM_CSIS_CLOCKSARRAY_SIZE(csi_clock_name)
+#define DEFAULT_SCLK_CSIS_FREQ 16600UL
static const char * const csis_supply_name[] = {
vddcore, /* CSIS Core (1.0V, 1.1V or 1.2V) suppply */
@@ -167,6 +170,11 @@ struct
[PATCH RFC 02/12] s5p-fimc: Add device tree support for FIMC devices
This patch adds support for devicetree based instantiation of FIMC
(s5p-fimc, s5pv210-fimc, exynos4-fimc platform) devices.
The FIMC IP features include colorspace conversion and scaling
(mem-to-mem) and parallel/MIPI CSI2 bus video capture interface.
Multiple SoC revision specific parameters are defined statically
in the driver and are used for both dt and non-dt. Specific driver
static data is selected based on the compatible property, and
previously platform device name was used to match driver data with
a specific SoC/IP version.
Aliases are used to determine an index of the IP which is essential
for linking FIMC IP with other ones, like MIPI-CSIS (MIPI CSI2 bus
frontend) or FIMC-LITE and FIMC-IS ISP.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/media/soc/samsung-fimc.txt | 92
drivers/media/platform/s5p-fimc/fimc-capture.c |2 +-
drivers/media/platform/s5p-fimc/fimc-core.c| 84 --
3 files changed, 148 insertions(+), 30 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
new file mode 100644
index 000..fab7e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
@@ -0,0 +1,92 @@
+Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC)
+--
+
+The Exynos Camera subsystem comprises of multiple sub-devices that are
+represented by separate platform devices. Some of the IPs come in different
+variants accross the SoC revisions (FIMC) and some remain mostly unchanged
+(MIPI CSIS, FIMC-LITE).
+
+All those sub-subdevices are defined as parent nodes of the common device
+node, which also includes common properties of the whole subsystem not really
+specific to any single sub-device, like common camera port pins or external
+clocks for image sensors attached to the SoC.
+
+Common 'camera' node
+
+
+Required properties:
+
+- compatible : must be samsung,fimc, simple-bus
+
+- pinctrl-names: pinctrl names for camera port pinmux control, the values
+must be default, inactive. default corresponds to
+pinmux configured for camera parallel bus; inactive is
+different from default only in that the CAMCLK pin is
+in high impedance state.
+- pinctrl-0..1: pinctrl properties corresponding to pinctrl-names
+
+The 'camera' node must include at least one 'fimc' child node.
+
+
+'fimc' device nodes
+---
+
+Required properties:
+
+- compatible : samsung,s5pv210-fimc for S5PV210,
+ samsung,exynos4210-fimc for Exynos4210,
+ samsung,exynos4212-fimc for Exynos4212/4412 SoCs;
+- reg : physical base address and size of the device memory mapped
+ registers;
+- interrupts : FIMC interrupt to the CPU should be described here;
+
+For every fimc node a numbered alias should be present in the aliases node.
+Aliases are of the form fimcn, where n is an integer (0...N) specifying
+the IP's instance index.
+
+'parallel-ports' node
+---
+
+This node should contain child 'port' nodes specifying active parallel video
+input ports. It includes camera A and camera B inputs. 'reg' property in the
+port nodes specifies the input - 0, 1 indicates input A, B respectively.
+
+Optional properties
+
+- samsung,camclk-out: specifies clock output for remote sensor,
+ 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+
+
+Example:
+
+ aliases {
+ csis0 = csis_0;
+ fimc0 = fimc_0;
+ };
+
+ camera {
+ compatible = samsung,fimc, simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = okay;
+
+ pinctrl-names = default, inactive;
+ pinctrl-0 = cam_port_a_clk_active;
+ pinctrl-1 = cam_port_a_clk_idle;
+
+ fimc_0: fimc@1180 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1180 0x1000;
+ interrupts = 0 85 0;
+ status = okay;
+ };
+
+ csis_0: csis@1188 {
+ compatible = samsung,exynos4210-csis;
+ reg = 0x1188 0x1000;
+ interrupts = 0 78 0;
+ max-data-lanes = 4;
+ };
+ };
+
+[1] Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 18a70e4..e716753 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++
[PATCH RFC 04/12] s5p-fimc: Instantiate media device from device tree
The platform sub-devices are looked up and registered to the top
level driver, similarly as it is done in non-dt case. When any
sub-device is not yet initialized and ready the main driver's
probe() will be deferred.
This patch adds matching table for the common media device driver
associated with the 'camera' dt node.
The previous method of registering platform entities into top
level driver using driver_find() and then iterating over devices
bound to a driver was racy and is being removed here. Instead,
we lookup a device first and then check for its driver, while
holding the device's mutex.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 261 +++-
drivers/media/platform/s5p-fimc/fimc-mdevice.h |4 +
2 files changed, 167 insertions(+), 98 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index 80d8fd1..2657e90 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -1,8 +1,8 @@
/*
* S5P/EXYNOS4 SoC series camera host interface media device driver
*
- * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- * Contact: Sylwester Nawrocki, s.nawro...@samsung.com
+ * Copyright (C) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrocki s.nawro...@samsung.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published
@@ -17,6 +17,8 @@
#include linux/kernel.h
#include linux/list.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/types.h
@@ -312,138 +314,187 @@ static int fimc_md_register_sensor_entities(struct
fimc_md *fmd)
}
/*
- * MIPI CSIS and FIMC platform devices registration.
+ * MIPI-CSIS, FIMC and FIMC-LITE platform devices registration.
*/
-static int fimc_register_callback(struct device *dev, void *p)
+
+static int register_fimc_lite_entity(struct fimc_md *fmd,
+struct fimc_lite *fimc_lite)
{
- struct fimc_dev *fimc = dev_get_drvdata(dev);
struct v4l2_subdev *sd;
- struct fimc_md *fmd = p;
int ret;
- if (fimc == NULL || fimc-id = FIMC_MAX_DEVS)
- return 0;
+ if (WARN_ON(fimc_lite-index = FIMC_LITE_MAX_DEVS ||
+ fmd-fimc_lite[fimc_lite-index]))
+ return -EBUSY;
- sd = fimc-vid_cap.subdev;
- sd-grp_id = GRP_ID_FIMC;
+ sd = fimc_lite-subdev;
+ sd-grp_id = GRP_ID_FLITE;
v4l2_set_subdev_hostdata(sd, (void *)fimc_pipeline_ops);
ret = v4l2_device_register_subdev(fmd-v4l2_dev, sd);
- if (ret) {
- v4l2_err(fmd-v4l2_dev, Failed to register FIMC.%d (%d)\n,
-fimc-id, ret);
- return ret;
- }
-
- fmd-fimc[fimc-id] = fimc;
- return 0;
+ if (!ret)
+ fmd-fimc_lite[fimc_lite-index] = fimc_lite;
+ else
+ v4l2_err(fmd-v4l2_dev, Failed to register FIMC.LITE%d\n,
+fimc_lite-index);
+ return ret;
}
-static int fimc_lite_register_callback(struct device *dev, void *p)
+static int register_fimc_entity(struct fimc_md *fmd, struct fimc_dev *fimc)
{
- struct fimc_lite *fimc = dev_get_drvdata(dev);
- struct fimc_md *fmd = p;
+ struct v4l2_subdev *sd;
int ret;
- if (fimc == NULL || fimc-index = FIMC_LITE_MAX_DEVS)
- return 0;
-
- fimc-subdev.grp_id = GRP_ID_FLITE;
- v4l2_set_subdev_hostdata(fimc-subdev, (void *)fimc_pipeline_ops);
+ if (WARN_ON(fimc-id = FIMC_MAX_DEVS || fmd-fimc[fimc-id]))
+ return -EBUSY;
- ret = v4l2_device_register_subdev(fmd-v4l2_dev, fimc-subdev);
- if (ret) {
- v4l2_err(fmd-v4l2_dev,
-Failed to register FIMC-LITE.%d (%d)\n,
-fimc-index, ret);
- return ret;
- }
+ sd = fimc-vid_cap.subdev;
+ sd-grp_id = GRP_ID_FIMC;
+ v4l2_set_subdev_hostdata(sd, (void *)fimc_pipeline_ops);
- fmd-fimc_lite[fimc-index] = fimc;
- return 0;
+ ret = v4l2_device_register_subdev(fmd-v4l2_dev, sd);
+ if (!ret)
+ fmd-fimc[fimc-id] = fimc;
+ else
+ v4l2_err(fmd-v4l2_dev, Failed to register FIMC.%d (%d)\n,
+fimc-id, ret);
+ return ret;
}
-static int csis_register_callback(struct device *dev, void *p)
+static int register_csis_entity(struct fimc_md *fmd,
+ struct platform_device *pdev,
+ struct v4l2_subdev *sd)
{
- struct v4l2_subdev *sd = dev_get_drvdata(dev);
- struct platform_device
[PATCH RFC 05/12] s5p-fimc: Add device tree based sensors registration
The sensor (I2C and/or SPI client) devices are instantiated by their
corresponding control bus controllers. Since their master clock is
often provided by a video bus receiver (host interface) or other than
I2C/SPI controller device, the drivers of those client devices are
not accessing hardware in their driver's probe() callback. Instead,
after enabling clock, the host driver calls back into a sub-device
when it wants to activate them. This pattern is used by some in-tree
drivers and this patch also uses it for DT case. This patch is
intended as a first step for adding device tree support to the
S5P/Exynos SoC camera drivers. The second one is adding support for
asynchronous sub-devices registration and clock control from
sub-device driver level. The bindings shall not change when
asynchronous probing support is added. The motivation behind this
approach is to have basic support for device tree based platforms
in the driver, while asynchronous subdev probing and related issues
are being discussed on LMML.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/media/soc/samsung-fimc.txt | 75 +
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 168 +---
2 files changed, 217 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
index 5bbda07..82bd619 100644
--- a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
@@ -73,6 +73,15 @@ node. Aliases are in form of fimc-liten, where n is an
integer (0...N)
specifying the IP's instance index.
+Image sensor nodes
+--
+
+The sensor device nodes should be added as their control bus controller
+(e.g. I2C0) child nodes and linked to a port created under csis or
+parallel-ports node, using common bindings for video input interfaces,
+.i.e. port/endpoint node pairs. The implementation of this binding requires
+at clock-frequency property to be present under sensor device nodes.
+
Example:
aliases {
@@ -80,6 +89,47 @@ Example:
fimc0 = fimc_0;
};
+ /* Parallel bus IF sensor */
+ i2c_0: i2c@1386 {
+ s5k6aa: sensor@3c {
+ compatible = samsung,s5k6aafx;
+ reg = 0x3c;
+ vddio-supply = ...;
+
+ clock-frequency = 2400;
+ clocks = ...;
+ clock-names = mclk;
+
+ port {
+ s5k6aa_ep: endpoint {
+ remote-endpoint = fimc0_ep;
+ bus-width = 8;
+ hsync-active = 0;
+ hsync-active = 1;
+ pclk-sample = 1;
+ };
+ };
+ };
+ };
+
+ /* MIPI CSI-2 bus IF sensor */
+ s5c73m3: sensor@0x1a {
+ compatible = samsung,s5c73m3;
+ reg = 0x1a;
+ vddio-supply = ...;
+
+ clock-frequency = 2400;
+ clocks = ...;
+ clock-names = mclk;
+
+ port {
+ s5c73m3_1: endpoint {
+ data-lanes = 1, 2, 3, 4;
+ remote-endpoint = csis0_ep;
+ };
+ };
+ };
+
camera {
compatible = samsung,fimc, simple-bus;
#address-cells = 1;
@@ -90,6 +140,21 @@ Example:
pinctrl-0 = cam_port_a_clk_active;
pinctrl-1 = cam_port_a_clk_idle;
+ /* parallel camera ports */
+ parallel-ports {
+ /* camera A input */
+ port@0 {
+ reg = 0;
+ fimc0_ep: endpoint {
+ remote-endpoint = s5k6aa_ep;
+ bus-width = 8;
+ hsync-active = 0;
+ hsync-active = 1;
+ pclk-sample = 1;
+ };
+ };
+ };
+
fimc_0: fimc@1180 {
compatible = samsung,exynos4210-fimc;
reg = 0x1180 0x1000;
@@ -102,6 +167,16 @@ Example:
reg = 0x1188 0x1000;
interrupts = 0 78 0;
max-data-lanes = 4;
+ /* camera C input */
+ port {
+ reg = 2;
+
[PATCH RFC 08/12] ARM: dts: Add camera node exynos4.dtsi
This adds common FIMC device nodes for all Exynos4 SoCs.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 64
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 15d5d39..633d2e2 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -28,6 +28,12 @@
spi0 = spi_0;
spi1 = spi_1;
spi2 = spi_2;
+ csis0 = csis_0;
+ csis1 = csis_1;
+ fimc0 = fimc_0;
+ fimc1 = fimc_1;
+ fimc2 = fimc_2;
+ fimc3 = fimc_3;
};
pd_mfc: mfc-power-domain@10023C40 {
@@ -104,6 +110,64 @@
power-domain = pd_lcd0;
};
+ camera {
+ compatible = samsung,fimc, simple-bus;
+ status = disabled;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ fimc_0: fimc@1180 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1180 0x1000;
+ interrupts = 0 84 0;
+ power-domain = pd_cam;
+ status = disabled;
+ };
+
+ fimc_1: fimc@1181 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1181 0x1000;
+ interrupts = 0 85 0;
+ power-domain = pd_cam;
+ status = disabled;
+ };
+
+ fimc_2: fimc@1182 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1182 0x1000;
+ interrupts = 0 86 0;
+ power-domain = pd_cam;
+ status = disabled;
+ };
+
+ fimc_3: fimc@1183 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1183 0x1000;
+ interrupts = 0 87 0;
+ power-domain = pd_cam;
+ status = disabled;
+ };
+
+ csis_0: csis@1188 {
+ compatible = samsung,exynos4210-csis;
+ reg = 0x1188 0x4000;
+ interrupts = 0 78 0;
+ max-data-lanes = 4;
+ power-domain = pd_cam;
+ status = disabled;
+ };
+
+ csis_1: csis@1189 {
+ compatible = samsung,exynos4210-csis;
+ reg = 0x1189 0x4000;
+ interrupts = 0 80 0;
+ max-data-lanes = 2;
+ power-domain = pd_cam;
+ status = disabled;
+ };
+ };
+
watchdog@1006 {
compatible = samsung,s3c2410-wdt;
reg = 0x1006 0x100;
--
1.7.9.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
[PATCH RFC 09/12] ARM: dts: Add ISP power domain node for Exynos4x12
The ISP power domain is a common power domain for fimc-lite
and fimc-is (ISP) devices.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c34810c..3cb4862 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,6 +28,11 @@
pinctrl3 = pinctrl_3;
};
+ pd_isp: isp-power-domain@10023CA0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10023CA0 0x20;
+ };
+
combiner:interrupt-controller@1044 {
interrupts = 0 0 0, 0 1 0, 0 2 0, 0 3 0,
0 4 0, 0 5 0, 0 6 0, 0 7 0,
--
1.7.9.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
[PATCH RFC 06/12] s5p-fimc: Use pinctrl API for camera ports configuration
Before the camera ports can be used the pinmux needs to be configured
properly. This patch adds a function to get the pinctrl states and to
set default camera port pinmux state during the media driver's probe().
The camera port(s) are configured for video bus operation in this way.
inactive pinctrl state is intended for setting clock output pin(s)
into high impedance state when camera sensors are powered off.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyugmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 35 +---
drivers/media/platform/s5p-fimc/fimc-mdevice.h |6
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index ee718af..74d16a3 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -1064,13 +1064,33 @@ static ssize_t fimc_md_sysfs_store(struct device *dev,
static DEVICE_ATTR(subdev_conf_mode, S_IWUSR | S_IRUGO,
fimc_md_sysfs_show, fimc_md_sysfs_store);
+static int fimc_md_get_pinctrl(struct fimc_md *fmd)
+{
+ fmd-pinctl = devm_pinctrl_get_select_default(fmd-pdev-dev);
+ if (IS_ERR(fmd-pinctl))
+ return PTR_ERR(fmd-pinctl);
+
+ fmd-pinctl_state_default = pinctrl_lookup_state(fmd-pinctl,
+PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(fmd-pinctl_state_default))
+ return PTR_ERR(fmd-pinctl_state_default);
+
+ fmd-pinctl_state_idle = pinctrl_lookup_state(fmd-pinctl,
+ PINCTRL_STATE_INACTIVE);
+ if (IS_ERR(fmd-pinctl_state_idle))
+ return PTR_ERR(fmd-pinctl_state_idle);
+
+ return 0;
+}
+
static int fimc_md_probe(struct platform_device *pdev)
{
+ struct device *dev = pdev-dev;
struct v4l2_device *v4l2_dev;
struct fimc_md *fmd;
int ret;
- fmd = devm_kzalloc(pdev-dev, sizeof(*fmd), GFP_KERNEL);
+ fmd = devm_kzalloc(dev, sizeof(*fmd), GFP_KERNEL);
if (!fmd)
return -ENOMEM;
@@ -1080,7 +1100,7 @@ static int fimc_md_probe(struct platform_device *pdev)
strlcpy(fmd-media_dev.model, SAMSUNG S5P FIMC,
sizeof(fmd-media_dev.model));
fmd-media_dev.link_notify = fimc_md_link_notify;
- fmd-media_dev.dev = pdev-dev;
+ fmd-media_dev.dev = dev;
v4l2_dev = fmd-v4l2_dev;
v4l2_dev-mdev = fmd-media_dev;
@@ -1088,7 +1108,7 @@ static int fimc_md_probe(struct platform_device *pdev)
strlcpy(v4l2_dev-name, s5p-fimc-md, sizeof(v4l2_dev-name));
- ret = v4l2_device_register(pdev-dev, fmd-v4l2_dev);
+ ret = v4l2_device_register(dev, fmd-v4l2_dev);
if (ret 0) {
v4l2_err(v4l2_dev, Failed to register v4l2_device: %d\n, ret);
return ret;
@@ -1107,15 +1127,22 @@ static int fimc_md_probe(struct platform_device *pdev)
/* Protect the media graph while we're registering entities */
mutex_lock(fmd-media_dev.graph_mutex);
+ if (dev-of_node) {
+ ret = fimc_md_get_pinctrl(fmd);
+ if (ret 0)
+ goto err_unlock;
+ }
+
ret = fimc_md_register_platform_entities(fmd);
if (ret)
goto err_unlock;
- if (pdev-dev.platform_data || pdev-dev.of_node) {
+ if (dev-platform_data || dev-of_node) {
ret = fimc_md_register_sensor_entities(fmd);
if (ret)
goto err_unlock;
}
+
ret = fimc_md_create_links(fmd);
if (ret)
goto err_unlock;
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.h
b/drivers/media/platform/s5p-fimc/fimc-mdevice.h
index 1b7850c..89cecaa 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.h
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.h
@@ -10,6 +10,7 @@
#define FIMC_MDEVICE_H_
#include linux/clk.h
+#include linux/pinctrl/consumer.h
#include linux/platform_device.h
#include linux/mutex.h
#include media/media-device.h
@@ -25,6 +26,8 @@
#define FIMC_LITE_OF_NODE_NAME fimc_lite
#define CSIS_OF_NODE_NAME csis
+#define PINCTRL_STATE_INACTIVE inactive
+
/* Group IDs of sensor, MIPI-CSIS, FIMC-LITE and the writeback subdevs. */
#define GRP_ID_SENSOR (1 8)
#define GRP_ID_FIMC_IS_SENSOR (1 9)
@@ -85,6 +88,9 @@ struct fimc_md {
struct media_device media_dev;
struct v4l2_device v4l2_dev;
struct platform_device *pdev;
+ struct pinctrl *pinctl;
+ struct pinctrl_state *pinctl_state_default;
+ struct pinctrl_state *pinctl_state_idle;
bool user_subdev_api;
spinlock_t slock;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
[PATCH RFC 10/12] ARM: dts: Add FIMC and MIPI CSIS device nodes for Exynos4x12
Add common camera node and fimc nodes specific to Exynos4212
and Exynos4412 SoCs.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 3cb4862..e8fd4b7 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -26,6 +26,8 @@
pinctrl1 = pinctrl_1;
pinctrl2 = pinctrl_2;
pinctrl3 = pinctrl_3;
+ fimc-lite0 = fimc_lite_0;
+ fimc-lite1 = fimc_lite_1;
};
pd_isp: isp-power-domain@10023CA0 {
@@ -75,4 +77,38 @@
reg = 0x106E 0x1000;
interrupts = 0 72 0;
};
+
+ camera {
+ fimc_0: fimc@1180 {
+ compatible = samsung,exynos4212-fimc;
+ };
+
+ fimc_1: fimc@1181 {
+ compatible = samsung,exynos4212-fimc;
+ };
+
+ fimc_2: fimc@1182 {
+ compatible = samsung,exynos4212-fimc;
+ };
+
+ fimc_3: fimc@1183 {
+ compatible = samsung,exynos4212-fimc;
+ };
+
+ fimc_lite_0: fimc_lite@1239 {
+ compatible = samsung,exynos4212-fimc-lite;
+ reg = 0x1239 0x1000;
+ interrupts = 0 125 0;
+ power-domain = pd_isp;
+ status = disabled;
+ };
+
+ fimc_lite_1: fimc_lite@123a {
+ compatible = samsung,exynos4212-fimc-lite;
+ reg = 0x123a 0x1000;
+ interrupts = 0 126 0;
+ power-domain = pd_isp;
+ status = disabled;
+ };
+ };
};
--
1.7.9.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
[PATCH RFC 11/12] ARM: dts: Add camera pinctrl nodes for Exynos4x12 SoCs
Add separate nodes for the CAMCLK pin and turn off pull-up on camera
port A. Default driver strength for CAMCLK pin is increased to maximum.
The driver strength change can be moved to board specific part if it
is considered more appropriate.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 33 +++--
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 56f4669..e3225d0 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,15 +401,28 @@
samsung,pin-drv = 0;
};
- cam_port_a: cam-port-a {
+ cam_port_a_io: cam-port-a-io {
samsung,pins = gpj0-0, gpj0-1, gpj0-2, gpj0-3,
gpj0-4, gpj0-5, gpj0-6, gpj0-7,
- gpj1-0, gpj1-1, gpj1-2, gpj1-3,
- gpj1-4;
+ gpj1-0, gpj1-1, gpj1-2, gpj1-4;
samsung,pin-function = 2;
- samsung,pin-pud = 3;
+ samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = gpj1-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ cam_port_a_clk_idle: cam-port-a-clk-idle {
+ samsung,pins = gpj1-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
};
pinctrl@1100 {
@@ -834,11 +847,17 @@
samsung,pin-drv = 0;
};
- cam_port_b: cam-port-b {
+ cam_port_b_io: cam-port-b-io {
samsung,pins = gpm0-0, gpm0-1, gpm0-2, gpm0-3,
gpm0-4, gpm0-5, gpm0-6, gpm0-7,
- gpm1-0, gpm1-1, gpm2-0, gpm2-1,
- gpm2-2;
+ gpm1-0, gpm1-1, gpm2-0, gpm2-1;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ cam_port_b_clk: cam-port-b-clk {
+ samsung,pins = gpm2-2;
samsung,pin-function = 3;
samsung,pin-pud = 3;
samsung,pin-drv = 0;
--
1.7.9.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
[PATCH RFC 12/12] ARM: dts: Add camera device nodes nodes for PQ board
This patch adds all nodes for camera devices on example Exynos4412 SoC
based board. This is all what's required in the board dts file to enable
rear facing camera (S5C73M3 sensor).
The aliases node contains entries required for the camera processing
data path entity drivers.
The sensor nodes use standard port/remote-endpoint nodes convention.
Internal SoC links between entities are not specified this way and
are coded in the driver instead, as it seemed more reasonable.
The S5C73M3 sensor uses two control buses: I2C and SPI. There are
two, i2c_0 and spi_1 bus controller child nodes assigned to it.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4412-slp_pq.dts | 130 +++
1 file changed, 130 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-slp_pq.dts
b/arch/arm/boot/dts/exynos4412-slp_pq.dts
index 3a5782d..6c0cce7 100644
--- a/arch/arm/boot/dts/exynos4412-slp_pq.dts
+++ b/arch/arm/boot/dts/exynos4412-slp_pq.dts
@@ -101,6 +101,34 @@
};
};
+ i2c_0: i2c@1386 {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-slave-addr = 0x10;
+ samsung,i2c-max-bus-freq = 40;
+ pinctrl-0 = i2c0_bus;
+ status = okay;
+
+ s5c73m3@3c {
+ compatible = samsung,s5c73m3;
+ reg = 0x3c;
+ gpios = gpm0 1 1, /* ISP_STANDBY */
+ gpf1 3 1; /* ISP_RESET */
+ vdd-int-supply = buck9_reg;
+ vddio-cis-supply = ldo9_reg;
+ vdda-supply = ldo17_reg;
+ vddio-host-supply = ldo18_reg;
+ vdd-af-supply = cam_af_reg;
+ vdd-reg-supply = cam_io_reg;
+ clock-frequency = 2400;
+
+ port {
+ s5c73m3_ep: endpoint {
+ remote-endpoint = csis0_ep;
+ };
+ };
+ };
+ };
+
i2c@1389 {
samsung,i2c-sda-delay = 100;
samsung,i2c-slave-addr = 0x10;
@@ -411,6 +439,34 @@
enable-active-high;
};
+ cam_af_reg: voltage-regulator@2 {
+ compatible = regulator-fixed;
+ regulator-name = CAM_AF;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ gpio = gpm0 4 0;
+ enable-active-high;
+ };
+
+ cam_io_reg: voltage-regulator@3 {
+ compatible = regulator-fixed;
+ regulator-name = CAM_SENSOR_A;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ gpio = gpm0 2 0;
+ enable-active-high;
+ };
+
+ cam_isp_core_reg: voltage-regulator@4 {
+ compatible = regulator-fixed;
+ regulator-name = CAM_ISP_CORE_1.2V_EN;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ gpio = gpm0 3 0;
+ enable-active-high;
+ regulator-always-on;
+ };
+
fimd0_lcd: panel {
compatible = s6e8ax0;
reset-gpio = gpy4 5 0;
@@ -462,4 +518,78 @@
vusb_d-supply = ldo15_reg;
vusb_a-supply = ldo12_reg;
};
+
+ spi_1: spi@1393 {
+ pinctrl-names = default;
+ pinctrl-0 = spi1_bus;
+ status = okay;
+
+ s5c73m3_spi: s5c73m3 {
+ compatible = samsung,s5c73m3;
+ spi-max-frequency = 5000;
+ reg = 0;
+ controller-data {
+ cs-gpio = gpb 5 0;
+ samsung,spi-feedback-delay = 2;
+ };
+ };
+ };
+
+ camera {
+ compatible = samsung,fimc, simple-bus;
+ status = okay;
+
+ pinctrl-names = default, inactive;
+ pinctrl-0 = cam_port_a_clk_active;
+ pinctrl-1 = cam_port_a_clk_idle;
+
+ fimc_0: fimc@1180 {
+ status = okay;
+ };
+
+ fimc_1: fimc@1181 {
+ status = okay;
+ };
+
+ fimc_2: fimc@1182 {
+ status = okay;
+ };
+
+ fimc_3: fimc@1183 {
+ status = okay;
+ };
+
+ csis_0: csis@1188 {
+ status = okay;
+ vddcore-supply = ldo8_reg;
+ vddio-supply = ldo10_reg;
+
[PATCH RFC 07/12] ARM: EXYNOS4: Add OF_DEV_AUXDATA for FIMC, FIMC-LITE and CSIS
Add these temporary OF_DEV_AUXDATA entries so we can use clocks
before common clock framework support for Exynos4 is available.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-exynos4-dt.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index d6bdcfb..6d2eaf8 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -89,6 +89,22 @@ static const struct of_dev_auxdata exynos4_auxdata_lookup[]
__initconst = {
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_PDMA1, dma-pl330.1, NULL),
OF_DEV_AUXDATA(samsung,exynos4-fb, EXYNOS4_PA_FIMD0,
exynos4-fb.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-csis, EXYNOS4_PA_MIPI_CSIS0,
+ s5p-mipi-csis.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-csis, EXYNOS4_PA_MIPI_CSIS1,
+ s5p-mipi-csis.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4212-fimc, EXYNOS4_PA_FIMC0,
+ exynos4-fimc.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4212-fimc, EXYNOS4_PA_FIMC1,
+ exynos4-fimc.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4212-fimc, EXYNOS4_PA_FIMC2,
+ exynos4-fimc.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4212-fimc, EXYNOS4_PA_FIMC3,
+ exynos4-fimc.3, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4212-fimc-lite, EXYNOS4_PA_FIMC_LITE(0),
+ exynos-fimc-lite.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4212-fimc-lite, EXYNOS4_PA_FIMC_LITE(1),
+ exynos-fimc-lite.1, NULL),
{},
};
--
1.7.9.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
[PATCH RFC 03/12] s5p-fimc: Add device tree support for FIMC-LITE
This patch add support for instantiation FIMC-LITE platform
devices from device tree. Device tree aliases are used to specify
the IP hardware instance.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/media/soc/samsung-fimc.txt | 16 +
drivers/media/platform/s5p-fimc/fimc-lite.c| 65 ++--
2 files changed, 62 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
index fab7e61..5bbda07 100644
--- a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
@@ -57,6 +57,22 @@ Optional properties
0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+'fimc-lite' device nodes
+---
+
+Required properties:
+
+- compatible : should be samsung,exynos4212-fimc for Exynos4212 and
+ Exynos4412 SoCs;
+- reg : physical base address and size of the device memory mapped
+ registers;
+- interrupts : should contain FIMC-LITE interrupt;
+
+For every fimc-lite node a numbered alias should be present in the aliases
+node. Aliases are in form of fimc-liten, where n is an integer (0...N)
+specifying the IP's instance index.
+
+
Example:
aliases {
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index ef31c39..cfa3952 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -17,6 +17,7 @@
#include linux/kernel.h
#include linux/list.h
#include linux/module.h
+#include linux/of.h
#include linux/types.h
#include linux/platform_device.h
#include linux/pm_runtime.h
@@ -1490,18 +1491,34 @@ static int fimc_lite_clk_get(struct fimc_lite *fimc)
return ret;
}
+static const struct of_device_id flite_of_match[];
+
static int __devinit fimc_lite_probe(struct platform_device *pdev)
{
- struct flite_drvdata *drv_data = fimc_lite_get_drvdata(pdev);
+ struct flite_drvdata *drv_data = NULL;
+ struct device *dev = pdev-dev;
+ const struct of_device_id *of_id;
struct fimc_lite *fimc;
struct resource *res;
int ret;
- fimc = devm_kzalloc(pdev-dev, sizeof(*fimc), GFP_KERNEL);
+ fimc = devm_kzalloc(dev, sizeof(*fimc), GFP_KERNEL);
if (!fimc)
return -ENOMEM;
- fimc-index = pdev-id;
+ if (dev-of_node) {
+ of_id = of_match_node(flite_of_match, dev-of_node);
+ if (of_id)
+ drv_data = (struct flite_drvdata *)of_id-data;
+ fimc-index = of_alias_get_id(dev-of_node, fimc-lite);
+ } else {
+ drv_data = fimc_lite_get_drvdata(pdev);
+ fimc-index = pdev-id;
+ }
+
+ if (!drv_data || fimc-index 0 || fimc-index = FIMC_LITE_MAX_DEVS)
+ return -EINVAL;
+
fimc-variant = drv_data-variant[fimc-index];
fimc-pdev = pdev;
@@ -1510,15 +1527,15 @@ static int __devinit fimc_lite_probe(struct
platform_device *pdev)
mutex_init(fimc-lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- fimc-regs = devm_request_and_ioremap(pdev-dev, res);
+ fimc-regs = devm_request_and_ioremap(dev, res);
if (fimc-regs == NULL) {
- dev_err(pdev-dev, Failed to obtain io memory\n);
+ dev_err(dev, Failed to obtain io memory\n);
return -ENOENT;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res == NULL) {
- dev_err(pdev-dev, Failed to get IRQ resource\n);
+ dev_err(dev, Failed to get IRQ resource\n);
return -ENXIO;
}
@@ -1526,10 +1543,10 @@ static int __devinit fimc_lite_probe(struct
platform_device *pdev)
if (ret)
return ret;
- ret = devm_request_irq(pdev-dev, res-start, flite_irq_handler,
- 0, dev_name(pdev-dev), fimc);
+ ret = devm_request_irq(dev, res-start, flite_irq_handler,
+ 0, dev_name(dev), fimc);
if (ret) {
- dev_err(pdev-dev, Failed to install irq (%d)\n, ret);
+ dev_err(dev, Failed to install irq (%d)\n, ret);
goto err_clk;
}
@@ -1539,23 +1556,23 @@ static int __devinit fimc_lite_probe(struct
platform_device *pdev)
goto err_clk;
platform_set_drvdata(pdev, fimc);
- pm_runtime_enable(pdev-dev);
- ret = pm_runtime_get_sync(pdev-dev);
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
if (ret 0)
goto err_sd;
- fimc-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev);
+ fimc-alloc_ctx = vb2_dma_contig_init_ctx(dev);
[PATCH RFC 00/13] Common video input interfaces bindings and V4L2 OF helpers
Hi all, This series is an update of work on common bindings for video capture interfaces [1], [2] originally started by Guennadi. I took the liberty of resending the original patches and adding my changes on top of it. I just noticed there were some comments to the v5 of the bindings documentation and the example. I might have addressed them in next iteration, unless the author prefers to take care of that himself. This series adds a bunch of empty function/macro definitions for when CONFIG_OF(_DEVICE) is disabled, video capture interfaces common bindings documentation, related OF helpers and some corrections/ enhancements of them. Full tree containing this patch series can be browsed at [3]. [1] http://www.spinics.net/lists/linux-sh/msg13391.html [2] http://www.spinics.net/lists/linux-sh/msg13111.html [3] http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/v3.7-rc8-pq-camera-dt Guennadi Liakhovetski (6): i2c: add dummy inline functions for when CONFIG_OF_I2C(_MODULE) isn't defined of: add a dummy inline function for when CONFIG_OF is not defined OF: define of_*_cmp() macros also if CONFIG_OF isn't set OF: make a function pointer argument const media: add V4L2 DT binding documentation media: add a V4L2 OF parser Sylwester Nawrocki (7): of: Add empty for_each_available_child_of_node() macro definition of: Add empty of_find_device_by_node() function definition of: Add empty of_get_next_child() function definition v4l2-of: Support variable length of data-lanes property v4l2-of: Add v4l2_of_parse_data_lanes() function v4l2-of: Corrected v4l2_of_parse_link() function declaration v4l2-of: Replace remote property with remote-endpoint Documentation/devicetree/bindings/media/v4l2.txt | 162 drivers/media/v4l2-core/Makefile |3 + drivers/media/v4l2-core/v4l2-of.c| 217 ++ drivers/of/base.c|4 +- include/linux/of.h | 36 +++- include/linux/of_i2c.h | 12 ++ include/linux/of_platform.h |7 + include/media/v4l2-of.h | 80 8 files changed, 509 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt create mode 100644 drivers/media/v4l2-core/v4l2-of.c create mode 100644 include/media/v4l2-of.h -- 1.7.9.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
Re: EM2800 and audio via USB ?
On Mon, Dec 10, 2012 at 2:32 PM, Frank Schäfer fschaefer@googlemail.com wrote: a Terratec Cinergy 200 USB Most of those really old devices don't actually make the PCM audio available over the USB. That's why they provide an audio out connector - you're supposed to connect it to the line-in on your sound card. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/10/2012 09:24 PM, Frank Schäfer wrote: Am 10.12.2012 18:57, schrieb Antti Palosaari: On 12/10/2012 06:13 PM, Devin Heitmueller wrote: On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer Adding a new property to the RC profile certainly seems to be the cleanest solution. Do all protocols have paritiy checking ? Otherwise we could add a new type RC_TYPE_NEC_NO_PARITY. OTOH, introducing a new bitfield in struct rc_map might be usefull for other flags, too, in the future... It's probably also worth mentioning that in that mode the device reports four bytes, not two. I guess perhaps if parity is ignored it reports the data in some other format? You will probably have to do some experimentation there. Uh, current em28xx NEC implementation is locked to traditional 16 bit NEC, where is hw checksum used. Implementation should be changed to more general to support 24 and 32 bit NEC too. There is multiple drivers doing already that, for example AF9015. Hmm... are there and documents (, links, books, ...) where I can learn more about all those RC protocols ? Specification comes here: NEC send always 32 bit, 4 bytes. There is 3 different sub protocols: 1) 16bit NEC standard, 1 byte address code, 1 byte key code full 4 byte code: AA BB CC DD where: AA = address code BB = ~address code CC = key code DD = ~key code checksum: AA + BB = 0xff CC + DD = 0xff 2) 24bit NEC extended, 2 byte address code, 1 byte key code full 4 byte code: AA BB CC DD where: AA = address code (MSB) BB = address code (LSB) CC = key code DD = ~key code 3) 32bit NEC full, 4 byte key code full 4 byte code: AA BB CC DD where: AA = BB = CC = DD = I am not sure if there is separate parts for address and key code in case of 32bit NEC. See some existing remote keytables if there is any such table. It is very rare protocol. 1) and 2) are much more common. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Dec 10 19:00:19 CET 2012 git hash:16427faf28674451a7a0485ab0a929402f355ffd gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The 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
Understanding v4l2-ctl flags
Hi, I have a Logitech webcam under PWC. I've managed to use v4l2-ctl to change come controls, but some of them seem to be unsupported. v4l2-ctl reports the following flags inactive update slider write-only ** no flags at all ** e.g. restore_factory_settings (button) : flags=update, write-only What is the meaning of them? I can guess that inactive means unsupported, but do I care about the others? -- 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: Kworld PCI Analog TV Card Lite PVR-7134SE
Hi Read: http://www.linuxtv.org/wiki/index.php/Kworld_PCI_Analog_TV_Card_Lite Alfredo El 10/12/12 15:06, Saad Bin Javed escribió: Can anybody help setting up this card? I posted details in an earlier message but got no response. This list is my last hope to get this thing working. Regards, Saad -- 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
[PATCHv2 1/9] [media] dvb-usb: fix indentation of a for loop
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/usb/dvb-usb/dvb-usb-init.c | 60 +++---
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c
b/drivers/media/usb/dvb-usb/dvb-usb-init.c
index 169196e..1adf325 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-init.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c
@@ -38,41 +38,41 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d,
short *adapter_nrs)
memcpy(adap-props, d-props.adapter[n], sizeof(struct
dvb_usb_adapter_properties));
- for (o = 0; o adap-props.num_frontends; o++) {
- struct dvb_usb_adapter_fe_properties *props =
adap-props.fe[o];
- /* speed - when running at FULL speed we need a HW PID filter */
- if (d-udev-speed == USB_SPEED_FULL !(props-caps
DVB_USB_ADAP_HAS_PID_FILTER)) {
- err(This USB2.0 device cannot be run on a USB1.1 port.
(it lacks a hardware PID filter));
- return -ENODEV;
- }
+ for (o = 0; o adap-props.num_frontends; o++) {
+ struct dvb_usb_adapter_fe_properties *props =
adap-props.fe[o];
+ /* speed - when running at FULL speed we need a HW PID
filter */
+ if (d-udev-speed == USB_SPEED_FULL !(props-caps
DVB_USB_ADAP_HAS_PID_FILTER)) {
+ err(This USB2.0 device cannot be run on a
USB1.1 port. (it lacks a hardware PID filter));
+ return -ENODEV;
+ }
- if ((d-udev-speed == USB_SPEED_FULL props-caps
DVB_USB_ADAP_HAS_PID_FILTER) ||
- (props-caps DVB_USB_ADAP_NEED_PID_FILTERING)) {
- info(will use the device's hardware PID filter (table
count: %d)., props-pid_filter_count);
- adap-fe_adap[o].pid_filtering = 1;
- adap-fe_adap[o].max_feed_count =
props-pid_filter_count;
- } else {
- info(will pass the complete MPEG2 transport stream to
the software demuxer.);
- adap-fe_adap[o].pid_filtering = 0;
- adap-fe_adap[o].max_feed_count = 255;
- }
+ if ((d-udev-speed == USB_SPEED_FULL props-caps
DVB_USB_ADAP_HAS_PID_FILTER) ||
+ (props-caps
DVB_USB_ADAP_NEED_PID_FILTERING)) {
+ info(will use the device's hardware PID filter
(table count: %d)., props-pid_filter_count);
+ adap-fe_adap[o].pid_filtering = 1;
+ adap-fe_adap[o].max_feed_count =
props-pid_filter_count;
+ } else {
+ info(will pass the complete MPEG2 transport
stream to the software demuxer.);
+ adap-fe_adap[o].pid_filtering = 0;
+ adap-fe_adap[o].max_feed_count = 255;
+ }
- if (!adap-fe_adap[o].pid_filtering
- dvb_usb_force_pid_filter_usage
- props-caps DVB_USB_ADAP_HAS_PID_FILTER) {
- info(pid filter enabled by module option.);
- adap-fe_adap[o].pid_filtering = 1;
- adap-fe_adap[o].max_feed_count =
props-pid_filter_count;
- }
+ if (!adap-fe_adap[o].pid_filtering
+ dvb_usb_force_pid_filter_usage
+ props-caps DVB_USB_ADAP_HAS_PID_FILTER) {
+ info(pid filter enabled by module option.);
+ adap-fe_adap[o].pid_filtering = 1;
+ adap-fe_adap[o].max_feed_count =
props-pid_filter_count;
+ }
- if (props-size_of_priv 0) {
- adap-fe_adap[o].priv = kzalloc(props-size_of_priv,
GFP_KERNEL);
- if (adap-fe_adap[o].priv == NULL) {
- err(no memory for priv for adapter %d fe %d.,
n, o);
- return -ENOMEM;
+ if (props-size_of_priv 0) {
+ adap-fe_adap[o].priv =
kzalloc(props-size_of_priv, GFP_KERNEL);
+ if (adap-fe_adap[o].priv == NULL) {
+ err(no memory for priv for adapter %d
fe %d., n, o);
+ return -ENOMEM;
+ }
}
}
- }
if (adap-props.size_of_priv 0) {
adap-priv = kzalloc(adap-props.size_of_priv,
GFP_KERNEL);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe
[PATCHv2 0/9] dvb-usb/m920x: support VP-7049 DVB-T USB Stick and other fixes
Hi, Here is a second iteration of the patchset to add support for the Twinhan VP7049 DVB-T USB Stick, v1 is at: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/56714 Patches from 1 to 7 are small fixes or refactorings to make the addition of the new device easier. Patches 8 and 9 are specific to the device. Changes since v1: - Patches 1-7: more refactorings - Patch 9: don't add a .pre_init callback to dvb-usb, Antti convinced me that the initialization is better done just before the frontend attach is called. - Patch 9: use the RC core infrastructure, the keymap I needed was already here: I could reuse the rc-twinhan1027 driver without touching anything in it. Again I deliberately ignored some checkpatch.pl warnings and errors because I preferred to stick with the code style in use in the dvb-usb/m920x files, let me know if you want me to do otherwise. Thanks, Antonio Antonio Ospite (9): [media] dvb-usb: fix indentation of a for loop [media] m920x: fix a typo in a comment [media] m920x: factor out a m920x_write_seq() function [media] m920x: factor out a m920x_parse_rc_state() function [media] m920x: avoid repeating RC state parsing at each keycode [media] m920x: introduce m920x_rc_core_query() [media] m920x: send the RC init sequence also when rc.core is used [media] get_dvb_firmware: add entry for the vp7049 firmware [media] m920x: add support for the VP-7049 Twinhan DVB-T USB Stick Documentation/dvb/get_dvb_firmware | 15 +- drivers/media/dvb-core/dvb-usb-ids.h |1 + drivers/media/usb/dvb-usb/dvb-usb-init.c | 60 +++ drivers/media/usb/dvb-usb/m920x.c| 269 -- 4 files changed, 266 insertions(+), 79 deletions(-) -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/9] [media] m920x: factor out a m920x_write_seq() function
This is in preparation for the vp7049 frontend attach function which is
going to set a sequence of registers as well.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/usb/dvb-usb/m920x.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index 433696d..23416fb 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -63,6 +63,21 @@ static inline int m920x_write(struct usb_device *udev, u8
request,
return ret;
}
+static inline int m920x_write_seq(struct usb_device *udev, u8 request,
+ struct m920x_inits *seq)
+{
+ int ret;
+ while (seq-address) {
+ ret = m920x_write(udev, request, seq-data, seq-address);
+ if (ret != 0)
+ return ret;
+
+ seq++;
+ }
+
+ return ret;
+}
+
static int m920x_init(struct dvb_usb_device *d, struct m920x_inits *rc_seq)
{
int ret = 0, i, epi, flags = 0;
@@ -71,15 +86,10 @@ static int m920x_init(struct dvb_usb_device *d, struct
m920x_inits *rc_seq)
/* Remote controller init. */
if (d-props.rc.legacy.rc_query) {
deb(Initialising remote control\n);
- while (rc_seq-address) {
- if ((ret = m920x_write(d-udev, M9206_CORE,
- rc_seq-data,
- rc_seq-address)) != 0) {
- deb(Initialising remote control failed\n);
- return ret;
- }
-
- rc_seq++;
+ ret = m920x_write_seq(d-udev, M9206_CORE, rc_seq);
+ if (ret != 0) {
+ deb(Initialising remote control failed\n);
+ return ret;
}
deb(Initialising remote control success\n);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/9] [media] m920x: fix a typo in a comment
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/usb/dvb-usb/m920x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index 661bb75..433696d 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -591,7 +591,7 @@ static struct m920x_inits tvwalkertwin_rc_init [] = {
};
static struct m920x_inits pinnacle310e_init[] = {
- /* without these the tuner don't work */
+ /* without these the tuner doesn't work */
{ 0xff20, 0x9b },
{ 0xff22, 0x70 },
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/9] [media] m920x: factor out a m920x_parse_rc_state() function
This is in preparation to using RC core infrastructure for some devices,
the RC button state parsing logic can be shared berween rc.legacy and
rc.core callbacks as it is independent from the mechanism used for RC
handling.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/usb/dvb-usb/m920x.c | 81 -
1 file changed, 44 insertions(+), 37 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index 23416fb..581c5de 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -140,9 +140,50 @@ static int m920x_init_ep(struct usb_interface *intf)
alt-desc.bAlternateSetting);
}
-static int m920x_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
+static inline void m920x_parse_rc_state(struct dvb_usb_device *d, u8 rc_state,
+ int *state)
{
struct m920x_state *m = d-priv;
+
+ switch (rc_state) {
+ case 0x80:
+ *state = REMOTE_NO_KEY_PRESSED;
+ break;
+
+ case 0x88: /* framing error or invalid code */
+ case 0x99:
+ case 0xc0:
+ case 0xd8:
+ *state = REMOTE_NO_KEY_PRESSED;
+ m-rep_count = 0;
+ break;
+
+ case 0x93:
+ case 0x92:
+ case 0x83: /* pinnacle PCTV310e */
+ case 0x82:
+ m-rep_count = 0;
+ *state = REMOTE_KEY_PRESSED;
+ break;
+
+ case 0x91:
+ case 0x81: /* pinnacle PCTV310e */
+ /* prevent immediate auto-repeat */
+ if (++m-rep_count 2)
+ *state = REMOTE_KEY_REPEAT;
+ else
+ *state = REMOTE_NO_KEY_PRESSED;
+ break;
+
+ default:
+ deb(Unexpected rc state %02x\n, rc_state);
+ *state = REMOTE_NO_KEY_PRESSED;
+ break;
+ }
+}
+
+static int m920x_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
+{
int i, ret = 0;
u8 *rc_state;
@@ -159,42 +200,8 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
for (i = 0; i d-props.rc.legacy.rc_map_size; i++)
if (rc5_data(d-props.rc.legacy.rc_map_table[i]) ==
rc_state[1]) {
*event = d-props.rc.legacy.rc_map_table[i].keycode;
-
- switch(rc_state[0]) {
- case 0x80:
- *state = REMOTE_NO_KEY_PRESSED;
- goto out;
-
- case 0x88: /* framing error or invalid code */
- case 0x99:
- case 0xc0:
- case 0xd8:
- *state = REMOTE_NO_KEY_PRESSED;
- m-rep_count = 0;
- goto out;
-
- case 0x93:
- case 0x92:
- case 0x83: /* pinnacle PCTV310e */
- case 0x82:
- m-rep_count = 0;
- *state = REMOTE_KEY_PRESSED;
- goto out;
-
- case 0x91:
- case 0x81: /* pinnacle PCTV310e */
- /* prevent immediate auto-repeat */
- if (++m-rep_count 2)
- *state = REMOTE_KEY_REPEAT;
- else
- *state = REMOTE_NO_KEY_PRESSED;
- goto out;
-
- default:
- deb(Unexpected rc state %02x\n, rc_state[0]);
- *state = REMOTE_NO_KEY_PRESSED;
- goto out;
- }
+ m920x_parse_rc_state(d, rc_state[0], state);
+ goto out;
}
if (rc_state[1] != 0)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 9/9] [media] m920x: add support for the VP-7049 Twinhan DVB-T USB Stick
This device was originally made by Twinhan/Azurewave[1] and sometimes
named DTV-DVB UDTT7049, it could be also found in Italy under the name
of Digicom Digitune-S[2], or Think Xtra Hollywood DVB-T USB2.0[3].
Components:
Usb bridge: ULi M9206
Frontend: MT352CG
Tuner: MT2060F
The firmware can be downloaded with:
$ ./Documentation/dvb/get_dvb_firmware vp7049
[1] http://www.azurewave.com/Support_Utility_Driver.asp
[2]
http://www.digicom.it/digisit/driver_link.nsf/driverprodotto?openformprodotto=DigiTuneS
[3] http://www.txitalia.it/prodotto.asp?prodotto=txhollywooddvttv
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/dvb-core/dvb-usb-ids.h |1 +
drivers/media/usb/dvb-usb/m920x.c| 123 ++
2 files changed, 124 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 58e0220..faeaadd 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -172,6 +172,7 @@
#define USB_PID_TWINHAN_VP7045_WARM0x3206
#define USB_PID_TWINHAN_VP7021_COLD0x3207
#define USB_PID_TWINHAN_VP7021_WARM0x3208
+#define USB_PID_TWINHAN_VP7049 0x3219
#define USB_PID_TINYTWIN 0x3226
#define USB_PID_TINYTWIN_2 0xe402
#define USB_PID_TINYTWIN_3 0x9016
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index 531a681..02facc6 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -16,6 +16,7 @@
#include qt1010.h
#include tda1004x.h
#include tda827x.h
+#include mt2060.h
#include media/tuner.h
#include tuner-simple.h
@@ -546,6 +547,12 @@ static struct qt1010_config m920x_qt1010_config = {
.i2c_address = 0x62
};
+static struct mt2060_config m920x_mt2060_config = {
+ .i2c_address = 0x60, /* 0xc0 */
+ .clock_out = 0,
+};
+
+
/* Callbacks for DVB USB */
static int m920x_mt352_frontend_attach(struct dvb_usb_adapter *adap)
{
@@ -560,6 +567,37 @@ static int m920x_mt352_frontend_attach(struct
dvb_usb_adapter *adap)
return 0;
}
+static int m920x_mt352_frontend_attach_vp7049(struct dvb_usb_adapter *adap)
+{
+ struct m920x_inits vp7049_fe_init_seq[] = {
+ /* XXX without these commands the frontend cannot be detected,
+* they must be sent BEFORE the frontend is attached */
+ { 0xff28, 0x00 },
+ { 0xff23, 0x00 },
+ { 0xff28, 0x00 },
+ { 0xff23, 0x00 },
+ { 0xff21, 0x20 },
+ { 0xff21, 0x60 },
+ { 0xff28, 0x00 },
+ { 0xff22, 0x00 },
+ { 0xff20, 0x30 },
+ { 0xff20, 0x20 },
+ { 0xff20, 0x30 },
+ { } /* terminating entry */
+ };
+ int ret;
+
+ deb(%s\n,__func__);
+
+ ret = m920x_write_seq(adap-dev-udev, M9206_CORE, vp7049_fe_init_seq);
+ if (ret != 0) {
+ deb(Initialization of vp7049 frontend failed.);
+ return ret;
+ }
+
+ return m920x_mt352_frontend_attach(adap);
+}
+
static int m920x_tda10046_08_frontend_attach(struct dvb_usb_adapter *adap)
{
deb(%s\n,__func__);
@@ -624,6 +662,18 @@ static int m920x_fmd1216me_tuner_attach(struct
dvb_usb_adapter *adap)
return 0;
}
+static int m920x_mt2060_tuner_attach(struct dvb_usb_adapter *adap)
+{
+ deb(%s\n,__func__);
+
+ if (dvb_attach(mt2060_attach, adap-fe_adap[0].fe, adap-dev-i2c_adap,
+ m920x_mt2060_config, 1220) == NULL)
+ return -ENODEV;
+
+ return 0;
+}
+
+
/* device-specific initialization */
static struct m920x_inits megasky_rc_init [] = {
{ M9206_RC_INIT2, 0xa8 },
@@ -652,6 +702,15 @@ static struct m920x_inits pinnacle310e_init[] = {
{ } /* terminating entry */
};
+static struct m920x_inits vp7049_rc_init[] = {
+ { 0xff28, 0x00 },
+ { 0xff23, 0x00 },
+ { 0xff21, 0x70 },
+ { M9206_RC_INIT2, 0x00 },
+ { M9206_RC_INIT1, 0xff },
+ { } /* terminating entry */
+};
+
/* ir keymaps */
static struct rc_map_table rc_map_megasky_table[] = {
{ 0x0012, KEY_POWER },
@@ -754,6 +813,7 @@ static struct dvb_usb_device_properties
digivox_mini_ii_properties;
static struct dvb_usb_device_properties tvwalkertwin_properties;
static struct dvb_usb_device_properties dposh_properties;
static struct dvb_usb_device_properties pinnacle_pctv310e_properties;
+static struct dvb_usb_device_properties vp7049_properties;
static int m920x_probe(struct usb_interface *intf,
const struct usb_device_id *id)
@@ -806,6 +866,13 @@ static int m920x_probe(struct
[PATCHv2 8/9] [media] get_dvb_firmware: add entry for the vp7049 firmware
Add an entry to download the dvb-usb-vp7049-0.95.fw firmware for the
Twinhan vp7049 and similar devices.
Known devices of this kind are:
Twinhan/Azurewave DTV-DVB UDTT7049
Digicom Digitune-S
Think Xtra Hollywood DVB-T USB2.0
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
Documentation/dvb/get_dvb_firmware | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index 32bc56b..0cdb157 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -23,7 +23,7 @@ use IO::Handle;
@components = ( sp8870, sp887x, tda10045, tda10046,
tda10046lifeview, av7110, dec2000t, dec2540t,
- dec3000s, vp7041, dibusb, nxt2002, nxt2004,
+ dec3000s, vp7041, vp7049, dibusb, nxt2002, nxt2004,
or51211, or51132_qam, or51132_vsb, bluebird,
opera1, cx231xx, cx18, cx23885, pvrusb2, mpc718,
af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
@@ -289,6 +289,19 @@ sub vp7041 {
$outfile;
}
+sub vp7049 {
+my $fwfile = dvb-usb-vp7049-0.95.fw;
+my $url =
http://ao2.it/sites/default/files/blog/2012/11/06/linux-support-digicom-digitune-s-vp7049-udtt7049/$fwfile;;
+my $hash = 5609fd295168aea88b25ff43a6f79c36;
+
+checkstandard();
+
+wgetfile($fwfile, $url);
+verify($fwfile, $hash);
+
+$fwfile;
+}
+
sub dibusb {
my $url =
http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw;;
my $outfile = dvb-dibusb-5.0.0.11.fw;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 7/9] [media] m920x: send the RC init sequence also when rc.core is used
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/usb/dvb-usb/m920x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index bddd763..531a681 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -84,7 +84,7 @@ static int m920x_init(struct dvb_usb_device *d, struct
m920x_inits *rc_seq)
int adap_enabled[M9206_MAX_ADAPTERS] = { 0 };
/* Remote controller init. */
- if (d-props.rc.legacy.rc_query) {
+ if (d-props.rc.legacy.rc_query || d-props.rc.core.rc_query) {
deb(Initialising remote control\n);
ret = m920x_write_seq(d-udev, M9206_CORE, rc_seq);
if (ret != 0) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 6/9] [media] m920x: introduce m920x_rc_core_query()
Add an m920x_rc_core_query() function for drivers which want to use the
linux RC core infrastructure.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/usb/dvb-usb/m920x.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index 5f6ca75..bddd763 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -215,6 +215,38 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
return ret;
}
+static int m920x_rc_core_query(struct dvb_usb_device *d)
+{
+ int ret = 0;
+ u8 *rc_state;
+ int state;
+
+ rc_state = kmalloc(2, GFP_KERNEL);
+ if (!rc_state)
+ return -ENOMEM;
+
+ if ((ret = m920x_read(d-udev, M9206_CORE, 0x0, M9206_RC_STATE,
rc_state[0], 1)) != 0)
+ goto out;
+
+ if ((ret = m920x_read(d-udev, M9206_CORE, 0x0, M9206_RC_KEY,
rc_state[1], 1)) != 0)
+ goto out;
+
+ deb(state=0x%02x keycode=0x%02x\n, rc_state[0], rc_state[1]);
+
+ m920x_parse_rc_state(d, rc_state[0], state);
+
+ if (state == REMOTE_NO_KEY_PRESSED)
+ rc_keyup(d-rc_dev);
+ else if (state == REMOTE_KEY_REPEAT)
+ rc_repeat(d-rc_dev);
+ else
+ rc_keydown(d-rc_dev, rc_state[1], 0);
+
+out:
+ kfree(rc_state);
+ return ret;
+}
+
/* I2C */
static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int
num)
{
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 5/9] [media] m920x: avoid repeating RC state parsing at each keycode
Parsing the RC press state is invariant wrt. the keycode, take it out of
the keycode scanning loop.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/usb/dvb-usb/m920x.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/m920x.c
b/drivers/media/usb/dvb-usb/m920x.c
index 581c5de..5f6ca75 100644
--- a/drivers/media/usb/dvb-usb/m920x.c
+++ b/drivers/media/usb/dvb-usb/m920x.c
@@ -197,10 +197,11 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
if ((ret = m920x_read(d-udev, M9206_CORE, 0x0, M9206_RC_KEY, rc_state
+ 1, 1)) != 0)
goto out;
+ m920x_parse_rc_state(d, rc_state[0], state);
+
for (i = 0; i d-props.rc.legacy.rc_map_size; i++)
if (rc5_data(d-props.rc.legacy.rc_map_table[i]) ==
rc_state[1]) {
*event = d-props.rc.legacy.rc_map_table[i].keycode;
- m920x_parse_rc_state(d, rc_state[0], state);
goto out;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop
On Tue, Nov 13, 2012 at 10:53:17AM +0100, Laurent Pinchart wrote: Hi Martin, On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote: [ snip ] These are 'Maintained' by me: i2c/aptina-pll.ko = i2c/aptina-pll.c i2c/mt9p031.ko = i2c/mt9p031.c i2c/mt9t001.ko = i2c/mt9t001.c i2c/mt9v032.ko = i2c/mt9v032.c I can maintain the following driver if needed: i2c/mt9m032.ko = i2c/mt9m032.c Do you plan to send a MAINTAINERS patch for this driver (and thus maintain the driver :-)), or should I maintain it ? I sadly neigher have time nor hardware to maintain this driver at the moment so i would be more than happy if you can maintain it. Thanks, - Martin Hostettler I could also take over maintenance the following driver, but I don't have access to a hardware platform that uses it: i2c/mt9v011.ko = i2c/mt9v011.c These are, as far as I know, co-maintained by Sakari and me :-) i2c/adp1653.ko = i2c/adp1653.c i2c/as3645a.ko = i2c/as3645a.c -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Understanding v4l2-ctl flags
On Mon December 10 2012 22:14:59 andrea wrote: Hi, I have a Logitech webcam under PWC. I've managed to use v4l2-ctl to change come controls, but some of them seem to be unsupported. v4l2-ctl reports the following flags inactive update slider write-only ** no flags at all ** e.g. restore_factory_settings (button) : flags=update, write-only What is the meaning of them? I can guess that inactive means unsupported, but do I care about the others? See the documentation for control flags: http://hverkuil.home.xs4all.nl/spec/media.html#control-flags 'inactive' doesn't mean unsupported, it just means that setting the control probably will have no effect at the moment. E.g. setting the gain when autogain is selected doesn't do anything. Only when the autogain is turned off can you set the gain control. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: First draft of guidelines for submitting patches to linux-media
Hi, On Monday 10 December 2012 16:33:13 Mauro Carvalho Chehab wrote: Em Mon, 10 Dec 2012 14:07:09 +0100 Hans Verkuil escreveu: Hi all, As discussed in Barcelona I would write a text describing requirements for new drivers and what to expect when submitting patches to linux-media. This is a first rough draft and nothing is fixed yet. I have a few open questions: 1) Where to put it? Maybe at media-build.git. Not everybody uses (or is even aware of) media-build. The goal here is to make sure that new driver developers will run into the guidelines before then spend months writing code that can't be upstreamed. Documentation/ thus looks like a good place to me. It might be a good idea to add a reference to the guidelines in the API DocBook documentation, regardless of where the guidelines end up being stored. If a developer reads a single document only it will probably be the API reference. I'm thinking on putting there, under devel_contrib, the main scripts I use here to handle patches. /me needs some time to sanitize them and add there. One thing I would propose that we improve is to move the dvb and video4linux directories in Documentation/ to Documentation/media to correctly reflect the drivers/media structure. If we do that, then we can put this document in Documentation/media/SubmittingMediaPatches. Hmm... I don't see any other subsystems having their own document for that. We may need to discuss it upstream before doing that, and be prepared to answer why we thing sub-systems would need their own rules there. Things like requiring the use of the control framework is obviously V4L- specific, we can't add that to Documentation/SubmittingPatches :-) In any case, I think that the better is to store it at media-build.git tree, and later open such discussions upstream, if we think it is valuable enough. Alternatively, this is something we can document in our wiki. 2) Are there DVB requirements as well for new drivers? We discussed a list of V4L2 requirements in Barcelona, but I wonder if there is a similar list that can be made for DVB drivers. Input on that will be welcome. See below. 3) This document describes the situation we will have when the submaintainers take their place early next year. So please check if I got that part right. 4) In Barcelona we discussed 'tags' for patches to help organize them. I've made a proposal for those in this document. Feedback is very welcome. 5) As discussed in Barcelona there will be git tree maintainers for specific platforms, but we didn't really go into detail who would be responsible for which platform. If you want to maintain a particular platform, then please let me know. 6) The patchwork section is very short at the moment. It should be extended when patchwork gets support to recognize the various tags. 7) Anything else that should be discussed here? Again, remember that this is a rough draft only, so be gentle with me :-) Regards, Hans --- cut here --- General Information === For general information on how to submit patches see: http://linuxtv.org/wiki/index.php/Developer_Section In particular the section 'Submitting Your Work'. This document goes into more detail regarding media specific requirements when submitting patches and what the patch flow looks like in this subsystem. I think we should add a paragraph here saying that rules may have exceptions, when there's a clear reason why a certain submission should need a different criteria. I agree. For instance the uvcvideo driver doesn't use the control framework, and has good reasons not to. This must be the exception rather than the rule, but we might have more than one exception. Also, IMHO, we should add a notice that this list is not exhaustive, and may be changed, keeping it for at least one or two Kernel cycles, while it doesn't get proofed/matured, as I'm sure we'll forget things. Submitting New Media Drivers When submitting new media drivers for inclusion in drivers/staging/media all that is required is that the driver compiles with the latest kernel and that an entry is added to the MAINTAINERS file Please add: and what is missing there for it to be promoted to be a main driver is documented at the TODO file. It should be noticed, however, that it is expected that the driver will be fixed to fulfill the requirements for upstream addition. If a driver at staging lacks relevant patches fixing it for more than a kernel cycle, it can be dropped without further notice. Maybe a single kernel cycle is a bit too strict. The unexpected can happen, so let's not be too harsh. And I'm pretty sure we'll always send a notice. For inclusion as a non-staging driver the requirements are more strict:
Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop
Hi Martin, On Monday 10 December 2012 23:01:31 mar...@neutronstar.dyndns.org wrote: On Tue, Nov 13, 2012 at 10:53:17AM +0100, Laurent Pinchart wrote: Hi Martin, On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote: [ snip ] These are 'Maintained' by me: i2c/aptina-pll.ko = i2c/aptina-pll.c i2c/mt9p031.ko = i2c/mt9p031.c i2c/mt9t001.ko = i2c/mt9t001.c i2c/mt9v032.ko = i2c/mt9v032.c I can maintain the following driver if needed: i2c/mt9m032.ko = i2c/mt9m032.c Do you plan to send a MAINTAINERS patch for this driver (and thus maintain the driver :-)), or should I maintain it ? I sadly neigher have time nor hardware to maintain this driver at the moment so i would be more than happy if you can maintain it. OK, I will do that. I could also take over maintenance the following driver, but I don't have access to a hardware platform that uses it: i2c/mt9v011.ko = i2c/mt9v011.c These are, as far as I know, co-maintained by Sakari and me :-) i2c/adp1653.ko = i2c/adp1653.c i2c/as3645a.ko = i2c/as3645a.c -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
is CI/CAM working at all?
I just tried to Anysee with CAM and it didn't work. Fedora 17 VLC, latest 3.7 Kernel and also latest 3.6. I can enter CAM menu (gnutv -cammenu), but no video stream. I updated subscription entitlements using Windows, so hardware is working. I wonder if it is some anysee or some other bug... Could anyone confirm if it works or not (Kernel 3.5+)? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] MAINTAINERS: Add entries for Aptina sensor drivers
Add an entry for the mt9m032, mt9p031, mt9t001 and mt9v032 Aptina sensor drivers. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- MAINTAINERS | 32 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9fba9ed..d4b699b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5008,6 +5008,38 @@ L: platform-driver-...@vger.kernel.org S: Supported F: drivers/platform/x86/msi-wmi.c +MT9M032 SENSOR DRIVER +M: Laurent Pinchart laurent.pinch...@ideasonboard.com +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/mt9m032.c +F: include/media/mt9m032.h + +MT9P031 SENSOR DRIVER +M: Laurent Pinchart laurent.pinch...@ideasonboard.com +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/mt9p031.c +F: include/media/mt9p031.h + +MT9T001 SENSOR DRIVER +M: Laurent Pinchart laurent.pinch...@ideasonboard.com +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/mt9t001.c +F: include/media/mt9t001.h + +MT9V032 SENSOR DRIVER +M: Laurent Pinchart laurent.pinch...@ideasonboard.com +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/mt9v032.c +F: include/media/mt9v032.h + MULTIFUNCTION DEVICES (MFD) M: Samuel Ortiz sa...@linux.intel.com T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] MAINTAINERS: Add an entry for the ad3645a LED flash controller driver
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- MAINTAINERS |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d4b699b..47678e4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1258,6 +1258,14 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm64/ +AS3645A LED FLASH CONTROLLER DRIVER +M: Laurent Pinchart laurent.pinch...@ideasonboard.com +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/as3645a.c +F: include/media/as3645a.h + ASC7621 HARDWARE MONITOR DRIVER M: George Joseph george.jos...@fairview5.com L: lm-sens...@lm-sensors.org -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] media: saa7146: don't use mutex_lock_interruptible() in device_release().
Use uninterruptible mutex_lock in the release() file op to make sure all
resources are properly freed when a process is being terminated. Returning
-ERESTARTSYS has no effect for a terminating process and this may cause driver
resources not to be released.
This was found using the following semantic patch (http://coccinelle.lip6.fr/):
spml
@r@
identifier fops;
identifier release_func;
@@
static const struct v4l2_file_operations fops = {
.release = release_func
};
@depends on r@
identifier r.release_func;
expression E;
@@
static int release_func(...)
{
...
- if (mutex_lock_interruptible(E)) return -ERESTARTSYS;
+ mutex_lock(E);
...
}
/spml
Signed-off-by: Cyril Roelandt tipec...@gmail.com
---
drivers/media/common/saa7146/saa7146_fops.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/common/saa7146/saa7146_fops.c
b/drivers/media/common/saa7146/saa7146_fops.c
index b3890bd..0afe98d 100644
--- a/drivers/media/common/saa7146/saa7146_fops.c
+++ b/drivers/media/common/saa7146/saa7146_fops.c
@@ -265,8 +265,7 @@ static int fops_release(struct file *file)
DEB_EE(file:%p\n, file);
- if (mutex_lock_interruptible(vdev-lock))
- return -ERESTARTSYS;
+ mutex_lock(vdev-lock);
if (vdev-vfl_type == VFL_TYPE_VBI) {
if (dev-ext_vv_data-capabilities V4L2_CAP_VBI_CAPTURE)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] media: saa7146: don't use mutex_lock_interruptible in
This is the same kind of bug as the one fixed by ddc43d6dc7df0849fe41b91460fa76145cf87b67 : mutex_lock() must be used in the device_release file operation in order for all resources to be freed, since returning -RESTARTSYS has no effect here. I stole the commit log from Sylwester Nawrocki, who fixed a few of these issues, since I could not formulate it better. --- Cyril Roelandt (1): media: saa7146: don't use mutex_lock_interruptible() in device_release(). drivers/media/common/saa7146/saa7146_fops.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: saa7146: don't use mutex_lock_interruptible() in device_release().
On Tue December 11 2012 04:05:28 Cyril Roelandt wrote:
Use uninterruptible mutex_lock in the release() file op to make sure all
resources are properly freed when a process is being terminated. Returning
-ERESTARTSYS has no effect for a terminating process and this may cause driver
resources not to be released.
Acked-by: Hans Verkuil hans.verk...@cisco.com
Thanks!
Hans
This was found using the following semantic patch
(http://coccinelle.lip6.fr/):
spml
@r@
identifier fops;
identifier release_func;
@@
static const struct v4l2_file_operations fops = {
.release = release_func
};
@depends on r@
identifier r.release_func;
expression E;
@@
static int release_func(...)
{
...
- if (mutex_lock_interruptible(E)) return -ERESTARTSYS;
+ mutex_lock(E);
...
}
/spml
Signed-off-by: Cyril Roelandt tipec...@gmail.com
---
drivers/media/common/saa7146/saa7146_fops.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/common/saa7146/saa7146_fops.c
b/drivers/media/common/saa7146/saa7146_fops.c
index b3890bd..0afe98d 100644
--- a/drivers/media/common/saa7146/saa7146_fops.c
+++ b/drivers/media/common/saa7146/saa7146_fops.c
@@ -265,8 +265,7 @@ static int fops_release(struct file *file)
DEB_EE(file:%p\n, file);
- if (mutex_lock_interruptible(vdev-lock))
- return -ERESTARTSYS;
+ mutex_lock(vdev-lock);
if (vdev-vfl_type == VFL_TYPE_VBI) {
if (dev-ext_vv_data-capabilities V4L2_CAP_VBI_CAPTURE)
--
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
