<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
sailus: <u>mchehab</u>: Bom dia!
mchehab: moikka!
<br> I double-checked the patches you pointed, and a few others: none of them are returning -EAGAIN at the .suspend callback
sailus: That's probably correct behaviour.
<br> The code is old and little tested.
<br> Speaking of which: I'm not at all certain CSI-2 subdev/master device drivers generally handle suspend and resume correctly.
mchehab: yeah, resuming PM just before suspending seem weird
sailus: I don't think it's been tested a lot either.
mchehab: I doubt that the suspend/resume code is tested on most drivers ;-)
sailus: Something to look at when there's time...
<br> Well, true. Unfortunately.
mchehab: yes
<br> anyway, returning -EAGAIN sounds a bug
<br> so, I'm applying a patch before the series making it return rval instead
<br> (for ccs driver)
sailus: Obrigado!
mchehab: you're welcomd
<br> <u>sailus</u>: I guess I know from where the -EAGAIN came from
<br> check rpm_check_suspend_allowed() at drivers/base/power/runtime.c
<br> else if (atomic_read(&dev->power.usage_count) > 0)
<br> retval = -EAGAIN;
<br> so, basically, if a driver calls pm_runtime_*get*(), it can't be suspended, util it calls pm_runtime_put*()
<br> on most sensor drivers, pm_runtime get is called when streaming, it means that suspend will be disabled while the device is streaming
<br> the right suspend logic would be to disable stream, call pm_runtime_put and then suspend
<br> and, at resume, check if it was streaming. if so, run pm_runtime_get and re-start streaming
<br> (that's theoretical - tests are required to double-check)
<br> also, autosuspend needs to be checked
<br> as drivers should not autosuspend while streaming
mfelsch: <u>pinchartl</u>: ping
pinchartl: <u>mfelsch</u>: pong
<br> <u>mchehab</u>: ideally, the sensor shouldn't suspend itself
<br> the bridge should be suspended first
<br> which will call .s_stream(0) on the sensor
<br> and the other way around on resumt
<br> it's especially important at resume time, to ensure a controlled order of the stream start
<br> otherwise, especially with CSI-2, the RX can fail to synchronize
mfelsch: <u>pinchartl</u>: Hi, thans for imx8mm series :) Was the connection between the mipi-csi and the csi working out of the box using the imx7-media-csi driver?
pinchartl: unfortunately not
<br> it works with the ov5645
<br> as well as the ar0144
<br> but I have an mt9m114 that I can't get to work properly
<br> no idea why. the interface between the CSIS and the CSI bridge is poorly documented, there are parameters on both sides that are not well explained
mfelsch: <u>pinchartl</u>: Ah okay, so there is some risk bring up the csis and the csi brigde with a new sensor.
<br> <u>pinchartl</u>: How did you manged the dphy setup?
pinchartl: badly :-)
<br> there are two parameters only
<br> the Ths_settle and Tclk_settle
<br> the formet isn't documented in the RM, but there's documentation in NXP forums, with values based on the D-PHY clock frequency
<br> the driver handles that automatically
<br> for Tclk_settle, it's badly documented, with no explanation as to what value to use
<br> it's still an open problem
mfelsch: <u>pinchartl</u>: I'm asking because the dphy gets configured through the blk_ctrl or did I miss somehing?
<br> <u>pinchartl</u>: the display_blk_ctrl isn't currently mainline available
pinchartl: on i.MX8MM, I've configure the PHY through the CSIS only
<br> and it works fine with two different sensors
mfelsch: <u>pinchartl</u>: oh, okay. I thought that the mipi-csi controller is connected to the standalone mipi-dphy
pinchartl: it doesn't seem so, but it's not entirely clear
<br> NXP reference manuals aren't exactly known to be clear and correct
<br> the DISPLAY_BLK_CTRL has been added in rev 3, it wasn't present in rev 2
<br> it may or may not be there
<br> speaking of which, I need to go for a bit
mfelsch: <u>pinchartl</u>: I think the blk_ctrl was there all the time but they didn't documented it, unfortunately. Question is if we need to configure the MIPI-DPHY too since I think that this is done currently within the TF-A and according my knowledge this should be moved to linux.
<br> <u>pinchartl</u>: Thanks for your information :)
ezequielg: <u>hverkuil</u>: very nice.
***: GBenji has left
pinchartl: <u>mfelsch</u>: it should definitely be moved to Linux
***: igrtrrt has left
Nable80: <u>mchehab</u>: hi! I've seen you were online recently, could you help me with atomisp a bit? I'm currently stuck with 2 problems: 1) how to find the right firmware file for 2401 (CHT) hardware and 2) how to wake this beast from D3hot/D3cold state, PCI power management doesn't seem to be working for this device:
<br> atomisp-isp2 0000:00:03.0: can't change power state from D3hot to D0 (config space inaccessible)