On Fri, 16 Jan 2015 11:36:46 +0000 Russell King - ARM Linux
<[email protected]> wrote:
> On Fri, Jan 16, 2015 at 07:53:08AM +1300, NeilBrown wrote:
> > Also, it isn't clear to me whether the need for power/reset is a function of
> > the mmc-host, or a function of the device attached to the host. I suspect
> > some are needed by one, some by the other. Any by both?
>
> Neil,
>
> There's a horrid issue there. The standard model of MMC/SD is that the
> device will be powered up by the host, and will then be probed to find
> out what the device is. This normally works fine as the host is
> responsible for controlling the power to the socket which the card is
> plugged into.
>
> Where things fall down is when you have a MMC/SD device embedded onto
> a board, and they decide that it'll be given separate controls for
> power and reset which are not under the control of the host.
>
> If the MMC/SD device is not powered up before we probe the bus, then
> the device is not discoverable, and this breaks the standard model:
> - If we run the standard MMC/SD device discovery code with the device
> powered down, it will find no device attached, so no device will be
> created.
>
> - If we create a device, then the device driver will be probed
> immediately. While the device driver can then bind, discover the
> power and reset controls, and activate them, it can't then talk to
> its device because the MMC layer hasn't gone through the required
> standard device discovery and probe sequence. If we could do that,
> we would then need some way to stop that mechanism creating another
> device.
Hi Russell,
thanks for the overview - quite helpful.
I would like to particularly focus on that last sentence mentioning
"some way to stop [standard device discovery] creating another device".
That way already exists, or something very similar to it, in the mmc/sdio
core. In particular, the 'oldcard' argument to mmc_sdio_init_card().
This is called both when initialising a card and when restoring power to it.
If 'oldcard' is set and the card found matches 'oldcard', then 'oldcard' is
left unchanged. i.e. a new device is not created.
Suppose that devicetree listed a child node for an mmc host with
"non-removable" set, then we could do a preliminary probe which sets
up host->card so that subsequent "standard" probes find the properly
matching card and leave 'oldcard' unchanged. This card could somehow
register its own power-up sequence.
In the case of 'non-removable' it might be nice to be much more cautious
about clearing host->card when a probe fails. One of the (many) problems I
have on my device is that occasionally the probe of the mmc/sdio/wifi card
fails (EBUSY I think, but I'm not sure and I have no idea why). Once that
happens, the wifi becomes inaccessible until a reboot.
As mmc_rescan ensures that a non-removable card is only scanned once, it
would be really good if we were extra careful never to remove a
non-removable card, even in the face of error...
>
> If we instead take the view that the host is responsible for powering
> up the device, then we are merely keeping with the standard MMC/SD
> model, and we don't have to hack around his.
>
> Keeping to the standard model of a host responsible for power control
> of its child devices is just a whole lot nicer.
>
I'm not really against the proposed patch. It should remove at least one of
my problems, and I don't think it makes any other problems more difficult.
So if the above ideas don't appeal to anyone else, I'll raise no further
objections.
Thanks,
NeilBrown
N�����r��y����b�X��ǧv�^�){.n�+���z��z��z)����w* jg��� �����ݢj/���z�ޖ��2�ޙ����&�)ߡ�a���� �G���h��j:+v���w��٥
