[PATCH] mmc: mxs-mmc: implement broken-cd

Lauri Hintsala lauri.hintsala at bluegiga.com
Wed Sep 12 10:06:39 EDT 2012


Hi,

On 09/10/2012 05:58 PM, Matt Sealey wrote:
> I think this describes three use cases which are different, as Shawn
> said we have here;
>
> * missing card detect support (card detect is not wired so it's
> impossible to tell, and the controller doesn't support the SD standard
> card detection)
> * non-removable device
> * broken card detect support
>
> The third one is what the property sounds like it describes, but this
> is not the use case you are describing at all. This kind of property
> naming is more like describing "card detect doesn't operate reliably"
> which is true of i.MX devices with certain versions of the eSDHC and
> uSDHC controllers, where non-GPIO card detection interferes with SDIO
> interrupts, but in this case a board designer should add a real card
> detect pin to the board (most more expensive push-push SD card slots
> come with a pin you can wire for CD). In cases where errata is
> published after boards are shipped, broken-cd is a meaningful
> description when described in the absense of a gpio cd description, or
> presence of some cd-handled-internally style property (forgive me for
> not cross-referencing the FSL definition for this property, we don't
> use it here at Genesi since all our boards have GPIO CD)
>
> It seems your device is a combination of the top two in the list, it
> is not down to a broken feature at all, but one that should be
> possible to not implement for devices which are permanently connected.
> A non-removable device should be able to be powered down, at least
> using runtime PM or clock gating (if this works, remember to whitelist
> the card for clock gating!) but card detect shouldn't be used in this
> case to detect if the card is powered or not (this is a problem for
> your card controller and card driver state tracker. The MMC subsystem
> already tracks this state fairly well for power management).

Do you mean the polling mode shouldn't been used to detect if the device 
is powered?

Is there any examples how PM support could be implemented? I'm not 
familiar with PM subsystem. How is it done in practice? Should I play 
with fixed regulators?

BR,
Lauri


> I would refrain from calling a feature "broken card detect" if there
> is actually no breakage involved especially if it would be more
> prudent instead look into how to figure out how to track power
> management state properly without cluttering the device tree.
>



More information about the linux-arm-kernel mailing list