[07:41] <hverkuil> mchehab: FYI: the daily build reports a bunch of sparse/smatch warnings/errors for vidtv (see end of https://hverkuil.home.xs4all.nl/logs/Thursday.log)
[07:48] <mchehab> hverkuil: thanks for reporting it. I'll check those
[08:35] <hverkuil> jmondi: mchehab: I'm preparing another PR today, and I just saw Geert's post with an URL for the commit mentioned in 'media: rcar-vin: Mask access to VNCSI_IFMD register'. So I'll fixup the commit log with this URL and add it to the new PR. No need for jmondi to do anything.
[09:17] <jmondi> hverkuil: just read the email!
[09:18] <jmondi> hverkuil: go ahead, I'm pleased not having to send a new version, and sorry for the issue in first place
[10:04] <hverkuil> mchehab: please note my reply to your mail about 'media: uapi: move H264 stateless controls out of staging'. Just making sure you saw it.
[10:16] <mchehab> hverkuil: works for me. I'll add it at the commit message
[10:17] <hverkuil> Great! A lot of people are waiting for stateless H.264 to go public :-)
[10:28] <hverkuil> The first post about 'configuration stores' was on Nov 15 2013: https://lore.kernel.org/linux-media/52862D55.8010406@xs4all.nl/
[10:28] <hverkuil> 7 years ago, how time flies :-)
[10:29] <mchehab> heh
[10:29] <mchehab> ok, description will be:
[10:29] <mchehab> The H.264 stateless 'uAPI' was staging and marked explicitly in the
[10:29] <mchehab> V4L2 specification that it will change and is unstable.
[10:29] <mchehab> Note that these control IDs were never exported as a public API,
[10:29] <mchehab> they were only defined in kernel-local headers (h264-ctrls.h).
[10:29] <mchehab> Now, the H264 stateless controls is ready to be part
[10:29] <mchehab> of the stable uAPI.
[10:29] <mchehab> While not too late, let's rename them and re-number their
[10:29] <mchehab> control IDs, moving them to the newly created stateless
[10:29] <mchehab> control class, and updating all the drivers accordingly.
[10:29] <hverkuil> Ack
[10:29] <mchehab> (merged both yours and ezequielg's comments)
[10:30] <hverkuil> For what it is worth, the same is true for the fwht controls in fwht-ctrls.h.
[10:34] <mchehab> +.. c:type:: v4l2_area
[10:34] <mchehab> +
[10:34] <mchehab> +.. cssclass:: longtable
[10:34] <mchehab> heh, a table with just 2 lines is not a longtable
[10:34] <hverkuil> copy-and-paste :-)
[10:35] <hverkuil> feel free to modify.
[10:35] <mchehab> just did
[10:35] <mchehab> btw, those small tables should really use the standard ascii artwork, instead of flat-table
[10:36] <mchehab> 3 columns, 2 lines fits just fine on an ASCII table
[10:36] <mchehab> I may eventually add a patch at the end of this series
[10:37] <mchehab> or maybe we should do it later on, double-checking where we could use ascii instead of flat-tables
[10:37] <hverkuil> I have another PR in the pipeline that goes on top of this series as well. It's basically waiting for this to be merged.
[10:40] <mchehab> media: vicodec: add V4L2_ prefix before FWHT_VERSION and FWHT_FL_*
[10:40] <mchehab> The FWHT stateless 'uAPI' was staging and marked explicitly in the
[10:40] <mchehab> V4L2 specification that it will change and is unstable.
[10:40] <mchehab> Note that these control IDs were never exported as a public API,
[10:40] <mchehab> they were only defined at the driver's code.
[10:40] <mchehab> While not too late, let's rename them is preparation for promoting
[10:40] <mchehab> the stateless FWHT codec API as a public API.
[10:40] <mchehab> (changed also this FWHT description)
[10:40] <mchehab> patch 18
[10:42] <hverkuil> Ack
[10:43] <mchehab> patch 19:
[10:43] <mchehab> media: vicodec: mark the stateless FWHT API as stable
[10:43] <mchehab> The FWHT stateless 'uAPI' was staging and marked explicitly in the
[10:43] <mchehab> V4L2 specification that it will change and is unstable.
[10:43] <mchehab> Note that these control IDs were never exported as a public API,
[10:43] <mchehab> they were only defined in kernel-local headers (fwht-ctrls.h).
[10:43] <mchehab> Now, the FWHT stateless controls is ready to be part
[10:43] <mchehab> of the stable uAPI.
[10:43] <mchehab> While not too late:
[10:43] <mchehab> - Rename V4L2_CID_MPEG_VIDEO_FWHT_PARAMS to V4L2_CID_STATELESS_FWHT_PARAMS.
[10:43] <mchehab> - Move the contents of fwht-ctrls.h to v4l2-controls.h.
[10:43] <mchehab> - Move the public parts of drivers/media/test-drivers/vicodec/codec-fwht.h
[10:43] <mchehab>   to v4l2-controls.h.
[10:43] <mchehab> - Add V4L2_CTRL_TYPE_FWHT_PARAMS control initialization and validation.
[10:44] <hverkuil> Ack
[10:51] <mchehab> patch series applied, except for the last two ones
[10:51] <mchehab> (Sphinx2 x Sphinx3 breakage)
[10:54] <hverkuil> OK. You will post revised versions of those two patches? You can also just update those patches, that's fine for me as well.
[10:55] <hverkuil> Hmm: 'git grep :c:struct Documentation/' shows nothing, so nobody appears to use :c:struct:
[11:04] <hverkuil> mchehab: there is a bug in drivers/media/i2c/ccs/ccs-data.h: line 34, missing */ for that comment block.
[11:04] <hverkuil> It no longer compiles.
[11:04] <hverkuil> adding back the */ will fix this.
[11:15] <hverkuil> Updated v4l-utils for the uAPI changes (specifically FWHT).
[11:15] <mchehab> scripts/kernel-doc:         print "\n\n.. c:struct:: " . $name . "\n\n";
[11:15] <mchehab> there are two ways of going mentioning a struct ref
[11:15] <mchehab> one is via :c:struct:
[11:16] <mchehab> let me check the alternative one
[11:17] <mort> Say, what would happen if one used one v4l device from multiple threads in a process? If I for example opened the device, configured it, queued the buffers and ran VIDIOC_STREAMON in one thread, then later, in another thread, do the dequeue/re-enqueue loop
[11:17] <mort> Could that potentially be an issue or would it kind of just work?
[11:19] <mchehab> hverkuil: ah! :c:expr:
[11:20] <mchehab> :c:expr:`foo` search for some type at the C domain that matches
[11:20] <hverkuil> mort: that will work, yes.
[11:20] <mchehab> however, automarkup will do this:
[11:21] <mchehab> # Simply convert :c:expr: and :c:texpr: into a literal block.
[11:21] <mchehab> #
[11:21] <mchehab> RE_expr = re.compile(r':c:(expr|texpr):`([^\`]+)`')
[11:21] <mchehab> def markup_c_expr(match):
[11:21] <mchehab>     return '\ ``' + match.group(2) + '``\ '
[11:21] <mchehab> if Sphinx 2.x
[11:21] <mchehab> So, IMO, we could just use "struct foo", as automarkup should be able to use the right macro
[11:22] <mchehab> hverkuil: let me check those better after lunch
[11:23] <hverkuil> mchehab: there is a bug in drivers/media/i2c/ccs/ccs-data.h: line 34, missing */ for that comment block.
[11:23] <hverkuil> can you perhaps fix it in the repo before you have lunch? It's a simple mistake, but it doesn't compile because of that.
[11:28] <mchehab> hverkuil: fixed
[11:31] <hverkuil> much better, thank you!
[11:33] <hverkuil> This is the last PR from me for v5.11: https://patchwork.linuxtv.org/project/linux-media/patch/4bfaa4d3-7b04-3b5c-801c-d68f0765646d@xs4all.nl/
[11:34] <hverkuil> I have no plans for more PRs (except for important bug fixes), everything else can go to 5.12.
[11:55] <ezequielg> hverkuil: mchehab: thanks for the good work on the uapis. I expect to destage mpeg-2 and vp8 for 5.12, which would only leave us with hevc.
[11:57] <mchehab> ezequielg: it would be great to have mpeg2 and vp8 de-staged ;-)
[11:57] <mchehab> hverkuil: Ok. I'll handle it later today
[11:57] <mchehab> let me check first the :c:type: thing
[12:04] <hverkuil> ezequielg: I'm really happy that this is finally in.
[12:04] <ezequielg> :-)
[17:32] <sailus> jmondi: Ping?
[17:51] <jmondi> sailus: pong !
[17:51] <jmondi> sorry, replying to emails and not looking at irc :)
[17:52] <sailus> A minute.
[17:52] <sailus> Signing Christmas cards.
[17:52] <sailus> Back.
[17:53] <sailus> jmondi: I'm trying to understand why some of the same SoCs would appear to have different number of lanes supported.
[17:55] <sailus> I mean, wouldn't the SoC model precisely identify the hardware and its capabilities?
[17:55] <jmondi> I think so, but we have a single compatible in those bindings
[17:55] <jmondi> let me re-fetch the older discussion, we've been though this so many times already -.-
[17:57] <sailus> Chen-Yu wrote that the same compatible string is apparently used for different models if the hardware is the same. But if the number of lanes is different, then isn't it different?
[17:57] <sailus> I have a not so vague feeling something is wrong here.
[17:58] <jmondi> sailus: from the discussion on v2
[17:58] <jmondi> >> is me
[17:58] <jmondi> > is Laurent
[17:58] <jmondi> reply is Dace
[17:58] <jmondi> https://paste.debian.net/1175464/
[17:58] <jmondi> what scares me is Dave mentioning
[17:58] <jmondi> "brcm,bcm2835-unicam-2-lane" and "brcm,bcm2835-unicam-4-lane"
[18:02] <sailus> Yes, but isn't bcm2835 a single SoC?
[18:03] <jmondi> that's what I don't get
[18:03] <jmondi> a single SoC, different data lanes ? My understanding is more likely that not all the available data lanes are routed out in the board
[18:04] <sailus> But then data-lanes tells that.
[18:05] <sailus> Rhea?
[18:08] <jmondi> there might be different board version using the same soc, each board .dts should overwrite data-lanes, but that's expected I guess
[18:09] <sailus> Indeed.
[18:10] <sailus> I'll be back later on.
[18:11] <jmondi> mee too probably
[18:11] <jmondi> pinchartl: ^ if you want to re-have the same discussion again :)
[18:26] <pinchartl> sailus: it's the number of data lanes routed from the unicam IP core to the SoC pins
[18:26] <pinchartl> so it could indeed be inferred from a SoC-specific compatible string
[18:26] <pinchartl> but if the IP core is the same, a DT property seems better to me
[18:27] <pinchartl> as it really describes how the same IP core is integrated in different SoCs
[18:27] <pinchartl> it's thus similar to clocks or interrupts in a way
[21:13] <sailus> pinchartl: Thanks for the explanation.
[21:14] <sailus> I think that seems fairly reasonable as such.
[21:14] <sailus> But it requires you to know, for every board, how many lanes are actually routed in the SoC.
[21:14] <sailus> That's not ideal. It should be as easy as possible, and so a single compatible string is easier to get right.
[21:15] <sailus> Albeit I believe we have a similar arrangement for omap3isp.
[21:15] <sailus> Well, the property value can (and should) come from the SoC specific DT include file.
[21:15] <sailus> So it's not a problem I guess.