Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1642021 > unrolled thread

Re: [PATCH 1/3] [media] si2157: get chip id during probing

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/3] [media] si2157: get chip id during probing Andreas Kemnade <andreas@kemnade.info> - 2017-05-15 22:30 +0200
    Re: [PATCH 1/3] [media] si2157: get chip id during probing Antti Palosaari <crope@iki.fi> - 2017-05-24 11:00 +0200

#1642021 — Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Sun, 23 Apr 2017 15:19:21 +0300
Antti Palosaari <crope@iki.fi> wrote:

> On 03/16/2017 12:22 AM, Andreas Kemnade wrote:
> > If the si2157 is behind a e.g. si2168, the si2157 will
> > at least in some situations not be readable after the si268
> > got the command 0101. It still accepts commands but the answer
> > is just ffffff. So read the chip id before that so the
> > information is not lost.
> > 
> > The following line in kernel output is a symptome
> > of that problem:
> > si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff
> That is hackish solution :( Somehow I2C reads should be get working 
> rather than making this kind of work-around. Returning 0xff to i2c reads 
> means that signal strength also shows some wrong static value?
> 
Also this is needed for the Terratec CinergyTC2.
I see the ff even on windows. So it cannot be solved by usb-sniffing of
a working system, so, again how should we proceed?

a) not support dvb sticks which do not work with your preferred
   order of initialization.

b) change order of initialisation (maybe optionally add a flag like
   INIT_TUNER_BEFORE_DEMOD to avoid risk of breaking other things)

c) something like the current patch.

d) while(!i2c_readable(tuner)) {
     write_random_data_to_demod();
     write_random_data_it9306_bridge();
   }
   remember_random_data();


There was not much feedback here.

An excerpt from my windows sniff logs:
ep: 02 l:   15 GEN_I2C_WR 00 0603c6120100000000
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:    5 042300dcff
ep: 02 l:    9 GEN_I2C_RD 00 0603c6
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:   11 0a240080ffffffffff5b02
ep: 02 l:   15 GEN_I2C_WR 00 0603c6140011070300
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:    5 042500daff
ep: 02 l:    9 GEN_I2C_RD 00 0403c6
ep: 02 l:    0
ep: 81 l:    0
ep: 81 l:    9 08260080ffffff5901

here you see all the ffff from the device.



Regards,
Andreas

[toc] | [next] | [standalone]

#1649325

On 05/15/2017 11:28 PM, Andreas Kemnade wrote:
> Hi,
> 
> On Sun, 23 Apr 2017 15:19:21 +0300
> Antti Palosaari <crope@iki.fi> wrote:
> 
>> On 03/16/2017 12:22 AM, Andreas Kemnade wrote:
>>> If the si2157 is behind a e.g. si2168, the si2157 will
>>> at least in some situations not be readable after the si268
>>> got the command 0101. It still accepts commands but the answer
>>> is just ffffff. So read the chip id before that so the
>>> information is not lost.
>>>
>>> The following line in kernel output is a symptome
>>> of that problem:
>>> si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff
>> That is hackish solution :( Somehow I2C reads should be get working
>> rather than making this kind of work-around. Returning 0xff to i2c reads
>> means that signal strength also shows some wrong static value?
>>
> Also this is needed for the Terratec CinergyTC2.
> I see the ff even on windows. So it cannot be solved by usb-sniffing of
> a working system, so, again how should we proceed?
> 
> a) not support dvb sticks which do not work with your preferred
>     order of initialization.
> 
> b) change order of initialisation (maybe optionally add a flag like
>     INIT_TUNER_BEFORE_DEMOD to avoid risk of breaking other things)
> 
> c) something like the current patch.
> 
> d) while(!i2c_readable(tuner)) {
>       write_random_data_to_demod();
>       write_random_data_it9306_bridge();
>     }
>     remember_random_data();
> 
> 
> There was not much feedback here.

If it is not possible to fix i2c communication then better to add some 
device specific logic to i2c adapter in order to meet demod/tuner 
requirements.


> 
> An excerpt from my windows sniff logs:
> ep: 02 l:   15 GEN_I2C_WR 00 0603c6120100000000
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:    5 042300dcff
> ep: 02 l:    9 GEN_I2C_RD 00 0603c6
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:   11 0a240080ffffffffff5b02
> ep: 02 l:   15 GEN_I2C_WR 00 0603c6140011070300
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:    5 042500daff
> ep: 02 l:    9 GEN_I2C_RD 00 0403c6
> ep: 02 l:    0
> ep: 81 l:    0
> ep: 81 l:    9 08260080ffffff5901
> 
> here you see all the ffff from the device.
> 
> 
> 
> Regards,
> Andreas
> 

regards
Antti



-- 
http://palosaari.fi/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web