Re: [PATCH] Support for Asus MyCinema U3100Mini Plus

[Antti Palosaari <crope@iki.fi>]

On 09/17/2012 06:20 PM, Oliver Schinagl wrote:
> On 17-09-12 15:52, Antti Palosaari wrote:
>> On 09/17/2012 04:26 PM, Oliver Schinagl wrote:
>>> On 17-09-12 15:16, Antti Palosaari wrote:
>>>> On 09/17/2012 04:02 PM, Oliver Schinagl wrote:
>>>>> On 17-09-12 10:25, Oliver Schinagl wrote:
>>>>>> On 17-09-12 01:36, Antti Palosaari wrote:
>>>>>>> On 09/17/2012 01:10 AM, Oliver Schinagl wrote:
>>>>>>>> On 09/16/12 19:25, Antti Palosaari wrote:
>>>>>>>>> On 09/16/2012 06:03 PM, Oliver Schinagl wrote:
>>>>>>>>>> I don't have windows, so capturing using windows is near
>>>>>>>>>> impossible.
>>>>>>>>>> Also since the vendor driver used to work, I guess I will have
>>>>>>>>>> to dig
>>>>>>>>>> into that more.
>>>>>>>>>
>>>>>>>>> You could capture data from Linux too (eg. Wireshark).
>>>>>>>> Ah of course. I'll dig up the old vendor driver and see if I can
>>>>>>>> get it
>>>>>>>> running on 3.2 or better yet, on 3.5/your-3.6. I know there's
>>>>>>>> patches
>>>>>>>> for 3.2 but I've never tested those. Otherwise the older 2.6.2*
>>>>>>>> series
>>>>>>>> should still work.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> But with a little experience you could see those GPIOs reading
>>>>>>>>> existing
>>>>>>>>> Linux driver and then do some tests to see what happens. For
>>>>>>>>> example
>>>>>>>>> some GPIO powers tuner off, you will see I2C error. Changing it
>>>>>>>>> back
>>>>>>>>> error disappears.
>>>>>>>> I have zero experience so I'll try to figure things out. I guess
>>>>>>>> you
>>>>>>>> currently turn on/off GPIO's etc in the current driver? Any line
>>>>>>>> which
>>>>>>>> does this so I can examine how it's done? As for the I2C errors, I
>>>>>>>> suppose the current driver will spew those out?
>>>>>>>
>>>>>>> Those GPIOs are set in file af9035.c, functiuons:
>>>>>>> af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For
>>>>>>> TDA18218 tuner there is no any GPIOs set, which could be wrong
>>>>>>> and it
>>>>>>> just works with good luck OR it is wired/connected directly so that
>>>>>>> GPIOs are not used at all.
>>>>>> Ahah! Then I know what to look for. Since af9035 also has fc0011
>>>>>> support, there should be some similarities I can find.
>>>>> Which I did. I found that the af9033 sets the "gpiot2" o, en and on
>>>>> values high to enable the tuner. Luckly, the fc2580 is routed to the
>>>>> exact same gpio and thus the same tuner enable/disable routine can be
>>>>> used as the FC0011. Appearantly the FC0011 tuner also has a led that
>>>>> needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I
>>>>> found the tuner enable and should be able to incorporate that without
>>>>> issue.
>>>>>
>>>>> The other callback the fc2580 has, is a 'reset'. The fc2580 appears to
>>>>> be lacking such feature, or is not used in the vendor driver.
>>>>>>>
>>>>>>>> Speaking off, in my previous message, I wrote about the driver
>>>>>>>> spitting
>>>>>>>> out the following error:
>>>>>>>> [dvb_usb_af9035]af9035_read_config =_ "%s: [%d]tuner=%02x\012"
>>>>>>>
>>>>>>> It is the tuner ID value got from eeprom. You should take that
>>>>>>> number
>>>>>>> and add it to af9033.h file:
>>>>>>> #define AF9033_TUNER_FC2580    0xXXXX <= insert number here
>>>>>> Yes, but I think %s, %d and %02x\012 should actually list values?
>>>>>> (\012 I belive is \newline)
>>>>> I need to learn dynamic_debug; and I think I may have set it up wrong
>>>>> last time (af9035 and fc2580, but not af9033). I found some good
>>>>> documentation and will try this tonight.
>>>>>>>
>>>>>>>> None of the values where set however. Did I miss-configure
>>>>>>>> anything for
>>>>>>>> it to cause to 'forget' substituting?
>>>>>>>
>>>>>>> What you mean? Could you enable debugs, plug stick in and copy paste
>>>>>>> what debugs says?
>>>>>> I have dynamic debugging enabled and have gotten the above snipped
>>>>>> from the proc/sysfs interface. Also dmesg from replugging I've
>>>>>> attached a few messages back.
>>>>>>
>>>>>> [  188.051502] af9033: firmware version: LINK=12.13.15.0
>>>>>> OFDM=6.20.15.0
>>>>>> [  188.051520] usb 1-3: DVB: registering adapter 0 frontend 0
>>>>>> (Afatech
>>>>>> AF9033 (DVB-T))...
>>>>>> [  188.054019] i2c i2c-1: fc2580_attach: chip_id=5a
>>>>>> [  188.054030] i2c i2c-1: fc2580_attach: failed=0
>>>>>> [  188.054471] i2c i2c-1: fc2580_release:
>>>>>> [  188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
>>>>>> loading driver (-19)
>>>>>>
>>>>>> is the dmesg output from then, which doesn't list the values from the
>>>>>> debugging bit either. I suppose I need more debugging options enabled
>>>>>> to have those flag characters actually filled in?
>>>>
>>>> It should print af9035 debugs too.
>>>>
>>>> usb 2-2: af9035_read_config: [0]tuner=27
>>>>
>>>> modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' >
>>>> /sys/kernel/debug/dynamic_debug/control
>>>>
>>>> modprobe dvb_usb_v2; echo -n 'module dvb_usb_v2 +p' >
>>>> /sys/kernel/debug/dynamic_debug/control
>>>>
>>>> If tuner communication is really working and it says chip id is 0x5a
>>>> then it is different than driver knows. It could be new revision of
>>>> tuner. Change chip_id to match 0x5a
>>>>
>>> Ah, so it's called chip_id on one end, but tuner_id on the other end.
>>> If/when I got this link working properly, I'll write a patch to fix some
>>> naming consistencies.
>>
>> No, you are totally wrong now. Chip ID is value inside chip register.
>> Almost every chip has some chip id value which driver could detect it
>> is speaking with correct chip. In that case value is stored inside
>> fc2580.
>>
>> Tuner ID is value stored inside AF9035 chip / eeprom. It is
>> configuration value for AF9035 hardware design. It says "that AF9035
>> device uses FC2580 RF-tuner". AF9035 (FC2580) tuner ID and FC2580 chip
>> ID are different values having different meaning.
> Ok, I understand the difference between Chip ID and Tuner ID I guess,
> and with my new knowledge about dynamic debug I know also understand my
> findings and where it goes wrong. I also know understand the chipID is
> stored in fc2580.c under the fc2580_attach, where it checks for 0x56.
> Appearantly my chipID is 0x5a. I wasn't triggered by this as none of the
> other fc2580 or af9035 devices had such a change so it wasn't obvious.
> Tuner ID is actively being chechked/set in the source, so that seemed
> more obvious.
>>
>>> The vendor source also slightly more accurately describes
>>> fc2580_init_reg_vals. When writing to 0x45 and 0x4c, it can have
>>> different meanings, it controls the AGC. While the vendor driver always
>>> uses the same bytes the init table uses, there always exists these
>>> differences and its documentation. Is it desired to document this, and
>>> if so where? A comment in the source? A wikipage somewhere? Or does it
>>> simply not matter? See
>>> http://git.schinagl.nl/AF903x_SRC.git/tree/api/fc2580.c#n135 for what I
>>> mean exactly.
>>
>> It does not matter how vendor have implemented it and how I have
>> implemented it if both end up same register value anyway. And even
>> register value is different it could be still correct. Driver does not
>> need to be similar, driver aim is just program chip and it could do
>> totally differently.
>>
>> If you do...
>> write_register(0x1a, 0x12);
>> write_register(0x1b, 0x34);
>> OR
>> write_register(0x1b, 0x34);
>> write_register(0x1a, 0x12);
>> OR
>> write_registers(0x1a, "\x12\x34", 2);
>>
>> all will generally end up similar solution, even all those are done
>> differently.
> No, you misunderstand me here entirely. Although I'm sure in some cases
> order can be of influence, I don't think this is the case. What happens
> in the original driver, upon init of the fc2580 they write some bytes
> over the i2c bus, at one point, (at line 135) there's a simple statement:
> if (ifagc_mode == 1) {
>      write(0x45, 0x10); /* internal AGC */ write(0x4c, 0x00); /*
> HOLD_AGC polarity */
> } else if (ifagc_mode == 2) {
>      write(0x45, 0x20); /* Voltage Control Mode */ write (0x4c, 0x02);
> /* HOLD_AGC polarity */
> } else if(ifagc_mode == 3) {
> write(0x45, 0x30); /* Up/Down Control (Digital AGC) */ write(0x4c,
> 0x02); /* HOLD_AGC polarity */
> }
>
> Thus there is 3 ways to init the fc2580, with 0x45 being 10, 20 or 30.

It is tuner AGC configuration. I suspect could work in any case, but 
performance is surely reduced.
Likely mode == 1 is correct, it is automatic AGC. 2 means control is 
coming outside, like from demod using voltage levels. And 3 means AGC 
which is controlled by steps, one step more / less every time some chip 
PIN is changed. I have never seen DVB stick that uses digital ADC control.

>>> I guess which address goes with which GPIO is far less interesting, as
>>> the gpio name could in theory be different from the actual pin due to
>>> pin multiplexing, right?
>>
>> dunno what you mean
> A microcontroler can change the meaning of a pin at startup. E.g. pin1
> could be GPIO1 or I2C_M, I believe this is set with fuses internal to
> the uC. So while we assume pin1 is always I2C_M, the chip could be
> reconfigured to have pin2 be I2C_M. Or anything really. So documenting
> which address/pin is GPIO1, 2 or 3 isn't that interesting? Or is the
> address always linked to a certain 'meaning' and not pin number?

Yes those pins are very often multipurpose. If there is some unused pin 
it could be used as a GPIO. In real life those are just same pins from 
device to device, because of chip vendor design some reference and 
device vendors just follow that.

>>
>>>>
>>>>>>>>>
>>>>>>>>>> Since all the pieces should be there, fc2580 driver, af9033/5
>>>>>>>>>> driver,
>>>>>>>>>> it's just a matter of glueing things together, right? I'll dig
>>>>>>>>>> further
>>>>>>>>>> into it and see what I can find/do.
>>>>>>>>>
>>>>>>>>> Correct. Tuner init (demod settings fc2580) for is needed for
>>>>>>>>> af9033.
>>>>>>>>> And GPIOs for AF9035. In very bad luck some changes for fc2580 is
>>>>>>>>> needed
>>>>>>>>> too, but it is not very, very, unlikely.
>>>>>>>>>
>>>>>>>>> This patch is very similar you will need to do (tda18218 tuner
>>>>>>>>> support
>>>>>>>>> for af9035):
>>>>>>>>> http://patchwork.linuxtv.org/patch/10547/
>>>>>>>> I re-did my patch using that as a template (before I used your
>>>>>>>> work on
>>>>>>>> the rtl) and got the exact result.
>>>>>>>>
>>>>>>>> Your rtl|fc2580 combo btw (from bare memory) didn't have the
>>>>>>>> fc2580_init
>>>>>>>> stream in af9033_priv.h. What exactly gets init-ed there? The
>>>>>>>> af9033 to
>>>>>>>> work with the fc2580?
>>>>>>>
>>>>>>> You have to add fc2580 init table to file af9033_priv.h. It
>>>>>>> configures all the settings needed for AF9033 demod in order to
>>>>>>> operate with FC2580 tuner. There is some values like "tuner ID"
>>>>>>> which
>>>>>>> is passed for AF9033 firmware, dunno what kind of tweaks it done.
>>>>>>> Maybe calculates some values like signal strengths and AGC
>>>>>>> values. It
>>>>>>> could work without, but at least performance is reduced.
>>>>>> I did add it. I found the init tables in the vendor driver, compared
>>>>>> them to the existing init tables, found that the others where
>>>>>> identical, but offset by 0x8000. I thus copied the table for the
>>>>>> fc2580 and added the address offset.
>>>>>> You can glance over it in the driver patch I submitted last week,
>>>>>> should be there :)
>>>>>>
>>>>>> But since it modified the AF9033, I understand why your rtl driver
>>>>>> didn't have the init table for the fc2580.
>>>>
>>>> If you look comment from the rtl28xxu.c around line 635 you will see
>>>> it.
>>>> /* FIXME: do not abuse fc0012 settings */
>>> I take it, if my patch works, it can be also useful to the rtl28xxu
>>> driver?
>>
>> If there is someday tuner version having different tuner id. Idea of
>> checking that ID is to ensure driver is speaking with chip it know.
>> The language is something that both chip and driver both understand.
>> Hey these are so basic questions I hope you will try to google answers
>> first.
> I think then this is such a day, where there exists another chip ID for
> the FC2580 :) I can read of specifics of the chips, so you can compare
> it to your other FC2580's and see maybe why the chip id is different.
> meanwhile I try to see how compatible the 5a is and how much the vendor
> driver relies on the chip ID.
>
> As for basic questions, Maybe somewhat basic, but certainly not extremly
> basic I would think. Also I wouldn't even know where to start googling
> with such specifics. I did not intend to offend you with my lack of
> knowledge, for that I sincerely appologize :(
>>
>> regards
>> Antti
>>
>
>

Antti


-- 
http://palosaari.fi/