date:20160528

cron job: media_tree daily build: OK

2016-05-28 Thread Hans Verkuil

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:   Sun May 29 04:00:24 CEST 2016
git branch: test
git hash:   bc2b80ee3490651904f121eac1c8fb7652d48253
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.5.0-264

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-bf561: 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.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.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: 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.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

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

Trustee :

2016-05-28 Thread FDF

You have been selected as one of our trustee,By Foundation De France Charity 
Works.Contact us for more details.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] dt-bindings: Update Renesas R-Car FCP DT binding

2016-05-28 Thread Geert Uytterhoeven

Hi Kieran,

On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham  wrote:
> The FCP driver, can also support the FCPF variant for FDP1 compatible
> processing.
>
> Signed-off-by: Kieran Bingham 

Thanks for your patch!

> ---
>  Documentation/devicetree/bindings/media/renesas,fcp.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> Cc: devicet...@vger.kernel.org
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt 
> b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> index 6a12960609d8..1c0718b501ef 100644
> --- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> @@ -7,11 +7,12 @@ conversion of AXI transactions in order to reduce the 
> memory bandwidth.
>
>  There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and 
> FCP
>  for FDP (FCPF). Their configuration and behaviour depend on the module they
> -are paired with. These DT bindings currently support the FCPV only.
> +are paired with. These DT bindings currently support the FCPV and FCPF.
>
>   - compatible: Must be one or more of the following
>
> - "renesas,r8a7795-fcpv" for R8A7795 (R-Car H3) compatible 'FCP for VSP'
> +   - "renesas,r8a7795-fcpf" for R8A7795 (R-Car H3) compatible 'FCP for FDP'
> - "renesas,fcpv" for generic compatible 'FCP for VSP'

I guess checkpatch complained about your dtsi additions because you forgot
to add  "renesas,fcpf" here?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] dt-bindings: Document Renesas R-Car FCP power-domains usage

2016-05-28 Thread Geert Uytterhoeven

Hi Kieran,

On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham  wrote:
> The example misses the power-domains usage, and documentation that the
> property is used by the node.
>
> Signed-off-by: Kieran Bingham 

Thanks for your patch!

> ---
>  Documentation/devicetree/bindings/media/renesas,fcp.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt 
> b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> index 1c0718b501ef..464bb7ae4b92 100644
> --- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> @@ -21,6 +21,8 @@ are paired with. These DT bindings currently support the 
> FCPV and FCPF.
>
>   - reg: the register base and size for the device registers
>   - clocks: Reference to the functional clock
> + - power-domains : power-domain property defined with a phandle
> +   to respective power domain.

I'd write "power domain specifier" instead of "phandle". While SYSC on R-Car
Gen3 uses #power-domain-cells = 0, the FCP module may show up on another
SoC that uses a different value, needing more than just a phandle.

In fact I'm inclined to leave out the power-domains property completely:
it's not a feature of the FCP, but of the SoC the FCP is part of.
power-domains properties may appear in any device node where needed.

>  Device node example
> @@ -30,4 +32,5 @@ Device node example
> compatible = "renesas,r8a7795-fcpv", "renesas,fcpv";
> reg = <0 0xfea2f000 0 0x200>;
> clocks = < CPG_MOD 602>;
> +   power-domains = < R8A7795_PD_A3VP>;

Adding it to the example doesn't hurt, though.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] saa7164: Replace if and BUG with BUG_ON

2016-05-28 Thread Amitoj Kaur Chawla

Replace if condition and BUG() with a BUG_ON having the conditional
expression of the if statement as argument.

The Coccinelle semantic patch used to make this change is as follows:
@@ expression E,f; @@

(
  if (<+... f(...) ...+>) { BUG(); }
|
- if (E) { BUG(); }
+ BUG_ON(E);
)

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/media/pci/saa7164/saa7164-encoder.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/pci/saa7164/saa7164-encoder.c 
b/drivers/media/pci/saa7164/saa7164-encoder.c
index 1b184c3..32a353d 100644
--- a/drivers/media/pci/saa7164/saa7164-encoder.c
+++ b/drivers/media/pci/saa7164/saa7164-encoder.c
@@ -1022,8 +1022,7 @@ int saa7164_encoder_register(struct saa7164_port *port)
 
dprintk(DBGLVL_ENC, "%s()\n", __func__);
 
-   if (port->type != SAA7164_MPEG_ENCODER)
-   BUG();
+   BUG_ON(port->type != SAA7164_MPEG_ENCODER);
 
/* Sanity check that the PCI configuration space is active */
if (port->hwcfg.BARLocation == 0) {
@@ -1151,8 +1150,7 @@ void saa7164_encoder_unregister(struct saa7164_port *port)
 
dprintk(DBGLVL_ENC, "%s(port=%d)\n", __func__, port->nr);
 
-   if (port->type != SAA7164_MPEG_ENCODER)
-   BUG();
+   BUG_ON(port->type != SAA7164_MPEG_ENCODER);
 
if (port->v4l_device) {
if (port->v4l_device->minor != -1)
-- 
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: netup_unidvb CI problem

2016-05-28 Thread Saso Slavicic

Another bug in the driver.
According to Netup 2014 drivers, the attributes should be read from _config
not _io

--- drivers/media/pci/netup_unidvb/netup_unidvb_ci.c.orig   2016-05-28
17:16:07.073608043 +0200
+++ drivers/media/pci/netup_unidvb/netup_unidvb_ci.c2016-05-28
17:16:33.970418997 +0200
@@ -147,7 +147,7 @@
 {
struct netup_ci_state *state = en50221->data;
struct netup_unidvb_dev *dev = state->dev;
-   u8 val = *((u8 __force *)state->membase8_io + addr);
+   u8 val = *((u8 __force *)state->membase8_config + addr);
 
dev_dbg(>pci_dev->dev,
"%s(): addr=0x%x val=0x%x\n", __func__, addr, val);
@@ -162,7 +162,7 @@
 
dev_dbg(>pci_dev->dev,
"%s(): addr=0x%x data=0x%x\n", __func__, addr, data);
-   *((u8 __force *)state->membase8_io + addr) = data;
+   *((u8 __force *)state->membase8_config + addr) = data;
return 0;
 }


# rmmod netup_unidvb
# insmod netup-unidvb-vanilla.ko
# dmesg | grep dvb_ca
[ 3997.014209] dvb_ca adapter 1: Invalid PC card inserted :(
[ 3997.691264] dvb_ca adapter 0: Invalid PC card inserted :(
# rmmod netup-unidvb
# insmod netup-unidvb-patched.ko
# dmesg | grep dvb_ca
[ 4030.205352] dvb_ca adapter 1: DVB CAM detected and initialised
successfully
[ 4030.476391] dvb_ca adapter 0: DVB CAM detected and initialised
successfully

Cheers,
Saso Slavicic

--
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: ascot2e.c off by one bug

2016-05-28 Thread Antti Palosaari


Convert it to regmap at the same (just a hint...)

On 05/28/2016 12:28 PM, Saso Slavicic wrote:

Hi,

Tuning a card with Sony ASCOT2E produces the following error:

kernel: i2c i2c-9: wr reg=0006: len=11 is too big!

MAX_WRITE_REGSIZE is defined as 10, buf[MAX_WRITE_REGSIZE + 1] buffer is
used in ascot2e_write_regs().

The problem is that exactly 10 bytes are written in ascot2e_set_params():

/* Set BW_OFFSET (0x0F) value from parameter table */
data[9] = ascot2e_sett[tv_system].bw_offset;
ascot2e_write_regs(priv, 0x06, data, 10);

The test in write_regs is as follows:

if (len + 1 >= sizeof(buf))

10 + 1 = 11 and that would be exactly the size of buf. Since 10 bytes +
buf[0] = reg would seem to fit into buf[], this shouldn't be an error.

The following patch fixes the problem for me, I have tested the card and it
seems to be working fine.

---
 drivers/media/dvb-frontends/ascot2e.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c
b/drivers/media/dvb-frontends/ascot2e.c
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -132,7 +132,7 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
}
};

-   if (len + 1 >= sizeof(buf)) {
+   if (len + 1 > sizeof(buf)) {
dev_warn(>i2c->dev,"wr reg=%04x: len=%d is too
big!\n",
 reg, len + 1);
return -E2BIG;

Regards,
Saso Slavicic


--
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



--
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

netup_unidvb CI problem

2016-05-28 Thread Saso Slavicic

Hi,

I have a problem with CI slots on NetUP Dual DVB Universal CI card.  Running
kernel-ml 4.4 on Centos 7 produces the following error:

[765846.415719] netup_unidvb :11:00.0: DVB init done, num=1
[765846.415721] dvb_ca_en50221_init
[765846.415804] DVB: register adapter0/ca0 @ minor: 24 (0x18)
[765846.415893] netup_unidvb :11:00.0: netup_unidvb_ci_register(): CI
adapter 0 init done
[765846.415895] dvb_ca_en50221_thread
[765846.415901] dvb_ca_en50221_init
[765846.416081] DVB: register adapter1/ca0 @ minor: 25 (0x19)
[765846.417708] netup_unidvb :11:00.0: netup_unidvb_ci_register(): CI
adapter 1 init done
[765846.417710] dvb_ca_en50221_thread
[765846.417719] netup_unidvb :11:00.0: netup_unidvb_dma_init(): starting
DMA0
[765846.417727] netup_unidvb :11:00.0: netup_unidvb_dma_init(): DMA0
buffer virt/phys 0x880073f0/0x73f0 size 192512
[765847.417870] netup_unidvb :11:00.0: netup_unidvb_dma_init(): starting
DMA1
[765847.417878] netup_unidvb :11:00.0: netup_unidvb_dma_init(): DMA1
buffer virt/phys 0x880073f2f000/0x73f2f000 size 192512
[765848.418819] netup_unidvb:netup_unidvb_dma_enable:190: netup_unidvb
:11:00.0: netup_unidvb_dma_enable(): DMA0 enable 0
[765848.418827] netup_unidvb:netup_unidvb_dma_enable:190: netup_unidvb
:11:00.0: netup_unidvb_dma_enable(): DMA1 enable 0
[765848.418831] netup_unidvb :11:00.0: netup_unidvb: device has been
initialized
[765851.415671] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765851.415682] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765851.415691] netup_unidvb:netup_unidvb_ci_slot_reset:100: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): CAM_CTRLSTAT_READ_SET=0x1a1a
[765851.415695] netup_unidvb:netup_unidvb_ci_slot_reset:105: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): waiting for reset
[765851.416651] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a0e
[765851.416662] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a0e
[765851.416671] netup_unidvb:netup_unidvb_ci_slot_reset:100: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): CAM_CTRLSTAT_READ_SET=0x1a0e
[765851.416675] netup_unidvb:netup_unidvb_ci_slot_reset:105: netup_unidvb
:11:00.0: netup_unidvb_ci_slot_reset(): waiting for reset
[765851.536622] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.536631] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x0
val=0x4
[765851.536636] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x2
val=0x0
[765851.536638] TUPLE type:0x4 length:0
[765851.536642] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.536645] dvb_ca adapter 1: Invalid PC card inserted :(
[765851.636603] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.736601] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.836599] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765851.936590] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765852.036583] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a8a
[765852.136611] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765852.210627] netup_unidvb:netup_unidvb_poll_ci_slot_status:132:
netup_unidvb :11:00.0: netup_unidvb_poll_ci_slot_status():
CAM_CTRLSTAT_READ_SET=0x1a1a
[765852.210635] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x0
val=0x1d
[765852.210640] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x2
val=0x0
[765852.210641] TUPLE type:0x1d length:0
[765852.210646] netup_unidvb:netup_unidvb_ci_read_attribute_mem:153:
netup_unidvb :11:00.0: netup_unidvb_ci_read_attribute_mem(): addr=0x4
val=0x0
[765852.210650]

ascot2e.c off by one bug

2016-05-28 Thread Saso Slavicic

Hi,

Tuning a card with Sony ASCOT2E produces the following error:

kernel: i2c i2c-9: wr reg=0006: len=11 is too big!

MAX_WRITE_REGSIZE is defined as 10, buf[MAX_WRITE_REGSIZE + 1] buffer is
used in ascot2e_write_regs().

The problem is that exactly 10 bytes are written in ascot2e_set_params():

/* Set BW_OFFSET (0x0F) value from parameter table */
data[9] = ascot2e_sett[tv_system].bw_offset;
ascot2e_write_regs(priv, 0x06, data, 10);

The test in write_regs is as follows:

if (len + 1 >= sizeof(buf))

10 + 1 = 11 and that would be exactly the size of buf. Since 10 bytes +
buf[0] = reg would seem to fit into buf[], this shouldn't be an error.

The following patch fixes the problem for me, I have tested the card and it
seems to be working fine.

---
 drivers/media/dvb-frontends/ascot2e.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c
b/drivers/media/dvb-frontends/ascot2e.c
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -132,7 +132,7 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
}
};
 
-   if (len + 1 >= sizeof(buf)) {
+   if (len + 1 > sizeof(buf)) {
dev_warn(>i2c->dev,"wr reg=%04x: len=%d is too
big!\n",
 reg, len + 1);
return -E2BIG;

Regards,
Saso Slavicic


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: OK

Trustee :

Re: [PATCH 2/4] dt-bindings: Update Renesas R-Car FCP DT binding

Re: [PATCH 3/4] dt-bindings: Document Renesas R-Car FCP power-domains usage

[PATCH] saa7164: Replace if and BUG with BUG_ON

RE: netup_unidvb CI problem

Re: ascot2e.c off by one bug

netup_unidvb CI problem

ascot2e.c off by one bug

9 matches

Site Navigation

Mail list logo

Footer information