sailus: ping
mchehab: Bom dia!
moikka!
I double-checked the patches you pointed, and a few others: none of them are returning -EAGAIN at the .suspend callback
That's probably correct behaviour.
The code is old and little tested.
Speaking of which: I'm not at all certain CSI-2 subdev/master device drivers generally handle suspend and resume correctly.
yeah, resuming PM just before suspending seem weird
I don't think it's been tested a lot either.
I doubt that the suspend/resume code is tested on most drivers ;-)
Something to look at when there's time...
Well, true. Unfortunately.
yes
anyway, returning -EAGAIN sounds a bug
so, I'm applying a patch before the series making it return rval instead
(for ccs driver)
Obrigado!
you're welcomd
sailus: I guess I know from where the -EAGAIN came from
check rpm_check_suspend_allowed() at drivers/base/power/runtime.c
	else if (atomic_read(&dev->power.usage_count) > 0)
		retval = -EAGAIN;
so, basically, if a driver calls pm_runtime_*get*(), it can't be suspended, util it calls pm_runtime_put*()
on most sensor drivers, pm_runtime get is called when streaming, it means that suspend will be disabled while the device is streaming
the right suspend logic would be to disable stream, call pm_runtime_put and then suspend
and, at resume, check if it was streaming. if so, run pm_runtime_get and re-start streaming
(that's theoretical - tests are required to double-check)
also, autosuspend needs to be checked
as drivers should not autosuspend while streaming
pinchartl: ping
mfelsch: pong
mchehab: ideally, the sensor shouldn't suspend itself
the bridge should be suspended first
which will call .s_stream(0) on the sensor
and the other way around on resumt
it's especially important at resume time, to ensure a controlled order of the stream start
otherwise, especially with CSI-2, the RX can fail to synchronize
pinchartl: 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?
unfortunately not
it works with the ov5645
as well as the ar0144
but I have an mt9m114 that I can't get to work properly
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
pinchartl: Ah okay, so there is some risk bring up the csis and the csi brigde with a new sensor.
pinchartl: How did you manged the dphy setup?
badly :-)
there are two parameters only
the Ths_settle and Tclk_settle
the formet isn't documented in the RM, but there's documentation in NXP forums, with values based on the D-PHY clock frequency
the driver handles that automatically
for Tclk_settle, it's badly documented, with no explanation as to what value to use
it's still an open problem
pinchartl: I'm asking because the dphy gets configured through the blk_ctrl or did I miss somehing?
pinchartl: the display_blk_ctrl isn't currently mainline available
on i.MX8MM, I've configure the PHY through the CSIS only
and it works fine with two different sensors
pinchartl: oh, okay. I thought that the mipi-csi controller is connected to the standalone mipi-dphy
it doesn't seem so, but it's not entirely clear
NXP reference manuals aren't exactly known to be clear and correct
the DISPLAY_BLK_CTRL has been added in rev 3, it wasn't present in rev 2
it may or may not be there
speaking of which, I need to go for a bit
pinchartl: 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.
pinchartl: Thanks for your information :)
hverkuil: very nice.
mfelsch: it should definitely be moved to Linux
mchehab: 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:
atomisp-isp2 0000:00:03.0: can't change power state from D3hot to D0 (config space inaccessible)