Zoilo Gomez wrote: > Manu Abraham wrote: >> >>>> sounds like you don't have the tone burst working. Looking in there.. >>>> Can you please try the modified burst callback ? You may/may not >>>> need to >>>> play a bit with a bit of sleep after the break in each case. >>>> >>> Sorry Manu, but this is not about diseqc-burst either ... >>> >>> >> >> There are 4 things >> >> 1) 13v/18v (LNB Polarization control) (vp1034_set_voltage) >> 2) 22k tone control (it has OFF/ON) (mb86a16_set_tone) >> 3) burst (A/B unmodulated/modulated) uses 22k modulation >> (mb86a16_send_diseqc_burst) >> 4) diseqc functions (mb86a16_send_diseqc_msg) >> > > Exactly. > >>> Unless our mutual terminology is inconsistent, "diseqc-burst" is a >>> simple enhancement method of controlling an individual 2-state switch, >>> in addition to existing conventional control by 18/13V for pol selection >>> and 22kHz for band selection (see: >>> http://www.eutelsat.com/satellites/pdf/Diseqc/Reference%20docs/bus_spec.pdf). >>> >>> >>> >>> What I need is DiSEqC 1.0 support, as specified in the above document, >>> where the entire control information (sat,pol,band) is being passed by >>> means of a digital message. No voltages or tones. >>> >> >> that one you are looking at send_diseqc_msg. You just managed to confuse >> me with the additional "22kmodulation" in there >> > > ... sorry ...! > >> IIRC, send_msg had been working. need to see what's wrong. (Maybe diseqc >> bus is busy ?) >> Can you add a dumb short sleep (~10 ms) before the for loop and try a >> larger sleep within the for loop (~100 - 200mS) and see whether any >> change in behaviour ? >> >> > > Assuming that you mean the for-loop in send_diseqc_msg: makes no > difference. > > Anyway, it would have surprised me if this had any effect, because the > loop seems to be merely filling a 4-byte hardware buffer with the > message to be sent, and I assume that only when writing 0x90 + msg > length into MB86A16_DCC1, followed by a writeof DISEN (DiSEqC enable?) > to MB86A16_DCCOUT, the hardware is actually being triggered to dispatch > the message. The last part is almost correct except for a slight change. There is a bug in there from my side, don't understand how it worked DISEN = DiSEqC (Mode) enable DISTA = DiSEqC Transaction Activate > > I notice that all other signaling methods are running in parallel > (18/13V, tone bursts etc). Could it be that message dispatch for DiSEqC > is being set up correctly, but then accidentally disabled while in > progress, by one of the other functions? Settings are being poked > straight into the registers as constants, instead of reading back the > actual setting and modifying only the appropriate bit(s). Just a thought. > modified send_msg a bit (didn't compile test yet) static int mb86a16_send_diseqc_msg(struct dvb_frontend *fe, struct dvb_diseqc_master_cmd *cmd) { struct mb86a16_state *state = fe->demodulator_priv; int i; u8 regs = 0x18; if (cmd->msg_len > 6 || cmd->msg_len < 3) return -EINVAL; // Enable DiSEqC Mode with 50% duty cycle if (mb86a16_write(state, MB86A16_DCCOUT, MB86A16_DCCOUT_DISEN) < 0) goto err; // Select DiSEqC and Clock if (mb86a16_write(state, MB86A16_TONEOUT1, 0x5b) < 0) goto err; if (mb86a16_write(state, MB86A16_TONEOUT2, 0x04) < 0) goto err; // Write to registers for (i = 0; i < cmd->msg_len; i++) { if (mb86a16_write(state, regs, cmd->msg[i]) < 0) goto err; regs++; } msleep_interruptible(10); // Load length and transmit if (mb86a16_write(state, MB86A16_DCC1, MB86A16_DCC1_DISTA | cmd->msg_len)) goto err; return 0; err: dprintk(verbose, MB86A16_ERROR, 1, "I2C transfer error"); return -EREMOTEIO; } _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
