RE: Troubleshooting problematic DVB-T reception
Hi Devin! Date: Wed, 9 Jul 2014 09:21:02 -0400 Subject: Re: Troubleshooting problematic DVB-T reception From: dheitmuel...@kernellabs.com To: luky...@hotmail.com CC: linux-media@vger.kernel.org I am trying to troubleshoot a (non-linux related) DVB-T issue and I basically want to create statistics about both DVB and MPEG framing, errors, corruption, missing frames, etc. The reason is that I believe there is a problem on the transmitting radio tower, RF is fine between the tower and me, but the actual payload (MPEG) is somehow bogus, errored or sporadically misses frames (due to backhaul problems or whatever). If I would be able to create some statistics confirming that I see all the DVB frames without any errors, but that the actual DVB payload (MPEG) has some problems, I could convince the tower guys to actually fix the issue, instead of blaming my antennas. So, can anyone suggest a tool or method to troubleshoot this issue further? tzap output for example confirms not a single BER error and the tuner keeps full LOCK on the channel while the actual stream is stuttering. I probably wouldn't rely on the BER stats from tzap. Their implementation varies in quality depending on which tuner you have, as well as how they are sampled. Almost all demods will set the TEI bit on the MPEG frame if it's determined that there was a decoding error - I would be much more inclined to look at that. Your best bet is to record the whole mux for a few minutes, then run it through some different tools to see what class of errors you are hitting. Tools such as tsreader or StreamEye will give you a better idea what's going on. Once you know what class of failure you have (e.g. TEI errors, MPEG discontinuities, etc), then you can better isolate where in the chain the failure is being introduced. Having the recording of the mux will also let you analyze in depth the actual nature of the problem, rather than trying to analyze an ever-changing stream in real-time, where signal conditions can change over time. Thanks for your advice! I agree capturing the whole mux for further analysis is the best thing todo. Thanks, Lukas -- 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] Add support for Exynos3250 SoC to s5p-mfc driver
This is second version of the patch set that adds support for MFC codec on Exynos3250 to the s5p-mfc driver (Sachin and Arun - thanks for a review). = Changes since v1: = - made SCLK an optional parameter, as not all the devices with the same MFC version require initializing the clock explicitly. - adjusted commit message of the patch extending DT documentation Thanks, Jacek Anaszewski Jacek Anaszewski (3): s5p-mfc: Fix selective sclk_mfc init ARM: dts: exynos3250 add MFC codec device node DT: s5p-mfc: Document exynos3250 SoC related settings .../devicetree/bindings/media/s5p-mfc.txt | 10 +--- arch/arm/boot/dts/exynos3250.dtsi | 11 + drivers/media/platform/s5p-mfc/s5p_mfc_pm.c| 24 3 files changed, 42 insertions(+), 3 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 v2 3/3] DT: s5p-mfc: Document exynos3250 SoC related settings
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/media/s5p-mfc.txt | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index 3e3c5f3..ee9604b 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -10,16 +10,20 @@ Required properties: - compatible : value should be either one among the following (a) samsung,mfc-v5 for MFC v5 present in Exynos4 SoCs (b) samsung,mfc-v6 for MFC v6 present in Exynos5 SoCs - (c) samsung,mfc-v7 for MFC v7 present in Exynos5420 SoC + (c) samsung,mfc-v7 for MFC v7 present in Exynos3250 and Exynos5420 SoC (d) samsung,mfc-v8 for MFC v8 present in Exynos5800 SoC - reg : Physical base address of the IP registers and length of memory mapped region. - interrupts : MFC interrupt number to the CPU. - - clocks : from common clock binding: handle to mfc clock. + - clocks : from common clock binding: handle to mfc clock and for +Exynos3250 SoC special clock gate should be defined +as the second element of the clocks array + - clock-names : from common clock binding: must contain mfc, - corresponding to entry in the clocks property. + corresponding to entry in the clocks property and + additionally sclk-mfc entry for Exynos3250 SoC - samsung,mfc-r : Base address of the first memory bank used by MFC for DMA contiguous memory allocation and its size. -- 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 v2 2/3] ARM: dts: exynos3250 add MFC codec device node
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/exynos3250.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 351871a..01bf5fa 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -283,6 +283,17 @@
status = disabled;
};
+ codec@1340 {
+ compatible = samsung,mfc-v7;
+ reg = 0x1340 0x1;
+ interrupts = 0 102 0;
+ clock-names = mfc, sclk-mfc;
+ clocks = cmu CLK_MFC, cmu CLK_SCLK_MFC;
+ #address-cells = 1;
+ #size-cells = 0;
+ samsung,power-domain = pd_mfc;
+ };
+
serial_0: serial@1380 {
compatible = samsung,exynos4210-uart;
reg = 0x1380 0x100;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] s5p-mfc: Fix selective sclk_mfc init
fc906b6d Remove special clock usage in driver removed
initialization of MFC special clock, arguing that there's
no need to do it explicitly, since it's one of MFC gate clock's
dependencies and gets enabled along with it. However, there's
no promise of keeping this hierarchy across Exynos SoC
releases, therefore this approach fails to provide a stable,
portable solution.
Out of all MFC versions, only v6 doesn't use special clock at all.
For other versions log a message only in case clk_get fails,
as not all the devices with the same MFC version require
initializing the clock explicitly.
Signed-off-by: Mateusz Zalega m.zal...@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 11d5f1d..b6a8be9 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -21,6 +21,8 @@
#include s5p_mfc_pm.h
#define MFC_GATE_CLK_NAME mfc
+#define MFC_SCLK_NAME sclk-mfc
+#define MFC_SCLK_RATE (200 * 100)
#define CLK_DEBUG
@@ -50,6 +52,20 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
goto err_p_ip_clk;
}
+ if (dev-variant-version != MFC_VERSION_V6) {
+ pm-clock = clk_get(dev-plat_dev-dev, MFC_SCLK_NAME);
+ if (IS_ERR(pm-clock)) {
+ mfc_info(Failed to get MFC special clock control\n);
+ } else {
+ clk_set_rate(pm-clock, MFC_SCLK_RATE);
+ ret = clk_prepare_enable(pm-clock);
+ if (ret) {
+ mfc_err(Failed to enable MFC special clock\n);
+ goto err_s_clk;
+ }
+ }
+ }
+
atomic_set(pm-power, 0);
#ifdef CONFIG_PM_RUNTIME
pm-device = dev-plat_dev-dev;
@@ -59,6 +75,9 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
atomic_set(clk_ref, 0);
#endif
return 0;
+
+err_s_clk:
+ clk_put(pm-clock);
err_p_ip_clk:
clk_put(pm-clock_gate);
err_g_ip_clk:
@@ -67,6 +86,11 @@ err_g_ip_clk:
void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)
{
+ if (dev-variant-version != MFC_VERSION_V6
+ pm-clock) {
+ clk_disable_unprepare(pm-clock);
+ clk_put(pm-clock);
+ }
clk_unprepare(pm-clock_gate);
clk_put(pm-clock_gate);
#ifdef CONFIG_PM_RUNTIME
--
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 v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's calling seq_printf() instead
of printk(). Can you not instead generalize print_hex_dump() and based
on it's invocation, make it call either seq_printf() or printk() ?
How do you propose doing that given any seq_foo call
requires a struct seq_file * and print_hex_dump needs
a KERN_LEVEL.
I can imagine a rather nasty way, I can't say I would like it myself tho. The
general idea would be to pull out the entire switch {} statement into a
separate
functions , one for printk() and one for seq_printf() cases. Then, have a
generic do_hex_dump() call which would take as an argument a pointer to either
of those functions and a void * to either the seq_file or level . Finally,
there
would have to be a wrapper to call the do_hex_dump() with the correct function
pointer and it's associated arg.
Nasty? Yes ... Ineffective? Most likely.
Is there an actual value to it?
Reducing the code duplication, but I wonder if there is a smarter solution than
the horrid one above.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Thu, 2014-07-10 at 09:58 +0200, Marek Vasut wrote:
On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's calling seq_printf() instead
of printk(). Can you not instead generalize print_hex_dump() and based
on it's invocation, make it call either seq_printf() or printk() ?
How do you propose doing that given any seq_foo call
requires a struct seq_file * and print_hex_dump needs
a KERN_LEVEL.
I can imagine a rather nasty way, I can't say I would like it myself tho. The
general idea would be to pull out the entire switch {} statement into a
separate
functions , one for printk() and one for seq_printf() cases. Then, have a
generic do_hex_dump() call which would take as an argument a pointer to
either
of those functions and a void * to either the seq_file or level . Finally,
there
would have to be a wrapper to call the do_hex_dump() with the correct
function
pointer and it's associated arg.
Nasty? Yes ... Ineffective? Most likely.
It looks not good idea, yeah.
Is there an actual value to it?
Reducing the code duplication, but I wonder if there is a smarter solution
than
the horrid one above.
I have considered to modify hex_dump_to_buffer() to return how many
bytes it actually proceed to the buffer. In that case we can directly
print to m-buf like other seq_foo calls do.
But I still have doubts about it. Any opinion?
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 5/5] [S390] zcrypt: use seq_hex_dump() to dump buffers
On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote:
Instead of custom approach let's use recently introduced seq_hex_dump()
helper.
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
The above paragraph is not true and will be removed in v2.
The output is kept the same as in original code.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/s390/crypto/zcrypt_api.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/s390/crypto/zcrypt_api.c
b/drivers/s390/crypto/zcrypt_api.c
index 0e18c5d..d1f9983 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -1203,16 +1203,8 @@ static void sprinthx(unsigned char *title, struct
seq_file *m,
static void sprinthx4(unsigned char *title, struct seq_file *m,
unsigned int *array, unsigned int len)
{
- int r;
-
seq_printf(m, \n%s\n, title);
- for (r = 0; r len; r++) {
- if ((r % 8) == 0)
- seq_printf(m, );
- seq_printf(m, %08X , array[r]);
- if ((r % 8) == 7)
- seq_putc(m, '\n');
- }
+ seq_hex_dump(m, , DUMP_PREFIX_NONE, 32, 4, array, len, false);
seq_putc(m, '\n');
}
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Thu, 2014-07-10 at 12:50 +0300, Andy Shevchenko wrote: I have considered to modify hex_dump_to_buffer() to return how many bytes it actually proceed to the buffer. In that case we can directly print to m-buf like other seq_foo calls do. But I still have doubts about it. Any opinion? Simpler is better. -- 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: soc_camera, rcar_vin, and adv7604
On Wed, 9 Jul 2014 22:34:07 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Maybe we dould add some support, say, to help with (fake) file handles just to aid the transition. Indeed - the filehandles are probably the biggest sticking point. I already have the soc_camera code able to select mutually acceptable data formats, but the calls to get/set resolution seem to use fh's I will persist with approach 2 then for now. -- Ian Molton ian.mol...@codethink.co.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] media: rcar_vin: Fix race condition terminating stream
On Tue, 08 Jul 2014 20:09:58 +0400 Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. Hi, 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 06ce705..aeda4e2 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c [...] @@ -462,7 +485,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); This seems like a random whitespace change. This empty should be present. Agreed. [...] @@ -517,12 +527,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 quite a random drove-by change. Agreed. Any further comments? If not, I can re-spin this ready for upstreaming. -- Ian Molton ian.mol...@codethink.co.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] si2168: implement CNR statistic
Implement CNR statistic.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/si2168.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 3a40181..d561d2c 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -141,6 +141,15 @@ static int si2168_read_status(struct dvb_frontend *fe,
fe_status_t *status)
s-fe_status = *status;
+ if (*status FE_HAS_LOCK) {
+ c-cnr.len = 1;
+ c-cnr.stat[0].scale = FE_SCALE_DECIBEL;
+ c-cnr.stat[0].svalue = cmd.args[3] * 1000 / 4;
+ } else {
+ c-cnr.len = 1;
+ c-cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ }
+
dev_dbg(s-client-dev, %s: status=%02x args=%*ph\n,
__func__, *status, cmd.rlen, cmd.args);
--
1.9.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 1/4] si2157: implement sleep
Implement sleep for power-management.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/si2157.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 271a752..3f88e53 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -89,12 +89,23 @@ static int si2157_init(struct dvb_frontend *fe)
static int si2157_sleep(struct dvb_frontend *fe)
{
struct si2157 *s = fe-tuner_priv;
+ int ret;
+ struct si2157_cmd cmd;
dev_dbg(s-client-dev, %s:\n, __func__);
s-active = false;
+ memcpy(cmd.args, \x13, 1);
+ cmd.len = 1;
+ ret = si2157_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
return 0;
+err:
+ dev_dbg(s-client-dev, %s: failed=%d\n, __func__, ret);
+ return ret;
}
static int si2157_set_params(struct dvb_frontend *fe)
--
1.9.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/4] si2168: implement sleep
Implement sleep for power-management.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/si2168.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 8637d2e..0d0545e 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -438,13 +438,6 @@ static int si2168_init(struct dvb_frontend *fe)
dev_dbg(s-client-dev, %s:\n, __func__);
- cmd.args[0] = 0x13;
- cmd.wlen = 1;
- cmd.rlen = 0;
- ret = si2168_cmd_execute(s, cmd);
- if (ret)
- goto err;
-
cmd.args[0] = 0xc0;
cmd.args[1] = 0x12;
cmd.args[2] = 0x00;
@@ -559,12 +552,24 @@ err:
static int si2168_sleep(struct dvb_frontend *fe)
{
struct si2168 *s = fe-demodulator_priv;
+ int ret;
+ struct si2168_cmd cmd;
dev_dbg(s-client-dev, %s:\n, __func__);
s-active = false;
+ memcpy(cmd.args, \x13, 1);
+ cmd.wlen = 1;
+ cmd.rlen = 0;
+ ret = si2168_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
return 0;
+err:
+ dev_dbg(s-client-dev, %s: failed=%d\n, __func__, ret);
+ return ret;
}
static int si2168_get_tune_settings(struct dvb_frontend *fe,
--
1.9.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 3/4] si2168: set cmd args using memcpy
Use memcpy for set cmd buffer in order to keep style in line with
rest of file.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/si2168.c | 48 +++-
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 0d0545e..3a40181 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -95,20 +95,17 @@ static int si2168_read_status(struct dvb_frontend *fe,
fe_status_t *status)
switch (c-delivery_system) {
case SYS_DVBT:
- cmd.args[0] = 0xa0;
- cmd.args[1] = 0x01;
+ memcpy(cmd.args, \xa0\x01, 2);
cmd.wlen = 2;
cmd.rlen = 13;
break;
case SYS_DVBC_ANNEX_A:
- cmd.args[0] = 0x90;
- cmd.args[1] = 0x01;
+ memcpy(cmd.args, \x90\x01, 2);
cmd.wlen = 2;
cmd.rlen = 9;
break;
case SYS_DVBT2:
- cmd.args[0] = 0x50;
- cmd.args[1] = 0x01;
+ memcpy(cmd.args, \x50\x01, 2);
cmd.wlen = 2;
cmd.rlen = 14;
break;
@@ -412,7 +409,7 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
- cmd.args[0] = 0x85;
+ memcpy(cmd.args, \x85, 1);
cmd.wlen = 1;
cmd.rlen = 1;
ret = si2168_cmd_execute(s, cmd);
@@ -438,54 +435,28 @@ static int si2168_init(struct dvb_frontend *fe)
dev_dbg(s-client-dev, %s:\n, __func__);
- cmd.args[0] = 0xc0;
- cmd.args[1] = 0x12;
- cmd.args[2] = 0x00;
- cmd.args[3] = 0x0c;
- cmd.args[4] = 0x00;
- cmd.args[5] = 0x0d;
- cmd.args[6] = 0x16;
- cmd.args[7] = 0x00;
- cmd.args[8] = 0x00;
- cmd.args[9] = 0x00;
- cmd.args[10] = 0x00;
- cmd.args[11] = 0x00;
- cmd.args[12] = 0x00;
+ memcpy(cmd.args,
\xc0\x12\x00\x0c\x00\x0d\x16\x00\x00\x00\x00\x00\x00, 13);
cmd.wlen = 13;
cmd.rlen = 0;
ret = si2168_cmd_execute(s, cmd);
if (ret)
goto err;
- cmd.args[0] = 0xc0;
- cmd.args[1] = 0x06;
- cmd.args[2] = 0x01;
- cmd.args[3] = 0x0f;
- cmd.args[4] = 0x00;
- cmd.args[5] = 0x20;
- cmd.args[6] = 0x20;
- cmd.args[7] = 0x01;
+ memcpy(cmd.args, \xc0\x06\x01\x0f\x00\x20\x20\x01, 8);
cmd.wlen = 8;
cmd.rlen = 1;
ret = si2168_cmd_execute(s, cmd);
if (ret)
goto err;
- cmd.args[0] = 0x02;
+ memcpy(cmd.args, \x02, 1);
cmd.wlen = 1;
cmd.rlen = 13;
ret = si2168_cmd_execute(s, cmd);
if (ret)
goto err;
- cmd.args[0] = 0x05;
- cmd.args[1] = 0x00;
- cmd.args[2] = 0xaa;
- cmd.args[3] = 0x4d;
- cmd.args[4] = 0x56;
- cmd.args[5] = 0x40;
- cmd.args[6] = 0x00;
- cmd.args[7] = 0x00;
+ memcpy(cmd.args, \x05\x00\xaa\x4d\x56\x40\x00\x00, 8);
cmd.wlen = 8;
cmd.rlen = 1;
ret = si2168_cmd_execute(s, cmd);
@@ -527,8 +498,7 @@ static int si2168_init(struct dvb_frontend *fe)
release_firmware(fw);
fw = NULL;
- cmd.args[0] = 0x01;
- cmd.args[1] = 0x01;
+ memcpy(cmd.args, \x01\x01, 2);
cmd.wlen = 2;
cmd.rlen = 1;
ret = si2168_cmd_execute(s, cmd);
--
1.9.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 1/2] m88ds3103: fix SNR reporting on 32-bit arch
There was 32-bit calculation overflow. Use div_u64.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/m88ds3103.c | 4 ++--
drivers/media/dvb-frontends/m88ds3103_priv.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/m88ds3103.c
b/drivers/media/dvb-frontends/m88ds3103.c
index 2ef8ce1..4176edf 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -879,7 +879,7 @@ static int m88ds3103_read_snr(struct dvb_frontend *fe, u16
*snr)
/* SNR(X) dB = 10 * ln(X) / ln(10) dB */
tmp = DIV_ROUND_CLOSEST(tmp, 8 * M88DS3103_SNR_ITERATIONS);
if (tmp)
- *snr = 100ul * intlog2(tmp) / intlog2(10);
+ *snr = div_u64((u64) 100 * intlog2(tmp), intlog2(10));
else
*snr = 0;
break;
@@ -908,7 +908,7 @@ static int m88ds3103_read_snr(struct dvb_frontend *fe, u16
*snr)
/* SNR(X) dB = 10 * log10(X) dB */
if (signal noise) {
tmp = signal / noise;
- *snr = 100ul * intlog10(tmp) / (1 24);
+ *snr = div_u64((u64) 100 * intlog10(tmp), (1 24));
} else {
*snr = 0;
}
diff --git a/drivers/media/dvb-frontends/m88ds3103_priv.h
b/drivers/media/dvb-frontends/m88ds3103_priv.h
index 84c3c06..e73db5c 100644
--- a/drivers/media/dvb-frontends/m88ds3103_priv.h
+++ b/drivers/media/dvb-frontends/m88ds3103_priv.h
@@ -22,6 +22,7 @@
#include dvb_math.h
#include linux/firmware.h
#include linux/i2c-mux.h
+#include linux/math64.h
#define M88DS3103_FIRMWARE dvb-demod-m88ds3103.fw
#define M88DS3103_MCLK_KHZ 96000
--
1.9.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] m88ds3103: implement BER
Implement read_ber for BER estimate.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/m88ds3103.c | 81
drivers/media/dvb-frontends/m88ds3103_priv.h | 1 +
2 files changed, 82 insertions(+)
diff --git a/drivers/media/dvb-frontends/m88ds3103.c
b/drivers/media/dvb-frontends/m88ds3103.c
index 4176edf..dfe0c2f 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -926,6 +926,86 @@ err:
return ret;
}
+static int m88ds3103_read_ber(struct dvb_frontend *fe, u32 *ber)
+{
+ struct m88ds3103_priv *priv = fe-demodulator_priv;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ int ret;
+ unsigned int utmp;
+ u8 buf[3], u8tmp;
+ dev_dbg(priv-i2c-dev, %s:\n, __func__);
+
+ switch (c-delivery_system) {
+ case SYS_DVBS:
+ ret = m88ds3103_wr_reg(priv, 0xf9, 0x04);
+ if (ret)
+ goto err;
+
+ ret = m88ds3103_rd_reg(priv, 0xf8, u8tmp);
+ if (ret)
+ goto err;
+
+ if (!(u8tmp 0x10)) {
+ u8tmp |= 0x10;
+
+ ret = m88ds3103_rd_regs(priv, 0xf6, buf, 2);
+ if (ret)
+ goto err;
+
+ priv-ber = (buf[1] 8) | (buf[0] 0);
+
+ /* restart counters */
+ ret = m88ds3103_wr_reg(priv, 0xf8, u8tmp);
+ if (ret)
+ goto err;
+ }
+ break;
+ case SYS_DVBS2:
+ ret = m88ds3103_rd_regs(priv, 0xd5, buf, 3);
+ if (ret)
+ goto err;
+
+ utmp = (buf[2] 16) | (buf[1] 8) | (buf[0] 0);
+
+ if (utmp 3000) {
+ ret = m88ds3103_rd_regs(priv, 0xf7, buf, 2);
+ if (ret)
+ goto err;
+
+ priv-ber = (buf[1] 8) | (buf[0] 0);
+
+ /* restart counters */
+ ret = m88ds3103_wr_reg(priv, 0xd1, 0x01);
+ if (ret)
+ goto err;
+
+ ret = m88ds3103_wr_reg(priv, 0xf9, 0x01);
+ if (ret)
+ goto err;
+
+ ret = m88ds3103_wr_reg(priv, 0xf9, 0x00);
+ if (ret)
+ goto err;
+
+ ret = m88ds3103_wr_reg(priv, 0xd1, 0x00);
+ if (ret)
+ goto err;
+ }
+ break;
+ default:
+ dev_dbg(priv-i2c-dev, %s: invalid delivery_system\n,
+ __func__);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ *ber = priv-ber;
+
+ return 0;
+err:
+ dev_dbg(priv-i2c-dev, %s: failed=%d\n, __func__, ret);
+ return ret;
+}
static int m88ds3103_set_tone(struct dvb_frontend *fe,
fe_sec_tone_mode_t fe_sec_tone_mode)
@@ -1284,6 +1364,7 @@ static struct dvb_frontend_ops m88ds3103_ops = {
.read_status = m88ds3103_read_status,
.read_snr = m88ds3103_read_snr,
+ .read_ber = m88ds3103_read_ber,
.diseqc_send_master_cmd = m88ds3103_diseqc_send_master_cmd,
.diseqc_send_burst = m88ds3103_diseqc_send_burst,
diff --git a/drivers/media/dvb-frontends/m88ds3103_priv.h
b/drivers/media/dvb-frontends/m88ds3103_priv.h
index e73db5c..9169fdd 100644
--- a/drivers/media/dvb-frontends/m88ds3103_priv.h
+++ b/drivers/media/dvb-frontends/m88ds3103_priv.h
@@ -35,6 +35,7 @@ struct m88ds3103_priv {
struct dvb_frontend fe;
fe_delivery_system_t delivery_system;
fe_status_t fe_status;
+ u32 ber;
bool warm; /* FW running */
struct i2c_adapter *i2c_adapter;
};
--
1.9.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 v1 3/5] crypto: qat - use seq_hex_dump() to dump buffers
On Wed, 2014-07-09 at 11:31 -0700, Tadeusz Struk wrote: On 07/09/2014 08:24 AM, Andy Shevchenko wrote: In this case it slightly changes the output, namely the four tetrads will be output on one line. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com It's ok, I can still read it. It seems I miscalculated the tetrads. It should be 8 per line, correct? In that case we could easily use 32 bytes per line and thus remove that paragraph from commit message. Acked-by: Tadeusz Struk tadeusz.st...@intel.com Thanks! -- Andy Shevchenko andriy.shevche...@intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: pvrusb2: make logging code sane
The issue was discovered by static analysis. It turns out that code is
somewhat insane, being
if (x) {...} else { if (x) {...} }
Edited it to do the only reasonable thing, which is to log the
information about the failed call. The most descriptive logging commands
set is taken from original code.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79801
Reported-by: David Binderman dcb...@hotmail.com
Signed-off-by: Andrey Utkin andrey.krieger.ut...@gmail.com
---
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index 7c280f3..1b158f1 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -951,15 +951,9 @@ static long pvr2_v4l2_ioctl(struct file *file,
if (ret 0) {
if (pvrusb2_debug PVR2_TRACE_V4LIOCTL) {
pvr2_trace(PVR2_TRACE_V4LIOCTL,
- pvr2_v4l2_do_ioctl failure, ret=%ld, ret);
- } else {
- if (pvrusb2_debug PVR2_TRACE_V4LIOCTL) {
- pvr2_trace(PVR2_TRACE_V4LIOCTL,
- pvr2_v4l2_do_ioctl failure, ret=%ld
- command was:, ret);
- v4l_printk_ioctl(pvr2_hdw_get_driver_name(hdw),
- cmd);
- }
+ pvr2_v4l2_do_ioctl failure, ret=%ld
+ command was:, ret);
+ v4l_printk_ioctl(pvr2_hdw_get_driver_name(hdw), cmd);
}
} else {
pvr2_trace(PVR2_TRACE_V4LIOCTL,
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: pvrusb2: make logging code sane
Nice. I wonder if a previous merge mechanically resulted in this. I
can't imagine deliberately writing code like that.
-Mike
Acked-by: Mike Isely is...@pobox.com
On Thu, 10 Jul 2014, Andrey Utkin wrote:
The issue was discovered by static analysis. It turns out that code is
somewhat insane, being
if (x) {...} else { if (x) {...} }
Edited it to do the only reasonable thing, which is to log the
information about the failed call. The most descriptive logging commands
set is taken from original code.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79801
Reported-by: David Binderman dcb...@hotmail.com
Signed-off-by: Andrey Utkin andrey.krieger.ut...@gmail.com
---
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index 7c280f3..1b158f1 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -951,15 +951,9 @@ static long pvr2_v4l2_ioctl(struct file *file,
if (ret 0) {
if (pvrusb2_debug PVR2_TRACE_V4LIOCTL) {
pvr2_trace(PVR2_TRACE_V4LIOCTL,
-pvr2_v4l2_do_ioctl failure, ret=%ld, ret);
- } else {
- if (pvrusb2_debug PVR2_TRACE_V4LIOCTL) {
- pvr2_trace(PVR2_TRACE_V4LIOCTL,
-pvr2_v4l2_do_ioctl failure, ret=%ld
- command was:, ret);
- v4l_printk_ioctl(pvr2_hdw_get_driver_name(hdw),
- cmd);
- }
+pvr2_v4l2_do_ioctl failure, ret=%ld
+ command was:, ret);
+ v4l_printk_ioctl(pvr2_hdw_get_driver_name(hdw), cmd);
}
} else {
pvr2_trace(PVR2_TRACE_V4LIOCTL,
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3.1 3/3] smiapp: Implement the test pattern control
Hi Sakari,
Thank you for the patch.
On Thursday 29 May 2014 18:16:54 Sakari Ailus wrote:
Add support for the V4L2_CID_TEST_PATTERN control. When the solid colour
mode is selected, additional controls become available for setting the
solid four solid colour components.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Please see below for a minor comment.
---
since v3:
- Remove redundant definition of smiapp_ctrl_ops.
- Initialise min, max and default in control creation time.
drivers/media/i2c/smiapp/smiapp-core.c | 75 +--
drivers/media/i2c/smiapp/smiapp.h | 4 ++
2 files changed, 75 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c index 446c82c..4ac7780 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
[snip]
@@ -535,6 +572,19 @@ static int smiapp_init_controls(struct smiapp_sensor
*sensor) sensor-pixel_array-ctrl_handler, smiapp_ctrl_ops,
V4L2_CID_PIXEL_RATE, 0, 0, 1, 0);
+ v4l2_ctrl_new_std_menu_items(sensor-pixel_array-ctrl_handler,
+ smiapp_ctrl_ops, V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(smiapp_test_patterns) - 1,
+ 0, 0, smiapp_test_patterns);
+
+ for (i = 0; i ARRAY_SIZE(sensor-test_data); i++)
+ sensor-test_data[i] =
+ v4l2_ctrl_new_std(
+ sensor-pixel_array-ctrl_handler,
+ smiapp_ctrl_ops, V4L2_CID_TEST_PATTERN_RED + i,
+ 0, (1 sensor-csi_format-width) - 1, 1,
+ (1 sensor-csi_format-width) - 1);
I would have used a local variable assigned to (1 sensor-csi_format-
width) - 1 outside of the loop.
+
if (sensor-pixel_array-ctrl_handler.error) {
dev_err(client-dev,
pixel array controls initialization failed (%d)\n,
--
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
Configurable Video Controller Driver
Hi, We are developing a driver for our video controller which has the particularity of being very reconfigurable. We have reached a point at which the complexity and variety of the applications we need to implement forces us to design an api/library that allows us to configure the interconnection of the different video processing units(Camera interfaces, LCD interfaces, scalers, rotators, demosaicing, dead pixel correction, etc...) from userland. The media controller api has the limitation of not being able to create links but just browsing and activating/deactivating them. If we just allowed a user to activate/deactivate links, then we would have to declare all the possible connections between the different blocks, which would make it very confusing from a userland point of view. Moreover, the interconnection constraints would have to be dealt with very generically, which would make it very difficult in the kernel too. The conclusion we have reached yet is that we have to design an API that allows us to create v4l2 subdevices that have certain capabilities(scaling,rotating, demosaicing, etc...) and then to create links between them from a userland library. I would like to know if anything like this has been implemented yet or if someone has been thinking about such an architecture before. Thanks for your inputs, Julien BERAUD -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v3 5/5] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek,
On Fri, May 09, 2014 at 09:18:55AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 05/07/2014 09:58 AM, Sakari Ailus wrote:
Hi Jacek,
On Wed, May 07, 2014 at 09:20:17AM +0200, Jacek Anaszewski wrote:
On 05/06/2014 11:10 AM, Sakari Ailus wrote:
Hi Jacek,
On Tue, May 06, 2014 at 08:44:41AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 05/02/2014 01:06 PM, Sakari Ailus wrote:
[...]
+static inline enum led_brightness
v4l2_flash_intensity_to_led_brightness(
+ struct led_ctrl *config,
+ u32 intensity)
Fits on a single line.
+{
+ return intensity / config-step;
Shouldn't you first decrement the minimum before the division?
Brightness level 0 means that led is off. Let's consider following
case:
intensity - 15625
config-step - 15625
intensity / config-step = 1 (the lowest possible current level)
In V4L2 controls the minimum is not off, and zero might not be a
possible
value since minimum isn't divisible by step.
I wonder how to best take that into account.
I've assumed that in MODE_TORCH a led is always on. Switching
the mode to MODE_FLASH or MODE_OFF turns the led off.
This way we avoid the problem with converting 0 uA value to
led_brightness, as available torch brightness levels start from
the minimum current level value and turning the led off is
accomplished on transition to MODE_OFF or MODE_FLASH, by
calling brightness_set op with led_brightness = 0.
I'm not sure if we understood the issue the same way. My concern was
that if
the intensity isn't a multiple of step (but intensity - min is), the
above
formula won't return a valid result (unless I miss something).
Please note that v4l2_flash_intensity_to_led_brightness is called only
from s_ctrl callback, and thus it expects to get the intensity aligned
to the step value, so it will always be a multiple of step.
Is it possible that s_ctrl callback would be passed a non-aligned
control value?
In a nutshell: value - min is aligned but value is not. Please see
validate_new() in drivers/media/v4l2-core/v4l2-ctrls.c .
Still, to my mind, value is aligned.
Below I execute the calculation steps one by one
according to the V4L2_CTRL_TYPE_INTEGER case in the
validate_new function:
c-value = 35000
val = c-value + step / 2; // 35000 + 15625 / 2 = 42812
val = clamp(val, min, max); // val = 42812
offset = val - min; // 42812 - 15625 = 27187
offset = step * (offset / step); // 15625 * (27187 / 15625) = 15625
c-value = min + offset; // 15625 + 15625 = 31250
Value is aligned to the nearest step.
Please spot any discrepancies in my way of thinking if there
are any :)
min is aligned to step above. This is not necessarily the case. And if min
is not aligned, neither is value.
Thanks for spotting this. Below are improved versions of the conversion
functions. Please let me know if you have any comments.
static inline
enum led_brightnessv4l2_flash_intensity_to_led_brightness(
struct led_ctrl *config,
u32 intensity)
{
return ((intensity - config-min) / config-step) + 1;
}
static inline
u32 v4l2_flash_led_brightness_to_intensity(
struct led_ctrl *config,
enum led_brightness brightness)
{
return ((brightness - 1) * config-step) + config-min;
V4L2 control integer values are signed, thus s32 instead of u32. Otherwise
looks good to me.
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] solo6x10: expose encoder quantization setting as V4L2 control
On Tue, 8 Jul 2014 18:23:32 +0300 Andrey Utkin andrey.ut...@corp.bluecherry.net wrote: solo6*10 boards have configurable quantization parameter which takes values from 0 to 31, inclusively. This change enables setting it with ioctl VIDIOC_S_CTRL with id V4L2_CID_MPEG_VIDEO_H264_MIN_QP. Signed-off-by: Andrey Utkin andrey.ut...@corp.bluecherry.net --- drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c index b8ff113..bf6eb06 100644 --- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c +++ b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c @@ -,6 +,9 @@ static int solo_s_ctrl(struct v4l2_ctrl *ctrl) case V4L2_CID_MPEG_VIDEO_GOP_SIZE: solo_enc-gop = ctrl-val; return 0; + case V4L2_CID_MPEG_VIDEO_H264_MIN_QP: + solo_enc-qp = ctrl-val; + return 0; case V4L2_CID_MOTION_THRESHOLD: solo_enc-motion_thresh = ctrl-val; if (!solo_enc-motion_global || !solo_enc-motion_enabled) @@ -1260,6 +1263,8 @@ static struct solo_enc_dev *solo_enc_alloc(struct solo_dev *solo_dev, V4L2_CID_SHARPNESS, 0, 15, 1, 0); v4l2_ctrl_new_std(hdl, solo_ctrl_ops, V4L2_CID_MPEG_VIDEO_GOP_SIZE, 1, 255, 1, solo_dev-fps); + v4l2_ctrl_new_std(hdl, solo_ctrl_ops, + V4L2_CID_MPEG_VIDEO_H264_MIN_QP, 0, 31, 1, SOLO_DEFAULT_QP); v4l2_ctrl_new_custom(hdl, solo_motion_threshold_ctrl, NULL); v4l2_ctrl_new_custom(hdl, solo_motion_enable_ctrl, NULL); v4l2_ctrl_new_custom(hdl, solo_osd_text_ctrl, NULL); Signed-off-by: Ismael Luceno ismael.luc...@corp.bluecherry.net signature.asc Description: PGP signature
Re: [PATCH 2/2] solo6x10: update GOP size, QP immediately
On Tue, 8 Jul 2014 18:23:33 +0300 Andrey Utkin andrey.ut...@corp.bluecherry.net wrote: Previously, it was needed to reopen device to update GOP size and quantization parameter. Now we update device registers with new values immediately. Signed-off-by: Andrey Utkin andrey.ut...@corp.bluecherry.net --- drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c index bf6eb06..14f933f 100644 --- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c +++ b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c @@ -1110,9 +1110,13 @@ static int solo_s_ctrl(struct v4l2_ctrl *ctrl) ctrl-val); case V4L2_CID_MPEG_VIDEO_GOP_SIZE: solo_enc-gop = ctrl-val; + solo_reg_write(solo_dev, SOLO_VE_CH_GOP(solo_enc-ch), solo_enc-gop); + solo_reg_write(solo_dev, SOLO_VE_CH_GOP_E(solo_enc-ch), solo_enc-gop); return 0; case V4L2_CID_MPEG_VIDEO_H264_MIN_QP: solo_enc-qp = ctrl-val; + solo_reg_write(solo_dev, SOLO_VE_CH_QP(solo_enc-ch), solo_enc-qp); + solo_reg_write(solo_dev, SOLO_VE_CH_QP_E(solo_enc-ch), solo_enc-qp); return 0; case V4L2_CID_MOTION_THRESHOLD: solo_enc-motion_thresh = ctrl-val; Signed-off-by: Ismael Luceno ismael.luc...@corp.bluecherry.net signature.asc Description: PGP signature
Re: [PATCH] [media] staging/solo6x10: SOLO6X10 should select BITREVERSE
On Sun, 6 Jul 2014 10:58:41 +0200 Geert Uytterhoeven ge...@linux-m68k.org wrote: If CONFIG_SOLO6X10=y, but CONFIG_BITREVERSE=m: drivers/built-in.o: In function `solo_osd_print': (.text+0x1c7a1f): undefined reference to `byte_rev_table' make: *** [vmlinux] Error 1 Reported-by: kbuild test robot fengguang...@intel.com Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/staging/media/solo6x10/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig index 6a1906fa1117..1ce2819efcb4 100644 --- a/drivers/staging/media/solo6x10/Kconfig +++ b/drivers/staging/media/solo6x10/Kconfig @@ -1,6 +1,7 @@ config SOLO6X10 tristate Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264) depends on PCI VIDEO_DEV SND I2C + select BITREVERSE select FONT_SUPPORT select FONT_8x16 select VIDEOBUF2_DMA_SG Signed-off-by: Ismael Luceno ismael.luc...@corp.bluecherry.net signature.asc Description: PGP signature
cron job: media_tree daily build: OK
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 Jul 11 04:00:21 CEST 2014 git branch: test git hash: 3c0d394ea7022bb9666d9df97a5776c4bcc3045c gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-14-gf11dd94 host hardware: x86_64 host os:3.14-5.slh.5-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.31.14-i686: 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-rc1-i686: OK linux-2.6.31.14-x86_64: 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-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS 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
