Re: [PATCH] Support for Asus MyCinema U3100Mini Plus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/10/2012 12:58 PM, Oliver Schinagl wrote:
Changed the address as recommended, which after reading 7bit and 8bit
addressing makes perfect sense (drop the r/w bit and get the actual
address).

  static struct fc2580_config af9035_fc2580_config = {
-       .i2c_addr = 0xac,
+       .i2c_addr = 0x56,
         .clock = 16384000,
  };


So now the address should actually be correct ;)

Unfortunately, nothing. What other debug options do I need to enable
besides CONFIG_DVB_USB_DEBUG to get more interesting output?

For me it sees something happens as there is no I2C error seen anymore.

AF9035 driver uses Kernel dynamic debugs. CONFIG_DVB_USB_DEBUG is legacy and proprietary DVB subsystem debug which should not be used anymore.
You could order dynamic debugs like that:
modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' > /sys/kernel/debug/dynamic_debug/control

For tuner, demod and dvb_usbv2 similarly if needed.

Anyway, dmesg reports the following.
[60.071538] usb 1-3: new high-speed USB device number 3 using ehci_hcd
[60.192627] usb 1-3: New USB device found, idVendor=0b05, idProduct=1779
[60.192638] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[60.192646] usb 1-3: Product: AF9035A USB Device
[60.192652] usb 1-3: Manufacturer: Afa Technologies Inc.
[60.192657] usb 1-3: SerialNumber: AF010asdfasdf12314
[60.198686] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.1/input/input14
[60.198832] hid-generic 0003:0B05:1779.0003: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-0000:00:12.2-3/input1
[60.263893] usbcore: registered new interface driver dvb_usb_af9035
[60.264605] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold state
[60.273924] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[60.584267] dvb_usb_af9035: firmware version=11.5.9.0
[60.584287] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm state
[60.586802] usb 1-3: dvb_usbv2: will pass the complete MPEG2 transport
stream to the software demuxer
[60.586871] DVB: registering new adapter (Asus U3100Mini Plus)
[60.595637] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[60.595654] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[60.599889] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
loading driver (-19)

I then tried using the firmware that came with said driver, as the
version seems slightly different/newer.

#define FW_RELEASE_VERSION "v8_8_63_0"

#define DVB_LL_VERSION1 11
#define DVB_LL_VERSION2 22
#define DVB_LL_VERSION3 12
#define DVB_LL_VERSION4 0

#define DVB_OFDM_VERSION1 5
#define DVB_OFDM_VERSION2 66
#define DVB_OFDM_VERSION3 12
#define DVB_OFDM_VERSION4 0

(which also gets displayed when loading the firmware, originally on the
old kernel).

This however results in a hard lock/dump when plugging in the device.
Are there certain size restrictions etc? What I did to obtain said
firmware was write a simple program that reads the array, static
unsigned char Firmware_codes[] and outputs the read bytes to a file.
 From what I saw from the -02 firmware, the first few bytes are
identical (header?) so should be right procedure.

Firmare surely works but you make some mistake. I have extracted those from the windows driver.

http://palosaari.fi/linux/v4l-dvb/firmware/af9035/

Btw, when using the -02 firmware and trying to unload the af9033 module,
either with or without the stick plugged in, it just hangs there for a
long time. Reboot fails too (it hangs at trying to disable swap). Only a
sys-req-reisub successfully reboots.

oliver


Antti


On 09/10/12 00:29, Antti Palosaari wrote:
On 09/10/2012 01:26 AM, Oliver Schinagl wrote:
On 09/09/12 23:51, Antti Palosaari wrote:
On 09/09/2012 11:49 PM, Oliver Schinagl wrote:
Hi All/Antti,

I used Antti's previous patch to try to get some support in for the
Asus
MyCinema U3100Mini Plus as it uses a supported driver (af9035) and now
supported tuner (FCI FC2580).

It compiles fine and almost works :(

Here's what I get, which I have no idea what causes it.

dmesg output:
[ 380.677434] usb 1-3: New USB device found, idVendor=0b05,
idProduct=1779
[ 380.677445] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 380.677452] usb 1-3: Product: AF9035A USB Device
[ 380.677458] usb 1-3: Manufacturer: Afa Technologies Inc.
[ 380.677463] usb 1-3: SerialNumber: AF01020abcdef12301
[ 380.683361] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.1/input/input15
[ 380.683505] hid-generic 0003:0B05:1779.0004: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-0000:00:12.2-3/input1
[ 380.703807] usbcore: registered new interface driver dvb_usb_af9035
[ 380.704553] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in
cold
state
[ 380.705075] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[ 381.014996] dvb_usb_af9035: firmware version=11.5.9.0
[ 381.015018] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in
warm
state
[ 381.017172] usb 1-3: dvb_usbv2: will pass the complete MPEG2
transport stream to the software demuxer
[ 381.017242] DVB: registering new adapter (Asus U3100Mini Plus)
[ 381.037184] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[ 381.037200] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[ 381.044197] i2c i2c-1: fc2580: i2c rd failed=-5 reg=01 len=1
[ 381.044357] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
loading driver (-19)

I2C communication to tuner chip does not work at all. It tries to read
chip id register but fails. If you enable debugs you will see which
error status af9035 reports.
CONFIG_DVB_USB_DEBUG was enabled, but nothing extra :(


There is likely 3 possibilities:
1) wrong I2C address
Well as linked before, I used it from the 'official' driver, where it
says:
#define FC2580_ADDRESS 0xAC

grepping the entire source of theirs, I then found this in FC2580.c
TunerDescription tuner_FC2580 = {
FC2580_open, /** Function to open tuner. */
FC2580_close, /** Function to close tuner. */
FC2580_set, /** Function set frequency. */
FC2580_scripts, /** Scripts. */
FC2580_scriptSets, /** Length of scripts. */
FC2580_ADDRESS, /** The I2C address of tuner. */
1, /** Valid length of tuner register. */
0, /** IF frequency of tuner. */
True, /** Spectrum inversion. */
0x32, /** tuner id */
};

The only other thing that I recognize is the scripts, which is some init
code (which I asked about below, which should also be right, unless I
made a typo) and the tuner id, which is the first thing in the script
and in my patch defined as AF9033_TUNER_FC2580. No idea of its
significance :)

2) wrong GPIOs
* tuner is not powered on or it is on standby
How/where would I check that?

3) wrong firmware
* it very unlikely that even wrong firmware fails basic I2C...
I know there's a few versions right? the 01 02 etc? But that is mostly
in relation with the af9035 mostly right?


using the following modules.
fc2580 4189 -1
af9033 10266 0
dvb_usb_af9035 8924 0
dvb_usbv2 11388 1 dvb_usb_af9035
dvb_core 71756 1 dvb_usbv2
rc_core 10583 2 dvb_usbv2,dvb_usb_af9035

I'm supprised though that dvb-pll isn't there. Wasn't that a
requirement? [1]

No. dvb-pll is used for old simple 4-byte PLLs. FCI FC2580 is modern
silicon tuner. There is PLL used inside FC2580 for frequency
synthesizer
but no dvb-pll needed as all calculations are done inside that driver.
Silicon tuners are so much more complicated to program than old 4-byte
PLLs, thus own driver is needed for each silicon tuner chip.
Ah, well then the wiki needs a small update ;)

For the tuner 'script' firmware/init bit, I used the 'official' driver
[2].

Also the i2c-addr and clock comes from these files.

Aaah, now I see. At least I2C address is wrong. You use 0xac but should
be 0x56. There is wrong "8-bit" address used. 0xac >> 1 == 0x56.
That I don't understand (as I wrote above) 0xac 'should' be the correct,
but appearantly it needs to be shifted. Why?

Because it is wrong in vendor driver you look. I2C addresses are 7 bit
long and LSB bit used for direction (read or write). Try to search some
I2C tutorials. This kind of wrong I2C addresses are called usually 8-bit
I2C address.




16384000 (16.384MHz) is FC2580 internal clock what I understand. It
should be OK. I suspect that everyone uses it for DVB-T to save
components / make design simple.
I would assume so, since also that is in the original sources; fc2580.c
lists it as:
#define FREQ_XTAL 16384 //16.384MHz


One minor questions I have regarding the recently submitted RTL and
AF9033 drivers, is one uses AF9033_TUNER_* whereas the other uses
TUNER_RTL2832_*. Any reason for this? It just confused me is all.

It is just naming issue driver, driver author decision. Usually names
start with driver name letters (in that case RTL28XXU_). It is not big
issue for variable names unless it is too "general" to conflict some
library. For function names driver names prefix (rtl28xxu_) should be
used as it eases debugging (example ooops is dumped showing function
names).

Ok I will test the shifted i2c address and try that.


Antti


Oliver

[1] http://linuxtv.org/wiki/index.php/DVB_via_USB#Introduction
[2] http://git.schinagl.nl/AF903x_SRC.git/tree/api/FCI_FC2580_Script.h
<snipped patch>





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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux