On 2018-01-16 13:32, Antti Palosaari wrote: > On 01/16/2018 07:31 PM, Brad Love wrote: >> >> On 2018-01-15 23:07, Antti Palosaari wrote: >>> Hello >>> And what is rationale here, is there some use case demod must be >>> active and ts set to tristate (disabled)? Just put demod sleep when >>> you don't use it. >>> >>> regards >>> Antti >> >> Hello Antti, >> >> Perhaps the .ts_bus_ctrl callback does not need to be included in ops, >> but the function is necessary. The demod is already put to sleep when >> not in use, but it leaves the ts bus open. The ts bus has no reason to >> be open when the demod is put to sleep. Leaving the ts bus open during >> sleep affects the other connected demod and nothing is received by it. >> The lgdt3306a driver already tri states its ts bus when put to sleep, >> the si2168 should as well. > > Sounds possible, but unlikely as chip is firmware driven. When you put > chip to sleep you usually want set ts pins to tristate (also other > unused pins) in order to save energy. I haven't never tested it anyway > though, so it could be possible it leaves those pins to some other > state like random output at given time. > > And if you cannot get stream from lgdt3306a, which is connected to > same bus, it really sounds like ts bus pins are left some state > (cannot work if same pin is driven high to other demod whilst other > tries to drive it low. > > Setting ts pins to tri-state during sleep should resolve your issue. Hello Antti, This patch fixes the issue I'm describing, hence why I submitted it. The ts bus must be tristated before putting the chip to sleep for the other demod to get a stream. Cheers, Brad > > > regards > Antti
