Hi Ulf & Alex,

Below is the complete analysis of this issue.

The basic flow of send command is as below:
(1) Upper layer  prepare the command parameter;
(2) Call sdhci_send_command, and sdhci_send_command will call 
sdhci_set_transfer_mode  to set Host Register 0xC;
(3) Call sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND) 
to send command;

For Linux kernel mainstream (without any quirk), MMC case: 
(1) It will call  mmc_get_ext_csd and this is an DMA transfer, then DMA enable 
bit will be set to 1 (0xC[0]=1'b1).
(2) Then next Command is mmc_switch(cmd6) which is none-data command, the 
driver will keep DMA enable bit to 1; this will let our Host failed to execute 
the CMD06.

According to SD Host Spec(SD Host Controller Specification verson 4.1 page 41):
Bit0 of  Transfer Mode Register(0x0C) is DMA Enable bit, this bit set to 1 
means a DMA operation shall begin when  Host Driver writes to the upper byte of 
Command Register(0x0F).   

The DMA enable bit should be set to zero for this none-data command(CMD6). 
Our host follow the spec. so I think it should be the sdhci driver’s issue 
(sdhci_set_transfer_mode).


So We tried  SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD to fix above issue.

But it encounter new problem as Alex reported for tuning command as tuning 
command flow in sdhci_execute_tuning function is:
(1). cmd.data = NULL; 
(2). sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
(3). sdhci_send_command(host, &cmd); 
As data is null, this quirk will  set 0x0C[0:15] to ALL zero before send tuning 
command including SDHCI_TRNS_READ, and the tuning command will failed.

So, can we commit one patch as below to fix this DMA enable bit for non-data 
command bug if you cannot accept add new QUIRK?
Code should like below(sdhci_set_transfer_mode):
                if (data == NULL) {
                                if (host->quirks2 &
                                                
SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD) {
                                                sdhci_writew(host, 0x0, 
SDHCI_TRANSFER_MODE);
                                } else {
                                /* clear Auto CMD settings for no data CMDs */
                                                mode = sdhci_readw(host, 
SDHCI_TRANSFER_MODE);
                                                sdhci_writew(host, mode & 
~(SDHCI_TRNS_AUTO_CMD12 | SDHCI_TRNS_DMA    /*Clear DMA enable bit also for no 
data CMDs*/
                                                                
SDHCI_TRNS_AUTO_CMD23), SDHCI_TRANSFER_MODE);
                                }
                                return;
                }


BR
Peter.Guo

-----Original Message-----
From: Alex Ballas [mailto:[email protected]] 
Sent: Saturday, December 19, 2015 6:56 AM
To: Peter Guo
Cc: Ulf Hansson; [email protected]; [email protected]
Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader 
doesn't work

Hello Peter & Uffe,

I tested the patch with the latest mainline kernel and it played nicely.
@Uffe how should we move forward with this?

Kind Regards,
Alex

On Fri, Dec 18, 2015 at 12:43 PM, Alex Ballas <[email protected]> wrote:
> Hello Uffe, Peter,
>
> Thank you both. I'll try out Peter's patch to see if it's addressing 
> the issue and we can work through it based on Uffe's guidelines.
>
> Kind Regards,
> Alex
>
> On Fri, Dec 18, 2015 at 11:39 AM, Peter Guo <[email protected]> wrote:
>> Hi Ulf,
>>
>> Thanks for your reply.
>>
>> So currently the problem is SDHCI_TRANS_DMA bit need to be cleared 
>> before send Non DMA SD/MMC command for some of our host, Could you please 
>> give me any suggestion on what kind of code modification you can accept?
>>
>>
>> BR
>> Peter.Guo
>>
>>
>> -----Original Message-----
>> From: Ulf Hansson [mailto:[email protected]]
>> Sent: Friday, December 18, 2015 4:52 PMT
>> To: Peter Guo
>> Cc: Alex Ballas; [email protected]; [email protected]
>> Subject: Re: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card 
>> Reader doesn't work
>>
>> On 18 December 2015 at 04:14, Peter Guo <[email protected]> wrote:
>>> Hi Alex & Adam,
>>>
>>> I have send the patch. Please check it.
>>> Attachment is the patch file.
>>
>> Thanks Peter for helping out!
>>
>> Although I would appreciate if you don't send patches as attachments.
>>
>> Moreover, even if the patch can be used to check whether it solves the 
>> problem - I won't accept it as is.
>> The reason is simply that I don't allow any more quirks/callbacks to be 
>> added for SDHCI.
>>
>> Kind regards
>> Uffe
N�����r��y����b�X��ǧv�^�)޺{.n�+����{��g"��^n�r���z���h�����&���G���h�(�階�ݢj"���m������z�ޖ���f���h���~�m�

Reply via email to