dvb-usb/friio, dvb-usb-v2/gl861: decompose friio and merge with gl861

From: Akihiro Tsukada <[email protected]>

Friio device contains "gl861" bridge and "tc90522" demod, for which the separate drivers are already in the kernel. But friio driver was monolithic and did not use them, practically copying those features.
This patch decomposes friio driver into sub drivers and re-uses existing ones, thus reduces some code.

It adds some features to gl861,
to support the friio-specific init/config of the devices and implement i2c communications to the tuner via demod with USB vendor requests.

---
Changes since v3:
- make dvb_usb_device_properties static

Changes since v2:
(patch #27928, dvb-usb-friio: split and merge into dvb-usbv2-gl861)
- used the new i2c binding helpers instead of my own one
- merged gl861-friio.c with gl861.c

 drivers/media/usb/dvb-usb-v2/Kconfig |   5 +-
 drivers/media/usb/dvb-usb-v2/gl861.c | 468 ++++++++++++++++++++++++++++++-
 drivers/media/usb/dvb-usb-v2/gl861.h |   1 +
 drivers/media/usb/dvb-usb/Kconfig    |   6 -
 drivers/media/usb/dvb-usb/Makefile   |   3 -
 drivers/media/usb/dvb-usb/friio-fe.c | 441 -----------------------------
 drivers/media/usb/dvb-usb/friio.c    | 522 -----------------------------------
 drivers/media/usb/dvb-usb/friio.h    |  99 -------
 8 files changed, 465 insertions(+), 1080 deletions(-)
 delete mode 100644 drivers/media/usb/dvb-usb/friio-fe.c
 delete mode 100644 drivers/media/usb/dvb-usb/friio.c
 delete mode 100644 drivers/media/usb/dvb-usb/friio.h

index 0e4944b2b0f..e0a1f377295 100644
@@ -95,10 +95,13 @@ config DVB_USB_GL861
 	tristate "Genesys Logic GL861 USB2.0 support"
 	depends on DVB_USB_V2
 	select DVB_ZL10353 if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
 	select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
 	help
 	  Say Y here to support the MSI Megasky 580 (55801) DVB-T USB2.0
-	  receiver with USB ID 0db0:5581.
+	  receiver with USB ID 0db0:5581, Friio White ISDB-T receiver
+	  with USB ID 0x7a69:0001.
 
 config DVB_USB_LME2510
 	tristate "LME DM04/QQBOX DVB-S USB2.0 support"

index b651b857e03..02c00e10748 100644
@@ -9,5 +9,6 @@
 
 #define GL861_REQ_I2C_WRITE	0x01
 #define GL861_REQ_I2C_READ	0x02
+#define GL861_REQ_I2C_RAW	0x03
 
 #endif

index 2651ae27734..1990d1c975e 100644
@@ -312,12 +312,6 @@ config DVB_USB_DTV5100
 	help
 	  Say Y here to support the AME DTV-5100 USB2.0 DVB-T receiver.
 
-config DVB_USB_FRIIO
-	tristate "Friio ISDB-T USB2.0 Receiver support"
-	depends on DVB_USB
-	help
-	  Say Y here to support the Japanese DTV receiver Friio.
-
 config DVB_USB_AZ6027
 	tristate "Azurewave DVB-S/S2 USB2.0 AZ6027 support"
 	depends on DVB_USB

index 9ad2618408e..407d90ca8be 100644
@@ -71,9 +71,6 @@ obj-$(CONFIG_DVB_USB_DTV5100) += dvb-usb-dtv5100.o
 dvb-usb-cinergyT2-objs := cinergyT2-core.o cinergyT2-fe.o
 obj-$(CONFIG_DVB_USB_CINERGY_T2) += dvb-usb-cinergyT2.o
 
-dvb-usb-friio-objs := friio.o friio-fe.o
-obj-$(CONFIG_DVB_USB_FRIIO) += dvb-usb-friio.o
-
 dvb-usb-az6027-objs := az6027.o
 obj-$(CONFIG_DVB_USB_AZ6027) += dvb-usb-az6027.o
 

2.16.3

You should implement i2c adapter to demod driver and not add such glue to that USB-bridge. I mean that "relayed" stuff, i2c communication to tuner via demod. I2C-mux may not work I think as there is no gate-style multiplexing so you probably need plain i2c adapter. There is few examples already on some demod drivers.

regards
Antti

http://palosaari.fi/

Hi,
thanks for the comment.

I am afraid that the glue is actually necessary.

host - USB -> gl861 - I2C(1) -> tc90522 (addr:X)

                                  \- I2C(2) -> tua6034 (addr:Y)

To send an i2c read message to tua6034,
one has to issue two transactions:
1. write via I2C(1) to addr:X, [ reg:0xfe, val: Y ]
2. read via I2C(1) from addr:X, [ out_data0, out_data1, ....]

The problem is that the transaction 1 is (somehow) implemented with the different USB request than the other i2c transactions on I2C(1). (this is confirmed by a packet capture on Windows box).

Although tc90522 already creats the i2c adapter for I2C(2), tc90522 cannot know/control the USB implementation of I2C(1), only the bridge driver can do this.

regards,
Akihiro

I simply cannot see why it cannot work. Just add i2c adapter and suitable logic there. Transaction on your example is simply and there is no problem to implement that kind of logic to demod i2c adapter.

If gl861 driver i2c adapter logic is broken it can be fixed easily too. It seems to support only i2c writes with len 1 and 2 bytes, but fixing it should be easy if you has some sniffs.

Antti

http://palosaari.fi/

I might be totally wrong, but...

i2c transactions to a tuner must use:
1. usb_control_msg(request:3) for the first half (write) of reads
2. usb_control_msg(request:1) for the other writes
3. usb_control_msg(request:2) for (all) reads

How can the demod driver control the 'request' argument of USB messages that are sent to its parent (not to the demod itself),
when the bridge of tc90522 cannot be limited to gl861 (or even to USB) ?

Akihiro

I don't understand those control message parts and it is bit too hard to read i2c adapter implementation to get understanding. Could you offer simple 2 sniff examples, register write to demod and register write to tuner.

Anyhow, demod i2c adapter gets request from tuner and then does some demod specific i2c algo stuff and then pass proper request to usb-bridge i2c adapter.

IIR it was somehing like

write_tuner_reg(0xaa, 0xbb);
==> demod i2c algo:
* write_demod_reg(0xfe, 0x60) // set tuner i2c addr + start i2c write
* write_demod_reg(0xaa, 0xbb)

so those command now goes to i2c-bridge i2c algo which uses gl861 i2c algo

regards
Antti

http://palosaari.fi/

Here is the part of a packet log.

1. write to demod (addr:0x18)

reg:0x76 val:0c
===============
[46264 ms] >>> URB 146 going down >>>
-- URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TR
ANSFER_OK)
TransferBufferLength = 00000000
TransferBuffer = 8609d21e
TransferBufferMDL = 00000000
UrbLink = 00000000
RequestTypeReservedBits = 00000000

  Request                 = 00000001
  Value                   = 0000300c
  Index                   = 00000076

[46266 ms] UsbSnoop - MyInternalIOCTLCompletion(f79b7db0) : fido=00000000, Irp=8 58f2938, Context=858c4ed8, IRQL=2
[46266 ms] <<< URB 146 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 86239260
TransferFlags = 0000000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANS
FER_OK)
TransferBufferLength = 00000000

  TransferBuffer       = 8609d21e
  TransferBufferMDL    = 00000000
  UrbLink              = 00000000
  SetupPacket          =
    00000000: 40 01 0c 30 76 00 00 00

===============

2. write to tuner (addr:0x60)

write [0f 7b b2 08] to addr 0x60
===============
[47267 ms] >>> URB 147 going down >>>
-- URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TR
ANSFER_OK)
TransferBufferLength = 00000005
TransferBuffer = 8581c7d6
TransferBufferMDL = 00000000

    00000000: c0 0f 7b b2 08
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000000
  Request                 = 00000003
  Value                   = 00003000
  Index                   = 000000fe

[47270 ms] UsbSnoop - MyInternalIOCTLCompletion(f79b7db0) : fido=00000000, Irp=8 58f2008, Context=86275258, IRQL=2
[47270 ms] <<< URB 147 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 86239260
TransferFlags = 0000000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANS
FER_OK)
TransferBufferLength = 00000005

  TransferBuffer       = 8581c7d6
  TransferBufferMDL    = 855f7760
  UrbLink              = 00000000
  SetupPacket          =
    00000000: 40 03 00 30 fe 00 05 00

===============

3. read from tuner

read one byte from addr 0x60
(2 USB packets)
===============
[46036 ms] >>> URB 26 going down >>>
-- URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TR
ANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = 8609d21e
TransferBufferMDL = 00000000

    00000000: c1
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000000
  Request                 = 00000003
  Value                   = 00003000
  Index                   = 000000fe

[46038 ms] UsbSnoop - MyInternalIOCTLCompletion(f79b7db0) : fido=00000000, Irp=8 58f2938, Context=858ccea0, IRQL=2
[46038 ms] <<< URB 26 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 86239260
TransferFlags = 0000000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANS
FER_OK)
TransferBufferLength = 00000001

  TransferBuffer       = 8609d21e
  TransferBufferMDL    = 855f7760
  UrbLink              = 00000000
  SetupPacket          =
    00000000: 40 03 00 30 fe 00 01 00

[46038 ms] >>> URB 27 going down >>>
-- URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRA
NSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = 8609d21e
TransferBufferMDL = 00000000
UrbLink = 00000000
RequestTypeReservedBits = 00000000

  Request                 = 00000002
  Value                   = 00003000
  Index                   = 00000100

[46040 ms] UsbSnoop - MyInternalIOCTLCompletion(f79b7db0) : fido=00000000, Irp=8 58f2938, Context=86366778, IRQL=2
[46040 ms] <<< URB 27 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 86239260
TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSF
ER_OK)
TransferBufferLength = 00000001
TransferBuffer = 8609d21e
TransferBufferMDL = 855f7760

    00000000: 7c
  UrbLink              = 00000000
  SetupPacket          =
    00000000: c0 02 00 30 00 01 01 00

============

Note: In log 2 & 3, "Request" parameter value is different from log 1.

regards,
Akihiro