cron job: media_tree daily build: WARNINGS

2016-07-26 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:   Wed Jul 27 04:00:25 CEST 2016
git branch: test
git hash:   009a620848218d521f008141c62f56bf19294dd9
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.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.23-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0-i686: WARNINGS
linux-4.1.1-i686: WARNINGS
linux-4.2-i686: WARNINGS
linux-4.3-i686: WARNINGS
linux-4.4-i686: WARNINGS
linux-4.5-i686: WARNINGS
linux-4.6-i686: WARNINGS
linux-4.7-rc1-i686: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.23-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0-x86_64: WARNINGS
linux-4.1.1-x86_64: WARNINGS
linux-4.2-x86_64: WARNINGS
linux-4.3-x86_64: WARNINGS
linux-4.4-x86_64: WARNINGS
linux-4.5-x86_64: WARNINGS
linux-4.6-x86_64: WARNINGS
linux-4.7-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.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

Re: [PATCH v2 2/4] dt-bindings: Add a binding for Mediatek MDP

2016-07-26 Thread Minghsiu Tsai 
On Tue, 2016-07-26 at 13:54 -0500, Rob Herring wrote:
> On Fri, Jul 22, 2016 at 04:33:01PM +0800, Minghsiu Tsai wrote:
> > Add a DT binding documentation of MDP for the MT8173 SoC
> > from Mediatek
> > 
> > Signed-off-by: Minghsiu Tsai 
> > ---
> >  .../devicetree/bindings/media/mediatek-mdp.txt |   96 
> > 
> >  1 file changed, 96 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> > b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > new file mode 100644
> > index 000..2dad031
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -0,0 +1,96 @@
> > +* Mediatek Media Data Path
> > +
> > +Media Data Path is used for scaling and color space conversion.
> > +
> > +Required properties (all function blocks):
> > +- compatible: "mediatek,-mdp"
> 
> What is this, ...
> 

It is used to match platform driver.


> > +"mediatek,-mdp-", one of
> 
> and this?
> 

It is string format of HW block.  could be "mt8173", and
 are "rdma", "rsz", "wdma", and "wrot".  


> > +"mediatek,-mdp-rdma"  - read DMA
> > +"mediatek,-mdp-rsz"   - resizer
> > +"mediatek,-mdp-wdma"  - write DMA
> > +"mediatek,-mdp-wrot"  - write DMA with rotation
> 
> List what are valid values of .
> 

 - mt8173. There should be other chip added in future.
I will change the property as blow:

- compatible: "mediatek,-mdp"
Should be one of
"mediatek,-mdp-rdma"  - read DMA
"mediatek,-mdp-rsz"   - resizer
"mediatek,-mdp-wdma"  - write DMA
"mediatek,-mdp-wrot"  - write DMA with rotation
 - could be 8173


If don't need , I also can change it as below. It is more clear.
- compatible: "mediatek,mt8173-mdp"
Should be one of
"mediatek,mt8173-mdp-rdma"  - read DMA
"mediatek,mt8173-mdp-rsz"   - resizer
"mediatek,mt8173-mdp-wdma"  - write DMA
"mediatek,mt8173-mdp-wrot"  - write DMA with rotation


> > +- reg: Physical base address and length of the function block register 
> > space
> > +- clocks: device clocks
> > +- power-domains: a phandle to the power domain.
> > +- mediatek,vpu: the node of video processor unit
> > +
> > +Required properties (DMA function blocks):
> > +- compatible: Should be one of
> > +"mediatek,-mdp-rdma"
> > +"mediatek,-mdp-wdma"
> > +"mediatek,-mdp-wrot"
> > +- iommus: should point to the respective IOMMU block with master port as
> > +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > +  for details.
> > +- mediatek,larb: must contain the local arbiters in the current Socs.
> 
> It is still not clear which properties apply to which compatible 
> strings.
> 

I found out the document for larb. 
I will change the property as below:

- mediatek,larb: must contain the local arbiters in the current Socs,
see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt 
  for details.


> > +
> > +Example:
> > +   mdp_rdma0: rdma@14001000 {
> > +   compatible = "mediatek,mt8173-mdp-rdma",
> > +"mediatek,mt8173-mdp";
> > +   reg = <0 0x14001000 0 0x1000>;
> > +   clocks = < CLK_MM_MDP_RDMA0>,
> > +< CLK_MM_MUTEX_32K>;
> > +   power-domains = < MT8173_POWER_DOMAIN_MM>;
> > +   iommus = < M4U_PORT_MDP_RDMA0>;
> > +   mediatek,larb = <>;
> > +   mediatek,vpu = <>;
> > +   };
> > +
> > +   mdp_rdma1: rdma@14002000 {
> > +   compatible = "mediatek,mt8173-mdp-rdma";
> > +   reg = <0 0x14002000 0 0x1000>;
> > +   clocks = < CLK_MM_MDP_RDMA1>,
> > +< CLK_MM_MUTEX_32K>;
> > +   power-domains = < MT8173_POWER_DOMAIN_MM>;
> > +   iommus = < M4U_PORT_MDP_RDMA1>;
> > +   mediatek,larb = <>;
> > +   };
> > +
> > +   mdp_rsz0: rsz@14003000 {
> > +   compatible = "mediatek,mt8173-mdp-rsz";
> > +   reg = <0 0x14003000 0 0x1000>;
> > +   clocks = < CLK_MM_MDP_RSZ0>;
> > +   power-domains = < MT8173_POWER_DOMAIN_MM>;
> > +   };
> > +
> > +   mdp_rsz1: rsz@14004000 {
> > +   compatible = "mediatek,mt8173-mdp-rsz";
> > +   reg = <0 0x14004000 0 0x1000>;
> > +   clocks = < CLK_MM_MDP_RSZ1>;
> > +   power-domains = < MT8173_POWER_DOMAIN_MM>;
> > +   };
> > +
> > +   mdp_rsz2: rsz@14005000 {
> > +   compatible = "mediatek,mt8173-mdp-rsz";
> > +   reg = <0 0x14005000 0 0x1000>;
> > +   clocks = < CLK_MM_MDP_RSZ2>;
> > +   power-domains = < MT8173_POWER_DOMAIN_MM>;
> > +   };
> > +
> > +   mdp_wdma0: wdma@14006000 {
> > +   compatible = "mediatek,mt8173-mdp-wdma";
> > +   reg = <0 0x14006000 0 0x1000>;
> > +   clocks = < CLK_MM_MDP_WDMA>;
> > +   power-domains = <

Avermedia TD310

2016-07-26 Thread Axel Rometsch 
Hi,

would it be possible to add support for the Avermedia TD310 USB TV 
Dongle? It is a combined DVB-C, DVB-T and DVB-T2 device that supports 
HEVC.

lsusb
ID 07ca:1871 AVerMedia Technologies, Inc. 

lsusb -v 
Bus 002 Device 003: ID 07ca:1871 AVerMedia Technologies, Inc. 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x07ca AVerMedia Technologies, Inc.
  idProduct  0x1871 
  bcdDevice1.00
  iManufacturer   1 
  iProduct2 
  iSerial 3 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   46
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0

Please let me know, if you need further informations

thank you

Axel

--
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 2/4] dt-bindings: Add a binding for Mediatek MDP

2016-07-26 Thread Rob Herring 
On Fri, Jul 22, 2016 at 04:33:01PM +0800, Minghsiu Tsai wrote:
> Add a DT binding documentation of MDP for the MT8173 SoC
> from Mediatek
> 
> Signed-off-by: Minghsiu Tsai 
> ---
>  .../devicetree/bindings/media/mediatek-mdp.txt |   96 
> 
>  1 file changed, 96 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> new file mode 100644
> index 000..2dad031
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> @@ -0,0 +1,96 @@
> +* Mediatek Media Data Path
> +
> +Media Data Path is used for scaling and color space conversion.
> +
> +Required properties (all function blocks):
> +- compatible: "mediatek,-mdp"

What is this, ...

> +"mediatek,-mdp-", one of

and this?

> +"mediatek,-mdp-rdma"  - read DMA
> +"mediatek,-mdp-rsz"   - resizer
> +"mediatek,-mdp-wdma"  - write DMA
> +"mediatek,-mdp-wrot"  - write DMA with rotation

List what are valid values of .

> +- reg: Physical base address and length of the function block register space
> +- clocks: device clocks
> +- power-domains: a phandle to the power domain.
> +- mediatek,vpu: the node of video processor unit
> +
> +Required properties (DMA function blocks):
> +- compatible: Should be one of
> +"mediatek,-mdp-rdma"
> +"mediatek,-mdp-wdma"
> +"mediatek,-mdp-wrot"
> +- iommus: should point to the respective IOMMU block with master port as
> +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +  for details.
> +- mediatek,larb: must contain the local arbiters in the current Socs.

It is still not clear which properties apply to which compatible 
strings.

> +
> +Example:
> + mdp_rdma0: rdma@14001000 {
> + compatible = "mediatek,mt8173-mdp-rdma",
> +  "mediatek,mt8173-mdp";
> + reg = <0 0x14001000 0 0x1000>;
> + clocks = < CLK_MM_MDP_RDMA0>,
> +  < CLK_MM_MUTEX_32K>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + iommus = < M4U_PORT_MDP_RDMA0>;
> + mediatek,larb = <>;
> + mediatek,vpu = <>;
> + };
> +
> + mdp_rdma1: rdma@14002000 {
> + compatible = "mediatek,mt8173-mdp-rdma";
> + reg = <0 0x14002000 0 0x1000>;
> + clocks = < CLK_MM_MDP_RDMA1>,
> +  < CLK_MM_MUTEX_32K>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + iommus = < M4U_PORT_MDP_RDMA1>;
> + mediatek,larb = <>;
> + };
> +
> + mdp_rsz0: rsz@14003000 {
> + compatible = "mediatek,mt8173-mdp-rsz";
> + reg = <0 0x14003000 0 0x1000>;
> + clocks = < CLK_MM_MDP_RSZ0>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + };
> +
> + mdp_rsz1: rsz@14004000 {
> + compatible = "mediatek,mt8173-mdp-rsz";
> + reg = <0 0x14004000 0 0x1000>;
> + clocks = < CLK_MM_MDP_RSZ1>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + };
> +
> + mdp_rsz2: rsz@14005000 {
> + compatible = "mediatek,mt8173-mdp-rsz";
> + reg = <0 0x14005000 0 0x1000>;
> + clocks = < CLK_MM_MDP_RSZ2>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + };
> +
> + mdp_wdma0: wdma@14006000 {
> + compatible = "mediatek,mt8173-mdp-wdma";
> + reg = <0 0x14006000 0 0x1000>;
> + clocks = < CLK_MM_MDP_WDMA>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + iommus = < M4U_PORT_MDP_WDMA>;
> + mediatek,larb = <>;
> + };
> +
> + mdp_wrot0: wrot@14007000 {
> + compatible = "mediatek,mt8173-mdp-wrot";
> + reg = <0 0x14007000 0 0x1000>;
> + clocks = < CLK_MM_MDP_WROT0>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + iommus = < M4U_PORT_MDP_WROT0>;
> + mediatek,larb = <>;
> + };
> +
> + mdp_wrot1: wrot@14008000 {
> + compatible = "mediatek,mt8173-mdp-wrot";
> + reg = <0 0x14008000 0 0x1000>;
> + clocks = < CLK_MM_MDP_WROT1>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
> + iommus = < M4U_PORT_MDP_WROT1>;
> + mediatek,larb = <>;
> + };
> -- 
> 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

dvb-usb/dw2102: frontend initialization missing when dvb_usb disable_rc_polling=1

2016-07-26 Thread Oliver O. 

Hi,

with kernel 4.4 (Ubuntu 4.4.0-28.47-generic 4.4.13), this option setting 
in /etc/modprobe.d/*.conf seems to block proper initialization:


options dvb_usb disable_rc_polling=1

Without this option, firmware for the frontend 'm88ds3103' is loaded on 
first access (see second log below). When the above option is set, this 
initialization is missing (see first log below).


Hardware used:

# lsusb | grep TechnoTrend
Bus 003 Device 011: ID 0b48:3011 TechnoTrend AG TT-connect S2-4600

Steps to reproduce:

* Disable software accessing the tuner.
* Unplug the tuner's usb connection.
* Add options dvb_usb disable_rc_polling=1 in /etc/modprobe.d/*.conf.
* Reboot.
* Plug in the tuner's usb connection.
* Tune to a transponder (w_scan -fs -I w_scan-initial-tuning.txt)

The faulty initialization sequence is:

Jul 23 16:08:16 Hotel kernel: usb 3-9.2: new high-speed USB device 
number 11 using xhci_hcd
Jul 23 16:08:16 Hotel kernel: usb 3-9.2: New USB device found, 
idVendor=0b48, idProduct=3011
Jul 23 16:08:16 Hotel kernel: usb 3-9.2: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3

Jul 23 16:08:16 Hotel kernel: usb 3-9.2: Product: dvb-s2
Jul 23 16:08:16 Hotel kernel: usb 3-9.2: Manufacturer: geniatech
Jul 23 16:08:16 Hotel kernel: usb 3-9.2: SerialNumber: 0232
Jul 23 16:08:16 Hotel kernel: dw2102: su3000_identify_state
Jul 23 16:08:16 Hotel kernel: dvb-usb: found a 'TechnoTrend TT-connect 
S2-4600' in warm state.

Jul 23 16:08:16 Hotel kernel: dw2102: su3000_power_ctrl: 1, initialized 0
Jul 23 16:08:16 Hotel kernel: dvb-usb: will pass the complete MPEG2 
transport stream to the software demuxer.
Jul 23 16:08:16 Hotel kernel: DVB: registering new adapter (TechnoTrend 
TT-connect S2-4600)

Jul 23 16:08:16 Hotel kernel: dvb-usb: MAC address: bc:ea:2b:46:14:e5
Jul 23 16:08:16 Hotel kernel: i2c i2c-1: Added multiplexed i2c bus 9
Jul 23 16:08:16 Hotel kernel: ts2020 9-0060: Montage Technology TS2022 
successfully identified
Jul 23 16:08:16 Hotel kernel: usb 3-9.2: DVB: registering adapter 3 
frontend 0 (Montage Technology M88DS3103)...

Jul 23 16:08:16 Hotel kernel: dw2102: su3000_power_ctrl: 0, initialized 1
Jul 23 16:08:16 Hotel kernel: dvb-usb: TechnoTrend TT-connect S2-4600 
successfully initialized and connected.

Jul 23 16:08:27 Hotel kernel: dw2102: su3000_power_ctrl: 1, initialized 1
Jul 23 16:08:29 Hotel kernel: dvb-usb: recv bulk message failed: -110
Jul 23 16:08:29 Hotel kernel: dw2102: i2c transfer failed.
Jul 23 16:08:29 Hotel kernel: dw2102: su3000_power_ctrl: 0, initialized 1
Jul 23 16:08:29 Hotel kernel: dw2102: su3000_power_ctrl: 1, initialized 1
Jul 23 16:08:29 Hotel kernel: dw2102: su3000_power_ctrl: 0, initialized 1

Without the disable_rc_polling option, the correct initialization 
sequence is:


Jul 23 16:12:15 Hotel kernel: usb 3-9.2: new high-speed USB device 
number 11 using xhci_hcd
Jul 23 16:12:15 Hotel kernel: usb 3-9.2: New USB device found, 
idVendor=0b48, idProduct=3011
Jul 23 16:12:15 Hotel kernel: usb 3-9.2: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3

Jul 23 16:12:15 Hotel kernel: usb 3-9.2: Product: dvb-s2
Jul 23 16:12:15 Hotel kernel: usb 3-9.2: Manufacturer: geniatech
Jul 23 16:12:15 Hotel kernel: usb 3-9.2: SerialNumber: 0232
Jul 23 16:12:15 Hotel kernel: dw2102: su3000_identify_state
Jul 23 16:12:15 Hotel kernel: dvb-usb: found a 'TechnoTrend TT-connect 
S2-4600' in warm state.

Jul 23 16:12:15 Hotel kernel: dw2102: su3000_power_ctrl: 1, initialized 0
Jul 23 16:12:15 Hotel kernel: dvb-usb: will pass the complete MPEG2 
transport stream to the software demuxer.
Jul 23 16:12:15 Hotel kernel: DVB: registering new adapter (TechnoTrend 
TT-connect S2-4600)

Jul 23 16:12:15 Hotel kernel: dvb-usb: MAC address: bc:ea:2b:46:14:e5
Jul 23 16:12:15 Hotel kernel: i2c i2c-3: Added multiplexed i2c bus 9
Jul 23 16:12:15 Hotel kernel: ts2020 9-0060: Montage Technology TS2022 
successfully identified
Jul 23 16:12:15 Hotel kernel: usb 3-9.2: DVB: registering adapter 3 
frontend 0 (Montage Technology M88DS3103)...

Jul 23 16:12:15 Hotel kernel: Registered IR keymap rc-tt-1500
Jul 23 16:12:15 Hotel kernel: input: IR-receiver inside an USB DVB 
receiver as /devices/pci:00/:00:14.0/usb3/3-9/3-9.2/rc/rc1/input8
Jul 23 16:12:15 Hotel kernel: rc1: IR-receiver inside an USB DVB 
receiver as /devices/pci:00/:00:14.0/usb3/3-9/3-9.2/rc/rc1
Jul 23 16:12:15 Hotel kernel: dvb-usb: schedule remote query interval to 
250 msecs.

Jul 23 16:12:15 Hotel kernel: dw2102: su3000_power_ctrl: 0, initialized 1
Jul 23 16:12:15 Hotel kernel: dvb-usb: TechnoTrend TT-connect S2-4600 
successfully initialized and connected.

Jul 23 16:12:17 Hotel kernel: dvb-usb: recv bulk message failed: -110
Jul 23 16:12:17 Hotel kernel: dw2102: i2c transfer failed.
Jul 23 16:12:24 Hotel kernel: dw2102: su3000_power_ctrl: 1, initialized 1
Jul 23 16:12:24 Hotel kernel: m88ds3103 3-0068: found a 'Montage 
Technology M88DS3103' in cold state
Jul 23 16:12:24 Hotel kernel: m88ds3103 3-0068:

IR button repeat not working in kernel 4.6 and 4.7

2016-07-26 Thread Matthias Reichl 
In kernel 4.6 and 4.7 holding down a button on an IR remote no longer
results in repeated key down events.

I've reproduced that issue on a Raspberry Pi B using a GPIO IR
receiver. Other systems seem to be affected as well, for
example Intel NUC with an ITE CIR receiver.

Bisecting points to this commit as a possible cause for that issue:

commit 078600f514a12fd763ac84c86af68ef5b5267563
Author: Mauro Carvalho Chehab 
Date:   Wed Mar 2 08:00:15 2016 -0300

[media] rc-core: allow calling rc_open with device not initialized

With upstream kernel 4.6.0 and 4.7.0 the ir-keytable output looks OK:

Found /sys/class/rc/rc0/ (/dev/input/event0) with:
Driver gpio-rc-recv, table rc-hauppauge
Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO RC-5-SZ SHARP XMP 
other
Enabled protocols: RC-5
Name: gpio_ir_recv
bus: 25, vendor/product: 0001:0001, version: 0x0100
Repeat delay = 500 ms, repeat period = 125 ms
 
But running evtest (or ir-keytable -t) only shows EV_KEY events on
initial button down and on release:

Event: time 1469531035.490700, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531035.490700, type 1 (EV_KEY), code 2 (KEY_1), value 1
Event: time 1469531035.490700, -- EV_SYN 
Event: time 1469531035.603725, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531035.603725, -- EV_SYN 
Event: time 1469531035.716778, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531035.716778, -- EV_SYN 
Event: time 1469531035.829849, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531035.829849, -- EV_SYN 
Event: time 1469531035.942893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531035.942893, -- EV_SYN 
Event: time 1469531036.055932, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.055932, -- EV_SYN 
Event: time 1469531036.169004, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.169004, -- EV_SYN 
Event: time 1469531036.282043, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.282043, -- EV_SYN 
Event: time 1469531036.395103, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.395103, -- EV_SYN 
Event: time 1469531036.508157, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.508157, -- EV_SYN 
Event: time 1469531036.621216, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.621216, -- EV_SYN 
Event: time 1469531036.734255, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.734255, -- EV_SYN 
Event: time 1469531036.875917, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531036.875917, -- EV_SYN 
Event: time 1469531037.125875, type 1 (EV_KEY), code 2 (KEY_1), value 0
Event: time 1469531037.125875, -- EV_SYN 

When reverting commit 078600f514a12fd763ac84c86af68ef5b5267563 in
kernel 4.6.0 evtest output is back to normal: EV_KEY events with
value 2 show up between button down and button up:

Event: time 1469531201.086823, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.086823, type 1 (EV_KEY), code 2 (KEY_1), value 1
Event: time 1469531201.086823, -- EV_SYN 
Event: time 1469531201.199789, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.199789, -- EV_SYN 
Event: time 1469531201.312818, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.312818, -- EV_SYN 
Event: time 1469531201.425846, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.425846, -- EV_SYN 
Event: time 1469531201.538852, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.538852, -- EV_SYN 
Event: time 1469531201.578497, type 1 (EV_KEY), code 2 (KEY_1), value 2
Event: time 1469531201.578497, -- EV_SYN 
Event: time 1469531201.651897, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.651897, -- EV_SYN 
Event: time 1469531201.708488, type 1 (EV_KEY), code 2 (KEY_1), value 2
Event: time 1469531201.708488, -- EV_SYN 
Event: time 1469531201.764901, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.764901, -- EV_SYN 
Event: time 1469531201.838497, type 1 (EV_KEY), code 2 (KEY_1), value 2
Event: time 1469531201.838497, -- EV_SYN 
Event: time 1469531201.877950, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e01
Event: time 1469531201.877950, -- EV_SYN

Re: Questions about userspace, request and frame API in your Rockchip VPU driver

2016-07-26 Thread Florent Revest 
Hi,

On 26/07/2016 11:26, Tomasz Figa wrote:
> I think the H264 API is more or less in a good shape. I don't remember
> exactly, but VP8 API might need a bit more work. There is also VP9 API
> in the works, but it's a quite early stage. Both are more or less
> blocked currently on the request API, which needs to be extended to
> support controls and merged upstream. I believe all the APIs could
> benefit from adding more platforms to the discussion.

Alright, I'll follow their development closely.

> You're correct. Basically for this kind of dumb decoding there is a
> need to attach additional data to each frame. In theory that could be
> done by a series of qbuf, s_ctrl, qbuf, s_ctrl, but it would require a
> contract with the driver, so that it latches the controls at qbuf time
> and would make the driver do basically the same as the request API,
> but on its own. That would overly complicate the driver, considering
> that you might want to queue multiple frames for better parallelism
> and each needs its own set of data.

This is indeed what I've been doing until now and I'm currently
switching to the request API to address this kind of issues. Thanks for
making it clearer!

I have another question regarding reference frames though. In
rockchip_vpu, you are referring to previous frames with their index in
"dst_bufs". Isn't it a problem to access buffers that have already been
dequeued by the driver ?

>> Also, the text says "The user space code should be implemented as
>> libv4l2 plugins". And Hans told me the opposite on IRC.
>> kido | is developing a libv4l2 plugin interface which uses
>> libavformat to pre-process buffers the "right" way to do it ?
>> hverkuil | kido: no, there isn't. [...]
>> hverkuil | Chances are he has code floating around for chromium that
>> you can use.
> 
> Personally I think that a plugin would be a good way to deal with
> legacy apps. Still, if I remember correctly, the preferred way is to
> have a shared bitstream parser library and then use the slice/frame
> API directly in the app, feeding the kernel with data from the parser.

In ChromeOS, I understand that "directly in the app" refers to chromium.
But in a more traditional linux desktop userspace, I'm still open to
suggestions of alternatives to a libv4l2 plugin. I thought about a VA
API backend for slice API but if anyone has a better idea to suggest,
please let me know.

>> How is the userspace part of your rockchip driver implemented in Chrome
>> OS and most importantly, do you have any userspace code available to share ?
> 
> I believe all the related code should be over there:
> 
> https://cs.chromium.org/chromium/src/media/gpu/
> 
> There are variants for VA-API, regular "smart" V4L2 codec API and
> frame/slice API, which you are interested in. The class responsible
> for talking the V4L2 frame/slice API is
> v4l2_slice_video_decode_accelerator.cc and there should be also some
> modules responsible for parsing the bitstream, but I don't have enough
> knowledge on this code to point exactly.

Great, thanks for pointing me to this code, this is indeed what I've
been searching for and it will be very helpful !

BR,
Florent

-- 
Florent Revest, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] lgdt3306a: remove 20*50 msec unnecessary timeout

2016-07-26 Thread Michael Ira Krufky 
On Mon, Jul 25, 2016 at 9:36 PM, Mauro Carvalho Chehab
 wrote:
> Em Mon, 25 Jul 2016 15:37:14 -0400
> Michael Ira Krufky  escreveu:
>
>> On Mon, Jul 25, 2016 at 3:28 PM, Mauro Carvalho Chehab
>>  wrote:
>> > Hi Michael,
>> >
>> > Em Mon, 25 Jul 2016 14:55:51 -0400
>> > Michael Ira Krufky  escreveu:
>> >
>> >> On Mon, Jul 25, 2016 at 2:38 PM, Abylay Ospan  wrote:
>> >> > inside lgdt3306a_search we reading demod status 20 times with 50 msec 
>> >> > sleep after each read.
>> >> > This gives us more than 1 sec of delay. Removing this delay should not 
>> >> > affect demod functionality.
>> >> >
>> >> > Signed-off-by: Abylay Ospan 
>> >> > ---
>> >> >  drivers/media/dvb-frontends/lgdt3306a.c | 16 
>> >> >  1 file changed, 4 insertions(+), 12 deletions(-)
>> >> >
>> >> > diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>> >> > b/drivers/media/dvb-frontends/lgdt3306a.c
>> >> > index 179c26e..dad7ad3 100644
>> >> > --- a/drivers/media/dvb-frontends/lgdt3306a.c
>> >> > +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>> >> > @@ -1737,24 +1737,16 @@ static int lgdt3306a_get_tune_settings(struct 
>> >> > dvb_frontend *fe,
>> >> >  static int lgdt3306a_search(struct dvb_frontend *fe)
>> >> >  {
>> >> > enum fe_status status = 0;
>> >> > -   int i, ret;
>> >> > +   int ret;
>> >> >
>> >> > /* set frontend */
>> >> > ret = lgdt3306a_set_parameters(fe);
>> >> > if (ret)
>> >> > goto error;
>> >> >
>> >> > -   /* wait frontend lock */
>> >> > -   for (i = 20; i > 0; i--) {
>> >> > -   dbg_info(": loop=%d\n", i);
>> >> > -   msleep(50);
>> >> > -   ret = lgdt3306a_read_status(fe, );
>> >> > -   if (ret)
>> >> > -   goto error;
>> >> > -
>> >> > -   if (status & FE_HAS_LOCK)
>> >> > -   break;
>> >> > -   }
>> >
>> > Could you please explain why lgdt3306a needs the above ugly hack?
>> >
>> >
>> >> > +   ret = lgdt3306a_read_status(fe, );
>> >> > +   if (ret)
>> >> > +   goto error;
>> >
>> >
>> >> >
>> >> > /* check if we have a valid signal */
>> >> > if (status & FE_HAS_LOCK)
>> >>
>> >> Your patch removes a loop that was purposefully written here to handle
>> >> conditions that are not ideal.  Are you sure this change is best for
>> >> all users?
>> >>
>> >> I would disagree with merging this patch.
>> >>
>> >> Best regards,
>> >>
>> >> Michael Ira Krufky
>>
>> Mauro,
>>
>> I cannot speak for the LG DT3306a part itself, but based on my past
>> experience I can say the following:
>>
>> To my understanding, the hardware might not report a lock on the first
>> read_status request, so the driver author chose to include a loop to
>> retry a few times before giving up.
>
> A one second wait, trying 50 times is not a "few times". It is a lot!
>
>> In real life scenarios, there are marginal signals that may take a
>> longer time to lock onto, but once locked, the demod will deliver a
>> reliable stream.
>>
>> Most applications will only issue a single tune request when trying to
>> tune to a given program. The application does not retry the tune
>> request if the driver reports no lock.
>
> I don't know a single application that would give up after a
> single status request with FE_READ_STATUS. Not even simple
> applications like the legacy dvb-tools do that. If such application
> exits, it is already broken, as it would fail with most drivers,
> as almost no drivers wait for frontend locks.
>
> Also, the frontend thread assumes that the lock will take some
> polls to happen, and it keep polling the status for some time,
> using the status return to do frequency zig-zag, on tuners that
> don't have hardware zig-zag, and to try bandwidth inversion.
>
> Please notice that some legacy DVBv3 applications might want to
> be bothered only after lock. In such case, they would be calling
> FE_GET_EVENT with the device opened in blocking mode:
> 
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/uapi/dvb/fe-get-event.html
>
> In such case, the frontend's kthread will keep the ioctl blocked
> until the device is locked, or will keep returning -EWOULDBLOCK
> in non-blocking mode.
>
>> Applying this patch will have the potential to cause userspace to
>> appear broken.  Some users will not be able to receive some weaker
>> channels anymore, and they will have no way to diagnose the problem
>> from within their application.
>
> This is not how it is supposed to work. An ioctl should not block
> for that long time for no reason, specially since the file
> descriptor could be opened in no blocking mode.
>
> The only possible reason to block would be on really broken hardware
> that would stop working if the status is called before a certain
> number of milliseconds. Even so, the proper

Re: [PATCH] rcar-vin: add R-Car gen2 fallback compatibility string

2016-07-26 Thread Sergei Shtylyov 

On 7/26/2016 9:05 AM, Niklas Söderlund wrote:


Such fallback string is present in the 'soc_camera' version of the R-Car VIN
driver, so need  to add it here as well...

Signed-off-by: Sergei Shtylyov 


Acked-by: Niklas Söderlund 


   Thanks and sorry for forgetting to CC you.

MBR, 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: Questions about userspace, request and frame API in your Rockchip VPU driver

2016-07-26 Thread Tomasz Figa 
Hi Florent,

Let's keep more people in the loop. CCing Pawel, Hans, Laurent and
linux-media ML, as there might be more people interested in the status
and/or helping.

On Tue, Jul 26, 2016 at 4:50 PM, Florent Revest
 wrote:
> Hi Tomasz,
>
> I'm currently an intern at Free Electrons working with Thomas and Maxime
> who told me that they know you.

Yeah, say hi to them from me. ;)

> I work on a v4l2 m2m VPU driver for
> Allwinner SoCs. This VPU has very similar problematics as the ones you
> meet on the Rockchip's RK3229. For instance, it is not able to work on
> raw bitstream and needs prior frames parsing, which can't be done in
> kernel space.
>
> Some time ago, I asked on the #v4l IRC channel what I should do to
> implement this behavior correctly and Hans Verkuil told me to get in
> touch with Pawel Osciak, but he is probably busy with other things and
> couldn't answer yet.

Yeah, I'm pretty much sure he is.

>
> So basically, I'm curious about the state of the "Frame API" he talked
> about at the linux kernel summit media workshop.
> https://blogs.s-osg.org/planning-future-media-linux-linux-kernel-summit-media-workshop-seoul-south-korea/
> Do you know what is the status of this API ?

I think the H264 API is more or less in a good shape. I don't remember
exactly, but VP8 API might need a bit more work. There is also VP9 API
in the works, but it's a quite early stage. Both are more or less
blocked currently on the request API, which needs to be extended to
support controls and merged upstream. I believe all the APIs could
benefit from adding more platforms to the discussion.

>
> Is this the place where it is implemented ?
> http://lists.infradead.org/pipermail/linux-rockchip/2016-February/007557.html
> If I get it right, this is just a new extended control that is attached
> to a frame with the media request API from Laurent, am I right ? I still
> have troubles understanding the overall concept of the request API and
> I'd like to know more about your usage of it.

You're correct. Basically for this kind of dumb decoding there is a
need to attach additional data to each frame. In theory that could be
done by a series of qbuf, s_ctrl, qbuf, s_ctrl, but it would require a
contract with the driver, so that it latches the controls at qbuf time
and would make the driver do basically the same as the request API,
but on its own. That would overly complicate the driver, considering
that you might want to queue multiple frames for better parallelism
and each needs its own set of data.

>
> Also, the text says "The user space code should be implemented as
> libv4l2 plugins". And Hans told me the opposite on IRC.
> kido | is developing a libv4l2 plugin interface which uses
> libavformat to pre-process buffers the "right" way to do it ?
> hverkuil | kido: no, there isn't. [...]
> hverkuil | Chances are he has code floating around for chromium that
> you can use.

Personally I think that a plugin would be a good way to deal with
legacy apps. Still, if I remember correctly, the preferred way is to
have a shared bitstream parser library and then use the slice/frame
API directly in the app, feeding the kernel with data from the parser.

>
> How is the userspace part of your rockchip driver implemented in Chrome
> OS and most importantly, do you have any userspace code available to share ?

I believe all the related code should be over there:

https://cs.chromium.org/chromium/src/media/gpu/

There are variants for VA-API, regular "smart" V4L2 codec API and
frame/slice API, which you are interested in. The class responsible
for talking the V4L2 frame/slice API is
v4l2_slice_video_decode_accelerator.cc and there should be also some
modules responsible for parsing the bitstream, but I don't have enough
knowledge on this code to point exactly.

Best regards,
Tomasz
--
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] cx231xx: Prepare for attaching new style i2c_client DVB demod drivers

2016-07-26 Thread Matthias Schwarzott 
cx231xx does not yet support attaching new-style i2c_client DVB demod
drivers. Add necessary code base on tuner support for i2c_client.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/usb/cx231xx/cx231xx-dvb.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index ab2fb9f..f030345 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -65,6 +65,7 @@ struct cx231xx_dvb {
struct dmx_frontend fe_hw;
struct dmx_frontend fe_mem;
struct dvb_net net;
+   struct i2c_client *i2c_client_demod;
struct i2c_client *i2c_client_tuner;
 };
 
@@ -586,8 +587,14 @@ static void unregister_dvb(struct cx231xx_dvb *dvb)
dvb->demux.dmx.remove_frontend(>demux.dmx, >fe_hw);
dvb_dmxdev_release(>dmxdev);
dvb_dmx_release(>demux);
-   client = dvb->i2c_client_tuner;
/* remove I2C tuner */
+   client = dvb->i2c_client_tuner;
+   if (client) {
+   module_put(client->dev.driver->owner);
+   i2c_unregister_device(client);
+   }
+   /* remove I2C demod */
+   client = dvb->i2c_client_demod;
if (client) {
module_put(client->dev.driver->owner);
i2c_unregister_device(client);
-- 
2.9.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

[PATCH 7/7] si2165: switch to regmap

2016-07-26 Thread Matthias Schwarzott 
This avoids some low-level operations.
It has the benefit that now register values van be read from 
/sys/kernel/debug/regmap
The maximum register value is just a guess - all higher addresses read as zero.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/dvb-frontends/Kconfig  |  1 +
 drivers/media/dvb-frontends/si2165.c | 70 +---
 2 files changed, 25 insertions(+), 46 deletions(-)

diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index c645aa8..8272c08 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -67,6 +67,7 @@ config DVB_TDA18271C2DD
 config DVB_SI2165
tristate "Silicon Labs si2165 based"
depends on DVB_CORE && I2C
+   select REGMAP_I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
help
  A DVB-C/T demodulator.
diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 9bf6609..d63cd73 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dvb_frontend.h"
 #include "dvb_math.h"
@@ -42,7 +43,7 @@
 struct si2165_state {
struct i2c_client *client;
 
-   struct i2c_adapter *i2c;
+   struct regmap *regmap;
 
struct dvb_frontend fe;
 
@@ -110,61 +111,27 @@ static int si2165_write(struct si2165_state *state, const 
u16 reg,
   const u8 *src, const int count)
 {
int ret;
-   struct i2c_msg msg;
-   u8 buf[2 + 4]; /* write a maximum of 4 bytes of data */
-
-   if (count + 2 > sizeof(buf)) {
-   dev_warn(>client->dev,
- "%s: i2c wr reg=%04x: count=%d is too big!\n",
- KBUILD_MODNAME, reg, count);
-   return -EINVAL;
-   }
-   buf[0] = reg >> 8;
-   buf[1] = reg & 0xff;
-   memcpy(buf + 2, src, count);
-
-   msg.addr = state->config.i2c_addr;
-   msg.flags = 0;
-   msg.buf = buf;
-   msg.len = count + 2;
 
if (debug & DEBUG_I2C_WRITE)
deb_i2c_write("reg: 0x%04x, data: %*ph\n", reg, count, src);
 
-   ret = i2c_transfer(state->i2c, , 1);
+   ret = regmap_bulk_write(state->regmap, reg, src, count);
 
-   if (ret != 1) {
+   if (ret)
dev_err(>client->dev, "%s: ret == %d\n", __func__, ret);
-   if (ret < 0)
-   return ret;
-   else
-   return -EREMOTEIO;
-   }
 
-   return 0;
+   return ret;
 }
 
 static int si2165_read(struct si2165_state *state,
   const u16 reg, u8 *val, const int count)
 {
-   int ret;
-   u8 reg_buf[] = { reg >> 8, reg & 0xff };
-   struct i2c_msg msg[] = {
-   { .addr = state->config.i2c_addr,
- .flags = 0, .buf = reg_buf, .len = 2 },
-   { .addr = state->config.i2c_addr,
- .flags = I2C_M_RD, .buf = val, .len = count },
-   };
+   int ret = regmap_bulk_read(state->regmap, reg, val, count);
 
-   ret = i2c_transfer(state->i2c, msg, 2);
-
-   if (ret != 2) {
+   if (ret) {
dev_err(>client->dev, "%s: error (addr %02x reg %04x 
error (ret == %i)\n",
__func__, state->config.i2c_addr, reg, ret);
-   if (ret < 0)
-   return ret;
-   else
-   return -EREMOTEIO;
+   return ret;
}
 
if (debug & DEBUG_I2C_READ)
@@ -176,9 +143,9 @@ static int si2165_read(struct si2165_state *state,
 static int si2165_readreg8(struct si2165_state *state,
   const u16 reg, u8 *val)
 {
-   int ret;
-
-   ret = si2165_read(state, reg, val, 1);
+   unsigned int val_tmp;
+   int ret = regmap_read(state->regmap, reg, _tmp);
+   *val = (u8)val_tmp;
deb_readreg("R(0x%04x)=0x%02x\n", reg, *val);
return ret;
 }
@@ -196,7 +163,7 @@ static int si2165_readreg16(struct si2165_state *state,
 
 static int si2165_writereg8(struct si2165_state *state, const u16 reg, u8 val)
 {
-   return si2165_write(state, reg, , 1);
+   return regmap_write(state->regmap, reg, val);
 }
 
 static int si2165_writereg16(struct si2165_state *state, const u16 reg, u16 
val)
@@ -1052,6 +1019,11 @@ static int si2165_probe(struct i2c_client *client,
u8 val;
char rev_char;
const char *chip_name;
+   static const struct regmap_config regmap_config = {
+   .reg_bits = 16,
+   .val_bits = 8,
+   .max_register = 0x08ff,
+   };
 
/* allocate memory for the internal state */
state = kzalloc(sizeof(struct si2165_state), GFP_KERNEL);
@@ -1060,9 +1032,15 @@ static int si2165_probe(struct i2c_client *client,
goto error;
}
 
+   /* create regmap */
+

[PATCH 4/7] cx231xx: attach si2165 driver via i2c_client

2016-07-26 Thread Matthias Schwarzott 
Use new style attach.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/usb/cx231xx/cx231xx-dvb.c | 73 ++---
 1 file changed, 48 insertions(+), 25 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index f030345..1417515 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -151,18 +151,6 @@ static struct tda18271_config pv_tda18271_config = {
.small_i2c = TDA18271_03_BYTE_CHUNK_INIT,
 };
 
-static const struct si2165_config hauppauge_930C_HD_1113xx_si2165_config = {
-   .i2c_addr   = 0x64,
-   .chip_mode  = SI2165_MODE_PLL_XTAL,
-   .ref_freq_Hz= 1600,
-};
-
-static const struct si2165_config pctv_quatro_stick_1114xx_si2165_config = {
-   .i2c_addr   = 0x64,
-   .chip_mode  = SI2165_MODE_PLL_EXT,
-   .ref_freq_Hz= 2400,
-};
-
 static struct lgdt3306a_config hauppauge_955q_lgdt3306a_config = {
.i2c_addr   = 0x59,
.qam_if_khz = 4000,
@@ -756,19 +744,38 @@ static int dvb_init(struct cx231xx *dev)
break;
 
case CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx:
+   {
+   struct i2c_client *client;
+   struct i2c_board_info info;
+   struct si2165_platform_data si2165_pdata;
 
-   dev->dvb->frontend = dvb_attach(si2165_attach,
-   _930C_HD_1113xx_si2165_config,
-   demod_i2c
-   );
+   /* attach demod */
+   memset(_pdata, 0, sizeof(si2165_pdata));
+   si2165_pdata.fe = >dvb->frontend;
+   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL,
+   si2165_pdata.ref_freq_Hz = 1600,
 
-   if (dev->dvb->frontend == NULL) {
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2165", I2C_NAME_SIZE);
+   info.addr = 0x64;
+   info.platform_data = _pdata;
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+   if (client == NULL || client->dev.driver == NULL || 
dev->dvb->frontend == NULL) {
dev_err(dev->dev,
"Failed to attach SI2165 front end\n");
result = -EINVAL;
goto out_free;
}
 
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   dvb->i2c_client_demod = client;
+
dev->dvb->frontend->ops.i2c_gate_ctrl = NULL;
 
/* define general-purpose callback pointer */
@@ -781,27 +788,43 @@ static int dvb_init(struct cx231xx *dev)
 
dev->cx231xx_reset_analog_tuner = NULL;
break;
-
+   }
case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
{
struct i2c_client *client;
struct i2c_board_info info;
+   struct si2165_platform_data si2165_pdata;
struct si2157_config si2157_config;
 
-   memset(, 0, sizeof(struct i2c_board_info));
+   /* attach demod */
+   memset(_pdata, 0, sizeof(si2165_pdata));
+   si2165_pdata.fe = >dvb->frontend;
+   si2165_pdata.chip_mode = SI2165_MODE_PLL_EXT,
+   si2165_pdata.ref_freq_Hz = 2400,
 
-   dev->dvb->frontend = dvb_attach(si2165_attach,
-   _quatro_stick_1114xx_si2165_config,
-   demod_i2c
-   );
-
-   if (dev->dvb->frontend == NULL) {
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2165", I2C_NAME_SIZE);
+   info.addr = 0x64;
+   info.platform_data = _pdata;
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+   if (client == NULL || client->dev.driver == NULL || 
dev->dvb->frontend == NULL) {
dev_err(dev->dev,
"Failed to attach SI2165 front end\n");
result = -EINVAL;
goto out_free;
}
 
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   dvb->i2c_client_demod = client;
+
+   memset(, 0, sizeof(struct i2c_board_info));
+
dev->dvb->frontend->ops.i2c_gate_ctrl = NULL;
 
/* define general-purpose callback pointer */
-- 
2.9.2

--
To unsubscribe from this list: send the line

[PATCH 2/7] cx23885: attach si2165 driver via i2c_client

2016-07-26 Thread Matthias Schwarzott 
Use new style attach.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/pci/cx23885/cx23885-dvb.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c 
b/drivers/media/pci/cx23885/cx23885-dvb.c
index e5748a9..5d0bbe4 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -867,12 +867,6 @@ static const struct tda10071_platform_data 
hauppauge_tda10071_pdata = {
.tuner_i2c_addr = 0x54,
 };
 
-static const struct si2165_config hauppauge_hvr4400_si2165_config = {
-   .i2c_addr   = 0x64,
-   .chip_mode  = SI2165_MODE_PLL_XTAL,
-   .ref_freq_Hz= 1600,
-};
-
 static const struct m88ds3103_config dvbsky_t9580_m88ds3103_config = {
.i2c_addr = 0x68,
.clock = 2700,
@@ -1182,6 +1176,7 @@ static int dvb_register(struct cx23885_tsport *port)
struct cx23885_i2c *i2c_bus = NULL, *i2c_bus2 = NULL;
struct vb2_dvb_frontend *fe0, *fe1 = NULL;
struct si2168_config si2168_config;
+   struct si2165_platform_data si2165_pdata;
struct si2157_config si2157_config;
struct ts2020_config ts2020_config;
struct i2c_board_info info;
@@ -1839,9 +1834,26 @@ static int dvb_register(struct cx23885_tsport *port)
break;
/* port c */
case 2:
-   fe0->dvb.frontend = dvb_attach(si2165_attach,
-   _hvr4400_si2165_config,
-   _bus->i2c_adap);
+   /* attach frontend */
+   memset(_pdata, 0, sizeof(si2165_pdata));
+   si2165_pdata.fe = >dvb.frontend;
+   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL,
+   si2165_pdata.ref_freq_Hz = 1600,
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2165", I2C_NAME_SIZE);
+   info.addr = 0x64;
+   info.platform_data = _pdata;
+   request_module(info.type);
+   client_demod = i2c_new_device(_bus->i2c_adap, 
);
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)
+   goto frontend_detach;
+   if (!try_module_get(client_demod->dev.driver->owner)) {
+   i2c_unregister_device(client_demod);
+   goto frontend_detach;
+   }
+   port->i2c_client_demod = client_demod;
+
if (fe0->dvb.frontend == NULL)
break;
fe0->dvb.frontend->ops.i2c_gate_ctrl = NULL;
-- 
2.9.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

[PATCH 6/7] si2165: use i2c_client->dev instead of i2c_adapter->dev for logging

2016-07-26 Thread Matthias Schwarzott 
Now that there is a i2c_client, use the more specific dev for logging.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/dvb-frontends/si2165.c | 46 ++--
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index e979fc0..9bf6609 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -114,7 +114,7 @@ static int si2165_write(struct si2165_state *state, const 
u16 reg,
u8 buf[2 + 4]; /* write a maximum of 4 bytes of data */
 
if (count + 2 > sizeof(buf)) {
-   dev_warn(>i2c->dev,
+   dev_warn(>client->dev,
  "%s: i2c wr reg=%04x: count=%d is too big!\n",
  KBUILD_MODNAME, reg, count);
return -EINVAL;
@@ -134,7 +134,7 @@ static int si2165_write(struct si2165_state *state, const 
u16 reg,
ret = i2c_transfer(state->i2c, , 1);
 
if (ret != 1) {
-   dev_err(>i2c->dev, "%s: ret == %d\n", __func__, ret);
+   dev_err(>client->dev, "%s: ret == %d\n", __func__, ret);
if (ret < 0)
return ret;
else
@@ -159,7 +159,7 @@ static int si2165_read(struct si2165_state *state,
ret = i2c_transfer(state->i2c, msg, 2);
 
if (ret != 2) {
-   dev_err(>i2c->dev, "%s: error (addr %02x reg %04x error 
(ret == %i)\n",
+   dev_err(>client->dev, "%s: error (addr %02x reg %04x 
error (ret == %i)\n",
__func__, state->config.i2c_addr, reg, ret);
if (ret < 0)
return ret;
@@ -347,7 +347,7 @@ static int si2165_wait_init_done(struct si2165_state *state)
return 0;
usleep_range(1000, 5);
}
-   dev_err(>i2c->dev, "%s: init_done was not set\n",
+   dev_err(>client->dev, "%s: init_done was not set\n",
KBUILD_MODNAME);
return ret;
 }
@@ -376,14 +376,14 @@ static int si2165_upload_firmware_block(struct 
si2165_state *state,
wordcount = data[offset];
if (wordcount < 1 || data[offset+1] ||
data[offset+2] || data[offset+3]) {
-   dev_warn(>i2c->dev,
+   dev_warn(>client->dev,
 "%s: bad fw data[0..3] = %*ph\n",
KBUILD_MODNAME, 4, data);
return -EINVAL;
}
 
if (offset + 8 + wordcount * 4 > len) {
-   dev_warn(>i2c->dev,
+   dev_warn(>client->dev,
 "%s: len is too small for block len=%d, 
wordcount=%d\n",
KBUILD_MODNAME, len, wordcount);
return -EINVAL;
@@ -446,15 +446,15 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
fw_file = SI2165_FIRMWARE_REV_D;
break;
default:
-   dev_info(>i2c->dev, "%s: no firmware file for 
revision=%d\n",
+   dev_info(>client->dev, "%s: no firmware file for 
revision=%d\n",
KBUILD_MODNAME, state->chip_revcode);
return 0;
}
 
/* request the firmware, this will block and timeout */
-   ret = request_firmware(, fw_file, state->i2c->dev.parent);
+   ret = request_firmware(, fw_file, >client->dev);
if (ret) {
-   dev_warn(>i2c->dev, "%s: firmware file '%s' not found\n",
+   dev_warn(>client->dev, "%s: firmware file '%s' not 
found\n",
KBUILD_MODNAME, fw_file);
goto error;
}
@@ -462,11 +462,11 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
data = fw->data;
len = fw->size;
 
-   dev_info(>i2c->dev, "%s: downloading firmware from file '%s' 
size=%d\n",
+   dev_info(>client->dev, "%s: downloading firmware from file '%s' 
size=%d\n",
KBUILD_MODNAME, fw_file, len);
 
if (len % 4 != 0) {
-   dev_warn(>i2c->dev, "%s: firmware size is not multiple 
of 4\n",
+   dev_warn(>client->dev, "%s: firmware size is not 
multiple of 4\n",
KBUILD_MODNAME);
ret = -EINVAL;
goto error;
@@ -474,14 +474,14 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
 
/* check header (8 bytes) */
if (len < 8) {
-   dev_warn(>i2c->dev, "%s: firmware header is missing\n",
+   dev_warn(>client->dev, "%s: firmware header is 
missing\n",
KBUILD_MODNAME);
ret = -EINVAL;
goto error;
}
 
if (data[0] != 1 || data[1] != 0) {
-   dev_warn(>i2c->dev,

[PATCH 5/7] si2165: Remove legacy attach

2016-07-26 Thread Matthias Schwarzott 
Now that all users of legacy attach are converted it can be removed.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/dvb-frontends/si2165.c  | 117 --
 drivers/media/dvb-frontends/si2165.h  |  31 
 drivers/media/dvb-frontends/si2165_priv.h |  17 +
 3 files changed, 17 insertions(+), 148 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 2d9bbdd..e979fc0 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -1005,14 +1005,6 @@ static int si2165_set_frontend(struct dvb_frontend *fe)
return 0;
 }
 
-static void si2165_release(struct dvb_frontend *fe)
-{
-   struct si2165_state *state = fe->demodulator_priv;
-
-   dprintk("%s: called\n", __func__);
-   kfree(state);
-}
-
 static struct dvb_frontend_ops si2165_ops = {
.info = {
.name = "Silicon Labs ",
@@ -1048,117 +1040,8 @@ static struct dvb_frontend_ops si2165_ops = {
 
.set_frontend  = si2165_set_frontend,
.read_status   = si2165_read_status,
-
-   .release = si2165_release,
 };
 
-struct dvb_frontend *si2165_attach(const struct si2165_config *config,
-  struct i2c_adapter *i2c)
-{
-   struct si2165_state *state = NULL;
-   int n;
-   int io_ret;
-   u8 val;
-   char rev_char;
-   const char *chip_name;
-
-   if (config == NULL || i2c == NULL)
-   goto error;
-
-   /* allocate memory for the internal state */
-   state = kzalloc(sizeof(struct si2165_state), GFP_KERNEL);
-   if (state == NULL)
-   goto error;
-
-   /* setup the state */
-   state->i2c = i2c;
-   state->config = *config;
-
-   if (state->config.ref_freq_Hz < 400
-   || state->config.ref_freq_Hz > 2700) {
-   dev_err(>i2c->dev, "%s: ref_freq of %d Hz not supported 
by this driver\n",
-KBUILD_MODNAME, state->config.ref_freq_Hz);
-   goto error;
-   }
-
-   /* create dvb_frontend */
-   memcpy(>fe.ops, _ops,
-   sizeof(struct dvb_frontend_ops));
-   state->fe.demodulator_priv = state;
-
-   /* powerup */
-   io_ret = si2165_writereg8(state, 0x, state->config.chip_mode);
-   if (io_ret < 0)
-   goto error;
-
-   io_ret = si2165_readreg8(state, 0x, );
-   if (io_ret < 0)
-   goto error;
-   if (val != state->config.chip_mode)
-   goto error;
-
-   io_ret = si2165_readreg8(state, 0x0023, >chip_revcode);
-   if (io_ret < 0)
-   goto error;
-
-   io_ret = si2165_readreg8(state, 0x0118, >chip_type);
-   if (io_ret < 0)
-   goto error;
-
-   /* powerdown */
-   io_ret = si2165_writereg8(state, 0x, SI2165_MODE_OFF);
-   if (io_ret < 0)
-   goto error;
-
-   if (state->chip_revcode < 26)
-   rev_char = 'A' + state->chip_revcode;
-   else
-   rev_char = '?';
-
-   switch (state->chip_type) {
-   case 0x06:
-   chip_name = "Si2161";
-   state->has_dvbt = true;
-   break;
-   case 0x07:
-   chip_name = "Si2165";
-   state->has_dvbt = true;
-   state->has_dvbc = true;
-   break;
-   default:
-   dev_err(>i2c->dev, "%s: Unsupported Silicon Labs chip 
(type %d, rev %d)\n",
-   KBUILD_MODNAME, state->chip_type, state->chip_revcode);
-   goto error;
-   }
-
-   dev_info(>i2c->dev,
-   "%s: Detected Silicon Labs %s-%c (type %d, rev %d)\n",
-   KBUILD_MODNAME, chip_name, rev_char, state->chip_type,
-   state->chip_revcode);
-
-   strlcat(state->fe.ops.info.name, chip_name,
-   sizeof(state->fe.ops.info.name));
-
-   n = 0;
-   if (state->has_dvbt) {
-   state->fe.ops.delsys[n++] = SYS_DVBT;
-   strlcat(state->fe.ops.info.name, " DVB-T",
-   sizeof(state->fe.ops.info.name));
-   }
-   if (state->has_dvbc) {
-   state->fe.ops.delsys[n++] = SYS_DVBC_ANNEX_A;
-   strlcat(state->fe.ops.info.name, " DVB-C",
-   sizeof(state->fe.ops.info.name));
-   }
-
-   return >fe;
-
-error:
-   kfree(state);
-   return NULL;
-}
-EXPORT_SYMBOL(si2165_attach);
-
 static int si2165_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
diff --git a/drivers/media/dvb-frontends/si2165.h 
b/drivers/media/dvb-frontends/si2165.h
index abbebc9..76c2ca7 100644
--- a/drivers/media/dvb-frontends/si2165.h
+++ b/drivers/media/dvb-frontends/si2165.h
@@ -50,35 +50,4 @@ struct si2165_platform_data {
bool inversion;
 };
 
-struct si2165_config {
-   /* i2c addr
-*

[PATCH 1/7] si2165: support i2c_client attach

2016-07-26 Thread Matthias Schwarzott 
Afterwards it is possible to convert attaching in card drivers.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/dvb-frontends/si2165.c | 149 +++
 drivers/media/dvb-frontends/si2165.h |  22 ++
 2 files changed, 171 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 8bf716a..2d9bbdd 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -40,6 +40,8 @@
  */
 
 struct si2165_state {
+   struct i2c_client *client;
+
struct i2c_adapter *i2c;
 
struct dvb_frontend fe;
@@ -1157,6 +1159,153 @@ error:
 }
 EXPORT_SYMBOL(si2165_attach);
 
+static int si2165_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct si2165_state *state = NULL;
+   struct si2165_platform_data *pdata = client->dev.platform_data;
+   int n;
+   int ret = 0;
+   u8 val;
+   char rev_char;
+   const char *chip_name;
+
+   /* allocate memory for the internal state */
+   state = kzalloc(sizeof(struct si2165_state), GFP_KERNEL);
+   if (state == NULL) {
+   ret = -ENOMEM;
+   goto error;
+   }
+
+   /* setup the state */
+   state->client = client;
+   state->i2c = client->adapter;
+   state->config.i2c_addr = client->addr;
+   state->config.chip_mode = pdata->chip_mode;
+   state->config.ref_freq_Hz = pdata->ref_freq_Hz;
+   state->config.inversion = pdata->inversion;
+
+   if (state->config.ref_freq_Hz < 400
+   || state->config.ref_freq_Hz > 2700) {
+   dev_err(>i2c->dev, "%s: ref_freq of %d Hz not supported 
by this driver\n",
+KBUILD_MODNAME, state->config.ref_freq_Hz);
+   ret = -EINVAL;
+   goto error;
+   }
+
+   /* create dvb_frontend */
+   memcpy(>fe.ops, _ops,
+   sizeof(struct dvb_frontend_ops));
+   state->fe.ops.release = NULL;
+   state->fe.demodulator_priv = state;
+   i2c_set_clientdata(client, state);
+
+   /* powerup */
+   ret = si2165_writereg8(state, 0x, state->config.chip_mode);
+   if (ret < 0)
+   goto nodev_error;
+
+   ret = si2165_readreg8(state, 0x, );
+   if (ret < 0)
+   goto nodev_error;
+   if (val != state->config.chip_mode)
+   goto nodev_error;
+
+   ret = si2165_readreg8(state, 0x0023, >chip_revcode);
+   if (ret < 0)
+   goto nodev_error;
+
+   ret = si2165_readreg8(state, 0x0118, >chip_type);
+   if (ret < 0)
+   goto nodev_error;
+
+   /* powerdown */
+   ret = si2165_writereg8(state, 0x, SI2165_MODE_OFF);
+   if (ret < 0)
+   goto nodev_error;
+
+   if (state->chip_revcode < 26)
+   rev_char = 'A' + state->chip_revcode;
+   else
+   rev_char = '?';
+
+   switch (state->chip_type) {
+   case 0x06:
+   chip_name = "Si2161";
+   state->has_dvbt = true;
+   break;
+   case 0x07:
+   chip_name = "Si2165";
+   state->has_dvbt = true;
+   state->has_dvbc = true;
+   break;
+   default:
+   dev_err(>i2c->dev, "%s: Unsupported Silicon Labs chip 
(type %d, rev %d)\n",
+   KBUILD_MODNAME, state->chip_type, state->chip_revcode);
+   goto nodev_error;
+   }
+
+   dev_info(>i2c->dev,
+   "%s: Detected Silicon Labs %s-%c (type %d, rev %d)\n",
+   KBUILD_MODNAME, chip_name, rev_char, state->chip_type,
+   state->chip_revcode);
+
+   strlcat(state->fe.ops.info.name, chip_name,
+   sizeof(state->fe.ops.info.name));
+
+   n = 0;
+   if (state->has_dvbt) {
+   state->fe.ops.delsys[n++] = SYS_DVBT;
+   strlcat(state->fe.ops.info.name, " DVB-T",
+   sizeof(state->fe.ops.info.name));
+   }
+   if (state->has_dvbc) {
+   state->fe.ops.delsys[n++] = SYS_DVBC_ANNEX_A;
+   strlcat(state->fe.ops.info.name, " DVB-C",
+   sizeof(state->fe.ops.info.name));
+   }
+
+   /* return fe pointer */
+   *pdata->fe = >fe;
+
+   return 0;
+
+nodev_error:
+   ret = -ENODEV;
+error:
+   kfree(state);
+   dev_dbg(>dev, "failed=%d\n", ret);
+   return ret;
+}
+
+static int si2165_remove(struct i2c_client *client)
+{
+   struct si2165_state *state = i2c_get_clientdata(client);
+
+   dev_dbg(>dev, "\n");
+
+   kfree(state);
+   return 0;
+}
+
+static const struct i2c_device_id si2165_id_table[] = {
+   {"si2165", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, si2165_id_table);
+
+static struct i2c_driver si2165_driver = {
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name

[PATCH] si2165: avoid division by zero

2016-07-26 Thread Matthias Schwarzott 
When si2165_init fails, the clk values in state are still at zero.
But the dvb-core ignores the return value of init will call tune
afterwards.
This will trigger a division by zero when tuning.
At least check for the variables to be non-zero before dividing.

This happened for a system with WinTV HVR-4400 PCIe-card after suspend-to-disk.
Do suspend-to-disk without accessing the DVB device before.
After wakeup try to tune.
si2165_init fails at checking the chip_mode and aborts.
Then si2165_set_if_freq_shift will fail with div-by-zero.

Signed-off-by: Matthias Schwarzott 
---
 drivers/media/dvb-frontends/si2165.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 8bf716a..849c3c4 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -751,6 +751,9 @@ static int si2165_set_oversamp(struct si2165_state *state, 
u32 dvb_rate)
u64 oversamp;
u32 reg_value;
 
+   if (!dvb_rate)
+   return -EINVAL;
+
oversamp = si2165_get_fe_clk(state);
oversamp <<= 23;
do_div(oversamp, dvb_rate);
@@ -775,6 +778,9 @@ static int si2165_set_if_freq_shift(struct si2165_state 
*state)
return -EINVAL;
}
 
+   if (!fe_clk)
+   return -EINVAL;
+
fe->ops.tuner_ops.get_if_frequency(fe, );
if_freq_shift = IF;
if_freq_shift <<= 29;
-- 
2.9.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] rcar-vin: add R-Car gen2 fallback compatibility string

2016-07-26 Thread Niklas Söderlund 
On 2016-07-25 22:19:33 +0300, Sergei Shtylyov wrote:
> Such fallback string is present in the 'soc_camera' version of the R-Car VIN
> driver, so need  to add it here as well...
> 
> Signed-off-by: Sergei Shtylyov 

Acked-by: Niklas Söderlund 

> 
> ---
> This patch is against the 'media_tree.git' repo's 'master' branch.
> This patch conflicts with Niklas Soderlund's former patch "[media] rcar-vin:
> add  Gen2 and Gen3 fallback compatibility strings"), I got his consent about
> splitting the gen2 part  of that patch to a separate patch...
> 
>  drivers/media/platform/rcar-vin/rcar-core.c |1 +
>  1 file changed, 1 insertion(+)
> 
> Index: media_tree/drivers/media/platform/rcar-vin/rcar-core.c
> ===
> --- media_tree.orig/drivers/media/platform/rcar-vin/rcar-core.c
> +++ media_tree/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -209,6 +209,7 @@ static const struct of_device_id rvin_of
>   { .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
>   { .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
>   { .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
> + { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
>   { },
>  };
>  MODULE_DEVICE_TABLE(of, rvin_of_id_table);
> 

-- 
Regards,
Niklas Söderlund
--
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