s
stdint: sorry, could you rephrase your previous question, you were asking something about predefined structures?
posciak, let me have a try
posciak, I don't what the slice/frame API would be. But I think you would defined something like structure for per codec right?
those structure would be used to store the encoder/decoder settings for stateless VPU right?
stdint: this is already defined and proposed by me
posciak, could you let me a look
I meant could I have a look?
hverkuil1: hello, in cec-test-adapter.cpp testModes function I have a an issue while testing monitor_all mode while been root
my driver don't set CEC_CAP_MONITOR_ALL so I think that the test shouldn't test if the mode is set even if it is running as root
benjiG: just pushed the fix for that to v4l-utils.
That test was obviously wrong if the monitor_all cap wasn't set.
hverkuil1: thanks that fix the last failed
just get a warning while testing topology: "Power Status: warn: cec-compliance.h(345): Waited 1368ms for reply."
for the last try running 'cec-follower' in a separate shell before running cec-compliance -A
benjiG: never mind. It's a valid warning: your TV is too late with the reply.
Replies should arrive (according to the CEC spec) within 1 second.
So this is a compliance issue with your TV.
cec-follower report the driver info  and multiple "Event: State Change: PA: 1.0.0.0, LA mask: 0x0000"
hverkuil1: does it sound good enough to send my driver on mailing list ?
yes
great !
Very nice to see this framework being picked up so quickly.
thanks to have develop it
Do you have any comments about it? Suggestions, things that are unclear?
no it was pretty simple to implement the driver (2-3 days)
That's my experience as well with most CEC hardware (omap4 being the exception, that one was hard)
Still haven't had time to clean that one up and post it :-(
only one very minor comment: on cec_transmit_done prototype I think that the last 4 parameters are useless because it give more or less the same info than the status
It's mostly useful for debugging: some hardware has counters that can tell you which error condition caused a retry. But HW implementations vary wildly in what errors they detect and what they can report.
It is one part of the API that I want to revisit before moving it out of staging.
benjiG: it looks like the hardware doesn't retry transmits?
hverkuil1: no it doesn't do retry
OK. I do see a CEC_FREE_TIME_THRESH register. Is that the Signal Free Time? The cec_transmit passes that as an argument, so if the hardware expects the driver to tell it what the SFT is, then you should probably fill in that register.
Unless the HW handles this automatically, but I suspect it doesn't do that.
from the doc:  CEC_FREE_TIME_THRESH: "Threshold to generate	interrupt request on CEC line idle time counter. The counter counts in units of nominal bit period. On reaching the threshold  count, a status bit CEC_FREE_TIME_IRQ_STS is flagged. "
not really sure that match with signal free time
Hmm, vague. The only reason for something like this would be if the HW doesn't handle SFT at all and expects the SW to wait for this free time interrupt, and then do the transfer.
Does the doc say anything about signal free time handling?
(often CEC documentation is very poor, so my guess is not)
nothing in the doc ...
You should at least add some comments about this in the driver.
My experience with CEC is that it is often an afterthought, but in HW and SW.
Something I hope to improve in the long-term by providing a proper framework and compliance utilities.
Have you tried using cec-compliance with your TV? ('man cec-compliance' gives useful info)
Also a general note about the comments in the driver: please be consistent in adding a space after /* and before */
It's all over the place in your driver.
:-)
yes I have run cec-compliance -A with TV link to my board
Not -A, use -r 0.
-A tests the local adapter, -r tests a remote CEC device.
I.e., the TV.
And with -i you get additional interactive tests.
cec-compliance -r0 => Total: 72, Succeeded: 65, Failed: 7, Warnings: 3
almost all FAILED are timeout failed
benjiG: can you pastebin it somewhere?
hverkuil1: http://pastebin.com/YrrJUxQW
hverkuil1: about signal free time, I think hardware handle it because I have a read-only register to  measure of how many bit periods CEC line was idle
OK.
What is the TV brand/model?
I will add a comment in transmit function about that
Philips 22PFL4208H/12
hverkuil1: any additional remarks before I send version 2 ?
No. I will have to go over v2 in more detail, but it looked fine to me otherwise.
pinchartl: FYI: I'll be at Kernel Recipes for the full three days after all. Looking forward to seeing you there!
hverkuil1: nice!
I'll arrive on Monday evening in Paris, but I'll be busy Monday and Tuesday I'm afraid
including Tuesday evening
I arrive at Paris Nord at 16:35.
but I'm sure you'll find nice people to have dinner with :-)
benjiG: if you post the v3 tomorrow, then I'll make a pull request for 4.9. Otherwise it will almost certainly slip to 4.10.
Just so you are aware :-)
hverkuil1: maybe I can send just this patch now ?
just updating version number for the driver and change nothing for binding, sound good for you ?
tomorrow morning/early afternoon is fine. It makes sense to wait a bit for other comments.
okay just until tomorrow morning then
hverkuil1: would you hav a bit of spare time to review "[PATCH 13/13] v4l: vsp1: wpf: Implement rotation support" ?
it adds support for V4L2_CID_ROTATE in the vsp1 driver
given the recent discussions on the topic I'd like your opinion
as well as mchehab 's opinion
as I intend to send a pull request before the end of the week
I'll drop the patch from the pull request if it's too controversial in order to avoid missing v4.9 for the other patches
pinchartl: that's the same discussion as we had yesterday ;) IMHO, the best is for us to solve the issues related to CTRL changing the buffer size first, before introducing rotate support on new drivers
I kind of expected that answer :-)
I'll exclude that patch from my pull request then
the rest should not be controversial
ok
pinchartl: do you still want me to review it? If so, I'll do it tomorrow morning (and ping me if you haven't seen anything from me by noon)
hverkuil1: I'd appreciate your thoughts on the topic of the rotation control in general, so a review would be nice
hverkuil1: mchehab: sailus: when would you have time to discuss this ?
tomorrow morning/early afternoon would be best for me.
early afternoon your time would work better for Mauro I think
in which time zone are you now ?
CET
so, 5 hours of difference than BRT
right?
GMT+2?
y
yeah, early afernoon then
perfect
that should work for Sakari too
I need to go for an hour
I'll be back