| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | mchehab: ^^^^^ | [08:06] |
| ............. (idle for 1h0mn) | ||
| mchehab | hverkuil: I pushed some fixes patches two days ago... I'm waiting for them to appear at -next
there were no next teee on Jan, 26... and the yesterday's tree were released by the end of the afternoon (only noticed that it was actually released today) if everything went fine, I should be sending a PR today yeah, everything looks fine | [09:06] |
| hverkuil | So that PR will contain the six rkisp1 patches from https://patchwork.linuxtv.org/project/linux-media/patch/f2acebbb-5d2a-e609-817b-58750dda82c8@xs4all.nl/ ? | [09:18] |
| mchehab | e081863ab48d (HEAD -> v4l_for_linus, upstream/fixes, origin/fixes) media: hantro: Fix reset_raw_fmt initialization
eaf18a416514 media: cec: add stm32 driver 73bc0b0c2a96 media: cedrus: Fix H264 decoding a53e3c189cc6 media: v4l2-subdev.h: BIT() is not available in userspace 95e9295daa84 (patchwork/v4l_for_linus) media: Revert "media: videobuf2: Fix length check for single plane dmabuf queueing" e1def45b5291 media: rc: ite-cir: fix min_timeout calculation 9eb09dc2f465 media: venus: core: Fix platform driver shutdown 06b831588b63 media: rc: fix timeout handling after switch to microsecond durations 2984a99ff1c0 media: v4l: common: Fix naming of v4l2_get_link_rate e99a8f0f6344 media: rcar-vin: fix return, use ret instead of zero 1bc0b1baf26e media: ccs: Get static data version minor correctly ff474acc4b1a media: ccs-pll: Fix link frequency for C-PHY 896111dc4bcf media: rc: ensure that uevent can be read directly after rc device register that's what I have for the PR | [09:18] |
| hverkuil | So these are missing the rkisp1 patches from https://patchwork.linuxtv.org/project/linux-media/patch/f2acebbb-5d2a-e609-817b-58750dda82c8@xs4all.nl/ ! | [09:19] |
| mchehab | hmm... it sounds https://patchwork.linuxtv.org/project/linux-media/patch/f2acebbb-5d2a-e609-817b-58750dda82c8@xs4all.nl/ is not there...
weird that it was marked as accepted re-tagged as "New" | [09:19] |
| hverkuil | OK, good that I checked. | [09:20] |
| mchehab | hmm... my scripts marked it as such
pwclient update -s 'Accepted' 71033 # patches/lmml_71033_git_fixes_for_v5_11_rkisp1_uapi_fixes.patch maybe it ended being merged at the main tree | [09:21] |
| hverkuil | it's not there either. | [09:22] |
| mchehab | yes. weird
I don't remember checking this specific PR maybe there were some hash collision unlikely, as this one doesn't have diffstat very weird anyway, thanks for pointing it to me! I'll handle this today, Hopefully we can send the PR tomorrow | [09:22] |
| hverkuil | Thank you! | [09:26] |
| ........ (idle for 35mn) | ||
| Discussion point for today's meeting: I would like to drop support for kernel 3.10-4.3 in media_build. 4.4 is the oldest supported LTS kernel, so that seems a good new cut-off point.
It is getting ever harder to support kernels <4.4, and frankly I can only guarantee that it compiles, I don't even know if it actually works. | [10:01] | |
| ....... (idle for 34mn) | ||
| mchehab | hverkuil: works or me. no need to wait for the today's meeting :-D
with regards to rkisp1 uAPI PR: merged I also sent upstream a PR with the stuf that it was there previously. I should be sending the rkisp1 PR tomorrow (after checking if everything went fine on next). Feel free to remind it if you feel the need | [10:35] |
| hverkuil | mchehab: much appreciated! | [10:38] |
| mchehab | from my side, the minimal Kernel version support by media-build can be anything below or equal to 4.19 (which is the one used at the by Jenkins)
It shouldn't be too hard to change Jenkins build to use some other Kernel version, but using 4.19 makes it simpler to maintain) bbiab | [10:39] |
| ..... (idle for 21mn) | ||
| hverkuil | I want to switch to a model where I do my best to support up to the oldest LTS kernel (as per kernel.org) and drop support for older kernels once the oldest LTS kernel goes EOL. | [11:02] |
| ..... (idle for 21mn) | ||
| mchehab | hverkuil: works for me | [11:23] |
| ....... (idle for 34mn) | ||
| hi all | [11:57] | |
| hverkuil | hi! | [11:57] |
| syoung | hi | [11:58] |
| mchehab | anything for today's meeting? | [11:58] |
| hverkuil | Not from me. | [11:59] |
| syoung | mchehab: Brad Love has resubmitted a new dvb frontend: https://patchwork.linuxtv.org/project/linux-media/patch/20210126015416.5622-2-brad@nextdimension.cc/ | [11:59] |
| sailus | Hyvää huomenta! | [12:00] |
| syoung | There is some pretty dubious endian conversion in there, which I've pointed out in the past. I don't think he's going to fix that. How do feel about accepting it as-is? | [12:00] |
| hverkuil | After this meeting I'll kill of media_build support for kernels 3.10-4.3, unless someone objects.
kill off | [12:00] |
| mchehab | hverkuil: OK | [12:01] |
| hverkuil | syoung: make sure it won't introduce sparse/smatch warnings/errors. I'm trying to keep that to a minimum.
mchehab: that reminds me: the daily build has this sparse warnings for siano: drivers/media/usb/siano/smsusb.c:53:38: warning: array of flexible structures | [12:01] |
| syoung | hverkuil: there are no sparse/smatch errors, I think. But there is some silly patching up of fields endianness | [12:02] |
| mchehab | syoung: well, nothing prevents to merge as-is and add a followup patch using __be/__le stuff | [12:02] |
| syoung | mchehab: OK, that's what I thought too. Thanks. | [12:02] |
| hverkuil | mchehab: The cause is the use of struct urb inside a larger struct: as I understand it struct urb has to be allocated separately. | [12:03] |
| mchehab | but the best would be if he could test after the changes, to be sure that nothing broke
syoung: sometimes, I just merge stuff as-is and do fixes myself | [12:03] |
| syoung | mchehab: problem is, I don't have the hardware to test it | [12:03] |
| mchehab | usually, when asking the developer to fix is more painful than doing myself :-) | [12:04] |
| syoung | but I can submit a patch to the list and ask Brad to test
mchehab: true | [12:04] |
| mchehab | syoung: yeah, feel free to do that
syoung: eventually, you could ask him, instead, if it would be possible to ship you a device with that | [12:04] |
| syoung | ok | [12:05] |
| mchehab | Hauppauge is a vendor that used to donate us some hardware in the past
I would talk with him in priv with that regards | [12:06] |
| syoung | ok | [12:07] |
| mchehab | btw, this specific device is ATSC/QAM only, it seems
so, you won't be able to test it, if you don't have a RF generator (btw, I don't currently have any myself... the ones I used to have were from my past employer) | [12:08] |
| syoung | can anyone help with https://bugzilla.kernel.org/show_bug.cgi?id=204317 ? A datasheet or vendor source or something like that would be helpful
I don't have the hardware either for this | [12:09] |
| mchehab | the dvbsky developer used to be active at the ML
nibble.max@gmail.com | [12:10] |
| syoung | I've emailed him, no response unfortunately | [12:12] |
| mchehab | :-(
Author: Olli Salonen <olli.salonen@iki.fi> Date: Fri Mar 11 03:48:03 2016 -0300 [media] smipcie: add RC map into card configuration options hmm... I guess you could try to reach Olli http://dvbsky.net/download/linux/ still exists maybe you might find something useful at the vendor's tree I have one device from them, but the one I have is USB... not sure if it is here with me (I guess it is, but not 100% sure) if you can't find what you want at the vendor's tree or with Olli, ping me next week anything else for today? | [12:12] |
| hverkuil | Not from me. But see my note above about the single remaining sparse warning for siano. | [12:21] |
| mchehab | (13:02:33) hverkuil: drivers/media/usb/siano/smsusb.c:53:38: warning: array of flexible structures | [12:22] |
| hverkuil | y | [12:22] |
| syoung | mchehab: thanks! | [12:23] |
| mchehab | struct smsusb_urb_t surbs[MAX_URBS];
? that sounds pretty much OK on my eyes #define MAX_URBS 10 this is a const | [12:23] |
| hverkuil | struct smsusb_urb_t contains a struct urb urb, and that's the one with the flexible length.
struct urb should AFAICT always be allocated separately, so this should become a struct urb *urb instead. | [12:24] |
| mchehab | works for me. I have several siano devices, but unfortunately none with me :-(
hmm... struct usb_iso_packet_descriptor iso_frame_desc[]; /* (in) ISO ONLY */ the question here is if this shouldn't be fixed, instead drivers/usb/core/urb.c: urb = kmalloc(struct_size(urb, iso_frame_desc, iso_packets), it seems that URBs are allocated without taking iso_frame_desc into account so, the warning seems to be a false-positive anyway, I agree that the better would be to convert the above to: struct smsusb_urb_t *surbs[MAX_URBS]; and then allocate the URBs dynamically the patch itself would be simple. testing it can be trickier. Maybe we could ask Mkrufky to test it for us he also has several siano-based devs, afaikt anything else for today? | [12:25] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |