[RFC 2/2] mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs

Ulf Hansson ulf.hansson at linaro.org
Mon Jun 19 04:50:39 PDT 2017

>> [...]
>>>>> +       if (!(cmd->flags & MMC_RSP_CRC))
>>>>> +               send |= MESON_MX_SDIO_SEND_RESP_WITHOUT_CRC7;
>>>>> +
>>>>> +       if (cmd->flags & MMC_RSP_BUSY)
>>>>> +               send |= MESON_MX_SDIO_SEND_CHECK_DAT0_BUSY;
>>>> In case the controller has HW support of busy detection, please
>>>> consider to enable MMC_CAP_WAIT_WHILE_BUSY for this driver. Then also
>>>> assign host->max_busy_timeout a good value.
>>> the IRQS register has bit 4 (CMD_BUSY) - but apart from that there is
>>> no other documentation (about timeout values, etc.). the vendor driver
>>> also neither uses MMC_CAP_WAIT_WHILE_BUSY nor host->max_busy_timeout
>>> should I leave this as it is?
>> Please don't just leave it as is. This is an important thing to get right.
>> You should be able to explore this area and see how the controller
>> behaves without too much of documentation. Regarding timeouts, it may
>> very well be that the controller don't have a timeout, which is why
>> you need a software timeout. That's not so uncommon actually.
> during my experiments I've never seen an interrupt when a command
> timed out (nor could I find information about a timeout register in
> the documentation). do you have any pointers (like a previous mail
> where you've explained) how I can "explore the controller's timeout
> behavior"?

Sorry, I don't have an pointers.

Anyway. If you do a big erase operation on an SD card, the card should
signal busy on DAT0 for a rather long time.

You could probably explore how long it takes for the card to respond
under those circumstances, and try both with and without

Of course you also need to try with and without
MMC_CAP_WAIT_WHILE_BUSY, as the core may sometimes convert R1B to R1
responses depending on that cap.


>> It shouldn't be that hard to implement, although I strongly recommend
>> you to address this in a second step. In other words, I suggest you to
>> drop the entire multiple slot support in the first step, then we can
>> deal with that on top instead.
> many thanks for the detailed explanation again!
> I would be fine with dropping multiple slot support for the moment
> *if* we can agree on the fact that the devicetree binding can support
> multiple slots in theory (my idea here is: keep the child-nodes with
> compatible = "mmc-slot" mandatory - but only allow one such child node
> for now). I don't want to break DT compatibility after a few
> weeks/months for a new driver. is that OK for you as well?

That's fine! We already have such a binding available for some other
mmc controllers. We could even consider to make that binding a generic
mmc binding.


Kind regards

More information about the linux-amlogic mailing list