| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| mszyprow | hverkuil: hi | [09:03] |
| hverkuil | mszyprow: hi | [09:03] |
| mszyprow | hverkuil: may I ask you to ack https://patchwork.linuxtv.org/project/linux-media/patch/20200904131711.12950-31-m.szyprowski@samsung.com/ and https://patchwork.linuxtv.org/project/linux-media/patch/20200904131711.12950-30-m.szyprowski@samsung.com/ ? I don't remember how the merge procedure looks like nowadays | [09:04] |
| hverkuil | mszyprow: out of curiosity: what exactly will go wrong if dma->sglen instead of dma->nr_pages is passed to dma_unmap_sg()?
mszyprow: reviewed and acked both patches. | [09:15] |
| mszyprow | hverkuil: if there is no iommu (and most legacy systems don't have it), nothing, because nr_pages equals to sglen
hverkuil: but I wanted to fix it to avoid the issue in the future, when that incorrect code might be copy/pasted to the different driver hverkuil: thx | [09:16] |
| hverkuil | Nice to have these new scatterlist helpers, that should prevent similar problems in the future. | [09:20] |
| mszyprow | hverkuil: well, I was surprised how often it was used incorrectly
hverkuil: but to be honest, the scatterlist api is a bit messy | [09:24] |
| hverkuil | mszyprow: I'm not surprised. I still think that the scatterlist.h documentation for struct sgtable is much too obscure. | [09:27] |
| mszyprow | hverkuil: do I need to write to mchehab to merge those 2 via media tree? I remember there is a patchwork and patches has to be marked there, but I lost my password and reset pw mail doesn't come | [09:32] |
| hverkuil | I can take them if you like? They are independent of the remainder of that v10 series, right?
I want to post a PR today anyway, so I can just add these two to that. | [09:32] |
| mszyprow | hverkuil: that would be great
hverkuil: they are independed hverkuil: I've already sent a pull req for the drm part | [09:33] |
| hverkuil | 24-26 should be added as well, I guess.
no, 24 is drm. 25 is dmabuf, but I can take 26 (staging/media) Or is that part of your drm PR? mszyprow: ^^^ should I also take patch 26/30? | [09:34] |
| mszyprow | hverkuil: it has been merged separately
hverkuil: dmabuf went together with drm hverkuil: my pr https://lore.kernel.org/dri-devel/20200910080505.24456-1-m.szyprowski@samsung.com/ | [09:40] |
| hverkuil | mszyprow: the tegra-vde patch isn't part of your PR, so do I understand it correctly that someone else picked it up? Sorry for the questions, I just want to make sure it doesn't fall through the cracks. | [09:44] |
| mszyprow | hverkuil: gkh took it
hverkuil: patch "staging: tegra-vde: fix common struct sg_table related issues" added to staging-next | [09:48] |
| hverkuil | OK, then it's just patch 29 and 30. Thank you. | [09:48] |
| ................ (idle for 1h15mn) | ||
| mszyprow: posted PR for this (sorry, forgot to CC you in the PR)
https://patchwork.linuxtv.org/project/linux-media/patch/707bbc69-b071-4fb0-71ff-a54eb87a60f9@xs4all.nl/ | [11:03] | |
| mszyprow | hverkuil: thx | [11:03] |
| ....................... (idle for 1h50mn) | ||
| tfiga | pinchartl: sailus: Hello! We have an interesting hardware design, where a UVC camera has a hardware privacy switch and it reports the state of it to the system via a GPIO.
I was considering exposing the state of the switch via a gpio-keys (or what the name was) input device and then having some means of associating it with the right camera but some folks are suggesting that it should be fully handled within the media subsystem (basing on the network subsystem, which has the link state signalling) (also, the use case for the signal to the system is to show a message to the user that they forgot to disable the privacy switch when they are trying to use the camera) | [12:53] |
| *** | blinky42 has quit IRC (Ping timeout: 246 seconds) | [13:06] |
| ........ (idle for 35mn) | ||
| ndufresne | tfiga: sounds like a discussion we had around "other HW" that are connected to the camera but aren't easily associated, perhaps a way to express them in the topology
but it will revive argument between what one topology contains, what is a graph, etc. I don't think USB buttons on camera are within the media subsystem, perhaps an hybrid, a bit like flash ? | [13:41] |
| ..... (idle for 22mn) | ||
| pinchartl | tfiga: is the system ACPI- or DT-based ? | [14:04] |
| tfiga | ultimately I expect us to have both, but the first one has ACPI
ndufresne: I had similar thoughts | [14:05] |
| pinchartl | how will you report the association to the driver ? | [14:07] |
| tfiga | that's a good question, but we have the interface links in MC, which maybe could work? | [14:07] |
| pinchartl | I mean from firmware to the driver | [14:10] |
| tfiga | heh, I wonder, since there are no firmware nodes for USB devices I guess... | [14:14] |
| pinchartl | USB hubs and their ports can be modelled in ACPI
i would be good to standardize a way to associated device-specific data to that | [14:16] |
| tfiga | interesting
I guess I'd have to check with our firmware folks did you see anything similar for DT? | [14:23] |
| broonie | The idiomatic way to do this stuff on Windows/ACPI appears to be to key off DMI data. :( | [14:24] |
| pinchartl | tfiga: Documentation/devicetree/bindings/usb/usb-device.txt
not showing the full picture, I'm not sure if it's fully implemented, but there's a path forward | [14:32] |
| tfiga | cool, thanks!
in any case, assuming that we actually find a way to link the two devices, I'm still wondering how to expose it to the userspace it could be also exposed as a V4L2 control and since we have control events, we would even be able to avoid polling | [14:34] |
| pinchartl | you should have wired it to the UVC controller as a button :-) | [14:38] |
| sailus | tfiga: I guess the ACPI spec isn't really helpful there. | [14:38] |
| tfiga | a completely lame alternative would be to just expose a separate input device and have the userspace figure out itself that it's the camera privacy switch...
I wonder how rfkill works https://elixir.bootlin.com/linux/latest/source/net/rfkill/rfkill-gpio.c I might have to dig deeper, but it looks like it's just the "lame" way? | [14:40] |
| kbingham | tfiga, I assume it's not relying upon userspace to respect the setting of the switch to determine whether or not to read from the camera right ...
and that this is just to report the 'state' of the switch ... | [14:49] |
| tfiga | correct | [14:50] |
| ..... (idle for 21mn) | ||
| pinchartl: how do we handle buttons on UVC controllers?
aha, I found it https://elixir.bootlin.com/linux/v5.9-rc4/source/drivers/media/usb/uvc/uvc_status.c the difference here is that it's not a button, but rather a switch my recollection is that the input subsystem is event-driven is it possible to obtain the initial state? | [15:11] | |
| pinchartl | well, the switch isn't connected to the UVC controller, so it won't be handled by the UVC status code in any case | [15:20] |
| tfiga | pinchartl: well, it could be in the future, if we think it's a better way to do it
but maybe not :) pinchartl: on an unrelated note, I stumbled upon the isight hack today and it looks like they had quite a good idea on how to improve the protocol efficiency we could actually avoid the whole copy and submit user buffers as URBs directly I guess | [15:33] |
| kbingham | tfiga, was that the zero-ish copy thing ... | [15:35] |
| tfiga | with the .data_offset field used to offset for the initial header
yeah, I guess :) we had some discussion with kernel folks on how uvc 2.0 could look and the need for the frame assembly was one of the major things to take care of | [15:36] |
| pinchartl | tfiga: the UVC protocol is crap, I agree | [15:39] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |