On Fri, 4 Oct 2024 at 19:34, Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 02/10/2024 10:55 pm, Ulf Hansson wrote: > > On Sat, 14 Sept 2024 at 13:52, Heiko Stübner <heiko@xxxxxxxxx> wrote: > >> > >> Am Donnerstag, 12. September 2024, 09:26:14 CEST schrieb Kever Yang: > >>> In order to make the SD card hotplug working we need the card detect > >>> function logic inside the controller always working. The runtime PM will > >>> gate the clock and the power domain, which stops controller working when > >>> no data transfer happen. > >>> > >>> So lets skip enable runtime PM when the card needs to detected by the > >>> controller and the card is removable. > >>> > >>> Signed-off-by: Kever Yang <kever.yang@xxxxxxxxxxxxxx> > >> > >> So for the change itself this looks good, i.e. it fixes an issue for baords relying > >> on the on-chip-card-detect. > >> > >> > >> But for boards doing that, the controller will be running _all the time_ > >> even if there is never any card inserted. > >> > >> So relying on the on-soc card-detect will effectively increase the power- > >> consumption of the board - even it it'll never use any sd-card? > > > > Good point! A better option is to use a polling based mechanism - and > > we have MMC_CAP_NEEDS_POLL for exactly that. > > > > Moreover, on DT based platforms one can even use the "broken-cd" > > property to indicate this. > > Except that goes further than is needed here, since it would fall back > entirely to software-based polling for card presence. In this case the > CD function is not broken in terms of actually detecting a card, it just > doesn't work to wake the controller up from suspend because it can't > fire its own interrupt while powered off. In principle all we should > require here is to periodically resume/suspend the device, to provide a > window for the interrupt to work and normal operation to take over if > appropriate. Well, I would not object if "broken-cd" would be used for this case too. I believe it already is. Another option would be to look at a compatible string and set MMC_CAP_NEEDS_POLL based on that. > > Of course the really clever way would be for suspend to switch the pin > into GPIO mode, and set the GPIO interrupt as a wakeup to trigger resume > and switch it back again, but perhaps that's a bit tricky without > explicit pinctrl states in the DT :/ Right. A dedicated GPIO pin for the card detect is certainly the preferred method, if you care about not wasting power. Kind regards Uffe
