minash has quit [Remote host closed the connection]
minash has joined #linux-ti
florian has quit [Ping timeout: 272 seconds]
ikarso has joined #linux-ti
rob_w has joined #linux-ti
Kubu_work has joined #linux-ti
Peng_Fan has joined #linux-ti
florian has joined #linux-ti
florian_kc has joined #linux-ti
florian_kc has quit [Ping timeout: 268 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
florian has quit [Ping timeout: 264 seconds]
florian has joined #linux-ti
ikarso has joined #linux-ti
tomba has joined #linux-ti
<tomba>
I have a question related to device power management. I was under the impression that the device hardware is enabled only when a driver chooses to enable it, but I noticed that the driver core seems to do some part of this automatically.
<tomba>
In this specific case what I observe is that if the AM62 DSS is enabled by the bootloader, and the kernel driver's probe is called, but it immediately returns -EPROBE_DEFER, the DSS device is turned off (as shown by k3conf).
<tomba>
I presume that's related to the power-domain, so the driver core handles the power-domain automatically, enabling it before the probe is called, and disabling it after driver remove has been called, perhaps?
<tomba>
This is rather problematic as the DSS hardware will go into a bad state if it's powered off while it is active.
<tomba>
So... Do my observations/points above make sense? Is that how power-domains work? Would it be possible for the framework to keep the current state of the power-domain if the driver probe fails?
rob_w has quit [Remote host closed the connection]
manchaw has quit [Quit: Connection closed for inactivity]