pinchartl: ping
hverkuil: pong
I'm going through the imx7 series, and I need a bit of clarification of patch 70/77.
let me open it
In the v2 version (not v2.1) you mention "Unlock mutex in mipi_csis_link_setup() error path" in the changes since v1
But it looks like that code has disappeared completely after the switch to v4l2_get_link_freq().
mipi_csis_link_setup() isn't touched at all in v2 (and v2.1)
indeed
what happened is
I first fixed the unlocking issue after v1
and recorded it in the changelog
then I've switched to v4l2_get_link_freq()
which doesn't touch mipi_csis_link_setup() anymore
and I forgot to remove the comment in the changelog
Got it, I thought that that would be the case, but I thought I'd better double check this.
thank you for the review :-)
I'm working on i.MX8 support, but it's not straightforward, I'm struggling with the hardware. the documentation isn't quite complete
hverkuil: Hey there. In case you are around (or something for later), regarding the VP8 uAPI work that I sent yesterday. The API control (it's a single control) is moved to the uapi public header as-is, just documenting things better. The control ID value is changed, as it's now moved to the proper STATELESS_BASE. However, it feels annoying to change the CID without need.
I'm trying to find something a tad better. E.g. we could leave the old CID, marking it as deprecated. Allowing drivers to treat it as an alias.
That would mean existing userspace continue to work as-is (right?)
pinchartl: the series looks good. I am missing Acked-by lines for the bindings patches though, you should probably ping Rob Herring. But if I am not mistaken these binding patches are independent from the other patches in the series, so I can take everything else, right?
hverkuil: that's my understand too, yes
reposting the bindings as a separate series may help getting them picked up by Rob
OK, then I'll do it like that. If it passes my build testing, then you can expect a PR for this series later today minus the bindings patches.
Very nice series, easy to review even though it's 77 patches :-)
\o/
thank you
I did my best :-)
I actually enjoy that kind of cleanups
ezequielg: I don't think there is any point in trying to stay compatible with the old staging API. You are changing names anyway (patch 1/7), so we might as well go the whole way.
I think it also gives a sense of security to applications since they will know that they are using a safe, stable API.
hverkuil: OK, makes sense. BTW, feel free to reject any of those invasive renames and cleaning. I disliked certain things profoundly and it made comparison with the VP8 specification so much easier to have it cleaned.
But they are just cleanups.
pinchartl: posted PR!
hverkuil: thank you !
ezequielg: once these patches finally arrive on the mailinglist, I'll prioritize this. It's nice to have another codec in mainline.
they arrived this morning I think. https://patchwork.linuxtv.org/project/linux-media/list/?series=4730
hmm, they arrived at patchwork, but not in my mailbox...
ah, now I received mails from vger.
I found a regression regarding saa7134 DMAs where the code wouldn't use the sg_dma_len() macro and the IOMMU would complain. saa7146 has the same exact code with presumably the same bug, but I don't have a card to test. Should I do something about it as well?
Sorry, I meant saa7164 instead of saa7146
No, I was right, it's 7146....
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/common/saa7146/saa7146_core.c#n256
KitsuWhooa: yes, just post a patch with the saa7146 fix. I can test if I think that's needed.
Excellent, thank you
since I'm not too familiar, should they be separate patches? For 7134 and 7146
separate, please.
alright, thanks!
hverkuil: ping
you meant add a patch for V4L2_CID_STATELESS_VP8_FRAME before renaming it?
hverkuil: nevermind! unping.