| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | mszyprow|home: ping | [07:46] |
| mszyprow|home | hverkuil: pong | [07:48] |
| hverkuil | Hi Marek, I'm processing patches from you and I have two questions:
https://patchwork.linuxtv.org/project/linux-media/patch/20200918144833.14618-3-m.szyprowski@samsung.com/ The first sentence in the commit log is a bit confusing: "Exynos4-IS driver relied on the was the ARM DMA-IOMMU glue code worked": 'on the was the' What did you want to say exactly? I can fix it, no need for a new patch. | [07:48] |
| mszyprow|home | was -> way | [07:50] |
| hverkuil | Ah, that makes much more sense! | [07:50] |
| mszyprow|home | typo... | [07:50] |
| hverkuil | I also have three media patches of your v10 30-part series (videobuf2, media:pci and tegra-vde): can those patches be merged independently from the remainder of the series? | [07:51] |
| mszyprow|home | yes. they are all independent
I thought you have already merged the videobuf2 related patches | [07:52] |
| hverkuil | Not according to patchwork :-) I've acked the patch, but not actually picked it up. Perhaps I thought this series would go through a different subsystem, but that's not the case, right?
Scratch that. You are right, the videobuf2 and pci patches are picked up. But not the tegra-vde. I'll just pick up the tegra-vde patch, then. | [07:53] |
| mszyprow|home | hverkuil: tegra vde is already merged as commit 76f50ad9b150 staging: tegra-vde: fix common struct sg_table related issues
in linux-next | [07:55] |
| hverkuil | OK, probably by Greg.
So then it is just the four exynos4-is/s5p-mfc patches, right? (good that I checked) | [07:56] |
| mszyprow|home | yes
although there is no hurry with them as I'm waiting for the comments from the IOMMU guys | [07:57] |
| hverkuil | So I should postpone merging them? | [07:59] |
| mszyprow|home | yes, they imho can wait a bit | [07:59] |
| hverkuil | Then no patches of yours will be merged :-) | [08:00] |
| ezequielg: ping | [08:10] | |
| ezequielg: never mind, I mailed instead. | [08:23] | |
| ........................................................... (idle for 4h50mn) | ||
| ezequielg | hverkuil: thanks for the review, it all made sense :) | [13:13] |
| ............ (idle for 55mn) | ||
| ndufresne | hverkuil: is there ready made mechanism for statistic (like number of corrupted mb, skipped frames, etc.) in a CODEC ?
I'm also pretty unsure if that should be API, or sysfs ... | [14:08] |
| hverkuil | ndufresne: no. | [14:09] |
| ndufresne | goal being to stop polluting logs with things that should be counted
ok, we'll have to think about what is best (it seems a bit easier to do for let's say a CPU then a CODEC ...) | [14:09] |
| hverkuil | I suspect it is highly HW dependent. So either private controls or sysfs or possibly even debugfs,
If it is just for debugging, then I'd go with debugfs. If you want to use it as feedback into the userspace application, then I'd go with private controls. This can be a mix of the two, of course. I don't think sysfs is a good idea. | [14:11] |
| ............... (idle for 1h10mn) | ||
| tfiga | ndufresne: hverkuil: also depends on whether we're interested in per context numbers
And I suspect me might be I'd second using controls. Vendor specific or generic, depending on the data of course | [15:23] |
| ndufresne | tfiga: right, per context / stream is more likely
the proposal I got was to aggregate this and create some sort of HUD into the application similar to youtube stats-for-nerd view I suppose but more HW level hverkuil: tfiga: My question would be, if some of the stats are generic, or common on multiple HW, how do we convert private to public controls (considering backward compat and all) is that something common ? I guess it might be case by case we should perhaps avoid having some structure based stats, or other blobs | [15:39] |
| hverkuil | I wouldn't use structs, just single values. Easier to maintain, and also easier to 'promote' a private control to a standard control (the original driver will have to support both in that case, this has happened before). | [15:53] |
| *** | mhp has left | [16:03] |
| mhp | i have a technical noob question | [16:06] |
| jm_h | mhp, please ask :-) | [16:17] |
| mhp | the tvp5150 has has 2 interrupt registers that require i2c_client irq's to be passed through tvp5150_probe(struct i2c_client *c). the chip has some very useful interrupt functionality, however c->irq is always set to 0. I'm wondering where i2c_client is set. I've combed through the documation, googled, and greped with no luck. any info is
appreciated. | [16:27] |
| ................................ (idle for 2h39mn) | ||
| mchehab | mhp1: it is always set to zero, because none of the devices supported so far needed that. It is as simple as that
We can accept upstream patches that will add support for other boards that could benefit on having IRQs enabled at tvp5150, together with the changes for tvp5150 to optionally support it | [19:06] |
| ............................................. (idle for 3h43mn) | ||
| *** | mhp1 has left | [22:51] |
| mhp | With respect to the em28xx/tvp5150 reference device, I'd like to properly set the interlaced_fieldmode, progressive, and possibly negotiate line count in the em28xx-video file as much hardware isn't 601 standard, and the tvp5150's interrupt register b's TV/VCR mode is able to detect line count and interlace and non-interlaced signals and other functionality. I'd be happy to send a patch. One thing I've not found is where c->irq is set.
fo regarding that would be helpful. thanks @mchehab. | [22:53] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |