lucaceresoli, I'm sorry for still not having responded to your mails. - everytime I open the mails - we discuss it here - and it takes longer :) (and we've been distracted by being in Vancouver for plumbers and extra travel)
lucaceresoli, Ok - one mail out - theres still anther half baked mail to send - but I have to catch a long haul flight I'm afraid! Hope to get back to you soon :)
mchehab: I hope you'll start processing pull requests soon. There are quite a lot of them pending :-)
I hope there are no conflicts between my pull requests. Let me know if there are and I'll take a look at it.
hverkuil: I'll try to handle at least the ones tagged with FIXES
been very busy those days, with several pendencies, due to all those trips
mripard, jmondi: Could you let me know when there are ov5640 patches I should review (or apply to my tree)?
The patches I've looked at seem fine but I'd like to see them being tested by others as there are different systems that could be easily broken by changes.
sailus: the current series I have work on parallel and CSI
Excellent.
the only thing that jmondi had comments about so far was comments and whether to merge further improvements should be merged as part of this series or as separate patches later on
I'm leaning towards the latter
Ok.
but in any case, I guess you can review those patches
they should be pretty close to the last iteration
sailus: the events patch was not on my fixes branch...
I probably applied it after sending the requests_api patchset
there are other fixes there pending a pull request
mixed with material for 4.21
mchehab: Ack. Do you have plans to send that to Linus any time soon?
mchehab: if you have a minute today, can you read and give your opinion on this: https://www.mail-archive.com/linux-media@vger.kernel.org/msg136525.html
Greg complained (rightly) the backported patch wasn't yet in upstream. :-\ It'd be nice to be able to tell him it is there...
then paulk-leonov and myself know how to proceed with this (targetting 4.20 or 4.21)
I'm figuring out if I should cherry-pick the patches or just reset the fixes branch to another place
anyway, I'm targeting to send a PR to Linus this week
mchehab: Great!
hverkuil: probably won't have time today
to look at this /9 series and look at this "tag support" issue
on a first glance, just the timestamp seems to be enough
mchehab: no need to look at those patches. Just want to know if it is OK to have a staging drivers whose API will change in 4.21.
(specific to cedrus, no other drivers are affected)
I don't see much issue on that
staging drivers changing APIs is something that we use to do
OK, then we won't bother trying to get this right for 4.20. Good.
(of course, it is better to make them right at the beginning)
yeah. Well, I'd say that, if we have something fixing it for 4.20, better to apply upstream
otherwise, nobody will die if we fix it while in staging
If we make cedrus uAPI changes for 4.20, then it is likely we'll have more uAPI changes for 4.21. I'd rather wait until we are all agreed on those changes and just have a single update of the uAPI in 4.21.
ok, works for me
sailus: figured out what's pending to be pushed upstream
no need to cherry-pick. Also, as everything is already at -next, I can issue a PR today
hverkuil: I'll wait until tomorrow before handling the pending PR's
better to wait for Linus to merge the fixes PR before adding more fixes on the top of it
ack
sailus: on the pending patches, the two first patches of media: sun6i: Add support for the H3 CSI controller should be pretty trivial
it's just adding a compatible to the binding and the driver
the DT patches need some work, but that won't go through your tree
mripard: Yeah, seems trivial stuff indeed.
Was that a comparison to the PHY patches? :-)
sailus: for example :)
or the ov5640 stuff you mentionned earlier
I'll wait for the next version on the ov driver patches. I presume there's little chance of breaking anything?
mchehab: Would you have a moment?
if you're quick
The ipu3 driver folks would like to get their driver to upstream, but there could be benefits from supporting request API for the device in the future.
I presume it would be unfeasible to support the existing API behaviour while supporting the request API at the same time.
At the very least it'd likely require a Kconfig option. I'm not overly enthusiastic about that.
A Kconfig option, I mean.
well, lets add it to staging
Another option would be to put the driver to staging now, and get it out of the staging tree once the request API support for the needed features is there.
There's a catch though.
The driver uses device specific formats.
They wouldn't make it to the uAPI headers until the driver gets out of staging.
Would you be fine with that?
yes
Ack.
I'll tell them to proceed with that then.
Obrigado!
the only thing that it is important is that someone has to continue working on it
Yes, I agree.
let's try to avoid another atomisp driver where nobody were actually working towards moving it out of staging
I don't want to see it go to the way of the atomisp. :-I
yep
Lots of work done that results into exactly nothing.
please be sure that the TODO list has everything that should be done there
I have to say that's not even one of my worries.
Sure.
yeah, the Intel people doing the IPU3 driver seem to be committed to have it merged outside staging
Yes. IMO the driver would be ready for upstream proper with current review comments addressed.
sailus: for the ov5640, we've had a decent amount of testing now (3 people on parallel, 2 on MIPI-CSI, at least), so the general case should work pretty well
mripard: Great!
sailus: given the lack of documentation though, it's always possible that we broke something
Yes.
I have to say I'm positively surprised how precise control you can have over a sensor which has so little documentation. :-)
mchehab: One more thing.
The imgu driver requires a new buffer type, META_OUTPUT.
As it uses it for the parameters.
But the buffer type as such is not specific to imgu.
The question would be rather when it'd be needed by another device.
I just wanted to mention that so it won't come as a surprise.
it should be really well documented
those META_* buffer types
Yes, there's ReST + kernel-doc documentation for the parameter struct.
hverkuil: thanks for the review! i will re-spin as soon as possible
ezequielg: my pleasure. After about three days of reviewing I feel I am mostly on top of my patch backlog :-)
hverkuil: one thing that i noticed is that you don't have any branches on linux-next.
have you considered that?
No :-) I rely on Mauro for that. I don't think there is much benefit of having a branch there for me.
early detection of merge conflicts could be a nice benefit
and it seems mostly free for you
ezequielg: what's the problem with merge conflicts? I can handle those
usually, they're trivial enough to be handled without bothering anyone
and it is good to see, specially when it happens between fixes and non-fixes trees
btw, Linus merged my PR
will handle at least the most trivial pending PRs now
mchehab: patch authors are the most qualified persons to handle merge conflicts, as they have the most knowledge of the related code
when my branch causes a merge conflict, I like to at least oversee the resolution
mchehab: well, in fact i overstated the benefits. there are two benefits: 1) by having sub-maintainers trees in linux-next, and given a lot of people use linux-next, you get more test coverage. 2) for developers, it's easy to just start off today's next (i do that all the time) and you have the most updated work, this assumption breaks if maintainers don't put their trees in linux-next.
as for the merge conflict, i think it's much more sensible to see if as soon as the code has been picked by the sub maintainer.
mchehab: you shouldn't have to get bothered by this, imho.
pinchartl: first of all, on a (sub-)maintainers tree, most of the patches are from other developers. Having to ping the patch author for him to fix it is usually counter-productive
sigh, s/overstated/understated... i need some coffee it seems
also, while this is not a general rule, most conflicts happen either between fixes/non-fixes branches or on drivers whose the author is not the patch submitter
when the conflict happen between fixes/non-fixes, it should be visible to the maintainer, because usually such conflict can be solved only during the merge window
or after pushing back from upstream
ezequielg: in practice, most media users don't rely on linux-next. They rely at the backports tree
typically, only developers use linux-next. The vast majority uses a stable Kernel from their distro vendor
and that's where the backport tree sits: it allows updating the media subsystem for the distro kernels
yes, I am talking about developers here.
very few developers outside the media subsystem really test media stuff
e.g. if you are developing against some new code (say request api, or anything else) it's easier to just pick linux-next, than it is to follow the discussion and pick the right tree.
(and when they do, it is usually just the UVC driver)
yes, i'm talking about maybe a humble benefit. but at the same time, adding some Hans, Laurent, Sean, etc -next branch to linux-next is IMHO quite easy.
no, it is not that easy
they would likely need to have two new branches where they'll merge from their topic branches (one for fixes, another one for non-fixes)
and be sure to have those always updated as they rebase their topic branches
In my case, I actually have 3 branches, as I have another one meant to merge conflict-solving patches
also, it would likely rise conflicts with the main tree as patches get merged there
hverkuil: you should decide if you'll be signining @cisco or @xs4all... right now, several patches have both :-p
mchehab: I'm switching from cisco.com to xs4all.nl because messages ended up in my spam folder, so there are still some duplicates due to the transition.
sorry about that.
hverkuil: I don't have too deep information about the rockchip VPU hardware, believe it or not. tfiga might know more about your macroblock padding question.
np, I'll drop one of those here
fixes applied