[23:07] *** roddenberry.freenode.net sets mode: +o ChanServ 
[08:32] <larsc> pong
[08:33] <_jmleo> larsc: regarding the patch https://patchwork.linuxtv.org/patch/30291/ it is a first step towards audio support in ADV76xx
[08:34] <_jmleo> do you know when you could review it, we will send audio support after this one accepted
[08:35] <larsc> I'll try to do it today
[08:36] <_jmleo> cool :)
[08:49] <larsc> 'try' is the important word here ;)
[08:49] <hverkuil> _jmleo: it's on my todo list for today or Monday.
[08:53] <_jmleo> hverkuil: great !
[09:32] <pinchartl> _jmleo: how do you plan to implement the adv76xx DT bindings for audio ?
[09:40] <_jmleo> If you want, it is already implemented right now, see here : https://gitlab.com/veo-labs/linux/blob/veobox/arch/arm/boot/dts/imx6qdl-veobox3.dtsi#L479
[09:40] <_jmleo> controlled by the FPGA
[09:42] <_jmleo> very basic
[09:42] <pinchartl> hmmm...
[09:43] <pinchartl> the HDMI audio link is not represented through a phandle in DT :-(
[09:43] <_jmleo> and https://gitlab.com/veo-labs/linux/blob/veobox/sound/soc/codecs/adv76xx.c and https://gitlab.com/veo-labs/linux/blob/veobox/drivers/media/i2c/adv7604.c
[09:45] <pinchartl> isn't it a bit hackish that the adv7604 "main" driver registers a platform device for its audio codec ?
[09:45] <pinchartl> wouldn't it be better to combine the two drivers into a single one ?
[09:46] <_jmleo> pinchartl: I discussed this point with larsc and I think we implemented what he proposed... Seems a bit difficult to get all in one though
[09:46] <pinchartl> I'm not saying you've done a bad job :-)
[09:46] <pinchartl> more that it seems we're lacking a good infrastructure in the kernel for this
[09:46] <_jmleo> pinchartl: no not at all but I think this is the best solution right now
[09:47] <pinchartl> larsc: ^^
[10:54] <larsc> yeah, no that binding is not good
[10:55] <larsc> it exports Linux audio framework implementation details into the DT
[10:55] <larsc> but the platform_device for the audio chip is the way to go
[10:56] <larsc> this way we can cleanly separate the video and the audio portion
[11:11] <pinchartl> larsc: in order to support video without audio ?
[11:16] <hverkuil> larsc: _jmleo: pinchartl: also take a look at the media/pci/cobalt driver: it has an alsa pcm node for the audio from the adv7604 (and also to an adv7511). It's basically just a front for the DMA engine, but if we improve the adv7604 in this respect, then it should be possible to use that as well from within a driver like that.
[11:18] <pinchartl> I'm more interested in audio support for adv7511 as that's what Renesas needs now
[11:18] <pinchartl> and with DRM, not V4L2
[11:19] <pinchartl> we need proper DT bindings
[11:19] <larsc> pinchartl: yes and in order to be able to put the video support in drivers/media and the audio support in sound/
[11:20] <pinchartl> larsc: the later seems a bit of an artifical restriction to me
[11:20] <pinchartl> and regarding the former
[11:20] <pinchartl> how about audio without video ? :-)
[11:21] <pinchartl> kdebski: ping
[11:21] <pinchartl> re commit f61bf13b6a07a93b9348e77808d369803f40b681 ("[media] vb2: add allow_zero_bytesused flag to the vb2_queue struct")
[11:21] <pinchartl> shouldn't the first check only WARN when using the non-multiplanar API ?
[11:22] <pinchartl> the API explicitly says that b->bytesused must be set to 0 for multiplanar buffers
[11:22] <larsc> pinchartl: that doesn't work with HDMI ;)
[11:23] <pinchartl> damn :-)
[11:24] <hverkuil> pinchartl: are you confusing input and output? For video output bytesused must be set by the application.
[11:24] <pinchartl> hverkuil: for multiplanar buffers v4l2_plane.bytesused must be set by the application
[11:24] <pinchartl> but v4l2_buffer.bytesused must be set to 0
[11:25] <hverkuil> Ah, now I understand.
[11:25] <pinchartl> the API says "For multiplanar formats this field is ignored and the planes pointer is used instead."
[11:25] <pinchartl> and videodev2.h tells to set it to 0
[11:25] <hverkuil> You are right, this check is not correct for multiplanar formats.
[11:25] <pinchartl> the bug was introduced in v4.1-rc1
[11:25] <pinchartl> ouch
[11:26] <hverkuil> Huh, well spotted.
[11:26] <pinchartl> dmesg spotted it for me :-)
[11:49] <pinchartl> patch sent
[11:49] <pinchartl> I wonder if there's still time to fast-track it to v4.1
[11:49] <pinchartl> probably not :-/
[11:51] <pinchartl> mchehab: ping
[11:51] <mchehab> pinchartl: pong
[11:51] <pinchartl> how are you doing ?
[11:51] <mchehab> fine. and you
[11:51] <pinchartl> I'm doing good too
[11:51] <pinchartl> getting ready for the midsummer celebrations this weekend :-)
[11:51] <pinchartl> I've just sent a fix for a bug that was introduced in v4.1-rc1
[11:52] <pinchartl> any chance to get it into v4.1 ?
[11:53] <mchehab> that depends on when Linus will release 4.1
[11:53] <mchehab> and if linux-next will have a release tomorrow (unlikely, but possible - as this happened in the past close to the merge window)
[11:53] <pinchartl> ok
[11:53] <pinchartl> hverkuil: could you have a look at the patch ?
[11:55] <pinchartl> does it need to go through linux-next ?
[11:55] <pinchartl> it's a fix for v4.1
[11:55] <pinchartl> not a patch for v4.2
[11:56] <hverkuil> sent comments
[12:01] <pinchartl> v2 sent
[12:08] <hverkuil> pinchartl: wow, that's a quick turn-around time for that patch. Three acks in no time!
[12:09] <pinchartl> :-)
[12:10] <pinchartl> mchehab: now it's your turn ;-)
[12:13] <lyakh> I'm looking at s5k5baf.c::s5k5baf_set_fmt() and failing to understand, why it simply accepts any format, sent by the user? Including for the FORMAT_TRY case. Can it use _any_ format at all??...
[12:14] <lyakh> it's not that there's some logic in place, that only formats from *_enum_*() are accepted that far?
[12:19] <hverkuil> lyakh: in the PAD_CIS case it is a fixed format, so it just replaces the input with that format, and for the ISP case the s5k5baf_try_isp_format() function will do the check (and if invalid, replace it with something valid).
[12:19] <hverkuil> at least, that's how I interpret it.
[12:21] <lyakh> hverkuil: but the "if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)" is before all that checking and correcting...
[12:21] <lyakh> and it simply takes what the user has sent and returns 0
[12:24] <hverkuil> Huh, that's a good question.
[12:25] <hverkuil> I was afraid for a moment that I introduced that when I did the conversion to v4l2_subdev_pad_config, but it was there already.
[12:26] <lyakh> good, so, that's a bug and one shouldn't follow that example :)
[12:54] <_jmleo> hverkuil: ping
[12:54] <_jmleo> do you want a v3 with your ack ? It can be sent right now :D
[13:15] <hverkuil> _jmleo: well, whenever you are ready. It won't be merged in master until 4.2-rc1 is released and merged in the media_tree master branch.
[13:17] <_jmleo> yep
[13:17] <_jmleo> but I want a review on audio too in order to take all remarks into account :D
[19:33] <joshi> hey Guys - I'm having trouble building v4l on my Ubuntu Server. Can you help me?
[19:34] <joshi> make fails with "./scripts/Makefile.modpost:100: *** target file 'firmware' has both : and :: entries. Stop." I'm running 3.16.0-41-generic x86_64 any advice?
[19:41] <joshi> is anyone there?
[19:49] <headless> joshi: don't you have a list of nicks currently on the channel? :-)
[19:50] <headless> hverkuil and pinchartl are away
[19:50] <headless> mchehab seems to be here
[19:53] <joshi> yes but it's my first time here :)