jernej: ping
pH5: Can you review this series? https://patchwork.linuxtv.org/project/linux-media/cover/20201112030557.8540-1-mirela.rabulea@oss.nxp.com/
esp. patches 7-10.
hverkuil, I see you reviewing patches, can you take a look in this series https://www.spinics.net/lists/linux-media/msg180810.html
ezequielg: ping
svarbanov: will look at that series today.
ezequielg: what's the status of this series? https://patchwork.linuxtv.org/project/linux-media/cover/20201102190551.1223389-1-adrian.ratiu@collabora.com/
ezequielg: OK to merge into staging? Or do you want a v6? It wasn't completely clear to me.
hverkuil: thank you, I will do that today.
hverkuil: I'd rather not have more apis in staging to be honest with you. I think we understand enough of vp9 to do it properly.
ezequielg: is that something you want to handle, or is that for Adrian in a v6 of the series?
I'd rather have Adrian (or the next one to be assigned) to work on the api , and skip staging. We have enough hardware blocks, and enough information to justify a proper public api .
Or me if time comes, but I would rather not merge it in staging as it is now.
Is it clear to Adrian that that's what you expect him to do? It wasn't obvious to me, so perhaps you should reply to prevent any misunderstandings (i.e. he's waiting for you, you're waiting for him)
mripard: ping
hverkuil: pong
mripard: https://patchwork.linuxtv.org/project/linux-media/cover/20201116125617.7597-1-m.cerveny@computer.org/
I'm picking up patches 1, 4 and 5. Are you responsible for the others?
hverkuil: yep
I'll take them
great!
This has been a productive day, lots of patches reviewed and processed :-)
hverkuil: I'll reply and make sure it's clear.
ezequielg: regarding the v3 MPEG-2 stateless API cleanup: if I understand this correctly this is expected to be the final change before it is moved to uapi, right? Or are more changes to the MPEG 2 api expected?
sailus: series merged. thanks!
mchehab: Obrigado!
there were one or two patches that weren't updated at patchwork
patch 17 and 27
Ack.
I always make a bundle in patchwork of the patches in my PR. When Mauro merges the PR, then I can just look at the bundle and see which patches need to be manually set to Accepted. I found that the easiest method.
hverkuil: do you download the patches from patchwork or do you use them from your e-mailer?
(or via b4?)
patchwork.
ok. So, a feature there that would add a "link: <lore address>" for patches would make sense for you
Three developers, three workflows. :-)
that's the UNIX way :-)
I wonder what the others do.
There must be more ways to do this.
If there are lots of acks, I've had the habit of editing the mbox. But I might switch to b4 at some point, it does have certain advantages.
I'd like to move to b4 on some point, but that would require some time for me to change my scripts
(in my specific case, not 100% convinced if it would be worth, although it will ceirtanly reduce the time for merging some things)
it would be nice if b4 could cope better with patchwork
jernej: ok, found that source of regression, wasn't the driver in the end, sorry for the noise
hverkuil: pong
ndufresne: what was it?
hverkuil: mripard: that series makes VP8 codec being unused on all SoCs
pinchartl: ok, thanks for the heads up. I guess it is msmfb? I can go look at the source myself
well, I'm not 100% sure, but V3s series splits all codecs to be enabled separately
jernej: can you send a patch adding it back/
?
jernej: I was reading the backtrace wrong, confusing cap and out, and turns out that some regression was causing some of the capture buffer not to be dequeued when the request completed
it's quite a pain to have to manage both the request completion and the dequeuing capture
specially when you do delayed dequeue, since you have to deal with out of order request (while the dequeu calls are decode order)
I've sent a revert for 1.18 (which support kernel up to 5.9 I think), and will find a better solution for gstreamer master, which will soon move to 5.11, 5.10 was abandoned in GStreamer, we didn't want to suffer two ABI breaks
I think in the long term, next time we introduce a new codec, I'll just maintain a branch until the kernel API is de-staged
mripard: on second look, it seems that VP8 is now enabled for all SoCs
jernej: unping :-)
mripard: but now it would be probably more readable, to have capability for all codecs, irrespective if V3s supports VP8 or not, right?
jernej: which series makes vp8 being unused?
hverkuil: this patch was made before VP8 was introduced: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=for-v5.11d&id=31d9b9ef8564b54674a0fbe191d10b099e50e5ae
It's very likely that this patch would handle VP8 too, if it have been merged beforehand
Ah yes. If you post a follow-up patch adding VP8, then I'll make sure that goes in as well, on top of that series + your vp8 patch.
hverkuil: you already posted VP8 patch in PR, so I can just do follow up, right?
yes.
hverkuil: mripard: fyi, you should receive patch for Cedrus VP8 capability flag
jernej: have you seen that one before ? https://paste.centos.org/view/3393f6c6
ndufresne: no, how did you trigger it?
fluster + gst
strange, this would mean that buffers are not handled correctly
it looks pretty generic code, not cedrus related
can you try with kasan enabled?
hverkuil: https://paste.centos.org/view/3393f6c6 want to look ?
jernej: if you guide me, I can try it for sure , how do you use / enable that ?
just enable kasan in kernel config, especially options related to memory handling
if something strange happens, you should get a log in dmesg
at least that was my experience some time ago, when I debugged memory corruption in ASoC framework
ok
that time kfree was called on pointer, which was not allocated, but only parent structure was
jernej: got this little problem, HAVE_ARCH_KASAN [=n]
which is required to build it, any idea where I can find detail about this check ?
Kconfig?
it's probably an external dep I'm missing ?
which SoC you have?
there is no arm 32bit support
that's on Tritium, an H3
I'm looking latest linux-next, and arm (32-bit) has support for it
select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
that's from arch/arm/Kconfig
perhaps I need to move to next rather then linuxtv master ....
was grepping HAVE_ARCH_KASAN
must be super recent then ?
idk
ndufresne: it is - ARM: 9017/2: Enable KASan for ARM, dated 2020-10-25 23:56:18
ok, rebased on next now
maybe this alone will change outcome
didn't build, it says I'm missing cache_is_vivt()
looks like missing include, that macro is in arm/iclude/asm/cachetype.h
but I really don't know this area...
indeed, fixed
jernej: no luck, it hangs with "rcu: INFO: rcu_sched self-detected stall on CPU"
sorry, no idea then...
try with -next but without kasan, maybe it's fixed already
ah, but kasan works, it complain about BUG: KASAN: global-out-of-bounds in _get_maxdiv+0x84/0x9c  (called from sun8i_ths_probe)
ha, good to know
yeah, as soon as the NIC is turned on, the system hangs, not a viable kernel
there was few more patches I was missing on linuxtv, let me go back to that kernel, and see if the crash is still thre
ndufresne: you actually found very interesting bug in clock framework with first kasan run :)
really ! (I had no idea what I was pasting ;-P)
jernej: fyi, moving from rc1 to rc3, the vb2 alloc crash is gone
ok, great