| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When | |
|---|---|---|---|
| *** | lyakh has quit IRC (Ping timeout: 245 seconds) | [03:26] | |
| ............. (idle for 1h1mn) | |||
| gnurou | mchehab: re-ping, checking out 1f0545d3ed1d in the current media tree will result in build failure: include/media/v4l2-ctrls.h:31:10: fatal error: media/h264-ctrls.h: No such file or directory
h264-ctrls.h is introduced by the commit that came right after, I think reversing the order of these patches solves the issue | [04:27] | |
| ................................. (idle for 2h44mn) | |||
| bbrezillon | hverkuil: oh, sorry, I missed your reply | [07:12] | |
| .... (idle for 18mn) | |||
| mjourdan | bbrezillon: thanks for the fix, works fine on my end | [07:30] | |
| ............................ (idle for 2h15mn) | |||
| mchehab | gnurou: when I apply patches locally, I build each one individually on a separate window. When they fail, a buzz should play. I probably missed this one - will double check why my scripts didn't alert me...
yet, rebases is something that we avoid, except when absolutely needed as this was fixed on a later patch at the same series, I'll probably let it as-is | [09:45] | |
| ........... (idle for 51mn) | |||
| sailus | mchehab: If you're interested, I can give you one of my 120 dB buzzers so you won't miss those sounds anymore. ;-) A transistor, a small capacitor and perhaps a resistor or two should be enough to connect that to audio output. 12 volts is needed, too. | [10:37] | |
| hverkuil | mchehab: can you prioritize https://patchwork.linuxtv.org/patch/56659/ ? Especially the _MPLANE regression is urgent since it breaks all drivers using V4L2_CAP_VIDEO_M2M_MPLANE. | [10:41] | |
| mchehab | sailus: it is probably related to ALSA playing audio from a remote source
hverkuil: yeah, I'll look on it today I really hated the patch that removed COMPILE_TEST though we should work on a way to re-introduce it at least this is a staging crap | [10:42] | |
| hverkuil | The driver should probably select IMX_IPUV3_CORE.
IMX_IPUV3_CORE is enabled in my daily build, so it does get compile tested there. | [10:48] | |
| mchehab | yeah, but maybe IMX_IPUV3_CORE is not available on other archs
(didn't check yet) | [10:49] | |
| hverkuil | It supports TEST_COMPILE as well. | [10:49] | |
| mchehab | well, then the best would be to add the dependency instead of reverting the compile_test addition | [10:49] | |
| ............................ (idle for 2h15mn) | |||
| sailus | neg: Kunde du prova dessa lappar funkar för dig?
| [13:04] | |
| .... (idle for 18mn) | |||
| neg: s/a\K/ om/ | [13:22] | ||
| ....... (idle for 32mn) | |||
| hverkuil | sailus: I'm getting this smatch warning:
drivers/media/v4l2-core/v4l2-fwnode.c: /home/hans/work/build/media-git/drivers/media/v4l2-core/v4l2-fwnode.c:1101 v4l2_fwnode_reference_parse_int_props() warn: passing zero to 'PTR_ERR' Can you take a look? (this warning probably has been there for quite some time, but I was grepping for "warning:" and not for "warn:". It turns out smatch produces warnings with both prefixes...) /home/hans/work/build/media-git/drivers/media/i2c/ov9640.c: /home/hans/work/build/media-git/drivers/media/i2c/ov9640.c:695 ov9640_probe() warn: passing zero to 'PTR_ERR' Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â /home/hans/work/build/media-git/drivers/media/i2c/ov9640.c: /home/hans/work/build/media-git/drivers/media/i2c/ov9640.c:702 ov9640_probe() warn: passing zero to 'PTR_ERR' Ditto for ov9640.c ^^^ Not sure who maintains that these days. mjourdan: ping | [13:54] | |
| mjourdan | hverkuil: pong | [14:00] | |
| hverkuil | mjourdan: unping
found the answer :-) | [14:00] | |
| mjourdan | unpong :D | [14:00] | |
| hverkuil | mjourdan: real ping
One question for the meson driver: why did you decide to create vdec_ctrls.c/h? It seems more like something that should be in vdec_helpers.c/h. | [14:01] | |
| mjourdan | hverkuil: I just went along with what venus does, to concentrate all ctrl related code in a file
before I removed the volatile flag from V4L2_CID_MIN_BUFFERS_FOR_CAPTURE there was more code there vdec_helpers.c is code aimed at the vdec/codec units rather than v4l2 logic | [14:03] | |
| hverkuil | Looking at this more closely, I think it should just to into vdec.c.
mjourdan: do you expect to add more controls in the future? Or is this it? | [14:05] | |
| mjourdan | true, now that it's limited to only amvdec_init_ctrls
hverkuil: not really, all my WiP code adding h264, hevc, vp9 doesn't add any new control hverkuil: I'll prepare a v10 with vdec_ctrls.c merged into vdec.c. Maybe not post it today in case you or someone else has new input. | [14:09] | |
| hverkuil | mjourdan: ok, then I prefer to have a v10 where vdec_ctrls.c is removed.
v9 passed checkpatch and sparse/smatch, and this is the only issue I noticed when I reviewed v9. | [14:11] | |
| sailus | hverkuil: I can fix both.
They're trivial. | [14:16] | |
| hverkuil | sailus: thanks! | [14:16] | |
| sailus | One could claim they're false positives but nevertheless the code looks cleaner if it's changed. | [14:17] | |
| hverkuil: I've written the patches on top of my fwnode changes but I don't expect them to conflict.
I'll send the patches once I've compile tested them. I'll put them to the fwnode pull request if that's fine. | [14:25] | ||
| hverkuil | sure | [14:32] | |
| ................ (idle for 1h15mn) | |||
| *** | benjiG has left | [15:47] | |
| .... (idle for 16mn) | |||
| mjourdan | hverkuil: alright then, sending v10 now :) | [16:03] | |
| .... (idle for 15mn) | |||
| hverkuil | mjourdan: building now.
mjourdan: out of curiosity: I noticed that I can select this driver both for arm and arm64 architectures. Is it indeed used in both 32 and 64 arm amlogic SoCs? | [16:18] | |
| mjourdan | hverkuil: Currently no, the supported SoCs are all arm64. However some older amlogic arm32 chips also use this IP (with less features), and it's very likely that support will be extended to them in the future | [16:24] | |
| hverkuil | OK, good to know.
Posted PR! Thank you for all your work. | [16:26] | |
| gnurou | mchebab: at your discretion. The only risk is having some failing bisects, but since the patch right after fixes the issue the risk probably remains low. Just wanted to let you know in any case. | [16:28] | |
| hverkuil | BTW, I've posted vicodec patches and I am preparing the corresponding v4l2-compliance patches. I hope these can be committed soon so it is easier to 1) test drivers and 2) work on improving the compliance tests. | [16:28] | |
| mjourdan | Thanks for all the time you took reviewing!
.. and there's a lot more code coming for this one :D. spec compliant h264 decoding will be a good milestone. | [16:29] | |
| hverkuil | mjourdan: my high-level plan is to:
1) update vicodec so it is in sync with the latest v4 decoder spec 2) update v4l2-compliance with the new stateful decoder tests 3) work on adding core support for at least some of the complexity involved to v4l2-mem2mem.c 3b) this might be something we can work on from your side as well, esp. with h264. We'll need some mpeg/h264 test streams (short!) as well for compliance testing. | [16:32] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |