[00:16] <kbingham> 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)
[00:38] <kbingham> 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 :)
[09:16] <hverkuil> mchehab: I hope you'll start processing pull requests soon. There are quite a lot of them pending :-)
[09:17] <hverkuil> I hope there are no conflicts between my pull requests. Let me know if there are and I'll take a look at it.
[09:26] <mchehab> hverkuil: I'll try to handle at least the ones tagged with FIXES
[09:26] <mchehab> been very busy those days, with several pendencies, due to all those trips
[10:04] <sailus> mripard, jmondi: Could you let me know when there are ov5640 patches I should review (or apply to my tree)?
[10:06] <sailus> 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.
[10:06] <mripard> sailus: the current series I have work on parallel and CSI
[10:06] <sailus> Excellent.
[10:07] <mripard> 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
[10:07] <mripard> I'm leaning towards the latter
[10:07] <sailus> Ok.
[10:07] <mripard> but in any case, I guess you can review those patches
[10:08] <mripard> they should be pretty close to the last iteration
[10:31] <mchehab> sailus: the events patch was not on my fixes branch...
[10:32] <mchehab> I probably applied it after sending the requests_api patchset
[10:33] <mchehab> there are other fixes there pending a pull request
[10:33] <mchehab> mixed with material for 4.21
[10:34] <sailus> mchehab: Ack. Do you have plans to send that to Linus any time soon?
[10:35] <hverkuil> 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
[10:35] <sailus> Greg complained (rightly) the backported patch wasn't yet in upstream. :-\ It'd be nice to be able to tell him it is there...
[10:35] <hverkuil> then paulk-leonov and myself know how to proceed with this (targetting 4.20 or 4.21)
[10:35] <mchehab> I'm figuring out if I should cherry-pick the patches or just reset the fixes branch to another place
[10:36] <mchehab> anyway, I'm targeting to send a PR to Linus this week
[10:36] <sailus> mchehab: Great!
[10:37] <mchehab> hverkuil: probably won't have time today
[10:38] <mchehab> to look at this /9 series and look at this "tag support" issue
[10:39] <mchehab> on a first glance, just the timestamp seems to be enough
[10:40] <hverkuil> 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.
[10:40] <hverkuil> (specific to cedrus, no other drivers are affected)
[10:40] <mchehab> I don't see much issue on that
[10:41] <mchehab> staging drivers changing APIs is something that we use to do
[10:42] <hverkuil> OK, then we won't bother trying to get this right for 4.20. Good.
[10:42] <mchehab> (of course, it is better to make them right at the beginning)
[10:42] <mchehab> yeah. Well, I'd say that, if we have something fixing it for 4.20, better to apply upstream
[10:43] <mchehab> otherwise, nobody will die if we fix it while in staging
[10:44] <hverkuil> 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.
[10:53] <mchehab> ok, works for me
[10:53] <mchehab> sailus: figured out what's pending to be pushed upstream
[10:53] <mchehab> no need to cherry-pick. Also, as everything is already at -next, I can issue a PR today
[11:29] <mchehab> hverkuil: I'll wait until tomorrow before handling the pending PR's
[11:30] <mchehab> better to wait for Linus to merge the fixes PR before adding more fixes on the top of it
[11:34] <hverkuil> ack
[12:19] <mripard> sailus: on the pending patches, the two first patches of media: sun6i: Add support for the H3 CSI controller should be pretty trivial
[12:19] <mripard> it's just adding a compatible to the binding and the driver
[12:20] <mripard> the DT patches need some work, but that won't go through your tree
[12:40] <sailus> mripard: Yeah, seems trivial stuff indeed.
[12:41] <sailus> Was that a comparison to the PHY patches? :-)
[12:41] <mripard> sailus: for example :)
[12:41] <mripard> or the ov5640 stuff you mentionned earlier
[12:41] <sailus> I'll wait for the next version on the ov driver patches. I presume there's little chance of breaking anything?
[12:48] <sailus> mchehab: Would you have a moment?
[12:48] <mchehab> if you're quick
[12:49] <sailus> 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.
[12:49] <sailus> I presume it would be unfeasible to support the existing API behaviour while supporting the request API at the same time.
[12:50] <sailus> At the very least it'd likely require a Kconfig option. I'm not overly enthusiastic about that.
[12:50] <sailus> A Kconfig option, I mean.
[12:50] <mchehab> well, lets add it to staging
[12:51] <sailus> 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.
[12:51] <sailus> There's a catch though.
[12:51] <sailus> The driver uses device specific formats.
[12:51] <sailus> They wouldn't make it to the uAPI headers until the driver gets out of staging.
[12:51] <sailus> Would you be fine with that?
[12:52] <mchehab> yes
[12:52] <sailus> Ack.
[12:52] <sailus> I'll tell them to proceed with that then.
[12:52] <sailus> Obrigado!
[12:52] <mchehab> the only thing that it is important is that someone has to continue working on it
[12:53] <sailus> Yes, I agree.
[12:53] <mchehab> let's try to avoid another atomisp driver where nobody were actually working towards moving it out of staging
[12:53] <sailus> I don't want to see it go to the way of the atomisp. :-I
[12:53] <mchehab> yep
[12:53] <sailus> Lots of work done that results into exactly nothing.
[12:54] <mchehab> please be sure that the TODO list has everything that should be done there
[12:54] <sailus> I have to say that's not even one of my worries.
[12:54] <sailus> Sure.
[12:55] <mchehab> yeah, the Intel people doing the IPU3 driver seem to be committed to have it merged outside staging
[12:55] <sailus> Yes. IMO the driver would be ready for upstream proper with current review comments addressed.
[12:58] <mripard> 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
[12:58] <sailus> mripard: Great!
[12:58] <mripard> sailus: given the lack of documentation though, it's always possible that we broke something
[12:58] <sailus> Yes.
[12:59] <sailus> I have to say I'm positively surprised how precise control you can have over a sensor which has so little documentation. :-)
[13:01] <sailus> mchehab: One more thing.
[13:01] <sailus> The imgu driver requires a new buffer type, META_OUTPUT.
[13:02] <sailus> As it uses it for the parameters.
[13:02] <sailus> But the buffer type as such is not specific to imgu.
[13:02] <sailus> The question would be rather when it'd be needed by another device.
[13:03] <sailus> I just wanted to mention that so it won't come as a surprise.
[13:03] <mchehab> it should be really well documented
[13:03] <mchehab> those META_* buffer types
[13:04] <sailus> Yes, there's ReST + kernel-doc documentation for the parameter struct.
[14:00] <ezequielg> hverkuil: thanks for the review! i will re-spin as soon as possible
[14:09] <hverkuil> ezequielg: my pleasure. After about three days of reviewing I feel I am mostly on top of my patch backlog :-)
[14:12] <ezequielg> hverkuil: one thing that i noticed is that you don't have any branches on linux-next.
[14:12] <ezequielg> have you considered that?
[14:13] <hverkuil> No :-) I rely on Mauro for that. I don't think there is much benefit of having a branch there for me.
[14:18] <ezequielg> early detection of merge conflicts could be a nice benefit
[14:18] <ezequielg> and it seems mostly free for you
[15:28] *** prabhakarlad has left 
[16:44] <mchehab> ezequielg: what's the problem with merge conflicts? I can handle those
[16:46] <mchehab> usually, they're trivial enough to be handled without bothering anyone
[16:46] <mchehab> and it is good to see, specially when it happens between fixes and non-fixes trees
[16:48] <mchehab> btw, Linus merged my PR
[16:48] <mchehab> will handle at least the most trivial pending PRs now
[16:58] <pinchartl> mchehab: patch authors are the most qualified persons to handle merge conflicts, as they have the most knowledge of the related code
[16:59] <pinchartl> when my branch causes a merge conflict, I like to at least oversee the resolution
[17:07] <ezequielg> 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.
[17:08] <ezequielg> 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.
[17:08] <ezequielg> mchehab: you shouldn't have to get bothered by this, imho.
[17:14] <mchehab> 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
[17:16] <ezequielg> sigh, s/overstated/understated... i need some coffee it seems
[17:17] <mchehab> 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
[17:17] <mchehab> 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
[17:18] <mchehab> or after pushing back from upstream
[17:19] <mchehab> ezequielg: in practice, most media users don't rely on linux-next. They rely at the backports tree
[17:20] <mchehab> typically, only developers use linux-next. The vast majority uses a stable Kernel from their distro vendor
[17:21] <mchehab> and that's where the backport tree sits: it allows updating the media subsystem for the distro kernels
[17:21] <ezequielg> yes, I am talking about developers here.
[17:22] <mchehab> very few developers outside the media subsystem really test media stuff
[17:22] <ezequielg> 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.
[17:22] <mchehab> (and when they do, it is usually just the UVC driver)
[17:23] <ezequielg> 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.
[17:24] <mchehab> no, it is not that easy
[17:24] <mchehab> 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)
[17:25] <mchehab> and be sure to have those always updated as they rebase their topic branches
[17:26] <mchehab> In my case, I actually have 3 branches, as I have another one meant to merge conflict-solving patches
[17:28] <mchehab> also, it would likely rise conflicts with the main tree as patches get merged there
[17:38] <mchehab> hverkuil: you should decide if you'll be signining @cisco or @xs4all... right now, several patches have both :-p
[17:45] <hverkuil> 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.
[17:46] <hverkuil> sorry about that.
[17:51] <ezequielg> 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.
[17:52] <mchehab> np, I'll drop one of those here
[17:54] <mchehab> fixes applied