anysee e30 suspend->resume causes wrong profiling of card.

anysee e30 suspend->resume causes wrong profiling of card.

[Hans van den Bogert]

The anysee driver works correctly from cold boot and reinsertion of the device, however, after a suspend resume cycle (S3),  the device suddenly is initated as dvb-t as where it was dvb-c before. Yes this is a combo device, so dvb T and C, but why does the profiling in anysee.c not handle this case? Obviously the following snippet produces a false positive on warm boot and resume:


/* Zarlink ZL10353 DVB-T demod inside of Samsung DNOS404ZH103A NIM */
        adap->fe = dvb_attach(zl10353_attach, &anysee_zl10353_config,
                              &adap->dev->i2c_adap);
        if (adap->fe != NULL) {
                state->tuner = DVB_PLL_THOMSON_DTT7579;
                info("mine: case 2");
                return 0;
        }

I've looked through the rest of the code and by no means am I a developer but, isn't the problem that on warm boots the register of the anysee device doesn't hold the right value in combination with a combo device? because in all the other cases when profiling for different kind of device like the e30c the register is put in a different state before probing for the demuxer.

In the meantime I have commented out the above snippet, which results in a works-for-me. But it isn't a nice solution for the average/new linux user wanting to build a htpc with a anysee combo device.

Tested with ubuntu-lucid module, further tested/compiled with the HG repo.

ps I'm new with mailing lists, is this the right place to post for the anysee driver?

Re: anysee e30 suspend->resume causes wrong profiling of card.

[Antti Palosaari]

Terve Hans,

On 03/14/2012 05:53 PM, Hans van den Bogert wrote:
> The anysee driver works correctly from cold boot and reinsertion of the device, however, after a suspend resume cycle (S3),  the device suddenly is initated as dvb-t as where it was dvb-c before. Yes this is a combo device, so dvb T and C, but why does the profiling in anysee.c not handle this case? Obviously the following snippet produces a false positive on warm boot and resume:

This is known problem. Actually it is coming from wrong GPIOs / 
demodulator selection logic. I just guessed those in the time driver was 
made. Now I have also correct info. Unfortunately I don't even have this 
device currently... IIRC you can blacklist zl10353 driver as workaround.

regards
Antti
-- 
http://palosaari.fi/