On 11 July 2017 at 23:23, Martin Blumenstingl
<martin.blumenstingl@xxxxxxxxxxxxxx> wrote:
> Hi Ulf,
>
> sorry for the delay, I've been pretty busy.
> however, I'll have more time to work in this driver this and next week
>
> On Mon, Jun 19, 2017 at 1:50 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>>>
>>>> [...]
>>>>
>>>>>>> + 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.
> erase operation = mount sd card; rm big_file.bin; sync ?
> or is there some other way?
There is tool called fstrim, maybe you can you that as well.
Don't forget that the mount options of the fs also matters of what
will happen for the so called discard operations (translates to erase
in SD).
>
>> You could probably explore how long it takes for the card to respond
>> under those circumstances, and try both with and without
>> MESON_MX_SDIO_SEND_CHECK_DAT0_BUSY.
> so I simply read the card status through sysfs? or would I need to get
> some of this information from the controller?
> I found that the IRQC register contains a few interesting bits:
> u32 sdio_force_data:6; /*[13:8]
> * Write operation: Data forced by software
> * Read operation: {CLK,CMD,DAT[3:0]}*/
> I dumped these while transferring some data, the values seem to be
> changing constantly (0x3f, 0x1f, 0x20, ...)
> if I interpret those bits correctly then they are the status of the
> corresponding pin
Okay! So if the controller doesn't fully support HW busy detection,
you should at least be able to implement the ->card_busy() host ops,
which is used to poll the DAT0 line for busy detection.
>
>> 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.
> so MESON_MX_SDIO_SEND_CHECK_DAT0_BUSY + MMC_CAP_WAIT_WHILE_BUSY should
> go together?
> and MESON_MX_SDIO_SEND_CHECK_DAT0_BUSY should not be set when
> MMC_CAP_WAIT_WHILE_BUSY isn't?
Yeah, something like that.
So if you controller fully supports HW busy detection, the driver
should set MMC_CAP_WAIT_WHILE_BUSY and then act accordingly when R1B
responses are expected.
[...]
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
