On 24/02/14 15:16, Philipp Zabel wrote: > Hi Srinivas, > > Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla: >> Thanks Philipp for your comments, >> >> On 24/02/14 10:33, Philipp Zabel wrote: >>>>> Did Srini's explanations convinced you? >>>>> >>>>> If so, could you queue the series for v3.15? >>> to be honest, I'm not comfortable with this explanation. If the >>> "powerdown" bits only gate the clocks to those modules, calling it a >>> reset control is clearly the wrong abstraction. If that is the case, >>> couldn't you handle those bits via the clock framework? >> I just had a re-look at the IPs specs for more information on where >> these power-down signals are actually terminating on the IP side. >> >> For example: ST-Synopsis Ethernet GMAC IP has two pins >> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by >> the software to either put the IP in powerdown or bring it out of >> powerdown state. > > Now I'm a bit confused. There is no mention of GMAC in your patches, > and for ETH[01] they contain only the SOFTRESET bits. I have no issue > with the SOFTRESETs. Yes, GMAC was a bad example indeed. However this same logic applies to the USB IP as well. GMAC power-down-reset can be added to the power-down-reset list for consistency. We did not define the power-down-reset for GMAC because the reset state of GMAC will not be in power down. softreset should be enough to bring the IP in to a usable state. So the software never drives the power down-request but instead uses softreset in this particular case. > >> The IP itself drives power_down_ack to indicate when the power down >> request is successfully finished. For power_down/power_up request the IP >> will change the internal state accordingly including powering up/down >> its internal blocks and/or clock gating. >> >>> If on the other hand these powerdown bits also trigger reset machinery, >>> such that asserting and deasserting that bit will change the module's >>> internal state, I could be convinced to queue them like this. >> This is true with ST IPs, these lines change the state of the IP as >> described above. Reset framework seems to fits in very well with this >> behavior rather than power-domains or clock framework. > > If you put the IP in power down when it is idle, and then power it up > again, will the IP registers have kept their previous state? No, the context is lost, the IP needs re-initialization. Thanks, srini > > regards > Philipp > > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
