Re: [PATCHv2 2/3] hdmi: added unpack and logging functions for InfoFrames
On Tue, Dec 02, 2014 at 01:08:45PM +0100, Hans Verkuil wrote:
From: Martin Bugge marbu...@cisco.com
When receiving video it is very useful to be able to unpack the InfoFrames.
Logging is useful as well, both for transmitters and receivers.
Especially when implementing the VIDIOC_LOG_STATUS ioctl (supported by many
V4L2 drivers) for a receiver it is important to be able to easily log what
the InfoFrame contains. This greatly simplifies debugging.
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/video/hdmi.c | 819
++-
include/linux/hdmi.h | 4 +
2 files changed, 816 insertions(+), 7 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 9e758a8..5f7ab47 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -27,10 +27,12 @@
#include linux/export.h
#include linux/hdmi.h
#include linux/string.h
+#include linux/device.h
-static void hdmi_infoframe_checksum(void *buffer, size_t size)
+#define hdmi_log(fmt, ...) dev_printk(level, dev, fmt, ##__VA_ARGS__)
I personally dislike macros like these that make assumptions about the
environment. While somewhat longer, directly using dev_printk() would in
my opinion be clearer.
But I realize this is somewhat bikesheddy, so don't consider it a hard
objection.
+
+static u8 hdmi_infoframe_checksum(u8 *ptr, size_t size)
{
- u8 *ptr = buffer;
For consistency with the other functions I'd prefer this to take void *
instead of u8 *. That'd also clean up the diff in this part a little.
u8 csum = 0;
size_t i;
@@ -38,7 +40,14 @@ static void hdmi_infoframe_checksum(void *buffer, size_t
size)
for (i = 0; i size; i++)
csum += ptr[i];
- ptr[3] = 256 - csum;
+ return 256 - csum;
+}
+
+static void hdmi_infoframe_set_checksum(void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ /* update checksum */
I think checkpatch warns these days about missing blank lines after the
declaration block. But perhaps it is tricked by the comment immediately
following.
Nit: I don't think the comment adds any value.
+static void hdmi_infoframe_log_header(const char *level,
+ struct device *dev, void *f)
Perhaps rather than pass a void *, make this take a hdmi_any_infoframe *
and require callers to explicitly cast.
This is an internal API and therefore less likely to be abused, so again
rather bikesheddy.
+static const char *hdmi_nups_get_name(enum hdmi_nups nups)
+{
+ switch (nups) {
+ case HDMI_NUPS_UNKNOWN:
+ return No Known Non-uniform Scaling;
s/No Known/Unknown/?
+static void hdmi_avi_infoframe_log(const char *level,
+struct device *dev,
+struct hdmi_avi_infoframe *frame)
+{
+ hdmi_infoframe_log_header(level, dev, frame);
+
+ hdmi_log(colorspace: %s\n,
+ hdmi_colorspace_get_name(frame-colorspace));
+ hdmi_log(scan mode: %s\n,
+ hdmi_scan_mode_get_name(frame-scan_mode));
+ hdmi_log(colorimetry: %s\n,
+ hdmi_colorimetry_get_name(frame-colorimetry));
+ hdmi_log(picture aspect: %s\n,
+ hdmi_picture_aspect_get_name(frame-picture_aspect));
+ hdmi_log(active aspect: %s\n,
+ hdmi_active_aspect_get_name(frame-active_aspect));
+ hdmi_log(itc: %s\n, frame-itc ? IT Content : No Data);
+ hdmi_log(extended colorimetry: %s\n,
+
hdmi_extended_colorimetry_get_name(frame-extended_colorimetry));
+ hdmi_log(quantization range: %s\n,
+
hdmi_quantization_range_get_name(frame-quantization_range));
+ hdmi_log(nups: %s\n, hdmi_nups_get_name(frame-nups));
+ hdmi_log(video code: %d\n, frame-video_code);
This could be %u.
+ hdmi_log(ycc quantization range: %s\n,
+
hdmi_ycc_quantization_range_get_name(frame-ycc_quantization_range));
+ hdmi_log(hdmi content type: %s\n,
+ hdmi_content_type_get_name(frame-content_type));
+ hdmi_log(pixel repeat: %d\n, frame-pixel_repeat);
+ hdmi_log(bar top %d, bottom %d, left %d, right %d\n,
+ frame-top_bar, frame-bottom_bar,
+ frame-left_bar, frame-right_bar);
Same here.
+static const char *
+hdmi_audio_coding_type_get_name(enum hdmi_audio_coding_type coding_type)
+{
+ switch (coding_type) {
+ case HDMI_AUDIO_CODING_TYPE_STREAM:
+ return Refer to Stream Header;
[...]
+ case HDMI_AUDIO_CODING_TYPE_CXT:
+ return Refer to CXT;
These aren't really names, but I can't come up with anything better.
+static const char *
+hdmi_audio_coding_type_ext_get_name(enum hdmi_audio_coding_type_ext ctx)
+{
+
Re: [PATCHv2 0/3] hdmi: add unpack and logging functions
On Thu, Dec 11, 2014 at 09:57:54AM +0100, Hans Verkuil wrote: Hi Thierry, On 12/02/14 13:08, Hans Verkuil wrote: This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and adds unpacking and logging functions to hdmi.c. It also uses those in the V4L2 adv7842 driver (and they will be used in other HDMI drivers once this functionality is merged). Patches 2 and 3 have been posted before by Martin Bugge. It stalled, but I am taking over from Martin to try and get this is. I want to use this in a bunch of v4l2 drivers, so I would really like to see this merged. Changes since v1: - rename HDMI_CONTENT_TYPE_NONE to HDMI_CONTENT_TYPE_GRAPHICS to conform to CEA-861-F. - added missing HDMI_AUDIO_CODING_TYPE_CXT. - Be explicit: out of range values are called Invalid, reserved values are called Reserved. - Incorporated most of Thierry's suggestions. Exception: I didn't create ..._get_name(buffer, length, ...) functions. I think it makes the API awkward and I am not convinced that it is that useful. I also kept No Data since that's what CEA-861-F calls it. I also think that No Data is a better description than None since it really means that nobody bothered to fill this in. Please let me know if there are more things that need to be addressed in these patches before they can be merged. Any comments about this v2? Sorry for taking so long. This got burried under a lot of other stuff. I have some minor comments to patch 2/3, but on the whole this looks very nice. If not, is this something you or someone else from dri-devel will take, or can it be merged through the media git repository? I'm not aware of anyone currently doing work on this for DRM, so I think it'd be fine if you took it through the media git tree, especially since patch 3/3 clearly belongs there. If we ever need to resolve dependencies between this and new work in DRM we could set up a stable branch containing patches 1/3 and 2/3 which can be merged into both trees. Thierry pgpm9NwSlP37s.pgp Description: PGP signature
Re: [PATCH v2 07/13] mfd: sun6i-prcm: Add support for the ir-clk
On Wed, 17 Dec 2014, Hans de Goede wrote:
Add support for the ir-clk which is part of the sun6i SoC prcm module.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/mfd/sun6i-prcm.c | 14 ++
1 file changed, 14 insertions(+)
Pretty standard stuff (
diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
index 2f2e9f0..1911731 100644
--- a/drivers/mfd/sun6i-prcm.c
+++ b/drivers/mfd/sun6i-prcm.c
@@ -41,6 +41,14 @@ static const struct resource
sun6i_a31_apb0_gates_clk_res[] = {
},
};
+static const struct resource sun6i_a31_ir_clk_res[] = {
+ {
+ .start = 0x54,
+ .end = 0x57,
+ .flags = IORESOURCE_MEM,
+ },
+};
I'm still unkeen on this registers not being defined -- but whateveer!
static const struct resource sun6i_a31_apb0_rstc_res[] = {
{
.start = 0xb0,
@@ -69,6 +77,12 @@ static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
.resources = sun6i_a31_apb0_gates_clk_res,
},
{
+ .name = sun6i-a31-ir-clk,
+ .of_compatible = allwinner,sun4i-a10-mod0-clk,
+ .num_resources = ARRAY_SIZE(sun6i_a31_ir_clk_res),
+ .resources = sun6i_a31_ir_clk_res,
+ },
+ {
.name = sun6i-a31-apb0-clock-reset,
.of_compatible = allwinner,sun6i-a31-clock-reset,
.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
This is all pretty standard stuff:
For my own reference:
Acked-by: Lee Jones lee.jo...@linaro.org
Do you do you expect this patch to be handled?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [linux-sunxi] [PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller
Hi, On 18-12-14 03:48, Chen-Yu Tsai wrote: Hi, On Thu, Dec 18, 2014 at 1:18 AM, Hans de Goede hdego...@redhat.com wrote: On sun6i the cir block is attached to the reset controller, add support for de-asserting the reset if a reset controller is specified in dt. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Maxime Ripard maxime.rip...@free-electrons.com --- .../devicetree/bindings/media/sunxi-ir.txt | 2 ++ drivers/media/rc/sunxi-cir.c | 25 -- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt index 23dd5ad..6b70b9b 100644 --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt @@ -10,6 +10,7 @@ Required properties: Optional properties: - linux,rc-map-name : Remote control map name. +- resets : phandle + reset specifier pair Should it be optional? Or should we use a sun6i compatible with a mandatory reset phandle? I mean, the driver/hardware is not going to work with the reset missing on sun6i. Seems we are doing it one way for some of our drivers, and the other (optional) way for more generic ones, like USB. I do not believe that we should add a new compatible just because the reset line of a block is hooked up differently. It is the exact same ip-block. Only now the reset is not controlled through the apb-gate, but controlled separately. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] ARM: at91: dts: sama5d3: add dt support for atmel isi and ov2640 sensor
This patch series add ISI and ov2640 support on dts files.
As the ov2640 driver dt is still in review. The patch is in:
https://patchwork.linuxtv.org/patch/27554/
So I want to send this dt patch early for a review.
Bo Shen (3):
ARM: at91: dts: sama5d3: split isi pinctrl
ARM: at91: dts: sama5d3: add missing pins of isi
ARM: at91: dts: sama5d3: move the isi mck pin to mb
Josh Wu (4):
ARM: at91: dts: sama5d3: add isi clock
ARM: at91: dts: sama5d3: change name of pinctrl_isi_{power,reset}
ARM: at91: dts: sama5d3: add ov2640 camera sensor support
ARM: at91: sama5: enable atmel-isi and ov2640 in defconfig
arch/arm/boot/dts/sama5d3.dtsi| 20 +-
arch/arm/boot/dts/sama5d3xmb.dtsi | 43 +++
arch/arm/configs/sama5_defconfig | 6 ++
3 files changed, 60 insertions(+), 9 deletions(-)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ARM: at91: dts: sama5d3: split isi pinctrl
From: Bo Shen voice.s...@atmel.com
As the ISI has 12 data lines, however we only use 8 data lines with
sensor module. So, split the data line into two groups which make
it can be choosed depends on the hardware design.
Signed-off-by: Bo Shen voice.s...@atmel.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/boot/dts/sama5d3.dtsi| 11 ---
arch/arm/boot/dts/sama5d3xmb.dtsi | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 61746ef..595609f 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -547,7 +547,7 @@
};
isi {
- pinctrl_isi: isi-0 {
+ pinctrl_isi_data_0_7: isi-0-data-0-7 {
atmel,pins =
AT91_PIOA 16
AT91_PERIPH_C AT91_PINCTRL_NONE /* PA16 periph C ISI_D0, conflicts with
LCDDAT16 */
AT91_PIOA 17
AT91_PERIPH_C AT91_PINCTRL_NONE /* PA17 periph C ISI_D1, conflicts with
LCDDAT17 */
@@ -559,10 +559,15 @@
AT91_PIOA 23
AT91_PERIPH_C AT91_PINCTRL_NONE /* PA23 periph C ISI_D7, conflicts with
LCDDAT23, PWML1 */
AT91_PIOC 30
AT91_PERIPH_C AT91_PINCTRL_NONE /* PC30 periph C ISI_PCK, conflicts with
UTXD0 */
AT91_PIOA 31
AT91_PERIPH_C AT91_PINCTRL_NONE /* PA31 periph C ISI_HSYNC, conflicts with
TWCK0, UTXD1 */
-AT91_PIOA 30
AT91_PERIPH_C AT91_PINCTRL_NONE /* PA30 periph C ISI_VSYNC, conflicts with
TWD0, URXD1 */
-AT91_PIOC 29
AT91_PERIPH_C AT91_PINCTRL_NONE /* PC29 periph C ISI_PD8, conflicts with
URXD0, PWMFI2 */
+AT91_PIOA 30
AT91_PERIPH_C AT91_PINCTRL_NONE; /* PA30 periph C ISI_VSYNC, conflicts with
TWD0, URXD1 */
+ };
+
+ pinctrl_isi_data_8_9: isi-0-data-8-9 {
+ atmel,pins =
+ AT91_PIOC 29
AT91_PERIPH_C AT91_PINCTRL_NONE /* PC29 periph C ISI_PD8, conflicts with
URXD0, PWMFI2 */
AT91_PIOC 28
AT91_PERIPH_C AT91_PINCTRL_NONE; /* PC28 periph C ISI_PD9, conflicts with
SPI1_NPCS3, PWMFI0 */
};
+
pinctrl_isi_pck_as_mck:
isi_pck_as_mck-0 {
atmel,pins =
AT91_PIOD 31
AT91_PERIPH_B AT91_PINCTRL_NONE; /* PD31 periph B ISI_MCK */
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 49c10d3..2530541 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -61,7 +61,7 @@
isi: isi@f0034000 {
pinctrl-names = default;
- pinctrl-0 = pinctrl_isi
pinctrl_isi_pck_as_mck pinctrl_isi_power pinctrl_isi_reset;
+ pinctrl-0 = pinctrl_isi_data_0_7
pinctrl_isi_pck_as_mck pinctrl_isi_power pinctrl_isi_reset;
};
mmc1: mmc@f800 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] ARM: at91: dts: sama5d3: add missing pins of isi
From: Bo Shen voice.s...@atmel.com
The ISI has 12 data lines, add the missing two data lines.
Signed-off-by: Bo Shen voice.s...@atmel.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/sama5d3.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 595609f..b3ac156 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -568,6 +568,12 @@
AT91_PIOC 28
AT91_PERIPH_C AT91_PINCTRL_NONE; /* PC28 periph C ISI_PD9, conflicts with
SPI1_NPCS3, PWMFI0 */
};
+ pinctrl_isi_data_10_11:
isi-0-data-10-11 {
+ atmel,pins =
+ AT91_PIOC 27
AT91_PERIPH_C AT91_PINCTRL_NONE /* PC27 periph C ISI_PD10, conflicts with
SPI1_NPCS2, TWCK1 */
+AT91_PIOC 26
AT91_PERIPH_C AT91_PINCTRL_NONE; /* PC26 periph C ISI_PD11, conflicts with
SPI1_NPCS1, TWD1 */
+ };
+
pinctrl_isi_pck_as_mck:
isi_pck_as_mck-0 {
atmel,pins =
AT91_PIOD 31
AT91_PERIPH_B AT91_PINCTRL_NONE; /* PD31 periph B ISI_MCK */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ARM: at91: dts: sama5d3: add isi clock
Add ISI peripheral clock in sama5d3.dtsi. Signed-off-by: Josh Wu josh...@atmel.com --- arch/arm/boot/dts/sama5d3.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi index 5f4144d..61746ef 100644 --- a/arch/arm/boot/dts/sama5d3.dtsi +++ b/arch/arm/boot/dts/sama5d3.dtsi @@ -214,6 +214,8 @@ compatible = atmel,at91sam9g45-isi; reg = 0xf0034000 0x4000; interrupts = 37 IRQ_TYPE_LEVEL_HIGH 5; + clocks = isi_clk; + clock-names = isi_clk; status = disabled; }; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/13] mfd: sun6i-prcm: Add support for the ir-clk
Hi,
On 18-12-14 09:41, Lee Jones wrote:
On Wed, 17 Dec 2014, Hans de Goede wrote:
Add support for the ir-clk which is part of the sun6i SoC prcm module.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/mfd/sun6i-prcm.c | 14 ++
1 file changed, 14 insertions(+)
Pretty standard stuff (
diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
index 2f2e9f0..1911731 100644
--- a/drivers/mfd/sun6i-prcm.c
+++ b/drivers/mfd/sun6i-prcm.c
@@ -41,6 +41,14 @@ static const struct resource sun6i_a31_apb0_gates_clk_res[]
= {
},
};
+static const struct resource sun6i_a31_ir_clk_res[] = {
+ {
+ .start = 0x54,
+ .end = 0x57,
+ .flags = IORESOURCE_MEM,
+ },
+};
I'm still unkeen on this registers not being defined -- but whateveer!
static const struct resource sun6i_a31_apb0_rstc_res[] = {
{
.start = 0xb0,
@@ -69,6 +77,12 @@ static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
.resources = sun6i_a31_apb0_gates_clk_res,
},
{
+ .name = sun6i-a31-ir-clk,
+ .of_compatible = allwinner,sun4i-a10-mod0-clk,
+ .num_resources = ARRAY_SIZE(sun6i_a31_ir_clk_res),
+ .resources = sun6i_a31_ir_clk_res,
+ },
+ {
.name = sun6i-a31-apb0-clock-reset,
.of_compatible = allwinner,sun6i-a31-clock-reset,
.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
This is all pretty standard stuff:
For my own reference:
Acked-by: Lee Jones lee.jo...@linaro.org
Do you do you expect this patch to be handled?
I've no preference for how this goes upstream. There are no compile time deps
and runtime the ir will not work (but not explode) until all the bits are
in place.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] ARM: at91: dts: sama5d3: change name of pinctrl_isi_{power,reset}
For sama5d3xmb board, the pins: pinctrl_isi_{power,reset} is used to
power-down or reset camera sensor.
So we should let camera sensor instead of ISI to configure the pins.
This patch will change pinctrl name from pinctrl_isi_{power,reset} to
pinctrl_sensor_{power,reset}.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/boot/dts/sama5d3.dtsi| 2 ++
arch/arm/boot/dts/sama5d3xmb.dtsi | 6 ++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index ed734e9..ff0fa3a 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -214,6 +214,8 @@
compatible = atmel,at91sam9g45-isi;
reg = 0xf0034000 0x4000;
interrupts = 37 IRQ_TYPE_LEVEL_HIGH 5;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi_data_0_7;
clocks = isi_clk;
clock-names = isi_clk;
status = disabled;
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 6af1cba..0aaebc6 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -60,8 +60,6 @@
};
isi: isi@f0034000 {
- pinctrl-names = default;
- pinctrl-0 = pinctrl_isi_data_0_7
pinctrl_isi_pck_as_mck pinctrl_isi_power pinctrl_isi_reset;
};
mmc1: mmc@f800 {
@@ -122,12 +120,12 @@
AT91_PIOD 31
AT91_PERIPH_B AT91_PINCTRL_NONE; /* PD31 periph B ISI_MCK */
};
- pinctrl_isi_reset: isi_reset-0 {
+ pinctrl_sensor_reset: sensor_reset-0 {
atmel,pins =
AT91_PIOE 24
AT91_PERIPH_GPIO AT91_PINCTRL_NONE; /* PE24 gpio */
};
- pinctrl_isi_power: isi_power-0 {
+ pinctrl_sensor_power: sensor_power-0 {
atmel,pins =
AT91_PIOE 29
AT91_PERIPH_GPIO AT91_PINCTRL_NONE; /* PE29 gpio */
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] ARM: at91: dts: sama5d3: move the isi mck pin to mb
From: Bo Shen voice.s...@atmel.com
The mck is decided by the board design, move it to mb related
dtsi file.
Signed-off-by: Bo Shen voice.s...@atmel.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/boot/dts/sama5d3.dtsi| 5 -
arch/arm/boot/dts/sama5d3xmb.dtsi | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index b3ac156..ed734e9 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -573,11 +573,6 @@
AT91_PIOC 27
AT91_PERIPH_C AT91_PINCTRL_NONE /* PC27 periph C ISI_PD10, conflicts with
SPI1_NPCS2, TWCK1 */
AT91_PIOC 26
AT91_PERIPH_C AT91_PINCTRL_NONE; /* PC26 periph C ISI_PD11, conflicts with
SPI1_NPCS1, TWD1 */
};
-
- pinctrl_isi_pck_as_mck:
isi_pck_as_mck-0 {
- atmel,pins =
- AT91_PIOD 31
AT91_PERIPH_B AT91_PINCTRL_NONE; /* PD31 periph B ISI_MCK */
- };
};
mmc0 {
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 2530541..6af1cba 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -117,6 +117,11 @@
AT91_PIOD 30
AT91_PERIPH_B AT91_PINCTRL_NONE; /* PD30 periph B */
};
+ pinctrl_isi_pck_as_mck:
isi_pck_as_mck-0 {
+ atmel,pins =
+ AT91_PIOD 31
AT91_PERIPH_B AT91_PINCTRL_NONE; /* PD31 periph B ISI_MCK */
+ };
+
pinctrl_isi_reset: isi_reset-0 {
atmel,pins =
AT91_PIOE 24
AT91_PERIPH_GPIO AT91_PINCTRL_NONE; /* PE24 gpio */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] ARM: at91: dts: sama5d3: add ov2640 camera sensor support
According to v4l2 dt document, we add:
a camera host: ISI port.
a i2c camera sensor: ov2640 port.
to sama5d3xmb.dtsi.
In the ov2640 node, it defines the pinctrls, clocks and isi port.
In the ISI node, it also reference to a ov2640 port.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/boot/dts/sama5d3xmb.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 0aaebc6..958a528 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -52,6 +52,29 @@
};
};
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = ovti,ov2640;
+ reg = 0x30;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi_pck_as_mck
pinctrl_sensor_power pinctrl_sensor_reset;
+ resetb-gpios = pioE 24
GPIO_ACTIVE_LOW;
+ pwdn-gpios = pioE 29
GPIO_ACTIVE_HIGH;
+ /* use pck1 for the master clock of
ov2640 */
+ clocks = pck1;
+ clock-names = xvclk;
+ assigned-clocks = pck1;
+ assigned-clock-rates = 2500;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint =
isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
+
usart1: serial@f002 {
dmas = 0, 0;/* Do not use DMA for
usart1 */
pinctrl-names = default;
@@ -60,6 +83,15 @@
};
isi: isi@f0034000 {
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ isi_0: endpoint {
+ remote-endpoint = ov2640_0;
+ bus-width = 8;
+ };
+ };
};
mmc1: mmc@f800 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] ARM: at91: sama5: enable atmel-isi and ov2640 in defconfig
Signed-off-by: Josh Wu josh...@atmel.com --- arch/arm/configs/sama5_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig index b58fb32..92f1d71 100644 --- a/arch/arm/configs/sama5_defconfig +++ b/arch/arm/configs/sama5_defconfig @@ -139,6 +139,12 @@ CONFIG_POWER_RESET=y CONFIG_SSB=m CONFIG_REGULATOR=y CONFIG_REGULATOR_ACT8865=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_V4L_PLATFORM_DRIVERS=y +CONFIG_SOC_CAMERA=y +CONFIG_SOC_CAMERA_OV2640=y +CONFIG_VIDEO_ATMEL_ISI=y CONFIG_FB=y CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/13] mfd: sun6i-prcm: Add support for the ir-clk
On Thu, 18 Dec 2014, Hans de Goede wrote:
Hi,
On 18-12-14 09:41, Lee Jones wrote:
On Wed, 17 Dec 2014, Hans de Goede wrote:
Add support for the ir-clk which is part of the sun6i SoC prcm module.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/mfd/sun6i-prcm.c | 14 ++
1 file changed, 14 insertions(+)
Pretty standard stuff (
diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
index 2f2e9f0..1911731 100644
--- a/drivers/mfd/sun6i-prcm.c
+++ b/drivers/mfd/sun6i-prcm.c
@@ -41,6 +41,14 @@ static const struct resource
sun6i_a31_apb0_gates_clk_res[] = {
},
};
+static const struct resource sun6i_a31_ir_clk_res[] = {
+ {
+ .start = 0x54,
+ .end = 0x57,
+ .flags = IORESOURCE_MEM,
+ },
+};
I'm still unkeen on this registers not being defined -- but whateveer!
static const struct resource sun6i_a31_apb0_rstc_res[] = {
{
.start = 0xb0,
@@ -69,6 +77,12 @@ static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
.resources = sun6i_a31_apb0_gates_clk_res,
},
{
+ .name = sun6i-a31-ir-clk,
+ .of_compatible = allwinner,sun4i-a10-mod0-clk,
+ .num_resources = ARRAY_SIZE(sun6i_a31_ir_clk_res),
+ .resources = sun6i_a31_ir_clk_res,
+ },
+ {
.name = sun6i-a31-apb0-clock-reset,
.of_compatible = allwinner,sun6i-a31-clock-reset,
.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
This is all pretty standard stuff:
For my own reference:
Acked-by: Lee Jones lee.jo...@linaro.org
Do you do you expect this patch to be handled?
I've no preference for how this goes upstream. There are no compile time deps
and runtime the ir will not work (but not explode) until all the bits are
in place.
Great, this is my kind of patch. Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [PATCHv2 0/3] hdmi: add unpack and logging functions
On 12/18/14 09:24, Thierry Reding wrote: On Thu, Dec 11, 2014 at 09:57:54AM +0100, Hans Verkuil wrote: Hi Thierry, On 12/02/14 13:08, Hans Verkuil wrote: This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and adds unpacking and logging functions to hdmi.c. It also uses those in the V4L2 adv7842 driver (and they will be used in other HDMI drivers once this functionality is merged). Patches 2 and 3 have been posted before by Martin Bugge. It stalled, but I am taking over from Martin to try and get this is. I want to use this in a bunch of v4l2 drivers, so I would really like to see this merged. Changes since v1: - rename HDMI_CONTENT_TYPE_NONE to HDMI_CONTENT_TYPE_GRAPHICS to conform to CEA-861-F. - added missing HDMI_AUDIO_CODING_TYPE_CXT. - Be explicit: out of range values are called Invalid, reserved values are called Reserved. - Incorporated most of Thierry's suggestions. Exception: I didn't create ..._get_name(buffer, length, ...) functions. I think it makes the API awkward and I am not convinced that it is that useful. I also kept No Data since that's what CEA-861-F calls it. I also think that No Data is a better description than None since it really means that nobody bothered to fill this in. Please let me know if there are more things that need to be addressed in these patches before they can be merged. Any comments about this v2? Sorry for taking so long. This got burried under a lot of other stuff. No problem! Much appreciated that you took the time for this review. I have some minor comments to patch 2/3, but on the whole this looks very nice. I'll make a v3 (probably tomorrow) fixing most of your comments although I'm keeping hdmi_log. Using dev_printk just made the code a lot harder to read IMHO. I plan to address all other comments. If not, is this something you or someone else from dri-devel will take, or can it be merged through the media git repository? I'm not aware of anyone currently doing work on this for DRM, so I think it'd be fine if you took it through the media git tree, especially since patch 3/3 clearly belongs there. OK, great. I'd appreciate it if you can Ack the v3 patch series when it's posted. If we ever need to resolve dependencies between this and new work in DRM we could set up a stable branch containing patches 1/3 and 2/3 which can be merged into both trees. 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: [PATCH] media: rc: Replace timeval with ktime_t in imon.c
On Thu, Dec 18, 2014 at 3:50 PM, Arnd Bergmann a...@linaro.org wrote:
On Thursday 18 December 2014 11:37:13 Chunyan Zhang wrote:
This patch changes the 32-bit time type (timeval) to the 64-bit one
(ktime_t), since 32-bit time types will break in the year 2038.
I use ktime_t instead of all uses of timeval in imon.c
This patch also changes do_gettimeofday() to ktime_get() accordingly,
since ktime_get returns a ktime_t, but do_gettimeofday returns a
struct timeval, and the other reason is that ktime_get() uses
the monotonic clock.
This patch use a new function which is provided by another patch listed below
to get the millisecond time difference.
The patch looks great. Just a few small details that could still be
improved:
http://lkml.iu.edu//hypermail/linux/kernel/1412.2/00625.html
Signed-off-by: Chunyan Zhang zhang.chun...@linaro.org
In general, when you give a mailing list link, use the 'Link' tag
under your Signed-off-by line, like
Link: http://lkml.iu.edu//hypermail/linux/kernel/1412.2/00625.html
It's not used much yet, but getting more popular and seems useful to me.
In this particular case, when you have patches that depend on one
another, you can make do it even better by sending all three patches
as a series with a [PATCH 0/3] cover letter.
OK, I'll send a patch-set including these three patches
If the media maintainers can provide an Ack for this patch, I would
suggest to queue it up in the y2038 branch together with your first
patch that it depends on.
@@ -1191,16 +1168,16 @@ static inline int tv2int(const struct timeval *a,
const struct timeval *b)
*/
static int stabilize(int a, int b, u16 timeout, u16 threshold)
{
- struct timeval ct;
- static struct timeval prev_time = {0, 0};
- static struct timeval hit_time = {0, 0};
+ ktime_t ct;
+ static ktime_t prev_time = {0};
+ static ktime_t hit_time = {0};
static int x, y, prev_result, hits;
int result = 0;
The = {0} part here is redundant, since static variables are always
initialized to zero. Normally, adding the explicit initializer can
help readability, but in this case I would leave it out because it shows
implementation details of ktime_t that are better hidden from drivers.
OK, I'll modify them soon
Thanks,
Chunyan
@@ -1596,9 +1573,9 @@ static void imon_incoming_packet(struct imon_context
*ictx,
int i;
u64 scancode;
int press_type = 0;
- int msec;
- struct timeval t;
- static struct timeval prev_time = { 0, 0 };
+ long msec;
+ ktime_t t;
+ static ktime_t prev_time = {0};
u8 ktype;
Same thing here of course.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC HACK] rtl2832: implement own lock for RegMap
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2001
09/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49 +++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index f44dc50..2ee5bcf 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1028,6 +1028,31 @@ static int rtl2832_regmap_gather_write(void *context,
const void *reg,
return 0;
}
+/*
+ * FIXME: Implement own RegMap locking in order to silence lockdep recursive
+ * lock warning. That happens when RegMap I2C client calls I2C mux adapter,
+ * which leads demod I2C repeater enable via demod RegMap. Operation takes two
+ * RegMap locks recursively - but those are different RegMap instances in a two
+ * different I2C drivers, so it should be deadlock.
+ */
+static void rtl2832_regmap_lock(void *__dev)
+{
+ struct rtl2832_dev *dev = __dev;
+ struct i2c_client *client = dev-client;
+
+ dev_dbg(client-dev, \n);
+ mutex_lock(dev-regmap_mutex);
+}
+
+static void rtl2832_regmap_unlock(void *__dev)
+{
+ struct rtl2832_dev *dev = __dev;
+ struct i2c_client *client = dev-client;
+
+ dev_dbg(client-dev, \n);
+ mutex_unlock(dev-regmap_mutex);
+}
+
static struct dvb_frontend *rtl2832_get_dvb_frontend(struct i2c_client *client)
{
struct rtl2832_dev *dev =
Re: [PATCH] media: rc: Replace timeval with ktime_t in imon.c
Em Thu, 18 Dec 2014 17:38:14 +0800
Chunyan Zhang zhang.chun...@linaro.org escreveu:
On Thu, Dec 18, 2014 at 3:50 PM, Arnd Bergmann a...@linaro.org wrote:
On Thursday 18 December 2014 11:37:13 Chunyan Zhang wrote:
This patch changes the 32-bit time type (timeval) to the 64-bit one
(ktime_t), since 32-bit time types will break in the year 2038.
I use ktime_t instead of all uses of timeval in imon.c
This patch also changes do_gettimeofday() to ktime_get() accordingly,
since ktime_get returns a ktime_t, but do_gettimeofday returns a
struct timeval, and the other reason is that ktime_get() uses
the monotonic clock.
This patch use a new function which is provided by another patch listed
below
to get the millisecond time difference.
The patch looks great. Just a few small details that could still be
improved:
Yes, patch looks OK. After addressing the bits pointed by Arnd:
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Feel free to merge via y2038 tree.
http://lkml.iu.edu//hypermail/linux/kernel/1412.2/00625.html
Signed-off-by: Chunyan Zhang zhang.chun...@linaro.org
In general, when you give a mailing list link, use the 'Link' tag
under your Signed-off-by line, like
Link: http://lkml.iu.edu//hypermail/linux/kernel/1412.2/00625.html
It's not used much yet, but getting more popular and seems useful to me.
In this particular case, when you have patches that depend on one
another, you can make do it even better by sending all three patches
as a series with a [PATCH 0/3] cover letter.
OK, I'll send a patch-set including these three patches
If the media maintainers can provide an Ack for this patch, I would
suggest to queue it up in the y2038 branch together with your first
patch that it depends on.
@@ -1191,16 +1168,16 @@ static inline int tv2int(const struct timeval *a,
const struct timeval *b)
*/
static int stabilize(int a, int b, u16 timeout, u16 threshold)
{
- struct timeval ct;
- static struct timeval prev_time = {0, 0};
- static struct timeval hit_time = {0, 0};
+ ktime_t ct;
+ static ktime_t prev_time = {0};
+ static ktime_t hit_time = {0};
static int x, y, prev_result, hits;
int result = 0;
The = {0} part here is redundant, since static variables are always
initialized to zero. Normally, adding the explicit initializer can
help readability, but in this case I would leave it out because it shows
implementation details of ktime_t that are better hidden from drivers.
OK, I'll modify them soon
Thanks,
Chunyan
@@ -1596,9 +1573,9 @@ static void imon_incoming_packet(struct imon_context
*ictx,
int i;
u64 scancode;
int press_type = 0;
- int msec;
- struct timeval t;
- static struct timeval prev_time = { 0, 0 };
+ long msec;
+ ktime_t t;
+ static ktime_t prev_time = {0};
u8 ktype;
Same thing here of course.
Arnd
--
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 HACK] rtl2832: implement own lock for RegMap
Em Thu, 18 Dec 2014 12:29:46 +0200
Antti Palosaari cr...@iki.fi escreveu:
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
Please do not add a hack just to silence a lockdep warning.
Please take a look at: Documentation/locking/lockdep-design.txt
There are some documentation there about the usage of nested locks and
how to avoid lockdep to complain.
Regards,
Mauro
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS
200109/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49
+++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index f44dc50..2ee5bcf 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1028,6 +1028,31 @@ static int rtl2832_regmap_gather_write(void *context,
const void *reg,
return 0;
}
+/*
+ * FIXME: Implement own RegMap locking in order to silence lockdep recursive
+ * lock warning. That happens when RegMap I2C client calls I2C mux adapter,
+ * which leads demod I2C repeater enable via demod RegMap. Operation takes
two
+ * RegMap locks recursively - but those are different RegMap instances in a
two
+ * different I2C drivers, so it should be deadlock.
+ */
+static void rtl2832_regmap_lock(void *__dev)
+{
+ struct rtl2832_dev *dev = __dev;
+ struct i2c_client *client = dev-client;
+
+
Re: [PATCH] media: rc: Replace timeval with ktime_t in imon.c
On Thu, Dec 18, 2014 at 7:00 PM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Em Thu, 18 Dec 2014 17:38:14 +0800 Chunyan Zhang zhang.chun...@linaro.org escreveu: On Thu, Dec 18, 2014 at 3:50 PM, Arnd Bergmann a...@linaro.org wrote: On Thursday 18 December 2014 11:37:13 Chunyan Zhang wrote: This patch changes the 32-bit time type (timeval) to the 64-bit one (ktime_t), since 32-bit time types will break in the year 2038. I use ktime_t instead of all uses of timeval in imon.c This patch also changes do_gettimeofday() to ktime_get() accordingly, since ktime_get returns a ktime_t, but do_gettimeofday returns a struct timeval, and the other reason is that ktime_get() uses the monotonic clock. This patch use a new function which is provided by another patch listed below to get the millisecond time difference. The patch looks great. Just a few small details that could still be improved: Yes, patch looks OK. After addressing the bits pointed by Arnd: Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Feel free to merge via y2038 tree. Ok, thank you, I'll send the updated patch-set soon. Chunyan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Changes the time type 'timeval' to 'Ktime'
This patch-set changes the 32-bit time type (timeval) to the 64-bit one (ktime_t) in imon.c, speedtest.c and torturetest.c, since 32-bit time types will break in the year 2038. This patch-set also introduces a reusable time difference function which returns the difference in millisecond in ktime.h. The last two patches of this patch-set will use this function, so they are dependent on the first one. Chunyan Zhang (3): ktime.h: Introduce ktime_ms_delta mtd: test: Replace timeval with ktime_t in speedtest.c and torturetest.c media: rc: Replace timeval with ktime_t in imon.c drivers/media/rc/imon.c | 49 +++ drivers/mtd/tests/speedtest.c | 10 drivers/mtd/tests/torturetest.c | 10 include/linux/ktime.h |5 4 files changed, 28 insertions(+), 46 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] media: rc: Replace timeval with ktime_t in imon.c
This patch changes the 32-bit time type (timeval) to the 64-bit one
(ktime_t), since 32-bit time types will break in the year 2038.
I use ktime_t instead of all uses of timeval in imon.c
This patch also changes do_gettimeofday() to ktime_get() accordingly,
since ktime_get returns a ktime_t, but do_gettimeofday returns a
struct timeval, and the other reason is that ktime_get() uses
the monotonic clock.
This patch will use a new function 'ktime_ms_delta' which is introduced
in 1/3 of this patch-set to get the millisecond time difference.
Signed-off-by: Chunyan Zhang zhang.chun...@linaro.org
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
---
drivers/media/rc/imon.c | 49 +--
1 file changed, 13 insertions(+), 36 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index b8837dd..a1e91d5 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -31,6 +31,7 @@
#include linux/errno.h
#include linux/init.h
#include linux/kernel.h
+#include linux/ktime.h
#include linux/module.h
#include linux/slab.h
#include linux/uaccess.h
@@ -41,7 +42,6 @@
#include linux/usb/input.h
#include media/rc-core.h
-#include linux/time.h
#include linux/timer.h
#define MOD_AUTHOR Jarod Wilson ja...@wilsonet.com
@@ -1158,29 +1158,6 @@ out:
return retval;
}
-static inline int tv2int(const struct timeval *a, const struct timeval *b)
-{
- int usecs = 0;
- int sec = 0;
-
- if (b-tv_usec a-tv_usec) {
- usecs = 100;
- sec--;
- }
-
- usecs += a-tv_usec - b-tv_usec;
-
- sec += a-tv_sec - b-tv_sec;
- sec *= 1000;
- usecs /= 1000;
- sec += usecs;
-
- if (sec 0)
- sec = 1000;
-
- return sec;
-}
-
/**
* The directional pad behaves a bit differently, depending on whether this is
* one of the older ffdc devices or a newer device. Newer devices appear to
@@ -1191,16 +1168,16 @@ static inline int tv2int(const struct timeval *a, const
struct timeval *b)
*/
static int stabilize(int a, int b, u16 timeout, u16 threshold)
{
- struct timeval ct;
- static struct timeval prev_time = {0, 0};
- static struct timeval hit_time = {0, 0};
+ ktime_t ct;
+ static ktime_t prev_time;
+ static ktime_t hit_time;
static int x, y, prev_result, hits;
int result = 0;
- int msec, msec_hit;
+ long msec, msec_hit;
- do_gettimeofday(ct);
- msec = tv2int(ct, prev_time);
- msec_hit = tv2int(ct, hit_time);
+ ct = ktime_get();
+ msec = ktime_ms_delta(ct, prev_time);
+ msec_hit = ktime_ms_delta(ct, hit_time);
if (msec 100) {
x = 0;
@@ -1596,9 +1573,9 @@ static void imon_incoming_packet(struct imon_context
*ictx,
int i;
u64 scancode;
int press_type = 0;
- int msec;
- struct timeval t;
- static struct timeval prev_time = { 0, 0 };
+ long msec;
+ ktime_t t;
+ static ktime_t prev_time;
u8 ktype;
/* filter out junk data on the older 0xffdc imon devices */
@@ -1692,10 +1669,10 @@ static void imon_incoming_packet(struct imon_context
*ictx,
/* Only panel type events left to process now */
spin_lock_irqsave(ictx-kc_lock, flags);
- do_gettimeofday(t);
+ t = ktime_get();
/* KEY_MUTE repeats from knob need to be suppressed */
if (ictx-kc == KEY_MUTE ictx-kc == ictx-last_keycode) {
- msec = tv2int(t, prev_time);
+ msec = ktime_ms_delta(t, prev_time);
if (msec ictx-idev-rep[REP_DELAY]) {
spin_unlock_irqrestore(ictx-kc_lock, flags);
return;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ktime.h: Introduce ktime_ms_delta
This patch introduces a reusable time difference function which returns
the difference in millisecond, as often used in some driver code, e.g.
mtd/test, media/rc, etc.
Signed-off-by: Chunyan Zhang zhang.chun...@linaro.org
Acked-by: Arnd Bergmann a...@linaro.org
---
include/linux/ktime.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index c9d645a..891ea92 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -186,6 +186,11 @@ static inline s64 ktime_us_delta(const ktime_t later,
const ktime_t earlier)
return ktime_to_us(ktime_sub(later, earlier));
}
+static inline s64 ktime_ms_delta(const ktime_t later, const ktime_t earlier)
+{
+ return ktime_to_ms(ktime_sub(later, earlier));
+}
+
static inline ktime_t ktime_add_us(const ktime_t kt, const u64 usec)
{
return ktime_add_ns(kt, usec * NSEC_PER_USEC);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] mtd: test: Replace timeval with ktime_t in speedtest.c and torturetest.c
This patch changes the 32-bit time type (timeval) to the 64-bit one
(ktime_t), since 32-bit time types will break in the year 2038.
I use ktime_t instead of timeval to define 'start' and 'finish'
which are used to get the time for tow points.
This patch also changes do_gettimeofday() to ktime_get() accordingly,
since ktime_get returns a ktime_t, but do_gettimeofday returns a
struct timeval, and the other reason is that ktime_get() uses
the monotonic clock.
This patch will use a new function 'ktime_ms_delta' which is introduced
in 1/3 of this patch-set to get the millisecond time difference.
Signed-off-by: Chunyan Zhang zhang.chun...@linaro.org
Reviewed-by: Arnd Bergmann a...@arndb.de
---
drivers/mtd/tests/speedtest.c | 10 +-
drivers/mtd/tests/torturetest.c | 10 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/tests/speedtest.c b/drivers/mtd/tests/speedtest.c
index 5ee9f70..87a6e25 100644
--- a/drivers/mtd/tests/speedtest.c
+++ b/drivers/mtd/tests/speedtest.c
@@ -22,6 +22,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
#include linux/init.h
+#include linux/ktime.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/err.h
@@ -49,7 +50,7 @@ static int pgsize;
static int ebcnt;
static int pgcnt;
static int goodebcnt;
-static struct timeval start, finish;
+static ktime_t start, finish;
static int multiblock_erase(int ebnum, int blocks)
{
@@ -168,12 +169,12 @@ static int read_eraseblock_by_2pages(int ebnum)
static inline void start_timing(void)
{
- do_gettimeofday(start);
+ start = ktime_get();
}
static inline void stop_timing(void)
{
- do_gettimeofday(finish);
+ finish = ktime_get();
}
static long calc_speed(void)
@@ -181,8 +182,7 @@ static long calc_speed(void)
uint64_t k;
long ms;
- ms = (finish.tv_sec - start.tv_sec) * 1000 +
-(finish.tv_usec - start.tv_usec) / 1000;
+ ms = ktime_ms_delta(finish, start);
if (ms == 0)
return 0;
k = goodebcnt * (mtd-erasesize / 1024) * 1000;
diff --git a/drivers/mtd/tests/torturetest.c b/drivers/mtd/tests/torturetest.c
index eeab969..7e77ed4 100644
--- a/drivers/mtd/tests/torturetest.c
+++ b/drivers/mtd/tests/torturetest.c
@@ -26,6 +26,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
#include linux/init.h
+#include linux/ktime.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/err.h
@@ -79,18 +80,18 @@ static unsigned char *check_buf;
static unsigned int erase_cycles;
static int pgsize;
-static struct timeval start, finish;
+static ktime_t start, finish;
static void report_corrupt(unsigned char *read, unsigned char *written);
static inline void start_timing(void)
{
- do_gettimeofday(start);
+ start = ktime_get();
}
static inline void stop_timing(void)
{
- do_gettimeofday(finish);
+ finish = ktime_get();
}
/*
@@ -322,8 +323,7 @@ static int __init tort_init(void)
long ms;
stop_timing();
- ms = (finish.tv_sec - start.tv_sec) * 1000 +
-(finish.tv_usec - start.tv_usec) / 1000;
+ ms = ktime_ms_delta(finish, start);
pr_info(%08u erase cycles done, took %lu
milliseconds (%lu seconds)\n,
erase_cycles, ms, ms / 1000);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] media: ov2640: dt: add the device tree binding document
Hi Josh,
Thank you for the patch.
On Thursday 18 December 2014 10:27:26 Josh Wu wrote:
Add the document for ov2640 dt.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
v3 - v4:
1. remove aggsigned-clocks as it's general.
2. refine the explation.
v2 - v3:
1. fix incorrect description.
2. Add assigned-clocks assigned-clock-rates.
3. resetb pin should be ACTIVE_LOW.
v1 - v2:
1. change the compatible string to be consistent with verdor file.
2. change the clock and pins' name.
3. add missed pinctrl in example.
.../devicetree/bindings/media/i2c/ov2640.txt | 46 +++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
b/Documentation/devicetree/bindings/media/i2c/ov2640.txt new file mode
100644
index 000..de11ebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
@@ -0,0 +1,46 @@
+* Omnivision ov2640 CMOS sensor
+
+The Omnivision OV2640 sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties:
+- compatible: Must be ovti,ov2640
+- clocks: reference to the xvclk input clock.
+- clock-names: Must be xvclk.
+
+Optional Properties:
+- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
+- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = ovti,ov2640;
+ reg = 0x30;
+
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_pck1 pinctrl_ov2640_pwdn
pinctrl_ov2640_resetb;
+
+ resetb-gpios = pioE 24 GPIO_ACTIVE_LOW;
+ pwdn-gpios = pioE 29 GPIO_ACTIVE_HIGH;
+
+ clocks = pck1;
+ clock-names = xvclk;
+
+ assigned-clocks = pck1;
+ assigned-clock-rates = 2500;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] media: ov2640: dt: add the device tree binding document
Hi Josh, On 18/12/14 03:27, Josh Wu wrote: Add the document for ov2640 dt. Cc: devicet...@vger.kernel.org Signed-off-by: Josh Wu josh...@atmel.com Acked-by: Sylwester Nawrocki s.nawro...@samsung.com It seems ovti is not in the list of vendor prefixes. You may want to send a patch adding it to Documentation/devicetree/bindings/ vendor-prefixes.txt. Just few minor comments below.. .../devicetree/bindings/media/i2c/ov2640.txt | 46 ++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt b/Documentation/devicetree/bindings/media/i2c/ov2640.txt new file mode 100644 index 000..de11ebb --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt @@ -0,0 +1,46 @@ +* Omnivision ov2640 CMOS sensor s/ov2640/OV2640 ? + +The Omnivision OV2640 sensor support multiple resolutions output, such as +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB +output format. + +Required Properties: +- compatible: Must be ovti,ov2640 I believe it is preferred to put it as Should contain, rather than Must be. +- clocks: reference to the xvclk input clock. +- clock-names: Must be xvclk. -- Regards, 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: [PATCH v4 5/5] media: ov2640: dt: add the device tree binding document
Hi Sylwester, On Thu, Dec 18, 2014 at 10:13 AM, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Josh, On 18/12/14 03:27, Josh Wu wrote: Add the document for ov2640 dt. Cc: devicet...@vger.kernel.org Signed-off-by: Josh Wu josh...@atmel.com Acked-by: Sylwester Nawrocki s.nawro...@samsung.com It seems ovti is not in the list of vendor prefixes. You may want to send a patch adding it to Documentation/devicetree/bindings/ vendor-prefixes.txt. I have already sent it: http://patchwork.ozlabs.org/patch/416685/ -- 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 6/7] ARM: at91: dts: sama5d3: add ov2640 camera sensor support
Hi Josh,
Thank you for the patch.
On Thursday 18 December 2014 16:51:06 Josh Wu wrote:
According to v4l2 dt document, we add:
a camera host: ISI port.
a i2c camera sensor: ov2640 port.
to sama5d3xmb.dtsi.
In the ov2640 node, it defines the pinctrls, clocks and isi port.
In the ISI node, it also reference to a ov2640 port.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/boot/dts/sama5d3xmb.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi index 0aaebc6..958a528 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -52,6 +52,29 @@
};
};
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = ovti,ov2640;
+ reg = 0x30;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi_pck_as_mck
pinctrl_sensor_power pinctrl_sensor_reset;
+ resetb-gpios = pioE 24
GPIO_ACTIVE_LOW;
+ pwdn-gpios = pioE 29
GPIO_ACTIVE_HIGH;
+ /* use pck1 for the master clock of
ov2640 */
+ clocks = pck1;
+ clock-names = xvclk;
+ assigned-clocks = pck1;
+ assigned-clock-rates = 2500;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint =
isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
+
usart1: serial@f002 {
dmas = 0, 0;/* Do not use DMA for
usart1 */
pinctrl-names = default;
@@ -60,6 +83,15 @@
};
isi: isi@f0034000 {
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
I would add the port node and those two properties to
arch/arm/boot/dts/sama5d3.dtsi, as the isi has a single port. The endpoint, of
course, should stay in this file.
+ isi_0: endpoint {
+ remote-endpoint = ov2640_0;
+ bus-width = 8;
+ };
+ };
};
mmc1: mmc@f800 {
--
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
[GIT PULL for v3.19-rc1] media updates
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
tags/media/v3.19-2
For a second set of changes for 3.19, including:
- moves drivers for really old legacy hardware to staging. Those are
using obsolete media kAPIs and are for hardware that nobody uses for years.
Simply not worth porting them to the new kAPIs. Of course, if anyone pops up
to fix, we can move them back from there;
- While not too late, do some API fixups at the new colorspace API, added
for v3.19;
- Some improvements for rcar_vin driver;
- Some fixups at cx88 and vivid drivers;
- Some Documentation fixups;
Thanks!
Mauro
The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1:
[media] mn88473: One function call less in mn88473_init() after error
(2014-12-04 16:00:47 -0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
tags/media/v3.19-2
for you to fetch changes up to 427ae153c65ad7a08288d86baf99000569627d03:
[media] bq/c-qcam, w9966, pms: move to staging in preparation for removal
(2014-12-16 23:21:44 -0200)
media updates for v3.19-rc1
Hans Verkuil (12):
[media] v4l2-mediabus.h: use two __u16 instead of two __u32
[media] DocBook media: add missing ycbcr_enc and quantization fields
[media] vivid.txt: document new controls
[media] DocBook media: update version number and document changes
[media] vivid: fix CROP_BOUNDS typo for video output
[media] v4l2-ioctl: WARN_ON if querycap didn't fill device_caps
[media] cx88: add missing alloc_ctx support
[media] cx88: remove leftover start_video_dma() call
[media] MAINTAINERS: vivi - vivid
[media] vino/saa7191: move to staging in preparation for removal
[media] tlg2300: move to staging in preparation for removal
[media] bq/c-qcam, w9966, pms: move to staging in preparation for removal
Koji Matsuoka (4):
[media] rcar_vin: Add YUYV capture format support
[media] rcar_vin: Add scaling support
[media] rcar_vin: Enable VSYNC field toggle mode
[media] rcar_vin: Fix interrupt enable in progressive
Yoshihiro Kaneko (1):
[media] rcar_vin: Add DT support for r8a7793 and r8a7794 SoCs
Documentation/DocBook/media/v4l/compat.xml | 12 +
Documentation/DocBook/media/v4l/pixfmt.xml | 36 +-
Documentation/DocBook/media/v4l/subdev-formats.xml | 18 +-
Documentation/DocBook/media/v4l/v4l2.xml | 11 +-
.../devicetree/bindings/media/rcar_vin.txt | 2 +
Documentation/video4linux/vivid.txt| 15 +
MAINTAINERS| 4 +-
drivers/media/Kconfig | 1 -
drivers/media/Makefile | 2 +-
drivers/media/i2c/Kconfig | 9 -
drivers/media/i2c/Makefile | 1 -
drivers/media/pci/cx88/cx88-blackbird.c| 4 +-
drivers/media/pci/cx88/cx88-dvb.c | 4 +-
drivers/media/pci/cx88/cx88-mpeg.c | 11 +-
drivers/media/pci/cx88/cx88-vbi.c | 9 +-
drivers/media/pci/cx88/cx88-video.c| 18 +-
drivers/media/pci/cx88/cx88.h | 2 +
drivers/media/platform/Kconfig | 8 -
drivers/media/platform/Makefile| 3 -
drivers/media/platform/soc_camera/rcar_vin.c | 466 -
drivers/media/platform/vivid/vivid-vid-out.c | 2 +-
drivers/media/usb/Kconfig | 1 -
drivers/media/usb/Makefile | 1 -
drivers/media/v4l2-core/v4l2-ioctl.c | 6 +
drivers/staging/media/Kconfig | 6 +
drivers/staging/media/Makefile | 3 +
drivers/{ = staging}/media/parport/Kconfig| 24 +-
drivers/{ = staging}/media/parport/Makefile | 0
drivers/{ = staging}/media/parport/bw-qcam.c | 0
drivers/{ = staging}/media/parport/c-qcam.c | 0
drivers/{ = staging}/media/parport/pms.c | 0
drivers/{ = staging}/media/parport/w9966.c| 0
.../{media/usb = staging/media}/tlg2300/Kconfig | 6 +-
.../{media/usb = staging/media}/tlg2300/Makefile | 0
.../{media/usb = staging/media}/tlg2300/pd-alsa.c | 0
.../usb = staging/media}/tlg2300/pd-common.h | 0
.../{media/usb = staging/media}/tlg2300/pd-dvb.c | 0
.../{media/usb = staging/media}/tlg2300/pd-main.c | 0
.../usb = staging/media}/tlg2300/pd-radio.c | 0
.../usb = staging/media}/tlg2300/pd-video.c | 0
.../usb = staging/media}/tlg2300/vendorcmds.h | 0
drivers/staging/media/vino/Kconfig | 24 ++
drivers/staging/media/vino/Makefile| 3 +
.../platform =
[RFC] [Patch] implement video driver for sur40
Hello everyone,
as promised, I've finally implemented the missing raw video feature for
the SUR40 touchscreen. Since this is a bit of a weird hybrid device
(multitouch input as well as video), I'm hoping for comments from both
communities (linux-input and linux-media). I'm also attaching the full
source code for the moment (not yet a proper patch submission) so it's
perhaps easier to get a view of the whole thing.
There's definitely some obvious cleanup still to be done (e.g. endpoint
selection), but I'd like to ask for feedback early so I can get most
issues fixed before really submitting a patch.
Thanks best regards, Florian
--
SENT FROM MY DEC VT50 TERMINAL
/*
* Surface2.0/SUR40/PixelSense input driver
*
* Copyright (c) 2013 by Florian 'floe' Echtler f...@butterbrot.org
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
*
* and from the Apple USB BCM5974 multitouch driver,
* Copyright (c) 2008 Henrik Rydberg (rydb...@euromail.se)
*
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty cha...@enac.fr
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*/
#include linux/kernel.h
#include linux/errno.h
#include linux/delay.h
#include linux/init.h
#include linux/slab.h
#include linux/module.h
#include linux/completion.h
#include linux/uaccess.h
#include linux/usb.h
#include linux/printk.h
#include linux/input-polldev.h
#include linux/input/mt.h
#include linux/usb/input.h
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-dev.h
#include media/v4l2-ioctl.h
#include media/videobuf2-dma-contig.h
/* read 512 bytes from endpoint 0x86 - get header + blobs */
struct sur40_header {
__le16 type; /* always 0x0001 */
__le16 count; /* count of blobs (if 0: continue prev. packet) */
__le32 packet_id; /* unique ID for all packets in one frame */
__le32 timestamp; /* milliseconds (inc. by 16 or 17 each frame) */
__le32 unknown;/* epoch? always 02/03 00 00 00 */
} __packed;
struct sur40_blob {
__le16 blob_id;
u8 action; /* 0x02 = enter/exit, 0x03 = update (?) */
u8 unknown;/* always 0x01 or 0x02 (no idea what this is?) */
__le16 bb_pos_x; /* upper left corner of bounding box */
__le16 bb_pos_y;
__le16 bb_size_x; /* size of bounding box */
__le16 bb_size_y;
__le16 pos_x; /* finger tip position */
__le16 pos_y;
__le16 ctr_x; /* centroid position */
__le16 ctr_y;
__le16 axis_x; /* somehow related to major/minor axis, mostly: */
__le16 axis_y; /* axis_x == bb_size_y axis_y == bb_size_x */
__le32 angle; /* orientation in radians relative to x axis -
actually an IEEE754 float, don't use in kernel */
__le32 area; /* size in pixels/pressure (?) */
u8 padding[32];
} __packed;
/* combined header/blob data */
struct sur40_data {
struct sur40_header header;
struct sur40_blob blobs[];
} __packed;
/* read 512 bytes from endpoint 0x82 - get header below
* continue reading 16k blocks until header.size bytes read */
struct sur40_image_header {
__le32 magic; /* SUBF */
__le32 packet_id;
__le32 size; /* always 0x0007e900 = 960x540 */
__le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
__le32 unknown; /* epoch? always 02/03 00 00 00 */
} __packed;
/* version information */
#define DRIVER_SHORT sur40
#define DRIVER_LONGSamsung SUR40
#define DRIVER_AUTHOR Florian 'floe' Echtler f...@butterbrot.org
#define DRIVER_DESCSurface2.0/SUR40/PixelSense input driver
/* vendor and device IDs */
#define ID_MICROSOFT 0x045e
#define ID_SUR40 0x0775
/* sensor resolution */
#define SENSOR_RES_X 1920
#define SENSOR_RES_Y 1080
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
/* video data endpoint */
#define VIDEO_ENDPOINT 0x82
/* video header fields */
#define VIDEO_HEADER_MAGIC 0x46425553
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
#define POLL_INTERVAL 10
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
/* control commands */
#define SUR40_GET_VERSION 0xb0 /* 12 bytes string*/
#define SUR40_UNKNOWN10xb3 /* 5 bytes */
#define SUR40_UNKNOWN20xc1 /* 24 bytes */
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
/*
* Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
* here by mistake which is very likely to have corrupted the firmware EEPROM
* on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
* Should you ever run into a similar problem, the background story to this
* incident and instructions on how to fix the corrupted EEPROM are available
*
Re: [RFC] [Patch] implement video driver for sur40
On 12/18/14 14:34, Florian Echtler wrote: Hello everyone, as promised, I've finally implemented the missing raw video feature for the SUR40 touchscreen. Since this is a bit of a weird hybrid device (multitouch input as well as video), I'm hoping for comments from both communities (linux-input and linux-media). I'm also attaching the full source code for the moment (not yet a proper patch submission) so it's perhaps easier to get a view of the whole thing. There's definitely some obvious cleanup still to be done (e.g. endpoint selection), but I'd like to ask for feedback early so I can get most issues fixed before really submitting a patch. Thanks best regards, Florian One thing you should do is to run the v4l2-compliance utility. Available here: http://git.linuxtv.org/cgit.cgi/v4l-utils.git/ Compile from the git repo to ensure you have the latest version. Run as 'v4l2-compliance -s' (-s starts streaming tests as well and it assumes you have a valid input signal). The driver shouldn't give any failures. When you post the actual patch, then make sure you also paste in the output of 'v4l2-compliance -s' as I'd like to see what it says. Mail if you have any questions about the v4l2-compliance output. The failure messages expect you to look at the v4l2-compliance source code as well, but even than it is not always clear what is going on. 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 HACK] rtl2832: implement own lock for RegMap
On 12/18/2014 01:21 PM, Mauro Carvalho Chehab wrote:
Em Thu, 18 Dec 2014 12:29:46 +0200
Antti Palosaari cr...@iki.fi escreveu:
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
Please do not add a hack just to silence a lockdep warning.
Please take a look at: Documentation/locking/lockdep-design.txt
There are some documentation there about the usage of nested locks and
how to avoid lockdep to complain.
I cannot see any way how those lockdep things could be used on my driver
as problematic lock itself is located inside RegMap. I think it is
RegMap which needs some special lockdep things in order to allow nested
locking of different instances.
So I think demod I2C adapter is good place for that kind of hack until
better solution is find. Defining own RegMap lock here in I2C repeater
allows all the clients be hack free using default RegMap lock.
regards
Antti
Regards,
Mauro
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f] regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2001
09/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49 +++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index f44dc50..2ee5bcf 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1028,6 +1028,31 @@ static int rtl2832_regmap_gather_write(void *context,
const void *reg,
return 0;
}
+/*
+ * FIXME: Implement own RegMap
Re: [RFC HACK] rtl2832: implement own lock for RegMap
Em Thu, 18 Dec 2014 16:41:28 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/18/2014 01:21 PM, Mauro Carvalho Chehab wrote:
Em Thu, 18 Dec 2014 12:29:46 +0200
Antti Palosaari cr...@iki.fi escreveu:
Introduce own lock to silence locdep warning. I suspect lockdep checks
make wrong decision when two similar name (map-mutex) locks were
taken recursively, even those are different mutexes in a two different
driver. After that patch, functionality remains same, but mutex names
are different.
Please do not add a hack just to silence a lockdep warning.
Please take a look at: Documentation/locking/lockdep-design.txt
There are some documentation there about the usage of nested locks and
how to avoid lockdep to complain.
I cannot see any way how those lockdep things could be used on my driver
as problematic lock itself is located inside RegMap. I think it is
RegMap which needs some special lockdep things in order to allow nested
locking of different instances.
Ok. So, do a patch for RegMap and send for its maintainers.
Regards,
Mauro
So I think demod I2C adapter is good place for that kind of hack until
better solution is find. Defining own RegMap lock here in I2C repeater
allows all the clients be hack free using default RegMap lock.
regards
Antti
Regards,
Mauro
=
[ INFO: possible recursive locking detected ]
3.18.0-rc4+ #4 Tainted: G O
-
kdvb-ad-0-fe-0/2814 is trying to acquire lock:
(map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
but task is already holding lock:
(map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(map-mutex);
lock(map-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by kdvb-ad-0-fe-0/2814:
#0: (map-mutex){+.+.+.}, at: [814ec90f]
regmap_lock_mutex+0x2f/0x40
stack backtrace:
CPU: 3 PID: 2814 Comm: kdvb-ad-0-fe-0 Tainted: G O 3.18.0-rc4+ #4
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS
200109/11/2014
410c8772 880293af3868 817a6f82
8800b3462be0 880293af3968 810e7f94
880293af3888 410c8772 82dfee60 81ab8f89
Call Trace:
[817a6f82] dump_stack+0x4e/0x68
[810e7f94] __lock_acquire+0x1ea4/0x1f50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817b01f3] ? _raw_spin_lock_irqsave+0x83/0xa0
[810e13e6] ? up+0x16/0x50
[810e2a7d] ? trace_hardirqs_off+0xd/0x10
[817af8bf] ? _raw_spin_unlock_irqrestore+0x5f/0x70
[810e9069] lock_acquire+0xc9/0x170
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817ab50e] mutex_lock_nested+0x7e/0x430
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[817a530b] ? printk+0x70/0x86
[8110d9e8] ? mod_timer+0x168/0x240
[814ec90f] regmap_lock_mutex+0x2f/0x40
[814f08d9] regmap_update_bits+0x29/0x60
[a03e9778] rtl2832_select+0x38/0x70 [rtl2832]
[a039b03d] i2c_mux_master_xfer+0x3d/0x90 [i2c_mux]
[815da493] __i2c_transfer+0x73/0x2e0
[815dbaba] i2c_transfer+0x5a/0xc0
[815dbb6e] i2c_master_send+0x4e/0x70
[a03ff25a] regmap_i2c_write+0x1a/0x50 [regmap_i2c]
[817ab713] ? mutex_lock_nested+0x283/0x430
[814f06b2] _regmap_raw_write+0x862/0x880
[814ec90f] ? regmap_lock_mutex+0x2f/0x40
[814f0744] _regmap_bus_raw_write+0x74/0xa0
[814ef3d2] _regmap_write+0x92/0x140
[814f0b7b] regmap_write+0x4b/0x70
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[a05141d4] e4000_init+0x34/0x210 [e4000]
[a032a029] dvb_frontend_init+0x59/0xc0 [dvb_core]
[810bde30] ? finish_task_switch+0x80/0x180
[810bddf2] ? finish_task_switch+0x42/0x180
[a032b116] dvb_frontend_thread+0x86/0x7b0 [dvb_core]
[817a9203] ? __schedule+0x343/0x930
[a032b090] ? dvb_frontend_release+0x110/0x110 [dvb_core]
[810b826b] kthread+0x10b/0x130
[81020099] ? sched_clock+0x9/0x10
[810b8160] ? kthread_create_on_node+0x250/0x250
[817b063c] ret_from_fork+0x7c/0xb0
[810b8160] ? kthread_create_on_node+0x250/0x250
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 49
+++---
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git
[RFC PATCH 0/5] media: rcar_vin: Fixes for buffer management
This is a re-submission of patches previously sent and archived at http://thread.gmane.org/gmane.linux.ports.sh.devel/37184/. Will has rebased onto 3.18 and added a further patch to address Hans' review comments. The driver continues to works for single frame capture, and no longer provokes a WARNing. However, video capture has regressed (a gstreamer capture pipeline yields a zero-length file). Ben. Ian Molton (4): media: rcar_vin: Dont aggressively retire buffers media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping. media: rcar_vin: Fix race condition terminating stream media: rcar_vin: Clean up rcar_vin_irq William Towle (1): media: rcar_vin: move buffer management to .stop_streaming handler drivers/media/platform/soc_camera/rcar_vin.c | 109 ++ 1 file changed, 59 insertions(+), 50 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/5] media: rcar_vin: Dont aggressively retire buffers
From: Ian Molton ian.mol...@codethink.co.uk
rcar_vin_videobuf_release() is called once per buffer from the buf_cleanup hook.
There is no need to look up the queue and free all buffers at this point.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 8d8438b..773de53 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -496,17 +496,11 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
* to release could be any of the current buffers in use, so
* release all buffers that are in use by HW
*/
- for (i = 0; i MAX_BUFFER_NUM; i++) {
- if (priv-queue_buf[i]) {
- vb2_buffer_done(priv-queue_buf[i],
- VB2_BUF_STATE_ERROR);
- priv-queue_buf[i] = NULL;
- }
- }
- } else {
- list_del_init(to_buf_list(vb));
+ priv-queue_buf[i] = NULL;
}
+ list_del_init(to_buf_list(vb));
+
spin_unlock_irq(priv-lock);
}
--
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
[RFC PATCH 3/5] media: rcar_vin: Fix race condition terminating stream
From: Ian Molton ian.mol...@codethink.co.uk
This patch fixes a race condition whereby a frame being captured may generate an
interrupt between requesting capture to halt and freeing buffers.
This condition is exposed by the earlier patch that explicitly calls
vb2_buffer_done() during stop streaming.
The solution is to wait for capture to finish prior to finalising these buffers.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 43 +-
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 7069176..b234e57 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -458,6 +458,29 @@ error:
vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
}
+/*
+ * Wait for capture to stop and all in-flight buffers to be finished with by
+ * the video hardware. This must be called under priv-lock
+ *
+ */
+static void rcar_vin_wait_stop_streaming(struct rcar_vin_priv *priv)
+{
+ while (priv-state != STOPPED) {
+
+ /* issue stop if running */
+ if (priv-state == RUNNING)
+ rcar_vin_request_capture_stop(priv);
+
+ /* wait until capturing has been stopped */
+ if (priv-state == STOPPING) {
+ priv-request_to_stop = true;
+ spin_unlock_irq(priv-lock);
+ wait_for_completion(priv-capture_stop);
+ spin_lock_irq(priv-lock);
+ }
+ }
+}
+
static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vb-vb2_queue);
@@ -465,7 +488,6 @@ static void rcar_vin_videobuf_release(struct vb2_buffer *vb)
struct rcar_vin_priv *priv = ici-priv;
unsigned int i;
int buf_in_use = 0;
-
spin_lock_irq(priv-lock);
/* Is the buffer in use by the VIN hardware? */
@@ -477,20 +499,8 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
}
if (buf_in_use) {
- while (priv-state != STOPPED) {
-
- /* issue stop if running */
- if (priv-state == RUNNING)
- rcar_vin_request_capture_stop(priv);
-
- /* wait until capturing has been stopped */
- if (priv-state == STOPPING) {
- priv-request_to_stop = true;
- spin_unlock_irq(priv-lock);
- wait_for_completion(priv-capture_stop);
- spin_lock_irq(priv-lock);
- }
- }
+ rcar_vin_wait_stop_streaming(priv);
+
/*
* Capturing has now stopped. The buffer we have been asked
* to release could be any of the current buffers in use, so
@@ -520,12 +530,15 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
spin_lock_irq(priv-lock);
+ rcar_vin_wait_stop_streaming(priv);
+
for (i = 0; i vq-num_buffers; ++i)
if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE)
vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR);
list_for_each_safe(buf_head, tmp, priv-capture)
list_del_init(buf_head);
+
spin_unlock_irq(priv-lock);
}
--
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
[RFC PATCH 2/5] media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping.
From: Ian Molton ian.mol...@codethink.co.uk Videobuf2 complains about buffers that are still marked ACTIVE (in use by the driver) following a call to stop_streaming(). This patch returns all active buffers to state ERROR prior to stopping. Note: this introduces a (non fatal) race condition as the stream is not guaranteed to be stopped at this point. Signed-off-by: Ian Molton ian.mol...@codethink.co.uk Signed-off-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 773de53..7069176 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -516,8 +516,14 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq) struct soc_camera_host *ici = to_soc_camera_host(icd-parent); struct rcar_vin_priv *priv = ici-priv; struct list_head *buf_head, *tmp; + int i; spin_lock_irq(priv-lock); + + for (i = 0; i vq-num_buffers; ++i) + if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE) + vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR); + list_for_each_safe(buf_head, tmp, priv-capture) list_del_init(buf_head); spin_unlock_irq(priv-lock); -- 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
[RFC PATCH 4/5] media: rcar_vin: Clean up rcar_vin_irq
From: Ian Molton ian.mol...@codethink.co.uk
This patch makes the rcar_vin IRQ handler a little more readable.
Removes an else clause, and simplifies the buffer handling.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Reviewed-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index b234e57..20dbedf 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -557,7 +557,6 @@ static irqreturn_t rcar_vin_irq(int irq, void *data)
struct rcar_vin_priv *priv = data;
u32 int_status;
bool can_run = false, hw_stopped;
- int slot;
unsigned int handled = 0;
spin_lock(priv-lock);
@@ -576,17 +575,22 @@ static irqreturn_t rcar_vin_irq(int irq, void *data)
hw_stopped = !(ioread32(priv-base + VNMS_REG) VNMS_CA);
if (!priv-request_to_stop) {
+ struct vb2_buffer **q_entry = priv-queue_buf;
+ struct vb2_buffer *vb;
+
if (is_continuous_transfer(priv))
- slot = (ioread32(priv-base + VNMS_REG)
- VNMS_FBS_MASK) VNMS_FBS_SHIFT;
- else
- slot = 0;
+ q_entry += (ioread32(priv-base + VNMS_REG)
+ VNMS_FBS_MASK) VNMS_FBS_SHIFT;
+
+ vb = *q_entry;
+
+ vb-v4l2_buf.field = priv-field;
+ vb-v4l2_buf.sequence = priv-sequence++;
+ do_gettimeofday(vb-v4l2_buf.timestamp);
+
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
- priv-queue_buf[slot]-v4l2_buf.field = priv-field;
- priv-queue_buf[slot]-v4l2_buf.sequence = priv-sequence++;
- do_gettimeofday(priv-queue_buf[slot]-v4l2_buf.timestamp);
- vb2_buffer_done(priv-queue_buf[slot], VB2_BUF_STATE_DONE);
- priv-queue_buf[slot] = NULL;
+ *q_entry = NULL;
if (priv-state != STOPPING)
can_run = rcar_vin_fill_hw_slot(priv);
--
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
[RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
From: William Towle william.to...@codethink.co.uk
Move the buffer state test in the .buf_cleanup handler into
.stop_streaming so that a) the vb2_queue API is not subverted, and
b) tracking of active-state buffers via priv-queue_buf[] is handled
as early as is possible
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 36 ++
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 20dbedf..bf60074 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -486,28 +486,8 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
*vb)
struct soc_camera_device *icd = soc_camera_from_vb2q(vb-vb2_queue);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct rcar_vin_priv *priv = ici-priv;
- unsigned int i;
- int buf_in_use = 0;
- spin_lock_irq(priv-lock);
-
- /* Is the buffer in use by the VIN hardware? */
- for (i = 0; i MAX_BUFFER_NUM; i++) {
- if (priv-queue_buf[i] == vb) {
- buf_in_use = 1;
- break;
- }
- }
- if (buf_in_use) {
- rcar_vin_wait_stop_streaming(priv);
-
- /*
-* Capturing has now stopped. The buffer we have been asked
-* to release could be any of the current buffers in use, so
-* release all buffers that are in use by HW
-*/
- priv-queue_buf[i] = NULL;
- }
+ spin_lock_irq(priv-lock);
list_del_init(to_buf_list(vb));
@@ -533,8 +513,20 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
rcar_vin_wait_stop_streaming(priv);
for (i = 0; i vq-num_buffers; ++i)
- if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE)
+ if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE) {
+ int j;
+
+ /* Is this a buffer we have told the
+* hardware about? Update the associated
+* list, if so
+*/
+ for (j = 0; j MAX_BUFFER_NUM; j++) {
+ if (priv-queue_buf[j] == vq-bufs[i]) {
+ priv-queue_buf[j] = NULL;
+ }
+ }
vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR);
+ }
list_for_each_safe(buf_head, tmp, priv-capture)
list_del_init(buf_head);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] au0828 vb2 conversion
This patch series includes patch v2 of the au0828 vb2 conversion, removing video and vbi buffer timeout handling, and a patch to not set fmt.pix.priv. The following work is in progress and will be as separate patches: - removing users and using v4l2_fh_is_singular_file() instead. - Changing dynamic allocation of video device structs to static which will reduce the overhead to allocate at register time and deallocating at unregister. Shuah Khan (3): media: au0828 - convert to use videobuf2 media: au0828 change to not zero out fmt.pix.priv media: au0828 remove video and vbi buffer timeout work-around drivers/media/usb/au0828/Kconfig| 2 +- drivers/media/usb/au0828/au0828-cards.c | 2 +- drivers/media/usb/au0828/au0828-vbi.c | 122 ++-- drivers/media/usb/au0828/au0828-video.c | 994 +++- drivers/media/usb/au0828/au0828.h | 64 +- 5 files changed, 414 insertions(+), 770 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] media: au0828 remove video and vbi buffer timeout work-around
au0828 does video and vbi buffer timeout handling to prevent
applications such as tvtime from hanging by ensuring that the
video frames continue to be delivered even when the ITU-656
input isn't receiving any data. This work-around is complex
as it introduces set and clear tier code paths in start/stop
streaming, and close interfaces. After the vb2 conversion, the
timeout handling is introducing instability as well as feeding
too many blank green screens, resulting in degraded video quality.
Without this timeout handling, both xawtv, and tvtime are working
well with good quality video.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828-video.c | 103 +---
drivers/media/usb/au0828/au0828.h | 5 --
2 files changed, 1 insertion(+), 107 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index ef49b2e..3bdf132 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -593,15 +593,6 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev,
struct urb *urb)
outp = NULL;
else
outp = vb2_plane_vaddr(buf-vb, 0);
-
- /* As long as isoc traffic is arriving, keep
- resetting the timer */
- if (dev-vid_timeout_running)
- mod_timer(dev-vid_timeout,
- jiffies + (HZ / 10));
- if (dev-vbi_timeout_running)
- mod_timer(dev-vbi_timeout,
- jiffies + (HZ / 10));
}
if (buf != NULL) {
@@ -804,15 +795,9 @@ int au0828_start_analog_streaming(struct vb2_queue *vq,
unsigned int count)
return rc;
}
- if (vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ if (vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
v4l2_device_call_all(dev-v4l2_dev, 0, video,
s_stream, 1);
- dev-vid_timeout_running = 1;
- mod_timer(dev-vid_timeout, jiffies + (HZ / 10));
- } else if (vq-type == V4L2_BUF_TYPE_VBI_CAPTURE) {
- dev-vbi_timeout_running = 1;
- mod_timer(dev-vbi_timeout, jiffies + (HZ / 10));
- }
}
dev-streaming_users++;
return rc;
@@ -851,9 +836,6 @@ static void au0828_stop_streaming(struct vb2_queue *vq)
(AUVI_INPUT(i).audio_setup)(dev, 0);
}
spin_unlock_irqrestore(dev-slock, flags);
-
- dev-vid_timeout_running = 0;
- del_timer_sync(dev-vid_timeout);
}
void au0828_stop_vbi_streaming(struct vb2_queue *vq)
@@ -882,9 +864,6 @@ void au0828_stop_vbi_streaming(struct vb2_queue *vq)
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
spin_unlock_irqrestore(dev-slock, flags);
-
- dev-vbi_timeout_running = 0;
- del_timer_sync(dev-vbi_timeout);
}
static struct vb2_ops au0828_video_qops = {
@@ -917,56 +896,6 @@ void au0828_analog_unregister(struct au0828_dev *dev)
mutex_unlock(au0828_sysfs_lock);
}
-/* This function ensures that video frames continue to be delivered even if
- the ITU-656 input isn't receiving any data (thereby preventing applications
- such as tvtime from hanging) */
-static void au0828_vid_buffer_timeout(unsigned long data)
-{
- struct au0828_dev *dev = (struct au0828_dev *) data;
- struct au0828_dmaqueue *dma_q = dev-vidq;
- struct au0828_buffer *buf;
- unsigned char *vid_data;
- unsigned long flags = 0;
-
- spin_lock_irqsave(dev-slock, flags);
-
- buf = dev-isoc_ctl.buf;
- if (buf != NULL) {
- vid_data = vb2_plane_vaddr(buf-vb, 0);
- memset(vid_data, 0x00, buf-length); /* Blank green frame */
- buffer_filled(dev, dma_q, buf);
- }
- get_next_buf(dma_q, buf);
-
- if (dev-vid_timeout_running == 1)
- mod_timer(dev-vid_timeout, jiffies + (HZ / 10));
-
- spin_unlock_irqrestore(dev-slock, flags);
-}
-
-static void au0828_vbi_buffer_timeout(unsigned long data)
-{
- struct au0828_dev *dev = (struct au0828_dev *) data;
- struct au0828_dmaqueue *dma_q = dev-vbiq;
- struct au0828_buffer *buf;
- unsigned char *vbi_data;
- unsigned long flags = 0;
-
- spin_lock_irqsave(dev-slock, flags);
-
- buf = dev-isoc_ctl.vbi_buf;
- if (buf != NULL) {
- vbi_data = vb2_plane_vaddr(buf-vb, 0);
- memset(vbi_data, 0x00, buf-length);
- vbi_buffer_filled(dev, dma_q,
[PATCH v2 1/3] media: au0828 - convert to use videobuf2
Convert au0828 to use videobuf2. Tested with NTSC.
Tested video and vbi devices with xawtv, tvtime,
and vlc. Ran v4l2-compliance to ensure there are
no new regressions in video and vbi now has 3 fewer
failures.
video before:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Video after:
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
vbi before:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
test VIDIOC_EXPBUF: FAIL
test USERPTR: FAIL
Total: 72, Succeeded: 66, Failed: 6, Warnings: 0
vbi after:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test USERPTR: OK
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/Kconfig| 2 +-
drivers/media/usb/au0828/au0828-cards.c | 2 +-
drivers/media/usb/au0828/au0828-vbi.c | 122 ++--
drivers/media/usb/au0828/au0828-video.c | 949 +---
drivers/media/usb/au0828/au0828.h | 61 +-
5 files changed, 444 insertions(+), 692 deletions(-)
diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig
index 1d410ac..78b797e 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_AU0828
depends on I2C INPUT DVB_CORE USB
select I2C_ALGOBIT
select VIDEO_TVEEPROM
- select VIDEOBUF_VMALLOC
+ select VIDEOBUF2_VMALLOC
select DVB_AU8522_DTV if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 9eb77ac..ae2e563 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -39,7 +39,7 @@ static void hvr950q_cs5340_audio(void *priv, int enable)
struct au0828_board au0828_boards[] = {
[AU0828_BOARD_UNKNOWN] = {
.name = Unknown board,
- .tuner_type = UNSET,
+ .tuner_type = -1U,
.tuner_addr = ADDR_UNSET,
},
[AU0828_BOARD_HAUPPAUGE_HVR850] = {
diff --git a/drivers/media/usb/au0828/au0828-vbi.c
b/drivers/media/usb/au0828/au0828-vbi.c
index 932d24f..f67247c 100644
--- a/drivers/media/usb/au0828/au0828-vbi.c
+++ b/drivers/media/usb/au0828/au0828-vbi.c
@@ -28,111 +28,67 @@
#include linux/init.h
#include linux/slab.h
-static unsigned int vbibufs = 5;
-module_param(vbibufs, int, 0644);
-MODULE_PARM_DESC(vbibufs, number of vbi buffers, range 2-32);
-
/* -- */
-static void
-free_buffer(struct videobuf_queue *vq, struct au0828_buffer *buf)
+static int vbi_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
- struct au0828_fh *fh = vq-priv_data;
- struct au0828_dev*dev = fh-dev;
- unsigned long flags = 0;
- if (in_interrupt())
- BUG();
-
- /* We used to wait for the buffer to finish here, but this didn't work
- because, as we were keeping the state as VIDEOBUF_QUEUED,
- videobuf_queue_cancel marked it as finished for us.
- (Also, it could wedge forever if the hardware was misconfigured.)
-
- This should be safe; by the time we get here, the buffer isn't
- queued anymore. If we ever start marking the buffers as
- VIDEOBUF_ACTIVE, it won't be, though.
- */
- spin_lock_irqsave(dev-slock, flags);
- if (dev-isoc_ctl.vbi_buf == buf)
- dev-isoc_ctl.vbi_buf = NULL;
- spin_unlock_irqrestore(dev-slock, flags);
+ struct au0828_dev *dev = vb2_get_drv_priv(vq);
+ unsigned long img_size = dev-vbi_width * dev-vbi_height * 2;
+ unsigned long size;
- videobuf_vmalloc_free(buf-vb);
- buf-vb.state = VIDEOBUF_NEEDS_INIT;
-}
-
-static int
-vbi_setup(struct videobuf_queue *q, unsigned int *count, unsigned int *size)
-{
- struct au0828_fh *fh = q-priv_data;
- struct au0828_dev*dev = fh-dev;
+ size = fmt ? (fmt-fmt.vbi.samples_per_line *
+ (fmt-fmt.vbi.count[0] + fmt-fmt.vbi.count[1])) : img_size;
+ if (size img_size)
+ return -EINVAL;
- *size = dev-vbi_width * dev-vbi_height * 2;
+ *nplanes = 1;
+ sizes[0] = size;
- if (0 == *count)
- *count = vbibufs;
- if (*count 2)
- *count = 2;
- if (*count 32)
- *count = 32;
return 0;
}
-static int
-vbi_prepare(struct videobuf_queue *q, struct videobuf_buffer *vb,
- enum v4l2_field field)
+static int vbi_buffer_prepare(struct vb2_buffer *vb)
{
-
[PATCH v2 2/3] media: au0828 change to not zero out fmt.pix.priv
There is no need to zero out fmt.pix.priv in vidioc_g_fmt_vid_cap() vidioc_try_fmt_vid_cap(), and vidioc_s_fmt_vid_cap(). Remove it. Signed-off-by: Shuah Khan shua...@osg.samsung.com --- drivers/media/usb/au0828/au0828-video.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c index 3011ca8..ef49b2e 100644 --- a/drivers/media/usb/au0828/au0828-video.c +++ b/drivers/media/usb/au0828/au0828-video.c @@ -1104,7 +1104,6 @@ static int au0828_set_format(struct au0828_dev *dev, unsigned int cmd, format-fmt.pix.sizeimage = width * height * 2; format-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; format-fmt.pix.field = V4L2_FIELD_INTERLACED; - format-fmt.pix.priv = 0; if (cmd == VIDIOC_TRY_FMT) return 0; @@ -1189,7 +1188,6 @@ static int vidioc_g_fmt_vid_cap(struct file *file, void *priv, f-fmt.pix.sizeimage = dev-frame_size; f-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; /* NTSC/PAL */ f-fmt.pix.field = V4L2_FIELD_INTERLACED; - f-fmt.pix.priv = 0; return 0; } -- 2.1.0 -- 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
coda: Unable to use encoder video_bitrate
Hi I am trying to use the coda encoder through Gstreamer on an iMX6-based board. I use the (rebased and slightly modified) gstv4l2h264enc plugin from: https://github.com/hizukiayaka/gst-plugins-good This pipeline works fine: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc ! h264parse ! mp4mux ! filesink location=test.mp4 When encoder has no bitrate param set (default=0), video encoding works well, but bitrate reaches ~2.5Mbps When I try to set the bitrate with whatever value like 100,000 or 1,000,000, the encoder produces video with bitrate around 480kbps and a very poor quality. Here is the gstreamer pipeline I use with bitrate set: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc extra-controls=controls,video_bitrate=100; ! h264parse ! mp4mux ! filesink location=test.mp4 The video_bitrate control seems to be correctly passed to the driver by GStreamer since I can see the VIDIOC_S_CTRL call. Any idea ? Thanks Fred -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] coda: fix encoder rate control parameter masks
This patch fixes the ENC_SEQ_RC_PARA initial delay and bitrate masks. These bit fields are 15 bit wide, not 7 bit. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/media/platform/coda/coda_regs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/coda/coda_regs.h b/drivers/media/platform/coda/coda_regs.h index 8e015b8..7d02624 100644 --- a/drivers/media/platform/coda/coda_regs.h +++ b/drivers/media/platform/coda/coda_regs.h @@ -304,9 +304,9 @@ #defineCODA_RATECONTROL_AUTOSKIP_OFFSET31 #defineCODA_RATECONTROL_AUTOSKIP_MASK 0x01 #defineCODA_RATECONTROL_INITIALDELAY_OFFSET16 -#defineCODA_RATECONTROL_INITIALDELAY_MASK 0x7f +#defineCODA_RATECONTROL_INITIALDELAY_MASK 0x7fff #defineCODA_RATECONTROL_BITRATE_OFFSET 1 -#defineCODA_RATECONTROL_BITRATE_MASK 0x7f +#defineCODA_RATECONTROL_BITRATE_MASK 0x7fff #defineCODA_RATECONTROL_ENABLE_OFFSET 0 #defineCODA_RATECONTROL_ENABLE_MASK0x01 #define CODA_CMD_ENC_SEQ_RC_BUF_SIZE 0x1b0 -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] coda: bitrate can only be set in kbps steps
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 42b4630..74261d9 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1407,7 +1407,7 @@ static const struct v4l2_ctrl_ops coda_ctrl_ops = {
static void coda_encode_ctrls(struct coda_ctx *ctx)
{
v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
- V4L2_CID_MPEG_VIDEO_BITRATE, 0, 32767000, 1, 0);
+ V4L2_CID_MPEG_VIDEO_BITRATE, 0, 32767000, 1000, 0);
v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_GOP_SIZE, 1, 60, 1, 16);
v4l2_ctrl_new_std(ctx-ctrls, coda_ctrl_ops,
--
2.1.3
--
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 0/3] Introduce IIO interface for fingerprint sensors
Adding V4L folks to Cc for more input.
On 12/08/2014 03:10 PM, Baluta, Teodora wrote:
Hello,
On Vi, 2014-12-05 at 02:15 +, Jonathan Cameron wrote:
On 04/12/14 13:00, Teodora Baluta wrote:
This patchset adds support for fingerprint sensors through the IIO interface.
This way userspace applications collect information in a uniform way. All
processing would be done in the upper layers as suggested in [0].
In order to test out this proposal, a minimal implementation for UPEK's
TouchChip Fingerprint Sensor via USB is also available. Although there is an
existing implementation in userspace for USB fingerprint devices, including this
particular device, the driver represents a proof of concept of how fingerprint
sensors could be integrated in the IIO framework regardless of the used bus. For
lower power requirements, the SPI bus is preferred and a kernel driver
implementation makes more sense.
So why not v4l? These are effectively image sensors..
Well, here's why I don't think v4l would be the best option:
- an image scanner could be implemented in the v4l subsystem, but it
seems far more complicated for a simple fingerprint scanner - it usually
has drivers for webcams, TVs or video streaming devices. The v4l
subsystem (with all its support for colorspace, decoders, image
compression, frame control) seems a bit of an overkill for a very
straightforward fingerprint imaging sensor.
- a fingerprint device could also send out a processed information, not
just the image of a fingerprint. This means that the processing is done
in hardware - the UPEK TouchStrip chipset in libfprint has this behavior
(see [0]). So, the IIO framework would support a uniform way of handling
fingerprint devices that either do processing in software or in
hardware.
The way I see it now, for processed fingerprint information, an IIO
device could have an IIO_FINGERPRINT channel with a modifier and only
the sensitivity threshold attribute set. We would also need two
triggers: one for enrollment and one for the verification mode to
control the device from a userspace application.
Thanks,
Teodora
[0] http://www.freedesktop.org/wiki/Software/fprint/libfprint/upekts/
A sysfs trigger is enabled and the device starts scanning. As soon as an image
is available it is written in the character device /dev/iio:deviceX.
Userspace applications will be able to calculate the expected image size using
the fingerprint attributes height, width and bit depth. Other attributes
introduced for the fingerprint channel in IIO represent information that aids in
the fingerprint image processing. Besides these, the proposed interface offers
userspace a way to read a feedback after a scan (like the swipe was too slow or
too fast) through a modified fingerprint_status channel.
[0] http://www.spinics.net/lists/linux-iio/msg11463.html
Teodora Baluta (3):
iio: core: add support for fingerprint devices
iio: core: change channel's storagebits/realbits to u32
iio: fingerprint: add fingerprint sensor via USB
Documentation/ABI/testing/sysfs-bus-iio | 51 +++
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile| 1 +
drivers/iio/fingerprint/Kconfig | 15 +
drivers/iio/fingerprint/Makefile| 5 +
drivers/iio/fingerprint/fp_tc.c | 162 +
drivers/iio/fingerprint/fp_tc.h | 22 ++
drivers/iio/fingerprint/fp_tc_usb.c | 618
drivers/iio/fingerprint/fp_tc_usb.h | 144
drivers/iio/industrialio-core.c | 9 +
include/linux/iio/iio.h | 11 +-
include/linux/iio/types.h | 10 +
12 files changed, 1047 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/fingerprint/Kconfig
create mode 100644 drivers/iio/fingerprint/Makefile
create mode 100644 drivers/iio/fingerprint/fp_tc.c
create mode 100644 drivers/iio/fingerprint/fp_tc.h
create mode 100644 drivers/iio/fingerprint/fp_tc_usb.c
create mode 100644 drivers/iio/fingerprint/fp_tc_usb.h
N�r��y���b�X��ǧv�^�){.n�+{��*��^n�r���z���h�� �G���h�(�階�ݢj���m�z�ޖ���f���h���~�mml==
--
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: coda: Unable to use encoder video_bitrate
Hi Frédéric, Am Donnerstag, den 18.12.2014, 17:44 +0100 schrieb Frédéric Sureau: Hi I am trying to use the coda encoder through Gstreamer on an iMX6-based board. I use the (rebased and slightly modified) gstv4l2h264enc plugin from: https://github.com/hizukiayaka/gst-plugins-good This pipeline works fine: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc ! h264parse ! mp4mux ! filesink location=test.mp4 When encoder has no bitrate param set (default=0), video encoding works well, but bitrate reaches ~2.5Mbps When I try to set the bitrate with whatever value like 100,000 or 1,000,000, the encoder produces video with bitrate around 480kbps and a very poor quality. Here is the gstreamer pipeline I use with bitrate set: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc extra-controls=controls,video_bitrate=100; ! h264parse ! mp4mux ! filesink location=test.mp4 The video_bitrate control seems to be correctly passed to the driver by GStreamer since I can see the VIDIOC_S_CTRL call. Any idea ? There is a bug in the register definitions that causes the driver to apply a wrong mask before writing the bitrate to the register. I've got a fix for this in the pipeline, sending it right now. regards Philipp -- 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: coda: Unable to use encoder video_bitrate
Hi Philipp, 2014-12-18 17:52 GMT+01:00 Philipp Zabel p.za...@pengutronix.de: Hi Frédéric, Am Donnerstag, den 18.12.2014, 17:44 +0100 schrieb Frédéric Sureau: Hi I am trying to use the coda encoder through Gstreamer on an iMX6-based board. I use the (rebased and slightly modified) gstv4l2h264enc plugin from: https://github.com/hizukiayaka/gst-plugins-good This pipeline works fine: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc ! h264parse ! mp4mux ! filesink location=test.mp4 When encoder has no bitrate param set (default=0), video encoding works well, but bitrate reaches ~2.5Mbps When I try to set the bitrate with whatever value like 100,000 or 1,000,000, the encoder produces video with bitrate around 480kbps and a very poor quality. Here is the gstreamer pipeline I use with bitrate set: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc extra-controls=controls,video_bitrate=100; ! h264parse ! mp4mux ! filesink location=test.mp4 The video_bitrate control seems to be correctly passed to the driver by GStreamer since I can see the VIDIOC_S_CTRL call. Any idea ? There is a bug in the register definitions that causes the driver to apply a wrong mask before writing the bitrate to the register. I've got a fix for this in the pipeline, sending it right now. Where can we find the register definitions ? In order to look at it before asking you :) ? Thanks, JM -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.20] uvcvideo changes
Hi Mauro, The following changes since commit 427ae153c65ad7a08288d86baf99000569627d03: [media] bq/c-qcam, w9966, pms: move to staging in preparation for removal (2014-12-16 23:21:44 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git uvc/next for you to fetch changes up to b8a2eed854ea417e82f316b45a749bbe0b43fb18: uvcvideo: Add GUID for BGR 8:8:8 (2014-12-18 18:59:50 +0200) Lad, Prabhakar (1): media: usb: uvc: use vb2_ops_wait_prepare/finish helper William Manley (1): uvcvideo: Add GUID for BGR 8:8:8 drivers/media/usb/uvc/uvc_driver.c | 5 + drivers/media/usb/uvc/uvc_queue.c | 19 +++ drivers/media/usb/uvc/uvcvideo.h | 3 +++ 3 files changed, 11 insertions(+), 16 deletions(-) -- 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
[GIT PULL FOR v3.20] OMAP3 ISP and OMAP4 ISS changes
Hi Mauro, The following changes since commit 427ae153c65ad7a08288d86baf99000569627d03: [media] bq/c-qcam, w9966, pms: move to staging in preparation for removal (2014-12-16 23:21:44 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap/next for you to fetch changes up to 0ad05d6633d3a6cb4410473ebc93c94b14f16478: v4l: omap4iss: Stop started entities when pipeline start fails (2014-12-18 18:54:27 +0200) Laurent Pinchart (5): omap3isp: Fix division by 0 v4l: omap4iss: Enable DMABUF support v4l: omap4iss: Remove bogus frame number propagation v4l: omap4iss: csi2: Perform real frame number propagation v4l: omap4iss: Stop started entities when pipeline start fails drivers/media/platform/omap3isp/isp.c| 3 + drivers/staging/media/omap4iss/iss.c | 111 +++--- drivers/staging/media/omap4iss/iss_csi2.c| 43 ++ drivers/staging/media/omap4iss/iss_csi2.h| 2 +- drivers/staging/media/omap4iss/iss_ipipeif.c | 22 +-- drivers/staging/media/omap4iss/iss_regs.h| 2 + drivers/staging/media/omap4iss/iss_resizer.c | 18 +- drivers/staging/media/omap4iss/iss_video.c | 11 +++- 8 files changed, 116 insertions(+), 96 deletions(-) -- 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: coda: Unable to use encoder video_bitrate
Hi Jean-Michel, Am Donnerstag, den 18.12.2014, 17:55 +0100 schrieb Jean-Michel Hautbois: Hi Philipp, 2014-12-18 17:52 GMT+01:00 Philipp Zabel p.za...@pengutronix.de: Hi Frédéric, Am Donnerstag, den 18.12.2014, 17:44 +0100 schrieb Frédéric Sureau: Hi I am trying to use the coda encoder through Gstreamer on an iMX6-based board. I use the (rebased and slightly modified) gstv4l2h264enc plugin from: https://github.com/hizukiayaka/gst-plugins-good This pipeline works fine: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc ! h264parse ! mp4mux ! filesink location=test.mp4 When encoder has no bitrate param set (default=0), video encoding works well, but bitrate reaches ~2.5Mbps When I try to set the bitrate with whatever value like 100,000 or 1,000,000, the encoder produces video with bitrate around 480kbps and a very poor quality. Here is the gstreamer pipeline I use with bitrate set: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc extra-controls=controls,video_bitrate=100; ! h264parse ! mp4mux ! filesink location=test.mp4 The video_bitrate control seems to be correctly passed to the driver by GStreamer since I can see the VIDIOC_S_CTRL call. Any idea ? There is a bug in the register definitions that causes the driver to apply a wrong mask before writing the bitrate to the register. I've got a fix for this in the pipeline, sending it right now. Where can we find the register definitions ? In order to look at it before asking you :) ? Sorry, forgot to put all of you on Cc: for the [media] coda: fix encoder rate control parameter masks patch. The coda driver is in drivers/media/platform/coda, register definitions in coda_regs.h. The CODA_RATECONTROL_BITRATE_MASK is 0x7f, but it should be 0x7fff. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.20] Renesas VSP1 changes
Hi Mauro, The following changes since commit 427ae153c65ad7a08288d86baf99000569627d03: [media] bq/c-qcam, w9966, pms: move to staging in preparation for removal (2014-12-16 23:21:44 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git vsp1/next for you to fetch changes up to c87bdd51972b9f7148732e359407f8038b572e8f: v4l: vsp1: Always enable virtual RPF when BRU is in use (2014-12-18 19:09:14 +0200) Laurent Pinchart (1): v4l: vsp1: Remove support for platform data Takanari Hayama (2): v4l: vsp1: Reset VSP1 RPF source address v4l: vsp1: Always enable virtual RPF when BRU is in use drivers/media/platform/Kconfig | 2 +- drivers/media/platform/vsp1/vsp1.h | 14 ++- drivers/media/platform/vsp1/vsp1_drv.c | 81 drivers/media/platform/vsp1/vsp1_rpf.c | 18 + drivers/media/platform/vsp1/vsp1_rwpf.h | 1 + drivers/media/platform/vsp1/vsp1_wpf.c | 13 --- include/linux/platform_data/vsp1.h | 27 -- 7 files changed, 68 insertions(+), 88 deletions(-) delete mode 100644 include/linux/platform_data/vsp1.h -- 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: coda: Unable to use encoder video_bitrate
2014-12-18 18:09 GMT+01:00 Philipp Zabel p.za...@pengutronix.de: Hi Jean-Michel, Am Donnerstag, den 18.12.2014, 17:55 +0100 schrieb Jean-Michel Hautbois: Hi Philipp, 2014-12-18 17:52 GMT+01:00 Philipp Zabel p.za...@pengutronix.de: Hi Frédéric, Am Donnerstag, den 18.12.2014, 17:44 +0100 schrieb Frédéric Sureau: Hi I am trying to use the coda encoder through Gstreamer on an iMX6-based board. I use the (rebased and slightly modified) gstv4l2h264enc plugin from: https://github.com/hizukiayaka/gst-plugins-good This pipeline works fine: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc ! h264parse ! mp4mux ! filesink location=test.mp4 When encoder has no bitrate param set (default=0), video encoding works well, but bitrate reaches ~2.5Mbps When I try to set the bitrate with whatever value like 100,000 or 1,000,000, the encoder produces video with bitrate around 480kbps and a very poor quality. Here is the gstreamer pipeline I use with bitrate set: gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! video/x-raw,width=1280,height=720 ! videoconvert ! v4l2video0h264enc extra-controls=controls,video_bitrate=100; ! h264parse ! mp4mux ! filesink location=test.mp4 The video_bitrate control seems to be correctly passed to the driver by GStreamer since I can see the VIDIOC_S_CTRL call. Any idea ? There is a bug in the register definitions that causes the driver to apply a wrong mask before writing the bitrate to the register. I've got a fix for this in the pipeline, sending it right now. Where can we find the register definitions ? In order to look at it before asking you :) ? Sorry, forgot to put all of you on Cc: for the [media] coda: fix encoder rate control parameter masks patch. The coda driver is in drivers/media/platform/coda, register definitions in coda_regs.h. The CODA_RATECONTROL_BITRATE_MASK is 0x7f, but it should be 0x7fff. Well, I meant, the datasheet of the CODA960 because we don't know, just by reading the coda_regs.h which register is where and does what. But it may be confidential ? JM -- 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 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
Hello.
On 12/18/2014 05:50 PM, Ben Hutchings wrote:
From: William Towle william.to...@codethink.co.uk
Move the buffer state test in the .buf_cleanup handler into
.stop_streaming so that a) the vb2_queue API is not subverted, and
b) tracking of active-state buffers via priv-queue_buf[] is handled
as early as is possible
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 36 ++
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 20dbedf..bf60074 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
[...]
@@ -533,8 +513,20 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
rcar_vin_wait_stop_streaming(priv);
for (i = 0; i vq-num_buffers; ++i)
- if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE)
+ if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE) {
+ int j;
+
+ /* Is this a buffer we have told the
+* hardware about? Update the associated
+* list, if so
+*/
+ for (j = 0; j MAX_BUFFER_NUM; j++) {
+ if (priv-queue_buf[j] == vq-bufs[i]) {
+ priv-queue_buf[j] = NULL;
+ }
Don't need {} here.
+ }
vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR);
+ }
WBR, Sergei
--
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 0/5] media: rcar_vin: Fixes for buffer management
Hello. On 12/18/2014 05:47 PM, Ben Hutchings wrote: This is a re-submission of patches previously sent and archived at http://thread.gmane.org/gmane.linux.ports.sh.devel/37184/. Will has rebased onto 3.18 and added a further patch to address Hans' review comments. The driver continues to works for single frame capture, and no longer provokes a WARNing. However, video capture has regressed (a gstreamer capture pipeline yields a zero-length file). Ben. Ian Molton (4): media: rcar_vin: Dont aggressively retire buffers media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping. media: rcar_vin: Fix race condition terminating stream media: rcar_vin: Clean up rcar_vin_irq William Towle (1): media: rcar_vin: move buffer management to .stop_streaming handler Having actual fixes and clean-ups in a single series is not a good idea... WBR, Sergei -- 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 3/5] media: rcar_vin: Fix race condition terminating stream
Hello. On 12/18/2014 05:49 PM, Ben Hutchings wrote: From: Ian Molton ian.mol...@codethink.co.uk This patch fixes a race condition whereby a frame being captured may generate an interrupt between requesting capture to halt and freeing buffers. No need for the leading space. This condition is exposed by the earlier patch that explicitly calls vb2_buffer_done() during stop streaming. Hm, perhaps for the sake of bisection, these 2 patches need to be merged? The solution is to wait for capture to finish prior to finalising these buffers. Signed-off-by: Ian Molton ian.mol...@codethink.co.uk Signed-off-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c | 43 +- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 7069176..b234e57 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c [...] @@ -465,7 +488,6 @@ static void rcar_vin_videobuf_release(struct vb2_buffer *vb) struct rcar_vin_priv *priv = ici-priv; unsigned int i; int buf_in_use = 0; - Unrelated white space change. Moreover, there should be an empty line after declarations. spin_lock_irq(priv-lock); /* Is the buffer in use by the VIN hardware? */ [...] @@ -520,12 +530,15 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq) spin_lock_irq(priv-lock); + rcar_vin_wait_stop_streaming(priv); + for (i = 0; i vq-num_buffers; ++i) if (vq-bufs[i]-state == VB2_BUF_STATE_ACTIVE) vb2_buffer_done(vq-bufs[i], VB2_BUF_STATE_ERROR); list_for_each_safe(buf_head, tmp, priv-capture) list_del_init(buf_head); + Also seems like unrelated whitespace cleanup. spin_unlock_irq(priv-lock); } WBR, Sergei -- 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
mceusb: sysfs: cannot create duplicate filename '/class/rc/rc0' (race condition between multiple RC_CORE devices)
Hi Occassionally, but not readily reproducably, I hit a race condition between mceusb and other connected RC_CORE devices when mceusb tries to create /class/rc/rc0, which is -by then- already taken by another RC_CORE device. The other involved IR devices (physically only one) are part of a PCIe TeVii s480 s2.1 twin-tuner DVB-S2 card and aren't actually supposed to receive IR signals (IR receiver not connected): mceusb device transceiver: Bus 002 Device 004: ID 0609:0334 SMK Manufacturing, Inc. eHome Infrared Receiver DVB-T receiver (no RC_CORE device) Bus 001 Device 004: ID 0ccd:0069 TerraTec Electronic GmbH Cinergy T XE (Version 2, AF9015) twin-tuner DVB-S2 PCIe device, TeVii s480 v2.1 (physically one IR receiver (NEC protocol), logically recognized as two RC_CORE devices): 04:00.0 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller 04:00.1 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller 04:00.2 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller 04:00.3 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller 04:00.4 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller 04:00.5 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller 04:00.6 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller 04:00.7 USB controller: MosChip Semiconductor Technology Ltd. MCS9990 PCIe to 4‐Port USB 2.0 Host Controller Bus 006 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 Bus 003 Device 003: ID 9022:d660 TeVii Technology Ltd. DVB-S2 S660 dmesg excerpt from kernel 3.18.1-rc1, but this already happened randomly with older kernels: [...] dvb_usb_dw2102: unknown parameter 'keymap' ignored dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' dw2102: start downloading DW210X firmware [...] usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in cold state [...] usb 1-1.5: dvb_usb_v2: downloading firmware from file 'dvb-usb-af9015.fw' usb 2-1.6: New USB device found, idVendor=0609, idProduct=0334 usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1.6: Product: MCE TRANCEIVR Emulator Device 2006 usb 2-1.6: Manufacturer: SMK CORPORATION usb 2-1.6: SerialNumber: PA070620045513C [...] usb 3-1: USB disconnect, device number 2 usb 1-1.5: dvb_usb_v2: found a 'TerraTec Cinergy T USB XE' in warm state [...] dvb-usb: found a 'TeVii S480.1 USB' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TeVii S480.1 USB) dvb-usb: MAC address: 40:40:40:40:40:40 Invalid probe, probably not a DS3000 dvb-usb: no frontend was attached by 'TeVii S480.1 USB' [...] Registered IR keymap rc-tevii-nec input:
[PATCH 1/2] regmap: pass map name to lockdep
lockdep complains recursive locking and deadlock when two different
regmap instances are called in a nested order. That happen easily
for example when both I2C client and muxed/repeater I2C adapter are
using regmap. As a solution, pass regmap name for lockdep in order
to force lockdep validate regmap mutex per driver - not as all regmap
instances grouped together.
Here is example connection, where nested regmap is used to control
I2C mux.
__ ___ ___
| USB IF | | demod | | tuner |
|--| |---| |---|
| |--I2C--|-/ |--I2C--| |
|I2C master| | I2C mux | | I2C slave |
|__| |___| |___|
Cc: Mark Brown broo...@kernel.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/base/regmap/regmap.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index d2f8a81..8d8ad37 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -559,6 +559,12 @@ struct regmap *regmap_init(struct device *dev,
mutex_init(map-mutex);
map-lock = regmap_lock_mutex;
map-unlock = regmap_unlock_mutex;
+ if (config-name) {
+ static struct lock_class_key key;
+
+ lockdep_set_class_and_name(map-mutex, key,
+ config-name);
+ }
}
map-lock_arg = map;
}
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] rtl2832: add name for RegMap
Pass module name to regmap in order to silence lockdep recursive
deadlock warning. Lockdep validator groups mutexes per mutex name by
default. Due to that tuner and demod regmap mutexes were seen as a
single mutex. Tuner register access causes demod register access,
because of I2C mux/repeater and that is seen as a recursive locking
- even those locks are different instances (tuner vs. demod).
Defining name for mutex allows lockdep to separate mutexes and error
is not shown.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index f44dc50..f41bbd0 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1187,6 +1187,7 @@ static int rtl2832_probe(struct i2c_client *client,
},
};
static const struct regmap_config regmap_config = {
+ .name = KBUILD_MODNAME,
.reg_bits= 8,
.val_bits= 8,
.volatile_reg = rtl2832_volatile_reg,
--
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] [media] uvcvideo: Add GUID for BGR 8:8:8
Hi William, On Thursday 11 December 2014 01:19:50 William Manley wrote: On 10/12/14 23:54, Laurent Pinchart wrote: On Monday 08 December 2014 18:57:58 William Manley wrote: The Magewell XI100DUSB-HDMI[1] video capture device reports the pixel format e436eb7d-524f-11ce-9f53-0020af0ba770. This is its GUID for BGR 8:8:8. The UVC 1.5 spec[2] only defines GUIDs for YUY2, NV12, M420 and I420. This seems to be an extension documented in the Microsoft Windows Media Format SDK[3] - or at least the Media Format SDK was the only hit that Google gave when searching for the GUID. This Media Format SDK defines this GUID as corresponding to `MEDIASUBTYPE_RGB24`. Note though, the XI100DUSB outputs BGR e.g. byte-reversed. I don't know if its the capture device in error or Microsoft mean BGR when they say RGB. I believe Microsoft defines RGB as BGR. They do at least in BMP (https://en.wikipedia.org/wiki/BMP_file_format), probably because they consider the RGB pixel to be stored in little-endian format. Thanks, that's helpful. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I'll apply the patch to my tree and submit it for v3.20. Great Could you please send me the output of 'lsusb -v' for your device, if possible running as root ? lsusb output attached. Thank you. I've updated the supported devices list. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regmap: pass map name to lockdep
On 12/18/2014 10:05 PM, Antti Palosaari wrote: lockdep complains recursive locking and deadlock when two different regmap instances are called in a nested order. That happen easily for example when both I2C client and muxed/repeater I2C adapter are using regmap. As a solution, pass regmap name for lockdep in order to force lockdep validate regmap mutex per driver - not as all regmap instances grouped together. That's not how it works. Locks are grouped by lock class, the name is just for pretty printing. The only reason you do not get a warning anymore is because you have now different lock classes one for configs with a name and one for configs without a name. You really need a way to specify a custom lock class per regmap instance in order to solve this problem. - Lars -- 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 v4 2/5] media: ov2640: add async probe function
Hi Josh,
Thanks for your patches!
On Thu, 18 Dec 2014, Josh Wu wrote:
To support async probe for ov2640, we need remove the code to get 'mclk'
in ov2640_probe() function. oterwise, if soc_camera host is not probed
in the moment, then we will fail to get 'mclk' and quit the ov2640_probe()
function.
So in this patch, we move such 'mclk' getting code to ov2640_s_power()
function. That make ov2640 survive, as we can pass a NULL (priv-clk) to
soc_camera_set_power() function.
And if soc_camera host is probed, the when ov2640_s_power() is called,
then we can get the 'mclk' and that make us enable/disable soc_camera
host's clock as well.
Signed-off-by: Josh Wu josh...@atmel.com
---
v3 - v4:
v2 - v3:
v1 - v2:
no changes.
drivers/media/i2c/soc_camera/ov2640.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..9ee910d 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
+ struct v4l2_clk *clk;
+
+ if (!priv-clk) {
+ clk = v4l2_clk_get(client-dev, mclk);
+ if (IS_ERR(clk))
+ dev_warn(client-dev, Cannot get the mclk. maybe
soc-camera host is not probed yet.\n);
+ else
+ priv-clk = clk;
+ }
return soc_camera_set_power(client-dev, ssdd, priv-clk, on);
}
@@ -1078,21 +1087,21 @@ static int ov2640_probe(struct i2c_client *client,
if (priv-hdl.error)
return priv-hdl.error;
- priv-clk = v4l2_clk_get(client-dev, mclk);
- if (IS_ERR(priv-clk)) {
- ret = PTR_ERR(priv-clk);
- goto eclkget;
- }
-
ret = ov2640_video_probe(client);
The first thing the above ov2640_video_probe() function will do is call
ov2640_s_power(), which will request the clock. So, by moving requesting
the clock from ov2640_probe() to ov2640_s_power() doesn't change how
probing will be performed, am I right? Or are there any other patched,
that change that, that I'm overseeing?
If I'm right, then I would propose an approach, already used in other
drivers instead of this one: return -EPROBE_DEFER if the clock isn't
available during probing. See ef6672ea35b5bb64ab42e18c1a1ffc717c31588a for
an example. Or did I misunderstand anything?
Thanks
Guennadi
if (ret) {
- v4l2_clk_put(priv-clk);
-eclkget:
- v4l2_ctrl_handler_free(priv-hdl);
+ goto evideoprobe;
} else {
dev_info(adapter-dev, OV2640 Probed\n);
}
+ ret = v4l2_async_register_subdev(priv-subdev);
+ if (ret 0)
+ goto evideoprobe;
+
+ return 0;
+
+evideoprobe:
+ v4l2_ctrl_handler_free(priv-hdl);
return ret;
}
@@ -1100,7 +1109,9 @@ static int ov2640_remove(struct i2c_client *client)
{
struct ov2640_priv *priv = to_ov2640(client);
- v4l2_clk_put(priv-clk);
+ v4l2_async_unregister_subdev(priv-subdev);
+ if (priv-clk)
+ v4l2_clk_put(priv-clk);
v4l2_device_unregister_subdev(priv-subdev);
v4l2_ctrl_handler_free(priv-hdl);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/8] v4l2-subdev: drop unused op enum_mbus_fmt
Hi Hans,
On Thu, 4 Dec 2014, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Weird, this op isn't used at all. Seems to be orphaned code.
Remove it.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/media/v4l2-subdev.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b052184..5beeb87 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -342,8 +342,6 @@ struct v4l2_subdev_video_ops {
struct v4l2_dv_timings *timings);
int (*enum_mbus_fmt)(struct v4l2_subdev *sd, unsigned int index,
u32 *code);
- int (*enum_mbus_fsizes)(struct v4l2_subdev *sd,
- struct v4l2_frmsizeenum *fsize);
After so many cheerful acks I feel a bit bluffed, but... Your subject says
drop enum_mbus_fmt and your patch drops enum_mbus_fsizes... What am I
missing??
Thanks
Guennadi
int (*g_mbus_fmt)(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *fmt);
int (*try_mbus_fmt)(struct v4l2_subdev *sd,
--
2.1.3
--
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
randconfig build error with next-20141218, in drivers/staging/media/tlg2300
Building with the attached random configuration file, ERROR: usb_kill_urb [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_deregister [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_set_interface [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_control_msg [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_free_coherent [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_submit_urb [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_get_dev [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_bulk_msg [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_put_dev [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_get_intf [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_register_driver [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_alloc_coherent [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_free_urb [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_alloc_urb [drivers/staging/media/tlg2300/poseidon.ko] undefined! ERROR: usb_put_intf [drivers/staging/media/tlg2300/poseidon.ko] undefined! # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.18.0 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y CONFIG_RCU_USER_QS=y # CONFIG_CONTEXT_TRACKING_FORCE is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
[PATCH] dtv-scan-tables: update dvb-t/au-Brisbane
From: Brian Burch br...@pingtoo.com Update dvb-t/au-Brisbane as per Brian Burch's bug report on Ubuntu Launchpad: https://bugs.launchpad.net/ubuntu/+source/dtv-scan-tables/+bug/1393280 Signed-off-by: Jonathan McCrohan jmccro...@gmail.com --- dvb-t/au-Brisbane | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dvb-t/au-Brisbane b/dvb-t/au-Brisbane index 68bc1ac..a23cb9c 100644 --- a/dvb-t/au-Brisbane +++ b/dvb-t/au-Brisbane @@ -54,7 +54,7 @@ # SBS [CHANNEL] DELIVERY_SYSTEM = DVBT - FREQUENCY = 585625000 + FREQUENCY = 18450 BANDWIDTH_HZ = 700 CODE_RATE_HP = 2/3 CODE_RATE_LP = NONE @@ -67,7 +67,7 @@ # 31 Digital [CHANNEL] DELIVERY_SYSTEM = DVBT - FREQUENCY = 59950 + FREQUENCY = 52950 BANDWIDTH_HZ = 700 CODE_RATE_HP = 2/3 CODE_RATE_LP = NONE -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Hi Jacek,
On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
Hi Tony,
Thanks for the patches.
Thanks for the review.
Please process them with scripts/checkpatch.pl as you will be submitting the
next
version - they contain many coding style related issues.
I ran checkpatch before posting. Do you find any checkpatch related issues in
the patch?
My remaining comments below.
[snip]
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS7_SWAP_CHROMA_SHIFT);
+ } else {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS4);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs,
+ ctx-subsampling,
EXYNOS4_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs,
+ ctx-out_q.fmt-fourcc,
+ EXYNOS4_SWAP_CHROMA_SHIFT);
+ }
+
I'd implement it this way:
exynos4_jpeg_set_interrupt(jpeg-regs, ctx-jpeg-variant-version);
exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_ENC_FMT_MASK :
EXYNOS7_ENC_FMT_MASK);
exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc,
(ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
EXYNOS4_SWAP_CHROMA_SHIFT :
EXYNOS7_SWAP_CHROMA_SHIFT);
OK. Looks goods to me. Thanks for the suggestion.
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
exynos4_jpeg_set_encode_hoff_cnt(jpeg-regs,
ctx-out_q.fmt-fourcc);
} else {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-cap_q.fmt-
fourcc);
- bitstream_size = DIV_ROUND_UP(ctx-out_q.size, 32);
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+ exynos4_jpeg_set_interrupt(jpeg-regs,
SJPEG_EXYNOS7);
+ exynos4_jpeg_set_huff_tbl(jpeg-regs);
+ exynos4_jpeg_set_huf_table_enable(jpeg-regs, 1);
+
+ /*
+* JPEG IP allows storing 4 quantization tables
+* We fill table 0 for luma and table 1 for chroma
+*/
+ exynos4_jpeg_set_qtbl_lum(jpeg-regs,
+ ctx-compr_quality);
+ exynos4_jpeg_set_qtbl_chr(jpeg-regs,
+ ctx-compr_quality);
Is it really required to setup quantization tables for encoding?
Without setting up the quantization tables, encoder is working fine.
But, as per Exynos7 User Manual setting up the quantization tables are required
for encoding also.
+ exynos4_jpeg_set_stream_size(jpeg-regs, ctx-
cap_q.w,
+ ctx-cap_q.h);
For exynos4 this function writes the number of samples per line and number
lines of the resulting JPEG image and is used only during encoding. Is the
semantics of the related register different in case of Exynos7?
Yes. In case of Exynos7 Encoding, This step is required.
[snip]
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -71,6 +71,7 @@
#define SJPEG_S5P 1
#define SJPEG_EXYNOS3250 2
#define SJPEG_EXYNOS4 3
+#define SJPEG_EXYNOS7 4
As you adding a new variant I propose to turn these macros into enum.
Ok. I will make this change in my next version.
[snip]
-void exynos4_jpeg_set_interrupt(void __iomem *base)
+void exynos4_jpeg_set_interrupt(void __iomem *base, unsigned int
+version)
{
- writel(EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
+ unsigned int reg;
+
+ reg = readl(base + EXYNOS4_INT_EN_REG)
~EXYNOS4_INT_EN_MASK(version);
+ writel(EXYNOS4_INT_EN_ALL(version), base + EXYNOS4_INT_EN_REG);
}
I believe that adding readl is a fix. I'd enclose it into separate patch and
explain its
merit.
Thanks for the suggestion. I will make a separate patch for this bug fix.
[snip]
--
Best Regards,
Jacek Anaszewski
Thanks,
Tony K Nadackal
--
To unsubscribe from this list:
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Dec 19 04:00:16 CET 2014 git branch: test git hash: 427ae153c65ad7a08288d86baf99000569627d03 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-3.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-x86_64: OK apps: ERRORS spec-git: OK sparse: ERRORS ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
V4L2_CID_AUTO_FOCUS_START VS V4L2_CID_FOCUS_AUTO
Hi, Can anyone explain what is the difference between setting control V4L2_CID_FOCUS_AUTO to 1 and and issuing V4L2_CID_AUTO_FOCUS_START? Confused... -- Regards, Bin -- 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: V4l2 state transition
Nicolas, On 8 December 2014 at 22:31, Nicolas Dufresne nicolas.dufre...@collabora.com wrote: Le 2014-12-08 09:29, Nicolas Dufresne a écrit : Le 2014-12-08 00:19, Bin Chen a écrit : Can anyone comment is following state transition diagram for V4l2 user space program make sense? Do you see any issues if we were to enforce this constraint? I think you should request some buffers before streamon. If in capture, you should also queue the minimum amount of buffers. I forgot, setting input and format isn't strictly required. Driver should have decent default configured. Thanks for all the explaining. Nicolas -- Regards, Bin -- 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 6/7] ARM: at91: dts: sama5d3: add ov2640 camera sensor support
Hi, Laurent
On 12/18/2014 8:32 PM, Laurent Pinchart wrote:
Hi Josh,
Thank you for the patch.
On Thursday 18 December 2014 16:51:06 Josh Wu wrote:
According to v4l2 dt document, we add:
a camera host: ISI port.
a i2c camera sensor: ov2640 port.
to sama5d3xmb.dtsi.
In the ov2640 node, it defines the pinctrls, clocks and isi port.
In the ISI node, it also reference to a ov2640 port.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/boot/dts/sama5d3xmb.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi index 0aaebc6..958a528 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -52,6 +52,29 @@
};
};
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = ovti,ov2640;
+ reg = 0x30;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_isi_pck_as_mck
pinctrl_sensor_power pinctrl_sensor_reset;
+ resetb-gpios = pioE 24
GPIO_ACTIVE_LOW;
+ pwdn-gpios = pioE 29
GPIO_ACTIVE_HIGH;
+ /* use pck1 for the master clock of
ov2640 */
+ clocks = pck1;
+ clock-names = xvclk;
+ assigned-clocks = pck1;
+ assigned-clock-rates = 2500;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint =
isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
+
usart1: serial@f002 {
dmas = 0, 0;/* Do not use DMA for
usart1 */
pinctrl-names = default;
@@ -60,6 +83,15 @@
};
isi: isi@f0034000 {
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
I would add the port node and those two properties to
arch/arm/boot/dts/sama5d3.dtsi, as the isi has a single port. The endpoint, of
course, should stay in this file.
That makes sense. I'll fix that. Thanks for the review.
Best Regards,
Josh Wu
+ isi_0: endpoint {
+ remote-endpoint = ov2640_0;
+ bus-width = 8;
+ };
+ };
};
mmc1: mmc@f800 {
--
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 v4 2/5] media: ov2640: add async probe function
Hi, Guennadi
Thanks for the review.
On 12/19/2014 5:59 AM, Guennadi Liakhovetski wrote:
Hi Josh,
Thanks for your patches!
On Thu, 18 Dec 2014, Josh Wu wrote:
To support async probe for ov2640, we need remove the code to get 'mclk'
in ov2640_probe() function. oterwise, if soc_camera host is not probed
in the moment, then we will fail to get 'mclk' and quit the ov2640_probe()
function.
So in this patch, we move such 'mclk' getting code to ov2640_s_power()
function. That make ov2640 survive, as we can pass a NULL (priv-clk) to
soc_camera_set_power() function.
And if soc_camera host is probed, the when ov2640_s_power() is called,
then we can get the 'mclk' and that make us enable/disable soc_camera
host's clock as well.
Signed-off-by: Josh Wu josh...@atmel.com
---
v3 - v4:
v2 - v3:
v1 - v2:
no changes.
drivers/media/i2c/soc_camera/ov2640.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..9ee910d 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
+ struct v4l2_clk *clk;
+
+ if (!priv-clk) {
+ clk = v4l2_clk_get(client-dev, mclk);
+ if (IS_ERR(clk))
+ dev_warn(client-dev, Cannot get the mclk. maybe
soc-camera host is not probed yet.\n);
+ else
+ priv-clk = clk;
+ }
return soc_camera_set_power(client-dev, ssdd, priv-clk, on);
}
@@ -1078,21 +1087,21 @@ static int ov2640_probe(struct i2c_client *client,
if (priv-hdl.error)
return priv-hdl.error;
- priv-clk = v4l2_clk_get(client-dev, mclk);
- if (IS_ERR(priv-clk)) {
- ret = PTR_ERR(priv-clk);
- goto eclkget;
- }
-
ret = ov2640_video_probe(client);
The first thing the above ov2640_video_probe() function will do is call
ov2640_s_power(), which will request the clock. So, by moving requesting
the clock from ov2640_probe() to ov2640_s_power() doesn't change how
probing will be performed, am I right?
yes, you are right. In this patch, the mclk will requested by
ov2640_s_power().
The reason why I put the getting mclk code from ov2640_probe() to
ov2640_s_power() is : as the mclk here is camera host's peripheral
clock. That means ov2640 still can be probed properly (read ov2640 id)
even no mclk. So when I move this code to ov2640_s_power(), otherwise
the ov2640_probe() will be failed or DEFER_PROBE.
Is this true for all camera host? If it's not true, then I think use
-EPROBE_DEFER would be a proper way.
Or are there any other patched,
that change that, that I'm overseeing?
If I'm right, then I would propose an approach, already used in other
drivers instead of this one: return -EPROBE_DEFER if the clock isn't
available during probing. See ef6672ea35b5bb64ab42e18c1a1ffc717c31588a for
an example. Or did I misunderstand anything?
Actually months ago I already done a version of ov2640 patch which use
-EPROBE_DEFER way.
But now I think the ov2640 can be probed correctly without mclk, so it
is no need to return -EPROBE_DEFER.
And the v4l2 asyn API can handle the synchronization of host. So I
prefer to use this way.
What do you think about this?
Best Regards,
Josh Wu
Thanks
Guennadi
if (ret) {
- v4l2_clk_put(priv-clk);
-eclkget:
- v4l2_ctrl_handler_free(priv-hdl);
+ goto evideoprobe;
} else {
dev_info(adapter-dev, OV2640 Probed\n);
}
+ ret = v4l2_async_register_subdev(priv-subdev);
+ if (ret 0)
+ goto evideoprobe;
+
+ return 0;
+
+evideoprobe:
+ v4l2_ctrl_handler_free(priv-hdl);
return ret;
}
@@ -1100,7 +1109,9 @@ static int ov2640_remove(struct i2c_client *client)
{
struct ov2640_priv *priv = to_ov2640(client);
- v4l2_clk_put(priv-clk);
+ v4l2_async_unregister_subdev(priv-subdev);
+ if (priv-clk)
+ v4l2_clk_put(priv-clk);
v4l2_device_unregister_subdev(priv-subdev);
v4l2_ctrl_handler_free(priv-hdl);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] [media] s5p-jpeg: Adding Exynos7 JPEG variant
Fimp_jpeg used in Exynos7 is a revised version. Some register
configurations are slightly different from JPEG in Exynos4.
Added one more variant SJPEG_EXYNOS7 to handle these differences.
Signed-off-by: Tony K Nadackal tony...@samsung.com
---
.../bindings/media/exynos-jpeg-codec.txt | 2 +-
drivers/media/platform/s5p-jpeg/jpeg-core.c| 61 ++
drivers/media/platform/s5p-jpeg/jpeg-core.h| 10 ++--
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 32 ++--
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h | 8 +--
drivers/media/platform/s5p-jpeg/jpeg-regs.h| 17 --
6 files changed, 93 insertions(+), 37 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
index bf52ed4..cd19417 100644
--- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : should be one of:
samsung,s5pv210-jpeg, samsung,exynos4210-jpeg,
- samsung,exynos3250-jpeg;
+ samsung,exynos3250-jpeg, samsung,exynos7-jpeg;
- reg : address and length of the JPEG codec IP register set;
- interrupts : specifies the JPEG codec IP interrupt;
- clock-names : should contain:
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 54fa5d9..204013e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1225,8 +1225,9 @@ static int s5p_jpeg_try_fmt_vid_cap(struct file *file,
void *priv,
return -EINVAL;
}
- if ((ctx-jpeg-variant-version != SJPEG_EXYNOS4) ||
- (ctx-mode != S5P_JPEG_DECODE))
+ if (((ctx-jpeg-variant-version != SJPEG_EXYNOS4)
+ (ctx-jpeg-variant-version != SJPEG_EXYNOS7)) ||
+ (ctx-mode != S5P_JPEG_DECODE))
goto exit;
/*
@@ -1349,7 +1350,8 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct
v4l2_format *f)
* the JPEG_IMAGE_SIZE register. In order to avoid sysmmu
* page fault calculate proper buffer size in such a case.
*/
- if (ct-jpeg-variant-version == SJPEG_EXYNOS4
+ if (((ct-jpeg-variant-version == SJPEG_EXYNOS4) ||
+ (ct-jpeg-variant-version == SJPEG_EXYNOS7))
f_type == FMT_TYPE_OUTPUT ct-mode == S5P_JPEG_ENCODE)
q_data-size = exynos4_jpeg_get_output_buffer_size(ct,
f,
@@ -1901,7 +1903,8 @@ static void exynos4_jpeg_device_run(void *priv)
if (ctx-mode == S5P_JPEG_ENCODE) {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
+ exynos4_jpeg_set_interrupt(jpeg-regs,
+ ctx-jpeg-variant-version);
exynos4_jpeg_set_huf_table_enable(jpeg-regs, 1);
exynos4_jpeg_set_huff_tbl(jpeg-regs);
@@ -1918,20 +1921,50 @@ static void exynos4_jpeg_device_run(void *priv)
exynos4_jpeg_set_stream_size(jpeg-regs, ctx-cap_q.w,
ctx-cap_q.h);
- exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc);
+ exynos4_jpeg_set_enc_out_fmt(jpeg-regs, ctx-subsampling,
+ (ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
+ EXYNOS4_ENC_FMT_MASK :
+ EXYNOS7_ENC_FMT_MASK);
+ exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-out_q.fmt-fourcc,
+ (ctx-jpeg-variant-version == SJPEG_EXYNOS4) ?
+ EXYNOS4_SWAP_CHROMA_SHIFT :
+ EXYNOS7_SWAP_CHROMA_SHIFT);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
exynos4_jpeg_set_encode_hoff_cnt(jpeg-regs,
ctx-out_q.fmt-fourcc);
} else {
exynos4_jpeg_sw_reset(jpeg-regs);
- exynos4_jpeg_set_interrupt(jpeg-regs);
+ exynos4_jpeg_set_interrupt(jpeg-regs,
+ ctx-jpeg-variant-version);
exynos4_jpeg_set_img_addr(ctx);
exynos4_jpeg_set_jpeg_addr(ctx);
- exynos4_jpeg_set_img_fmt(jpeg-regs, ctx-cap_q.fmt-fourcc);
- bitstream_size = DIV_ROUND_UP(ctx-out_q.size, 32);
+ if (ctx-jpeg-variant-version == SJPEG_EXYNOS7) {
+
[PATCH v2 1/2] [media] s5p-jpeg: Fix modification sequence of interrupt enable register
Fix the bug in modifying the interrupt enable register.
Signed-off-by: Tony K Nadackal tony...@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index e53f13a..a61ff7e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -155,7 +155,10 @@ void exynos4_jpeg_set_enc_out_fmt(void __iomem *base,
unsigned int out_fmt)
void exynos4_jpeg_set_interrupt(void __iomem *base)
{
- writel(EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
+ unsigned int reg;
+
+ reg = readl(base + EXYNOS4_INT_EN_REG) ~EXYNOS4_INT_EN_MASK;
+ writel(reg | EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
}
unsigned int exynos4_jpeg_get_int_status(void __iomem *base)
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Adding support for Exynos7 Jpeg variant
This patch series adds support for Exynos7 JPEG variant, which is mostly same as Exynos4 JPEG variants with few register configuration differences. At the same time it modifies #define based JPEG variant macros into enum. Patch 1/2 fixes possible bug in setting INT EN register, where EXYNOS4_INT_EN_REG was getting modified without reading before. Patch set v1 and related discussion can be found here [1]. [1]: http://www.spinics.net/lists/linux-samsung-soc/msg40308.html Changes since v1: - Added new patch 1/2 which fixes issues in writing EXYNOS4_INT_EN_REG. - Converted JPEG variant macros into enum as suggested by Jacek Anaszewski. Tony K Nadackal (2): [media] s5p-jpeg: Fix modification sequence of interrupt enable register [media] s5p-jpeg: Adding Exynos7 Jpeg variant .../bindings/media/exynos-jpeg-codec.txt | 2 +- drivers/media/platform/s5p-jpeg/jpeg-core.c| 61 ++ drivers/media/platform/s5p-jpeg/jpeg-core.h| 10 ++-- drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 33 +++- drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h | 8 +-- drivers/media/platform/s5p-jpeg/jpeg-regs.h| 17 -- 6 files changed, 95 insertions(+), 36 deletions(-) -- 2.2.0 -- 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
