<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
larsc: pong
_jmleo: <u>larsc</u>: regarding the patch https://patchwork.linuxtv.org/patch/30291/ it is a first step towards audio support in ADV76xx
<br> do you know when you could review it, we will send audio support after this one accepted
larsc: I'll try to do it today
_jmleo: cool :)
larsc: 'try' is the important word here ;)
hverkuil: <u>_jmleo</u>: it's on my todo list for today or Monday.
_jmleo: <u>hverkuil</u>: great !
pinchartl: <u>_jmleo</u>: how do you plan to implement the adv76xx DT bindings for audio ?
_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
<br> controlled by the FPGA
<br> very basic
pinchartl: hmmm...
<br> the HDMI audio link is not represented through a phandle in DT :-(
_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
pinchartl: isn't it a bit hackish that the adv7604 "main" driver registers a platform device for its audio codec ?
<br> wouldn't it be better to combine the two drivers into a single one ?
_jmleo: <u>pinchartl</u>: I discussed this point with larsc and I think we implemented what he proposed... Seems a bit difficult to get all in one though
pinchartl: I'm not saying you've done a bad job :-)
<br> more that it seems we're lacking a good infrastructure in the kernel for this
_jmleo: <u>pinchartl</u>: no not at all but I think this is the best solution right now
pinchartl: <u>larsc</u>: ^^
larsc: yeah, no that binding is not good
<br> it exports Linux audio framework implementation details into the DT
<br> but the platform_device for the audio chip is the way to go
<br> this way we can cleanly separate the video and the audio portion
pinchartl: <u>larsc</u>: in order to support video without audio ?
hverkuil: <u>larsc</u>: _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.
pinchartl: I'm more interested in audio support for adv7511 as that's what Renesas needs now
<br> and with DRM, not V4L2
<br> we need proper DT bindings
larsc: <u>pinchartl</u>: yes and in order to be able to put the video support in drivers/media and the audio support in sound/
pinchartl: <u>larsc</u>: the later seems a bit of an artifical restriction to me
<br> and regarding the former
<br> how about audio without video ? :-)
<br> <u>kdebski</u>: ping
<br> re commit f61bf13b6a07a93b9348e77808d369803f40b681 ("[media] vb2: add allow_zero_bytesused flag to the vb2_queue struct")
<br> shouldn't the first check only WARN when using the non-multiplanar API ?
<br> the API explicitly says that b->bytesused must be set to 0 for multiplanar buffers
larsc: <u>pinchartl</u>: that doesn't work with HDMI ;)
pinchartl: damn :-)
hverkuil: <u>pinchartl</u>: are you confusing input and output? For video output bytesused must be set by the application.
pinchartl: <u>hverkuil</u>: for multiplanar buffers v4l2_plane.bytesused must be set by the application
<br> but v4l2_buffer.bytesused must be set to 0
hverkuil: Ah, now I understand.
pinchartl: the API says "For multiplanar formats this field is ignored and the planes pointer is used instead."
<br> and videodev2.h tells to set it to 0
hverkuil: You are right, this check is not correct for multiplanar formats.
pinchartl: the bug was introduced in v4.1-rc1
<br> ouch
hverkuil: Huh, well spotted.
pinchartl: dmesg spotted it for me :-)
<br> patch sent
<br> I wonder if there's still time to fast-track it to v4.1
<br> probably not :-/
<br> <u>mchehab</u>: ping
mchehab: <u>pinchartl</u>: pong
pinchartl: how are you doing ?
mchehab: fine. and you
pinchartl: I'm doing good too
<br> getting ready for the midsummer celebrations this weekend :-)
<br> I've just sent a fix for a bug that was introduced in v4.1-rc1
<br> any chance to get it into v4.1 ?
mchehab: that depends on when Linus will release 4.1
<br> and if linux-next will have a release tomorrow (unlikely, but possible - as this happened in the past close to the merge window)
pinchartl: ok
<br> <u>hverkuil</u>: could you have a look at the patch ?
<br> does it need to go through linux-next ?
<br> it's a fix for v4.1
<br> not a patch for v4.2
hverkuil: sent comments
pinchartl: v2 sent
hverkuil: <u>pinchartl</u>: wow, that's a quick turn-around time for that patch. Three acks in no time!
pinchartl: :-)
<br> <u>mchehab</u>: now it's your turn ;-)
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??...
<br> it's not that there's some logic in place, that only formats from *_enum_*() are accepted that far?
hverkuil: <u>lyakh</u>: 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).
<br> at least, that's how I interpret it.
lyakh: <u>hverkuil</u>: but the "if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)" is before all that checking and correcting...
<br> and it simply takes what the user has sent and returns 0
hverkuil: Huh, that's a good question.
<br> 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.
lyakh: good, so, that's a bug and one shouldn't follow that example :)
_jmleo: <u>hverkuil</u>: ping
<br> do you want a v3 with your ack ? It can be sent right now :D
hverkuil: <u>_jmleo</u>: 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.
_jmleo: yep
<br> but I want a review on audio too in order to take all remarks into account :D
joshi: hey Guys - I'm having trouble building v4l on my Ubuntu Server. Can you help me?
<br> 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?
<br> is anyone there?
headless: <u>joshi</u>: don't you have a list of nicks currently on the channel? :-)
<br> hverkuil and pinchartl are away
<br> mchehab seems to be here
joshi: yes but it's my first time here :)