snawrocki: Dzien dobre!
larsc: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=cec-edid
should solve the CEC bug you found.
larsc: can you test this?
Moikka Sakari ;)
sailus: How are you doing?
hverkuil1: thanks. I can't, but I'll let the person who can know
snawrocki: Fine, thanks!
How about you?
sailus: I'm fine, thank you
About the sub-device (and entity) naming unification patch for Samsung sensors.
Should I be expecting an ack, or postpone the changes for now?
sailus: I'll try to review it today, if it has been copied to s.nawrocki@samsung.com I have not been reading e-mail sent there for several weeks, please use snawrocki@kernel.org if you need quick feedback
snawrocki: I'll bounce it there for you.
sailus: Great, thanks.
Done.
jmondi: On your comment to patch 9 in my fwnode set --- what do you mean? :-)
sailus: that you can you the V4L2_MBUS_PARALLEL_FLAGS macro
sailus: AH! I forgot " _FLAGS" sorry for the confusion
sailus: is this what confused you?
jmondi: Oh, yes.
sorry :)
No worries.
I added the macro orignally as the same set of flags was needed multiple times.
Then due to changes to the patches that no longer was the case but I forgot to remove the macro.
It seems it's indeed used at the moment.
I'll send a new version soon...
sailus: wait, the PARALLEL_MBUS_FLAGS is unused?
I see it being used in the "V4L2_MBUS_BT656" case
and I was suggesting you could use it in the "default" case too
(in the v4l2_fwnode_endpoint_parse_parallel_bus() function)
It was probably unused briefly.
btw, minor issue
sailus: I've tested with parallel bus, and have a patch to use defaults with the CEU... I'll reply by email
Resent.
Nice!
larsc: posted the patches fixing the CEC situation. They are in the same branch (cec-edid), but that's now rebased since the previous version caused bisect problems.
mchehab: I'm confused: did you find some more issues in mripard's "[PATCH] staging: cedrus: Fix checkpatch issues"? https://patchwork.linuxtv.org/patch/52009/
You mentioned that you wanted to comment on it, but I don't see anything (yet?)
Ah, let me guess, this wasn't fixed in the patch: "CHECK: Macro argument reuse 'x' - possible side-effects?"
hverkuil: this was supposed to be fixed as well
mripard: I'd have expected to see, e.g.: #define VE_DEC_MPEG_MP12HDR_F_CODE_MASK(x, y)
change to: #define VE_DEC_MPEG_MP12HDR_F_CODE_MASK(_x, _y)
ignore this
Never mind, I did read the patch correctly.
did -> didn't
It looks good to me, so if mchehab has more comments, then I'm curious to what they are.
ok :)
but I'm not really sure what you were replying to
it was a remark from mchehab over in the media-maint channel.
oh
ok
just answered :-D
sorry, got sidetracked by something else
paulk-leonov: hey
mchehab: should I send an additional version of the checkpatch-patch, or a v10 with your changes will do?
jmondi: I still want to look at removing soc-camera completely, but I haven't had time yet. People keep posting all these new drivers, darn it :-)
mripard: my preference is a new checkpatch-patch, and (if Mauro is OK with it) a v10 with those follow-on patches merged in the main driver patch and with no other changes.
hverkuil: ahah, are you complaning because of too active development :D ?
jmondi: yup.
hverkuil: I know it's more fun concentrating on 10 years old stuff instead of having to deal with all these new hardware and drivers :)
jmondi: to be honest, it is really satisfying to remove code.
So it's worth the effort.
hverkuil: by the way, SH people is still not reactive, so I have a series removing soc_camera symbols from defconfigs pending
hverkuil: ok, doing it now
but driver-wise we should be fine...
hverkuil: maybe we should sync up at ELC-E, if you need any help, or if there's something else pending I'm not aware of
jmondi: specifically soc-camera, or media in general?
hverkuil: soc_camera... I won't dare asking "do you need help" for media in general :)
Well, one thing that needs to be done is to strip soc-camera from old board files that haven't worked for ages since the corresponding soc-camera driver was removed a long time ago.
And that itself isn't the biggest problem, it's finding which maintainers should Ack the patches and which mailinglists to use.
I see, it's dead-old stuff most of the times, hard to find anyone looking after it
mripard: a v10 works for me
but hverkuil prefers otherwise :-)
Yes :-)
mripard: just post the patch for the checkpatch fixes, followed by a v10. No need to wait, I'm sure v2 will be right.
ezequielg, hey there
hverkuil, sorry I've been away from development these days, I'll try to at least follow-up on the spec discussions
thankfully mripard is there to cover for me :)
paulk-leonov: hey! I'm trying to understanding how the sunxi jpeg decoder would use the restart interval. Is it completely stateless?
ezequielg, well, I'm not sure what that restart interval really indicates, need to look up the spec
"The integer number of MCUs processed as an independent sequence within a scan."
ezequielg, looks like it's a legit requirement for decoding, although the value is often 0
ezequielg, would be interesting to know if rockchip VPU can decode images where this is != 0
paulk-leonov: it makes sense for stateful decoders, but for stateless where the userspace is handling the header generation, I can't possibly understand why we'd set a restart interval.
of course, I can be missing something, so please let me know if I am.
ezequielg, ah sorry it seems that I mixed things up -- this is only relevant for decoding, not encoding
does that make more sense?
i know
hm, ok, I think I get it. It has nothing to do with stateful / stateless.
apparently it indicates how many decoding iterations are required, in certain cases
so to be clear, the reason I haven't submitted any controls except quantization is because I don't like pushing unused stuff.
We'll submit when we submit the first decoder.
can sunxi do extended profile encoding / decoding ?
yes that makes sense
ezequielg, not really
it seems to be baseline only
SOF0/SOF1
not anything else
baseline/Extended sequential, Huffman apparently
which probably means custom huff tables
yeah, you always have to support custom huff tables - i think
so, the current out standing issue is how to pass 8-bit vs 16-bit precision controls
given there are some encoders that produce 16-bit quantization for baseline :/
right
and if we want the control to be useful for decoders, we should get that right from start.
agreed
ezequielg, this purely concerns decoding though, right?
I don't think setting the profile makes any sense for decoding, so I definitely think this should be in the control as you did it
or have two controls, either one should do the job
pH5, any idea what this means "ipu1_csi1: EOF timeout"
pH5, I have hooked Nit6X_5MP_MIPI to my SBL, setup the pipeline as documented, but capture fails ....
ndufresne: if you haven't configured the ov5642 to send on virtual channel 1, I'd expect you have to use ipu1_csi0 on i.MX6D/Q
I'm not sure why the example is for VC1, I think the sensor defaults to sending on VC0 if you don't do anything special.
I think the example is for when you have both sensor
but indeed, I only have a 5640
oh, I meant 5640, my bad. 5642 is the parallel one
I'd be curious to understand, what does virtual channel 1 mean in this case ?
(we really need to implement bash completion for media-ctl ..)
mipi csi-2 is packet based, the virtual channel is just a 2-bit value, I think, in the packet headers
so a single link can carry up to four streams simultaneously
does the channel matchs the port number in imx3-mipi-csi2 ?
the i.MX6Q has a fixed mapping from those virtual channels to the actual ipu csi that can receive them (vc0 -> ipu1_csi0, vc1 -> ipu1_csi1, and so on)
(in case that helps, that's the graph I got here, https://paste.fedoraproject.org/paste/3-Qr1JBvk-8KYUbBYdFSDQ)
well, off-by-one.
right, because 0 is a sink pad
at least the sink/src pad thing I'm well trained
and how does ip1_cr0_mux works ?
is it like a input selector ?
yes, exactly. pad 'imx6-mipi-csi2':1 is the vc0 source, enabling the link to 'ipu1_csi0_mux':0 switches the mux to csi-2 input
the unconnected pad 1 is for parallel input
right, I have disabled that one, so I don't see the possible link, but I can imagine now
I never used a media controller before, how dynamic is this ?
do I have to stream off all end-point entity before changing the links ?
in practice, yes. streamon on the video device collects all connected entities into a pipeline and does some link validation, and then any config requests return -EBUSY until streaming stops
there's a per-link 'dynamic' flag for exceptions, but I think nobody uses them yet.
reason I ask, is that if I want to reconfigure without dropping the scannout buffer, I'll have to make a cpu copy of the scanout buffer as the next STREAMON would ebusy if there is a DMABuf that didn't come back
(I don't like much that restriction, it's a bit artificial)
I know, we have the same problem with Mesa/etnaviv aggressively caching imported dmabuf textures (and not freeing them until the next frame is drawn, which doesn't happen until we get a new buffer, catch-22).
yep, something we'll have to push forward
pH5, thanks, works indeed
well, except frames are all black, but that's a detail
ok, the test pattern generator works
start and stop is quite slow, this will need investigation
lol, apparently if you remove the protective sticker it works better, lol
"let there be light"
well, though, automatic gain control does not seem to work, whatever, I don't care that much, it's not that MIPI device we are goign to use
hverkuil1: perhaps we can discuss the JPEG quantization controls tomorrow?
I think having a precision field in the control would cover both 8-bit and 16-bit cases.