hverkuil: ping
pinchartl: pong (have a meeting in 5 min!)
I'll be quick then
do you have any information regarding the availability of a V4L2 driver for NVidia TX1 and/or TX2 ?
Erm, not sure what I can share.
I'll talk to you privately.
I meant availability of a public driver, so I assume that can be shared publicly :-)
mchehab: when do you plan to accept the last pull request for v4.12 ?
when I have time ;)
I applied several pull requests yesterday
not sure how many are still pending
mchehab: at least two CEC pull requests that I posted today :-)
I should be applying them up to this weekend, hopefully
of submission
I mean what's the deadline to send you a pull request if I want to get it in v4.12 ? :-)
I'll likely handle the last pull requests for 4.12 next week
and pending patches that submaintainers didn cared enough to pick
I'll likely priorize the pending patches next week, though
ok thanks
I'm just a bit worried about the vsp rotation+histogram pull request
I think we're good
merging pull requests at the end, if I have time
but you haven't reviewed the patches on the list as far as I know
and there's little time to resubmit it if you find a problem
yeah, too many work here
pinchartl: can you take another look at Helen's v9 vimc patch? I would really like to get that in. I plan on looking it over again tomorrow as well.
I promised Sakari to review his fwnodes patches first
I'll get to Helen's series next
OK.
pinchartl: hverkuil: thanks. Also, could you take a look in my last comment about V4L2_CAP_MC ?
Will do that as well tomorrow.
ok, thanks
mchehab: for my information where in your queue is the VSP pull request ?
lmml_40540_git_pull_for_v4_12_various_fixes.patch
lmml_40579_git_pull_for_v4_12_uvcvideo_changes.patch
lmml_40586_git_pull_for_v4_12_atmel_isi_ov7670_ov2640_convert_to_standalone_drivers.patch
lmml_40587_git_pull_for_v4_12_renesas_r_car_vsp1_changes.patch
ok, close enough :-)
pinchartl: there are two minor fixes that I need to change in vimc v9, do you prefer me to send a v10 before you start your review or can I just comment in the mail patch ?
koike: you can just comment, no issue
Are patches generally discussed in the same mail thread that git send-mail does? E.g. do I add clarifications and follow-up behavior questions to the same email thread?
pbos: I always answer to the same mail thread, nobody complained so far
koike: Thanks, new to this so it feels more comfy to ask on IRC than in the more official channels.
Probably just a newbie thing.
pbos: yes they are, that's the whole purpose of a mail thread, to group the e-mails from the same discussion :-)
I'll shoot out the patch and see what happens :)
pbos: it's expected that you start a new thread if you re-spin the patches though
javier__: patch updates -> new git send-email?
pbos: yes
gotcha, that's fine
pbos: yes, and you should add a version number in your subject line, i.e: [PATCH v2] foo: bar
pbos: git format-patch has a -v option for that
javier__: Just edit inside the format-patch file?
ah, neat
pbos: I use patman, it's a great tool to keep patch series
well, here goes
will anyone stab me if I reply from Inbox/gmail and it might do html formatting things?
pbos: fyi http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README
pbos: mailing list usually won't accept html formatting, but you can disable it in gmail
usually you receive an auto message from the mailing list saying that you message wasn't send iirc
pbos: yeah, people will complain if your emails are not formated correctly (even if using plain text)
pbos: better to use a saner mailer and follow the advice at Documentation/process/email-clients.rst
javier__: thanks for patman, I heard that there was a tool for managing git patch series, but the ones I found weren't nice
koike: I'll check and see if Inbox supports that, but it's such a slim usecase it might not.
Wonder if it'll send something sane unless I touch formatting buttons, but it feels like I'm playing with fire. :)
koike: yw, it's awesome IMHO
pbos: when I started in the kernel I used gmail with no problems, if you click in compose there is an option called "Plain text mode" (in case you don't want to setup a new mail client only to send a few emails)
koike: Sweet, thanks!
I also found a way to get back to gmail from inbox, so that works :)
theoretically, should I be able to call media_device_unregister(mdev) before calling v4l2_device_unregister_subdev(sd) ? because if I do that, then v4l2_device_unregister_subdev(sd) will call kobject_put() that endsup calling v4l2_device_release() that calls media_device_unregister_entity() again (previous called by media_device_unregister(mdev)). But if I change the order and call media_device_unregister(mdev)
last, my /dev/mediaX node will be in an inconsistent state for a moment no?
and I get a kernel oops when media_device_unregister_entity() is called twice for the same entity
well, don't do it!
larsc, so the right order is v4l2_device_unregister_subdev(sd) first, then media_device_unregister(mdev) last ? But my /dev/mediaX node won't stay in an inconsistent state for a moment? (or maybe this is not a big problem?)
I believe either is supposed to work
larsc: no, if I swap the order it calls media_device_unregister_entity() twice for the same entity
which kernel version are you using?
larsc: 4.11, based on media/master (last commit was Mar 15 c3d4fb0fb41f4b5eafeee51173c14e50be12f839)
I'll update it
I'd expect that to work, but maybe something else is going on.
koike: That worked fine, thanks for the tip.
larsc: right, thanks, I'll investigate a little more and send an email if I find anything wrong
pbos: yw :)
larsc: found it, the problem happen only when debug is active, dev_dbg_obj(gobj) was being called before checkig if gobj->mdev was null, patch sent