Lines Matching defs:mode
25 * - Correct RX DMA generally forces the engine into irq-per-packet mode,
211 /* disable RNDIS mode, also host rx RNDIS autorequest */
450 /* NOTE: DaVinci autoreq is ignored except for host side "RNDIS" mode RX;
537 * irq-per-packet mode very often. RNDIS mode seems to behave too
542 * The main issue with TX mode RNDIS relates to transfer lengths that
553 * On TX, "transparent" mode works ... although experiments have shown
572 /* TX can use the CPPI "rndis" mode, where we can probably fit this
680 * - RX queues in "rndis" mode -- one single BD -- handle (a) correctly, but
683 * not a "true" RNDIS mode. In the RNDIS protocol short-packet termination
686 * implement that mode by default ... which is no accident.)
688 * - RX queues in "transparent" mode -- two BDs with 512 bytes each -- have
695 * - A variant of "transparent" mode -- one BD at a time -- is the only way to
706 * But there seems to be no way to identify the cases where CPPI RNDIS mode
709 * So we can't _ever_ use RX RNDIS mode ... except by using a heuristic
712 * Leaving only "transparent" mode; we avoid multi-bd modes in almost all
714 * since CPPI penalizes our need for a "true RNDIS" default mode.
721 * (a) peripheral mode ... since rndis peripherals could pad their
731 * try rx rndis mode
756 * mode (since it's not a "true" RNDIS mode) with complete safety..
758 * It's ESSENTIAL that callers specify "onepacket" mode unless they kick in
803 /* In host mode, autorequest logic can generate some IN tokens; it's
806 * And always at least two IRQs ... RNDIS mode is not an option.
940 * @mode: For RX, 1 unless the usb protocol driver promised to treat
942 * For TX, ignored because of RNDIS mode races/glitches.
948 u16 maxpacket, u8 mode,
996 cppi_next_rx_segment(musb, cppi_ch, mode);
1447 * (write back mode)
1449 * compare mode by writing 1 to the tx_complete register.
1514 * REVISIT does using rndis mode change that?