mchehab: when would you like to continue the connectors discussion ?
irc is silent today. this is Monday, right ? :-)
0603 ET
EST
pinchartl: mchehab: I'm available the whole day today for connector discussions
hverkuil: while waiting for Mauro's answer, should we try to agree on what to do for media_entity::type ?
pinchartl: I'm preparing a patch series. Let's discuss this after you've seen that. Will post it in a few minutes.
what is it about ? :-)
that would be telling
tell me I'll like it...
pinchartl: posted
the series includes my two patches so I think I'll like it :-D
only the first one, not the second.
right
better than nothing though ;-)
although your patch 5/5 includes my patch 2/2
for media-entity.h, yes. But the name is kept for the drivers.
Best of both worlds, I think.
And we can do fun things with device_caps in the future.
how about using _video_device in the drivers ? as I mentioned _v4l2_io can be useful, but right now the drivers that use the function really mean _video_device, not _v4l2_io
for the vsp1 driver I'll post a patch to use _v4l2_subdev as that's what the driver really wants to check
I really think they are checking for io, not for video_device. They are walking the pipeline, which means they need I/O capable entities.
why do they ?
(granted, for those drivers _v4l2_io will always return the same value as _video_device)
their pipeline is made of two entity types
subdev and video nodes
they walk the pipeline
for two purposes
either performing operations on subdevs and stopping when they find a video node
or count the number of video nodes in the pipeline in order to count the number of users of video nodes
they're really interested in video nodes
and don't care about whether those video nodes can perform I/O
What about drivers/media/platform/exynos4-is/fimc-lite.c? It explicitly associates the entity with DMA.
BTW, I know that in all these cases the check for a video_device will suffice, because we never have cases where you have non-I/O video devices today.
But that might happen in the future, so the question is: are you just testing for whether it is a video_device, or whether it can do I/O and the two just happen to be the same today.
what fimc-lite does is record information about the output path
in its link_setup implementation
the omap3isp driver does so as well, albeit differently
the idea is that some entities (in the hardware sense) have multiple output routes that can be configure
d
they can push data to the next entity in the pipeline
or write to memory through a DMA engine
sometimes only one output path can be selected at a time, sometimes they can be used in parallel
the link_setup function records whether the path to memory is enabled
and looking at the code this actually seems to be implemented wrongly
as there are two output pads
one connected to the DMA engine and the other one connected to the next processing block in the pipeline
I don't think the is_media_entity_v4l2_io() check can ever be false there
the omap3isp, omap4iss and davinci_vpfe drivers really mean is_media_entity_video_device()
I think fimc-lite does, but the opposite could possibly be argued
but for that driver I think the checks can be removed
OK, so make a follow-up patch to my patch series that make the necessary changes to the driver you know really mean is_media_entity_video_device().
sounds good to me
it might render is_media_entity_v4l2_io() unused though :-)
pinchartl: feel free to take my patch series and run with it.
thanks a lot
I hope it doesn't feel like I'm really nitpicking
I think that media-related APIs have been largely abused in the past, and that it's important to be precise now in order to avoid repeating similar mistakes
pinchartl: I agree. It just makes this a bit of a painful process :-)
that I agree with
it would be so much simpler if everybody assumed I was always right of course. you know, the whole dictatorship is wrong unless I'm the dictator argument ;-)
(and I've very thankful for people who prove me wrong, it's definitely needed to keep some level of sanity)
s/for people/to people/
ezequielg: ping
lexano: ping
hverkuil: \o
ezequielg: can you give me the full output of v4l2-compliance for your tw686x driver?
I don't think I ever saw that.
hm, it's in the mail? or did i cutted down?
Also one small question regarding the dma_interval module option: it doesn't state the time unit.
hverkuil: i know, the specs doesn't either :/
i thought that it was better to allow some user control, than just hardcode some value
I saw only part of the compliance output, part of it was cut (up to 'Test input 0')
oh, yes.
pinchartl, hverkuil: I should have time today for the discussions
hverkuil: let me find some time to setup my test machine and i'll send you the full output
i'll reply the original thread, is that ok?
do you have a need to set that value yourself?
Sure
hverkuil: hm, well. that parameter is quite useful as it allows IRQ coalescing.
and it certainly allows to reduce the IRQs per sec, when you are capturing from all the channels
I use the default
mchehab: I'm available now but I'll have a meeting starting in 30 minutes :-/
I'll have time in ~1 hour
would work for me.
I actually prefer to discuss via email
makes easier for Sakari and others to participate
so, if you didn't answer the email yet, please do it
ok