On 06/02/17 11:15, Russell King - ARM Linux wrote: > On Fri, Jun 02, 2017 at 06:02:28AM +0100, Jose Abreu wrote: >> You should check that CEC is: not in standy, acknowledges >> broadcast messages, signal free time is 5bit period, and not lost >> arbitration, which basically means CEC_CTRL must be 0x2 and >> IH_CEC_STAT0 must not have ARB_LOST set. > > If ARB_LOST is set, that will trigger an interrupt, and the interrupt > handler will clear the bit. So all the time that the interrupt handler > is present, ARB_LOST should be clear whenever we try to send a message. > > When we enable the CEC interface, we zero the CEC_CTRL register, which > takes the controller out of standby, and initialises the command > register. > > Bits 2:1 select the signal free time, and there's no requirement > specified to require them to be set to '01' before writing the > message - in fact, it's legal for them to be set to other values, > particularly when retrying, which is something I've missed. > > 2-1 Frame Type bit > FRAME_TYP > 00 Signal Free Time = 3-bit periods. Previous > attempt to send frame is unsuccessful. > 01 Signal Free Time = 5-bit periods. New initiator > wants to send a frame. > 10 Signal Free Time = 7-bit periods. Present > initiator wants to send another frame > immediately after its previous frame. (spec > CEC 9.1) > 11 Illegal value. If software write this value, > hardware will set the value to the default 2'b01. The 'signal_free_time' argument of adap_transmit will have the recommended signal free time. You can test against the CEC_SIGNAL_FREE_TIME_* defines from media/cec.h. You probably saw this already, but just in case you missed this... Regards, Hans _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
