<!-- 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>
***: ChanServ sets mode: +v mchehab`
<br> ChanServ sets mode: +v mchehab
<br> ChanServ sets mode: +v mchehab
<br> ChanServ sets mode: +v mchehab
<br> ChanServ sets mode: +v hverkuil
<br> ChanServ sets mode: +v mchehab
<br> ChanServ sets mode: +v mchehab
mchehab: hi all
hverkuil: <u>mchehab</u>: you're a bit early :-)
mchehab: yeah, I noticed :-)
-: mchehab hates summer time
mchehab: I mean: daylight savings time
<br> it is specially confusing after returning from trips
<br> hi all (this time at the right time)
hverkuil: still three minutes early :-)
mchehab: :-)
<br> better earlier than later
<br> yeah, I set my clock to ring 3 mins earlier
syoung: Hello
mchehab: let me start
sailus: Hello!
mchehab: from my side, the patches for 4.16 were already merged upstream
<br> there was a conflict with vfs, with added some annotations for poll() syscall
hverkuil: I noticed. I've started backporting the CVE fixes for older LTS kernels now that they are in mainline. I hope to have something next week.
mchehab: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b46dc8ae17a427c50c00241898832807576fd28a
hverkuil: Can I send those patches straight to the stable mailinglist, or should I also CC linux-media? There will be 6 of those patch series, so it spams linux-media perhaps a bit too much.
mchehab: the merge itself is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68c5735eaa5e680e701c9a2d1e3c7880bdf5ab66
<br> <u>hverkuil</u>: please c/c linux-media
hverkuil: OK, will do.
mchehab: add something like [PATCH -stable]
<br> for us to be aware that they're just backports
hverkuil: [PATCH for v4.9-stable]?
mchehab: OK
<br> probably, it is not needed to backport vivid changes
hverkuil: I haven't decided yet. I might do it for 4.14, but not the older ones.
<br> The biggest issue is not making the patches, but testing them. So I need a working vivid and v4l2-compliance for those LTS kernels to get the coverage I need in order to be confident that nothing was missed.
<br> We'll see what makes sense.
mchehab: i see
<br> today, I finally discovered why non-UVC video drivers with ISOCH transfers don't work on upstream Kernel on Raspberry Pi 3
<br> basically, all IRQs there have the same priority, and the logic to handle USBs is too expensive
<br> at downstream Kernel, it was solved by using FIQ (it is a higher priority IRQ-like type)
<br> the thing is that FIQ requires special setups (and even some asm code)
<br> probably hard to be merged upstream
<br> (it seems that USB guys already rejected it in the past)
<br> (uvc cameras has a separate issue: controls are broken there, due to the way it caches control values)
<br> not sure if I'll spend more time on it or not
hverkuil: 'controls are broken there': is that an rpi3 issue or a generic uvc issue?
mchehab: it is a generic UVC issue
<br> it doesn't work on USB controllers that has a minimal DMA transfer of 32 bits
<br> as it caches controls using 16 bits and do DMA transfers directly into a cache area
<br> at the wrong order
hverkuil: OK, so specific to certain USB controllers.
mchehab: yes
<br> one possible fix woudl be this: https://patchwork.kernel.org/patch/9630317/ (but it is too expensive for network)
<br> a simpler fix would be to change control cache at UVC to use 32 bits instead of 16
<br> with any such fix, BULK cameras work with UVC
<br> ISOC won't work, as using a micro-frame interval equal to 1 (125 microsseconds) cause frame overruns
<br> as it seems that the IRQ code takes more than 125 us to re-enable IRQs
hverkuil: Lovely.
mchehab: actually, for the IRQ to be triggered again
<br> yep
<br> FIQ solves it, and that's what the RPi downstream driver does
<br> but I've no idea if this won't be impacting on other things
<br> like, for example, affecting MMC block IRQs
<br> s/block/block device/
<br> I did one hack here that would have improved IRQ handling, but it caused MMC errors
<br> anyway, someone would need to convince upstream to accept FIQ and work on the patches for it
<br> with aren't trivial - although the RPi Kernel tree could be used as reference
<br> anyway, I guess we ran OOT :-)
<br> sorry for that
<br> next week, I should be start handling patches again - likely on Mon or Tue
<br> anything I should consider?
hverkuil: I posted two pull requests already and I plan to make some more today/tomorrow.
<br> I would really appreciate it if you could all review this patch series: https://www.mail-archive.com/linux-media@vger.kernel.org/msg125810.html
<br> They all fix little issues found when I wrote the compliance tests for subdevs and the MC.
<br> I'd like to get those in early on so I have a decent starting point for more MC development.
mchehab: ok, I will
sailus: <u>hverkuil</u>: I'll check those as well. Probably tomorrow.
hverkuil: If you maintain subdev/media devices, then please test v4l2-compliance as well for subdevs/media devices. You need that patch series first (otherwise it will fail of course).
<br> I think I've found most bugs in the tests, but there may always be a few lurking.
mchehab: are there any special syntax for v4l2-compliance with MC?
hverkuil: My experience is that the type/function fields are rarely filled in correctly, or at all, so it will often fail on that. With the -v (verbose) flag you can see which entity failed.
<br> <u>Syntax</u>: to test subdevs: v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shorthand)
<br> To test the MC: v4l2-compliance -m /dev/mediaX (or -mX)
<br> To test everything: v4l2-compliance -m /dev/mediaX -M
<br> this will test the MC and all interfaces it finds in the media topology.
<br> (all V4L2 interfaces, that is)
<br> <u>syoung</u>: would there be a need for a lirc-compliance utility?
<br> contact me if you thing that will be useful.
mchehab: yeah, several device drivers didn't care enough to set the type in the past - and such trouble was carried to function setting
<br> -M also tests the related subdevs?
hverkuil: yes
<br> I think v4l2-compliance might be rechristened to media-compliance at some point in the future.
mchehab: ok, good. I would actually make -M default and add a --only-mc (or similar) if someone doesn't want to parse all other devnodes related to MC
<br> that would make our life easier when requesting someone to check for V4L2 compliance
<br> as I'm pretty sure people will forget about adding a -M
hverkuil: Hmm, I could change it: -mX would test all, -MX would only test the media device.
<br> I think that will work better.
mchehab: works for me
hverkuil: In the future when we add new public APIs, I really want to see support for it in the (or 'a') compliance test. I've found way too many issues, both in the core code, in drivers, in documentation and in the MC utilities.
<br> The compliance tests save a huge amount of work in the code review phase, and they will find all the little corner cases that are next to impossible to find in the code review.
mchehab: now that we have a compliance tool for MC, I suspect it shouldn't be hard to keep it updated
<br> btw, what happens if you use it on a hibrid DVB/V4L2 device?
hverkuil: I tried that: lots of fails. I can't remember the details. I saw pads that were neither sink nor source (not sure what to make of that), that's the main thing I remember.
syoung: <u>hverkuil</u>: for lirc, that would be useful I think. It would also be useful to have a tester which verifies the software encoders/decoders over rc-loopback
hverkuil: I tested with an au08<whatever> I think. The pad issue was with the tvp5150.
syoung: <u>hverkuil</u>: lirc-compliance would be small, though.
mchehab: IMHO, the better would be to have a single media-compliance tool, with several "modules"
<br> as, when pointed to a MC node, it will find all sorts of stuff
<br> (radio, video, vbi, dvb, cec, rc, ...)
<br> it would be great to have a single compliance tool to test the device as a hole
hverkuil: That is the intention eventually.
<br> <u>syoung</u>: as long as it tests the API, however small. The MC API is small, but it turns out to be full of bugs.
mchehab: testing the LIRC API is likely the most complex one for RC
<br> the documentation is very spartan
syoung: yes, the documentation does need improving.
mchehab: testing it on a pure DVB device sounds ok: https://pastebin.com/NPUdbGKp
<br> (this device has 2 MC controllers, as it is actually a dual DVB device)
hverkuil: Implemented -m/-M.
mchehab: there is one false positive though
<br> test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
<br> this is not applicable for DVB, as the functions on DVB don't exist as types
hverkuil: So what value do they set in type?
<br> (run with -v to see the type value of the entity in question)
mchehab: it doesn't
hverkuil: You mean type is uninitialized?
mchehab: <u>Entities</u>: 513 Interfaces: 4 Pads: 769 Links: 1024
<br> <u>Entity</u>: demux-tsout #0 (0x00000001)
<br> <u>fail</u>: v4l2-test-media.cpp(88): (function & MEDIA_ENT_TYPE_MASK) == MEDIA_ENT_F_OLD_BASE && function > MEDIA_ENT_T_DEVNODE_DVB
<br> <u>fail</u>: v4l2-test-media.cpp(260): checkFunction(ent.type, false)
<br> test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
hverkuil: Hmm.
<br> sorry, -v didn't do what it should do here. Let me fix that.
mchehab: that's what media-ctl reports: https://pastebin.com/yKhM1qET
<br> everything is marked as type: Node, with an unknown subtype
<br> (probably MEDIA_ENT_T_DEVNODE_DVB ?)
<br> I guess it is MEDIA_ENT_T_DEVNODE_UNKNOWN
<br> yes, very likely
<br> else if (ent->function != MEDIA_ENT_F_IO_V4L)
<br> entd->type = MEDIA_ENT_T_DEVNODE_UNKNOWN;
hverkuil: OK, do git pull, build v4l2-compliance and test again with -v.
<br> The type is now shown.
mchehab: <u>Entities</u>: 513 Interfaces: 4 Pads: 769 Links: 1024
<br> <u>Entity</u>: 0x00000001 (Name: 'demux-tsout #0', Type: 0x0001ffff
<br> <u>fail</u>: v4l2-test-media.cpp(88): (function & MEDIA_ENT_TYPE_MASK) == MEDIA_ENT_F_OLD_BASE && function > MEDIA_ENT_T_DEVNODE_DVB
<br> <u>fail</u>: v4l2-test-media.cpp(261): checkFunction(ent.type, false)
<br> test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
hverkuil: Ah, DEVNODE_UNKNOWN ORs with 0xffff.
<br> let me fix this.
mchehab: #define MEDIA_ENT_T_DEVNODE_UNKNOWN (MEDIA_ENT_T_DEVNODE | \
<br> MEDIA_ENT_SUBTYPE_MASK)
<br> yes
<br> this is a valid type when there is a non-V4L devnode
<br> you should likely cross such check with the G_TOPOLOGY one
<br> e. g. it this happens *and* G_TOPOLOGY reports an unknown function, there is a non-compliance issue
<br> for both ioctls
<br> otherwise, it is just an indication that the MC supports other APIs
pinchartl: <u>hverkuil</u>: regarding types and functions, we have a bunch of drivers failing there, as the patch that added a warning when the function wasn't set didn't bother fixing drivers
<br> (see https://bugzilla.kernel.org/show_bug.cgi?id=111291 for instance)
hverkuil: <u>mchehab</u>: try the latest v4l2-compliance. It should allow DEVNODE_UNKNOWN.
mchehab: <u>hverkuil</u>: an em28xx hybrid device: https://pastebin.com/rsMG8MSe
hverkuil: The checkFunction fail for that hybrid device is probably fixed with the v4l2-compliance commit I just made. I had the same pad fail when I tested it. No idea what to make of it.
mchehab: with that pure DVB device, it now shows: Total: 7, Succeeded: 7, Failed: 0, Warnings: 0
hverkuil: Again, with -v you can see which entity/pad fails exactly.
mchehab: https://pastebin.com/LLGsiJ4e
<br> and again the em28xx device, with the latest version: https://pastebin.com/nULLirKy
<br> indeed the device unknown issue disappeared
<br> only V4L2 had compliance issues there - MC looks OK on both devices
<br> <u>pinchartl</u>: the patch that added a warning just made something that used to happen before explicit: drivers weren't properly setting entity types
<br> and still don't set entity function
<br> fixing it require driver-specific knowledge
<br> I mean: drivers that expose sub-devices should be doing it for a good reason - and should provide the function of the sub-device being exposed
hverkuil: <u>mchehab</u>: I'm still not entirely sure I have all the function/type checks correct. I'll discuss this on #v4l if I have more questions.
pinchartl: <u>mchehab</u>: they were not because the types were not mandatory
<br> as part of your MC rework types became mandatory
<br> but drivers didn't get fixed in that patch series
mchehab: need to go... another meeting
hverkuil: <u>pinchartl</u>: in uvc, do you know what those entities do at all?
pinchartl: <u>hverkuil</u>: to some extent. not for all of them, only for the standard ones
<br> I think I submitted a patch a while ago to add types that I needed, and it was rejected
hverkuil: If you can dig up that patch, then I can take another look at it. See if I can fix this.
<br> It's a nice test of v4l2-compliance as well.
pinchartl: time for a code archeology session :)
<br> 1) Agreed proposed task titles:
<br> Dynamic BRS/BRU allocation in display pipelines @ 3/M (2) [Ki/La]
<br> Port and Run igt on the DU @ 3/M (1) [Uli/(Ja)]
<br> VIN Capture mode update @ 3/M (1) [Nk]
<br> DU interlaced modes support @ 3/M (1) [Uli/(Ja/Ki/La/Nk)]
<br> Upstream DISCOM support @ 3/M (1) [Ja/(Ki/La/Nk)]
<br> 2) Proposed tasks more suitable for completion as part of base task:
<br> Upstream pending VSP patches @ 3/M (2) [Ki/La]
<br> Upstream DU dmabuf import with IPMMU fixes @ 3/M (2) [Ki/La]
<br> 3) Potential mismatch between time assigned and software complexity:
<br> Upstream FCNL support @ 3/M (2) [Ki/La]
<br> 4) Potentially overlapping with existing stuff - needs more discussion:
<br> V3M Eagle display support @ 3/M (1) [Uli/(Ja/Ki/La)]
<br> D3 VIN support (parallel input) @ 3/M (1) [Ja/(Nk)]
<br> oops
<br> wrong channel
<br> my bad
***: kektrain_ has left "iÑÑ.sцреÑиетs.оÑg Ñни sцреÑвоwl"