| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | svarbanov: ping | [08:44] |
| ..... (idle for 21mn) | ||
| narmstrong | hverkuil: what would be simplest merge path for CEC ? if the media tree can provide an immutable branch for mfd and drm and take everything, it would be the best case | [09:05] |
| ..... (idle for 23mn) | ||
| hverkuil | narmstrong: I'd rather not go through the media tree actually. I think the safest approach with the least chance of conflicts is 1+2 through drm and the others through mfd. | [09:28] |
| ...... (idle for 28mn) | ||
| svarbanov | hverkuil: pong | [09:56] |
| hverkuil | svarbanov: What is the status of the venus HEVC series? | [09:58] |
| svarbanov | hverkuil: I almost addressed all review comments from tfiga, just small details are left. Hope that I will be able to send v3 early next week | [09:59] |
| hverkuil | OK. Can I set the status of the v2 series to "Changes Requested" so it is no longer in my way-too-long TODO list? | [10:00] |
| svarbanov | hverkuil: yes, you have to :) | [10:03] |
| hverkuil | done | [10:04] |
| ..................... (idle for 1h42mn) | ||
| jmondi: ping | [11:46] | |
| sailus: mchehab: jmondi: https://patchwork.linuxtv.org/patch/50017/
Should this pull request be merged for 4.18? I gather that an earlier pull request had only part of the ov772x patches? In any case I gather that this should go in before this series from Jacopo: https://lkml.org/lkml/2018/5/28/1936 jmondi: if I understand correctly there will be new versions of both https://www.spinics.net/lists/arm-kernel/msg656323.html and https://www.spinics.net/lists/linux-media/msg135263.html, right? Please confirm so I can mark these as 'Changes Requested'. | [12:00] | |
| .... (idle for 17mn) | ||
| jmondi | hverkuil: pong
hverkuil: yes, both VIN patch series will be re-spinned | [12:21] |
| hverkuil | sailus: what is the status of this series? https://www.mail-archive.com/linux-media@vger.kernel.org/msg131186.html
sailus: this needs Acks/Reviewed-by tags from you before it can be merged. sailus: Other series depend on this. jmondi: thanks, I'll update patchwork. | [12:21] |
| jmondi | hverkuil: an Mita-san patches were just partially collected, so I guess 50017 should be merged.. but I'll let Sakari confirm this | [12:23] |
| ndufresne | ezequielg, I just picked a random cam, and plugged unplug, nothing special
and could reproduce the reported bug interesting thing is that on Fedora shipped 4.16.12-300.fc28.x86_64 I don't reproduce it ... ah, wait, wrong terminal, I'm testing on 4.17-rc7 (couple of merge before the release, got 13 media controllers now ;-P | [12:23] |
| pinchartl | ndufresne: the problem should be fixed by f9ffcb0a21e1fa8e64d09ed613d884e054ae8191
in Linus' tree for v4.18-rc1 | [12:28] |
| ........... (idle for 50mn) | ||
| ndufresne | pinchartl, great | [13:18] |
| ......... (idle for 40mn) | ||
| ezequielg | pinchartl: hverkuil and i have been talking about how to represent m2m in the media-controller. | [13:58] |
| pinchartl | have you reached a conclusion I will like ? -:) | [13:59] |
| ezequielg | i have tested yesterday and with a recent change from hverkuil, vim2m + request api passes v4l-compliance and media-ctl -p works as well.
we haven't, i was hoping to pick your brain. i do not have much experience with mc. hverkuil made some valid points about m2m not having any pads. he said we might want to have a separate function type, but I am unable to see the value of that. m2m have the same api than any other v4l device, so i am not sure why i would describe them differently. not sure _exactly_ what the function type and entity type describes. formally, i mean. | [13:59] |
| pinchartl | a m2m device has (at least) one processing block and (at least) two DMA engines
the DMA engines are associated with video nodes so I would envision an entity for the processing block, with a sink pad and a source pad and one entity per video node (depending on the type of m2m device you can have one or two video nodes) so that would create a media graph | [14:02] |
| ezequielg | the video node would be e.g. a scaler, or a decoder, or you could have both, right_ | [14:03] |
| pinchartl | at the hardware level, you have
DMA engine -> processing block -> DMA engine | [14:04] |
| hverkuil | that was one of the two options I had in mind. The other was a single entity for the DMA engine since the actual processing block is generally integrated. | [14:05] |
| pinchartl | that's three entities
a potential issue is how to map the two DMA engine entities to a single video node | [14:05] |
| hverkuil | It's a MEDIA_ENT_F_IO_V4L with both an input and an output pad.
processing block <--> DMA engine | [14:05] |
| pinchartl | that seems like a hack | [14:06] |
| hverkuil | why? | [14:06] |
| pinchartl | as we really have two DMA engines
maybe a hack is unavoidable but if I remember correctly the plan was to separate the hardware representation of the DMA engine from the video node with a DMA engine entity linked to a V4L2 interface I'd rather have two DMA engine entities linked to the same V4L2 interface | [14:06] |
| hverkuil | was I involved in that discussion? I can't remember it. | [14:08] |
| pinchartl | it dates back to when we introduced the concept of interfaces
(and extending the concept of links to show the relationships between HW entities and interfaces, which I disliked, I'm sure you remember my opposition to that :-)) | [14:08] |
| hverkuil | Actually, this is already the case: v4l2-compliance -m0 for vim2m gives:
Media Driver Info:        Driver name      : vim2m        Model            : vim2m        Serial           :         Bus info         :         Media version    : 4.17.0        Hardware revision: 0x00000000 (0)        Driver version   : 4.17.0 Interface Info:        ID               : 0x03000002        Type             : V4L Video Entity Info:        ID               : 0x00000001 (1)        Name             : vim2m        Function         : V4L2 I/O One interface, one DMA engine. | [14:09] |
| pinchartl | that's not what we have agreed to back then :-( | [14:10] |
| hverkuil | (I thought you referred to some recent discussion, hence my question) | [14:10] |
| pinchartl | I'm not aware of any recent discussion on this subject, no
but the last discussion led to a half-baked result unfortunately we still have no solution for connectors and vim2m clearly doesn't implement the multiple entities pipeline we discussed back then there are lots of issues to fix there to mae mc-v2 usable I mean in the API | [14:10] |
| hverkuil | No, but that's because this vim2m implementation in reqv15 is a hack. Hence this discussion. I implemented just enough so that I had a media device in vim2m. | [14:12] |
| pinchartl | there are also issues in the internal implementation, but that's out of topic for now
ah ok glad that's not in mainline yet then :-) I think we should finish the design of mc-v2 and fix the API issues before building codec support on top of it | [14:12] |
| ezequielg | it is one the things we need to solve for mainline, and hence why i pinged you guys. | [14:13] |
| pinchartl | I'd like to have three entities in this case | [14:13] |
| hverkuil | So you want a processing entity with a source and a sink pad, each connected to a DMA engine entity. And both DMA engines link to the same interface entity. | [14:13] |
| pinchartl | DMA (1) -> processing (2) -> DMA (3)
with one interface | [14:14] |
| hverkuil | And the interface entity represents the video device node. | [14:14] |
| pinchartl | V4L2 interface (4)
with 1 and 3 linked to 4 the function of 1 and 3 should be DMA engine, not V4L2 I/O | [14:14] |
| hverkuil | OK, I'm fine with that. | [14:14] |
| pinchartl | as V4L2 is an interface
wow, that's was an easy MC-related discussion, it hasn't happened for a long time :-) s/has/had/ | [14:14] |
| hverkuil | V4L2_IO is what was chosen as the function name for "Data streaming input and/or output entity." of which DMA engines are a subset. | [14:15] |
| pinchartl | :-S
VIDEO_DMA_ENGINE (or something similar) would make more sense note the in mc-v1 V4L2_IO made sense as the entities and interfaces were merged together but now that they're split, V4L2 I/O doesn't make much sense as a function for entities | [14:16] |
| hverkuil | Not the greatest name, but I remember endless discussions about that, and I'm OK with it. | [14:17] |
| pinchartl | didn't it come from backward compatibility requirements ? | [14:17] |
| hverkuil | The struct v4l2_device name is way worse :-) | [14:17] |
| pinchartl | we have lots of bad names
v4l2_device is internal to the kernel though :-) | [14:18] |
| hverkuil | I don't think so, we didn't have MEDIA_ENT_F_ defines in v1. | [14:18] |
| pinchartl | I think we should rename V4L2_IO (I'm fine keeping an alias for backward-compat) | [14:18] |
| hverkuil | RFCs are welcome!
Anyway, these additional entities make things a bit more complicated, and since it will be the same for most m2m devices it will make sense to have some helper code in v4l2-mem2mem.c to set this up. | [14:20] |
| pinchartl | agreed | [14:22] |
| hverkuil | ezequielg: it's all yours! :-) | [14:22] |
| ezequielg | \o/ | [14:22] |
| ......... (idle for 42mn) | ||
| *** | prabhakarlad has left
benjiG has left | [15:04] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |