[...] >>> But considering about the benefits, it is not that urgent to take runtime pm >>> feature as a must, it is a better to have feature. System standby is a must >>> feature, without this patch, the system can't work well after resume. >>> Do you think it is reasonable to add complete standby support at first, then >>> take runtime pm as a next step? >> >> You can do that, but why? And will then the "next step" ever happen? >> >> Do you really want to spend efforts in getting something working for >> system suspend only, while you instead easily could deploy both >> runtime PM and system PM support at the same time? >> > > As the author of this patch, I'd like to argue for myself here, although it is > not my task any more. :p > The reason of implementing system PM firstly, is definitely NOT that > runtime PM is > unnecessary. Instead, I was just not able to. > > Internal customers in Marvell and external customers previously just required > simple system PM. Thus I decided to meet customers requirement at first. > Otherwise, I didn't have any platform to verify runtime PM even if runtime PM > is completed. > > Those SoCs implementation vary a lot. Thus I was actually not sure > what a generic Xenon runtime PM should look like for all those Marvell products. > I previously planed to implement runtime PM when I got enough resources > (boards/BSP/supports) from customers. If saving power during system sleep makes sense, then it seems odd that one don't want to care about saving power in runtime as well. Anyway, I rest my case and I won't prevent you from adding only system sleep support. > >>> >>>> Besides the clocks, you have the xenon mmc phy. Can't that also be put >>>> that in some low power mode at request in-activity? >>> >>> For the phy behavior, currently I don't see any SW operation for the lpm, I >>> will check with HW guys about the behaviour. >> >> Great, that would really be interesting from a runtime PM point of view. >> >> Perhaps then also ask if re-configuring the phy via xenon_phy_adj(), >> makes sense when powering off the card? Because currently you seems to >> keep the latest configuration, even if the mmc core decides to power >> off the card during system sleep. Unless I am reading the code wrong >> from the ->set_ios() ops. >> > > As I know, PHY HW will also automatically enter standby mode > (power saving mode) > when ACG/SDCLK-off-while-idle are triggered. Actually there is no SW interface > to "enable" or "disable" PHY. It requires confirm from HW bros. > > xenon_phy_adj() will set PHY based on current timing. For example, > when coming back > from resume, xenon_phy_adj() will re-configure PHY for legacy timing. > Thus it is unnecessary to clean PHY setting before sleep. Okay, thanks for clarifying. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
