Re: [PATCH RFC 01/12] s5p-csis: Add device tree support
On Mon, 10 Dec 2012 20:45:55 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: 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); 'reg' has a very specific definition. If you're going to use a reg property here, then the parent nodes need to have #address-cells=1;#size-cells=0; properties to define the address specifier format. However since you're identifying port numbers that aren't really addresses I would suggest simply changing this property to something like 'port-num'. Otherwise the binding looks good. g. -- 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 01/13] i2c: add dummy inline functions for when CONFIG_OF_I2C(_MODULE) isn't defined
On Mon, 10 Dec 2012 20:41:27 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: 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 Applied, thanks. g. -- 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 02/13] of: add a dummy inline function for when CONFIG_OF is not defined
On Mon, 10 Dec 2012 20:41:28 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: 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. Where is this function getting called when CONFIG_OF is not defined? I suspect that any code calling of_get_parent() should be CONFIG_OF specific code and configured out when CONFIG_OF=n, but let me know if I'm missing something. g. -- 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 03/13] OF: define of_*_cmp() macros also if CONFIG_OF isn't set
On Mon, 10 Dec 2012 20:41:29 +0100, Sylwester Nawrocki s.nawro...@samsung.com
wrote:
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.
Patch looks fine, but I'd like to know the situation where you found
this problem. Again, anything calling these of_ helpers is probably
CONFIG_OF specific code.
I've resisted doing a blanket add of these helpers outside of CONFIG_OF
exactly because it helps identify CONFIG_OF code that should be compiled
out when CONFIG_OF=n
g.
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_DETACHED 2 /* node has been detached from the device tree */
--
1.7.9.5
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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 04/13] OF: make a function pointer argument const
On Mon, 10 Dec 2012 20:41:30 +0100, Sylwester Nawrocki s.nawro...@samsung.com
wrote:
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
The struct device_node * argument of of_parse_phandle_*() can be const.
This is a good time to talk about commit text. Again, the patch looks
fine, but it helps *a lot* if you give me some details about how you
constructed the patch and tested it.
What architectures did you build? What defconfigs did you use? Did you look
at all the users, or can you say the users should all be good?
It also always helps to tell my *why* you made a change.
Otherwise you leave all the leg work up to me or another maintainer.
We've got a lot of work. Anything you can do to make that easier makes
us less grumpy. :-)
I'll try to apply the patch (I've actually already merged another one
that does of_parse_phandle, but not of_parse_phandle_with_args, so I'll
need to resolve the conflict)
g.
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
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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 v2] media: v4l2-ctrl: Add gain controls
On Thu 6 December 2012 10:54:32 Sakari Ailus wrote: Hi Prabhakar and Hans, On Thu, Dec 06, 2012 at 10:24:18AM +0530, Prabhakar Lad wrote: Hi Hans, On Wed, Dec 5, 2012 at 5:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: (resend without HTML formatting) On Wed 5 December 2012 12:49:29 Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add support for per color component digital/analog gain controls and also their corresponding offset. Some obvious questions below... Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Hans de Goede hdego...@redhat.com Cc: Chris MacGregor ch...@cybermato.com Cc: Rob Landley r...@landley.net Cc: Jeongtae Park jtp.p...@samsung.com Cc: Mauro Carvalho Chehab mche...@infradead.org --- Changes for v2: 1: Fixed review comments pointed by Laurent. 2: Rebased on latest tree. Documentation/DocBook/media/v4l/controls.xml | 54 ++ drivers/media/v4l2-core/v4l2-ctrls.c | 11 + include/uapi/linux/v4l2-controls.h | 11 + 3 files changed, 76 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1..847a9bb 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4543,6 +4543,60 @@ interface and may change in the future./para specific test patterns can be used to test if a device is working properly./entry /row + row + entry spanname=idconstantV4L2_CID_GAIN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have + the capability to set per color component digital/analog gain values./entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have the + capability to set per color component digital/analog gain offset values. + V4L2_CID_GAIN_OFFSET is the global gain offset and the rest are per + color component gain offsets./entry If I set both V4L2_CID_GAIN_RED and V4L2_CID_RED_OFFSET, how are they supposed to interact? Or are they mutually exclusive? And if I set both V4L2_CID_GAIN_OFFSET and V4L2_CID_RED_OFFSET, how are they supposed to interact? This questions should be answered in the documentation... I haven’t worked on the hardware which supports both, What is the general behaviour when the hardware supports both per color component and global and both of them are set ? That could be helpful for me to document. I'd guess most of the time only either one is supported, Are you talking about GAIN_RED vs GAIN_RED_OFFSET or GAIN_OFFSET vs RED_OFFSET? Or both? and when someone thinks of supporting both on the same device, we can start thinking of the interaction of per-component and global ones. That may be hardware specific as well, so standardising it might not be possible. I think it'd be far more important to know which unit is it. Many such controls are indeed fixed
Re: [PATCH RFC 05/13] of: Add empty for_each_available_child_of_node() macro definition
On Mon, 10 Dec 2012 20:41:31 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: 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 What non-OF code is calling this function? g. --- 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 -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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/13] of: Add empty of_find_device_by_node() function definition
On Mon, 10 Dec 2012 20:41:32 +0100, Sylwester Nawrocki s.nawro...@samsung.com
wrote:
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
Same question here... Okay, I'll stop replying to these now. :-) When
you repost, for each one of these please tell me why the empty version
is needed. ie. what is the non-OF code block that is simpler if it
doesn't have to worry about CONFIG_OF?
g.
---
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
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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 v2] media: v4l2-ctrl: Add gain controls
On Tue 11 December 2012 09:56:42 Hans Verkuil wrote: On Thu 6 December 2012 10:54:32 Sakari Ailus wrote: Hi Prabhakar and Hans, On Thu, Dec 06, 2012 at 10:24:18AM +0530, Prabhakar Lad wrote: Hi Hans, On Wed, Dec 5, 2012 at 5:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: (resend without HTML formatting) On Wed 5 December 2012 12:49:29 Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add support for per color component digital/analog gain controls and also their corresponding offset. Some obvious questions below... Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Hans de Goede hdego...@redhat.com Cc: Chris MacGregor ch...@cybermato.com Cc: Rob Landley r...@landley.net Cc: Jeongtae Park jtp.p...@samsung.com Cc: Mauro Carvalho Chehab mche...@infradead.org --- Changes for v2: 1: Fixed review comments pointed by Laurent. 2: Rebased on latest tree. Documentation/DocBook/media/v4l/controls.xml | 54 ++ drivers/media/v4l2-core/v4l2-ctrls.c | 11 + include/uapi/linux/v4l2-controls.h | 11 + 3 files changed, 76 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1..847a9bb 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4543,6 +4543,60 @@ interface and may change in the future./para specific test patterns can be used to test if a device is working properly./entry /row + row + entry spanname=idconstantV4L2_CID_GAIN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have + the capability to set per color component digital/analog gain values./entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have the + capability to set per color component digital/analog gain offset values. + V4L2_CID_GAIN_OFFSET is the global gain offset and the rest are per + color component gain offsets./entry If I set both V4L2_CID_GAIN_RED and V4L2_CID_RED_OFFSET, how are they supposed to interact? Or are they mutually exclusive? And if I set both V4L2_CID_GAIN_OFFSET and V4L2_CID_RED_OFFSET, how are they supposed to interact? This questions should be answered in the documentation... I haven’t worked on the hardware which supports both, What is the general behaviour when the hardware supports both per color component and global and both of them are set ? That could be helpful for me to document. I'd guess most of the time only either one is supported, Are you talking about GAIN_RED vs GAIN_RED_OFFSET or GAIN_OFFSET vs RED_OFFSET? Or both? I guess GAIN_RED + GAIN_RED_OFFSET is fine as a combination after reading up on it a bit. It's the global vs per-component that's
Re: [PATCH RFC v2] media: v4l2-ctrl: Add gain controls
Hi Hans, On Tue, Dec 11, 2012 at 2:26 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu 6 December 2012 10:54:32 Sakari Ailus wrote: Hi Prabhakar and Hans, On Thu, Dec 06, 2012 at 10:24:18AM +0530, Prabhakar Lad wrote: Hi Hans, On Wed, Dec 5, 2012 at 5:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: (resend without HTML formatting) On Wed 5 December 2012 12:49:29 Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add support for per color component digital/analog gain controls and also their corresponding offset. Some obvious questions below... Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Hans de Goede hdego...@redhat.com Cc: Chris MacGregor ch...@cybermato.com Cc: Rob Landley r...@landley.net Cc: Jeongtae Park jtp.p...@samsung.com Cc: Mauro Carvalho Chehab mche...@infradead.org --- Changes for v2: 1: Fixed review comments pointed by Laurent. 2: Rebased on latest tree. Documentation/DocBook/media/v4l/controls.xml | 54 ++ drivers/media/v4l2-core/v4l2-ctrls.c | 11 + include/uapi/linux/v4l2-controls.h | 11 + 3 files changed, 76 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1..847a9bb 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4543,6 +4543,60 @@ interface and may change in the future./para specific test patterns can be used to test if a device is working properly./entry /row + row + entry spanname=idconstantV4L2_CID_GAIN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have + the capability to set per color component digital/analog gain values./entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have the + capability to set per color component digital/analog gain offset values. + V4L2_CID_GAIN_OFFSET is the global gain offset and the rest are per + color component gain offsets./entry If I set both V4L2_CID_GAIN_RED and V4L2_CID_RED_OFFSET, how are they supposed to interact? Or are they mutually exclusive? And if I set both V4L2_CID_GAIN_OFFSET and V4L2_CID_RED_OFFSET, how are they supposed to interact? This questions should be answered in the documentation... I haven’t worked on the hardware which supports both, What is the general behaviour when the hardware supports both per color component and global and both of them are set ? That could be helpful for me to document. I'd guess most of the time only either one is supported, Are you talking about GAIN_RED vs GAIN_RED_OFFSET or GAIN_OFFSET vs RED_OFFSET? Or both? and when someone thinks of supporting both on the same device, we can start thinking of the interaction of per-component and global ones. That may be hardware specific as well, so standardising it might not be possible. I think it'd
Re: RFC: First draft of guidelines for submitting patches to linux-media
Em Tue, 11 Dec 2012 00:52:39 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: 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. Agreed. 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. Yes. 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
Re: [PATCH RFC 01/12] s5p-csis: Add device tree support
Hello Grant,
On 12/11/2012 09:36 AM, Grant Likely wrote:
On Mon, 10 Dec 2012 20:45:55 +0100, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
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);
'reg' has a very specific definition. If you're going to use a reg
property here, then the parent nodes need to have
#address-cells=1;#size-cells=0; properties to define the address
specifier format.
However since you're identifying port numbers that aren't really
addresses I would suggest simply changing this property to something
like 'port-num'.
Otherwise the binding looks good.
Thank you for the review. Indeed I should have said about #address-cells,
#size-cells here. I thought using 'reg' was agreed during previous discussions
on the mailing lists (e.g. [1]), so I just carried on with 'reg'.
I should just have addressed the comments from Stephen and Rob, instead of
just resending same version of the documentation. I'll try to take care of
it in the next post. i.e. rename 'link' node to 'endpoint' and 'remote'
phandle to 'remote-endpoint'.
I'm not really sure what advantage 'reg' gives over a new property.
Would it still be OK to have port nodes names followed by indexes with
port-num instead of reg, e.g.
foo {
port@0 {
port-num = 0;
};
port@1 {
port-num = 1;
};
};
?
[1] http://www.spinics.net/lists/linux-sh/msg13383.html
--
Thanks,
Sylwester
--
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 Mauro, On Tuesday 11 December 2012 08:29:30 Mauro Carvalho Chehab wrote: Em Tue, 11 Dec 2012 00:52:39 +0100 Laurent Pinchart escreveu: On Monday 10 December 2012 16:33:13 Mauro Carvalho Chehab wrote: Em Mon, 10 Dec 2012 14:07:09 +0100 Hans Verkuil escreveu: [snip] 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. The above is not saying that it should be fixed on one kernel cycle. It says, instead, that drivers without relevant changes during a cycle can be dropped. We'll likely not enforce it too hard, except if we notice some sort of bad faith from the driver's maintainer. That's my point, exactly. The text above just sounds a bit too harsh for my taste, it might even scare people :-) I of course share your point of view that we want developers to understand that they need to work on staging drivers and not let them rot, And I'm pretty sure we'll always send a notice. The notice will likely be just a patch to the ML c/c the driver's maintainer and the mailing list. As the driver's maintainer email's address might have changed, and/or he might not be subscribed at the ML, it may happen that such email will never reach him. So, the it can be dropped without further notice wording is meant to avoid later complains that from driver's maintainer that he was not warned. It also passes the idea that no ack from the driver's maintainer is needed/expected on such patch. If you think it is badly written, feel free to change it, but keeping this idea. What about If no real effort to get a driver out of staging is noticed, the driver can be dropped from the kernel altogether. This policy can be applied over a single kernel release period and without any notice, although we will try our best to communicate with the driver developers and not to enforce the policy too harshly. 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; Should *not* ? :-) Gah... Yeah, it should read, instead: shouldn't. - Errors should be reported as negative numbers, using the Kernel error codes; CodingStyle, chapter 16 (although not as clearly stated). Yes, I know. Yet, this is one of the most frequent bad things we notice on code from new developers. IMHO, it doesn't hurt to explicitly say it here, likely pointing to the CodingStyle corresponding chapter. Maybe we could just add Follow the CodingStyle guidelines. - typedefs should't be used; CodingStyle, chapter 5. Same as above: that's the second most frequent bad thing. It seems that windows-way is to create typedefs for each struct and return positive, driver-specific return codes. At least I saw the very same pattern on all windows drivers I looked. [snip] Timeline for code submissions = After a new kernel is released the merge window will be open for about two weeks Please add: for the maintainers to send him the patches they already received him ? I suppose you mean Linus :-) Yes. Maybe it can be changed from send him to send upstream. during the last development cycle, and that went into the linux-next tree in time for the other maintainers and reviewers to double-check the entire set of changes for the next Linux version. (yeah, I know you're talking more about it later, but I think this makes it a little clearer that no submissions will typically be accepted so late at the development cycle). During that time Linus will merge any pending work for the next kernel. Once that merge window is closed only regression fixes and serious bug fixes will be accepted, everything else will be postponed please add: upstream postponed upstream ? What do you mean ? This is just a small
Re: RFC: First draft of guidelines for submitting patches to linux-media
I've added a few quick remarks below. I'll collect all the very useful feedback on Friday and post a new version. After that I'm on vacation for three weeks. On Tue 11 December 2012 11:29:30 Mauro Carvalho Chehab wrote: Em Tue, 11 Dec 2012 00:52:39 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: 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. I agree with Laurent here. The media_build repo isn't widely used, certainly not in the embedded world. I don't think we should stick documentation there. 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. Agreed. 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. Yes. 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
Re: Kworld PCI Analog TV Card Lite PVR-7134SE
On 12/11/2012 02:22 AM, Alfredo Jesús Delaiti wrote: 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. I've tried following the wiki, but i'm unable to set the correct tuner. Please take a look at my card and onboard chips (http://tinypic.com/view.php?pic=2lwnmucs=6) and the dmesg output. This is after manually specifying card=153 and tuner=61 (sudo modprobe saa7134 card=153 tuner=61) [ 2142.483753] Linux video capture interface: v2.00 [ 2142.517975] saa7130/34: v4l2 driver version 0, 2, 17 loaded [ 2142.518013] saa7134 :02:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 2142.518021] saa7134[0]: found at :02:00.0, rev: 1, irq: 16, latency: 32, mmio: 0xfe40 [ 2142.518030] saa7134[0]: subsystem: 17de:712b, board: Kworld Plus TV Analog Lite PCI [card=153,insmod option] [ 2142.518050] saa7134[0]: board init: gpio is 80407f [ 2142.546076] IR NEC protocol handler initialized [ 2142.548285] IR RC5(x) protocol handler initialized [ 2142.550044] IR RC6 protocol handler initialized [ 2142.552768] IR JVC protocol handler initialized [ 2142.554466] IR Sony protocol handler initialized [ 2142.562683] Registered IR keymap rc-kworld-plus-tv-analog [ 2142.562767] input: saa7134 IR (Kworld Plus TV Anal as /devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/rc/rc0/input7 [ 2142.563834] rc0: saa7134 IR (Kworld Plus TV Anal as /devices/pci:00/:00:1c.0/:01:00.0/:02:00.0/rc/rc0 [ 2142.564266] IR MCE Keyboard/mouse protocol handler initialized [ 2142.587345] lirc_dev: IR Remote Control driver registered, major 250 [ 2142.587783] IR LIRC bridge handler initialized [ 2142.710404] saa7134[0]: i2c eeprom 00: de 17 2b 71 10 28 ff ff ff ff ff ff ff ff ff ff [ 2142.710416] saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710427] saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710436] saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710446] saa7134[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710456] saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710466] saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710476] saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710485] saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710495] saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710505] saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710515] saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710525] saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710534] saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710544] saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.710554] saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2142.725718] i2c-core: driver [tuner] using legacy suspend method [ 2142.725721] i2c-core: driver [tuner] using legacy resume method [ 2142.754313] All bytes are equal. It is not a TEA5767 [ 2142.754323] tuner 14-0060: Tuner -1 found with type(s) Radio TV. [ 2142.756682] tea5767 14-0060: type set to Philips TEA5767HN FM Radio [ 2142.786402] saa7134[0]: registered device video0 [v4l2] [ 2142.787009] saa7134[0]: registered device vbi0 [ 2142.787585] saa7134[0]: registered device radio0 [ 2142.810813] saa7134 ALSA driver for DMA sound loaded [ 2142.810839] saa7134[0]/alsa: saa7134[0] at 0xfe40 irq 16 registered as card -2 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
Hi Hans, On Tuesday 11 December 2012 12:50:21 Hans Verkuil wrote: I've added a few quick remarks below. I'll collect all the very useful feedback on Friday and post a new version. After that I'm on vacation for three weeks. On Tue 11 December 2012 11:29:30 Mauro Carvalho Chehab wrote: Em Tue, 11 Dec 2012 00:52:39 +0100 Laurent Pinchart escreveu: On Monday 10 December 2012 16:33:13 Mauro Carvalho Chehab wrote: Em Mon, 10 Dec 2012 14:07:09 +0100 Hans Verkuil escreveu: [snip] 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. The above is not saying that it should be fixed on one kernel cycle. It says, instead, that drivers without relevant changes during a cycle can be dropped. We'll likely not enforce it too hard, except if we notice some sort of bad faith from the driver's maintainer. And I'm pretty sure we'll always send a notice. The notice will likely be just a patch to the ML c/c the driver's maintainer and the mailing list. As the driver's maintainer email's address might have changed, and/or he might not be subscribed at the ML, it may happen that such email will never reach him. So, the it can be dropped without further notice wording is meant to avoid later complains that from driver's maintainer that he was not warned. It also passes the idea that no ack from the driver's maintainer is needed/expected on such patch. If you think it is badly written, feel free to change it, but keeping this idea. 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; Should *not* ? :-) Gah... Yeah, it should read, instead: shouldn't. - Errors should be reported as negative numbers, using the Kernel error codes; CodingStyle, chapter 16 (although not as clearly stated). Yes, I know. Yet, this is one of the most frequent bad things we notice on code from new developers. IMHO, it doesn't hurt to explicitly say it here, likely pointing to the CodingStyle corresponding chapter. - typedefs should't be used; CodingStyle, chapter 5. Surprisingly this chapter doesn't mention typedefs for function pointers. Those are very hard to manage without a typedef. Agreed. Same as above: that's the second most frequent bad thing. It seems that windows-way is to create typedefs for each struct and return positive, driver-specific return codes. At least I saw the very same pattern on all windows drivers I looked. 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 tests. Please add: - hybrid tuners should be shared with DVB; DVB specific requirements: - Use the DVB core, for both internal and external APIs; - Each I2C-based chip should have its own driver; - Tuners and frontends should be mapped as different drivers; - hybrid tuners should be shared with V4L; Should something be mentioned with regards to DVBv5 and using GET/SET_PROPERTY? [snip] Reviewed-by/Acked-by Within the media subsystem there are three levels of
[PATCH] omap3isp: csiphy: Fix an uninitialized variable compiler warning
drivers/media/platform/omap3isp/ispcsiphy.c: In function
‘csiphy_routing_cfg’:
drivers/media/platform/omap3isp/ispcsiphy.c:71:57: warning: ‘shift’
may be used uninitialized in this function [-Wuninitialized]
drivers/media/platform/omap3isp/ispcsiphy.c:40:6: note: ‘shift’ was
declared here
The warning is a false positive but the compiler is right in
complaining. Fix it by using the correct enum data type for the iface
argument and adding a default case in the switch statement.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispcsiphy.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 3d56b33..c09de32 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -32,7 +32,8 @@
#include ispreg.h
#include ispcsiphy.h
-static void csiphy_routing_cfg_3630(struct isp_csiphy *phy, u32 iface,
+static void csiphy_routing_cfg_3630(struct isp_csiphy *phy,
+ enum isp_interface_type iface,
bool ccp2_strobe)
{
u32 reg = isp_reg_readl(
@@ -40,6 +41,8 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy *phy,
u32 iface,
u32 shift, mode;
switch (iface) {
+ default:
+ /* Should not happen in practice, but let's keep the compiler happy. */
case ISP_INTERFACE_CCP2B_PHY1:
reg = ~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
@@ -59,9 +62,8 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy *phy,
u32 iface,
}
/* Select data/clock or data/strobe mode for CCP2 */
- switch (iface) {
- case ISP_INTERFACE_CCP2B_PHY1:
- case ISP_INTERFACE_CCP2B_PHY2:
+ if (iface == ISP_INTERFACE_CCP2B_PHY1 ||
+ iface == ISP_INTERFACE_CCP2B_PHY2) {
if (ccp2_strobe)
mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
else
@@ -110,7 +112,8 @@ static void csiphy_routing_cfg_3430(struct isp_csiphy *phy,
u32 iface, bool on,
* and 3630, so they will not hold their contents in off-mode. This isn't an
* issue since the MPU power domain is forced on whilst the ISP is in use.
*/
-static void csiphy_routing_cfg(struct isp_csiphy *phy, u32 iface, bool on,
+static void csiphy_routing_cfg(struct isp_csiphy *phy,
+ enum isp_interface_type iface, bool on,
bool ccp2_strobe)
{
if (phy-isp-mmio_base[OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL]
--
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: RFC: First draft of guidelines for submitting patches to linux-media
On Mon 10 December 2012 14:07:09 Hans Verkuil wrote: 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? How to submit patches for a stable kernel. I can never remember, and I'm sure I'm not the only one :-) 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
Em Tue, 11 Dec 2012 12:39:06 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Hi Mauro, On Tuesday 11 December 2012 08:29:30 Mauro Carvalho Chehab wrote: Em Tue, 11 Dec 2012 00:52:39 +0100 Laurent Pinchart escreveu: On Monday 10 December 2012 16:33:13 Mauro Carvalho Chehab wrote: Em Mon, 10 Dec 2012 14:07:09 +0100 Hans Verkuil escreveu: [snip] 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. The above is not saying that it should be fixed on one kernel cycle. It says, instead, that drivers without relevant changes during a cycle can be dropped. We'll likely not enforce it too hard, except if we notice some sort of bad faith from the driver's maintainer. That's my point, exactly. The text above just sounds a bit too harsh for my taste, it might even scare people :-) I of course share your point of view that we want developers to understand that they need to work on staging drivers and not let them rot, And I'm pretty sure we'll always send a notice. The notice will likely be just a patch to the ML c/c the driver's maintainer and the mailing list. As the driver's maintainer email's address might have changed, and/or he might not be subscribed at the ML, it may happen that such email will never reach him. So, the it can be dropped without further notice wording is meant to avoid later complains that from driver's maintainer that he was not warned. It also passes the idea that no ack from the driver's maintainer is needed/expected on such patch. If you think it is badly written, feel free to change it, but keeping this idea. What about If no real effort to get a driver out of staging is noticed, the driver can be dropped from the kernel altogether. This policy can be applied over a single kernel release period and without any notice, although we will try our best to communicate with the driver developers and not to enforce the policy too harshly. OK. 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; Should *not* ? :-) Gah... Yeah, it should read, instead: shouldn't. - Errors should be reported as negative numbers, using the Kernel error codes; CodingStyle, chapter 16 (although not as clearly stated). Yes, I know. Yet, this is one of the most frequent bad things we notice on code from new developers. IMHO, it doesn't hurt to explicitly say it here, likely pointing to the CodingStyle corresponding chapter. Maybe we could just add Follow the CodingStyle guidelines. I prefer to keep those two (errno/typedefs) explicitly, as they're the most common cases. Maybe something like: - Follow Documentation/CodingStyle guidelines. Two common mistakes that should be fixed are to declare typedefs or to return positive, driver-specific error codes on functions, instead of using the standard Linux negative error codes. - typedefs should't be used; CodingStyle, chapter 5. Same as above: that's the second most frequent bad thing. It seems that windows-way is to create typedefs for each struct and return positive, driver-specific return codes. At least I saw the very same pattern on all windows drivers I looked. [snip] 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:
Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator
Sorry for the late answer to this. This allocator is needed because some device (like STA2X11 VIP) cannot work with DMA sg or DMA coherent. Some other device (like the one used by Jonathan when he proposes vb2-dma-nc allocator) can obtain much better performance with DMA streaming than coherent. Ok, please add such explanations at the patch's descriptions, as it is important not only for me, but to others that may need to use it.. OK 2) why vb2-dma-config can't be patched to use dma_map_single (eventually using a different vb2_io_modes bit?); I did not modify vb2-dma-contig because I was thinking that each DMA memory allocator should reflect a DMA API. The basic reason for having more than one VB low-level handling (vb2 was inspired on this concept) is that some DMA APIs are very different than the other ones (see vmalloc x DMA S/G for example). I didn't make a diff between videobuf2-dma-streaming and videobuf2-dma-contig, so I can't tell if it makes sense to merge them or not, but the above argument seems too weak. I was expecting for a technical reason why it wouldn't make sense for merging them. I cannot work on this now. But I think that I can do an integration like the one that I pushed some month ago (a8f3c203e19b702fa5e8e83a9b6fb3c5a6d1cce4). Wind River made that changes to videobuf-contig and I tested, fixed and pushed. 3) what are the usecases for it. Could you please detail it? Without that, one that would be needing to write a driver will have serious doubts about what would be the right driver for its usage. Also, please document it at the driver itself. I don't have a full understand of the board so I don't know exactly why dma_alloc_coherent does not work. I focused my development on previous work by Wind River. I asked to Wind River (which did all the work on this board) for the technical explanation about why coherent doesn't work, but they do not know. That's why I made the new allocator: coherent doesn't work and HW doesn't support SG. I'm not a DMA performance expert. As such, from that comment, it sounded to me that replacing dma-config/dma-sg by dma streaming will always give performance optimizations the hardware allow. me too, I'm not a DMA performance expert. I'm just an user of the DMA API. On my hardware simply it works only with that interface, it is not a performance problem. On a separate but related issue, while doing DMABUF tests with an Exynos4 hardware, using a s5p sensor, sending data to s5p-tv, I noticed a CPU consumption of about 42%, which seems too high. Could it be related to not using the DMA streaming API? As I wrote above, I'm not a DMA performance expert. I skip this -- Federico Vaga -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] vb2: force output buffers to fault into memory
Hi Marek, On Friday 07 December 2012 15:29:30 Marek Szyprowski wrote: On 12/6/2012 2:23 AM, Laurent Pinchart wrote: On Tuesday 04 December 2012 16:48:40 Hans Verkuil wrote: (repost after accidentally using HTML formatting) This needs a good review. The change is minor, but as I am not a mm expert, I'd like to get some more feedback on this. The dma-sg change has been successfully tested on our hardware, but I don't have any hardware to test the vmalloc change. Note that the 'write' attribute is still stored internally and used to tell whether set_page_dirty_lock() should be called during put_userptr. It is my understanding that that still makes sense, so I didn't change that. Regards, Hans --- start patch --- When calling get_user_pages for output buffers, the 'write' argument is set to 0 (since the DMA isn't writing to memory), This can cause unexpected results: If you calloc() buffer memory and do not fill that memory afterwards, then the kernel assigns most of that memory to one single physical 'zero' page. If you queue that buffer to the V4L2 driver, then it will call get_user_pages and store the results. Next you dequeue it, fill the buffer and queue it again. Now the V4L2 core code sees the same userptr and length and expects it to be the same buffer that it got before and it will reuse the results of the previous get_user_pages call. But that still points to zero pages, whereas userspace filled it up and so changed the buffer to use different pages. In other words, the pages the V4L2 core knows about are no longer correct. The solution is to always set 'write' to 1 as this will force the kernel to fault in proper pages. I'm wondering if we should really force faulting pages. The buffer given to the driver might be real read-only memory, in which case faulting the pages would probably hurt (agreed, that's pretty unlikely, but it's still a valid use case according to the API). Moreover, this wouldn't fix all similar userptr-related issues. An application could remap a completely different memory area to the same userspace address between two QBUF calls, and videobuf2 would not handle that properly. That's also a valid use case according to the API, and it would be pretty difficult to handle it correctly in an efficient way on the kernel side. I think we could modify the spec to forbid mapping changes between QBUF calls, and in that case the zero-page mapping situation you described could be forbidden as well. If we clearly document it in the spec we could push the responsibility of faulting the pages to userspace. I've spent some time thinking on this issue and I came to the conclusion that it might be a good idea extend the v4l2 spec with such case. Changing the write parameter for get_user_pages() is only a workaround, which doesn't even work for all possible use cases, so I agree with Laurent that user ptr usage should be much better documented. I only wonder if it a good idea to require faulting in pages from the user space application. Can we assume that memset(ptr, 0, buf_size) will do the job in all cases? I expect yes, but I would like to be really sure, Good question, I would also guess that memset should do, but I'm no expert on memory management code. this will be probably put into the documentation for the reference code. At the end of the day it's just an API contract, like all the others. The USERPTR API should, in my opinion, require userspace to provide a buffer backed by usable pages (for non PFNMAP buffers) or usable physical memory (for PFNMAP buffers). Otherwise the kernel will need to switch to a guesswork mode, which is hackish at best. Of course people should use DMABUF instead of USERPTR when possible :-) -- 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: RFC: First draft of guidelines for submitting patches to linux-media
Em Tue, 11 Dec 2012 12:50:21 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: - typedefs should't be used; CodingStyle, chapter 5. Surprisingly this chapter doesn't mention typedefs for function pointers. Those are very hard to manage without a typedef. It seems you detected a potential patch for CodingStyle ;) Anyway, this one of the exceptions that would be accepted. Very unlikely to have it at driver level anyway, as function pointers is more used at the core handlers. DVB specific requirements: - Use the DVB core, for both internal and external APIs; - Each I2C-based chip should have its own driver; - Tuners and frontends should be mapped as different drivers; - hybrid tuners should be shared with V4L; Should something be mentioned with regards to DVBv5 and using GET/SET_PROPERTY? The DVB internal API already enforces it. There's only one thing that could be miss-filled due to DVBv3. So, please add: - dvb_frontend_ops should specify the delivery system, instead of specifying the frontend type via dvb_frontend_ops info.type field. You can also add: - DVB frontends should not implement dummy function handlers; if the function is not implemented, the DVB core should be handled it properly. ... When we point that responsibility to a single person, I'm afraid that the message passed is that he is the sole/main responsible for reviewing core changes, and this is not the case, as it is everybody's responsibility to review v4l/dvb/media controller core changes True, but I think it is a good idea to have a main reviewer assigned whose Acked-by you definitely need. Sure, I can ack a DVB core patch, but that carries a lot less weight than if Mike acks it. I think you'll likely be surprised if you play a little bit with get_maintainer.pl under the DVB tree. For example: $ ./scripts/get_maintainer.pl -f --git-blame drivers/media/dvb-core/dvb_ca_en50221.c Mauro Carvalho Chehab mche...@redhat.com (maintainer:MEDIA INPUT INFRA...,commit_signer:2/2=100%,commits:18/24=75%) Andrew de Quincey adq_...@lidskialf.net (authored lines:41/172=24%,commits:3/24=12%) Matthias Dahl de...@mortal-soul.de (authored lines:21/172=12%) Johannes Stezenbach j...@linuxtv.org (authored lines:19/172=11%,commits:3/24=12%) Harvey Harrison harvey.harri...@gmail.com (authored lines:18/172=10%) Robert Schedel r.sche...@yahoo.de (authored lines:16/172=9%) Andrew Morton a...@osdl.org (commits:7/24=29%) Oliver Endriss o.endr...@gmx.de (commits:6/24=25%) linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) linux-ker...@vger.kernel.org (open list) So, your ack for a patch at dvb_ca_en50221.c is as good as Mike's one, as none of you ever touched there, according with git blame. - Guennadi Liakhovetski: soc-camera drivers - Laurent Pinchart: sensor subdev drivers. In addition he'll be the reviewer for Media Controller core patches. I'll change it to a reviewer, as perhaps he won't be able to review everything, and because we're welcoming others to also review it. Ditto. - 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. I'll change it to a reviewer, as perhaps he won't be able to review everything, and because we're welcoming others to also review it. Ditto. 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 - s5p/exynos? - DaVinci? - Omap3? - Omap2? - dvb-usb-v2? Some of those (OMAP2 and OMAP3 at least) are really single drivers. I'm not sure whether we need to list them as platforms. We're currently handling all those Nokia/TI drivers as one platform set of drivers and waiting for Prabhakar to merge them on his tree and submit via git pull request That's only for the davinci code. Prabhakar doesn't handle omap3, that's a single driver at the moment. Ideally there would be an omap directory where TI would maintain the
How to configure resizer in ISP pipeline?
Hello, using Media Controller API, I can successfully configure a simple ISP pipeline on an OMAP3530 and capture video data. Now I want to include the resizer. So the pipeline would look like this (where MEM would be the devnode corresponding to resizer output): Sensor -- CCDC -- Resizer -- MEM My sensor (TVP5146) already provides YUV data, so I can skip the previewer. I tried setting the input and output pad of the resizer subdevice to incoming resolution (input pad) and desired resolution (output pad). For example: 720x576 -- 352x288. But it didn't work out quite well. Can someone explain how one properly configures the resizer in an ISP pipeline (with Media Controller API) ? I spend some hours researching, but this topic seems to be a well guarded secret... Kind regards, Andreas -- 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 Tue, 11 Dec 2012 13:20:32 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: [snip] - not sure if this is possible: if a v2 patch series is posted, then automatically remove v1. This would require sanity checks: same subject, same author. There's a security issue here as it's easy to spoof a sender e-mail address, but I don't think that we need to care about it. This can be easily detected: if the patch author didn't opt-out, he, and the others who signed the v1 patch will receive a notification when it gets any status change. Also, when the patch gets merged on my tree, the author will receive another email. So, a fake submission can easily be detected. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: First draft of guidelines for submitting patches to linux-media
Em Tue, 11 Dec 2012 14:15:31 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Mon 10 December 2012 14:07:09 Hans Verkuil wrote: 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? How to submit patches for a stable kernel. I can never remember, and I'm sure I'm not the only one :-) The standard way is to add this tag: Cc: sta...@vger.kernel.org eventually with a comment saying to what versions it should be applied, like: Cc: sta...@vger.kernel.org # for v3.5 and upper If it is noticed later the need for it on stable, or a backport is needed, the patch author should send the patch to sta...@vger.kernel.org, c/c the ML, preferably pointing to the upstream commit ID. The patch has to be merged upstream before being merged at stable. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3isp: csiphy: Fix an uninitialized variable compiler warning
On Tue, Dec 11, 2012 at 02:11:52PM +0100, Laurent Pinchart wrote: drivers/media/platform/omap3isp/ispcsiphy.c: In function ‘csiphy_routing_cfg’: drivers/media/platform/omap3isp/ispcsiphy.c:71:57: warning: ‘shift’ may be used uninitialized in this function [-Wuninitialized] drivers/media/platform/omap3isp/ispcsiphy.c:40:6: note: ‘shift’ was declared here The warning is a false positive but the compiler is right in complaining. Fix it by using the correct enum data type for the iface argument and adding a default case in the switch statement. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks! Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 05/13] of: Add empty for_each_available_child_of_node() macro definition
On 12/11/2012 09:57 AM, Grant Likely wrote:
On Mon, 10 Dec 2012 20:41:31 +0100, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
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
What non-OF code is calling this function?
It is used in a driver [1] in an OF specific function. The patch is
in my second series that depends this one.
[PATCH RFC 00/12] Device tree support for Exynos4 SoC camera drivers
I thought it was better to add this empty macro definition rather
than using #ifdef CONFIG_OF in the code. However, in this case
the local variables would remain unused, so it's not really any
good solution. It just looked cumbersome to me to have in the code
something like
#ifdef CONFIG_OF
int func(void)
{
int x;
return x;
}
#else
#define func() (-ENOSYS)
#endif
After all it's not that bad and allows to compile out all OF code
when it's unused.
Please ignore patches 05..07/13, I'll drop them in next iteration.
And sorry for the noise.
[1] http://patchwork.linuxtv.org/patch/15852/
---
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
Thanks,
Sylwester
--
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
How to manage weighted sections for scene brightness calculation
Hi, I'm writing a driver for a CMOS sensor having the following feature: the frame average brightness value is given by the weighted average of 16 sections. In other words, the scene is divided into 16 square areas: each area can be weighted differently (from 1 to 4) to achieve the whole scene brightness. How can I set the 16 weights of the sub-windows from userspace? Which controls or ioctl can I use to implement such a function? Thank you for the support, Davide Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite. This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. -- 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 01/12] s5p-csis: Add device tree support
On Tue, 11 Dec 2012 12:24:23 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hello Grant, On 12/11/2012 09:36 AM, Grant Likely wrote: On Mon, 10 Dec 2012 20:45:55 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: 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); 'reg' has a very specific definition. If you're going to use a reg property here, then the parent nodes need to have #address-cells=1;#size-cells=0; properties to define the address specifier format. However since you're identifying port numbers that aren't really addresses I would suggest simply changing this property to something like 'port-num'. Otherwise the binding looks good. Thank you for the review. Indeed I should have said about #address-cells, #size-cells here. I thought using 'reg' was agreed during previous discussions on the mailing lists (e.g. [1]), so I just carried on with 'reg'. I should just have addressed the comments from Stephen and Rob, instead of just resending same version of the documentation. I'll try to take care of it in the next post. i.e. rename 'link' node to 'endpoint' and 'remote' phandle to 'remote-endpoint'. Could be. I can't remember what has been discussed from one day to the next. :-) If you've got #address/#size-cells in the binding, then reg is fine. If that's what you've already got, then just leave it. As long as the conventions are intact. g. -- 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 20:40, schrieb Mauro Carvalho Chehab: [snip] 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. I don't want to complain (yet ;) ). I'm just trying to understand what is supposed to reduce the review times... Haven't succeeded yet, because the same amount work seems to be redivided among the same amount of maintainer/reviewer resources (=people). Anyway, I will be patient and hope that things will evolve as planed. I will also try to test and/or review patches from other if possible. [snip] So who can get an account / is supposed to access patchwork ? - subsystem maintainers ? - driver maintainers ? - patch creators ? Subsystem maintainers only, except if someone can fix patchwork, adding proper ACL's there to allow patch creators to manage their own patches and sub-system maintainers to delegate work to driver maintainers, without giving them full rights, and being notified about status changes on those driver's patches. Ok, thanks, I think this should be mentioned in the document. 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: EM2800 and audio via USB ?
Am 10.12.2012 21:08, schrieb Devin Heitmueller: 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. Yes, I remeber these days ;) I just wonder why it has a line-in input. It seems it is completely useless... 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]
Am 10.12.2012 21:48, schrieb Antti Palosaari: 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. Many thanks. So the problem is, that we have only a single RC_TYPE for all 3 protocol variants and need a method to distinguish between them, right ? Regards, Frank regards Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Dec 11 19:00:20 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/11/2012 10:51 PM, Frank Schäfer wrote: Am 10.12.2012 21:48, schrieb Antti Palosaari: 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. Many thanks. So the problem is, that we have only a single RC_TYPE for all 3 protocol variants and need a method to distinguish between them, right ? Yes, that is. I have said it million times I would like to see that implemented as a one single 4 byte NEC, but it is currently what it is. What I understand David Härdeman has done some work toward that too, but it is not ready. See current af9015 driver as example how driver makes decision which variant of NEC is used. You will need something similar. Read all 4 NEC bytes from the hardware and then use driver to make decision which variant it is. I am quite sure em28xx hardware supports reading all 4 bytes, but if not, you will need to do some other tricks. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] V4L: Add auto focus selection targets
Hi Andrzej, Many thanks for the patch! On Mon, Dec 10, 2012 at 02:43:38PM +0100, Andrzej Hajda wrote: From: Sylwester Nawrocki s.nawro...@samsung.com The camera automatic focus algorithms may require setting up a spot or rectangle coordinates. The automatic focus selection targets are introduced in order to allow applications to query and set such coordinates. Those selections are intended to be used together with the automatic focus controls available in the camera control class. 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/selection-api.xml | 32 - .../DocBook/media/v4l/selections-common.xml| 37 .../media/v4l/vidioc-subdev-g-selection.xml|4 +-- include/uapi/linux/v4l2-common.h |5 +++ 4 files changed, 75 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml index 4c238ce..8caf67b 100644 --- a/Documentation/DocBook/media/v4l/selection-api.xml +++ b/Documentation/DocBook/media/v4l/selection-api.xml @@ -1,6 +1,6 @@ section id=selection-api - titleExperimental API for cropping, composing and scaling/title + titleExperimental selections API/title Hmm. I wonder if it'd be enough to call this just Selection API. There's a note just below telling it's experimental. note titleExperimental/title @@ -9,6 +9,10 @@ interface and may change in the future./para /note + section + + titleImage cropping, composing and scaling/title + section titleIntroduction/title @@ -321,5 +325,31 @@ V4L2_BUF_TYPE_VIDEO_OUTPUT /constant for other devices/para /example /section + /section + + section + titleAutomatic focus regions of interest/title + +paraThe camera automatic focus algorithms may require configuration of +regions of interest in form of rectangle or spot coordinates. The automatic +focus selection targets allow applications to query and set such coordinates. +Those selections are intended to be used together with the +constantV4L2_CID_AUTO_FOCUS_AREA/constant link linkend=camera-controls +camera class/link control. The constantV4L2_SEL_TGT_AUTO_FOCUS/constant +target is used for querying or setting actual spot or rectangle coordinates, +while constantV4L2_SEL_TGT_AUTO_FOCUS_BOUNDS/constant target determines +bounds for a single spot or rectangle. +These selections are only effective when the constantV4L2_CID_AUTO_FOCUS_AREA +/constantcontrol is set to +constantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constant. The new coordinates shall +be accepted and applied to hardware when the focus area control value is +changed and also during a VIDIOC-S-SELECTION; ioctl call, only when the focus +area control is already set to required value./para + +paraWhen the structfieldwidth/structfield and +structfieldheight/structfield of the selection rectangle are set to 0 the +selection determines spot coordinates, rather than a rectangle./para + + /section /section diff --git a/Documentation/DocBook/media/v4l/selections-common.xml b/Documentation/DocBook/media/v4l/selections-common.xml index 7502f78..9f0c477 100644 --- a/Documentation/DocBook/media/v4l/selections-common.xml +++ b/Documentation/DocBook/media/v4l/selections-common.xml @@ -93,6 +93,22 @@ entryYes/entry entryNo/entry /row + row + entryconstantV4L2_SEL_TGT_AUTO_FOCUS/constant/entry + entry0x1001/entry + entryActual automatic focus rectangle./entry + entryYes/entry + entryYes/entry + /row + row + entryconstantV4L2_SEL_TGT_AUTO_FOCUS_BOUNDS/constant/entry + entry0x1002/entry + entryBounds of the automatic focus region of interest. All valid + automatic focus rectangles fit inside the automatic focus bounds + rectangle./entry + entryYes/entry + entryYes/entry + /row /tbody /tgroup /table @@ -158,7 +174,28 @@ /tbody /tgroup /table + /section + + section + titleAutomatic focus regions of interest/title + + paraThe camera automatic focus algorithms may require configuration + of a region or multiple regions of interest in form of rectangle or spot + coordinates./para + + paraA single rectangle of interest is represented in v4l2-rect; + by the coordinates of the top left corner and the rectangle size. Both + the coordinates and sizes are expressed in pixels. When the structfield + width/structfield and structfieldheight/structfield fields of + v4l2-rect; are set to 0 the selection determines spot coordinates, + rather than a
Re: [PATCH RFC 2/2] V4L: Add V4L2_CID_AUTO_FOCUS_AREA control
Hi Andrzej and Sylwester, Thanks for the patch! On Mon, Dec 10, 2012 at 02:43:39PM +0100, Andrzej Hajda wrote: 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 Extra space above.^ +invoke a VIDIOC-SUBDEV-S-SELECTION; or a VIDIOC-S-SELECTION; ioctl again. How about requiring explicit V4L2_CID_AUTO_FOCUS_START? If you need to specify several AF selection windows, then on which one do you start the algorithm? A bitmask control explicitly telling which ones are active would also be needed --- but that's for the future. I think now we just need to ascertain we don't make that difficult. :-) +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 Does this need to be explicitly specified? Shouldn't the user just choose the largest possible AF window instead? I'd even expect that the AF window might span the whole frame by default (up to driver, hardware etc.). + /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 It's not strictly required in documentation (and that shows) but it'd be nice to align the paragraphs at equal indentation. + /row + row + entryconstantV4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION/constantnbsp;/entry + entryThe auto focus region of interest is determined +by an object
[PATCH 08/19] MAINTAINERS: fix drivers/media/usb/dvb-usb/cxusb*
This driver was never at dvb-usb-v2, as far as I could see. Cc: Michael Krufky mkru...@linuxtv.org Cc: linux-media@vger.kernel.org Signed-off-by: Cesar Eduardo Barros ces...@cesarb.net --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8265764..b8dfc72 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2594,7 +2594,7 @@ W:http://github.com/mkrufky Q: http://patchwork.linuxtv.org/project/linux-media/list/ T: git git://linuxtv.org/media_tree.git S: Maintained -F: drivers/media/usb/dvb-usb-v2/cxusb* +F: drivers/media/usb/dvb-usb/cxusb* DVB_USB_CYPRESS_FIRMWARE MEDIA DRIVER M: Antti Palosaari cr...@iki.fi -- 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
[PATCH 06/19] MAINTAINERS: fix drivers/media/platform/atmel-isi.c
This file was moved to drivers/media/platform/soc_camera/atmel-isi.c by commit b47ff4a ([media] move soc_camera to its own directory). Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Josh Wu josh...@atmel.com Cc: linux-media@vger.kernel.org Signed-off-by: Cesar Eduardo Barros ces...@cesarb.net --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1fb780e..efbdf54 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1395,7 +1395,7 @@ ATMEL ISI DRIVER M: Josh Wu josh...@atmel.com L: linux-media@vger.kernel.org S: Supported -F: drivers/media/platform/atmel-isi.c +F: drivers/media/platform/soc_camera/atmel-isi.c F: include/media/atmel-isi.h ATMEL LCDFB DRIVER -- 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 RFC v2] media: v4l2-ctrl: Add gain controls
Hi Hans, On Tue, Dec 11, 2012 at 09:56:42AM +0100, Hans Verkuil wrote: ... If I set both V4L2_CID_GAIN_RED and V4L2_CID_RED_OFFSET, how are they supposed to interact? Or are they mutually exclusive? And if I set both V4L2_CID_GAIN_OFFSET and V4L2_CID_RED_OFFSET, how are they supposed to interact? This questions should be answered in the documentation... I haven’t worked on the hardware which supports both, What is the general behaviour when the hardware supports both per color component and global and both of them are set ? That could be helpful for me to document. I'd guess most of the time only either one is supported, Are you talking about GAIN_RED vs GAIN_RED_OFFSET or GAIN_OFFSET vs RED_OFFSET? Or both? Per-component vs. global controls. Few devices support both; AFAIR on SMIA the user can choose which one to use, but the driver implements neither currently. and when someone thinks of supporting both on the same device, we can start thinking of the interaction of per-component and global ones. That may be hardware specific as well, so standardising it might not be possible. I think it'd be far more important to know which unit is it. Many such controls are indeed fixed point values but the location of the point varies. For unstance, u16,u16 and u8,u8 aren't uncommon. We currently have no way to tell this to the user space. This isn't in any way specific to gain or offset controls, though. There are no standardized units for gain at the moment, and I don't really see that happening any time soon. Fixed point isn't supported at all as a control type, so that will have to be converted to an integer anyway. Do you think it'd require a new control type? There might be many; some devices use funny fixed point values, such as u8.u5. I guess you could use step for those, sure. For instance, some sensors natively use lines to tell the exposure value (and in low level sensors control the granularity really matters, so lines it should be) whereas some SoC ones could use µs instead. This is about units and prefixes IMO. Fixed point is just a prefix, such as milli or micro, but instead of being a power of ten it's a power of two. This would also allow telling the user about a gain control that e.g. the value 0x100 means no gain. I think someone should write an RFC about this. :-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EM2800 and audio via USB ?
Frank Schäfer fschaefer@googlemail.com writes: Yes, I remeber these days ;) I just wonder why it has a line-in input. It seems it is completely useless... Just a guess: The line-in is patched through to line-out when the TV tuner is not in use. That way you do not have to move cables all the time if you have another device you want to use with line-in on your soundcard. /Benny -- 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/5] media: davinci: fix return value check in vpbe_display_reqbufs().
vb2_dma_contig_init_ctx() returns ERR_PTR and never returns NULL, so IS_ERR
should be used instead of a NULL check.
Signed-off-by: Cyril Roelandt tipec...@gmail.com
---
drivers/media/platform/davinci/vpbe_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 2bfde79..2db4eff 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -1393,7 +1393,7 @@ static int vpbe_display_reqbufs(struct file *file, void
*priv,
}
/* Initialize videobuf queue as per the buffer type */
layer-alloc_ctx = vb2_dma_contig_init_ctx(vpbe_dev-pdev);
- if (!layer-alloc_ctx) {
+ if (IS_ERR(layer-alloc_ctx)) {
v4l2_err(vpbe_dev-v4l2_dev, Failed to get the context\n);
return -EINVAL;
}
--
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 2/5] media: davinci: fix return value check in vpbe_display_reqbufs().
Hi Cyril,
On Wed, Dec 12, 2012 at 5:54 AM, Cyril Roelandt tipec...@gmail.com wrote:
vb2_dma_contig_init_ctx() returns ERR_PTR and never returns NULL, so IS_ERR
should be used instead of a NULL check.
patch fixing this issue has been already posted with a better fix
https://patchwork.kernel.org/patch/1830231/
Regards,
--Prabhakar Lad
Signed-off-by: Cyril Roelandt tipec...@gmail.com
---
drivers/media/platform/davinci/vpbe_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 2bfde79..2db4eff 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -1393,7 +1393,7 @@ static int vpbe_display_reqbufs(struct file *file, void
*priv,
}
/* Initialize videobuf queue as per the buffer type */
layer-alloc_ctx = vb2_dma_contig_init_ctx(vpbe_dev-pdev);
- if (!layer-alloc_ctx) {
+ if (IS_ERR(layer-alloc_ctx)) {
v4l2_err(vpbe_dev-v4l2_dev, Failed to get the context\n);
return -EINVAL;
}
--
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
--
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
Dear Alfredo, Thank you for helping me. Is the same card: Board indentification : 713XTV VRE: J Yes, I have the same board. 713XTV VRE:J Please try: modprobe saa7134 card=63 tuner=43 or modprobe saa7134 card=59 tuner=56 please tell me which program you use to watch TV. Use xawtvand set it well,run from a terminal I'm using tv-time and scantv. I've also tried VLC and Mplayer. I will try xawtvand. What is your country and TV standard?, Do the channels are correctly set? Country: Pakistan, TV Standard: PAL-B Since the proper tuner is not getting detected, I can't scan for channels. BTW I tried the card in a windows box borrowed from my cousin. The card works fine. I had a similar problem and what I did was try all tuners example: modprobe saa7134 card=63 tuner=1 modprobe saa7134 card=63 tuner=2 ... modprobe saa7134 card=63 tuner=63 modprobe saa7134 card=59 tuner=1 modprobe saa7134 card=59 tuner=2 ... modprobe saa7134 card=59 tuner=56 I will try different card/tuner combinations but since there are 50+ cards and 50+ tuners, you can imagine the number of combinations :) Plus I can't seem to unload the saa7134 module using modprobe -r or rmmod...It gives a FATAL module in use error. So I have to reboot the machine every time to set new card/tuner which SUCKS. I think that your card isn't 153.There are many cards with the same name but different electronic. The tuner is what is below the sticker that says kworld. Perhaps you can see the name of the tuner. In the jpeg link I posted in the earlier message, I have labelled all the onboard chips. Have a look again: http://tinypic.com/view.php?pic=2lwnmucs=6 I can't seem to find which chip is the tuner. I emailed Kworld support, they say its a TENA TNF9533BDF/BK tuner. I can't find any chip onbaord with this name! Anyways thanks again. 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
