Linux Media Controller development
 help / color / mirror / Atom feed
From: Jose Abreu <Jose.Abreu@synopsys.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	Jose Abreu <Jose.Abreu@synopsys.com>,
	<linux-media@vger.kernel.org>
Cc: Hans Verkuil <hans.verkuil@cisco.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>
Subject: Re: [PATCH] [media] cec: GIVE_PHYSICAL_ADDR should respond to unregistered device
Date: Fri, 15 Sep 2017 11:34:15 +0100	[thread overview]
Message-ID: <80045a4a-db2f-d805-0142-9418d012ded6@synopsys.com> (raw)
In-Reply-To: <c77ce39b-a3f0-3eea-6db2-1af99e9e1d7e@xs4all.nl>

Hi Hans,

On 14-09-2017 16:46, Hans Verkuil wrote:
> On 09/14/2017 05:30 PM, Jose Abreu wrote:
>>
>> On 14-09-2017 16:09, Hans Verkuil wrote:
>>> On 09/14/17 15:28, Jose Abreu wrote:
>>>
>>>> Actually, I have at least one more fix which I don't know if it's
>>>> valid and I didn't manage to actually write it in a nice way.
>>>> This one is for CEC 2.0. My test equipment (which is certified)
>>>> in some tests sends msgs only with the opcode. As the received
>>>> msg length does not match the expected one CEC core is rejecting
>>>> the message and my compliance test is failling (test is 4.2.3).
>>> In the HDMI 1.4 spec in CEC 7.3 (Frame Validation) it says that a follower
>>> should ignore frames that are too small.
>>>
>>> At the same time unsupported opcodes should result in a Feature Abort.
>>>
>>> If you don't send a properly formed message, then it's not clear to me
>>> what should happen. Which opcode failed?
>> Hmm, yeah, the spec confirms. The failing opcodes are the ones
>> that have arguments, the test equipment is just sending the
>> header plus opcode. Anyway, for this failing test the MOI for
>> this equipment is not approved so I will probably carry this fix
>> only locally and send it upstream only if the MOI gets approved.
> So is this test just running through all opcodes from 1-255 and see
> what happens? Or is it only doing this for a subset of opcodes?
> And if so, which?

Its running through the opcodes that the sink does not support
and sending only the opcode. By spec sink should respond with
Feature Abort. But, as you said, only sending opcode is out of
spec (for opcodes that have arguments).

>
> I'm just curious to see how this is done.
>
> Which test equipment do you use?

Its a QD980.

Best regards,
Jose Miguel Abreu

>
> We don't actually have any certified CEC 2.0 test equipment, only 1.4,
> so I'm grateful that you did it for me :-)
>
> Regards,
>
> 	Hans
>
>>>> Have you run this test? Did it pass?
>>> No, we haven't. Never got around to that.
>> Ok. I can say that CEC 1.4 + CEC 2.0 all pass compliance with
>> this patch and with my local fix + my test app!
>>
>> Best regards,
>> Jose Miguel Abreu
>>
>>> Regards,
>>>
>>> 	Hans
>>>
>>>> Best regards,
>>>> Jose Miguel Abreu
>>>>
>>>>> Regards,
>>>>>
>>>>> 	Hans

      reply	other threads:[~2017-09-15 10:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14 11:33 [PATCH] [media] cec: GIVE_PHYSICAL_ADDR should respond to unregistered device Jose Abreu
2017-09-14 13:10 ` Hans Verkuil
2017-09-14 13:28   ` Jose Abreu
2017-09-14 15:09     ` Hans Verkuil
2017-09-14 15:30       ` Jose Abreu
2017-09-14 15:46         ` Hans Verkuil
2017-09-15 10:34           ` Jose Abreu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80045a4a-db2f-d805-0142-9418d012ded6@synopsys.com \
    --to=jose.abreu@synopsys.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox