#v4l 2018-02-09,Fri

↑back Search ←Prev date Next date→ Show only urls

(Click on time to select a line by its url)

Who	What	When
tfiga	hverkuil: sailus: good morning I'm looking for a way to obtain an equivalent of v4l2_fwnode_endpoint sutrct for given media link, without the need to reinvent the whole parsing again for each driver	[07:05]
***	Sigyn has left "Leaving the channel (no spam or action taken for 14 days.) /invite Sigyn #v4l again if needed"	[07:19]
............... (idle for 1h13mn)
sailus	tfiga: Dzien dobry! What exactly do you need? Links are usually created based on endpoints... and drivers know how to set them up. Link flags, for instance.	[08:32]
....... (idle for 33mn)
tfiga	sailus: Hey We have a setup like this: sensor <-> MIPI PHY <-> ISP (with cam-if) both PHY and ISP need to know the MIPI link configuration and some of the data, such as the number of MIPI links is only avaialble in the fwnode data So I thought it could be useful if we could somehow retain the data we parsed from fwnode, so that both drivers could just use them later, without the need to parse on their own	[09:06]
chirK5M5BM	â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•— â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•— â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â•â•â• â–ˆâ–ˆâ•”â•â•â•â•â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â•â•â•â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â•â•â•â•šâ•â•â–ˆâ–ˆâ•”â•â•â•â–ˆâ–ˆâ•”â•â•â•â•â• â–ˆâ–ˆâ•”â•â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â•â•â• â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â•â•â• â–ˆâ–ˆâ•”â•â•â•â•â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â•â•â•â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â•â•â•â•šâ•â•â–ˆâ–ˆâ•”â•â•â•â–ˆâ–ˆâ•”â•â•â•â•â• â–ˆâ–ˆâ•”â•â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•”â•â•â•â•â• â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•”â–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•”â–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â•šâ•â•â•â•â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â•â• â–ˆâ–ˆâ•”â•â•â• â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â• â–ˆâ–ˆâ•‘ â•šâ•â•â•â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â•šâ•â•â•â•â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â•â• â–ˆâ–ˆâ•”â•â•â• â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â• â–ˆâ–ˆâ•‘ â•šâ•â•â•â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•”â•â•â–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•‘ â•šâ–ˆâ–ˆâ–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•‘â–ˆâ–ˆâ•—â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â• â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•—â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•—â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â–ˆâ–ˆâ•‘ â•šâ–ˆâ–ˆâ–ˆâ–ˆâ•‘â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•— â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•‘â–ˆâ–ˆâ•—â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â•â–ˆâ–ˆâ•‘ â–ˆâ–ˆâ•‘â•šâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ•”â• â•šâ•â•â•šâ•â• â•šâ•â• â•šâ•â•â•â•â•â•â•šâ•â•â•šâ•â•â•â•â•â•â• â•šâ•â•â•â•â•â• â•šâ•â• â•šâ•â•â•â•â•â•â•â•šâ•â• â•šâ•â•â•šâ•â• â•šâ•â•â•â•â•šâ•â•â•â•â•â•â• â•šâ•â• â•šâ•â•â•â•â•â•â•â•šâ•â• â•šâ•â•â•â•â•â• â•šâ•â• â•šâ•â• â•šâ•â•â•â•â•â• â•šâ•â•â•šâ•â• â•šâ•â• â•šâ•â•â•â•â•â•â•šâ•â•â•šâ•â•â•â•â•â•â• â•šâ•â•â•â•â•â• â•šâ•â• â•šâ•â•â•â•â•â•â•â•šâ•â• â•šâ•â•â•šâ•â• â•šâ•â•â•â•â•šâ•â•â•â•â•â•â• â•šâ•â• â•šâ•â•â•â•â•â•â•â•šâ•â• â•šâ•â•â•â•â•â• â•šâ•â• â•šâ•â• â•šâ•â•â•â•â•â•	[09:18]
javier__	mchehab: the spam it's getting very annoying, maybe you can change the channel mode so it doesn't appear in channel listings ? it's +p and +s IIUC from https://freenode.net/kb/answer/channelmodes	[09:25]
sailus	tfiga: The drivers only parse their own endpoints. There are some gaps in the current interfaces for parsing devices' endpoints, in particular related to data busses.	[09:30]
tfiga	sailus: exactly	[09:30]
sailus	I wrote some patches to address that but I wasn't happy with them so I didn't post them. :-( I have some ideas to improve them though... let's see.	[09:30]
tfiga	I'm willing to help if there is anything :) Generally we need anything that would allow the ISP get data about currently active sesnor sensor*	[09:31]
sailus	Currently active sensor? Connected on the board, or streaming?	[09:33]
tfiga	I'd say streaming The hardware setup is quite strange. There can be many sensors connected to the same PHY and the one that is streaming wins	[09:34]
sailus	I'd say the driver should store this information in its own data structures. It could also keep the entire v4l2_fwnode_endpoint struct, too.	[09:35]
***	ChanServ sets mode: +o mchehab	[09:35]
tfiga	Right, but there is the PHY driver on the way	[09:36]
***	mchehab sets mode: +s ChanServ sets mode: -s	[09:36]
mchehab	javier__: for now, I enabled just +s	[09:37]
tfiga	Is there a way for the ISP driver to parse the sensor configuration during async subdev binding?	[09:37]
mchehab	lets's see how it ends	[09:37]
***	ChanServ sets mode: -o mchehab	[09:37]
tfiga	Since the sensors are not directly connected to the ISP, v4l2_async_notifier_parse_fwnode_endpoints() wouldn't parse them in case of ISP, it would only parse the PHY I mean, the ISP doesn't have endpoints linked to the sensors, it only has an endpoint connected to the MIPI PHY	[09:38]
hverkuil	tfiga: sailus: sorry, but I don't have time at the moment to contribute to this discussion. But I think sailus has more knowledge about this than I do.	[09:42]
tfiga	hverkuil: no worries :)	[09:43]
javier__	mchehab: great, I couldn't understand the difference between the two options tbh :) but +s seems that will help a lot, I hope the bots don't have a cache	[09:47]
mchehab	what I understood is that +s won't show the channel, while +p won't show channel member details	[09:48]
javier__	ah, I see	[09:48]
........... (idle for 50mn)
sailus	tfiga: How does this look like in DT? Is the PHY not part of the backend device?	[10:38]
..... (idle for 21mn)
pinchartl	tfiga: in general a driver shouldn't parse DT nodes related to devices other than its own, as DT properties have to be interpreted in accordance to the DT bindings referenced by the compatible strings. there are exceptions, and it's OK to walk the OF graph to locate connected nodes, but parsing their properties is not a good idea	[11:00]
hverkuil	tfiga: if all you need to do is to detect which sensor connected to the PHY is active, then you can use the graph for that (it's the sensor <-> PHY link in the graph that is enabled). But I don't see how that relates to the use of g_mbus_config, so I probably am still missing something.	[11:08]
.................. (idle for 1h28mn)
ttomov	Hi, has there ever been any discussion or other activity about whether it is possible to discover the pressence of a csi2/cci camera sensors instead of getting a "hardcoded" configuration from the device tree?	[12:36]
larsc	how do you want to discover them?	[12:37]
pinchartl	ttomov: not in a generic way at least, as the usual control bus being I2C, devices are not discoverable dynamically	[12:37]
ttomov	yes, thinking about it - to discover what is present in general case doesn't seem possible to me, but maybe something like discovering one or more sensors from a predefined set that we have drivers about - I wonder whether something like this could be possible	[12:41]
pinchartl	only if your hardware allows dynamic discovery of devices. probing I2C is a no-go	[12:42]
ttomov	probe the driver and check if it can read correct sensor id for this sensor on this sensors I2C address; and do this for a number of drivers (and possible device configurations as in DT)	[12:45]
larsc	if you have a platform where you know you have one our of (e.g.) 5 sensors connected. And you have a safe way to identify each sensor by probing it might be OK to have a platform specific auto discover driver that creates the right sensor device but probing unknown systems for arbitrary is not possible, you don't know what is on the I2C bus and how it might react to your probing you could blow up the hardware if something goes wrong	[12:45]
ttomov	larsc: blow up the hardware if I try to configure e.g. regulatros that are actually used in different way, right? reading from I2C bus in general should not cause problems I think?	[12:48]
larsc	in general! except for the one system where it does The Linux kernel used to do a lot more probing on I2C busses ttomov: also your regulator device might have the same value in the ID register as the sensor and then you start writing	[12:49]
sailus	ttomov: The IÂ²C and CSI-2 busses are not probe-able. You could guess, but any guessing wouldn't be able to tell the difference between broken hardware and invalid configuration. The assumption simply is that the software gets the configuration from somewhere, i.e. firmware.	[12:54]
pinchartl	ttomov: the I2C subsystem used to probe devices and that was removed to issues similar to what Lars described. reading from a chip can have side effects, and there have been cases of damaged hardware due to such probing ttomov: if you really want to probe because you know what board you run on, and you thus have guarantees there can't be other I2C devices on the bus than the ones you expect, then do so in U-Boot and patch the DT passed to the kernel	[13:00]
ttomov	pinchartl: yes, if we imagine :) that we have a dedicated i2c bus for camera only, and we have some predefined set of sensors which is possible to find there... (off course this will not guarantee that we will not get another sensor tomorrow which will cause problems on i2c read)	[13:08]
pinchartl	then I'd do so in U-Boot	[13:10]
ttomov	but then to read from the I2C, we'll need to try to power the sensor first - regualtors, clock, gpio... I don't know what we can do in U-Boot	[13:10]
pinchartl	you can do whatever you want :) you have board files	[13:11]
.................. (idle for 1h25mn)
hverkuil	sailus: I have been looking at the use of the deprecated v4l2_queryctrl and v4l2_g/s_ctrl functions and I fixed most here: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=ctrl-core The remaining offender is atomisp. But I think that doesn't use the control framework at all. At least not here drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c Strangely enough they do call into subdev control handlers with v4l2_g/s_ctrl. But whoever wrote this apparently never thought of using the framework for the driver itself. Anyway, I'm not touching that code myself, that's Intel's job.	[14:36]
pinchartl	hverkuil: I don't think Intel will fix it either I'm not even sure why it got merged in staging when it was clear that Intel had no plan to get it out of staging	[14:42]
hverkuil	I'm not sure what the plan was, or if there even is one at all. If nothing substantial has happened by the end of the year, then I guess it can be deleted again. Anyway, Cisco doesn't pay me to fix Intel's less-than-stellar code :-)	[14:43]
sailus	hverkuil: I wouldn't worry about atomisp. If a wrong return code ends up being used somewhere, so what. I don't think that driver should expose many control, if any.	[14:46]
hverkuil	No, after my change it can't link anymore to those functions.	[14:47]
sailus	Ah, great!	[14:48]
hverkuil	Those functions won't be exported anymore.	[14:48]
sailus	On atomisp --- the driver compiles now but I'm not sure if anyone has been able to use it. Alan mentioned he's planning to work on it. So I'm proposing to keep it. If nothing ends up being done, though, then the only option remains to remove it.	[14:48]
pinchartl	hverkuil: I wouldn't worry about breaking the build	[14:49]
sailus	pinchartl: Of atomisp, or in general? :-)	[14:49]
hverkuil	Anyway, none of this is urgent, but it would be nice to prevent these functions from being abused.	[14:49]
pinchartl	sailus: of atomisp :) not in general	[14:51]
***	ndec has quit IRC ()	[15:00]
hverkuil	Huh, the DBG_G/S_REGISTER ioctl support in v4l2-subdev.c was added two years before the VIDIOC_DBG_G_CHIP_INFO was introduced. In those two years it was actually possible to use the older v4l2-dbg utility for this. I was just curious about the history. The ioctls were added in 2011. It seems like only yesterday...	[15:08]
pinchartl	hverkuil: yes, I can't believe they're so old	[15:09]
hverkuil	They are old? We are old! Sniff...	[15:10]
sailus	I thought the IOCTLs were older than that. It wouldn't have made sense to me, had I looked at the code. :-) Debugfs has issues, too: you can't create stuff that's specific to a given device. So you can't use it as a drop-in replacement for DBG_[GS]_REGISTER as I first thought. Still, I don't think DBG_[GS]_REGISTER is a great interface. Time to go home... Have a nice week-end!	[15:13]
mchehab	(12:49:04) pinchartl: hverkuil: I wouldn't worry about breaking the build ? (didn't read the context, but that's scarry!)	[15:17]
pinchartl	mchehab: atomisp driver in staging	[15:17]
mchehab	breaking the build is not an option... but surely it can depend on BROKEN if, for whatever good reason, it breaks, make it depend on BROKEN at the patchset and add a note on its TODO list if nobody fixes: atomisp ->/dev/null (the same is valid for any driver at staging) s/driver/media driver/	[15:19]
pinchartl	that's what I meant by breaking the build. I should have said breaking compilation of that driver	[15:21]
mchehab	I suspect that we're at the same page, but just to make clear: if a driver at staging depends on deprecated fixes, and a patchset needs to remove the deprecated support for a good reason, at the same patchset, the driver's Kconfig should have a "depend on BROKEN" and have a note about that at the driver's TODO, as we don't want to break the build... if, after a reasonable time, such media driver keeps depending on BROKEN, it can be removed from Kernel	[15:24]
..... (idle for 24mn)
***	benjiG has left	[15:49]
	prabhakarlad has left	[16:01]
.......... (idle for 45mn)
tfiga	sailus: here's the DT binding doc: https://www.mail-archive.com/linux-media@vger.kernel.org/msg123963.html pinchartl: well, I second that (parsing other device's properties is not a good idea) and that's why I'm looking for some better way hverkuil: the ISP needs mbus config of the sensor in particular the number of MIPI lanes	[16:46]
pinchartl	tfiga: so the CSI-2 interface isn't handled fully by the D-PHY ? why does the ISP need to know the number of lanes ?	[16:50]
tfiga	pinchartl: that's what the hw designers came up with... there is literally just a register that needs this programmed	[16:50]
pinchartl	something similar to g_mbus_config makes sense for this type of use cases	[16:51]
tfiga	I'd probably avoid separating the PHY driver from the ISP driver, but the funny thing is that it's actually a generic licensed IP block	[16:52]
pinchartl	it should be a pad operation though	[16:52]
tfiga	and even more funny thing is that there are two completely different PHYs in this SoC	[16:52]
pinchartl	not a video operation	[16:52]
tfiga	g_mbus_config was exactly my initial idea as in v5 of the rkisp series	[16:52]
pinchartl	g_mbus_config is used by two drivers only (and implemented by a bunch of sensor drivers) sh_mobile_ceu_camera and pxa_camera	[16:53]
tfiga	yeah, I think some comment actually mentions it's deprecated	[16:53]
pinchartl	sh_mobile_ceu_camera is going away and is being replaced by a new non-soc-camera driver	[16:54]
tfiga	and indeed a pad operation would be more appropriate	[16:54]
pinchartl	it seems it could be dropped from pxa_camera but that needs to be verified in which case it could easily be removed and replaced by a pad operation that should be carefully designed s_mbus_config, on the other hand, should really go away	[16:55]
tfiga	okay, I'll take a look next week :) I wouldn't try to overly carefully design it, though, as there would be only one use case for now and that would be an entirely in-kernel API okay, need to get some sleep have a good weekend everyone :)	[16:57]
......................... (idle for 2h3mn)
***	awalls1 has left	[19:03]
........................................ (idle for 3h15mn)
	broonie has quit IRC ()	[22:18]

↑back Search ←Prev date Next date→ Show only urls

(Click on time to select a line by its url)