| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | _jmleo has quit IRC (Quit: Disconnecting from stoned server.) | [09:25] |
| prabhakarlad has left | [09:37] | |
| .............. (idle for 1h7mn) | ||
| ayaka | I have a problem with v4l2 dma-sg, I have a device with IOMMU
so it doesn't need the memory is in contiguous in physics or virtual, but it is in dma address I use the multi-planes buffers, but I found the address of second plane is less than first plane which means the second plane is mapping to IOMMU first or allocate first but I need the second plane is append after the first plane any ideas on how to control the dma-sg to do that | [10:44] |
| ............. (idle for 1h0mn) | ||
| sailus | ayaka: You could use the dma-contig mem ops instead if you're behind an IOMMU in principle, but that does not help if the planes need to be in order in the address space.
That is actually not trivial to handle with a generic IOMMU. | [11:47] |
| ayaka | sailus, I just wonder why it would be that
sailus, is there a way to invoke the buffer allocation in driver, I mean allocate a buffer in manual actually I don't need multi-planes but it is hard for userspace to handle the memory alignment with the offset as the userspace having no idea on where the second plane would actually start so I have to use multi-planes sailus, and I think I don't need Physically contiguous since I have an IOMMU I thought it is used for those non-IOMMU device | [11:49] |
| sailus | Then dma-contig is a better choice than dma-sg.
You don't need the scatterlists because of the IOMMU. Well, there are different kinds of IOMMUs. | [11:54] |
| ayaka | sorry, I don't understand
that IOMMU support mapping pages into device contiguous memory | [11:55] |
| sailus | If you have an IOMMU, then the allocated memory, even if physically scattered around the system memory, can be mapped in a continuous manner in the device's virtual address space.
Hence dma-contig may be used. It does not mean that the memory would be physically contiguous. It would be if there is no IOMMU though. | [11:57] |
| ayaka | ok I see
then when would the dma-sg is used? the device support only access a page once time? | [11:57] |
| sailus | If you have a device that does not use an IOMMU or requires physically contiguous memory. | [11:58] |
| ayaka | I see, thank you
the https://linuxtv.org/downloads/v4l-dvb-apis/kapi/v4l2-videobuf.html make me confused | [11:59] |
| sailus | Don't read videobuf documentation.
Videobuf is old and being phased out. Use videobuf2 instead. | [12:00] |
| ayaka | but this https://linuxtv.org/downloads/v4l-dvb-apis/kapi/v4l2-videobuf2.html doesn't cover those knowledge about the dma-sg dma-contig | [12:02] |
| sailus | Yes, this is a known gap. :-(
The videobuf2 code is a lot more readable though. | [12:03] |
| ayaka | it has been many years, videobuf2's documents never talk about which mem_ops I should use | [12:05] |
| sailus | This is actually more related to DMA API than it is to videobuf2.
Videobuf2 uses the DMA API to allocate the memory. I guess one could write a short description of how it works and put it into the documentation. | [12:06] |
| ayaka | because in the previous kernel version, the iommu driver doesn't support of probing
I still worry about the DMA API would call the virtual ARM iommu that is why I care about this problem | [12:07] |
| sailus | It all needs to be set up correctly of course. :-)
But that's a bit out of scope of the videobuf2 documentation. | [12:08] |
| ayaka | I think it works now | [12:08] |
| sailus | :-) | [12:08] |
| ayaka | I mean the iommu part | [12:09] |
| sailus | Memory management in general tends to be complicated. | [12:09] |
| ayaka | but I still need to solve the address position problem
I remember the samsung mfc would request each planes in different memory banks I wonder how does it work | [12:10] |
| .... (idle for 19mn) | ||
| *** | paul3741 has quit IRC (Ping timeout: 246 seconds)
tagr has quit IRC (Ping timeout: 246 seconds) | [12:30] |
| ............................ (idle for 2h18mn) | ||
| ayaka | sailus: and thank you | [14:48] |
| .................... (idle for 1h38mn) | ||
| ezequielg | hverkuil: ping | [16:26] |
| hverkuil | ezequielg: pong | [16:30] |
| *** | benjiG has left | [16:32] |
| ezequielg | about on the pixel format helpers, i don't see why we'd want to have the alpha plane in the bytes-per-plane array.
formats with alpha channels are always packed the bytes-per-plane really only applies to planar format it's not bytes-per-channel hverkuil: ^ | [16:35] |
| hverkuil | I'm OK with that change. It's an internal API, so it can always be extended if needed. | [16:37] |
| ezequielg | right. | [16:38] |
| ....... (idle for 32mn) | ||
| *** | lyakh has quit IRC (Excess Flood) | [17:10] |
| ....... (idle for 30mn) | ||
| mchehab | hverkuil: could you point again the command line needed to test bayer with qvidcap?
that one with vim2m | [17:40] |
| nevermind... I guess it was something like this:
v4l2-ctl --stream-mmap --stream-out-mmap --stream-to-host localhost --stream-out-hor-speed 1 -x pixelformat=RGBR | [17:47] | |
| hverkuil | mchehab: that looks correct. | [18:01] |
| ............... (idle for 1h13mn) | ||
| ndufresne | ezequielg, "formats with alpha channels are always packed", that's just a point in time, e.g. in gst we have A420 support (and 10bit variants), which have 4 planes and can be produced by JPEG2000 decoder | [19:14] |
| ................... (idle for 1h34mn) | ||
| ezequielg | ndufresne: aight, i see what you mean. | [20:48] |
| ndufresne | (just saying on a theoretical basic, no idea if that has any impact in your code) | [20:50] |
| ezequielg | it doesn't but only because we don't have that pixel format. | [20:59] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |