| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| jmondi | pinchartl: sailus: I'm happy to have Laurent give it a go :) | [06:51] |
| ............................................. (idle for 3h44mn) | ||
| tfiga | hverkuil: pong | [10:35] |
| hverkuil | tfiga: ping
Regarding the 'remove V4L2-FLAG-MEMORY-NON-CONSISTENT' thread: I was out most of last week, so I haven't followed the latest posts on that. I'm a bit confused. Is this problem just with this flag, or with the V4L2_BUF_FLAG_NO_CACHE_CLEAN/INVALIDATE flags as well? | [10:37] |
| tfiga | I believe it's only with the flag
also the begin/end_cpu_usage() should be fine but the patches are kind of intertwined, so not sure if it's 100% safe to do a partial revert | [10:40] |
| hverkuil | I would prefer to have a patch on top that strips the V4L2_FLAG_MEMORY_NON_CONSISTENT support. I would hate to see the caching hints support to be lost as well.
I don't think that would be too difficult. | [10:47] |
| tfiga | okay, so I guess Christoph's patch does it
the one that I asked you for a revert | [10:50] |
| hverkuil | That patch is close, but it should also remove the new flags field from vb2_core_reqbufs and vb2_core_create_bufs, since that's no longer used.
If I have a patch for that this week/next week, then that should be early enough to revert in 5.9. What I don't understand is what the plan is going forward: is it going to be impossible to create non-coherent buffers? Or does it require the use of a completely different API? kAPI? | [10:54] |
| tfiga | Christoph said that he would create a new kAPI for it, something like dma_alloc_noncoherent() | [11:01] |
| hverkuil | OK. So basically today support for this isn't actually available (even though we erroneously thought it was), but it is being worked on, and then we can retry adding support for this flag. Is that correct? | [11:02] |
| tfiga | yes | [11:02] |
| hverkuil | Great, that makes sense. So once I have a v2 of Christoph's patch removing the flags argument and it is reviewed/acked by you, then I can make a PR for 5.9.
Is that something you'll pick up? | [11:04] |
| tfiga | What do you mean by pick up? | [11:13] |
| hverkuil | post a v2 patch based on Christoph's patch. Alternatively, I can reply to his patch asking him to remove the flags argument. But then we need to wait for his v2. | [11:17] |
| tfiga | ah, okay, I can do that
but then probably doesn't make sense to self-review/self-ack it :) or let me check with Sergey | [11:17] |
| .......... (idle for 49mn) | ||
| hverkuil: what do we do with v4l2-compliance? it uses the flag already | [12:06] | |
| hverkuil | Support in v4l2-ctl/compliance for this flag should be reverted as well. Not a problem. | [12:07] |
| tfiga | okay, I'll review Christoph's revert patch and make sure what's missing there | [12:08] |
| ....................... (idle for 1h53mn) | ||
| kbingham | sailus, I've had some community interaction with people trying to get the IPU3 modules loaded on their device, but they're saying the PCI vendor comes up as 8086:8a19, rather than 8086:1919 used by the IPU3 driver. Is there anyway to find out what the 8a19 device corresponds to? Is it still an IPU3? My google-fu is letting me down. | [14:01] |
| .............. (idle for 1h8mn) | ||
| sailus | kbingham: 8a19 is not IPU3. | [15:09] |
| kbingham | sailus, I think it's IPU4 | [15:10] |
| sailus | One of IPU4 variants, yes. | [15:10] |
| kbingham | But it's not listed in https://github.com/intel/intel-camera-drivers/blob/master/drivers/media/pci/intel-ipu4/intel-ipu4.h either. | [15:10] |
| sailus | It's newer than that. | [15:11] |
| kbingham | sailus, Ok thanks, so unlikely to be able to even support with that joule driver then. I have already recommended that there are some nice USB cameras available to buy ... I think that's the only option for those devices ;-( | [15:12] |
| sailus | Yeah, unfortunately I'm not able to help here. | [15:17] |
| tfiga | wow, I didn't know IPU4 actually existed anywhere in practice | [15:20] |
| kbingham | Don't worry - I understand. Confirmation that it's /not/ an IPU3 is all I needed. | [15:20] |
| tfiga | fwiw, there is also some driver available for :5a19
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/974918 but I guess :8a19 is still something else | [15:25] |
| kbingham | tfiga, haha, is that a mix of the 5a88 and the 8a19 ;-) | [15:26] |
| tfiga | lol
I also have one for :9a19 but that's too far ahead https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2043435/ | [15:27] |
| kbingham | interesting that the '19' suffix is retained. Certainly seems to be some part-type encoding in those values ... | [15:29] |
| tfiga | maybe doing a weighted average of both drivers could give you a working one
;) | [15:32] |
| kbingham | tfiga, I'm sure we can just run all the IPU* drivers into some AI and get a combined result for all of them ;-) Simples... | [15:37] |
| tfiga | they call it "bring-up engineers" | [15:38] |
| ........ (idle for 35mn) | ||
| sailus | kbingham: Don't assume too much about device IDs. If it's different, it's just a different device, not more can be assumed. | [16:13] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |