| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | kbingham[m] has quit IRC (Ping timeout: 276 seconds) | [00:14] |
| ...... (idle for 29mn) | ||
| ali1234 | has anyone ever done virtualbox PCI passthrough with an analog PCI capture card like a bt8x8? linux host and windows guest? is it even possible? | [00:43] |
| .............. (idle for 1h8mn) | ||
| gnurou | hverkuil: sailus: sent the rebased request API RFC - happy hacking! :) | [01:51] |
| ................................................................... (idle for 5h30mn) | ||
| hverkuil | gnurou: thanks! | [07:21] |
| tfiga | hverkuil: good morning | [07:21] |
| hverkuil | tfiga: morning | [07:22] |
| tfiga | let me know when you want to chat about the Rockchip ISP | [07:22] |
| hverkuil | probably in about an hour and a half. It's 8:23 here, so around 10 would be a good time. | [07:24] |
| ....... (idle for 32mn) | ||
| tfiga | sgtm | [07:56] |
| .................. (idle for 1h25mn) | ||
| hverkuil | tfiga: ping | [09:21] |
| tfiga | hverkuil: pong | [09:22] |
| hverkuil | tfiga: OK, so what's the deal with g_mbus_config? :-) | [09:25] |
| tfiga | hverkuil: As you said, normally such data would be parsed directly from DT/fwnode
but it's not so simple because there is a PHY IP block between the sensor and the ISP the PHY needs direct access to the sensor subdev, because it needs to know parameters that can change at runtime such as V4L2_CID_LINK_FREQ and then, for the ISP, the PHY looks kind of like a parallel sensor actually, if you use a parallel sensor, not CSI, there is no PHY in between I mean, no dedicated PHY block that needs management the ISP block itself controls the parallel IF That was the reason for making the topology look like CSI sensor <-> CSI PHY <-> ISP | [09:25] |
| hverkuil | The data in struct v4l2_mbus_type defines the bus (parallel, csi, etc), active low/high and csi lanes.
In almost all cases (there is an exception for lanes) all this information is static, i.e. depending on the board design. | [09:31] |
| tfiga | yeah | [09:32] |
| hverkuil | So what is in struct v4l2_mbus_type that is dynamic for this driver? I don't see how the PHY matters. | [09:32] |
| tfiga | in the v4l2_mbus_type there is nothing dynamic | [09:33] |
| hverkuil | sorry, I meant struct v4l2_mbus_config | [09:33] |
| tfiga | but I wasn't able to find a way to get this data without accessing some internal data of the PHY
AFAICT the async subdev binding only works with the links that are directly connected to the device that registers the async notifier | [09:33] |
| hverkuil | But don't all these subdevs (sensor, phy, isp) use the video-interface bindings? | [09:34] |
| tfiga | yeah, they do
but from the ISP driver, I don't know how to parse that, because I don't know which endpoints,ports of the PHY are used for what it's actually more difficult, because one PHY can be used for more than 1 sensor so I guess, that would be the dynamic part depending on which sensor is enabled, the ISP configuration must be different too so the PHY also works like a pseudo-mux pseudo, because it doesn't select the sensor, the selection is done by only letting 1 of the sensors stream at the same time | [09:35] |
| hverkuil | sorry, got interrupted.
But isn't that defined in the device tree? E.g. the PHY entity has two sink pads, one for each sensor. The ISP can know this since it knows the media topology. And I still don't know how using g_mbus_config would solve any of this, (BTW, I have a meeting in 10 minutes) | [09:44] |
| Oh, wait, this driver isn't using the media controller, right?
That's why you can't figure out the topology in the ISP driver. Or is it using it? I'm confused. Oh, it is. Shouldn't there be a 'depends on MEDIA_CONTROLLER' in the Kconfig? | [09:52] | |
| tfiga | Okay, I think I can see a possible solution indeed
during media pipiline setup, the driver could find the active sensor (must be only one), find the path to it based on pad indices and then traverse DT based on that path g_mbus_config let's the ISP driver use the values, which the PHY driver already parsed at async subdev parsing time | [09:57] |
| *** | philomath has quit IRC (Ping timeout: 240 seconds) | [10:00] |
| tfiga | or rather the fwnode helpers parsed for it | [10:00] |
| hverkuil | Meeting, sorry. 15-30 minutes I guess. | [10:00] |
| tfiga | Okay, no worries
I'll try to explore this approach thanks for a good hint :) | [10:00] |
| ........................................ (idle for 3h15mn) | ||
| *** | benjiG has left | [13:16] |
| ................................................... (idle for 4h14mn) | ||
| benjiG has left | [17:30] | |
| ......................................... (idle for 3h22mn) | ||
| awalls has left | [20:52] | |
| .................... (idle for 1h36mn) | ||
| hverkuil has left | [22:28] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |