On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> + if (status & CEC_STATUS_TX_DONE) {
> + if (status & CEC_STATUS_TX_ERROR) {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> + cec->tx = STATE_ERROR;
> + } else {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> + cec->tx = STATE_DONE;
> + }
> + s5p_clr_pending_tx(cec);
> + }
Your CEC implementation seems to be written around the idea that there
are only two possible outcomes from a CEC message - "done" and "error",
which get translated to:
> + case STATE_DONE:
> + cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
> + cec->tx = STATE_IDLE;
> + break;
> + case STATE_ERROR:
> + cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
> + cec->tx = STATE_IDLE;
"okay" and "retry_timeout". So, if we have an adapter which can report
(eg) a NACK, we have to report it as the obscure "retry timeout" status?
Why this obscure naming - why can't we have something that uses the
terminology in the spec?
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
