On 2 October 2017 at 16:31, Bernd Edlinger <bernd.edlinger@xxxxxxxxxx> wrote: > On 10/02/17 09:12, Ulf Hansson wrote: >> On 30 September 2017 at 17:39, Bernd Edlinger <bernd.edlinger@xxxxxxxxxx> 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 -- 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
