| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| pinchartl | :-/ | [00:02] |
| ............................................................................................................................... (idle for 10h31mn) | ||
| *** | dannas has left | [10:33] |
| javier__ | mchehab: I'm glad that you found the issue in the em28xx driver, now I've one less thing to worry about today :) | [10:46] |
| ...................... (idle for 1h49mn) | ||
| nohous | hi, given our device supports "contiguous" range of input video timings, how should VIDIOC_ENUM_DV_TIMINGS be implemented? I don't think it's reasonable to provide list as long as the cartesian product of supported timing params is (example: supported h-active: (128-4095)* supported v-active (128-4095) -> list consists of 15737089 items...)
should we only return an intersection with pre-defined BT656/1152 timings? | [12:35] |
| hverkuil1 | nohous: ENUM_DV_TIMINGS only lists discrete timings (DMT & CEA861). | [12:45] |
| nohous | allright then | [12:46] |
| hverkuil1 | VIDIOC_DV_TIMINGS_CAP will set in the capabilities field if other timings are supported:
s/capabilities field/standards and capabilities fields/ the standards field signals if CVT/GTF standards are supported the caps field signals if custom timings are supported (i.e. anything goes) v4l2-dv-timings.c has helpers for handling cvt and gtf. | [12:46] |
| nohous | yeah, i've seen the helpers | [12:48] |
| hverkuil1 | see pci/cobalt and i2c/adv7604/adv7842 for existing examples
vivid too. | [12:48] |
| nohous | i am however quite confused why there are three interfaces affecting the ROI: S/G_FMT, S/G_DV_TIMINGS and S/G_STD | [12:50] |
| hverkuil1 | ROI?
four: G/S_SELECTION as well :-) | [12:51] |
| nohous | sorry, region of interest, s/ROI/resolution
i guess i should read some user space code on how are these usually used | [12:53] |
| hverkuil1 | G/S_STD and G/S_DV_TIMINGS deal with the hardware receiver: selecting/detecting the correct timings and locking on to it.
Two different APIs because the signalling between a tuner/composite input and an HDMI/VGA/DP/... input is radically different. | [12:53] |
| nohous | ok, so since we have auto-detect here, we should only implement QUERY_DV_TIMINGS and G_STD | [12:54] |
| hverkuil1 | G/S_FMT deals with the output of the DMA engine: the format and size in memory. If there is a scaler, then the format size can be different from what you receive on the input port and the hw scales up/down for you.
With G/S_SELECTION you can add hardware cropping/composing into the mix. You need QUERY/G/S/DV_TIMINGS. | [12:55] |
| nohous | ok, so fmt width / height has nothing to do with the actual signal | [12:57] |
| hverkuil1 | Correct. It's about what ends up in memory. | [12:57] |
| nohous | ok, thanks - is there any summary of this available? i am apparently incapable of googling and i don't want to waste your time | [12:58] |
| hverkuil1 | Note: if you detect in the driver that the timings have changed, never try to detect and set the new timings. Instead send an event to userspace and let userspace call QUERY and S_DV_TImings.
Best things to do is actually play with the vivid driver and v4l2-ctl/qv4l2 and read the code. And of course the v4l2 spec. When developing the driver run v4l2-compliance: this checks many things. I don't mind these questions. I'd rather answer them here and get a high quality driver in return :-) nohous: for the event see V4L2_EVENT_SOURCE_CHANGE here: http://hverkuil.home.xs4all.nl/spec/media.html#vidioc-dqevent | [12:58] |
| nohous | hverkuil: i've already run into this event, i want to use it for sure, but what's unfortunate is that is not available in 3.10 kernel (which is the newest one supported by nvidia), but i'll deal with backporting issues later | [13:05] |
| ezequielg | hverkuil1: Hello!, I'm not completely sure how to respond to the tw686x discussion about "don't merge this driver, merge the other driver". maybe you can through some light on the discussion.
hverkuil1: it seems the guy is frustrated because I submitted a modified version of the driver he sent in July, instead of merging that one. | [13:16] |
| ............ (idle for 57mn) | ||
| hverkuil1 | ezequielg: as long as a driver is never merged there is no need to split it up, in fact, that would only make the review process more complicated. So as long as it is clearly stated that the driver is derived from that older driver I am OK.
What worries me more is that I understand that sg dma works in the older driver, at least with his hardware. So for him your driver would be a step back. in functionality. | [14:14] |
| ezequielg | i understand
fwiw, i did very *deep* changes to his submission. my requirements are support up to 96 channels (up to 12 tw6869 in a single box), with long uptime, so it took a lot of effort to stabilize. | [14:16] |
| hverkuil1 | do you have a link to his most recent patch that he posted? (I don't have my old media mails available at work) | [14:17] |
| ezequielg | sure, let me see.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg90170.html | [14:18] |
| hverkuil1 | Right, so you requested changes and he never posted a newer version so instead you ran with it, right? | [14:21] |
| ezequielg | right
waited until now, in case he posted something new, and then figured he just lost interest. | [14:22] |
| hverkuil1 | In your driver you dropped dma-sg because you wanted to dma frames instead of fields and I gather that dma-sg is only supported for fields, correct? | [14:22] |
| ezequielg | not really, i dropped dma-sg because my x86 setup ran out of sg resources when streaming more than N cameras at once
dma-sg only provides separate fields, but that would be easily handled by userspace not to mention the machine freeze i experienced, in any implementation that involves writing the DMA registers while streaming | [14:23] |
| hverkuil1 | Ah yes, it's coming back to me :-) | [14:25] |
| ezequielg | notice that his old submission is not that great too
lacks audio, uses a kthread instead of just working in the irq handler so it needs quite a bit of work in any case i can drop my workaround, and put sg instead. tbh, i don't know if the machine freeze is a chip bug or board bug. i only have boards from the same manufacturer but i thought that since the submitted driver is running very stable, why wouldn't upstream carry the same workaround? | [14:25] |
| hverkuil1 | so it looks that you only support field_interlaced while his driver also supports field_top/bottom/seq_bt and no interlaced.
There also seems to be fewer pixel formats that are supported | [14:29] |
| ezequielg | yup, I'm only using DMA frame mode, which delivers interlaced frames
and not so sure about the pixel formats | [14:31] |
| hverkuil1 | that means he can't use your driver, and that feels wrong to me. | [14:32] |
| ezequielg | so you want me to put s-g ? | [14:33] |
| hverkuil1 | I would like to see that functionality back in the driver. Whether that means that dma-sg should be used for that (i.e. the field mode) is a separate matter. If that is stable for you, then that makes sense, if that's unstable then using the same technique as you use now would also be OK.
It's unfortunate that you don't know the root cause of the unstable DMA. At the moment I am less interested in the driver internals and more in the user-facing functionality. Driver internals can always be changed later. | [14:35] |
| ezequielg | yeah, but mainline provides no functioanlity at all for tw6869. so it feels strange to be asked to add more stuff to a patch that is perfectly fine on its own.
i mean, the driver is posted, reviewed comments were adressed, etc. it's usually easier to merge basic stuff first, and then add features as follow-ups | [14:38] |
| hverkuil1 | how much work would it be to add the field support? | [14:40] |
| ezequielg | well, not that hard, not that easy either.
fwiw, the issue here is that DMA frame mode requires a large chunk of memory and that may not be possible on ARM platforms. | [14:41] |
| hverkuil1 | my problem is (and I didn't realized that when I reviewed your code) that you customized the driver for your specific needs, which would be fine if this was really the first driver code ever posted, but you based it on work Krzysztof did that *did* support the field formats.
(arm can handle that fine with cma these days) I would be happier if the functionality was added back to your driver. See it as a courtesy towards Krzysztof. | [14:43] |
| ezequielg | ok, i really disagree with you. i'm not happy with being told that we can't merge a perfectly sane patch because a patch was sent 6 months ago, while that patch wasn't followed up. however, i want to see the driver merged, so i'll put s-g mode back on if that's the path forward.
we could argue the whole day, but i really just want to find a way forward to merge the driver. notice that Krzysztof is suggesting that we should "just merge" his 6-months old submission. | [14:47] |
| hverkuil1 | I definitely wasn't planning on merging that.
It would also be perfectly fine by me if the work for the field mode is in a separate patch on top of your current patch. No need to merge into a single patch. | [14:50] |
| ezequielg | ok, let's try that :)
now all we need to find is another family-free weekend btw, supporting s-g means a different vb2_mem_ops. i failed to change that dynamically, so last time i tried that i went for a module option. while probably possible, i'm not sure it's worth the pain since a user will probably want either frame or s-g mode, but not switch between them. how does it sound? | [14:51] |
| hverkuil1 | quick question first: is dma-sg required for capturing fields? Can't you use what you have now and just capture fields instead of frames? Or does the hw require you to use dma-sg? | [14:57] |
| ezequielg | there is a field DMA mode, which I haven't used.
it probably would work (maybe struggling to configure it properly?) but the DMA frame mode that i used in the last submission delivers both fields interlaced no way to "de-interlace" (except manually, of course) | [14:58] |
| hverkuil1 | You can use two different vb2_queues: one for frame based and one for field based (dma-sg).
That should work. got to go ttyl | [15:02] |
| ............................................................ (idle for 4h59mn) | ||
| *** | awalls has left | [20:04] |
| .... (idle for 17mn) | ||
| shuah | pinchartl: Hi Laurent! How is California? Hope you are doing well.
I am unable reproduce the problem on 4.5-rc1 - I do have my patch series on top test program I am using: http://hastebin.com/woboteseju.coffee I just wrote a simple test I run that and then remove the usb device No crashes seen and I killed the app after device removal - no issues | [20:21] |
| pinchartl | shuah: can you try issueing ioctls on the device after unplugging it ? | [20:27] |
| shuah | yes I can try that
ok I will add ioctl and make it to do something | [20:27] |
| .... (idle for 15mn) | ||
| fullstop | jmleo: sorry for the delay in my response. That change is less than ideal, as I'd have to rewrite everything to be select / event based rather than blocking. | [20:44] |
| ............................... (idle for 2h30mn) | ||
| shuah | pinchartl: yes adding reproduces the problem
pinchartl - http://hastebin.com/oqijudehel.md | [23:14] |
| pinchartl | shuah: I'm not sure if it's good or bad, but at least it's consistent :-) | [23:18] |
| shuah | It is good - this is without the kref API - so now I have a way to make sure the API works :)
I also have a selftest now for this problem - which is nice | [23:19] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |