| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | posciak1 has quit IRC (Quit: WeeChat 0.4.2) | [00:31] |
| ..................................................................................................... (idle for 8h23mn) | ||
| janaszewski | Hi, one week ago I posted a patch set with libv4l plugin for exynos4 camera (http://www.spinics.net/lists/linux-media/msg96510.html). This is a follow up of the version 5 from February 2015, not reviewed yet. Hans pinged me few months ago about that, so I finally carved out some time and finished it, along with required exynos4-is fixes.
I'd like to ask you guys for a review , so that I know how far from the acceptable form it is. | [08:54] |
| hverkuil | janaszewski: there is one thing that I'd like to see before it is merged: the media controller reorganization is merged in 4.5-rc1 and once it is merged back into our media_tree master I think it is a good idea for you to verify that the plugin works fine with that.
I should, but it is a big change so I think it is wise to double check. | [09:01] |
| janaszewski | hverkuil: sure, I'll check that and provide you with a feedback | [09:02] |
| mchehab | hverkuil: I should be merging it back on master today | [09:03] |
| hverkuil | pinchartl: sailus: does one of you have the time to review that patch series? | [09:03] |
| mchehab | janaszewski: are there any ways for us to test it? | [09:03] |
| hverkuil | mchehab: great! | [09:03] |
| janaszewski | You'd have to have an access to exynos4412-trats2 board (Samsung Galaxy S3 aka M0) | [09:04] |
| .... (idle for 17mn) | ||
| mchehab | janaszewski: yes, I have two M0 here
I don't use them for a while... not sure what tizen versions are installed on them | [09:21] |
| janaszewski | mchebab: you don't need tizen, it can be debian or anything else I think
mchebab: only kernel version should matter - the plugins will not work properly without exynos4-is fixes I also submitted | [09:22] |
| mchehab | janaszewski: ok, I'll take a look on the fixes before compiling a Kernel for it | [09:25] |
| janaszewski | and please note that only pipelines with S5c73m3 camera will work, as it doesn't required external firmware . s5k6a3 sensor require a firmware which hasn't been opened for public use | [09:25] |
| mchehab | ok
I'll email you in priv if I have any issues testing it | [09:26] |
| janaszewski | sure | [09:26] |
| mchehab | I should be doing it later this week or next week... just returned from vacations.... lots of pending stuff ;) | [09:27] |
| janaszewski | sure, not in a hurry :) | [09:27] |
| mchehab | hverkuil: v4.5-rc1 applied and reverted "Postpone the addition of MEDIA_IOC_G_TOPOLOGY" patch
so, we should be able to test and polite the new ioctl, if needed | [09:34] |
| hverkuil | thanks! I'll have a few pending branches with bug fixes/new drivers that I'll rebase and (if no issues) post pull requests for.
s/I'll/I/ | [09:35] |
| mchehab | ok
i got some arm64 boards, so I should be able to test compat32 bits there too I'll merge the mc-nextgen-test tool at libv4l2 to allow more people to test it | [09:35] |
| hverkuil | mchehab: are you accepting driver patches relating to the MC again? | [09:37] |
| mchehab | yes | [09:37] |
| hverkuil | good. | [09:37] |
| ...... (idle for 27mn) | ||
| mchehab | v4l-utils patches added
they basically add mc_nextgen_test tool, with retrieves the topology data via MEDIA_IOC_G_TOPOLOGY, and supports graphviz graph generation, as the ones at: https://mchehab.fedorapeople.org/mc-next-gen/ it also uses libudev by default, if available as converting from major,minor -> /dev/foo is controlled by udev, on systems with udev. It falls back to sysfs, if libudev is not found | [10:04] |
| ................... (idle for 1h33mn) | ||
| updated documentation and tarball
media_build seems broken patch -s -f -N -p1 -i ../backports/api_version.patch 1 out of 1 hunk FAILED | [11:40] | |
| ...... (idle for 27mn) | ||
| ok, media_build is fixed
at least, it is now compiling on Kernel 4.2.7 didn't try to compile for other Kernels | [12:08] | |
| hverkuil | mchehab: I've just started a test run of the daily build. | [12:11] |
| mchehab | good, thanks! | [12:11] |
| CarlFK | sudo modprobe vivi ... modprobe: FATAL: Module vivi not found. - am I missing something, or is it not included? | [12:11] |
| hverkuil | CarlFK: vivi is replaced by the vivid module | [12:12] |
| mchehab | also, vivi/vivid is usually not compiled on distros
it also built on Kernel 4.3.3 | [12:12] |
| CarlFK | hverkuil: thanks.
mchehab: i | [12:13] |
| hverkuil | for what it is worth: the debian sid distro has it. | [12:13] |
| CarlFK | mchehab: its always been included in ubuntu | [12:13] |
| mchehab | interesting
on Fedora, I guess it is included only on the kernel-devel | [12:13] |
| hverkuil | I think distros should enable it: it is a very useful driver to test corner cases in applications that are otherwise next to impossible to reproduce. | [12:14] |
| mchehab | (with is a version of the Kernel with several debug Kconfig symbols added)
hverkuil: I don't think its worth to add at the production-level kernel, but for sure it makes sense to be included on development-level Kernels Fedora does it right: it has two separate Kernel versions, one for production, and another one for development/testing hmm... the kernel with debug enabled is not kernel-devel, it is kernel-debug hmm... it seems that vivid is not enabled on it nowadays | [12:14] |
| hverkuil | We (cisco) use vivid quite a lot for prototyping and testing. Most devs use something debian based, so it is nice that it is enabled by default. | [12:21] |
| javier__ | mchehab: I wonder what's the disadvantage for the user for having too many things built as a module (besides a little more of disk space) | [12:21] |
| mchehab | javier__: it adds more vulnerabilities | [12:22] |
| javier__ | mchehab: true | [12:22] |
| mchehab | from security PoV, the less, the better :)
yet, as vivid is not loaded by default, not really a big issue as someone would need to be root to load it and, if some hacker gets root access, he doesn't need to find any Kernel vulnerability to be root ;) anyway, this is something for distro guys to decide and live with it :-D | [12:23] |
| javier__ | mchehab: nod, my point was that it won't be auto load since there isn't a device registered that matches
mchehab: but you are right that the less the better from a sec pov :) | [12:31] |
| mchehab | javier__: yes, I see your point | [12:32] |
| javier__ | mchehab: btw, now that you are accepting MC patches again, do you want me to resend http://www.spinics.net/lists/devicetree/msg108828.html or should I just patiently wait for it to be handled at some point?
I know you should be buried on emails after your vacation that doesn't have input connectos support in MC yet but that is true for all the other video decoders AFAICT so I believe it could be done as a follow up | [12:35] |
| mchehab | check patchwork
if it is there, no need to resubmit except if it gets non-trivial conflicts | [12:37] |
| javier__ | mchehab: it is in patchwork and no conflicts with v4.5-rc1 since I based on top of your mc-next-gen work
mchehab: thanks for the clarification | [12:42] |
| .... (idle for 17mn) | ||
| mchehab | all patches look ok except for patch 3 | [12:59] |
| javier__ | mchehab: Ok, is splitting the patch enough for now? I guess adding the sink pads could be done as a follow up or do you think that is a blocker for now? | [13:01] |
| mchehab | i'm actually in doubt about that split
mchehab is checking at the datasheet if this is actually a fixup or if it has to do with register TVP5150_MISC_CTL I mean: this driver is know to work for a long time it seems very unlikely that height is twice the value for such long time | [13:01] |
| javier__ | mchehab: but the output is known to be yuv interlaced too
or did I misunderstood | [13:04] |
| mchehab | perhaps the chip does something different on BT656 mode
I don't think it sends interlaced data on the em28xx-based hardware the em28xx has an internal logic to do interlace | [13:05] |
| javier__ | mchehab: let's wait for pinchartl comments since he is the author of that patch
and also was the one who added BT.656 support for the omap3isp driver | [13:07] |
| mchehab | http://www.ti.com/lit/ds/symlink/tvp5151.pdf
page 14 no, page 15 shows the format lines aren't interlaced my guess is that either the hunk is wrong or it applies only when the device is in BT.656 but the datasheet is not clear | [13:11] |
| javier__ | mchehab: sorry I was double checking the datasheet. So yeah, I don't know what happens when using 8-Bit 4:2:2 With Discrete Syncs since I can't test on my board
I thought the output was always interlaced and no progressive, but maybe I was wrong and that is not true when using discrete syncs | [13:26] |
| mchehab | i double-checked: em28xx doesn't call .get_fmt/.set_fmt
so, I guess it should not cause any regressions | [13:28] |
| javier__ | mchehab: Ok | [13:31] |
| ...... (idle for 25mn) | ||
| mchehab | just split the patch and re-send
I should be able to test if the tvp5150 changes broke something or not | [13:56] |
| javier__ | mchehab: Ok, I will
mchehab: any reasons why this one was not accepted? https://patchwork.linuxtv.org/patch/32531/ | [14:01] |
| mchehab | didn't push it yet ;)
done | [14:04] |
| javier__ | mchehab: Ok :) | [14:04] |
| mchehab | I'm marking some MC patches as superseded, because they don't apply cleanly anymore
so, I guess those got applied already, but feel free to double-check javier__: ^ | [14:08] |
| javier__ | mchehab: I will, thanks
and yes, I see some patches that got already applied but are marked as New on patchwork | [14:11] |
| mchehab | shuah: I'll mark all your MC patches that don't belong to the latest series as superseded
please let me know if some patch should be unmarked as such | [14:12] |
| *** | dannas has left | [14:25] |
| .... (idle for 17mn) | ||
| shuah | ok checking now | [14:42] |
| mchehab: Looks good - these patches aren't needed | [14:47] | |
| javier__ | mchehab: checked the superseed patches and all seems OK
*superseded | [14:50] |
| ..... (idle for 23mn) | ||
| mchehab | with regards to tvp5150, something broke since Kernel 4.4
not sure yet if it is due to tvp5150 changes, or due to some X11/GLES change doing more tests here | [15:13] |
| javier__ | mchehab: I see, but that's not related to Laurent and my patches right?
I mean, is not working for you even for v4.5-rc1 ? | [15:16] |
| mchehab | not sure yet | [15:16] |
| javier__ | Ok | [15:16] |
| mchehab | yes, your patches broke tvp5150 | [15:20] |
| javier__ | mchehab: hrm... I tested on the IGEPv2 and had no issues
well, with patch 3/10 | [15:21] |
| mchehab | not applied | [15:22] |
| javier__ | do you know which patch broke exacly? | [15:22] |
| mchehab | not yet | [15:23] |
| javier__ | Ok
sorry for that, I don't know what could be causing the regression | [15:24] |
| mchehab | it should be either the DT patch or the init patch, I guess
it isn't the init patch | [15:26] |
| javier__ | I see, more likely the DT patch since the init one uses devm_gpiod_get_optional() and does nothing if the GPIOs are not found
but again, that patch should be a no-op if !OF | [15:28] |
| mchehab | reverting it doesn't fix the issue
I guess I'll need to bisect | [15:33] |
| javier__ | :(
mchehab: maybe pinchartl patch "[media] tvp5150: Add s_stream subdev operation support" ? | [15:37] |
| mchehab | doing bisect | [15:39] |
| javier__ | Ok | [15:39] |
| mchehab | I'll let you know in a few | [15:39] |
| javier__ | thanks | [15:39] |
| mchehab | [dd3a46bbbe1d49a70a66d95a435a729f7ecd7e8f] [media] tvp5150: Add g_mbus_config subdev operation support | [15:41] |
| no, reverting it didn't change anything | [15:47] | |
| javier__ | mchehab: yeah, I don't see a v4l2_subdev_call() call for g_mbus_config in the em28xx driver so it shouldn't affect it | [15:47] |
| mchehab | yes, me neither | [15:48] |
| javier__ | mchehab: have to leave for 30 min to do a bank errand, bbiab | [15:52] |
| mchehab | Revert "[media] tvp5150: Add s_stream subdev operation support"
this worked | [15:52] |
| javier__ | mchehab: right, that was my suspicious since is the most intrusive change, it sets the output format to BT.656 by default
mchehab: probably has to be discrete syncs by default? | [15:54] |
| mchehab | yes, but it also does:
- /* Initializes TVP5150 to its default values */ - /* # set PCLK (27MHz) */ - tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00); | [15:54] |
| javier__ | mchehab: right | [15:59] |
| mchehab | no, it is not the shared pin change that broke it | [16:00] |
| javier__ | mchehab: yeah, is the output format change right? | [16:01] |
| mchehab | https://paste.fedoraproject.org/314504/73786914
first dump is before s_stream second is after | [16:04] |
| javier__ | Miscellaneous controls = 0x6f | [16:05] |
| mchehab | @@ -4 +4 @@
-Miscellaneous controls = 0x6f +Miscellaneous controls = 0x00 @@ -7 +7 @@ -Luminance processing controls #1 #2 and #3 = 60 00 00 +Luminance processing controls #1 #2 and #3 = 60 00 03 @@ -25 +25 @@ -Chroma gain factor: Cb=0xe7 Cr=0xc3 +Chroma gain factor: Cb=0x52 Cr=0x24 @@ -34 +34 @@ -Status regs #1 to #5 = 71 00 1a 01 83 +Status regs #1 to #5 = 71 30 1a 58 83 this is with tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00); commented | [16:06] |
| *** | benjiG has left | [16:10] |
| javier__ | mchehab: sorry, I should really go before my bank closes, I'll be back in ~30min-1hr | [16:10] |
| ........ (idle for 39mn) | ||
| fullstop | Hi all. I've a v4l2 application, threaded, which uses blocking calls for v4l2.
I have a problem where VIDIOC_DQBUF blocks forever.. is there a way to set a timeout without changing everything to non-blocking? | [16:49] |
| ..... (idle for 24mn) | ||
| jmleo | fullstop, You can open your device with the O_NONBLOCK flag and then, instead of blocking, you will get EAGAIN when no buffer is available | [17:14] |
| pinchartl | hverkuil: I won't have time this month | [17:21] |
| ......................... (idle for 2h4mn) | ||
| *** | makomk has quit IRC (Ping timeout: 265 seconds) | [19:25] |
| ................ (idle for 1h15mn) | ||
| awalls1 has left | [20:40] | |
| ................... (idle for 1h33mn) | ||
| javier__ | pinchartl: I tried to test what you suggested of only disabling / enabling YUV, clock and HSYNC/VSYNC/etc enable bits on s_stream but there is something wrong with my igepv2
I only get i2c i/o timeouts when trying to access the tvp5151 i2c registers, I hope is not a hw issue :-/ since this happens even with the older branches that I used to test the patches before posting | [22:13] |
| ..... (idle for 21mn) | ||
| pinchartl | javier__: :-/
I won't have access to my hardware before two weeks | [22:39] |
| javier__ | pinchartl: no worries, I'll dig more tomorrow since I'm about to leave for today | [22:43] |
| ............. (idle for 1h4mn) | ||
| Ok, the good news is that my issue is not a HW error
the bad news is that the same patch that works on top of the media-controller, does not work on latest media_tree / v4.5-rc1 so something changed in the kernel and I wonder how could affect the patch. It only toggles some GPIO lines | [23:47] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |