| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | epaul- has left | [02:21] |
| ................................................... (idle for 4h14mn) | ||
| dafna2 | hverkuil: ping | [06:35] |
| ...... (idle for 28mn) | ||
| hverkuil | dafna2: pong | [07:03] |
| dafna2 | hi, I had this patch https://patchwork.kernel.org/patch/11715801/ | [07:17] |
| montjoie | mchehab: I have sent mail to you but your huawei addres reject google... Sender IP in realtime blacklist client [209.85.128.68] blocked using rbl.skyguard.cn | [07:17] |
| dafna2 | Helen wrote it is not necessary, so I removed it, but the stats and params entities are part of the media controller | [07:19] |
| mchehab | montjoie: what e-mail are you using for sending stuff to me? mchehab+huawei@kernel.org? | [07:21] |
| dafna2 | so according to the API they should call media_pipeline_start/stop | [07:22] |
| mchehab | $ nslookup 209.85.128.68
68.128.85.209.in-addr.arpa name = mail-wm1-f68.google.com. that makes no sense. It should, instead use this IP: mail.kernel.org has address 198.145.29.99 montjoie: if you're trying to send e-mails to my @kernel.org address, then it sounds to me that someone poisoned your DNS server:-p | [07:22] |
| montjoie | mchehab: no to your huaway address
ah I just saw that TO is your kernel address, but your huawey is in CC | [07:26] |
| hverkuil | dafna2: what is the question? | [07:29] |
| dafna2 | whether this patch should be added or not | [07:29] |
| lyakh | just a heads-up: it has been a topic since a few years now that audio might at some point want to adopt the media API. That idea might or might not be dead by now, but IIUC an attempt to add an ancillary bus for handling audio "subdevices" makes that goal even less achievable
e.g. https://github.com/thesofproject/linux/pull/2264 | [07:30] |
| dafna2 | are video entities that are part of media controller should call media_pipeline_start upon stream start or is it only optional? | [07:31] |
| hverkuil | My understanding is that media_pipeline_start is only necessary if you have a pipeline consisting of multiple configurable device nodes (e.g. a videoX node and one or more v4l-subdevY nodes) and/or containing dynamic links. If it is a fixed pipeline with just one device node, then there is nothing to lock in the pipeline and you don't need to call these functions.
It's basically a static pipeline. | [07:37] |
| dafna2 | ok
in rkisp1 case it is not a fixed pipeline | [07:39] |
| hverkuil | so the routing can be changed? | [07:40] |
| dafna2 | the links between the isp entity to the params and stats are dynamic
though calling 'start stream' on the stats/params does not really do anything, it just means that userspace wants to use the stats/params loop once the camera will start | [07:41] |
| hverkuil | Calling media_pipeline_start would prevent userspace from changing the routing while streaming is in progress.
But you'd better test that that does actually work. actually does work So yes, if the routing is dynamic, then you'd call media_pipeline_start to lock the routing in place. | [07:44] |
| dafna2 | currently the driver doesn't even check if the links to those entities are enabled | [07:46] |
| hverkuil | Can you pastebin the topology? | [07:48] |
| dafna2 | https://pasteboard.co/JtKF0Wb.png
I was wrong, the links to the stats/params are not dynamic ok , so looks to me it is not necessary to call media_pipeline_start, | [08:02] |
| I meant that the links are immutable | [08:11] | |
| .......................... (idle for 2h8mn) | ||
| tfiga | dafna2: I think it depends on whether one is able (and wants) to get only statistics, discarding the pictures
Honestly I see little value in such setup, so I wouldn't bother | [10:19] |
| ................. (idle for 1h20mn) | ||
| sailus | hverkuil: I picked up Niklas's ADV7604 DT binding patches assigned to you in my tree. I hope that's ok. | [11:39] |
| hverkuil | that's fine. Are they delegated to me in patchwork? If so, please delegate those patches to yourself. | [11:40] |
| sailus | hverkuil: Thanks. They were, but I delegated them to me.
neg: Would you happen to have time to check out these: https://lore.kernel.org/linux-media/20200930144811.16612-1-sakari.ailus@linux.intel.com/ jmondi: ^ | [11:40] |
| neg | sailus: Sure I will do so a bit later today | [11:43] |
| ........ (idle for 39mn) | ||
| sailus | neg: Tack, tack!
gnurou: Have you had issues compiling mtk-vcodec? I have on media tree master: WARNING: unmet direct dependencies detected for MTK_SCP Depends on [n]: REMOTEPROC [=n] && (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) Selected by [m]: - VIDEO_MEDIATEK_VCODEC [=m] && MEDIA_SUPPORT [=m] && MEDIA_PLATFORM_SUPPORT [=y] && V4L_MEM2MEM_DRIVERS [=y] && (MTK_IOMMU [=y] || COMPILE_TEST [=n]) && VIDEO_DEV [=m] && VIDEO_V4L2 [=m] && (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) | [12:22] |
| gnurou | sailus: which arch/config are you compiling for? | [12:25] |
| sailus: I think this comes from REMOTEPROC [=n]... this prevents MTK_SCP to be compiled, yet mtk-vcodec is built
I guess we should make VIDEO_MEDIATEK_VCODEC depend on REMOTEPROC? Any thoughts? | [12:34] | |
| ...... (idle for 27mn) | ||
| tfiga | should VIDEO_MEDIATEK_VCODEC depend on MTK_SCP rather than select it?
gnurou: ^^ but actually I'd imagine one would want to compile it for 8173 only, which uses VPU instead of SCP | [13:03] |
| gnurou | tfiga: that's my concern as well | [13:05] |
| tfiga | so perhaps depend on MTK_SCP || MTK_VPU (if that's the right symbol name) and make the driver build in any case? | [13:05] |
| gnurou | ah, that sounds good
... although the current policy is to select MTK_VPU and MTK_SCP, so we would be kind of reversing the policy | [13:05] |
| tfiga | where does the policy come from?
AFAIR the usual recommendation was to prefer depends over select | [13:06] |
| gnurou | it's what was there when I started looking at it
I'm fine going the DEPENDS direction though, after making sure defconfig still behaves like it used to | [13:06] |
| tfiga | https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt
"select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over." | [13:07] |
| gnurou | mmm that settles it I guess
thanks for the reference | [13:08] |
| tfiga | np
I think it always ends up being confusing especially since depends is not the most intuitive option for whoever configures the kernel... because if one wants to enable symbol B which depends on A, one needs to enable A first, as otherwise B wouldn't show in menuconfig I've learned to live with it by using the search option (/ in menuconfig), which shows all matching symbols and lists its dependencies I guess that's a problem with menuconfig, though it could as well display any possible symbols in the menu and give you an option of "enable recursively with all dependencies" | [13:08] |
| gnurou | ah but wait, currently the driver depends on both VPU and SCP | [13:12] |
| tfiga | hmm, https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/media/platform/Kconfig?h=next-20201002 only has "select MTK_SCP" | [13:13] |
| gnurou | I suppose I can attempt to make the VPU and SCP parts compile conditionally while depending on VPU || SCP | [13:13] |
| tfiga | ah, and "select VIDEO_MEDIATEK_VPU"
or provide stubs for corresponding modules | [13:13] |
| gnurou | mm right | [13:15] |
| I think it should work if I just make some bits in mtk_vcodec_fw.c conditional at compile-time
getting approval for stubs in SCP would require approval from remoteproc/, which could take some time | [13:20] | |
| jmondi | sailus: I see I'm cc-ed but I don't have it in my inbox :/
sailus: will look there! | [13:25] |
| tfiga | gnurou: if we need to fix it quickly then I guess just making it depend on both (rather than select) could work?
and a follow up could make it depend on either | [13:25] |
| gnurou | yes, but I'm worried it could also make it impossible to compile on some configurations, or force them to drag remoteproc when they don't need it | [13:27] |
| pinchartl | gnurou: of course the right fix is to drop SCP and directly talk to the hardware from the driver ;-) | [13:35] |
| gnurou | pinchartl: I need no convincing about that ;) | [13:37] |
| ....... (idle for 31mn) | ||
| hverkuil | arnd: ping | [14:08] |
| arnd | hi hverkuil | [14:08] |
| hverkuil | Hi Arnd! A quick question: what is the status with y2038 and glibc? Or do I still have to use musl to test TIME32? | [14:09] |
| arnd | hverkuil: there is y2038 support for rv32 in glibc now, but none of the older architectures have added it, that is still work in progress
there is a constant stream of glibc patches working on it bit by bit, but I stopped following how much work is left for them, I don't expect it to be done soon | [14:10] |
| hverkuil | right, so for i686 I still have to use musl.
I'm testing your compat series, fixing the bugs. It's now working for regular i686, and now I want to test with the y2038 compat code. you can expect a mail later today. | [14:11] |
| ........... (idle for 53mn) | ||
| *** | k-bob has left | [15:06] |
| das_coach | hi@all | [15:08] |
| i'm seeking advice on where to start looking closer with a problem i'm experiencing: i got a new, cheap webcam (12d1:4321), which works in cheese, though it gets recognized twice with different resolutions (some combinations crash). it also comes with a build in mic that doesn't record anything, but i don't care about that at the moment. i finally
managed to get the webcam passed through to a RDP session (using xfreerdp), but here's the thing: access from within the RDP session hangs for a while and then reboots the webcam. is this more likely a uvcvideo or an usb issue? any ideas about how to get closer to the issue? dmesg shows only a "usb 3-3: reset high-speed USB device number 2 using xhci_hcd" out of nowhere when it happens | [15:14] | |
| .............................................................. (idle for 5h7mn) | ||
| sailus | jmondi: Oops. I misspelled your e-mail address apparently.
gnurou: Yes, I don't have CONFIG_REMOTEPROC set. The warning is indeed followed by an error in linking phase. | [20:21] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
