Re: [PATCH] mmc: dw_mmc: Add support for multiple SD cards on one host interface

[Ulf Hansson <ulf.hansson@linaro.org>]

On 2 October 2017 at 16:31, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
> On 10/02/17 09:12, Ulf Hansson wrote:
>> On 30 September 2017 at 17:39, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
>>>
>>> Needs external logic to multiplex the clock signal,
>>> which is controlled by a GPIO output pin.
>>>
>>> Only the selected SD card receives the clock,
>>> while the other SD card's clock is forced to LOW.
>>> DATA and CMD lines can be connected to both SD cards.
>>>
>>> On warm-start UBOOT should use a sequence of
>>> CMD12 and CMD7 with RCA=0 to force any active SD card
>>> to stop transmission and release the DATA bus.
>>
>> I doubt that is sufficient to support multiple slots.
>>
>
> A hardware exists and AFAICT works as expected,
> with bus speeds up to 50 MHz.
> We have a use case with internal peripherals.
>
>> Sometimes the mmc core needs to perform a sequence of operations
>> towards *one* host/card and that must be done in guaranteed manner, to
>> that no other operations are performed for another card/host
>> in-between.
>>
>
> Could you please elaborate on this?

mmc_claim|release_host() is used by the core to get exclusive access
to the host and its controller.

That's needed for a several reasons, both good and bad. In the case I
am referring to, it's about running a sequence of operations as to
follow the MMC/SD/SDIO spec. The sequence may involve calling several
of the host ops callbacks (->set_ios() ->request() etc) in a row,
without having any other to interfere with the same host.

Now, because those host drivers that *tries* to support multiple
cards, registers one host per card slot, the above assumption from the
core falls apart. In other words, the core can no longer guarantee to
follow the specs.

>
>> Perhaps if you are lucky you may get something that is very fragile to
>> work, but in the end I think the core needs to play along. Moreover,
>> dw_mmc has recently removed its multiple slot support - simply because
>> the complexity wasn't worth it.
>>
>
> I was not overly happy to see this removed, when I re-based to current master :-(

Sorry, but the code has never worked. And because no one complained,
it for sure made sense to remove it.

Kind regards
Uffe